La IA no es cara. Tu arquitectura sí.

No dejo de ver gente entrando en pánico por los costos de la IA, el consumo de tokens, las ventanas de contexto que se quedan cortas y cómo «la IA deja de ser útil» cuando un proyecto crece.

Pero el problema no es la IA. Y la mayoría de las veces, ni siquiera es el prompt.

El verdadero problema es cómo construimos software

Durante años repetimos los mismos principios de ingeniería:

• mantener el código claro y conciso,
• separar responsabilidades,
• aislar el comportamiento mediante la arquitectura,
• usar paquetes y módulos con propósitos específicos,
• diseñar sistemas que puedan escalar sin colapsar.

Después apareció la IA generativa y, de repente, todos quieren ignorar décadas de ingeniería de software volcando una aplicación entera en un único prompt gigantesco.

Mi ciela, no. Así no funciona. Y dudo seriamente que alguna vez funcione.

Si quieres construir software en serio con IA, tienes que volver a los fundamentos:

• módulos pequeños,
• responsabilidades aisladas,
• funciones enfocadas,
• contexto acotado,
• estructuras de dependencias claras,
• arquitectura antes que generación.

La IA rinde muchísimo mejor cuando el sistema en sí está bien diseñado. Porque la IA no «entiende tu producto» por arte de magia. Opera sobre contexto. Y cuanto más caótico se vuelve tu contexto, más tokens desperdicias, más alucinaciones aparecen y más caro se vuelve todo.

Muchos desarrolladores intentan usar la IA como reemplazo de la arquitectura. Pero la IA no reemplaza la arquitectura. La vuelve todavía más importante.

Interactivo // Lo que un cambio arrastra al contexto

Elige el módulo que quieres cambiar. Compara un prompt monolítico con una arquitectura modular y después improvisa mezclando responsabilidades.

Prompt monolítico Arquitectura modular

Improvisar: mezclar responsabilidades

Módulo a cambiar

Interfaz Autenticación Usuarios Catálogo Pedidos Facturación Notificaciones Búsqueda Reportes

ModificadoCargado en contexto

3 de 9 módulos en contexto

Contexto acotado: solo el módulo que cambias y los contratos de los que depende.

A escala empresarial, sí, el consumo de tokens puede volverse enorme. Pero incluso trabajando solo, como desarrollador y product manager, puedo construir sistemas altamente escalables casi sin quedarme nunca sin contexto.

¿Y las pocas veces que pasó?

Fue porque me alejé de la arquitectura. Empecé a improvisar funcionalidades. Probé ideas innecesarias. Mezclé responsabilidades que tendrían que haber quedado aisladas. Ahí es cuando el contexto explota. Ahí es cuando los prompts se vuelven enormes. Ahí es cuando la respuesta de la IA empieza a degradarse.

Porque el problema nunca fue el modelo. Quizás alguna que otra vez sí. Pero el verdadero problema siempre fue el sistema.

Hoy más que nunca, construir con IA exige pensar el software como un verdadero desarrollador de la vieja escuela:

• definir límites,
• diseñar contratos,
• separar dominios,
• planificar la escalabilidad,
• crear paquetes reutilizables,
• agregar funcionalidades sin romper el resto del sistema.

Primero la arquitectura, después las funcionalidades

Esto requiere desarrolladores capacitados, sí. Pero, por encima de todo, requiere un cambio de mentalidad: pensar las funcionalidades desde un punto de vista arquitectónico. No solo «¿qué quiero que haga esto?», sino «¿cómo lo agrego sin romper lo que ya existe?».

Diagrama // Una funcionalidad, vista desde la arquitectura

1. 01Funcionalidad¿qué quiero que haga?
2. 02Límites¿a qué dominio pertenece?
3. 03Contratos¿de qué depende?
4. 04Generacióncon contexto acotado, sin romper lo que existe

Claro, para un MVP o una prueba de concepto puedes juntar todo y moverte rápido.

Pero si nunca haces el trabajo duro después (aislar responsabilidades, reestructurar la arquitectura, organizar el sistema como corresponde), la IA termina convirtiéndose en una pesadilla operativa.

Y ahí es cuando todos dicen: «La IA es demasiado cara».

No.

Lo caro es improvisar. La IA solo lo deja en evidencia más rápido.

Pero aquí es donde se complica

Todo lo que describí hasta ahora es manejable cuando eres un desarrollador que trabaja solo. Tú tomas las decisiones de arquitectura. Tú defines los límites. Tú controlas el caos.

Ahora suma un equipo de producto. Suma stakeholders que piensan en funcionalidades, no en sistemas. Suma desarrolladores que tienen cada uno su propia interpretación de lo que significa «código limpio». Suma la presión del sprint, los compromisos del roadmap y un CEO que acaba de ver una demo y quiere esa funcionalidad para el viernes.

De repente, «pensar la arquitectura antes que las funcionalidades» deja de ser un principio técnico y se convierte en un desafío organizacional. Y la mayoría de los equipos no están para nada preparados.

En el próximo artículo voy a profundizar justamente en eso: cómo el pensamiento arquitectónico tiene que vivir no solo en el código, sino en cómo se estructuran los equipos de producto y desarrollo, cómo se comunican y cómo toman decisiones juntos antes de que la IA siquiera abra un archivo.

Nos vemos pronto.