Microsoft compró GitHub para reforzar su posición en el corazón del desarrollo de software. Años después, la paradoja es difícil de ignorar: el dueño de Azure estaría recurriendo a capacidad de Amazon Web Services para aliviar la presión sobre GitHub en plena explosión del desarrollo asistido por Inteligencia Artificial. La compañía no ha confirmado el nombre de AWS, pero sí reconoce que GitHub está usando una estrategia multicloud para ganar elasticidad y escala.
El dato importante no es solo quién presta capacidad a quién. La verdadera lectura está en la carga que está generando la nueva programación asistida por agentes. Durante meses el debate se ha centrado en el precio de los tokens, los planes de Copilot, la competencia con Cursor o Claude Code y la productividad prometida. Mucho menos se ha hablado del coste de ejecutar todo lo que esos sistemas producen: ramas, commits, pull requests, revisiones automáticas, tests, linters, contenedores, runners y pipelines de integración continua.
La Inteligencia Artificial no genera código en el vacío. Cada sugerencia aceptada puede convertirse en un commit. Cada agente que crea una rama puede abrir una pull request. Cada revisión automática puede activar validaciones. Cada workflow de GitHub Actions consume CPU, memoria, almacenamiento temporal, red y tiempo de máquina. Y cuando eso ocurre a escala de plataforma global, el problema deja de ser una anécdota de productividad y pasa a ser infraestructura pura.
GitHub ya no aloja solo código, aloja actividad generada por máquinas
GitHub siempre ha sido una plataforma intensiva en actividad: repositorios, issues, pull requests, paquetes, Actions, releases, artefactos y documentación. Pero la llegada de Copilot y de los agentes cambia la naturaleza del tráfico. Ya no se trata solo de humanos escribiendo código y subiéndolo al repositorio. Ahora hay sistemas que pueden investigar un proyecto, proponer cambios, crear ramas, ejecutar pruebas y abrir pull requests.
Ese cambio multiplica la actividad de forma menos visible que el uso de un chatbot. Una consulta a un modelo se mide en tokens. Una sesión de agente se mide también en entorno de ejecución, ficheros leídos, comandos lanzados, tests corridos y tiempo de runner. El coste se reparte entre varias capas y por eso es más difícil de ver.
| Acción de IA en desarrollo | Coste que suele quedar oculto |
|---|---|
| Generar código | Tokens del modelo y revisión humana |
| Abrir una pull request automática | Validaciones, revisiones y almacenamiento |
| Ejecutar tests | Minutos de CI/CD y runners |
| Pedir una revisión de Copilot | Créditos de IA y, en privados, minutos de Actions |
| Iterar con un agente | Entorno efímero, comandos, logs y consumo de cómputo |
| Crear más commits | Más actividad de repositorio y más workflows |
GitHub lo explica en su propia documentación: Copilot cloud agent trabaja en un entorno de desarrollo efímero basado en GitHub Actions, donde puede explorar código, hacer cambios, ejecutar tests y linters. También consume minutos de Actions y créditos de Inteligencia Artificial. Además, Copilot Code Review consume minutos de GitHub Actions en repositorios privados.
Eso significa que la factura del desarrollo con IA tiene dos caras. Una es visible: la suscripción al asistente o el coste por token. La otra aparece después, en la infraestructura que ejecuta las consecuencias de ese asistente.
La productividad también genera trabajo nuevo
La promesa de Copilot y de los agentes de desarrollo es clara: escribir más rápido, automatizar tareas repetitivas, reducir tiempos de entrega y ampliar la capacidad del equipo. En muchos casos esa promesa es real. Pero producir más código no siempre equivale a producir menos trabajo.
Si la IA genera más cambios, alguien o algo debe revisarlos. Si abre más pull requests, el pipeline debe validarlas. Si propone refactorizaciones, hay que probarlas. Si crea tests, hay que ejecutarlos. Si corrige vulnerabilidades, hay que comprobar que no rompe nada. El flujo de desarrollo se acelera, pero también aumenta el volumen de operaciones técnicas.
| Antes de los agentes | Con agentes de IA |
| Menos pull requests, más humanas | Más pull requests, algunas generadas por máquinas |
| Pipelines activados por equipos humanos | Pipelines activados también por agentes |
| Revisión manual concentrada | Revisión humana y automática combinada |
| Menos experimentos paralelos | Más ramas, pruebas y cambios exploratorios |
| Coste de CI más predecible | Coste más variable y difícil de atribuir |
El riesgo es que las empresas midan la productividad por velocidad de generación y no por coste total de entrega. Un agente que escribe una solución en minutos puede parecer barato. Pero si dispara varias ejecuciones de CI, fuerza revisiones, falla tests, reintenta cambios y consume runners, el ahorro ya no es tan evidente.
La pregunta no es si la Inteligencia Artificial ayuda a programar. La pregunta es cuánto cuesta convertir su producción en software fiable.
Las incidencias de GitHub muestran dónde aprieta la presión
GitHub ha publicado informes de disponibilidad que muestran cómo la presión sobre Actions y servicios vinculados a Copilot ya tiene efectos operativos. En mayo de 2026, GitHub Actions sufrió degradaciones que afectaron a runners alojados. En una de las ventanas, el 13,5 % de los trabajos que solicitaban un runner estándar fallaron, y unas 8.500 solicitudes de Copilot Code Review agotaron tiempo durante el incidente.
En otra incidencia del mismo mes, los usuarios no pudieron iniciar o ver sesiones de Copilot cloud agent durante varios minutos por un cambio de configuración en el enrutamiento del servicio. Son problemas técnicos normales en una plataforma de esta escala, pero apuntan a algo más amplio: el desarrollo agéntico no es solo una función de producto, es una carga de infraestructura que debe escalar.
| Incidencia o patrón | Qué revela |
| Degradación de runners | La CI/CD es una capa crítica del desarrollo con IA |
| Timeouts en Copilot Code Review | Las revisiones automáticas dependen de infraestructura real |
| Fallos en sesiones de cloud agent | Los agentes son servicios distribuidos, no magia local |
| Estrategia multicloud | La elasticidad empieza a pesar más que la pureza de proveedor |
| Competencia de Cursor y Claude Code | GitHub debe escalar sin perder fiabilidad |
Que Microsoft explore capacidad fuera de Azure para GitHub no debería sorprender tanto. Las grandes plataformas no pueden permitirse caídas prolongadas por orgullo de proveedor. Si una carga crece más rápido que la capacidad disponible, se busca elasticidad donde la haya. Lo incómodo es el simbolismo: Azure necesita ayuda de AWS para sostener una de las plataformas de desarrollo más importantes del mundo.
El coste se desplaza del sueldo a la infraestructura
La frase “la IA abarata el desarrollo” necesita muchos matices. Puede reducir tiempo humano en determinadas tareas. Puede acelerar prototipos. Puede ayudar a documentar, testear o revisar código. Pero no elimina el coste; lo desplaza.
Parte de ese coste sale del salario directo del desarrollador y entra en suscripciones, créditos de modelo, minutos de CI, almacenamiento de artefactos, logs, entornos efímeros y capacidad cloud. En empresas pequeñas, puede parecer una partida menor. En equipos grandes, con miles de repositorios y automatizaciones, puede convertirse en una factura difícil de controlar.
| Coste tradicional | Coste desplazado por IA |
| Horas de desarrollo | Suscripciones y créditos de IA |
| Revisión manual | Revisiones automáticas y validaciones adicionales |
| Pruebas bajo demanda | Pipelines más frecuentes |
| Menos ramas paralelas | Más experimentos generados por agentes |
| Capacidad CI estable | Más runners y más consumo variable |
| Gestión de deuda técnica humana | Refactorizaciones automáticas que deben validarse |
El problema no es que ese coste exista. El problema es no medirlo. Muchas compañías han desplegado asistentes de código como una mejora de productividad sin rediseñar sus métricas de FinOps, DevOps y gobierno de plataforma. Después descubren que los pipelines se ejecutan más, que las colas crecen, que los runners no bastan y que el coste por repositorio ya no se parece al del año anterior.
El nuevo FinOps también tendrá que mirar GitHub Actions
Hasta ahora, FinOps se ha centrado sobre todo en infraestructura cloud: máquinas virtuales, Kubernetes, almacenamiento, bases de datos, tráfico de red, GPUs y servicios gestionados. Con los agentes de desarrollo, habrá que mirar también el coste de fabricar software.
GitHub Actions, GitLab CI, Jenkins, Buildkite, CircleCI o Azure DevOps ya no son simples herramientas de automatización. Son líneas de coste asociadas a la nueva productividad. Cuando un agente trabaja en segundo plano, no solo consume tokens: usa capacidad de ejecución.
| Métrica que conviene vigilar | Por qué importa |
| Minutos de CI por pull request | Mide el coste real de validar cambios |
| Pull requests creadas por agentes | Permite separar actividad humana y automática |
| Tasa de fallo de workflows | Detecta ruido generado por cambios de baja calidad |
| Reintentos de pipelines | Señala coste repetido |
| Coste por repositorio | Ayuda a priorizar optimización |
| Tiempo de runner por modelo o agente | Vincula IA con gasto operativo |
| Cambios aceptados frente a generados | Mide productividad neta, no actividad bruta |
La disciplina que viene no será prohibir la IA, sino ponerle límites operativos. No todas las tareas necesitan un agente. No todos los cambios requieren ejecutar todo el pipeline. No todas las ramas deberían disparar despliegues completos. No todas las revisiones automáticas merecen el mismo nivel de cómputo.
Las empresas tendrán que diseñar políticas: cuándo puede actuar un agente, qué workflows puede activar, cuántos reintentos se permiten, qué tests se ejecutan en cada fase y qué repositorios pueden consumir más capacidad.
La multicloud deja de ser discurso y vuelve a ser necesidad
Durante años, muchas empresas hablaron de multicloud como estrategia. En la práctica, pocas lo aplicaron de verdad para cargas críticas, porque añade complejidad, costes y problemas de gobierno. Pero el caso GitHub recuerda que la multicloud no siempre nace de una preferencia arquitectónica. A veces nace de una urgencia de capacidad.
Cuando la demanda de IA crece más rápido que los centros de datos, la pureza de proveedor se vuelve secundaria. Las empresas quieren que el servicio funcione. Los usuarios de GitHub no quieren saber si el runner está en Azure, en AWS o en otra nube. Quieren que su build arranque y su pull request no quede bloqueada.
Esto también anticipa una etapa más pragmática en cloud. Las grandes tecnológicas competirán, pero también comprarán capacidad unas a otras cuando lo necesiten. En un mercado tensionado por GPUs, energía, suelo, refrigeración y construcción de centros de datos, la autosuficiencia total es más difícil de sostener incluso para gigantes.
Qué deberían aprender las empresas
La lección para un CTO o un responsable de plataforma es sencilla: antes de celebrar que el equipo genera más código con IA, hay que medir cuánto cuesta validar, integrar y mantener ese código. La productividad real no termina en el autocompletado. Termina cuando el cambio está en producción, no rompe nada y no dispara la factura.
La adopción de agentes debería venir acompañada de una revisión de arquitectura CI/CD. Hay que evitar pipelines excesivos, tests redundantes, runners sobredimensionados, workflows mal diseñados y políticas que permitan a los agentes abrir trabajo ilimitado sin control.
| Pregunta práctica | Por qué conviene hacerla |
| ¿Cuánto subieron los minutos de CI desde que usamos IA? | Mide coste oculto |
| ¿Cuántas PR abre o modifica un agente? | Mide actividad automática |
| ¿Cuántas fallan en tests? | Mide calidad real |
| ¿Qué workflows dispara cada tipo de cambio? | Evita cómputo innecesario |
| ¿Hay límites por repositorio o equipo? | Controla gasto |
| ¿El coste se atribuye al producto correcto? | Mejora FinOps |
| ¿La IA reduce incidencias o solo aumenta volumen? | Mide valor neto |
La Inteligencia Artificial puede ser una gran herramienta para desarrollo. Pero desplegarla sin gobierno es como dar acceso ilimitado a una fábrica automática sin mirar el contador eléctrico. Produce más, sí. También consume más.
La factura que llega después del entusiasmo
El episodio de GitHub y AWS deja una imagen potente: Microsoft, con Azure como uno de los mayores negocios cloud del mundo, buscando elasticidad adicional para mantener GitHub bajo la presión del desarrollo agéntico. Puede ser temporal, pragmático y razonable. Pero también es una advertencia.
Si GitHub, Microsoft y Azure sienten la presión de esta nueva carga, cualquier empresa que haya activado asistentes de código y agentes en sus repositorios debería revisar sus números. Quizá el equipo escribe más rápido. Quizá el backlog baja. Quizá se abren más PR. Pero quizá también el coste de CI, los runners, los logs y las revisiones automáticas están creciendo sin que nadie los haya conectado con la adopción de IA.
La IA no elimina el coste del desarrollo. Lo mueve. Del tiempo humano al cómputo. Del editor al pipeline. Del salario a la factura de infraestructura. Y cuando ese traslado se hace sin medir, la sorpresa llega en el extracto cloud.
Preguntas frecuentes
¿Por qué Microsoft recurriría a AWS para GitHub?
Según informaciones publicadas, GitHub está sufriendo presión de capacidad por el aumento del desarrollo asistido por IA. Microsoft ha confirmado una estrategia multicloud para GitHub, aunque no ha nombrado específicamente a AWS.
¿Qué tiene que ver Copilot con GitHub Actions?
Copilot cloud agent trabaja en un entorno basado en GitHub Actions, donde puede explorar código, hacer cambios, ejecutar tests y abrir pull requests. Eso implica consumo de infraestructura, no solo de tokens.
¿La IA encarece el desarrollo?
Puede reducir horas humanas en algunas tareas, pero también aumenta costes de infraestructura si genera más commits, pull requests, revisiones y ejecuciones de CI/CD. El coste no desaparece, se desplaza.
¿Qué deberían medir las empresas que usan agentes de código?
Minutos de CI por pull request, tasa de fallo de workflows, reintentos, coste por repositorio, pull requests generadas por agentes y relación entre cambios aceptados y cambios producidos.
