Desarrollo de Software con IA

Arquitectura sin sintaxis: dibujar el sistema antes de pedirlo

Dibujar el mapa de componentes y conexiones de una aplicación y usarlo como guía en el prompt.

El plano antes del ladrillo

Firma a punto de sellar un contrato junto a un tampón de oficina sobre el escritorio.
Entre piezas, como entre empresas, hay contratos: quién llama a quién, con qué datos y de quién es la responsabilidad. Un plano sin contrato es una postal.

Un constructor no empieza sin plano. Tú tampoco deberías empezar a pedir código sin saber qué piezas va a tener tu sistema y cómo se hablan entre ellas. Dibujar la arquitectura no es programar: es decidir de antemano el mapa. Cuando el mapa está claro, cada prompt deja de ser una apuesta.

[Las cuatro piezas de casi toda aplicación web]

Esta actividad interactiva ('Explicacion visual') requiere el motor completo de Lumbre. El contenido estatico se muestra arriba; para la experiencia interactiva, visita la version online de este objeto.

Qué es cada pieza (en una frase)

Nombra la pieza y su trabajo; la IA pone la sintaxis.
PiezaLo que haceNo necesitas saber…
FrontendLo que el usuario ve y toca en el navegadorel CSS exacto de cada botón
BackendLa lógica que decide qué pasa con lo que se envíala sintaxis del servidor
Base de datosDonde se guarda la información que persisteoptimizar índices
APIEl puente por el que frontend y backend se hablanfirmar cada endpoint a mano

Cómo usar el plano en el prompt

Cuando le entregas el mapa a la IA, dejas de decir «hazme una app» y empiezas a decir «esto vive aquí, esto se conecta allá». El mismo plano se pega en cada prompt para que la IA no invente una arquitectura distinta en cada respuesta.

El plano como constraint
ARQUITECTURA DEL PROYECTO (respétala, no la cambies sin avisar):\n- Frontend: pagina de agenda de contactos (lista + formulario).\n- API interna: GET /contactos, POST /contactos, PUT /contactos/{id}, DELETE /contactos/{id}.\n- Backend: valida y guarda en la base de datos.\n- Base de datos: tabla contactos(id, nombre, telefono, email, creado_en).\n\nConstruye SOLO el endpoint GET /contactos siguiendo este mapa. No toques el frontend todavía.

Para profundizar

Las capas de una aplicación: frontend, backend y datos
OA ya publicado en «IA Aplicada y Negocios Digitales». Repasa las capas antes de seguir; aquí no lo repetimos, lo ampliamos hacia el plano.

Prueba

En tu plano, el formulario de registro del usuario guarda el usuario. ¿Qué pieza decide realmente si el correo es válido y lo escribe en la base de datos?

Dibujar la arquitectura exige saber escribir el código de cada componente.

Detecta el plano roto

Un alumno describe la arquitectura de su app. Señala la conexión que NO tiene sentido en un sistema web típico:

  1. El frontend muestra los datos que recibe de la API.
  2. La base de datos guarda la información que le pasa el backend.
  3. El navegador del usuario se conecta directamente a la base de datos para ir más rápido.
  4. El backend expone endpoints que el frontend consume.

Identifica la linea con error.

Dibuja (a mano o como lista) la arquitectura de tu proyecto: nombra cada pieza y qué le envía a cuál. Pégala al inicio de tu próximo prompt de código.

PistaSi no sabes cómo se conecta una pieza con otra, ahí tienes un hueco de diseño que la IA rellenará por ti sin consultar.