GitHub tuvo que llamar a Amazon para sobrevivir: los agentes de IA colapsaron la infraestructura de Microsoft

Hay una forma de leer el anuncio de ayer que hace que parezca una decisión técnica rutinaria. Microsoft necesitaba más capacidad. AWS tiene capacidad. Microsoft la compró. Ocurre constantemente en la industria cloud.

Hay otra forma de leerlo que es la correcta: la empresa que gastó 190.000 millones de dólares en infraestructura cloud en 2026, que construyó Azure específicamente para no depender de competidores, que tiene una de las infraestructuras de centros de datos más grandes del mundo, tuvo que llamar a su rival más directo para mantener funcionando uno de sus productos más estratégicos porque los agentes de IA estaban generando más tráfico del que podía manejar.

La crisis de infraestructura de GitHub alcanzó un nuevo nivel el 16 de junio cuando Microsoft confirmó que recurría a Amazon Web Services para gestionar el tráfico de agentes de codificación de IA que había empujado la plataforma más allá de sus límites — 275 millones de commits por semana, nueve outages en mayo y disponibilidad en junio muy por debajo del umbral de SLA enterprise del 99,9%. NewsBytes

275 millones de commits semanales. Nueve outages en mayo. Disponibilidad por debajo del 99,9% en junio. Estos son los números que hicieron que Microsoft tuviera que hacer algo que ninguna empresa tecnológica de su tamaño y posición hace de forma voluntaria: pagar a su competidor principal para mantener su producto funcionando.

Por qué los agentes de codificación son distintos de los usuarios humanos

Para entender por qué la infraestructura de GitHub colapsó en 2026 después de décadas de escalar sin grandes problemas, hay que entender qué hace diferente a un agente de codificación respecto a un usuario humano.

Un desarrollador humano trabaja de forma intermitente. Escribe código, piensa, hace una pausa, revisa, hace un commit. El patrón de uso es pulsado — hay momentos de alta actividad y momentos de silencio. La infraestructura de GitHub fue diseñada para ese patrón: millones de usuarios con actividad distribuida en el tiempo.

Un agente de codificación — Claude Code, GitHub Copilot en modo agéntico, Cursor en modo autónomo — no hace pausas. Itera continuamente. Hace decenas o cientos de llamadas a la API por minuto. Crea branches, abre pull requests, ejecuta tests y revisa resultados en un bucle continuo que puede durar horas sin intervención humana.

Cuando millones de agentes hacen esto simultáneamente, el efecto acumulativo se parece a una carga sostenida contra los propios servicios internos de la plataforma. NewsBytes

El CTO de GitHub Vlad Fedorov reconoció en un post del blog de abril que GitHub comenzó a ejecutar un plan en octubre de 2025 para aumentar la capacidad diez veces. En febrero de 2026, ese objetivo había sido revisado a 30 veces — porque el uso de herramientas de desarrollo agéntico había crecido más rápido de lo que los modelos del equipo de infraestructura habían predicho. NewsBytes

De 10x a 30x en cuatro meses. Eso no es planificación de capacidad que se quedó corta — es una categoría de crecimiento que ningún modelo de planificación razonable habría predicho porque el comportamiento de los agentes de IA en producción a escala es genuinamente nuevo. No hay precedentes históricos de cómo crece el tráfico cuando los usuarios son en parte humanos y en parte agentes que nunca duermen.

El problema estructural que el crecimiento reveló

Más cómputo por sí solo no resuelve esto. Fedorov identificó la causa raíz con precisión: «crecimiento rápido de carga, acoplamiento arquitectónico que permitía que problemas localizados se propagaran en cascada por servicios críticos, e incapacidad del sistema para descargar adecuadamente la carga de clientes con comportamiento anómalo». Ese lenguaje describe un problema estructural. NewsBytes

La plataforma de GitHub fue construida en 2008 sobre Ruby on Rails y todavía ejecuta una aplicación monolítica de casi dos millones de líneas en su núcleo. NewsBytes

Aquí está el problema real: no es solo que GitHub necesita más servidores. Es que su arquitectura fundamental — una aplicación monolítica construida hace dieciocho años para un patrón de uso que ya no existe — no puede escalar limpiamente para el tipo de tráfico que los agentes de codificación generan. Añadir más capacidad de AWS es un parche que compra tiempo. El problema estructural requiere una reescritura de arquitectura que toma años y que nadie puede hacer sin interrumpir el servicio para los 100 millones de desarrolladores que lo usan a diario.

La capacidad de Azure está siendo distribuida entre los clientes de Azure, la demanda relacionada con OpenAI, los propios productos Copilot de Microsoft, cargas de trabajo de seguridad, servicios de datos y aplicaciones propias. El problema de GitHub es que es tanto un activo estratégico como otro reclamante interno de infraestructura escasa. Benzinga

Esta última frase es la más reveladora de todo el episodio. Azure no tiene capacidad de sobra para GitHub porque esa misma capacidad está siendo consumida por OpenAI, por Copilot, por los propios servicios internos de Microsoft y por los clientes de Azure que pagan. GitHub compite internamente con todos esos usos por los mismos recursos, y en esa competencia interna está perdiendo.

Lo que significa que Microsoft pague a Amazon

«El increíble pico en el desarrollo agéntico que comenzó a finales del año pasado ha puesto a prueba los límites de nuestra infraestructura», dijo un portavoz de la empresa, declinando comentar específicamente sobre la participación de AWS pero reconociendo su movimiento hacia Azure y el uso continuado de «una estrategia multi-cloud para asegurar que tenemos la capacidad futura». CNBC

La frase «estrategia multi-cloud» es el lenguaje corporativo para «necesitamos a Amazon porque nuestra propia infraestructura no es suficiente». Es un lenguaje que cualquier CTO de empresa mediana usaría para no admitir que su proveedor principal no da abasto. Que sea Microsoft quien lo usa sobre su propio producto es la parte que hace que la historia sea significativa más allá de los detalles técnicos.

Sigue siendo una salida llamativa usar AWS para ejecutar una pieza central de GitHub. Sugiere que la infraestructura de IA de Azure, aunque masiva, no es infinita. Microsoft ha estado en una frenética expansión, añadiendo capacidad GPU para el GPT-5 de OpenAI y Copilot, pero el buildout lleva tiempo y las escaseces de chips y las limitaciones energéticas pueden retrasar los lanzamientos de nuevos centros de datos. MIT Technology Review

GitHub ha enfrentado problemas de fiabilidad del servicio este año, con Business Insider reportando docenas de grandes outages en 2026. En abril, Mitchell Hashimoto, cofundador de HashiCorp, escribió que GitHub «ya no es un lugar para trabajo serio si simplemente te bloquea durante horas al día, todos los días». Yahoo!

Cuando el cofundador de HashiCorp — uno de los proyectos de infraestructura de código abierto más relevantes del ecosistema de desarrollo — dice que GitHub ya no es fiable para trabajo serio, eso no es una queja de usuario insatisfecho. Es una señal de mercado que Cursor, Claude Code y los competidores de GitHub están aprovechando activamente.

Los 190.000 millones en capex de Microsoft que no resuelven el problema de hoy

Microsoft sigue gastando como si tuviera intención de ser propietaria de esta capa. Business Insider señaló que la empresa proyectó recientemente 190.000 millones de dólares en gastos de capital para el año calendario 2026, en gran parte para capacidad de centros de datos. Pero el gasto de capital y la capacidad utilizable no son lo mismo. Los centros de datos necesitan tiempo, energía, terreno, chips y construcción de redes. GitHub necesita capacidad ahora, mientras los desarrolladores ya están usando el producto, no después de que la próxima oleada de campus entre en funcionamiento. Eso es lo que hace que este episodio sea útil más allá de Microsoft. Caixin Global

La paradoja que este episodio revela es la más importante para entender el estado de la industria cloud en 2026: los hyperscalers están comprometiendo cientos de miles de millones en infraestructura que no estará disponible hasta 2027 o 2028, mientras los agentes de IA generan demanda que ya está colapsando sus sistemas en 2026. La brecha entre la velocidad de adopción de los agentes y la velocidad de construcción de la infraestructura que los soporta no se puede cerrar con dinero — solo con tiempo.

GitHub debería haber sido una de las empresas mejor posicionadas del mundo para ver llegar la demanda de codificación con IA. Posee la plataforma, vende el asistente, observa los flujos de trabajo y vive dentro de Microsoft. Y aun así fue sorprendida. Caixin Global

Esa frase es el epitafio del episodio. Si GitHub — con acceso a todos los datos de uso de los desarrolladores, con Copilot integrado en su plataforma, con el respaldo de capital de Microsoft — no pudo predecir que los agentes de codificación generarían este nivel de demanda, es razonable asumir que ninguna empresa del sector está verdaderamente preparada para lo que viene cuando los agentes de IA pasen de ser una herramienta de nicho a ser la forma estándar en que se escribe software.