Arquitectura de 3 capas:que la IA escriba código limpio

La IA genera código desordenado porque tu proyecto no tiene arquitectura, no porque la IA sea mala. Una arquitectura de 3 capas lo arregla. Dale tres capas claras (componentes para la UI, servicios para la lógica de negocio y una capa de datos para la base de datos) y pídele una capa cada vez, y la misma IA produce código limpio, testeable y escalable. Yo construí más de 3 millones de líneas así.

Este es el patrón, por qué funciona y la secuencia exacta de prompts.

El problema: la IA sin estructura crea caos

Le pides a la IA que construya una funcionalidad. Te da código. Lo pegas. Una semana después, tu código es un desastre: llamadas a la base de datos esparcidas por todas partes, lógica de negocio mezclada con la UI, código copiado y pegado por todos lados, imposible de testear, que se rompe cuando intentas escalar.

La IA no es el problema. Tu arquitectura sí.

La IA genera lo que le pides. Pero sin una arquitectura clara, mezcla responsabilidades, crea patrones inconsistentes y no puede mantener la estructura de tu código: cada prompt crea nuevo caos. La IA no conoce tu arquitectura. Tienes que guiarla tú.

La solución: una arquitectura de 3 capas

Imagina tu app como una pila de tres plantas. Los componentes arriba: solo UI. Los servicios en el medio: lógica de negocio. La capa de datos abajo: base de datos y APIs. Cada planta solo habla con la que tiene justo debajo. Cuando la IA sabe en qué capa está trabajando, genera código limpio.

• Capa 1: componentes (solo UI). Lo que va aquí: lógica de visualización, interacciones del usuario, enrutado, maquetación. Lo que no: llamadas a la base de datos, lógica de negocio, validación, permisos. Un mal componente obtiene los usuarios de la base de datos dentro de sí mismo, filtrando por estado por el camino. Un buen componente le pide a un hook los "usuarios activos", muestra un esqueleto de carga mientras espera y renderiza la lista. Ese es todo su trabajo.
• Capa 2: servicios (lógica de negocio). Lo que va aquí: obtención de datos, validación, permisos, reglas de negocio, transformaciones de datos. Lo que no: nada que renderice, ni estado específico de un componente. Un UserService conoce las reglas (se requiere una organización, qué filtros se aplican, qué pasa si falla) y es el único lugar donde viven esas reglas.
• Capa 3: datos (base de datos y APIs). Consultas a la base de datos, llamadas a APIs, integraciones externas. Se accede solo a través de servicios, nunca directamente desde los componentes.

Cómo darle prompts a la IA con este patrón

La forma equivocada es un solo prompt: "Build a user management feature." El resultado es todo en un único componente: llamadas a la base de datos, validación y UI, todo mezclado. La forma correcta son tres prompts, de abajo arriba, uno por capa:

1. Primero el servicio: "Generate a UserService with methods to get, create, update, and delete users. Include validation and error handling."
2. Después el hook: "Create a useUsers hook that wraps the UserService with caching."
3. Al final el componente: "Build a UserList component that uses the useUsers hook. Display loading states and handle errors."

Resultado: código limpio y separado, con cada capa centrada en su responsabilidad. Pedirlo todo de golpe es el error número uno: la IA genera código mezclado con todas las capas enredadas. Una capa cada vez, construyendo de abajo arriba.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

Funciona con cualquier stack

El mismo patrón, con herramientas distintas:

¿Ya tienes código desordenado? La migración en 5 pasos

1. Encuentra todas las llamadas a la base de datos. Busca en tus componentes las llamadas directas a la base de datos y a APIs.
2. Crea servicios. Mueve todo el acceso a datos a clases de servicio: la consulta que vivía dentro de un componente ahora vive en un método de servicio con gestión de errores.
3. Crea hooks. Envuelve cada servicio con la capa de obtención de datos de tu framework para que los componentes reciban caché y estados de carga gratis.
4. Actualiza los componentes. Sustituye el patrón de pedir los datos dentro del componente por una única llamada a un hook.
5. Deja que la IA ayude. Prompt: "Refactor this component to use the hook pattern. Move database logic to a service." La IA migrará cada pieza.

La recompensa se ve de inmediato en los tests: los servicios se testean sin ninguna UI, los hooks se testean como envoltorios finos y los componentes se testean con el hook simulado. Capas limpias = tests fáciles.

Por qué funciona

Sin capas, la IA genera componentes monolíticos, duplica lógica entre archivos y produce código difícil de testear, difícil de mantener y que se rompe al escalar. Con capas, la IA genera código enfocado para cada capa, la lógica está centralizada en los servicios, cada capa se testea de forma independiente y escala hasta millones de líneas.

Construí más de 3 millones de líneas de código así. Funciona. Esta es la arquitectura exacta que hay detrás de FIKR Space: más de 3 millones de líneas, 964 tablas de base de datos, 5 productos integrados, construido con Claude y funcionando en producción. Los dos errores que evitar: saltarse los servicios ("usaré los hooks directamente con la base de datos": la lógica de negocio en los hooks es difícil de testear e imposible de reutilizar) y los componentes gordos ("pondré la validación en los componentes": no puedes reutilizarla ni testearla sin la UI).

Antes de lanzar, pasa la checklist: ninguna importación de base de datos en los componentes, toda la lógica de negocio en los servicios, los componentes solo gestionan la UI, los hooks envuelven servicios, los servicios se pueden testear sin UI, gestión de errores en todas las capas. Este patrón es el pilar 2 de los cinco pilares del software en producción, y una vez que existen las capas, los prompts estructurados como el método PRP se vuelven muchísimo más fiables, porque cada prompt tiene un lugar evidente donde encajar.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

Preguntas frecuentes

¿Necesito entender de código para usar la arquitectura de 3 capas?

Necesitas entender el mapa, no las calles. Saber que la UI, la lógica de negocio y el acceso a datos son tres plantas separadas, y que cada prompt apunta exactamente a una, basta para dirigir bien a la IA. La arquitectura es una herramienta de comunicación entre tú y la IA, y dirigir es tu mitad del trabajo.

¿Son 3 capas demasiado para un MVP pequeño?

No, porque el coste es casi cero y la alternativa se acumula. Tres prompts en lugar de uno el primer día son unos minutos de trabajo extra; desenredar las llamadas a la base de datos de cincuenta componentes en el sexto mes son semanas. El patrón escala hacia abajo hasta un proyecto de fin de semana y hacia arriba hasta millones de líneas: yo lo he usado en ambos extremos.

¿Qué va en un servicio y qué en un hook?

Las reglas van en el servicio; la fontanería va en el hook. Si es una decisión de negocio (qué se considera válido, quién tiene permiso, cómo se calcula un valor), pertenece al servicio. Si trata de llevar datos a la pantalla (caché, indicadores de carga, recarga de datos), pertenece al hook. En caso de duda, ponlo en el servicio: los servicios son más fáciles de testear y reutilizar.

¿Cómo hago que la IA respete las capas automáticamente?

Escribe la regla en las instrucciones permanentes de tu proyecto: los componentes nunca importan el cliente de la base de datos, todo acceso a datos pasa por servicios, los hooks envuelven servicios. Luego haz que cada prompt nombre su capa ("crea un método de servicio para..."). La IA sigue la arquitectura que está realmente escrita, nunca la que tienes en la cabeza.