Anthropic afirma que Claude Code ya escribe cerca del 90% de su propio código y que el equipo está cambiando la forma de revisar ese trabajo. En una publicación, Addy Osmani, Morgan Westlee Lunt y Qing Wang describen un objetivo: que la mayoría de las solicitudes de cambios se fusionen con la participación de, como máximo, una persona, que incluso podría ser quien escribió el cambio, sin que aumenten las reversiones ni los incidentes.
El equipo dice que quienes revisan no necesitan tener un modelo mental completo de Claude Code. En cambio, le piden a Claude que explique la parte de la base de código que necesitan entender. El enfoque recibió críticas en un debate en Hacker News: algunos participantes cuestionaron si depender de explicaciones de IA significa que nadie podrá depurar un fallo cuando la comprensión del modelo sea incorrecta.
Cómo funcionan los filtros de revisión
Un clasificador asigna a cada cambio un nivel de riesgo según el propio cambio, no según quién lo haya escrito. Los cambios de bajo riesgo incluyen documentación, textos y funciones incorporadas detrás de una bandera de funcionalidad; pueden aprobarse sin autorización humana. Los cambios de riesgo medio, entre ellos los relacionados con el almacenamiento en caché, el actualizador automático y los mensajes del sistema, requieren la aprobación de una persona. La aprobación de un agente no cuenta como aprobación humana, pero quien solicitó un cambio sí puede contar como el revisor requerido.
El proceso de revisión tiene su propio modo de fallo: los agentes actúan sobre comentarios que una persona quizá pasaría por alto. Anthropic describe una solicitud de cambios que pasó por más de 50 rondas de revisión y correcciones durante la noche, antes de que su autor la detuviera. El equipo afirma que limitó el número de rondas tras descubrir que hacer más revisiones solo empeoraba las cosas. También observó que cerca del 59% del código señalado en rondas posteriores ya estaba presente cuando el revisor lo examinó por primera vez.
Qué sigue sin estar claro
Otro ejemplo, tomado del repositorio público de Claude Code, muestra los límites de las explicaciones generadas. En agosto, una respuesta generada por Claude dijo que se habían cerrado incidencias por inactividad cuando faltaba información necesaria para reproducir un problema. Sin embargo, las reglas del repositorio permiten cerrar incidencias después de 14 días con la etiqueta de obsoleta y otros 14 días, salvo que tengan al menos 10 votos positivos. Un desarrollador contó más de 6.000 incidencias etiquetadas como si incluyeran pasos para reproducir el problema que, aun así, seguían cerradas por inactividad. La sugerencia de la respuesta de dejar un comentario para reabrir una incidencia también chocó con un flujo de trabajo que bloquea las incidencias cerradas después de siete días.
Anthropic afirma que todavía no cuenta con mecanismos de seguridad que endurezcan los requisitos de aprobación si empeoran sus métricas de revisión. Su producto Code Review está disponible de forma general en los planes Team y Enterprise. La GitHub Action de revisión de seguridad es de código abierto, pero su README advierte que no está protegida contra la inyección de instrucciones y que solo debe usarse para revisar solicitudes de cambios de confianza.
Por qué importa
Para los equipos que estén considerando la revisión de código dirigida por IA, el proceso de Anthropic muestra que los cambios de bajo riesgo pueden fusionarse sin aprobación humana, mientras que los de riesgo medio siguen requiriendo la intervención de una persona. La empresa afirma que no ha creado mecanismos de seguridad para endurecer las aprobaciones cuando empeoran las métricas de revisión, por lo que la publicación no aclara cómo respondería el proceso si sus salvaguardas empezaran a fallar.
