De Ágil a Agéntico: Por Qué el Desarrollo de Software Necesita una Nueva Disciplina

La práctica de la ingeniería de software está cambiando. Cuando los agentes de IA escriben la mayor parte de la implementación, el desafío ya no es coordinar desarrolladores humanos. Es especificar qué construir, gobernar lo que los agentes producen, y rediseñar cómo operan los equipos. Han surgido múltiples marcos de ingeniería nativos de IA para abordar partes de este problema, desde workflows impulsados por especificaciones hasta compuertas de evaluación automatizadas. Pero ninguno de ellos aborda completamente el lado organizacional: cómo evolucionan los roles, cómo crecen los desarrolladores junior, qué rituales deben seguirse, cómo la gobernanza escala con la confianza. Este artículo propone el desarrollo agéntico como una disciplina que se basa en estos marcos y en la experiencia de desarrollo de software empresarial para abordar el panorama completo, incluyendo personas y procesos.

El Cambio Que Ya Ocurrió

Agile se construyó sobre tres supuestos. Primero, los humanos escriben todo el código¹, por lo que el cuello de botella es la coordinación entre personas. Segundo, los requisitos se expresan mejor como narrativas, específicamente historias de usuario que capturan la intención y dejan la implementación al desarrollador². Tercero, la calidad se asegura a través de revisión por pares, donde otro humano lee el código antes de que se despliegue³.

Los tres supuestos se mantuvieron durante veinte años. Ninguno de ellos se mantiene ahora.

Según el Reporte de Tendencias de Programación Agéntica 2026 de Anthropic, los desarrolladores ya usan IA en el 60% de su trabajo. El código generado por agentes no es un escenario futuro. Es la condición operativa actual. Y cuando los agentes escriben la mayor parte de la implementación, la mecánica de construir software cambia de maneras que Agile nunca fue diseñado para manejar.

Considera qué sucede cuando un equipo trata de ejecutar sprints con salida generada por agentes. La velocidad de sprint se vuelve insignificante porque un agente completa una tarea en minutos, no días, entonces las métricas de velocidad no miden nada útil. Los puntos de historia colapsan porque el esfuerzo ya no está en escribir código sino en especificar qué debe hacer el código y validar que lo hizo correctamente. Los standups se convierten en reuniones de estado sobre salida de agentes en lugar de sesiones de coordinación entre personas haciendo el trabajo. La revisión de código no escala. Cuando los agentes producen diez veces el volumen de código, esperar que los humanos revisen cada línea no es diligencia. Es un cuello de botella.

Esto no es un ataque a Agile. Agile resolvió el problema correcto para su tiempo: cómo coordinar desarrolladores humanos construyendo software iterativamente. El problema es que las condiciones operativas cambiaron. La unidad de trabajo ya no es una tarea humana estimada en puntos de historia. Es una especificación ejecutable por agentes validada por compuertas automatizadas. Ese cambio requiere una disciplina diferente.

Lo Que Es Realmente el Desarrollo Agéntico

El desarrollo agéntico no es un marco. No es una cadena de herramientas. No es una metodología de proveedor.

Es una disciplina enfocada en personas y procesos: los cambios sociotécnicos requeridos cuando los agentes de IA se convierten en participantes de primera clase en el desarrollo de software. Cómo evolucionan los roles. Cómo se organizan los equipos. Cómo se gana la confianza incrementalmente. Cómo la gobernanza escala sin convertirse en un cuello de botella.

Las herramientas importan, pero son implementaciones. Ya sea que un equipo use BMAD, Spec Kit, Kiro, o un enfoque hecho en casa, las preguntas de personas y procesos son las mismas: ¿Quién posee la arquitectura cuando los agentes escriben el código? ¿Qué artefactos produce y mantiene el equipo? ¿Cómo crece un desarrollador junior cuando las tareas de las que solía aprender ahora están automatizadas? ¿Cómo se mueve una organización de supervisión humana completa a supervisión selectiva sin perder control?

Esta distinción importa porque los términos adyacentes (vibe coding, ingeniería agéntica, programación agéntica) cada uno describe algo más estrecho.

El vibe coding es desarrollo sin disciplina. Un desarrollador describe lo que quiere en lenguaje natural, la IA genera código, y el desarrollador lo acepta con revisión mínima. Funciona para prototipos y scripts desechables. Explícitamente no es desarrollo agéntico. Son paradigmas incompatibles, no puntos en un espectro, porque el vibe coding abandona el rigor de gobernanza y especificación que requiere el desarrollo agéntico.

La ingeniería agéntica, como la describen Addy Osmani y otros, es una práctica individual: supervisión humana más implementación de IA. Es valiosa, pero solo aborda el workflow del desarrollador, no el equipo, la organización, o el modelo de gobernanza.

La programación agéntica está centrada en herramientas: cómo configurar y usar agentes de programación de IA efectivamente. Importante, pero no suficiente.

El desarrollo agéntico es la disciplina que se sitúa por encima de todos estos. Aborda personas y organizaciones, no solo tecnología. Es agnóstico de marco por diseño, opinionado sobre principios y flexible sobre implementaciones.

Startup vs Empresa: Mismas Herramientas, Disciplina Diferente

Un fundador solitario construyendo con Claude Code y una organización de ingeniería de 200 personas adoptando Kiro ambos usan agentes de IA para escribir código. Pero los desafíos de personas y procesos que enfrentan son fundamentalmente diferentes, y conflactuarlos es uno de los errores más comunes en este espacio.

En una startup o equipo pequeño, la disciplina es ligera. Un solo desarrollador puede mantener el contexto completo del sistema en su cabeza. Las especificaciones podrían ser un archivo CLAUDE.md y algunos prompts bien estructurados. La gobernanza es implícita porque el fundador revisa la salida del agente directamente como el único tomador de decisiones. El bucle de retroalimentación es estrecho: especificar, generar, revisar, desplegar. El cuello de botella no es coordinación o gobernanza. Es calidad del contexto, si el agente tiene suficiente información para producir salida correcta. Una startup no necesita un Squad Híbrido o un Gestor de Flujo. Necesita buenas especificaciones e iteración rápida.

En una empresa compleja, cada uno de esos supuestos se rompe. Ninguna persona sola mantiene el contexto completo. Múltiples equipos interactúan con la misma base de código, cada uno con diferente conocimiento de dominio. Las especificaciones deben ser lo suficientemente precisas para que los agentes ejecuten sin acceso al ingeniero senior que "simplemente sabe" cómo funciona el módulo de facturación. La gobernanza no puede ser implícita. Cuando 50 agentes están produciendo código a través de 12 equipos, alguien necesita decidir qué salida se despliega, cómo se mantiene la consistencia arquitectónica, y qué sucede cuando un agente produce algo que pasa todas las pruebas pero viola una regla de negocio no documentada.

Aquí es donde las preguntas de personas y procesos se vuelven inevitables:

• Los roles cambian. El Arquitecto de Contexto (alguien que curatea y estructura la información que consumen los agentes) se vuelve tan crítico como el ingeniero senior. El Operador de Agentes (alguien que monitorea, ajusta, e interviene en workflows de agentes) es un rol que no existía hace dos años.
• Las estructuras de equipo cambian. Un Squad Híbrido no es un equipo Scrum tradicional con un complemento de IA. Es una composición diferente: menos desarrolladores, más especialistas en contexto y evaluación, con agentes como miembros de equipo de primera clase cuya salida es gobernada, no solo consumida.
• La gobernanza debe ser estructural. No puedes confiar en una política que dice "revisar toda la salida del agente" cuando el volumen hace eso imposible. Necesitas compuertas automatizadas: verificaciones determinísticas que corren antes de cualquier juicio probabilístico, arneses de evaluación que validan salida contra muestras doradas, y caminos claros de escalación para cuando los agentes se atascan.
• El pipeline de talento junior se rompe. Si los agentes absorben las tareas de las que los desarrolladores junior solían aprender (correcciones de errores, características pequeñas, código repetitivo), entonces la organización debe rediseñar intencionalmente cómo los junior construyen experiencia. Esto no es un efecto secundario a manejar después. Es un problema estructural a resolver ahora.

La disciplina del desarrollo agéntico debe ser lo suficientemente flexible para servir ambos contextos. Una startup necesita los principios sin la sobrecarga. Una empresa necesita los principios operacionalizados en roles, ceremonias, y estructuras de gobernanza. Los principios son los mismos. La implementación escala con la complejidad organizacional.

El Panorama: Muchos Marcos, Una Capa Faltante

El panorama del desarrollo agéntico en 2026 no carece de marcos. BMAD ofrece 12 personas especializadas de agentes. Spec Kit proporciona un workflow de seis fases desde constitución hasta implementación. Kiro integra desarrollo impulsado por especificaciones en un IDE. La Agentic AI Foundation se lanzó bajo la Linux Foundation para estandarizar protocolos e interoperabilidad.

Cada marco serio converge en tres principios técnicos. Primero, especificaciones sobre prompts: especificaciones estructuradas, legibles por máquina producen mejor salida del agente que prompting conversacional. Segundo, el contexto es la restricción. La calidad de salida del agente es proporcional a la calidad del contexto, no a la capacidad del modelo. Un modelo mediocre con excelente contexto supera a un modelo de frontera con instrucciones vagas. Tercero, gobernanza automatizada: la revisión de código humana no escala con el throughput del agente, entonces las compuertas de evaluación automatizadas son requeridas.

Estas son contribuciones valiosas. Cada marco resuelve una pieza real del rompecabezas: creación de especificaciones, orquestación de agentes, automatización de gobernanza, estandarización de protocolos.

Pero hay una capa que ninguno de ellos aborda completamente: el lado humano.

¿Quién posee la arquitectura cuando los agentes escriben el código? ¿Cómo se reorganizan los equipos cuando la proporción de desarrolladores humanos a tareas ejecutadas por agentes cambia de 1:1 a 1:10? ¿Cómo haces crecer talento junior cuando las tareas de nivel de entrada están automatizadas? ¿Cómo escala la gobernanza con la confianza, moviéndose de supervisión completa a supervisión selectiva mientras la organización demuestra confiabilidad en cada nivel?

Los experimentos de Birgitta Böckeler con Desarrollo Impulsado por Especificaciones, publicados en el blog de Martin Fowler, revelaron que incluso con especificaciones detalladas, los agentes generaron características no solicitadas y reclamaron éxito en construcciones fallidas. Las especificaciones eran correctas. La gobernanza faltaba. Las herramientas solas no resuelven el problema. La disciplina alrededor de las herramientas es lo que las hace funcionar en organizaciones reales.

El desarrollo agéntico como disciplina se sitúa por encima de cualquier marco específico. Es la capa que aborda personas y procesos, las preguntas que atraviesan cada herramienta, cada proveedor, cada metodología.

Principios Borrador para el Desarrollo Agéntico

En febrero de 2001, diecisiete profesionales de software se reunieron en un albergue de esquí en Snowbird, Utah. Discreparon en casi todo excepto una convicción: los procesos pesados impulsados por documentos que dominaban el desarrollo de software estaban fallando. Produjeron el Manifiesto Agile: cuatro valores y doce principios que reconfiguraron la industria durante veinte años.

Las condiciones operativas que hicieron necesario Agile han cambiado de nuevo. Lo que sigue es un borrador, no un manifiesto, no un estándar, sino un punto de partida para una conversación comunitaria. Estos principios son opinionados sobre personas y procesos, deliberadamente agnósticos sobre herramientas y marcos.

Contexto sobre capacidad. La calidad de la salida del agente depende de la calidad de la entrada, no de la inteligencia del modelo. Arregla el contexto, no el modelo. Un equipo que invierta en arquitectura de contexto (información estructurada, curada, versionada que consumen los agentes) superará a un equipo persiguiendo la última liberación de modelo. En la práctica, esto significa tratar el contexto como un artefacto de ingeniería de primera clase: un Índice de Contexto que se mantiene, prueba y gobierna como código.

Especificaciones sobre prompts. Especificaciones estructuradas, no instrucciones conversacionales. Una Especificación Viva es un documento legible por máquina que define qué debe construir el agente, qué restricciones debe respetar, y cómo la salida será validada. No es una historia de usuario. No es un prompt. Es un artefacto duradero que sobrevive el ciclo de implementación y se convierte en la fuente de verdad. La Proporción Especificación-a-Código (cuánta especificación existe relativa al código generado) es una mejor métrica de salud que líneas de código o velocidad.

Gobernanza por estructura, no política. Compuertas determinísticas antes de juicio probabilístico. Una política que dice "revisar toda la salida del agente" falla en el momento que el volumen excede la capacidad humana. La gobernanza debe ser estructural: verificaciones automatizadas que corren en cada salida, arneses de evaluación que comparan resultados contra muestras doradas, y caminos claros de escalación cuando la salida falla la validación. Confía en la compuerta, no en el memo.

Autonomía graduada. Confianza ganada, no delegación binaria. Las organizaciones no deben elegir entre "humano hace todo" y "agente hace todo". Hay una progresión: observar salida del agente → dejar que los agentes sugieran → dejar que los agentes actúen con supervisión humana → dejar que los agentes actúen autónomamente. Cada nivel se gana a través de confiabilidad demostrada en el nivel anterior. Saltar un nivel, y pierdes control. Quedarte demasiado tiempo en un nivel temprano, y pierdes las ganancias de productividad.

Recuperación sobre reintento. La intervención humana cuando los agentes se atascan es una característica del sistema, no una falla. Una Recuperación de Agente (un proceso estructurado para que un humano tome control cuando un agente no puede proceder) debe ser diseñada, documentada y medida. La métrica es Tiempo Medio para Desbloquear, no si el agente tuvo éxito en el primer intento.

Personas sobre automatización. Rediseñar roles intencionalmente, especialmente el pipeline de talento junior. Cuando los agentes absorben tareas de implementación de nivel de entrada, las organizaciones deben crear nuevos caminos para que los desarrolladores junior construyan experiencia a través de curación de contexto, escritura de especificaciones, diseño de evaluación, y operación supervisada de agentes. Automatización sin rediseño intencional de roles no crea eficiencia. Crea una brecha de habilidades que aparece dos años después cuando nadie en el equipo entiende por qué el sistema funciona de la manera que funciona.

Estos principios son un borrador. Están destinados a ser desafiados, refinados y debatidos por profesionales que están construyendo con agentes diariamente. Si cualquiera de ellos está mal, la comunidad debe decirlo y proponer algo mejor.

Lo Que Estamos Construyendo, y Qué Sigue

La iniciativa de Desarrollo Agéntico es una base de conocimiento agnóstica de marcos construida por profesionales. No es un marco competidor. Es un vocabulario compartido y un conjunto de prácticas de personas y procesos que se aplican sin importar qué herramientas o metodología impulsada por especificaciones adopte un equipo.

La base de conocimiento incluye un manual que cubre los conceptos fundamentales: arquitectura de contexto, desarrollo impulsado por especificaciones, patrones de orquestación, y modelos de gobernanza. Incluye patrones, enfoques reutilizables como workflows de Recuperación de Agentes, gobernanza basada en compuertas, y arquitectura context-first. Incluye un glosario que define el vocabulario emergente (desde Workbench Efímero hasta Workflow Triangular hasta Bucle de Desarrollo Continuo) para que los equipos puedan comunicarse con precisión. E incluye guías, guías paso a paso para adoptar prácticas como configuración de Squad Híbrido e implementación de arnés de evaluación.

El contenido está disponible en agentic-dev.org. Los profesionales pueden unirse a la comunidad gratis para contribuir contenido, compartir experiencia de implementación, y acceder material solo para miembros. La disciplina es más grande que cualquier herramienta individual, y la base de conocimiento debe reflejar eso.

Qué sigue: más patrones basados en experiencia de implementación real. Más guías para las transiciones organizacionales: cómo reestructurar equipos, cómo rediseñar el camino del desarrollador junior, cómo introducir autonomía graduada sin perder gobernanza. Y, críticamente, más profesionales dispuestos a unirse a la conversación. El Manifiesto Agile fue escrito por diecisiete personas que discreparon en específicos pero acordaron en principios. Esta iniciativa necesita lo mismo: profesionales que estén dispuestos a desafiar, refinar, y mejorar lo que hemos comenzado.

Las herramientas seguirán evolucionando. Los modelos seguirán mejorando. Los marcos seguirán multiplicándose. Pero las preguntas de personas y procesos (cómo se organizan los equipos, cómo evolucionan los roles, cómo escala la gobernanza, cómo se construye la confianza) son las preguntas que determinan si algo de eso funciona.

De eso se trata el desarrollo agéntico. No las herramientas. La disciplina.

Footnotes

1. Este era un supuesto implícito, nunca declarado explícitamente porque no existía alternativa en 2001. Los valores del Manifiesto ("individuos e interacciones", equipos auto-organizados, conversación cara a cara) todos presuponen implementación humana. ↩

2. Las historias de usuario se originan de Extreme Programming (Kent Beck, 1999) y fueron popularizadas por User Stories Applied de Mike Cohn (2004). No son un artefacto del Manifiesto sino el formato de requisitos dominante adoptado por equipos Agile. La preferencia del Manifiesto por "software funcionando sobre documentación exhaustiva" creó el espacio para formatos ligeros como las historias. ↩

3. La revisión de código y programación en pares son prácticas de XP, no principios del Manifiesto. El Manifiesto pide "atención continua a la excelencia técnica". La revisión por pares se convirtió en la forma más común en que los equipos operacionalizaron esto. ↩