La ingeniería agéntica de IA es el enfoque disciplinado donde agentes de IA ejecutan tareas de programación bajo supervisión humana activa: el desarrollador define specs, revisa el código generado y mantiene la responsabilidad sobre lo que va a producción. No es automatización ciega ni delegar el teclado a un bot.
En 30 segundos
- Andrej Karpathy acuñó “vibe coding” en 2025 para describir programar sin revisar el código; agentic engineering es lo opuesto: agentes de IA con supervisión humana rigurosa.
- Addy Osmani documentó la distinción en 2026: conflating them is causing real confusion and real damage.
- Los cuatro pilares: planificar primero, revisar sin concesiones, testear en serio y mantener accountability humana.
- Gartner proyecta que el 33% de las aplicaciones enterprise van a tener agentic AI para 2028.
- El riesgo real: 40% de proyectos agénticos se cancelan antes de 2027 por costos e incertidumbre sobre el valor entregado.
Qué es Agentic Engineering
Ponele que tenés que refactorizar un módulo de pagos: 8 archivos, 2.000 líneas, tests que no cubren todos los casos. Podrías pedirle a un agente de IA que lo haga y aceptar todo lo que genere sin leer. Eso es vibe coding. O podés escribir una spec de qué debería hacer cada función, pasársela al agente, revisar cada diff como si viniera de un colega junior, correr los tests y recién ahí mergear. Eso es ingeniería agéntica.
La diferencia no es el nivel de automatización. Es quién tiene el control.
Según la documentación de Addy Osmani, ingeniería agéntica de IA es el flujo donde agentes de IA manejan la implementación mientras los humanos mantienen supervisión sobre arquitectura, calidad y decisiones críticas. El humano pasa de ser “prompt DJ” a ser arquitecto y revisor.
Vibe Coding vs Agentic Engineering: diferencias fundamentales
El problema con “vibe coding” es que se convirtió en un término paraguas. Hoy la gente lo usa para describir tanto un hack de fin de semana como un workflow de ingeniería disciplinado con agentes. Osmani lo dice directo: eso “is causing real confusion and real damage”.
Vibe coding tiene casos de uso legítimos: un MVP que necesitás para el domingo, un script personal que si se rompe lo regenerás, exploración creativa donde generás para ver qué propone la IA y después tirás todo y lo hacés bien. En esos contextos, no revisar el código tiene sentido porque la calidad no importa todavía.
El problema es cuando ese mismo approach llega a producción.
| Dimensión | Vibe Coding | Agentic Engineering |
|---|---|---|
| Revisión de código | No se hace | Peer-review estándar de producción |
| Specs previas | Ninguna o mínima | Documentación clara antes de generar |
| Manejo de errores | Pegar el error de vuelta en el prompt | Testing exhaustivo + debugging estructurado |
| Accountability | El agente “se mandó” | El desarrollador firma y es responsable |
| Casos de uso | Prototipos, hackathons, scripts personales | Código de producción, refactors, integraciones |
| Rol del humano | Operador de prompts | Arquitecto, revisor, tomador de decisiones |
Los cuatro pilares de Agentic Engineering
No es una metodología compleja. Son cuatro principios que cualquier equipo puede implementar, y que marcan la diferencia entre usar IA para amplificar capacidad o para acumular deuda técnica.
Plan First: diseño antes de prompts
Antes de abrir el chat con el agente, tenés que saber qué querés construir. Eso significa documentación de diseño, specs de inputs y outputs, criterios de aceptación. Si no podés escribir la spec, no estás listo para delegar la implementación. El agente va a generar algo, pero sin north star, vas a iterar en la dirección equivocada. Te puede servir nuestra cobertura de optimizar costos de API en proyectos IA.
Review Rigorously: el mismo estándar que producción
Cada diff que genera el agente pasa por el mismo proceso que el código de cualquier colega. ¿La función hace lo que dice que hace? ¿Maneja los edge cases? ¿Hay side effects no documentados? No porque el agente sea poco confiable, sino porque la revisión es lo que convierte código generado en código mantenible.
Test Comprehensively: sin tests, no hay ingeniería
Este pilar es el que más se saltea y el más crítico. TypeScript, linters, unit tests, integration tests. El testing es lo que diferencia agentic engineering de vibe coding con buenas intenciones. ¿Y qué pasa cuando te saltás el testing? Exacto: el bug aparece en producción un martes a las 2 AM.
Own Accountability: el desarrollador firma
Documentación, versionado, CI/CD, monitoreo. Si algo sale mal, la responsabilidad es del desarrollador, no del agente. Ese framing cambia cómo vas a revisar el código que generó.
Mejores prácticas para implementar
Hay algunas que marcan la diferencia entre equipos que aprovechan los agentes y equipos que los padecen.
Spec-driven development. Definís los requisitos antes de generar código. No “haceme un backend de e-commerce”, sino “implementá el endpoint POST /orders con validación de stock, manejo de errores 400/409/500 y estos contratos de input/output”. La especificidad del prompt determina la calidad del output.
Tareas acotadas. No le pedís al agente que construya el sistema completo. Lo dividís: primero el modelo de datos, después la lógica de negocio, después la API. Cada pieza es revisable, testeable, integrable de forma incremental. Relacionado: nuevos modelos de facturación por tokens.
Governance de datos. Qué información podés pasarle al agente y qué no. Datos de clientes, credenciales, lógica de negocio confidencial: definís las reglas antes de empezar a usarlo en el equipo. Especialmente relevante si usás servicios externos de IA (y no infraestructura propia).
Para equipos que usan servidores propios o VPS para correr sus pipelines de IA, donweb.com tiene opciones de hosting con soporte local que pueden simplificar el tema de residencia de datos.
El juicio humano no es opcional. Los agentes son muy buenos implementando soluciones bien definidas. Son muy malos eligiendo qué problema vale la pena resolver, qué arquitectura va a escalar y qué decisión tiene implicancias legales. Eso sigue siendo trabajo de personas.
Cuándo usar Agentic Engineering (y cuándo no)
Hay contextos donde agentic engineering brilla: refactors grandes con specs claras, implementación de tests exhaustivos, generación de código repetitivo (serializers, validadores, CRUDs). Tareas donde la “solución correcta” está bien definida y la revisión es viable.
Hay contextos donde hay que ir con cuidado. Decisiones arquitectónicas que van a vivir 5 años en el codebase. Código que maneja datos sensibles sin governance claro. Sistemas donde un bug tiene consecuencias irreversibles.
Los números del mercado son interesantes pero hay que tomarlos con pinzas (la “innovación” de turno tiene sus propios analistas entusiastas): según proyecciones de ArkonData para 2026, el 33% de las aplicaciones enterprise van a incorporar agentic AI para 2028. El mismo reporte señala que el 40% de los proyectos agénticos se cancelan antes de 2027 por costos mayores a los esperados y valor incierto. Ese 40% no es un dato menor.
¿Alguien verificó esos números de forma independiente? Todavía no de manera sistemática. Pero la dirección general de adopción está clara.
Errores comunes en Agentic Engineering
Confundir los dos enfoques. El error más frecuente. Pensás que estás haciendo ingeniería agéntica porque usás herramientas de agentes, pero no revisás los diffs, no escribís specs y aceptás todo lo que genera. Eso es vibe coding con más pasos. Para más detalles técnicos, mirá cambios recientes en planes de herramientas IA.
Creer que reemplaza desarrolladores. Los agentes amplifican a buenos ingenieros. Un developer con criterio y 10 años de experiencia revisando el output de un agente produce más y mejor que antes. Un junior que delega sin entender lo que genera pierde la oportunidad de construir los fundamentos que van a necesitar en 3 años. La herramienta acentúa lo que ya está.
Subís el código generado, lo probás en local, funciona bárbaro, lo mandás a revisión y de repente el reviewer encontró tres edge cases no manejados, una query sin índice y un secret hardcodeado, porque nadie había escrito la spec y el agente asumió el happy path.
Saltear el testing. El testing es lo que hace que el código agéntico sea confiable. Sin él, tenés código que parece funcionar hasta que no funciona. Y cuando falla en producción, vas a tardar el doble en debuggear porque no tenés tests que te cuenten qué parte rompió.
No escribir specs claras. “Haceme una función que procese pagos” genera código que procesa pagos de alguna forma. Puede no ser la forma que necesitás. Las specs no son burocracia, son la interfaz entre tu intención y la ejecución del agente.
Agent washing de vendors. Muchos productos que hoy se venden como “agentic” son pipelines simples con un LLM en el medio. Antes de comprometer infraestructura o presupuesto, preguntá qué decisiones toma el agente de forma autónoma y qué tan reversibles son.
El rol del desarrollador en la era de agentes autónomos
La descripción del trabajo cambió. De escribir código línea a línea a diseñar sistemas, definir contratos, revisar outputs y tomar decisiones que los agentes no pueden tomar solos. En limitaciones de capacidad actuales profundizamos sobre esto.
El workflow híbrido que se está imponiendo en equipos maduros tiene dos fases: una fase de prototipado donde el agente genera libremente y el developer explora posibilidades (vibe phase, deliberadamente), seguida de una fase de ingeniería donde todo pasa por specs, revisión y testing (production phase). No son enfoques competidores, son etapas de un mismo proceso.
Lo que no cambia: el contexto del negocio, las prioridades del equipo, las consecuencias de una decisión técnica incorrecta. Eso sigue siendo trabajo humano. Los agentes son muy buenos ejecutando. Son malos eligiendo qué ejecutar.
Preguntas Frecuentes
¿Qué es la ingeniería agéntica de IA?
La ingeniería agéntica de IA es un enfoque de desarrollo de software donde agentes de IA ejecutan tareas de implementación bajo supervisión humana activa. El desarrollador define specs, revisa el código generado con los mismos estándares que aplicaría a cualquier código de producción y mantiene accountability sobre el resultado. No es automatización ciega: el humano sigue siendo arquitecto y tomador de decisiones.
¿Cuál es la diferencia entre vibe coding e ingeniería agéntica?
La diferencia central está en la revisión. En vibe coding, el developer acepta el output del agente sin revisarlo, itera pegando mensajes de error y no escribe specs previas. En ingeniería agéntica, cada diff se revisa como el código de cualquier colega, hay documentación de diseño antes de generar y existe testing formal. Según Addy Osmani, confundir los dos está “causing real confusion and real damage” en equipos de desarrollo.
¿Cómo implementar agentic engineering en un equipo de desarrollo?
Los pasos concretos: escribir specs claras antes de generar código, dividir tareas grandes en partes acotadas y revisables, aplicar el mismo proceso de code review que con código humano y definir governance sobre qué datos pueden pasarse al agente. La adopción no requiere herramientas especiales: cualquier agente de codificación funciona si el proceso humano alrededor es disciplinado.
¿Es seguro dejar que agentes de IA escriban código en producción?
Seguro con las salvaguardas correctas: specs claras, revisión de cada diff, testing exhaustivo y governance de datos. Sin esas condiciones, el riesgo es alto, especialmente en sistemas con lógica de negocio compleja o datos sensibles. El 40% de proyectos agénticos enterprise se cancelan antes de 2027 por valor incierto, señal de que muchos equipos están implementando sin el proceso adecuado.
¿Qué mejores prácticas hay para agentic engineering en 2026?
Las más importantes: spec-driven development (definir inputs, outputs y criterios de aceptación antes de prompting), tareas acotadas en vez de delegaciones masivas, TypeScript y linters para atrapar errores antes de la revisión humana, y un proceso de governance claro sobre qué datos puede manejar el agente. El testing sigue siendo el pilar que más equipos saltean y el que más impacto tiene en la calidad del output final.
Conclusión
La discusión sobre vibe coding vs ingeniería agéntica no es semántica. Define cómo los equipos van a usar estas herramientas y qué van a producir con ellas. Los equipos que traten a los agentes como ejecutores de sus propias specs van a amplificar su capacidad. Los que los usen como sustitutos del pensamiento de ingeniería van a acumular deuda técnica a velocidad de máquina.
La ingeniería agéntica de IA no es el futuro. Es el estándar que los equipos serios ya están adoptando ahora. Y la buena noticia es que no requiere herramientas nuevas: requiere disciplina vieja aplicada a herramientas nuevas.