La era de los agentes requiere software extremadamente robusto
Las personas usan las aplicaciones a ritmo de humano: abren una página, pulsan un botón, esperan una respuesta y deciden qué hacer después.
Un agente puede hacer varias llamadas a una API, lanzar subagentes en paralelo, revisar sus resultados y repetir el ciclo antes de que quien lo usa termine de leer la primera respuesta. Para los servicios que atienden esas llamadas, esto implica más peticiones que llegan en ráfagas más pronunciadas y con mayor concurrencia.
En la era de los agentes, es fácil someter a los sistemas a un tráfico para el que quizá nunca se diseñaron.
GitHub es probablemente el ejemplo más claro de un servicio ya afectado por este tipo de carga.
GitHub
GitHub ha tenido problemas de disponibilidad a medida que las herramientas de agentes han crecido con fuerza. Su CTO escribió en abril que el equipo había pasado de planificar un aumento de capacidad de 10x en octubre a diseñar para 30x de aumento en febrero.
El COO de GitHub proyectó un ritmo anualizado de 14 mil millones de commits para 2026, frente a mil millones en 2025. Este crecimiento no se limita a los commits, pues también incluye la creación de repositorios, pull requests, uso de la API y ejecuciones de CI, que los agentes pueden generar mucho más rápido que las personas.
Esto ha provocado problemas de fiabilidad repetidos, algunos vinculados directamente al rápido crecimiento de la actividad agéntica. Han afectado servicios centrales y han reducido mucho la confianza de algunos desarrolladores en la plataforma.
Los agentes cambian cómo llega la carga
Sam Altman explicó recientemente la escala de este cambio de una forma útil. En 2020, la persona que más tokens consumía en OpenAI usaba unos 100k al mes, una cifra que entonces parecía absurda. Ahora sitúa la media mundial aproximadamente en esa misma cantidad, mientras que quien más usa tokens en OpenAI consume cientos de miles de millones cada mes. El número de tokens es una métrica imperfecta, pero muestra por qué las previsiones basadas en uso histórico e interacción humana ya no son del todo fiables.
Los agentes cambian más cosas que el número de peticiones. Cuando una persona abre un pull request, normalmente espera al CI y a la revisión de sus compañeros antes de actuar de nuevo. Un agente puede crear varios a la vez, pedir a otros agentes que los revisen, comprobar los resultados, hacer cambios y repetir el ciclo. Una tarea que antes implicaba unos pocos pasos ahora puede generar mucho trabajo en distintos servicios.
Esto se vuelve más peligroso cuando algo falla. Los agentes suelen reintentar hasta obtener una respuesta, así que un fallo pequeño puede generar rápidamente todavía más tráfico.
Preparar los límites antes de necesitarlos
No todos los proyectos necesitan prepararse para millones de usuarios, pero deberían plantearse qué ocurre cuando un cliente automatizado envía mucho más tráfico de lo esperado. Las acciones importantes deberían poder repetirse sin problemas, y el servicio debería poder ralentizar a los clientes, encolar el trabajo o rechazarlo claramente cuando esté bajo presión.
La monitorización y las pruebas también deberían cubrir este tipo de tráfico. Es útil saber qué agente está haciendo las llamadas, con qué frecuencia reintenta y si el trabajo se está acumulando, y probar qué ocurre cuando varios agentes intentan lo mismo a la vez.
La facilidad para producir software ha aumentado la necesidad de diseñarlo bien.