Revisión de código con IA: Anthropic dice que nadie necesita entender todo Claude Code, y los ingenieros ya lo ponen a prueba

Cuando una IA escribe el 90% de tu producto, ¿quién necesita entenderlo? Anthropic responde que nadie. La compañía publicó cómo el equipo de Claude Code gestiona la revisión de código con IA ahora que Claude escribe aproximadamente el 90% de su propio código. La frase que más debate genera no es esa cifra, sino esta: «Nadie en el equipo mantiene un modelo mental completo de Claude Code en su cabeza, y no creemos que nadie lo necesite».

El contexto explica la urgencia. Según el artículo de InfoQ, el monorepo de Anthropic pasó de unos 2.500 cambios fusionados al día en mayo a más de 30.000 en septiembre. Tanto que la empresa ya había reemplazado git por un sistema propio, y la revisión fue lo siguiente en romperse. El objetivo declarado es que la mayoría de los pull requests se fusionen con, como máximo, una persona en el circuito (que puede ser el propio autor) y sin aumento de reversiones ni incidentes. Cuando alguien necesita entender una parte del código, le pide a Claude un «explicador» de ese fragmento, que tarda minutos y refleja el código tal como está hoy.

Cómo funciona la revisión de código con IA por niveles de riesgo en Claude Code

El mecanismo central es un clasificador que asigna un nivel de riesgo a cada cambio. La regla es que «el cambio fija el nivel, no el autor»:

Riesgo bajo (documentación, textos, cambios aditivos tras una bandera de funcionalidad): se aprueban sin intervención humana.

Riesgo medio (caché, el actualizador automático, prompts de sistema): requieren al menos una persona.

Dos reglas fijas: la aprobación de un agente nunca cuenta como la de una persona, y quien dio la instrucción para el cambio cuenta como uno de los revisores exigidos.

El equipo también documenta fallos concretos. Un pull request de la CLI pasó por más de cincuenta rondas de revisión y corrección durante una noche, hasta que su autor lo detuvo. Un humano ignora una nimiedad en segundos, pero un agente la corrige y genera otro commit y otra ronda. Tras ejecutar git blame, descubrieron que cerca del 59% de lo que el revisor marcaba era código presente desde su primera pasada: no encontraba bugs nuevos, sino unos cuantos viejos más en cada ronda. La solución fue limitar las rondas. En Reddit, un usuario contó que llegó al mismo control por su cuenta: se detiene tras dos arreglos fallidos, porque repetir el fallo indica que la imagen que el agente tiene del código es errónea.

La admisión más reveladora es que todavía no existen «cortacircuitos» que endurezcan la aprobación cuando las métricas empeoran. Los propios ingenieros los quieren antes de llevar más código a fusiones sin humanos.

Las críticas: qué se pierde sin un modelo mental

En Hacker News, el comentarista jonahx señaló el precio del enfoque: si el sistema falla con un bug crítico, no hay nadie con un modelo causal en la cabeza para depurar con método. El nuevo modelo de confianza es que Claude siempre entenderá el sistema lo suficiente. Hubo además un caso incómodo en el repositorio público de Claude Code. Una respuesta generada con el modelo describió mal cómo se gestionan los issues, y el desarrollador marcindulak contó más de 6.000 issues con pasos de reproducción que se cerraron igualmente por inactividad. Otros lectores plantearon preguntas sin respuesta: si los cambios a CLAUDE.md, el archivo que el revisor carga en cada revisión, cuentan como «documentación» de riesgo bajo, y cómo encaja el enfoque con auditorías SOC 2 que exigen una segunda persona.

También hubo defensores. El comentarista cheema33 recordó que en las grandes organizaciones nadie ha tenido nunca el modelo completo, y markbao dijo gastar unos pocos miles de dólares al mes en revisión con IA frente a una revisión humana que consume hasta un tercio del tiempo de un ingeniero. El producto ya es público: Code Review para Claude Code está disponible en los planes Team y Enterprise, y la revisión de seguridad corre como una GitHub Action de código abierto que advierte que «no está reforzada contra ataques de inyección de prompts» y solo debe usarse con PRs de confianza.

Qué puedes aplicar en tu empresa

La lección no es «quita a los humanos», sino diseñar dónde importan. Esto encaja con lo que mostró Spotify al duplicar sus cambios de código: escribir dejó de ser el cuello de botella y lo es la revisión. Para tu organización:

1. Clasifica por riesgo, no por autor. Define qué cambios son seguros sin aprobación humana y cuáles no. Empieza con una lista corta y conservadora.
2. Pon un tope a las rondas. Dos intentos fallidos de un agente deberían escalar a una persona, no repetirse cincuenta veces.
3. Nunca cuentes la aprobación de un agente como humana en cambios sensibles ni en entornos regulados.
4. Instala cortacircuitos antes de ampliar la autonomía. Mide reversiones, incidentes y rondas por PR, y define umbrales que endurezcan la aprobación automáticamente.
5. Trata los archivos de instrucciones como código de producción. Un cambio en el contexto de un agente puede alterar su comportamiento sin tocar la aplicación.
6. Conserva el conocimiento causal. Si el sistema se rompe de una forma que ningún explicador resuelve, necesitas personas capaces de razonarlo. Casos como el de Tenex, que guarda cada decisión en Git para que los agentes no pierdan el hilo, muestran una vía para mantener esa memoria.

Por último, evalúa el agente igual que evalúas el código. Los errores de criterio tienen consecuencias reales, como en el agente de AWS que confundió $410 con $410 millones.

La pregunta para tu equipo

Anthropic opera hoy en el extremo del espectro y es honesta sobre lo que le falta. Si tu empresa adopta la revisión de código con IA, la pregunta no es cuánta autonomía darle, sino qué señales te dirán a tiempo que debes quitársela. ¿Sabrías detectar hoy que tus agentes empiezan a degradar la calidad antes de que lo haga un incidente?