¿Quién lee el código cuando la IA escribe el 90%?
El equipo de Claude Code afirma que Claude escribe cerca del 90% del código de su propio producto. Aun así, entre junio y septiembre los pull requests mergeados en ese repositorio más que se duplicaron, y la proporción de cambios que hubo que revertir cayó más del 40%. La pregunta que el equipo se hace en su blog es la que cualquier CTO debería hacerse: si nadie lee línea por línea, ¿quién atrapa el bug?
La respuesta no es «nadie». Es que la revisión dejó de ser una puerta al final del camino y ahora corre de forma continua, más parecida al corrector ortográfico mientras escribes que a la espera del compañero de equipo.
El contexto de escala explica por qué. En el monorepo de Anthropic, los cambios que aterrizan por día pasaron de unos 2.500 en mayo a más de 30.000 en septiembre. Con ese volumen, la revisión manual línea por línea es directamente imposible.
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 días¿Cómo funciona la revisión de código con agentes?
El equipo lo resume así: la pregunta correcta no es «¿un humano leyó el código?», sino «¿qué puede salir mal con este cambio y qué control —automático o humano— es el indicado para atraparlo?».
Esa reformulación cambió tres cosas:
- Cuándo se revisa. La mayor parte de la revisión ocurre antes de que exista un PR. Se le da a Claude algo que pueda ejecutar —tests, un build, una captura contra la que comparar el diseño— y se le pide que muestre el resultado en lugar de decir que terminó. Después, un subagente revisa el diff con contexto fresco.
- Quién revisa primero. Todo pull request pasa por una revisión de Claude antes de que lo vea una persona. El revisor lee el diff contra todo el repositorio y contra la intención declarada del PR.
- Cómo se verifican los hallazgos. Varios agentes buscan bugs en paralelo y un grupo separado vota cada hallazgo: solo se publica si suficientes coinciden en que es real. Los comentarios que son solo estilo, diagnósticos o limpieza se descartan. Lo que queda aparece como comentario inline etiquetado como Important, Nit o Pre-existing, para que un bug que el PR no introdujo no parezca culpa del autor.
El impacto fue medible: cuando el equipo lanzó la research preview, la proporción de PRs internos que recibían comentarios sustantivos de revisión pasó del 16% al 54%. La mayoría de los PRs de más de 1.000 líneas reciben hallazgos, y la mayoría de los pequeños vuelven limpios.
Boris Cherny, creador de Claude Code, sostiene que darle a Claude una forma de verificar su propio trabajo es probablemente lo más importante para obtener buenos resultados: estima que mejora el resultado final entre dos y tres veces. Y el producto ya está disponible fuera de casa: Code Review for Claude Code está en disponibilidad general en los planes Team y Enterprise, mientras que el comando /code-review corre una versión más liviana en local.
Los tres niveles de riesgo: no todo cambio necesita un humano
El equipo clasifica cada cambio por riesgo, no por autor. Un clasificador lee el cambio y le asigna un nivel; un segundo clasificador pregunta si ese cambio concreto necesita otra persona incluso cuando su nivel dice que no.
| Riesgo | Ejemplos | Aprobaciones humanas |
|---|---|---|
| Bajo | Documentación, copy, features internas, cambios aditivos detrás de un flag | Ninguna, si la revisión automática y los chequeos de seguridad están en verde |
| Medio | Cambios de producto ordinarios y zonas sensibles como caché, auto-updater o system prompts | Una persona |
| Alto | El código de mayor riesgo y un conjunto de rutas que siempre exigen dos personas | Dos personas |
Dos detalles importan para cualquier equipo. Primero: solo los autores de la lista de confianza del repositorio acceden a las rutas livianas; el resto necesita una segunda persona. Segundo: la aprobación de un agente nunca cuenta como la de una persona. La revisión automática puede liberar un cambio de riesgo bajo, pero no puede ocupar un lugar reservado a un humano.
Y hay una regla que vale oro: quien pidió el cambio queda enganchado a él. En un PR escrito por un agente, la persona que dirigió al agente cuenta como uno de los revisores requeridos, igual que si hubiera tecleado el código. Además, un PR no puede mergear mientras siga abierto cualquier hallazgo de la revisión de bugs o de la revisión de seguridad: se arregla o se cierra el hilo con una razón breve.
El hallazgo incómodo: la revisión que no converge
El equipo documenta un problema que cualquier empresa que use agentes va a encontrar: un autor agente y un revisor agente pueden mantenerse ocupados indefinidamente. Un PR del CLI pasó por más de cincuenta rondas de revisión y arreglos durante la noche antes de que su autor lo detuviera.
Al correr git blame sobre lo que el revisor seguía marcando, encontraron que cerca del 59% era código que ya estaba ahí desde la primera pasada. El revisor casi no encontraba bugs nuevos: encontraba unos pocos viejos más en cada ronda.
La lección es contraintuitiva: más rondas de revisión no equivalen automáticamente a más calidad. El equipo ahora mide rondas-hasta-aprobar junto con la tasa de detección, y ajustó su proceso de re-revisión. También convirtió los incidentes pasados en un set de evaluación que el revisor corre a diario.
¿Qué significa esto para tu startup?
No necesitas 30.000 cambios diarios para que este modelo te sirva. La lógica escala hacia abajo con bastante fidelidad.
Primero, separa el riesgo del autor. La mayoría de los equipos pequeños revisa todo con el mismo rasero porque no tiene tiempo de pensar en niveles. Un archivo de configuración y un cambio en el sistema de pagos no deberían costar lo mismo en atención humana. Empieza con tres categorías y una regla explícita para cada una.
Segundo, dale a tu agente algo que pueda verificar. El punto de Cherny aplica igual en una startup de cinco personas: si el agente puede correr los tests, comparar contra un diseño o ejecutar un comando y mostrar la salida, la calidad del resultado sube sin que tú revises nada.
Tercero, mide reverts, no solo velocidad. El equipo de Claude Code usa la tasa de reversiones e incidentes como guardrail explícito: si suben, no ahorraron tiempo humano, solo lo movieron de lugar. Es la métrica que evita que la velocidad se convierta en deuda silenciosa.
Cuarto, cuida el ruido. Un humano descarta un comentario inútil en segundos; un agente lo arregla, lo que genera otro commit y otra ronda de revisión. El ruido cuesta mucho más cuando el autor es un agente.
El mercado ya se movió hacia acá
La revisión de código automatizada dejó de ser un experimento interno. CodeRabbit levantó US$143 millones en una ronda Serie C que la valoró en US$1.500 millones, según Reuters, menos de un año después de su Serie B de US$60 millones. La compañía dice que realiza más de 2 millones de revisiones de código por semana y tiene más de 17.000 clientes, entre ellos Nvidia, BMW, JFrog y Adyen.
La presión no es solo de volumen. Según The Next Web, más del 80% del código que se integra al codebase de producción de Anthropic fue escrito por Claude en mayo de 2026, y Claude Code genera por sí solo 2,6 millones de commits públicos semanales en GitHub, el 4,5% del total. La infraestructura tradicional —control de versiones, builds, colas de merge— fue diseñada para velocidades humanas. Anthropic terminó migrando su repositorio principal a un sistema propio llamado Scion, construido por un equipo de siete ingenieros en cinco meses, según CryptoBriefing, porque su historial de rama principal se acerca a los 100 GB y los jobs de testing hacen unos 25 millones de checkouts por día.
La conclusión: menos lectura, más criterio
El cambio de fondo no es que las máquinas lean el código. Es que el trabajo humano se movió hacia donde las máquinas son malas: decidir qué construir, evaluar el riesgo de un cambio, entender por qué algo se rompió y qué capa debió atraparlo.
El equipo admite que todavía no tiene todo resuelto: no existen circuit breakers que endurezcan las aprobaciones cuando suben los incidentes, y varios ingenieros los quieren antes de mover más código a merges sin humanos. También reconocen que nadie en el equipo mantiene un modelo mental completo de Claude Code, y que no creen que nadie lo necesite: cuando alguien quiere entender una parte del código, le pide a Claude un explicador de esa porción exacta.
Para un founder, la traducción es simple. La revisión de código como ritual de lectura está perdiendo sentido. La revisión como sistema de control de riesgo —con capas, umbrales y métricas de reversión— recién empieza. Y la pregunta que define el diseño no es cuánta gente mira el diff, sino qué capa es la responsable de atrapar cada tipo de error.
Fuentes
- Solving code review at Anthropic (fuente original)
- Anthropic replaces Git with custom source control system Scion
- Anthropic says Claude writes 80% of its own code and the world needs a plan to hit the brakes
- AI code review platform CodeRabbit valued at $1.5 billion in latest funding round
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 días
