En febrero de 2025, Andrej Karpathy describió la "codificación por vibra" (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 creciera más allá de la 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 agéntica" como su nombre preferido para la práctica evolucionada de orquestar agentes mientras se mantiene una fuerte supervisión humana sobre 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. La codificación por vibra funciona bien para un solo usuario en trabajos personales de bajo riesgo, pero acumula rápidamente deuda técnica oculta, brechas de seguridad y problemas de mantenibilidad en cuanto otras personas dependen del resultado. La ingeniería agéntica 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 Agéntica
Comienza con una intención aproximada y lleva a cabo conversaciones de diseño con la IA mientras documentas la funcionalidad en notas de reunión 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 le brinda tanto a ti como al agente acceso fácil al contexto circundante, decisiones relacionadas y dependencias. Aquí es también donde residen los diagramas de diseño, como UML (Lenguaje Unificado de Modelado), flujos de código o de interacción del 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 archivo spec.md enfocado dentro del LLD que defina el comportamiento preciso, las firmas de las funciones, los casos extremos, las expectativas de prueba y los puntos de integración. Usando toda la estructura como un contexto de diseño, incita a la IA a construir una jerarquía de tickets con trazabilidad directa hacia las páginas wiki y las especificaciones. Implementa ticket por ticket con el agente siguiendo el spec.md relevante como su contrato. Luego ejecutas compuertas de verificación, despliegas, observas y actualizas los artefactos vivos a medida que los requisitos evolucionan.
Ejemplo Real: Verificador Diario de Copias de Seguridad
Considera una herramienta CLI pequeña y de calidad profesional que verifique las copias de seguridad diarias de S3 y envíe alertas de Slack en caso de fallo.
Comienza con el objetivo general: "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 extremos:
- ¿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, número 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 notificación, 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 la jerarquía de diseño, donde cada página tiene versión y se puede enlazar.
La wiki proporciona a los lectores futuros el contexto circundante que un documento plano no puede ofrecer. 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 extractor 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 las especificaciones de los módulos en su lugar, incitas a la IA a generar la jerarquía de tickets directamente a partir de ellas. Cada elemento se remonta a un requisito funcional y a la especificación que define su contrato.
La implementación procede entonces 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 activa la alerta.
La ejecución sale con un código distinto de cero para que el cron job lo note, y activa la alerta que llega a Slack.
La alerta contiene 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 visibilidad a nivel de proyecto y decisiones, mientras que los archivos
spec.mdproporcionan contratos precisos a nivel de módulo sin inflar el diseño de alto nivel. - Los requisitos y las decisiones fluyen directamente desde las páginas wiki y las especificaciones 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 al código base.
- La clara separación de responsabilidades respalda el trabajo en paralelo, la incorporación de nuevos miembros 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.
La codificación por vibra sigue siendo un modo excelente para la exploración y la creación rápida de prototipos personales. La ingeniería agéntica es cómo canalizas ese mismo poder conversacional hacia sistemas en los 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 cuando 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 cargar 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 amplia 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 extremo o el punto de integración que importa en ese momento. El agente proporciona el detalle exhaustivo cada vez que lo pides.
Esto cambia el rol humano de "debo entenderlo todo todo el tiempo" a "sé cómo navegar, preguntar y validar a la altitud adecuada". Esa es la verdadera habilidad de la ingeniería agéntica.
