Requisitos dentro, infraestructura fuera: de un servicio gestionado al desarrollo agéntico

A principios de este año ayudamos a un proveedor de servicios gestionados (MSP) a trasladar el desarrollo de su plataforma principal, la infraestructura como código (IaC) que despliega y mantiene la infraestructura y las cargas de trabajo de sus clientes en Azure, de Azure DevOps a GitHub Enterprise, y a reconstruir la forma de trabajar de su equipo en torno a agentes de IA. Los miembros del equipo entregan ahora cambios reales de infraestructura describiendo lo que necesitan. Los ingenieros sénior mantienen el control mediante la revisión y la aprobación. Esto es lo que cambió.

Dónde empezó

La plataforma nació como un entorno de Azure DevOps: infraestructura escrita en Terraform para los clientes de servicios gestionados, validada y desplegada mediante canalizaciones (pipelines) de CI/CD en Azure DevOps. Funcionaba, pero escalaba con las personas, no con la demanda. Un ingeniero sénior solo podía asumir un número limitado de tareas complejas a la vez. La entrega pasaba por cientos de archivos de pipeline, la mayoría copias específicas de cada cliente, de modo que cualquier cambio transversal había que repetirlo en todos ellos. Contribuir exigía conocer Terraform, las reglas de nomenclatura, la estructura del repositorio y su lógica. El conocimiento vivía en una sola cabeza.

El traslado

Primero pusimos bajo código la propia GitHub Enterprise, después trasladamos el repositorio de la plataforma con todo su historial y migramos todas las pipelines a GitHub Actions en una sola semana. Los cientos de archivos de pipeline se redujeron a una única plantilla de despliegue reutilizable que se despliega sobre cada cliente y cada entorno a partir de la configuración, más un flujo de trabajo ligero por funcionalidad. Un cambio que antes se editaba en cada copia ahora se edita una sola vez. Incorporar a un cliente se convirtió en un archivo de configuración, y ese archivo lo crea un agente de IA a partir de una petición en lenguaje natural planteada como incidencia (issue) de GitHub.

Gobernanza como código

Las identidades, los equipos y los permisos proceden de Microsoft Entra ID y se crean mediante código. La protección de ramas se define a nivel de organización y ningún administrador de repositorio puede relajarla: cada cambio necesita una revisión aprobada, y los despliegues a producción pasan por una aprobación humana. Las reglas son las mismas para una persona y para un agente, y una persona siempre tiene el control.

Un único reglamento para personas y agentes

El equipo mantiene un único conjunto central de instrucciones que todo agente adopta en cualquier tarea que realiza: cómo está organizado el repositorio, las convenciones de nomenclatura, qué herramientas usar, cómo se prueba un cambio y cómo se redacta una solicitud de incorporación de cambios (pull request). Esas mismas reglas se ejecutan como comprobaciones en cada pull request y como hooks en la máquina de cada desarrollador, de modo que una regla que importa se hace cumplir, no solo se deja por escrito.

Esas barreras de seguridad son lo que hace que sea seguro que compañeros con menos experiencia contribuyan: el agente sigue el reglamento, las comprobaciones detectan lo que hace mal y un ingeniero sénior tiene la última palabra.

La nueva forma de trabajar

Cualquier persona del equipo describe lo que necesita como una incidencia de GitHub, a menudo redactada con GitHub Copilot, y se la asigna a un agente de programación. El agente abre una pull request. Se ejecutan las comprobaciones. Un ingeniero sénior revisa, pide cambios donde hace falta y aprueba; el agente itera en la misma pull request. La fusión (merge) lanza el despliegue, y producción sigue esperando una aprobación humana. En el primer paso nadie toca código.

Los ingenieros sénior usan asistentes de IA de forma interactiva para el diseño, la depuración, la revisión y las operaciones, y ese trabajo llega como pull requests revisadas, igual que cualquier otro.

Qué cambió

• Velocidad. En el primer mes tras el traslado, los agentes entregaron por sí solos decenas de cambios fusionados, y no han dejado de hacerlo desde entonces. Hoy, aproximadamente un tercio de todos los cambios fusionados los escriben agentes, y la mayoría se aceptan tras una sola ronda de revisión.
• Tiempo hasta la entrega. Una petición bien descrita pasa normalmente de incidencia a cambio fusionado en un día, con el despliegue a continuación de forma automática, y muchas de esas peticiones se completan el mismo día.
• Complejidad. Cientos de archivos de pipeline se convirtieron en una plantilla. El formato, la documentación y los informes de estado los hacen bots. Un despliegue nocturno fallido abre su propia incidencia en lugar de esperar a que alguien lo note. Los ingenieros sénior podrían haber construido todo esto por su cuenta; lo que la IA cambió fue el plazo: lo terminó en un margen de tiempo que ningún equipo humano habría podido cumplir.
• Calidad. Cada cambio, de una persona o de un agente, pasa por las mismas comprobaciones y la misma revisión. Las reglas viven en el repositorio, y el rastro de auditoría va de la petición a producción.
• Capacidad del equipo. El ingeniero que antes escribía la mayor parte del código ahora revisa y decide. La contribución de un segundo ingeniero se multiplicó por más de diez. Otros dos compañeros entregan cambios describiéndolos. El punto único de fallo ha desaparecido.

Qué ahorró

Como estimación, solo los cambios escritos por agentes representan entre dos y tres meses de ingeniero en los primeros ocho meses, descontando el tiempo de revisión que necesitan. La ganancia mayor es más difícil de contar: tiempo sénior dedicado al diseño y la revisión en lugar de a cambios rutinarios, y un backlog que ya no espera a una sola persona.

Qué aprendimos

• Los agentes necesitan reglas exigibles, no prosa. Cada directriz que importaba se convirtió en una comprobación.
• La calidad de la petición decide la calidad del resultado. Escribir criterios de aceptación es la nueva competencia clave.
• La revisión es donde la experiencia sénior rinde. El equipo situó a sus mejores personas en el punto de mayor palanca.

Predicamos con el ejemplo

Nuestra propia infraestructura, documentación, sitio web y organización de GitHub funcionan de la misma manera: las peticiones se convierten en incidencias, los agentes hacen el trabajo, cada cambio es una pull request revisada tras comprobaciones automáticas, y un registro de decisiones y unos runbooks conservan el rastro de auditoría. La página que estás leyendo se produjo así.

La IA no sustituye a la experiencia sénior, ni la excluye. Multiplica lo que un equipo puede entregar cuando las reglas están claras y los ingenieros sénior tienen la última palabra. Descubre lo que ofrecemos en IA e IA agéntica y formación de equipos.