De Vibe Coding a Ingeniería

El “Vibe Coding” no escala. El LLM se degrada, alucina y produce errores cuando pierde el contexto. La solución es simular la misma práctica que utilizamos al programar, pero adapatada. Esto significa pasar de una conversación fluida a un pipeline (o línea de montaje) de agentes o sub agentes que ejecutan contratos, no que interpreten nuestras intenciones.

Cuando la Memoria Falla

El Vibe Coding es lo que hacemos cuando abrimos un chat con un LLM (ChatGPT, Gemini, Claude) y comenzamos a pedirle código en una conversación que cada se hace más larga. Es atractivo, sin duda. Para un prototipo rápido o un script simple de lógica aislada, la fluidez que nos entrega es lo mejor. Pero en el momento en que el proyecto se hace más complejo, con capas aisladas, abstracción y lógica de negocio, nos chocamos de frente contra una pared: el límite de la memoria del modelo.

Esta pared se llama Context Window (Ventana de contexto). Se trata de la cantidad finita de información (medida en tokens) que un modelo puede procesar en un único instante. En la práctica, imaginate que eestás realizando un trabajo para entregar, pero tu memoria RAM se llena y la computadora empieza a cerrar programas al azar para hacer lugar. Entre esos programas que cierra, tenías información que era importante para que el trabajo esté bien realizado. Eso mismo le pasa al LLM, para prestarle atención a tus nuevos mensajes, debe “olvidar” partes de la conversación, incluyendo tus instrucciones críticas. Siendo un poco más técnicos, no es que la olvida, pero casi; sino que comprime todo lo que estuvieron hablando para liberar espacios en la Ventana de Contexto. De esa manera nos da la sensación de que mantiene el hilo de la conversación, pero muchas partes se perdieorn.

Cuando el modelo comprime la conversación, empiezan los problemas serios:

• Alucinaciones: El agente se desvía de las reglas originales y empieza a inventar funcionalidad.
• Código Monolítico: Sin una estructura clara y persistente, el LLM tiende a agregar código en un único bloque.

La solución para esto es el Specification-Driven Development (SDD). La IA no debe ser un compañero de código, sino una herramienta de ejecución que cumple un contrato (spec).

El Patrón Orquestador

Para implementar SDD con agentes, necesitamos una arquitectura que resuelva el problema de la memoria. Aquí es donde entra el patrón Orquestador.

Su trabajo no es ejecutar, sino enrutar. Toma lo que queremos realizar y delega las distintas tareas a otros agentes (o chat LLM). Sería como un director de orquesta. Él no toca el violín ni el piano; solo le indica al violinista cuándo es su turno de tocar. Nuestro Orquestador hace exactamente eso. Sigue una lista de pasos que le establecimos, lo cual marca el estado del proyecto y decide qué agente es el siguiente en la línea de producción.

La habilidad de esta arquitectura es el aislamiento de memoria. Cada vez que el Orquestador llama a un Skill o sub Agente, este se ejecuta en un entorno completamente limpio, con una Ventana de Contexto nueva y sin conocer lo que hablamos anteriormente. Es como abrir una pestaña de incógnito para cada tarea. El agente puede enfocar el 100% de su atención en su objetivo, sin el ruido de las 50 pestañas que tenías abiertas antes. Así, el problema de la Ventana de Contexto principal se anula por diseño. Gracias a esta manera de trabajar, el Orquestador puede realizar una implementación de inicio a fin manteniendo en memoria la totalidad de lo que fue sucediendo.

Skill

Si el Orquestador es el patrón, entonces un Skill es un obrero que se especializa en una única tarea. Se compone de tres partes:

1. System Prompt: Un conjunto de instrucciones que le dice quién es, qué hace, qué formato debe seguir y cuáles son sus limitaciones.
2. Input: El recurso que consume. Un archivo específico, como requerimiento.md.
3. Output: La tarea que realizó, como esquema.md.

Gracias a esto, luego el orquestador puede determinar que si en nuestra carpeta Workflow existe el archivo esquema.md puede continuar la ejecución del flujo o Pipeline llamando a otro agente a quién se le pasará el archivo recién creado (esquema.md) y cuya función es realizar un nuevo trabajo que termine generando otro archivo. Esto se repite tantas veces como el proyecto necesite, pudiendo trabajar con 5, 6, 7 o más sub agentes, cada uno especializado en algo específico. En conjunto, toda esta ejecución concluye con el requerimiento inicial programada, corregido y probado para incluirlo en Producción.

El trabajo del Skill, por lo tanto, es ser una parte de una línea de montaje o Pipeline.

Pipeline

La definición técnica dice que un pipeline es una serie de etapas de procesamiento lineal. Puesto en práctica, es una fábrica donde la IA tiene una tarea específica con un inicio y un fin. Al concluir se lo libera, para el Orquestador retomar el flujo y decidir cuál Agente continúa. Así garantizamos que el código no sea un “vibe” sino un producto de diseño.

El Pipeline queda de la siguiente manera:

[USUARIO] -> creamos el archivo requerimiento.md 

[ORQUESTADOR]
  Entrada: requerimiento.md
  Función: Lee archivos locales, decide el próximo skill, limpia el contexto y hace la petición.
  Salida: Orquestación de archivos.

  |
  +-> 1. [SKILL PLANIFICADOR]
  |      Entrada: requerimiento.md
  |      Salida: backlog.md (Lista de tareas atómicas)
  |
  +-> 2. [SKILL ARQUITECTO]
  |      Entrada: backlog.md (Tarea actual) + requerimiento.md
  |      Salida: diseño_tarea.md (Contratos, OpenAPI, firmas de interfaces en C#)
  |
  +-> 3. [SKILL IMPLEMENTADOR]
  |      Entrada: diseño_tarea.md
  |      Salida: codigo_fuente.cs (Lógica estricta sin alterar firmas)
  |
  +-> 4. [SKILL TESTER (QA)]
  |      Entrada: codigo_fuente.cs + diseño_tarea.md
  |      Salida: reporte_qa.md (Aprobado/Fallo) + codigo_test.cs
  |
  +-> 5. [SKILL REVISOR] (Solo si QA falla)
         Entrada: codigo_fuente.cs + reporte_qa.md
         Salida: codigo_corregido.csanguage

Con esta línea de trabajo, aseguramos que la Ventana de Contexto del Orquestador no se llene, pero también evitamos que en cada etapa sea necesario leer todo el proyecto para poder ejecutar la nueva tarea. Esta es una manera en la que se trabaja hoy en desarrollo y es una gran solución que nos permite gastar menos recursos (tokens) en una tara, ya que cada Skill desconoce el proyecto porque tiene una tarea específica para lo cual solo requiere una información de entrada precisa.

El Requerimiento

La definición formal de un requerimiento técnico es un documento que especifica el proyecto que queremos realizar. Puesto en práctica, el requerimiento.md es el punto inicial de tus agentes. Todo inicia con este requerimiento y cada Skill sin saberlo lo está siguiendo al pie de la letra.

Acá es donde comienza a separarse el que sabe de código del que solo le pide un chat qué es lo que tiene que hacer. Y para saber qué pedirle a la IA en un requerimiento necesitás entender de ćódigo. Excepto que te conformes con algo “similar”.

Si vos no sabés qué es una Inyección de Dependencias, un DTO o por qué tu Dominio tiene que estar aislado de la Infraestructura, no se lo podés pedir al agente. Y si no se lo pedís, la IA va a elegir el camino que consideré mejor (el más corto si no somos capaces de poner restricciones fuertes).

Escribir un requerimiento efectivo es, en esencia, programar en un nivel de abstracción superior. Vos sabés qué es lo mejor para el proyecto que estás desarrollando, porque entendés la cantidad de usuarios que podés manejar y sabés qué lógica de negocio es necesaría. Porque ya o hiciste y te equivocaste y pagaste por ese error, sabés que aunque la IA no lo proponga, tenés que poner memoria Caché; o guardar en Token el Claim que te permita revocarlo en caso de problemas de seguridad; incluso sabés que si tu proyecto crece y no querés tener problemas de licencia lo mejor es evitar SQL Server.

Si no sabés programar, tus resultados no van a ser más que Productos Mínimos Viables o ejemplos de lo que querías realizar. Podés tener el mejor orquestador del mundo, los skills de un programador Senior y pagar el modelo más caro de IA, pero si tu requerimiento es vago, lo que vas a obtener es un sistema que “parece” que funciona pero que no escala.

El orquestador ejecuta, el skill construye, pero vos dirigis toda la línea de montaje.

Estado Cero

La IA no parte de la nada. Antes de que el Orquestador pueda siquiera ejecutarse, un humano debe preparar el terreno. Este Estado Cero tiene tres componentes:

1. Los Cimientos: Vos tenés que crear la estructura de directorios, los archivos de configuración y, más importante, los System Prompts de cada Skill.
2. Memoria Constitucional: Para convenciones que no deben cambiar jamás (estilo de código, decisiones de arquitectura), se usa una memoria persistente como Engram (Proyecto Open Source de Gentleman Programing). Es la “constitución” del proyecto, que los agentes pueden consultar pero no modificar.
3. El Punto de Ignición: La ejecución del Orquestador por primera vez. A partir de ahí, el sistema es autónomo. Podemos utilizar herramientas como Open Code que se pueden configurar para que inicie el Pipeline con un comando /init-orquestator.

Conclusión

Es por todo esto que saber programar es esencial para el mundo que se viene. No se trata de decir a un ‘chat’: “Hacé X proyecto, con charts y colores bonitos”, sino utilizar a la IA como una verdadera herramienta que ejecuta lo que necesitamos. Cero sorpresas finales. Tiene que entregarnos lo que le pedimos.

Si bien la tarea de escribir código poco a poco empieza a delegarse, comienza una etapa más compleja en la que debemos de entender sobre Arquitecturas, patrónes, lógica de negocio, herramientas, alcances, escalaibilidad, etc.

En resumen, no podés crear con la IA lo que no sabés programar por tu cuenta. El costo técnico de hacerlo puede ser muy caro.

Como consejo final, intentá programar lo que ya sabés. Un CRUD con Postgres, NodeJS y NextJs. Lo que sea, pero que entiendas por completo. Escribí ese requerimiento como un mapa que vos mismo seguirías. Revisá cada etapa de los Skills para ver si están siguiendo el requerimiento.md. Si no lo siguen, es porque faltaron lineamientos o algunos punto de ese archivo son ‘vagos’. Ajusta las Skills, mejorá al Orquestdor, mirá cómo resuelven los problemas otros programadores más experimentados. Estudía otros patrones con SDD. Poco a poco, hasta que finalmente el resultado que obtenés es exactamente el que esperabas.