La «A» de «agentic» se refiere a sistemas multi-agente que dividen las tareas en subtareas modulares, con el desarrollador humano supervisando y validando cada iteración

Enfoque de decisión

Los equipos que no establezcan gobernanza explícita sobre cuándo y cómo usan agentes de IA en su pipeline van a acumular deuda técnica más rápido de lo que la IA la genera. La distinción entre vibe coding y agentic engineering no es semántica: es operativa.

Resumen en 90 segundos

Esta semana, el concepto de «agentic engineering» emerge como evolución directa del «vibe coding», con ambos términos asociados a Andrej Karpathy. La diferencia central es la presencia de un humano que orquesta, valida y mantiene control sobre los agentes, en lugar de delegar la construcción completa del codebase a la IA. Encuestas recientes de Stack Overflow revelan que una proporción significativa de desarrolladores desconfía de la precisión de las herramientas de IA, y los ingenieros senior muestran los niveles más altos de escepticismo. Ese contexto convierte la gobernanza de flujos agénticos en una decisión operativa, no en una opción secundaria.

¿Qué está pasando realmente?

El «vibe coding» nació como una práctica exploratoria: prompt libre, iteración rápida, sin demasiadas restricciones de proceso. Funcionó bien para prototipos y para desarrolladores individuales que querían validar ideas rápidamente. El problema es que esa misma informalidad, trasladada a equipos de producción, genera lo que ya se denomina «AI slop»: código que no es útil, rompe funcionalidades existentes o introduce deuda técnica silenciosa que los equipos tardan semanas en detectar.

El agentic engineering detalla un modelo diferente. La «A» de «agentic» se refiere a sistemas multi-agente que dividen las tareas en subtareas modulares, con el desarrollador humano supervisando y validando cada iteración. La «E» de «engineering» subraya que el uso efectivo de estos flujos requiere expertise real: no basta con saber hacer prompts; hay que saber diseñar sistemas, orquestar agentes autónomos y construir loops de revisión que encajen con los pipelines de CI/CD existentes.

Ese reencuadre tiene consecuencias prácticas inmediatas. Los equipos necesitan playbooks internos que estandaricen patrones de uso seguro: qué tipo de tareas son delegables a agentes (refactoring, generación de boilerplate, scaffolding de APIs, tests), cuáles requieren revisión humana obligatoria y qué configuraciones de guardrails son aceptables. Muchas organizaciones están adoptando arquitecturas basadas en RAG para que los agentes operen sobre documentación real, especificaciones y repositorios de código, reduciendo alucinaciones y mejorando precisión.

La señal más importante del contexto actual no es tecnológica, sino cultural: los ingenieros senior son los más escépticos. Eso significa que cualquier rollout de flujos agénticos que no contemple la resistencia legítima de los perfiles más experimentados está destinado a fallar o a quedarse en la superficie del equipo.

¿Por qué importa para Líderes de Ingeniería de Software?

  • Desde el punto de vista operativo: Los flujos agénticos sin gobernanza activa aumentan la deuda técnica a velocidades que ningún proceso de code review tradicional puede absorber. Establecer estándares claros sobre qué puede generar un agente autónomamente y qué requiere revisión humana no es opcional; es una decisión de arquitectura de proceso.

  • Desde el punto de vista de talento: La distinción entre vibe coding y agentic engineering crea un nuevo eje de seniority. Un ingeniero senior que sabe orquestar agentes, validar su output e integrar loops de revisión en CI/CD tiene un perfil distinto al que solo sabe hacer prompts. Esto redefine qué habilidades se evalúan en el hiring y qué se desarrolla en el equipo actual.

  • Desde el punto de vista competitivo: Los equipos que adopten agentic engineering con marcos de gobernanza sólidos pueden producir más con los mismos headcounts sin sacrificar calidad. Los que adopten vibe coding sin estructura van a pagar ese costo más adelante en ciclos de debugging y refactoring.

  • Desde el punto de vista presupuestario: El costo oculto del «AI slop» no aparece en las facturas de API: aparece en las horas de ingeniería consumidas en entender, depurar y reescribir código generado bajo supervisión insuficiente. Medir ese costo antes de escalar cualquier flujo agéntico es una decisión financiera, no solo técnica.

  • Desde el punto de vista regulatorio: A medida que el código generado por agentes ingresa a sistemas críticos, la trazabilidad de quién validó qué y cuándo se convierte en un requerimiento de auditoría. Los playbooks de uso agéntico no son solo buenas prácticas; son evidencia de control.

Perspectiva a futuro

En los próximos 30 a 90 días, los equipos que ya están experimentando con flujos agénticos van a enfrentar una decisión de escalado: ¿institucionalizar lo que funciona o seguir en modo piloto indefinido? Las señales observables incluyen si los vendors de CI/CD integran guardrails nativos para agentes, si emergen estándares de SBOM que capturen código de origen agéntico, y si los frameworks de revisión de código empiezan a distinguir entre código humano y código generado por agente.

Lo que aún es incierto

  • Métricas de productividad real: No existe todavía un conjunto de datos independiente y a escala que muestre el impacto neto del agentic engineering sobre velocity y calidad. Lo que resolvería esto: estudios longitudinales de equipos que adopten estos flujos en producción durante al menos dos trimestres.

  • Estandarización de gobernanza: No hay consenso sobre qué debe contener un playbook de uso agéntico seguro ni qué nivel de supervisión humana es suficiente para distintos tipos de tareas. Lo que resolvería esto: guías de organismos como NIST o iniciativas de la industria como OpenSSF que aborden agentes de código explícitamente.

  • Impacto en estructuras de equipo: No está claro cómo el agentic engineering cambia el ratio óptimo entre ingenieros senior y junior, ni qué roles se vuelven redundantes o cuáles ganan importancia crítica. Lo que resolvería esto: datos de organizaciones que hayan completado un ciclo completo de adopción.

  • Trazabilidad legal del código agéntico: La responsabilidad sobre bugs críticos en código generado por agentes bajo supervisión humana parcial aún no tiene respuesta jurídica clara. Lo que resolvería esto: precedentes contractuales o regulación específica en mercados clave.

Una pregunta para tu equipo

¿Tenemos definido hoy qué tareas pueden ejecutar nuestros agentes de forma autónoma y cuáles requieren revisión humana obligatoria antes de llegar al pipeline de CI/CD?

Fuentes

  • Ibm — What is Agentic Engineering? (Link)

Tags