La Inteligencia Artificial prometía escribir código más rápido. Lo está haciendo. Pero la parte incómoda empieza ahora: cada línea generada, cada pull request automática y cada agente que ejecuta tareas en segundo plano consume infraestructura real. No basta con pagar tokens o una suscripción a Copilot, Cursor, Claude Code o Codex. También hay que pagar todo lo que ocurre después: compilaciones, tests, runners, revisiones, artefactos, logs y pipelines.
La información publicada por diferentes medios como Noticias.AI sobre Microsoft y GitHub ha puesto el tema sobre la mesa. Según el medio, Microsoft estaría recurriendo a capacidad de Amazon Web Services para aliviar la presión sobre GitHub provocada por el crecimiento del desarrollo asistido por IA. Microsoft no ha confirmado públicamente el nombre de AWS, pero sí ha reconocido una estrategia multicloud para GitHub. El matiz es importante, aunque no cambia la lectura de fondo: incluso una plataforma propiedad de Microsoft puede necesitar capacidad externa cuando el uso de IA crece más rápido que la infraestructura disponible.
La paradoja es potente. GitHub es una de las piezas centrales del desarrollo moderno y Microsoft controla Azure, una de las mayores nubes del mundo. Si ese conjunto siente presión por la actividad generada alrededor de Copilot, los equipos de ingeniería de cualquier empresa deberían mirar con atención su propia factura de CI/CD.
El coste ya no termina en el token
Durante los últimos meses, buena parte del debate sobre IA en desarrollo se ha centrado en el coste de los modelos. Cuánto cuesta cada millón de tokens. Cuánto cobra una herramienta por usuario. Qué plan incluye más contexto. Qué modelo es mejor para programar. Es una parte relevante, pero no la única.
Un agente de código no se limita a responder en un chat. Puede clonar un repositorio, leer ficheros, modificar ramas, ejecutar comandos, lanzar tests, abrir pull requests, pedir revisiones y repetir el ciclo varias veces. Cada paso toca sistemas que ya existían antes de la IA, pero que ahora reciben más carga y con menos intervención humana.
| Acción generada por IA | Coste visible | Coste que suele aparecer después |
|---|---|---|
| Sugerir código | Suscripción o créditos de IA | Revisión, tests y mantenimiento |
| Abrir una pull request | Créditos del agente | Runners, CI/CD y almacenamiento |
| Revisar código automáticamente | Créditos de IA | Minutos de Actions en ciertos casos |
| Ejecutar tests | Minutos de CI | Reintentos, logs y artefactos |
| Refactorizar módulos | Tokens y tiempo de agente | Validación funcional y regresión |
| Generar más cambios | Productividad aparente | Más presión sobre pipelines |
GitHub lo explica en su documentación: Copilot cloud agent usa minutos de GitHub Actions y créditos de IA. También las funciones de revisión o los agentes de terceros pueden consumir capacidad de ejecución además de créditos asociados al modelo. Eso significa que la actividad de IA tiene una doble contabilidad: la del modelo y la de la infraestructura que convierte sus propuestas en cambios verificables.
El problema para muchas empresas es que esas dos partidas no siempre se miran juntas. El equipo de desarrollo ve productividad. Finanzas ve más gasto cloud. Plataforma ve más colas en los runners. Seguridad ve más cambios que revisar. Y nadie tiene una foto completa del coste por cambio aceptado.
GitHub Actions se convierte en una línea crítica de gasto
La integración continua siempre ha tenido coste, pero era relativamente predecible. Un equipo abría pull requests, se ejecutaban pipelines, pasaban o fallaban tests y el volumen dependía de la actividad humana. Con agentes, ese patrón cambia. La IA puede multiplicar ramas, commits, pruebas y revisiones sin que aumente en la misma proporción el número de desarrolladores.
La incidencia de GitHub Actions de mayo de 2026 muestra hasta qué punto esta capa es crítica. GitHub informó de una degradación en runners alojados en la región East US, con fallos en trabajos que solicitaban runners estándar y larger runners con red privada. Durante esa ventana, unas 8.500 solicitudes de Copilot Code Review agotaron tiempo.
No es una catástrofe ni una prueba de fragilidad estructural. Plataformas de esta escala sufren incidencias. Pero sí deja una señal clara: los asistentes de código ya no son solo una capa de ayuda al desarrollador. Son parte del flujo operativo de GitHub. Si fallan los runners, fallan también piezas de la experiencia de IA.
| Capa afectada | Por qué importa |
| GitHub Actions | Ejecuta builds, tests y tareas de agentes |
| Copilot Code Review | Añade revisión automática sobre pull requests |
| Copilot cloud agent | Trabaja en entornos efímeros basados en Actions |
| Runners alojados | Aportan capacidad de ejecución bajo demanda |
| Créditos de IA | Miden consumo de modelo |
| Logs y artefactos | Almacenan el resultado de cada ejecución |
La conclusión para empresas no debería ser “no uses IA”. Sería una lectura pobre. La conclusión razonable es otra: la IA en desarrollo necesita gobierno operativo. No puede tratarse como un simple plugin del editor.
Más código no siempre significa menos coste
Uno de los errores habituales al evaluar herramientas de IA es medir solo velocidad de producción. Si un desarrollador entrega antes una función con ayuda de Copilot, parece que el ahorro es directo. Pero el software no termina cuando se escribe. Termina cuando pasa pruebas, se revisa, se despliega, se monitoriza y se mantiene.
La IA puede ayudar mucho en tareas repetitivas, documentación, generación de tests, migraciones controladas y análisis de código. Pero también puede aumentar el volumen de cambios que entran en el sistema. Más cambios implican más validaciones. Más validaciones implican más minutos de cómputo. Más automatización mal diseñada implica más ejecuciones innecesarias.
| Métrica tradicional | Métrica que empieza a importar |
| Líneas de código generadas | Cambios aceptados en producción |
| Pull requests abiertas | Pull requests fusionadas sin regresiones |
| Velocidad de desarrollo | Coste total por cambio útil |
| Uso de Copilot | Impacto en CI/CD y revisión |
| Ahorro de horas humanas | Incremento de infraestructura |
| Número de agentes activos | Calidad y coste de sus ejecuciones |
La frase “la IA abarata el desarrollo” necesita contexto. Puede reducir tiempo humano en algunas tareas, pero también puede desplazar el coste hacia plataformas, runners, modelos y cloud. No desaparece el gasto. Cambia de sitio.
Esta idea será cada vez más importante para CTOs, responsables de plataforma y equipos FinOps. La adopción de agentes de desarrollo no puede justificarse solo con encuestas de productividad o con métricas de autocompletado. Hay que medir coste por entrega real.
La multicloud vuelve por una razón muy simple: capacidad
Durante años, la multicloud se vendió como estrategia de independencia. En la práctica, muchas empresas acabaron concentrando cargas en un proveedor porque operar varias nubes es más caro y complejo. El caso GitHub recuerda que hay otra razón mucho más directa para usar varias nubes: falta de capacidad suficiente donde se necesita y cuando se necesita.
Si Microsoft está añadiendo capacidad externa para GitHub, no lo hace por romanticismo arquitectónico. Lo hace para sostener un servicio global con millones de desarrolladores y una presión creciente por la IA. Los usuarios no quieren saber si una parte de la carga corre sobre Azure, AWS u otro proveedor. Quieren que su workflow arranque, que Copilot responda y que la pull request no se quede esperando.
La demanda de IA está tensionando GPUs, CPU, almacenamiento, energía, redes y centros de datos. Incluso los grandes proveedores tienen plazos de construcción, restricciones eléctricas y regiones saturadas. La capacidad se está convirtiendo en una variable estratégica.
| Motivo para multicloud | Antes | Ahora |
| Resiliencia | Evitar dependencia de un proveedor | Mantener servicios bajo demanda extrema |
| Coste | Arbitraje de precios | Acceso a capacidad disponible |
| Regulación | Ubicación de datos | Soberanía y continuidad |
| Rendimiento | Cercanía al usuario | Disponibilidad de cómputo especializado |
| Escala | Crecimiento planificado | Picos generados por IA y agentes |
La IA está empujando a las empresas hacia una arquitectura más pragmática. Donde haya capacidad, allí irá parte de la carga, siempre que los costes, la seguridad y la operación lo permitan.
El nuevo FinOps empieza en el repositorio
La mayoría de programas FinOps nacieron mirando infraestructura cloud: máquinas virtuales, bases de datos, Kubernetes, almacenamiento, tráfico y licencias. Ahora hace falta bajar un nivel y mirar el repositorio. La actividad de desarrollo se ha convertido en una fuente de coste más dinámica.
Una empresa que adopta agentes debería saber cuántos minutos de CI consume cada pull request generada por IA, cuántos workflows fallan, cuántos reintentos se ejecutan, qué repositorios concentran gasto y qué porcentaje de cambios generados llega realmente a producción. Sin esos datos, la productividad puede ser una ilusión cara.
| Indicador | Pregunta que responde |
| Minutos de CI por PR | ¿Cuánto cuesta validar cada cambio? |
| PR generadas por agentes | ¿Qué parte del flujo ya no es humana? |
| Tasa de fallo de workflows | ¿La IA produce cambios útiles o ruido? |
| Reintentos automáticos | ¿Estamos pagando varias veces por lo mismo? |
| Coste por repositorio | ¿Dónde se concentra la factura? |
| Cambios fusionados frente a generados | ¿Cuál es la productividad neta? |
| Créditos de IA por cambio aceptado | ¿Qué modelo aporta mejor relación coste-valor? |
También habrá que repensar los pipelines. No todos los cambios necesitan ejecutar toda la batería de pruebas. No todos los agentes deberían tener permiso para activar cualquier workflow. No todos los repositorios necesitan la misma política. La automatización debe ser más inteligente justo porque la IA puede generar más actividad.
La factura que nadie presupuestó
El desarrollo asistido por IA está pasando de experimento a infraestructura. Eso cambia las preguntas. Ya no basta con decidir qué herramienta usa el equipo. Hay que decidir cómo se gobierna, cuánto puede consumir, qué límites tiene, qué costes activa y cómo se mide su valor.
GitHub es un buen aviso porque concentra todas las capas del problema: plataforma de código, CI/CD, asistentes, agentes, revisión automática y dependencia de infraestructura cloud. Si su crecimiento obliga a una estrategia multicloud más agresiva, el resto de empresas debería revisar sus propios supuestos.
La Inteligencia Artificial no elimina la ingeniería de plataformas. La hace más importante. Los equipos que mejor aprovechen los agentes no serán necesariamente los que generen más código, sino los que sepan integrar esa generación en un flujo controlado, medible y eficiente.
La próxima factura cloud no vendrá solo de entrenar modelos ni de ejecutar inferencia. También vendrá de todos los pipelines que esos modelos ponen en marcha.
Preguntas frecuentes
¿Por qué se habla de AWS en relación con GitHub?
Business Insider ha informado de que Microsoft estaría añadiendo capacidad de AWS para GitHub por la presión generada por el uso de IA. Microsoft ha confirmado una estrategia multicloud para GitHub, aunque no ha nombrado públicamente a AWS.
¿Qué tiene que ver GitHub Copilot con GitHub Actions?
Copilot cloud agent trabaja en entornos basados en GitHub Actions y consume minutos de Actions, además de créditos de IA. Las revisiones automáticas y otros agentes también pueden activar consumo de infraestructura.
¿La IA hace más barato desarrollar software?
Puede reducir tiempo humano en algunas tareas, pero también aumenta costes en modelos, CI/CD, runners, almacenamiento, logs y validaciones. El coste no desaparece: se desplaza.
¿Qué deben medir las empresas que usan agentes de código?
Deben medir minutos de CI por pull request, tasa de fallo de workflows, reintentos, coste por repositorio, cambios generados por agentes y cambios que llegan realmente a producción.
