GitHub suma 4 millones de núcleos para los agentes de IA

Cuatro millones de núcleos extra: la factura invisible de los agentes de IA

GitHub añadió en lo que va de 2026 cuatro millones de núcleos de CPU, 160 petabytes de almacenamiento de alta velocidad y 50 terabits por segundo de capacidad de red. No es la capacidad total de la plataforma ni un anuncio a futuro: son recursos que la compañía ya incorporó para atender una actividad que creció más rápido de lo que había previsto.

Para un founder, la cifra importa por una razón poco obvia. Si tu equipo vive en GitHub, tu integración continua, tus revisiones y tus despliegues corren sobre una infraestructura que está siendo reconstruida mientras sigue operando. Entender por qué se saturó te ayuda a anticipar los cuellos de botella que vas a ver en tu propio flujo de trabajo.

¿Cuánto creció de verdad la actividad en GitHub?

Según Octoverse 2026, la plataforma pasó de 12.900 millones de commits anuales a 34.300 millones en los doce meses terminados en septiembre de 2026, contando repositorios públicos y privados. Solo en ese último mes registró 7.380 millones de commits.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

TechBooky añade que esa cifra mensual equivale a más de cinco veces la de un año antes, y aporta dos métricas que casi nadie mira y que explican mejor la presión: los envíos (pushes) mensuales pasaron de 690 millones a 3.350 millones en un año, y GitHub Actions ejecutó 3.260 millones de jobs solo en septiembre. Cada push puede disparar pruebas, compilaciones y escaneos de seguridad. Ahí está el multiplicador real, no en el volumen de código.

Del informe, Moneycontrol recoge además 1.300 millones de pull requests en el año, 566 millones de repositorios públicos y de código abierto (más de 30% interanual) y un nuevo desarrollador registrado cada segundo, por segundo año consecutivo.

Hay una advertencia metodológica que la propia GitHub hace y que conviene retener: un commit es una instantánea guardada de cambios, no una medida de productividad. Puede contener una línea o mil, y un agente puede generar decenas durante una sola tarea.

¿Por qué un agente de IA genera tantos commits?

En septiembre, más del 40% de las pull requests comenzaron con un borrador elaborado por un agente de IA que la plataforma pudo detectar. En marzo eran el 17%. En seis meses, esa proporción se multiplicó por más de dos.

El segundo dato es más sugestivo todavía: los repositorios nuevos con archivos de configuración para agentes registraron, en promedio, ocho veces más commits que los que no tienen esos archivos. GitHub lo presenta como una asociación, no como una relación causal, y la distinción es honesta: los equipos que versionan la configuración de sus agentes son los que ya decidieron trabajar de forma agéntica, así que el volumen refleja esa decisión tanto como la herramienta.

La mecánica detrás es fácil de reconstruir. Un agente recibe una tarea, lee el repositorio, propone un cambio, ejecuta las comprobaciones, falla, vuelve a modificar y vuelve a enviar. El resultado final puede ser una sola mejora para el producto, pero el sistema registró cinco, ocho o quince operaciones. Ese es el punto que se escapa cuando se mide solo el código generado.

El cuello de botella no es el tamaño del código, es la frecuencia de escritura

La parte menos intuitiva del fenómeno es esta: GitHub no se está quedando sin espacio para guardar archivos, se está quedando corto en la capacidad de coordinar operaciones concurrentes. Cuando muchas personas y muchos agentes tocan el mismo repositorio al mismo tiempo, cada escritura necesita un orden, un control de acceso y una verificación. Multiplica eso por flotas de agentes en paralelo y el desafío deja de ser el volumen y pasa a ser la tasa de operaciones por segundo.

Es una diferencia relevante para cualquier equipo que esté diseñando su propio pipeline. Escalar almacenamiento es barato y predecible; escalar la coordinación entre procesos que escriben a la vez es un problema de arquitectura.

La caída del 17 de agosto: cuando la capacidad no alcanzó

El 17 de agosto de 2026, GitHub sufrió una interrupción de siete horas y 47 minutos que afectó a varios servicios. Según explicó la propia compañía, el incidente comenzó cuando el tráfico alcanzó un nuevo máximo y un componente crítico de su centro de datos en Estados Unidos no consiguió escalar para responder a la demanda. GitHub reconoció que no había ampliado determinados recursos con suficiente antelación, aunque no atribuyó directamente esa caída a los agentes de IA.

El episodio no fue aislado. TechCrunch reportó más de seis horas de degradación con una tasa de error cercana al 20% a nivel mundial en esa misma semana, coincidiendo con el lanzamiento de Origin, la plataforma de hosting de código de Cursor. El mismo medio citó un análisis de LeadDev que contabilizaba 257 interrupciones en el último año. Cuando un proveedor de infraestructura crítica falla con esa frecuencia, el costo no es solo la espera: es el tiempo de ingeniería que tu equipo dedica a rodear el problema.

¿Qué está cambiando GitHub en su arquitectura?

Más hardware no resuelve el problema de fondo, y la compañía parece haberlo asumido. Su plan, según lo reportado por Moneycontrol y TechBooky, tiene tres frentes:

Migración a un despliegue multirregión sobre Microsoft Azure, que la empresa espera completar a principios de 2027.
Separar el almacenamiento del procesamiento, de modo que ambos recursos puedan ampliarse de forma independiente en lugar de crecer en bloque.
Reducir las operaciones que requieren coordinación entre sí, que es la raíz del cuello de botella en las escrituras.

En pruebas internas, la nueva arquitectura multiplicó hasta por 35 la capacidad de escritura, según cifras de la propia GitHub. Moneycontrol detalló otra prueba: con 5.000 agentes trabajando sobre un mismo repositorio, el sistema sostuvo 7.200 escrituras por segundo, unas 180 veces el rendimiento actual que cita la compañía. Son objetivos de ingeniería, no una promesa de que cada desarrollador vaya a notar esa mejora, y la migración de usuarios está prevista para comienzos del próximo año.

La competencia ya está ocupando ese hueco

Que GitHub esté reconstruyendo su núcleo no pasa desapercibido para el resto del mercado. El 26 de octubre, Thomas Dohmke, quien fuera CEO de GitHub hasta 2025, presentó Entire, una plataforma que ofrece hosting privado nativo, infraestructura distribuida, un sistema de revisión propio y una capa de memoria para conservar el contexto detrás de los cambios escritos por agentes. Según TechBooky, puede replicar repositorios de GitHub, de modo que adoptarla no obliga a una ruptura inmediata.

El argumento de fondo de estos competidores es incómodo y vale la pena escucharlo: la pull request, el mecanismo de revisión que sostiene el desarrollo de software desde hace más de una década, se diseñó para un mundo en el que los cambios llegaban a un ritmo que un humano podía evaluar. Cuando un agente produce revisiones más rápido de lo que un equipo puede leerlas, el proceso deja de filtrar y empieza a acumular.

¿Qué significa esto para tu startup?

El mensaje para un equipo pequeño no es que debas migrar de plataforma. Es que la adopción de agentes cambia tu perfil de costos y de riesgos de una manera que no aparece en el roadmap de producto.

Mide cuánto de tu CI lo dispara un agente y no una persona. Con 3.260 millones de jobs ejecutados en un solo mes en toda la plataforma, los minutos de Actions dejan de ser un detalle de facturación y se convierten en una línea de gasto que crece con cada flota de agentes. Revisa qué workflows se activan en cada push y elimina los que corren de más.
Define la política de revisión antes de escalar. Si ya hay borradores de agentes en tus pull requests, decide por escrito quién aprueba, qué pruebas son obligatorias para hacer merge y qué rutas críticas quedan fuera de cualquier automatización. El 40% de pull requests nacidas de un agente que reporta GitHub no es una anécdota: es tu bandeja de entrada dentro de seis meses.
Versiona la configuración de tus agentes en el repositorio. La correlación de ocho veces más commits en repos con archivos de configuración sugiere que la estandarización es lo que separa un uso ordenado de un caos reproducible. Un archivo compartido con instrucciones, límites y convenciones evita que cada desarrollador improvise su propio flujo.
Ten un plan de continuidad para los repositorios críticos. Mantener un espejo o una copia sincronizada de los proyectos de los que depende tu producción es barato comparado con siete horas y 47 minutos de indisponibilidad en plena semana de lanzamiento.

Conclusión

La expansión de los agentes de IA está moviendo el valor del desarrollo de software hacia un lugar poco glamoroso: la capacidad de absorber cambios. Generar una función ya es la parte fácil; registrar versiones, coordinar revisiones, ejecutar pruebas y decidir qué se conserva es donde se juega la velocidad real de un equipo.

GitHub está gastando cuatro millones de núcleos y un rediseño de arquitectura para demostrarlo. La lección para un founder es simétrica: cada agente que sumes a tu flujo multiplica la actividad del sistema, y ese sistema también necesita presupuesto, reglas y margen para crecer.