De Vibe Coding a Ingeniería

El “Vibe Coding” en un chat de LLM no escala. Se degrada, alucina y produce código inmanejable. La solución es aplicar ingeniería. Esto significa pasar de una conversación fluida a un pipeline de agentes especializados que ejecutan contratos, no que adivinan intenciones.

Cuando la Memoria Falla

El Vibe Coding es lo que hacés cuando abrís un chat con un LLM y empezás a pedirle código en una conversación larguísima. Es atractivo, sin duda. Para un prototipo rápido o un script simple, la fluidez es imbatible. Pero en el momento en que el proyecto gana complejidad, te chocás de frente contra una pared invisible: el límite de la memoria del modelo.

Esta pared se llama Context Window. Técnicamente, es la cantidad finita de información (medida en tokens) que un modelo puede procesar en un único instante. Seguro, esto no te dice nada. En la práctica, imaginate que tu memoria RAM se llena y la computadora empieza a cerrar programas al azar para hacer lugar. Eso mismo le pasa al LLM: para prestarle atención a tus nuevos mensajes, debe “olvidar” partes de la conversación anterior, incluyendo tus instrucciones críticas.

Cuando el modelo olvida, empiezan los problemas serios:

• Alucinaciones: El agente se desvía de las reglas originales que ya no recuerda y empieza a inventar funcionalidad o a ignorar restricciones.
• Código Monolítico: Sin una estructura clara y persistente, el LLM tiende a agregar código en un único bloque. El resultado es un “Frankenstein” imposible de mantener, testear o refactorizar.

La solución para esto es el Specification-Driven Development (SDD). El cambio de paradigma es fundamental: la IA no debe ser un compañero creativo que adivina, sino una herramienta de ejecución que cumple un contrato, una especificación (spec).

El Patrón Orquestador: Una Arquitectura de Atención Delegada

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

La definición técnica es que el Orquestador es una máquina de estados finitos que delega tareas a agentes especializados (Skills). Su trabajo no es ejecutar, sino enrutar. ¿No te dice nada? Pensá en 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: mira 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, este se ejecuta en un entorno completamente limpio, sin la contaminación del “dialogo” anterior. 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 atómico, sin el ruido de las 50 pestañas que tenías abiertas antes. Así, el problema del Context Window se anula por diseño.

Anatomía de un Skill: Los Obreros Especializados

Si el Orquestador es el patrón, entonces un Skill es un obrero especializado en una única tarea. Su anatomía es simple y se compone de una trinidad:

1. System Prompt: Su ADN. 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 especificaciones.md.
3. Output: El artefacto que produce. Otro archivo, como esquema.md.

Y su trabajo es ser una parte de una línea de montaje que definimos como Pipeline.

En la actualidad, puede que escuches hablar de “Sub-agentes”, lo cual no es otra cosa que una Skill a la que el Orquestador le entrega lo mínimo y necesario para que arranque con un Context Windows en cero.

Línea de montaje: 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 prohibido improvisar. Si un skill intenta hacer más de lo que su tarea indica, el sistema se rompe. Así garantizamos que el código no sea un “vibe” sino un producto de diseño.

Entonces, el Pipeline o flujo de ejecución general del Orquestador y Skill queda de la siguiente manera:

[USUARIO] -> requerimiento.md -> [ORQUESTADOR]

[ORQUESTADOR] (Script de control)
  Entrada: requerimiento.md, estado actual.
  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 el Context Windows del Orquestador no se llene, pero también evitamos que en cada etapa sea necesario leer todo el proyecto para poder ejecutar. 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.

El Requerimiento: La Piedra Angular (si no sabés programar, ya perdiste)

La definición formal de un requerimiento técnico es un documento que especifica las capacidades, interfaces y restricciones de un sistema. Puesto en práctica, el requerimiento.md es el código fuente de tus agentes. Es la estaca que clavás en el suelo y de la cual la IA no se puede soltar.

Acá es donde se separa el que sabe de código del que solo le pide un chat qué es lo que tiene que hacer:

La IA no llena baches de lógica: 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 más corto (y probablemente el más mediocre).

La precisión es el nuevo lenguaje de programación: Escribir un requerimiento efectivo es, en esencia, programar en un nivel de abstracción superior. Si no entendés cómo funciona el software por dentro, no tenés la capacidad de dictar las reglas del juego.

Si no sabés programar, te falta la piedra angular. 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 es una bomba de tiempo técnica.

El orquestador ejecuta, el skill construye, pero vos diseñás. Si no sabés qué estás diseñando, la IA solo va a automatizar tu propia confusión.

Estado Cero: La Preparación del Terreno

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. Es la “constitución” del proyecto, que los agentes pueden consultar pero no modificar.
3. El Punto de Ignición: Un simple script (go.sh o similar) que ejecuta al Orquestador por primera vez. A partir de ahí, el sistema es autónomo. También podemos utilizar herramientas como Open Code que se pueden configurar para que inicie el Pipeline.

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”, 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.