En febrero de 2025, Andrej Karpathy describió el "vibe coding" como la práctica de describir la intención en lenguaje natural, aceptar los cambios de un LLM con una revisión mínima y dejar que el código crezca más allá de tu comprensión habitual. Ofrecía una velocidad impresionante para proyectos personales y prototipos.
Un año después, observó que las capacidades de los agentes habían avanzado y propuso "ingeniería agentiva" como su nombre preferido para la práctica evolucionada de orquestar agentes mientras se mantiene una fuerte supervisión humana de la arquitectura y el proceso. El objetivo, según lo planteó, es aprovechar el poder de los agentes sin comprometer la calidad del software.
La distinción es importante. El "vibe coding" funciona bien para un solo usuario en trabajos personales de bajo riesgo, pero rápidamente acumula deuda oculta, brechas de seguridad y problemas de mantenibilidad en el momento en que otras personas dependen del resultado. La ingeniería agentiva mantiene la velocidad y el poder de los agentes modernos, pero ancla todo en una estructura clara, artefactos trazables y responsabilidad humana.
El Flujo de Trabajo de la Ingeniería Agentiva
Comienza con una intención aproximada y lleva a cabo conversaciones de diseño con la IA mientras documentas la funcionalidad en notas de reuniones de diseño, describiendo la funcionalidad en sus partes componentes. Una vez que el diseño se siente sólido, captura la vista de alto nivel y el mapa de componentes en una jerarquía de diseño (esto es lo que la gente muestra cuando muestra un "cerebro" de Obsidian): una estructura navegable que te da a ti y al agente acceso inmediato al contexto circundante, decisiones relacionadas y dependencias. Aquí también es donde viven los diagramas de diseño, como UML (Lenguaje de Modelado Universal), flujos de código o de interacción de usuario, junto con enlaces a registros de decisiones arquitectónicas (ADR) donde aclaran cómo se relacionan los componentes.
Para cada módulo o bloque de funcionalidad más pequeño, crea un spec.md enfocado dentro del LLD que defina el comportamiento preciso, las firmas de funciones, los casos límite, las expectativas de prueba y los puntos de integración. Usando toda la estructura como contexto de diseño, incita a la IA a construir una jerarquía tipo ticket con trazabilidad directa a las páginas wiki y los specs. Implementa ticket por ticket con el agente siguiendo el spec.md relevante como su contrato. Luego ejecutas puertas de verificación, despliegas, observas y actualizas los artefactos vivos a medida que los requisitos evolucionan.
Ejemplo Real: Verificador de Copias de Seguridad Diarias
Considera una pequeña herramienta CLI de grado de producción que verifica las copias de seguridad diarias de S3 y envía alertas a Slack en caso de fallo.
Comienza con el objetivo aproximado: "Necesito algo confiable que verifique que mis copias de seguridad estén saludables todos los días." Luego lleva a cabo conversaciones arquitectónicas con la IA para descubrir requisitos y casos límite:
- ¿Cuáles son los modos de fallo realistas para las copias de seguridad de S3 en la práctica?
- ¿Qué exactamente deberíamos verificar (antigüedad, cantidad de archivos, tamaño, tasa de éxito) y qué umbrales tienen sentido?
- ¿Cómo deberían manejarse la configuración y los secretos entre el desarrollo local y los roles IAM de producción?
- ¿Qué comandos CLI y formatos de salida serían útiles en el día a día?
- ¿Qué requisitos no funcionales son más importantes para una herramienta diaria programada?
Estas conversaciones aclaran el alcance y ayudan a descomponer la herramienta en sus componentes principales: obtención de metadatos de S3 con lógica de reintento, un motor de reglas de verificación, un sistema de notificaciones, un cargador de configuración, una interfaz CLI, registro estructurado y manejo de errores.
Con el diseño claro, documentas la vista de alto nivel y el mapa de componentes en la wiki de jerarquía de diseño, donde cada página tiene versión y es enlazable.
La wiki brinda a los lectores futuros el contexto circundante que un documento plano no puede proporcionar. Como parte del mismo trabajo de diseño, creas un spec.md enfocado a nivel de sub-LLD para cada módulo. Aquí está el contrato para el recuperador de metadatos de S3.
Este spec.md es el contrato que le entregas al agente, por ejemplo: "Implementa exactamente según spec.md en el directorio s3_client/, sigue los estándares del proyecto e incluye pruebas exhaustivas." Con la wiki y los specs de los módulos en su lugar, luego incitas a la IA a generar la jerarquía de tickets directamente a partir de ellos. Cada elemento se remonta a un requisito funcional y al spec que define su contrato.
Luego, la implementación avanza ticket por ticket, cada uno entregado al agente con su spec.md correspondiente como contrato. Esto es lo que produce en la práctica: una ejecución programada que detecta un conjunto de copias de seguridad corto y dispara la alerta.
La ejecución termina con código de salida distinto de cero para que el cron job lo note y dispare la alerta que llega a Slack.
La alerta lleva el contexto de la regla que un ingeniero de guardia necesita para actuar: qué verificación falló, qué se encontró, qué se esperaba y qué conjunto de copias de seguridad.
Beneficios de Este Enfoque en Capas
- Los agentes manejan el volumen de implementación mientras los humanos son dueños de la arquitectura y la calidad en cada capa.
- La wiki proporciona descubribilidad y decisiones a nivel de proyecto, mientras que los archivos spec.md proporcionan contratos precisos a nivel de módulo sin inflar el diseño de alto nivel.
- Los requisitos y decisiones fluyen directamente desde las páginas wiki y los specs hacia los tickets y el código.
- Los cambios comienzan a partir de artefactos de diseño vivos en lugar de aplicar ingeniería inversa a la base de código.
- La clara separación de responsabilidades respalda el trabajo en paralelo, la incorporación y las auditorías.
- Los profesionales en forma de T navegan con amplitud y cuestionan con precisión, y el agente proporciona profundidad bajo demanda sin obligar a nadie a tener todo el sistema en su cabeza.
El "vibe coding" sigue siendo un modo excelente para la exploración y la creación rápida de prototipos personales. La ingeniería agentiva es cómo canalizas ese mismo poder conversacional hacia sistemas que otras personas puedan confiar y mantener.
El Rol del Profesional en Forma de T
Este flujo de trabajo es especialmente poderoso para los profesionales en forma de T: ingenieros que mantienen un conocimiento amplio en todo el espacio de la aplicación con la capacidad de profundizar donde sea necesario.
Porque no necesitas tener un modelo mental completo y actualizado al minuto de cómo funciona toda la aplicación en ningún momento. El agente puede llevar esa profundidad y reexplicar cualquier parte bajo demanda, siempre que tenga el contexto adecuado de la wiki, los archivos spec.md y el historial de la conversación.
Lo que sí necesitas es la capacidad de saber qué buscar y dónde buscar, más la disciplina de seguir haciendo preguntas precisas hasta que entiendas el elemento específico en el que estás trabajando. La parte ancha de la T te da el mapa del sistema; el agente de IA respalda las habilidades necesarias para profundizar en el módulo exacto, el caso límite o el punto de integración que importa en ese momento. El agente proporciona el detalle exhaustivo cada vez que preguntas.
Esto cambia el rol humano de "Debo entender todo todo el tiempo" a "Sé cómo navegar, cuestionar y validar en la altitud correcta". Esa es la verdadera habilidad de la ingeniería agentiva.
