Anthropic publicó el 14 de septiembre una entrada en su blog de ingeniería. Su autor, Sachin Malhotra, relata cómo un servicio interno de la empresa quedó desbordado y tuvo que reescribirse desde cero. El servicio se llama test impact analysis (análisis de impacto de pruebas) y su función es bastante simple: cada vez que entra un cambio de código, decidir qué pruebas deben ejecutarse y cuáles pueden omitirse. Suena a un componente de trasfondo, pero el motivo por el que no aguantó resulta bastante representativo.
Primero, algunos múltiplos
El primer conjunto de cifras del artículo es del lado de la producción: los ingenieros de Anthropic ahora entregan, en promedio, 8 veces más código por trimestre que en el periodo 2021-2025, y el 80% de ese código lo escribe Claude, que además asume gran parte de la revisión y aprobación de pull requests.
El segundo conjunto de cifras es del lado de la presión: el total de pruebas en el repositorio se multiplicó por 10, y el número de tareas de CI aumentó 25 veces en seis meses.
El tercer conjunto de cifras es el que mejor ilustra el ritmo de la situación. Para aguantar la carga, el equipo desplegó tres rondas de solución temporal, que compraron, respectivamente, 70 días, 29 días y menos de 1 día de margen. La tercera solución se agotó el mismo día de su lanzamiento.
Dónde se atascaba el servicio antiguo
La arquitectura anterior tenía un listener de proceso único que debía escribir el resultado de cada prueba en el almacenamiento en orden secuencial. Una sola vía de escritura significa que no se puede escalar horizontalmente, y en cuanto la velocidad de llegada de pull requests superaba la capacidad de procesamiento, la cola empezaba a acumularse. La frase textual del artículo es que el listener "starts to increasingly fall behind the PR queue" (empieza a quedarse cada vez más atrás respecto a la cola de PR).
El retraso traía consecuencias en cadena. El ejemplo que da el artículo es que un retraso de 20 minutos equivalía a decenas de miles de actualizaciones de resultados de pruebas aún sin guardar en el almacenamiento. Y como la selección de pruebas se basa precisamente en resultados históricos, un historial impreciso hace que el conjunto de pruebas elegido no sea confiable. Para colmo, ese proceso también tenía una fuga de memoria y llegaba a su límite todas las tardes.
En qué se convirtió
La idea de la reescritura fue sacar el estado del proceso. La nueva arquitectura introduce un almacén de datos en memoria: cualquier worker del listener puede procesar cualquier resultado, su única tarea es añadirlo a un registro, sin guardar estado propio, lo que permite sumar máquinas según haga falta. Además hay un proceso consumidor independiente que, cada pocos segundos, condensa el registro en un historial organizado por prueba individual. Cuando el selector necesita decidir, consulta directamente ese historial.
El precio de esto fue un aumento de costos. El artículo lo reconoce, y lo justifica por la escalabilidad y la observabilidad obtenidas: ahora se puede medir por separado qué etapa va lenta y en qué punto exacto. Todo el rediseño lo hizo un solo ingeniero en tres semanas.
Esa curva del 25 veces
Un crecimiento de 25 veces en seis meses equivale a una tasa de crecimiento compuesto mensual de aproximadamente 1,71 veces (cálculo aproximado: raíz sexta de 25). Si se proyecta esa pendiente seis meses más, se llega a 625 veces. La frase final del autor, "always plan for the exponential" (siempre hay que planear para lo exponencial), no es retórica: corresponde a una curva que ya se ha medido.
Esta extrapolación, por supuesto, no es fiable: la tasa de crecimiento puede cambiar de rumbo por políticas internas, cuotas o cambios en los hábitos de ingeniería. Anthropic tampoco ha publicado la cifra absoluta de su factura de CI, no ha dicho qué proporción de las pruebas logra filtrar el nuevo servicio, y mucho menos ha dado cifras de la latencia después de la reescritura. Cuánto dinero se ahorró es algo que no se puede deducir de la información pública.
Aun así, queda claro por dónde va pasando la presión de una etapa a otra. En abril de este año, GitHub dejó de aceptar nuevas suscripciones a los planes individuales de pago de Copilot, alegando que el consumo de cómputo de las tareas largas de agentes superaba lo que esos planes estaban diseñados para soportar; antes de eso, una oleada de commits generados por IA ya había provocado fallos en GitHub, y Microsoft llegó a pedir prestada capacidad a AWS para aguantar. Son tres episodios de forma distinta, pero apuntan a lo mismo: la generación de código se acelera primero, luego la revisión, y después, uno a uno, cada sistema dimensionado para la velocidad de programación humana va siendo golpeado. El análisis de impacto de pruebas es solo la primera alarma de esta ronda.
Fuentes: CocoLoop, blog de ingeniería de Anthropic; los múltiplos de volumen de código, pruebas y tareas de CI, así como la duración de las tres soluciones temporales, se tomaron de las cifras publicadas en ese artículo.