Durante años, GitHub fue de esas cosas que simplemente funcionaban. Estaba siempre ahí, como la luz cuando le das al interruptor, y nadie se paraba a pensar en ello. Eso se acabó. En los últimos meses se ha caído una y otra vez, y por primera vez muchos desarrolladores se han parado a mirar de cuántas cosas depende su trabajo diario que están fuera de su control.
Los números asustan. Entre mayo de 2025 y abril de 2026 se registraron 257 incidentes, 48 de ellos caídas serias. Eso es, de media, un problema gordo por semana durante un año entero. Febrero de 2026 fue el peor mes, con 37 incidentes. El servicio más castigado fue GitHub Actions, lo que ejecuta tus pruebas y tus despliegues automáticos: cuando se cae, no hay plan B. Tus tests no corren, tu código no se despliega, y te quedas esperando a que GitHub se recupere.
Qué dice GitHub
La explicación oficial apunta a la IA. El responsable técnico de GitHub reconoció por escrito que en octubre de 2025 pusieron en marcha un plan para multiplicar por diez la capacidad de la plataforma, y que en febrero de 2026 ya tenían claro que se quedaba corto: necesitaban prepararse para treinta veces la escala actual. El motivo, según ellos, es cómo ha cambiado la forma de escribir software. Desde finales de diciembre de 2025, las herramientas de IA que generan código y abren cambios por su cuenta se dispararon.
Y el dato que mejor lo resume: los cambios de código abiertos por agentes de IA pasaron de cuatro millones en septiembre de 2025 a diecisiete millones en marzo de 2026. Más del triple en seis meses. Donde antes un programador abría un cambio cada cierto tiempo, ahora una herramienta automática abre cientos a la vez, de madrugada, sin descanso.
Pero hay algo que no cuadra
Hasta aquí, la versión oficial: la IA trajo una avalancha y GitHub no daba abasto. Pero hay un detalle que no encaja.
Cuando alguien se molestó en pedir los números reales de carga, salió que el aumento fue de unas 3,5 veces repartido en dos años. No es poco, pero tampoco es una marea imposible que llegó de un día para otro. Y la pregunta es la siguiente: si el crecimiento es ese, y otras plataformas parecidas aguantan cargas mayores sin caerse cada semana, ¿por qué GitHub no puede?
La respuesta no está en cuánta gente usa GitHub, sino en cómo está construido por dentro. Una sola subida de código no toca una pieza: dispara en cadena una docena de sistemas conectados entre sí (el almacenamiento, las comprobaciones de permisos, las pruebas automáticas, las notificaciones, las bases de datos...). Cuando uno de esos sistemas se atasca, arrastra a los de al lado, y un fallo pequeño en un rincón se convierte en una caída general. Un programador disparaba esa cadena una vez; una herramienta de IA la dispara miles de veces a la vez.
A eso se suma una limitación de fondo. Buena parte de GitHub está escrita en Ruby, y Ruby tiene un techo conocido: por su GIL (Global Interpreter Lock), un proceso solo ejecuta un hilo de código Ruby a la vez, aunque el servidor tenga 64 núcleos. Para tráfico al ritmo de personas eso se gestiona sin problema. Para cientos de sesiones automáticas trabajando en paralelo, ese límite deja de ser un detalle y se convierte en un muro.
Así que la conclusión es otra: la IA no rompió GitHub. Puso una carga que una infraestructura bien diseñada habría absorbido, y al hacerlo dejó a la vista grietas que ya estaban ahí desde antes. El volumen fue la chispa, no el incendio.
Qué tiene que ver esto contigo
Aunque solo abras GitHub para subir código, esto te toca de cerca. Y no es un problema solo de GitHub.
Piensa en cuánto de tu trabajo se paraliza cuando un servicio que no controlas deja de funcionar. Si tus despliegues dependen de GitHub Actions y se cae, no despliegas. Si tu integración continua vive ahí, se para. Dar por hecho que "GitHub siempre está disponible" era algo completamente razonable hace dos años; hoy ya no lo es.
No se trata de huir de GitHub. Se trata de analizar tu forma de trabajar y preguntarte: el día que esto caiga tres horas, ¿qué se me bloquea y qué puedo seguir haciendo? Tener una forma de desplegar a mano por si acaso, no encadenar cada paso de tu trabajo a un único servicio externo, y saber de antemano de qué dependes son cosas que se agradecen cuando llegue el día. Y llega.
GitHub se está reorganizando por dentro para aguantar lo que viene, y probablemente lo consiga. Pero lo que estos meses dejan claro no es un problema de una empresa concreta: es que estamos construyendo todo nuestro trabajo encima de servicios que dábamos por intocables, y que también tienen su límite.
Rutas de aprendizaje
