Hemos dicho antes que Claude escribe alrededor del 90 por ciento del propio código de Claude Code. Entonces, ¿cómo revisamos código al volumen que lo producimos? ¿Todavía alguien lee el código? Y si algo se rompe, ¿quién lo detecta? Esta publicación explica el flujo de revisión de código del equipo de Claude Code y cómo ha evolucionado. De junio a septiembre, las pull requests fusionadas en la base de código de Claude Code más que se duplicaron, mientras que la proporción que tuvo que revertirse bajó más de un 40 por ciento. No eliminamos la revisión. Pero trasladamos la mayor parte de la lectura a las máquinas, optimizada para el tiempo y la atención humanos, e invertimos mucho en hacer rápido y sencillo deshacer los errores.
Cuando los agentes escriben código, el número de cambios aumenta rápidamente. En el monorepo de Anthropic, los cambios integrados por día pasaron de unos 2.500 en mayo a más de 30.000 en septiembre de este año. Claude Code vive en su propio repositorio, separado del monorepo, pero también recibe mucha presión. Cuando se envía tan rápido, la revisión manual, línea por línea, es enormemente difícil, por no decir imposible. La revisión de código cumple dos funciones: encontrar y corregir problemas antes de publicar, y construir contexto compartido y comprensión de la base de código en todo el equipo. Este artículo se centra sobre todo en encontrar y corregir problemas, pero volveremos a la segunda función al final.
Creemos que "¿lo leyó una persona?" es un indicador impreciso de "¿qué podría salir mal con este cambio, y qué comprobación, automatizada o humana, es la adecuada para detectarlo?". Plantearse esa pregunta también cambió cuándo ocurre la revisión. Antes, la revisión era una puerta al final del camino: escribir el código, abrir una PR y esperar a un compañero. Ahora la revisión se ejecuta continuamente, más como el corrector ortográfico mientras escribes. La mayoría de los cambios ya han sido revisados y corregidos por Claude al menos una vez antes de pedir a una persona que los mire. Esto detecta la mayoría de los errores rutinarios y reserva la atención del equipo para preguntas de nivel superior y para un escrutinio más profundo.
El recurso escaso: el tiempo y la atención humanos. Queremos preservar el tiempo y la atención humanos para los problemas que solo las personas pueden resolver, y asegurarnos de que las comprobaciones automatizadas detecten el resto. Al ritmo actual de cambios, todavía hay una cantidad increíble de trabajo para las personas, y nuestro equipo se encuentra casi a diario con desafíos nuevos e inéditos. El tiempo humano abarca ambos lados del coste de la revisión: el tiempo que las personas dedican a revisar y el tiempo que dedican a arreglar lo que el código defectuoso rompe. Reducir lo primero no sirve de nada si el tiempo simplemente reaparece en lo segundo. Por eso, el objetivo es que la mayoría de las pull requests de los repositorios de Claude Code (la CLI, las aplicaciones de escritorio y web, y las aplicaciones móviles) se fusionen con como máximo una persona en el proceso, que puede ser el autor, sin aumentar las reversiones ni los incidentes. Para medir el tiempo humano, registramos las aprobaciones humanas por PR (mediana y percentil 95), los comentarios humanos y cuánto tiempo espera una PR a que alguien la atienda. Las tasas de reversión e incidentes son la salvaguarda: si suben, no hemos ahorrado tiempo humano, solo lo hemos desplazado.
La vida de un cambio. Un cambio típico, desde el portátil de un ingeniero (o una sesión de Claude en Slack), atraviesa varias capas de revisión de código. La mayor parte del recorrido está automatizada; la atención de una persona se dirige allí donde está el riesgo. Capas, no una única puerta: seis niveles de comprobaciones, con la reversión como red de seguridad. Cada capa detecta algunos problemas y se le escapan otros. Pocos atraviesan todas, y la reversión se encarga del resto. 1. El trabajo se verifica antes de que nadie más lo mire. Hoy la mayor parte de la revisión ocurre antes de que exista una PR. Le damos a Claude algo que puede ejecutar, como pruebas, una compilación o una captura de pantalla para comparar con el diseño, y le pedimos que muestre el resultado en lugar de decir que ha terminado. Luego, un subagente revisa el diff con contexto nuevo. Ambos hábitos vienen de nuestra guía de buenas prácticas. Antes de abrir una PR, muchos de nosotros también ejecutamos algunas habilidades internas: una busca errores, otra simplifica el diff y otra comprueba el comportamiento de extremo a extremo. Los cambios de interfaz también se revisan frente a nuestras pautas de diseño.
Fuente: Hacker News · Resumido por HeadlinesBriefing