En los meses transcurridos desde entonces, hemos aplicado técnicas de desarrollo basado en agentes a un número cada vez mayor de proyectos, tanto de clientes como internos. El Proyecto X, una iniciativa reciente en la que esta evolución sigue desarrollándose, ofrece una perspectiva útil sobre lo que hemos aprendido en términos más generales. La lección más importante no fue simplemente que los agentes pudieran escribir código más rápido. Fue que nuestras plataformas de desarrollo y prácticas de entrega existentes no estaban diseñadas para gestionarlos a lo largo de todo el ciclo de vida del desarrollo.
En el Proyecto X, las implementaciones generadas por los agentes superaban los controles de calidad tradicionales, aunque se desviaban de la arquitectura, la intención de la historia o los requisitos empresariales subyacentes. El código estaba bien estructurado, pero no siempre era el código adecuado. A medida que los agentes van más allá del autocompletado y comienzan a planificar el trabajo, modificar el código y abrir solicitudes de incorporación de cambios, los controles diseñados para equipos de desarrollo humanos no resultan automáticamente suficientes.
Esa brecha —entre superar todas las comprobaciones y crear realmente lo correcto— resultó ser la verdadera historia de los últimos nueve meses. Cerrarla nos llevó a plantearnos una cuestión sobre la plataforma mucho más amplia de lo que esperábamos, y es la que abordaremos en nuestro seminario web de agosto.
También predijimos que la generación de código sería cada vez más simplificable, mientras que comprender el problema y elaborar la solución adecuada no lo sería. Los desarrolladores dedicarían menos tiempo a producir un borrador inicial y más tiempo a revisar el trabajo generado por la IA. Sostuvimos que los desarrolladores junior seguirían necesitando la experiencia práctica de escribir y revisar código por sí mismos —esa memoria muscular que permite reconocer una mala implementación a simple vista— y que la programación en pareja tendría que convertirse en revisión en pareja. Los flujos de trabajo basados en texto y centrados en las especificaciones también requerirían ciclos de retroalimentación más estrechos para preservar el entendimiento compartido que tradicionalmente se construye a través de la conversación.
Esas eran las predicciones de octubre. En todos los proyectos para clientes y en el trabajo interno que hemos realizado desde entonces, se han ido convirtiendo cada vez más en realidades operativas.
Cómo se desarrolló esto en el Proyecto X
El Proyecto X no comenzó como un experimento para ver cuánto trabajo podíamos delegar a los agentes. Comenzó como cualquier iniciativa de producto bien gestionada, con requisitos detallados, un plan de MVP vinculado a ellos y una cadencia semanal de elementos priorizados de la lista de tareas pendientes.
Lo que cambió fue la forma en que el equipo trasladaba cada elemento desde el requisito hasta la implementación. Un desarrollador trabajaba con IA para redactar la historia y el plan de implementación, basando ambos en los requisitos del proyecto, la arquitectura y las expectativas de diseño. A continuación, utilizamos comprobaciones independientes basadas en agentes para auditar la historia y el plan en busca de lagunas antes de escribir ningún código. Una vez que el trabajo estaba suficientemente definido, un agente de ejecución que utilizaba Devin o GitHub Copilot podía implementarlo.
Este era el «trabajo comprimible» del que hablamos en octubre: traducir un plan bien definido en código. Pero, tal y como vimos en el Proyecto X y en otros trabajos de desarrollo con agentes, la velocidad de producción de código puso de manifiesto un problema diferente. Cuanto más rápido implementaban los agentes, más importante resultaba determinar si habían implementado lo correcto.
La desviación que los controles de calidad tradicionales no podían detectar
Nuestros controles de calidad existentes hacían exactamente lo que se esperaba de ellos. Las comprobaciones de estilo, el linting, la verificación de tipos y las pruebas automatizadas podían indicarnos si el código estaba bien formado y si los comportamientos conocidos seguían funcionando. Sin embargo, no podían determinar si una implementación reflejaba la intención de la historia, satisfacía el requisito subyacente o se mantenía coherente con la arquitectura.
Como resultado, algunas implementaciones generadas por agentes superaban todas las comprobaciones automatizadas tradicionales y, aun así, requerían correcciones significativas. El problema no era necesariamente la calidad del código, sino la alineación.
En un caso, un agente creó pruebas de front-end simulando un módulo de datos compartido al completo, en lugar de utilizar la infraestructura de simulación de solicitudes establecida por el proyecto. Las pruebas se superaron, pero ese enfoque podía permitir que simulaciones incompletas llegaran a las API reales y hacía que el conjunto de pruebas fuera frágil a medida que evolucionaba la capa de datos. Un linter o un verificador de tipos no habría señalado la implementación porque el código era válido y las pruebas daban resultado positivo. Una revisión que tuviera en cuenta la arquitectura podría reconocer que se había eludido el patrón de pruebas previsto por el proyecto.
Esto puso de manifiesto una nueva responsabilidad de la plataforma. Necesitábamos controles capaces de evaluar la solicitud de incorporación de cambios (pull request) en relación con el problema vinculado, los criterios de aceptación, los requisitos del proyecto y la arquitectura. En otras palabras, necesitábamos comprobar si el agente había creado lo correcto, no solo si lo había creado correctamente.
Cerrar esa brecha se convirtió en el objetivo principal de los siguientes meses de inversión en herramientas.
Cómo evolucionó la plataforma en torno a los agentes
La historia de las herramientas del Proyecto X muestra una clara progresión. Cada etapa añadió capacidades a los agentes y puso de manifiesto una nueva brecha de confianza.
Abril de 2026: Establecimiento de un contexto compartido.
Introducimos reglas compartidas, habilidades reutilizables, comandos básicos y la infraestructura de integración continua (CI) y sincronización de incidencias, de modo que los agentes partieran del mismo conocimiento del proyecto del que dispone un desarrollador humano.
Mayo de 2026: Mejora de la calidad de las especificaciones.
Los agentes ayudaron a redactar historias de usuario, elementos de deuda técnica, planes de implementación y actualizaciones de la documentación. Añadimos comprobaciones independientes que auditaban esos artefactos antes de su implementación.
Junio de 2026: Estandarización del comportamiento e incorporación de revisiones independientes.
Unificamos las mismas habilidades en todos los entornos de desarrollo e introdujimos controles de calidad basados en IA en la integración continua (CI). Estos incluían revisiones de la arquitectura, comprobaciones de los criterios de aceptación frente a la incidencia vinculada y comprobaciones de preparación antes de la implementación.
Julio de 2026: Mantener la fiabilidad del estado del proyecto.
Introdujimos capacidades de preparación y sincronización que conciliaban requisitos, planes, documentación y código. Los desarrolladores también podían verificar los criterios de aceptación antes de abrir una solicitud de incorporación de cambios.
La progresión consistió en un contexto compartido, la calidad de las especificaciones, la revisión independiente y la sincronización a nivel de proyecto. Cada etapa amplió las capacidades del agente y subsanó una brecha de confianza puesta de manifiesto por la anterior.
De «human in the loop» a «human on the loop»
Con estas herramientas en marcha, los agentes podían llevar a cabo el trabajo definido a lo largo de la implementación, la creación de solicitudes de incorporación de cambios y las respuestas a las revisiones. Las comprobaciones de preparación, de deficiencias y de arquitectura nos proporcionaron una forma práctica de abordar los problemas de alineación.
Esto apuntaba hacia un modelo operativo diferente. En lugar de iniciar y aprobar cada paso, una persona podía supervisar el trabajo rutinario y gestionar las escalaciones. El modelo «human on the loop» no elimina la responsabilidad humana. Las personas siguen definiendo los objetivos, las prioridades, los límites arquitectónicos y de seguridad, así como los derechos de decisión. El agente opera dentro de esos límites y escala las excepciones, las ambigüedades y las compensaciones sustanciales.
La oportunidad que quedaba por aprovechar no consistía en dejar que un agente determinara la estrategia de producto, sino en reducir la coordinación manual que aún se requería para llevar un elemento del backlog elegible desde la planificación hasta la implementación.
Próximos pasos: ciclos de planificación delimitados
Esa es la frontera en la que estamos trabajando ahora y el tema que queremos explorar en agosto. La próxima evolución no consiste simplemente en dejar que un agente escriba más código. Se trata de permitir que el agente participe antes en el ciclo de vida, sin salirse de los objetivos y derechos de decisión definidos por los humanos.
El ciclo de planificación en el que estamos trabajando comienza con una lista de tareas pendientes priorizada y unos requisitos establecidos por el equipo. Dentro de esos límites, un agente identifica la siguiente historia candidata elegible, redacta el borrador de la historia y el plan de implementación, y evalúa ambos en función de la preparación del proyecto y de las comprobaciones de deficiencias. Si se encuentra con requisitos poco claros, prioridades contradictorias, excepciones arquitectónicas o decisiones que exceden su autoridad, lo remite a una persona.
Una vez que una historia y un plan superan esas comprobaciones, pueden entregarse a un agente del ciclo de desarrollo que:
Desarrolla el código.
Valida el resultado en función de los objetivos establecidos en el requisito y la historia. Comprueba no solo si las pruebas se superan, sino también si estas evalúan el comportamiento correcto.
Confirma que la implementación se ajusta a nuestra arquitectura y a nuestras normas de codificación.
Abre la solicitud de incorporación de cambios.
En cada etapa, el agente actúa únicamente dentro de su ámbito de competencia definido y remite el asunto a un nivel superior cuando se requiere el criterio humano. Una vez que una persona resuelve el problema, el proceso puede reanudarse. Esto es lo que se conoce como «human on the loop» aplicado a todo el ciclo de vida de la entrega, no solo a la generación de código.
Por qué es importante para August
La lección va más allá del Proyecto X. En todo nuestro trabajo de desarrollo con agentes, los controles que rodean al agente han demostrado ser tan importantes como la propia capacidad del agente para generar código. A medida que los agentes comienzan a planificar el trabajo, modificar el código, abrir solicitudes de incorporación de cambios y ejecutar validaciones, la plataforma de desarrollo debe hacer algo más que ayudar a los equipos humanos a lanzar software. También debe gestionar las identidades de los agentes, los permisos, los entornos de ejecución, el acceso al código y a los datos, y el recorrido desde un cambio propuesto hasta su puesta en producción.
La mayoría de las plataformas de desarrollo empresariales no se diseñaron teniendo en cuenta a ese actor. Muchas prácticas de gestión de secretos se crearon en torno a un desarrollador humano o a una identidad predecible del proceso de trabajo, no a un agente autónomo capaz de elegir e invocar herramientas. Los controles de desarrollo seguro suelen dar por sentado que una persona inspeccionará un cambio antes de su lanzamiento. Las configuraciones predeterminadas de las organizaciones de GitHub dan por hecho que un desarrollador envía una confirmación y espera a que el proceso de revisión establecido se encargue del resto. Los agentes funcionan de manera diferente, y esas suposiciones pueden convertirse en brechas de control.
Cerrar esas brechas requiere controles explícitos para la protección de ramas, los permisos de los repositorios, la autenticación de agentes, la auditabilidad, el alcance de los secretos y el análisis de secretos. Las aplicaciones de GitHub, los tokens de acceso personal de alto nivel de detalle, los entornos de GitHub Actions, Azure Key Vault y HashiCorp Vault tienen todos un papel que desempeñar, dependiendo del entorno y de los requisitos normativos.
Esto convierte el desarrollo de agentes en una cuestión que atañe a la plataforma y al modelo operativo, y no simplemente en una decisión sobre herramientas de desarrollo. Los responsables de la plataforma, DevOps, la arquitectura, la seguridad y la ingeniería deben determinar cómo operarán los agentes antes de que se les permita participar ampliamente en la entrega.
La evolución del Proyecto X también ilustra la Modelo de Madurez de la IA Mejorado, el marco de ocho etapas que presentamos el 8 de junio de 2026 —casualmente, la misma semana en que la propia trayectoria de herramientas del Proyecto X muestra que los controles de calidad de la IA aparecen en la integración continua (CI). El proyecto comenzó en torno a la etapa 3, con un agente completando una tarea definida y un humano revisando el resultado. Los controles añadidos posteriormente hicieron avanzar el modelo de entrega hacia las etapas 5 y 6, en las que los equipos delegan objetivos y permiten que los agentes coordinen el trabajo dentro de unos límites definidos.
Lo importante no es el número de la etapa en sí. Cada aumento de la autonomía de los agentes requiere un aumento correspondiente de la madurez de la plataforma, la gobernanza y la supervisión. Las organizaciones no pueden pasar de forma segura de la asistencia a la delegación limitándose a ampliar la capacidad de los agentes.
En octubre nos preguntamos si la IA podría crear una función con nosotros, en directo y ante el público. En agosto, continuaremos con la pregunta más difícil: ¿está la plataforma que sustenta a los agentes de desarrollo preparada para respaldar y regular en qué se están convirtiendo?
Algunas de las preguntas que vale la pena plantearse antes de entonces:
¿Qué significa el acceso con privilegios mínimos para un agente que puede elegir sus propias herramientas y acceder a varios sistemas en una sola ejecución?
¿Podría tu equipo responder, ahora mismo, qué ha hecho un agente y por qué, sin esperar a que algo falle primero?
¿Cuáles de tus actuales controles de aprobación están adaptados al ritmo humano y cuáles se convierten silenciosamente en un cuello de botella —o en un punto ciego— cuando el código se ejecuta diez veces más rápido?
Nosotros tampoco tenemos aún todas las respuestas. Para eso está el seminario web de agosto.
Si prefieres hablarlo antes, también ofrecemos una charla de 30 minutos sobre la preparación de la plataforma de desarrollo «agentic» para equipos que actualmente utilizan, están probando o evaluando GitHub Copilot. Para los equipos que aún se encuentran en las primeras fases de adopción, esa charla es también la puerta de entrada a nuestro taller «GitHub Copilot Accelerator» : una actividad práctica dirigida por expertos para que los desarrolladores utilicen Copilot de forma eficaz antes de abordar la cuestión de la gobernanza que plantea esta publicación.
Si tu organización está pasando del desarrollo asistido por IA a agentes que planifican el trabajo, modifican el código y participan en la entrega, únete a nosotros el 5 de agosto a las 12:30 p. m. EDT para «Creación de la plataforma de desarrolladores para agentes de IA».
Inscríbete en «Creación de la plataforma de desarrolladores para agentes de IA»
