El término lleva meses apareciendo en conversaciones técnicas, en ofertas de empleo y en presentaciones de producto. Y como suele pasar con los conceptos que se popularizan rápido, hay mucho ruido alrededor de qué es exactamente el Agentic Engineering y en qué se diferencia de lo que los equipos de desarrollo ya hacían con IA.
Este artículo lo aclara desde una perspectiva de implementación real: qué es, de dónde viene, qué cambia en el equipo cuando lo adoptas y qué necesita estar en su lugar antes de que tenga sentido hacerlo.
Del asistente de código al agente: cómo llegamos hasta aquí
Durante años, la IA en desarrollo de software funcionó como un asistente de autocompletado avanzado. El modelo sugería una línea o un bloque, el desarrollador lo revisaba, lo aceptaba o lo corregía, y el trabajo seguía siendo esencialmente humano. La IA aceleraba, pero no decidía.
Ese equilibrio cambió cuando los modelos de lenguaje cruzaron un umbral de calidad a partir del cual sus salidas eran mayoritariamente correctas sin corrección manual. A partir de ese punto, el patrón de trabajo empezó a cambiar de forma natural: el desarrollador dejó de revisar cada línea porque la mayoría ya eran buenas. Empezó a delegar más, a dirigir más que a escribir. El salto real no fue la mejora en la generación de código en sí: fue el paso de la asistencia en un solo intercambio a flujos de trabajo de múltiples pasos donde el agente puede ejecutar, validar y corregir sin intervención en cada paso. Eso es lo que abrió la puerta al Agentic Engineering.
Qué es Agentic Engineering
Agentic Engineering es la disciplina de ingeniería profesional donde agentes de IA planifican, escriben, prueban y despliegan código bajo supervisión humana estructurada. El término lo acuñó Andrej Karpathy (cofundador de OpenAI, exdirector de IA en Tesla) a principios de 2026 como evolución del Vibe Coding: no el uso casual de la IA para generar código rápido, sino una metodología construida alrededor de agentes autónomos con el humano en el rol de arquitecto y validador.
La definición más precisa que el propio Karpathy ha dado es esta: un sistema de orquestación de agentes escribe el código, y el desarrollador humano supervisa y valida el resultado. A medida que el agente avanza en las subtareas, el humano permanece en el bucle. No desaparece: cambia de función. Deja de ser quien teclea cada implementación y pasa a ser quien define qué tiene que hacer el sistema, qué criterios tiene que cumplir y cuándo el resultado es correcto.
Lo que hace al Agentic Engineering distinto de cualquier forma de asistencia con IA anterior es el nivel de autonomía. El agente recibe un objetivo, lo descompone en tareas, ejecuta cada una, valida los resultados y ajusta el plan si algo falla, sin que el humano tenga que intervenir en cada paso. El trabajo de valor del desarrollador se desplaza de la implementación al diseño, la especificación y el criterio técnico.
Agentic Engineering vs. Vibe Coding: la distinción que importa
Antes de Agentic Engineering, Karpathy acuñó Vibe Coding. Y la diferencia entre ambos términos no es de grado: es de propósito y de consecuencias en producción.
El Vibe Coding describe el flujo donde el desarrollador escribe un prompt, acepta lo que genera el modelo y comprueba si funciona. Si no funciona, vuelve a promptear. El resultado puede ser sorprendentemente bueno para un prototipo, un script personal o un hackathon. El problema aparece cuando ese código intenta mantenerse, escalarse o pasar una revisión de seguridad. Karpathy lo resume de forma directa: el Vibe Coding eleva el suelo para los principiantes; el Agentic Engineering preserva el techo de calidad para los profesionales.
En el Agentic Engineering, el agente ejecuta la implementación pero lo hace dentro de restricciones que el humano ha definido antes: un documento de diseño, una especificación técnica, una arquitectura acordada, unos criterios de aceptación. El desarrollador escribe menos código línea a línea, pero es completamente responsable de lo que llega a producción. Esa responsabilidad no se delega al agente. La velocidad aumenta; la accountability no cambia.
En entornos empresariales donde los sistemas son críticos, esa distinción tiene un impacto directo en la deuda técnica acumulada, en la capacidad del equipo para mantener lo que construye y en la seguridad de lo que se despliega.
Qué cambia en el equipo cuando adoptas Agentic Engineering
Adoptar Agentic Engineering no es instalar una herramienta. Es un cambio en cómo trabaja el equipo, en qué perfiles se necesitan y en qué tiene que estar en su lugar antes de que los agentes empiecen a generar código de producción.
Los roles cambian, no desaparecen
El desarrollador que trabaja con Agentic Engineering no escribe menos código porque sea menos capaz. Lo escribe menos porque dedica su tiempo a lo que más impacta: definir especificaciones precisas, diseñar la arquitectura que el agente va a implementar, escribir los tests que validan que el resultado es correcto y revisar el output con criterio técnico real. Los equipos de ingeniería necesitan formarse no solo en cómo promptear mejor, sino en diseño de sistemas: cómo orquestar agentes, validar su output e integrar bucles de revisión en las pipelines de CI/CD existentes.
El testing pasa a ser la pieza central
La diferencia más práctica entre Agentic Engineering y Vibe Coding es el testing. Sin una suite de tests sólida, un agente declarará terminado un código roto con toda la confianza del mundo. Con tests, el agente puede iterar hasta que todo pase, y el equipo tiene garantías reales sobre el resultado. En términos concretos: si el equipo no tiene una cobertura de tests suficiente antes de incorporar agentes, los agentes van a generar código que parece correcto pero que esconde errores que solo aparecerán en producción.
La especificación se convierte en el artefacto más valioso
En un flujo de Agentic Engineering, la calidad del output del agente depende directamente de la calidad de la especificación que recibe. Un agente con un brief vago toma decisiones de diseño por su cuenta. Esas decisiones pueden ser razonables, pero no necesariamente alineadas con lo que el negocio necesita. El documento de diseño, la especificación detallada y los criterios de aceptación dejan de ser burocracia y pasan a ser el principal mecanismo de control de calidad del sistema.
El riesgo que nadie menciona
El argumento más repetido a favor del Agentic Engineering es la velocidad. Organizaciones que trabajan intensivamente con IA están consiguiendo reducciones de costes operativos significativas y ciclos de desarrollo mucho más cortos. Esos números son reales. Pero hay una condición que suele quedar fuera del titular: la velocidad que generan los agentes amplifica tanto las buenas decisiones de arquitectura como las malas.
Un equipo con arquitectura bien definida, tests sólidos y procesos de revisión estructurados puede comprimir semanas de trabajo en días. Un equipo sin esas bases va a generar el mismo volumen de código en mucho menos tiempo, pero ese código va a acumular deuda técnica a una velocidad que tampoco tiene precedente. Más autonomía sin más arquitectura no es progreso.
La pregunta que cualquier CTO debería hacerse antes de adoptar Agentic Engineering no es qué herramienta usar, sino si están en su lugar los procesos que permiten validar lo que generan los agentes antes de que llegue a producción.
Agentic Engineering y datos: la capa que lo sostiene
Los agentes de software necesitan contexto: acceso a bases de datos, a APIs, a sistemas internos, a documentación técnica. La calidad de ese contexto determina la calidad de lo que el agente produce. Un agente que trabaja con datos mal estructurados, sin gobernanza o dispersos en silos toma decisiones de implementación basadas en información incompleta, con todos los problemas que eso genera en producción.
Por eso Agentic Engineering y arquitectura de datos no son disciplinas separadas en entornos empresariales. Los equipos que consiguen resultados más consistentes con agentes son los que tienen una capa de datos bien ordenada: fuentes de verdad únicas, gobernanza de acceso, linaje documentado. Conectar bien a los agentes con IA agéntica a nivel de infraestructura no es un detalle técnico secundario: es la condición que determina si el sistema funciona de forma fiable más allá del primer prototipo. El context engineering (cómo se estructura y curada la información que reciben los agentes) es tan determinante como la calidad del modelo que los ejecuta.
Cómo trabajamos en BertIA con sistemas agénticos
En BertIA llevamos tiempo trabajando con arquitecturas de IA agéntica en clientes de sectores industriales, logísticos y farmacéuticos. Lo que hemos aprendido en ese proceso es que el punto de fracaso más habitual no está en la tecnología (los modelos están suficientemente maduros para esto) sino en la ausencia de las capas que tienen que existir antes de que los agentes operen con autonomía real.
El patrón que se repite cuando algo no funciona como se esperaba tiene siempre la misma estructura: los agentes reciben instrucciones ambiguas, no tienen acceso fiable al contexto que necesitan, o no hay un proceso de validación que permita detectar cuándo el output no cumple los criterios de negocio. La solución no es volver a supervisión manual en cada paso. Es diseñar bien la capa de orquestación, el acceso a datos y los criterios de aceptación desde el inicio, antes de que el agente empiece a trabajar.
En los proyectos donde hemos visto mayor impacto real, la arquitectura agéntica descansa sobre tres elementos que, en BertIA, trabajamos desde el principio: una capa de datos bien gobernada que sirve como base de contexto fiable, un sistema de MLOps que gestiona el ciclo de vida de los modelos que utilizan los agentes, y un proceso de revisión estructurado que mantiene al equipo humano en el bucle en los puntos de decisión que importan.
Conclusión
Agentic Engineering no es el futuro del desarrollo de software. Es el presente de los equipos que ya construyen con IA de forma profesional y estructurada. La diferencia entre los equipos que lo aprovechan bien y los que acumulan deuda técnica a mayor velocidad que nunca está exactamente ahí: en si las bases (arquitectura, testing, especificación, datos) estaban en su lugar antes de delegar la implementación a los agentes.
Si estás evaluando cómo incorporar Agentic Engineering en tu equipo de desarrollo o cómo construir la arquitectura que necesitan los agentes para funcionar con garantías en producción, habla con nuestro equipo para analizar tu caso concreto.
