Hay una frase que hace unos años habría sonado a truco publicitario. Según Anthropic, Claude ya escribe cerca del 90 por ciento del código de Claude Code, la propia herramienta de programación de la compañía. La cifra procede de un relato publicado el 16 de octubre de 2026 por miembros del equipo de Claude Code, Osmani, Lunt y Wang, donde describen cómo construyen el producto en su día a día. Simon Willison destacó el texto ese mismo día. La herramienta, en gran parte, se está construyendo a sí misma.
El número grande se lleva la atención. El cambio más callado que hay debajo importa más. La revisión de código, dice el equipo, ya no se sienta al final del proceso como un profesor que corrige un examen después de clase. Funciona de forma continua, mientras se escribe el código, más cerca de un corrector ortográfico que de una inspección formal. La mayoría de los cambios, informa el equipo, los revisa y corrige Claude antes de que una persona los vea. Conviene leerlo otra vez: la persona ya no es la primera lectora. Es la segunda.
Las cifras detrás de la afirmación
El relato del equipo de Anthropic ofrece dos cifras que dan forma a la historia. Las solicitudes de integración fusionadas, es decir, los bloques de código que de verdad llegan al producto, se multiplicaron por más del doble entre junio y septiembre de 2026. Al mismo tiempo, la proporción de cambios que necesitaron una reversión, es decir, trabajo deshecho después de publicarse, cayó más de un 40 por ciento. Esas dos cifras van juntas. Que llegue más código no impresiona por sí solo, porque cualquiera puede entregar más rápido si baja el listón. Lo que el equipo afirma es rapidez y una tasa de error menor a la vez, que es el truco difícil. Si se fusiona el doble de cambios y una parte menor regresa, algo en el proceso mismo ha cambiado, no solo el ritmo.
Ayuda situar esto junto a otros trabajos recientes sobre fiabilidad. Cuando un laboratorio logra que un sistema cometa menos errores y lo mide con cuidado, la historia real no es la potencia bruta. Es el control del error. La programación se dirige hacia esa misma puerta. La pregunta ya no es quién o qué escribió la línea. Es con qué rapidez se caza un error y qué tan cerca del momento de escribirlo ocurre esa caza.
La revisión se metió dentro de la escritura
La revisión tradicional de código tiene un ritmo que la mayoría de los programadores conoce de memoria. Escribes durante horas, a veces días. Abres una solicitud de integración. Un colega la lee después, cansado, ocupado y saltando desde su propio trabajo, y deja comentarios. Corriges, esperas, corriges otra vez. El ciclo puede alargarse una semana, y para cuando aparece un problema real, quien escribió el código ya olvidó a medias por qué tomó la decisión que se cuestiona.
La revisión continua rompe ese ritmo. Si Claude lee cada cambio en cuanto aparece, señala una suposición frágil en el acto y sugiere una corrección mientras el razonamiento aún está fresco, la revisión deja de ser una puerta y se convierte en parte del acto de escribir. La comparación con el corrector ortográfico que hace el equipo es acertada. Nadie envía una carta y después pide a un amigo que revise la ortografía. El subrayado rojo aparece mientras las manos siguen en el teclado. Ese es el modelo que ahora se aplica al software, con la diferencia de que el subrayado también puede explicarse y proponer la corrección.
Esa obsesión por revisar mientras se crea conecta con la cultura de comprobación que Revista Minutos valora en otros campos, como en los proyectos de largo recorrido celebrados en Montecarlo. En tecnología como en ciencia, revisar pronto sale más barato que corregir tarde.
Lo que la persona sigue haciendo
Nada de esto saca a las personas del proceso, y el relato del equipo no afirma que lo haga. Una persona sigue decidiendo qué debe hacer el producto, sigue mirando después de que Claude haga su pasada y sigue cargando con la responsabilidad de lo que se publica. El gusto, el criterio y el sentido de producto, llámalo como quieras, no se han automatizado hasta desaparecer. Lo que ha cambiado es el orden de las operaciones.
Ese matiz importa para cualquier equipo que esté pensando en copiar el método. La ganancia no viene de quitar lectores humanos. Viene de mover la primera lectura, la más mecánica y la más repetida, al momento en que corregir cuesta menos. La segunda lectura, la humana, llega entonces con menos ruido y con la atención puesta en las decisiones que de verdad necesitan juicio.
Qué vigilar ahora
Quedan preguntas abiertas y conviene no esconderlas. ¿Se mantienen esas tasas cuando el código toca zonas más delicadas del producto? ¿Cómo decide el equipo qué cambios necesitan una revisión humana más larga? ¿Y qué pasa con los errores que el propio modelo no sabe que comete? El relato publicado da cifras de velocidad y de reversiones, que son un buen comienzo, pero la confianza a largo plazo pedirá ejemplos concretos y seguimiento en el tiempo.
Aun con esas cautelas, el mensaje central se sostiene. Un equipo de software afirma, con números, que su herramienta de inteligencia artificial ya escribe la mayor parte de su propio código y que revisar dejó de ser una etapa separada para volverse un hábito continuo. Si otros equipos confirman resultados parecidos, la forma de construir programas cambiará menos por un gran salto y más por este cambio silencioso en el orden de lectura. Primero la máquina, en el momento. Después la persona, con criterio. Y el código, mientras tanto, sigue llegando el doble de rápido y volviendo atrás menos veces, que es justo el tipo de progreso que se puede medir. Historias así, con cifras y método, son las que Revista Minutos seguirá contando junto a otras de trabajo bien hecho, como el reconocimiento a las nuevas enfermeras de Suecia.
Sé el primero en comentar