📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
Los números que nadie esperaba
En abril de este año GitHub procesaba 1.400 millones de commits al mes. En agosto eran 2.900 millones. Y en septiembre saltó a 7.400 millones. Para que te dimensiones el absurdo: en 2024 los desarrolladores empujaban 65 millones de commits mensuales a toda la plataforma. Eso no es crecimiento, es un cambio de régimen. Y la empresa lo confirmó igual en GitHub Universe, este miércoles en San Francisco: la demanda viene de los agentes de IA.
Lo que me llama la atención no es el número, sino la forma de la curva. Un humano codifica en horas y commitea una vez por bloque de trabajo. Un agente commitea en ráfagas: prueba, rompe, rehaz, commitea de nuevo. Commits son gratis para un agente, porque él no carga con el costo de revisión ni de compilación: lo cargan los demás. La capacidad de GitHub estaba calibrada para la segunda forma, no para la primera.
La factura llegó antes que la solución
Trauma reciente: los problemas con tráfico de agentes empezaron en diciembre pasado y se repitieron en febrero, abril y agosto. Lo más feo llegó en mayo, cuando la disponibilidad de 90 días del sitio cayó a cerca del 84%, según datos reconstruidos desde la página de estado de GitHub. Un 84% de disponibilidad no es el estándar que uno espera del lugar donde vive el código del mundo.
La respuesta: hierro nuevo y una cirugía de fondo
En agosto GitHub ya había agregado 3 millones de CPU cores. Ahora anuncia 4 millones más, 160 petabytes de almacenamiento de alta velocidad y 50 terabits por segundo de capacidad de red adicional. Pero lo importante viene aparte: están re-arquitectando la plataforma para separar cómputo y almacenamiento, con benchmarks internos que prometen 35 veces más throughput de escritura, y migrando a un despliegue multi-región en Azure que esperan terminar a comienzos del año próximo.
Jay Parikh, VP ejecutivo de CoreAI en Microsoft, lo dijo claro: agregar capacidad importa, pero sin cambiar la arquitectura no alcanza. Traducido a lo que uno ve en la pista: el hierro se compra rápido, la arquitectura se demora, y entremedio hay caídas que nadie puede predecir.
Lo que me deja pensando
Yo corro agentes en mi propia infraestructura todos los días —jobs automáticos, delegación de tareas, scripts que trabajan en paralelo— y aprendí la lección a punta de incidentes: cada agente es un usuario sin empatía que prueba límites que nadie dimensionó. Un cron mal calibrado me ha tirado procesos y saturado discos cuando menos lo esperaba; GitHub simplemente lo vivió a escala planetaria.
Si piensas soltar agentes contra un repositorio, una API o cualquier servicio compartido, tres reglas que me funcionan: limita la tasa de peticiones desde el día cero, dimensiona la cuota de escritura como si fuera un usuario malicioso, y monitorea el consumo de la infra antes de la carga, no después de la caída. Porque cuando millones de bots empiezan a commitear de madrugada, los commits dejan de ser una métrica de productividad y pasan a ser tráfico de red.
Fuente: GitHub powering up four million extra cores to stop its service going down, The Register (28-oct-2026); cifras de commits confirmadas en The New Stack.
Fuente de inspiración: GitHub powering up four million extra cores to stop its service going down
