El 17 de agosto, GitHub sufrió una de las peores caídas de su historia. Durante casi ocho horas fallaron servicios críticos como Actions, la API, la autenticación de Copilot y el inicio de sesión de miles de empresas. El colapso dejó a millones de desarrolladores de brazos cruzados.

Ese mismo día, Cursor —el editor de código de SpaceX— lanzó Origin, su propia plataforma para alojar repositorios. La coincidencia alimentó las bromas sobre el monopolio de Microsoft. Sin embargo, la causa real de la caída muestra un problema de fondo más grave. La plataforma no pudo escalar ante la carga de tráfico de las últimas semanas.

La infraestructura de la nube, diseñada para el ritmo de trabajo de los humanos, está chocando con el volumen de tráfico que generan los agentes autónomos de desarrollo.

El día en que la nube se quedó sin espacio para escalar

El postmortem oficial de GitHub confirma que la caída no la causó un error de código. Fue un fallo de capacidad. Los sistemas de autoescalado no respondieron rápido ante un pico de tráfico, bloqueando los servicios de autenticación.

Al fallar la conexión, editores de código como VS Code y Copilot multiplicaron por diez sus peticiones. Cada reintento automático saturó los balanceadores de carga de la plataforma. Mientras el equipo de ingeniería intentaba resolverlo, miles de bots de scraping seguían descargando código de forma automática.

Aunque GitHub añadió tres millones de núcleos de CPU y 120 petabytes de almacenamiento este año, no fue suficiente. Su CTO admitió que ahora necesitan planificar la infraestructura para soportar treinta veces el tráfico actual, no solo diez.

La ironía es clara. GitHub, impulsor de Copilot, es la primera víctima de la carga de datos de esa misma automatización.

La explosión de datos: los agentes no necesitan dormir

Las cifras de actividad de la plataforma en los últimos meses muestran este cambio:

• los commits mensuales se duplicaron en cuatro meses, de 10.000 millones en abril a casi el doble en agosto;
• las pull requests (PR) mensuales pasaron de 25 millones en 2023 a más de 130 millones;
• y las ejecuciones semanales de GitHub Actions subieron de 15 millones a principios de año a 115 millones.

Los desarrolladores humanos no nos hemos multiplicado. La diferencia es que ahora trabajamos junto a agentes de IA que abren PRs y ejecutan pruebas sin parar. El tráfico humano sube de día y baja de noche, lo que permite el autoescalado de los servidores. Los agentes, en cambio, operan las 24 horas del día a gran velocidad.

El auge del código basura: spam, malware y la crisis del open source

Más código no significa mejor software. Gran parte de este tráfico es lo que llamamos “código basura” o AI slop. El problema se divide en tres frentes:

1. El spam industrial

GitGuardian rastreó una campaña de 40 millones de commits falsos diseñados para promocionar webs de apuestas ilegales. En las horas de mayor tráfico, el 70% de los eventos públicos de GitHub eran spam. Esta basura infla las métricas de uso de la plataforma.

2. El “agenting” y los repositorios maliciosos

La firma Fake Git detectó más de 7.000 repositorios falsos que se hacían pasar por herramientas útiles o servidores MCP (Model Context Protocol). Cuando un agente busca resolver una tarea para el usuario, lee la documentación falsa. Al creerla legítima, instala malware de forma automática.

3. La crisis del código abierto y la pérdida de confianza

Los mantenedores de proyectos de código abierto están saturados. Reciben docenas de PRs automáticas de IA que prometen arreglar fallos, pero que contienen código inservible. El esfuerzo cognitivo de revisar y descartar estas peticiones recae en los humanos.

La trampa del coste asimétrico: generar es gratis, evaluar es carísimo

Detrás de todo esto hay una asimetría muy simple:

[!IMPORTANT] Para un agente de IA, escribir mil líneas de código o enviar una docena de pull requests no cuesta nada. Para un programador humano, entender, compilar y validar ese código requiere tiempo y esfuerzo.

Esta asimetría rompe el modelo de confianza del desarrollo de software. Para cuidar la calidad, GitHub limitó las PRs por usuario en junio de 2026. También empezó a etiquetar el código de baja calidad. Es revelador que una plataforma creada para compartir código deba diseñar herramientas para restringir la colaboración y proteger a sus mantenedores.

Qué podemos hacer: purificadores, filtros y el valor de los fundamentos

Para evitar que el código basura sature los repositorios, debemos cambiar la forma en que usamos la IA. No sirve de nada pulsar un botón y aceptar la propuesta del asistente sin analizarla. Necesitamos establecer filtros claros:

• usar “purificadores” o agentes de validación intermedios que limpien el código generado antes de que llegue a las ramas principales;
• configurar suites de pruebas y linters estrictos que actúen como primera barrera contra las líneas redundantes;
• limitar la autonomía de los agentes en producción, manteniendo un humano a cargo de revisar las decisiones del bot;
• y recordar que las plataformas en la nube pueden caer, pero el conocimiento del sistema de control de versiones reside en ti.

Git es una herramienta local que funciona sin conexión a internet. La saturación de los servidores externos es un aviso: no delegues tu criterio en manos de agentes automáticos. La IA ayuda, pero la responsabilidad final de la calidad del código sigue siendo del programador.

---

Este artículo está basado en el videoblog de Brais Moure (MoureDev).