Claude escribe el 80% del código de Anthropic: dónde está ahora tu cuello de botella
Anthropic confirma que Claude lidera el 26% de su I+D y escribe más del 80% de su código. Qué cambia para quien construye software: la revisión como cuello de botella, los tests como red de seguridad y las especificaciones como nuevo trabajo de programar.
El 12 de septiembre de 2026, Dario Amodei publicó “We Must Pace the Frontier”, un ensayo de unas 3.900 palabras en el que pide a la industria frenar el ritmo al que mejoran los modelos. Sam Altman y Elon Musk lo respaldaron esa misma jornada y, el 15 de septiembre, OpenAI confirmó que llevaba semanas hablando de seguridad con Anthropic y con Google DeepMind.
La parte que afecta a quien construye software no es el llamamiento: son los números que lo acompañan. El 17 de septiembre, Anthropic publicó datos internos. Claude ya lidera el 26% de la investigación y el desarrollo de sus propios modelos, y más del 80% del código que entra en su repositorio lo escribe el propio Claude. En el segundo trimestre de 2026, un ingeniero suyo fusionaba ocho veces más código al día que en 2024.
Son cifras de parte, y la propia Anthropic avisa de que contar líneas de código premia la cantidad sobre la calidad. La dirección, aun así, es difícil de discutir.
El cuello de botella se ha mudado
Durante veinte años, la parte cara de hacer software era escribir. Con agentes capaces de trabajar en horizontes largos, el código aparece solo y lo que escasea es la capacidad de revisarlo con criterio. Cuando el volumen generado crece, la restricción deja de ser cuánto produces y pasa a ser cuánto puedes leer, entender y aceptar en un día.
Si eso es cierto en tu equipo, organizarse alrededor de la escritura ya no tiene sentido. Organízate alrededor de la verificación.
Tus tests son ahora el producto
Si buena parte del código no sale de tus dedos, tu red de seguridad deja de ser tu cabeza y pasa a ser la suite de tests, el tipado y el pipeline. Un modelo escribe una función con la misma seguridad cuando acierta que cuando se equivoca: no hay titubeo que te avise. Lo que te avisa son las pruebas.
Antes de gastar una tarde afinando prompts, gástala en tests sobre el camino crítico y en un CI que no deje fusionar en rojo. Con más volumen, la tentación de saltarse el rojo es real.
Especificar es el nuevo programar
Un agente resuelve bien un problema bien planteado y resuelve mal uno mal planteado, sin distinguir entre ambos. El trabajo se desplaza a escribir el enunciado: qué tiene que pasar, con qué entradas, qué no puede romperse y cómo se comprueba.
En la práctica, esto se parece mucho a lo que ya hacías con un júnior competente pero sin memoria: escribir la tarea en el ticket, con criterios de aceptación, en vez de explicarla de viva voz. La diferencia es que aquí el júnior no recuerda nada de la sesión anterior.
El contexto del proyecto es infraestructura
Un agente rinde según lo que sabe de tu código. Lo que sabe es lo que le has dejado leer: convenciones escritas en el repositorio, un fichero de instrucciones para el asistente, un README que no miente y una arquitectura que se entiende sin preguntar. Diez minutos poniendo por escrito tus reglas de estilo y de estructura se pagan solos en la primera semana; cada vez que las explicas en un chat, las pierdes.
Lo que no cambió el 12 de septiembre
Ninguna API, ningún precio y ningún roadmap. El compromiso firme de todo aquello fue meter evaluadores externos en el laboratorio; lo demás son propuestas. No reorganices tu empresa por un ensayo. Reorganízate por los números.
Para las siguientes cuatro semanas, tres cosas concretas:
- Mide cuánto código generado apruebas por hora y cuánta revisión real le haces. Esa cifra es tu nuevo techo.
- Cubre con tests el camino crítico antes de ampliar el uso de agentes a más partes del sistema.
- Escribe las convenciones del proyecto donde el agente las pueda leer, no donde tú las recuerdas.
El titular de la semana parece hablar del fin del mundo. El trabajo real está en el punto uno.