El 9 de febrero, en plena noche (hora de Pekín), decenas de millones de desarrolladores de todo el mundo abrieron GitHub y se encontraron con la misma página.
No era un error 404, sino algo aún más inquietante —la inquietante barra de advertencia amarilla que hace que a todos los ingenieros se les erice el vello de la nuca, junto con un tablero de estado lleno de indicadores que pasaban de verde a rojo.
github.com estaba caído.
La API estaba caída.
GitHub Actions estaba caído.
Las operaciones Git estaban caídas— ni siquiera Copilot se salvó.
Esa noche, las tuberías CI/CD de algunos se atascaron en el momento más crítico, los despliegues automatizados de otros quedaron colgados a mitad de camino, y algunos esperaban un PR que no podía fusionarse —detrás del cual había una funcionalidad esperando para ser lanzada y usuarios reales esperando.
Posteriormente, GitHub publicó un informe del incidente. La causa raíz, en lenguaje técnico, fue una «sobrecarga de un clúster de bases de datos central responsable de la autenticación y la gestión de usuarios». Pero detrás de esas palabras se escondía una cadena de desencadenantes alarmante —
Dos días antes, el equipo de ingeniería, para poder enviar un nuevo modelo a los usuarios lo antes posible, cambió el tiempo de refresco de una «caché de configuración de usuario» de 12 horas a 2 horas. Sólo fue cambiar un número en la configuración.
El resultado fue que la reescritura de la caché, que originalmente se distribuía a lo largo de 12 horas, se comprimió en 2, formando una intensa «tormenta de reescritura de caché». La cola de tareas asíncronas se colapsó al instante, los componentes de infraestructura compartida fallaron, y la reacción en cadena se propagó al servicio responsable de las operaciones Git HTTPS a través de proxy, agotando finalmente las conexiones de toda la plataforma.
Un número, de 12 a 2.
GitHub fue derribado por un cambio de configuración que él mismo hizo.
Pero si sólo ves este cambio de configuración, probablemente te estás perdiendo la parte más importante de esta historia.
01 No fue un accidente, fueron diez
El incidente del 9 de febrero no fue un hecho aislado.
De hecho, en los primeros tres meses de 2026, GitHub experimentó al menos 8 incidentes importantes. Sólo en febrero se registraron 37 interrupciones de diversa magnitud. El CTO de GitHub, Vlad Fedorov, admitió más tarde en un blog que GitHub no había logrado mantener las «tres nueves» —99.9% de disponibilidad— que promete a sus clientes empresariales.
Si revisas el archivo de incidentes de esos dos meses, encontrarás un patrón peculiar: cada interrupción parece tener una causa diferente.
2 de febrero: Problemas con el proveedor de computación de Azure, GitHub Actions estuvo inactivo durante casi 4 horas, afectando también al agente de codificación de Copilot, CodeQL y Dependabot.
9 de febrero: Tormenta de reescritura de caché, sobrecarga de la base de datos de autenticación.
5 de marzo: Fallo en un clúster de Redis, el 95% de los flujos de trabajo de GitHub Actions no pudo iniciarse en 5 minutos, con una latencia media de 30 minutos.
18 de marzo: La latencia de los Webhooks se disparó hasta 32 veces su nivel normal.
Cada una parecía un «accidente», cada una tenía una causa directa diferente. Pero la explicación de Fedorov las une en una misma historia. Dijo que detrás de estos incidentes hay tres causas estructurales comunes: «crecimiento rápido de la carga, acoplamiento estrecho entre servicios que propaga fallos locales, y falta de capacidad en los sistemas para proteger el tráfico de clientes anómalos».
En términos de ingeniería, los cimientos de GitHub ya están mostrando grietas bajo la presión de la nueva carga.
Y esta «nueva carga» tiene un nombre concreto.
02 275 millones de commits a la semana
Datos clave
Total de commits en 2025: aproximadamente 1,000 millones
Commits semanales en 2026: 275 millones
A este ritmo, proyección para todo 2026: 14,000 millones (14 veces más que el año anterior)
Carga computacional de GitHub Actions: 2023: 500 millones de minutos/semana → 2025: 1,000 millones → Principios de 2026: 2,100 millones de minutos (en una semana)
Si eres un ingeniero de infraestructura de GitHub, comparar los paneles de control de 2025 y 2026 probablemente te dejaría boquiabierto.
En todo 2025, GitHub procesó alrededor de 1,000 millones de commits. Esta cifra ya era enorme, resultado de años de acumulación en la plataforma. Pero en 2026, el volumen semanal de commits alcanzó los 275 millones. Haciendo cálculos — si este ritmo se mantuviera todo el año, el total de commits en 2026 se acercaría a los 14,000 millones, multiplicando por 14 la cifra de todo 2025.
Esto no es una curva de crecimiento suave, sino un precipicio. El cambio en la carga computacional de GitHub Actions lo ilustra aún mejor: en 2023 se consumían 500 millones de minutos por semana, en 2025 se duplicó a 1,000 millones, y en una semana de principios de 2026, se disparó directamente a 2,100 millones de minutos.
¿Qué está haciendo commits al código de forma tan frenética?
No son desarrolladores humanos.
Los datos de GitHub muestran que los Agentes de IA se están convirtiendo en los «usuarios» más activos de la plataforma. Solo la herramienta Claude Code ahora contribuye con el 4.5% de todos los commits en repositorios públicos de GitHub. 2.6 millones de commits a la semana, mientras que a finales de septiembre de 2025, esa cifra era de solo 100,000 — un crecimiento de 25 veces en tres meses.
El número de PRs (Pull Requests) abiertos por Agentes de IA también está explotando. En septiembre de 2025, los PRs generados por IA eran alrededor de 4 millones al mes; para marzo de 2026, esa cifra saltó a 17 millones —más de cuatro veces, en medio año.
Hay una imagen que puede ayudarte a entender lo que esto significa.
Antes, los «usuarios» de GitHub eran principalmente programadores humanos. Trabajaban de día, dormían por la noche, descansaban los fines de semana, pensaban y dudaban antes de cada commit, y su velocidad tenía un límite. La carga del sistema seguía el ritmo humano, con picos y valles, era predecible.
Ahora, cada vez más «usuarios» son Agentes de IA. No duermen, no descansan, no dudan, pueden lanzar múltiples Agentes en paralelo para una tarea, y las cantidades de commits por hora de cada Agente superan fácilmente el trabajo semanal de un ingeniero real. Lo más importante es que no solo están haciendo commits, sino que también están creando constantemente nuevos repositorios —tratándolos como el «producto de salida» de un flujo de trabajo, no como el «espacio de trabajo» de un humano.
Los ingenieros de infraestructura de GitHub ya no enfrentan un problema del mismo tipo pero con más tráfico, sino un problema de naturaleza completamente diferente.
03 El dinero de Copilot ya no alcanza para pagar la cuenta
Los fallos frecuentes son solo una cara de la moneda. GitHub tiene otro problema más complicado —al hacer las cuentas, descubrieron que estaban perdiendo dinero.
La lógica de precios inicial de Copilot se basaba en una suposición razonable: el usuario la usaría principalmente como «asistente de autocompletado», cada interacción sería breve y el cómputo sería predecible. La versión personal a $10 al mes, la comercial a $19 al mes, por asiento, un modelo que funcionó bien durante los últimos años.
Luego llegó la IA Agéntica (Agentic AI).
Los flujos de trabajo Agénticos y el autocompletado tradicional son dos especies diferentes. El autocompletado de código estándar es lineal, predecible, con ciclos computacionales breves. Una sesión de codificación Agéntica puede durar horas, lanzar múltiples hilos en paralelo, realizar razonamientos de varios pasos, autocorrección, refactorización entre repositorios —el consumo de tokens en una sesión supera fácilmente la cuota mensual de un usuario común.
La situación que enfrenta GitHub es que unos pocos usuarios intensivos de IA Agéntica están consumiendo recursos computacionales que valen cientos de dólares, pagando solo unos pocos dólares al mes.
Frente a esto, la reacción de GitHub fue directa —primero controlar el flujo, luego cambiar los precios.
A principios de este año, GitHub implementó dos mecanismos de limitación paralelos para Copilot: límites de duración de sesión y límites de uso semanal, ambos calculados según el consumo de tokens multiplicado por un peso computacional del modelo. Al mismo tiempo, se suspendió el registro de nuevos usuarios para algunos planes personales de Copilot.
El 1 de junio, GitHub completó una reforma de precios más fundamental: Copilot cambió completamente a un modelo de pago por uso, reemplazando las tarifas planas anteriores por «Créditos de IA». 1 Crédito de IA equivale a 1 centavo de dólar, y el uso se calcula en tiempo real según el consumo de tokens.
La era del pago por asiento ha llegado a su fin ante la IA Agéntica.
Este cambio no es solo un problema de GitHub. Es una crisis de precios colectiva que toda la industria de herramientas de IA está experimentando en 2026 —cuando la IA empieza a reemplazar a los humanos en la ejecución de flujos de trabajo completos, y no solo a «asistirlos», toda la lógica de suscripciones basadas en «por persona, por mes» queda obsoleta.
04 30 veces, no 10
Volviendo al problema de infraestructura. ¿Cómo planea GitHub exactamente hacer frente a este «crecimiento de 14 veces»?
Hay un detalle que ilustra la gravedad de la situación:
A finales de diciembre de 2025, los flujos de trabajo Agénticos empezaron a acelerarse de repente. Los ingenieros de GitHub se dieron cuenta de que 10 veces no era suficiente. Para febrero de 2026, justo después de esa grave interrupción, GitHub anunció que necesitaba rediseñar su arquitectura para una escala 30 veces mayor que la actual.
No es ampliar capacidad, es rediseñar.
La diferencia entre estos dos términos es enorme. Ampliar capacidad es añadir más máquinas existentes, más memoria a las bases de datos existentes —la dirección es la misma, solo aumenta la escala. Rediseñar significa que los supuestos arquitectónicos actuales fallarán sistémicamente a una escala 30 veces mayor, y hay que repensar desde la base la forma de dividir servicios, los flujos de datos y el aislamiento de fallos.
Las direcciones específicas que GitHub ha revelado incluyen desacoplar servicios clave para prevenir fallos en cascada, introducir mecanismos de «backpressure» y capacidad de degradación de tráfico, implementar hosts independientes para servicios críticos, eliminar puntos únicos de fallo, y una gestión de cambios más rigurosa —para evitar que operaciones como «cambiar el TTL de la caché de 12 horas a 2» se implementen en producción sin pruebas de carga exhaustivas.
Vale la pena señalar que GitHub no está solo.
Stripe ya se ha enfrentado al problema de que los Agentes de IA crean cuentas en masa, AWS está construyendo sistemas de identidad, de registro (logging) y mecanismos de control de producción específicos para Agentes. Estas acciones no son preventivas, sino que son señales que ya aparecen en sus paneles de control y que deben resolver.
GitHub fue solo el primero en ser derribado —porque está en el núcleo mismo de la cadena de herramientas de IA.
05 Los repositorios de código se están convirtiendo en el tubo de escape de la IA
Detengámonos a pensar en la naturaleza de todo esto.
¿Qué es GitHub? La respuesta más directa es: es donde los programadores guardan su código. Pero a un nivel más profundo, es la infraestructura de colaboración de software humano —el historial de commits es la traza de la colaboración, los PRs son contenedores de discusión, los Issues son la huella de la intención, las Actions son las tuberías de ejecución. Todo el sistema está diseñado para el ritmo de trabajo, la forma de pensar y los modos de colaboración humanos.
Los Agentes de IA están cambiando todo esto.
Cuando un Agente de IA puede hacer cientos de commits al día, y detrás de cada «commit» no hay reflexión o ponderación humana, sino solo un paso de progreso en un ciclo de tareas —¿sigue siendo el repositorio de código un «contenedor de colaboración»?
Cuando las herramientas de IA generan repositorios automáticamente, abren PRs automáticamente, ejecutan CI automáticamente, fusionan automáticamente —¿siguen siendo los desarrolladores el sujeto principal de este flujo, o se han convertido en «revisores» o incluso «espectadores»?
El CTO de GitHub, al describir esta crisis, usó la frase «crecimiento rápido de la carga». Pero esta frase probablemente subestima la naturaleza del problema —esto no es solo un crecimiento cuantitativo, es un cambio cualitativo en la forma de uso. En el modelo antiguo, GitHub era una «herramienta para desarrolladores»; en el nuevo modelo, GitHub se está convirtiendo en el «tubo de escape de la IA», un conducto de salida para flujos de trabajo automatizados.
Lo que esto significa para GitHub aún no tiene respuesta. Escalar 30 veces puede resolver el problema del tráfico, pero no puede resolver la redefinición del modelo de negocio, ni la cuestión identitaria de «quién es mi verdadero usuario».
Recientemente ha habido un fenómeno bastante significativo: después de las interrupciones, GitHub ha publicado numerosos blogs de ingeniería, describiendo con un detalle casi sorprendente la causa raíz de cada incidente, alcanzando un nivel de transparencia inesperado. Algunos piensan que GitHub está construyendo confianza activamente, otros creen que está intercambiando transparencia por la paciencia de la comunidad de desarrolladores —porque durante el próximo período de rediseño, habrá más inestabilidad.
Una plataforma, después de ser derribada por su propio éxito, necesita desmontarse y reconstruirse —y este proceso en sí mismo también es una prueba para ver si puede aguantar.
Esa noche del 9 de febrero, ese ingeniero esperando que se fusionara su PR probablemente finalmente vio la luz verde. Pero quizás no se dio cuenta de que la interrupción que lo hizo esperar no fue un accidente aislado de GitHub, sino el primer estruendo de toda la industria del desarrollo de software al entrar en una nueva era.
Este artículo proviene del WeChat Official Account «极客公园» (ID:geekpark), autor: 宇航猿 (Astronaut Simio).
