Así revisamos código en nuestro equipo, al estilo del equipo de Claude Code

Anthropic contó hace poco cómo revisa el código el equipo de Claude Code: How the Claude Code team does code review. Su objetivo cabe en una frase: dedicar el menor tiempo posible de revisión humana sin aumentar las reversiones ni los incidentes. La revisión ya no es un único filtro antes de fusionar. Las comprobaciones automáticas se ejecutan durante todo el proceso, y la atención humana se reserva para las partes de riesgo.

Nos sentimos muy identificados. Somos un equipo de ingeniería de poco más de diez personas y llevamos más de un año persiguiendo lo mismo: poner el esfuerzo humano donde de verdad hace falta y dejar el resto a la IA. La herramienta con la que lo conseguimos es HeyDeer, el servicio de revisión de código con IA que creamos nosotros. A continuación repasamos nuestro enfoque junto al artículo de Anthropic y explicamos por qué HeyDeer está diseñado así.

1. Por qué las personas ya no pueden revisar cada línea

Anthropic cuenta que Claude escribe alrededor del 90 % del código de Claude Code y que los PR fusionados se duplicaron con creces en unos pocos meses. Nuestro camino ha sido parecido.

Antes éramos muy exigentes con la revisión de código: alguien leía cada línea con atención y se planteaba si había una forma mejor de escribirla, porque el código malo que llega a la base de código es difícil de sacar después.

En la época de Opus 4.1, la IA ya escribía entre el 70 % y el 80 % de nuestro código, y los PR pendientes de revisión en GitHub no paraban de acumularse. Empezábamos a quedarnos atrás. Hoy, con Opus 5.5, los modelos son tan capaces que los ingenieros se dedican sobre todo a fijar objetivos y dejan la implementación a los agentes de programación, y la IA escribe casi el 100 % de nuestro código. Si las personas siguieran revisando cada línea, serían el paso más lento de todo el proceso.

Al mismo tiempo, la revisión línea a línea vale menos que antes. Los code smells que más nos preocupaban son fáciles de limpiar para la IA, así que ya no hace falta que una persona los busque línea a línea. Contaremos cómo lo hacemos en otro artículo.

Así que la pregunta ya no es “¿cómo pueden las personas revisar más rápido?”, sino:

1. ¿Qué cambios necesitan de verdad que una persona los mire?
2. ¿Cómo mantenemos la calidad en los que no?

Veámoslas una por una.

2. Qué cambios necesitan a una persona: niveles según el riesgo

La respuesta de Anthropic es la aprobación humana según el riesgo: un clasificador fija el nivel de riesgo a partir del propio cambio, no de quién lo escribió. Los cambios de riesgo bajo no necesitan aprobación humana una vez que pasan las comprobaciones automáticas, los de riesgo medio necesitan a una persona y los de riesgo alto, a dos.

HeyDeer funciona igual. Cada revisión evalúa el nivel de riesgo del PR (bajo, medio o alto) y explica por qué. En el ajuste PR que HeyDeer puede aprobar, eliges qué niveles de riesgo puede aprobar HeyDeer.

Riesgo bajo y medio: aprueba HeyDeer

Nuestro equipo eligió PR de riesgo bajo y medio: siempre que un PR no sea de riesgo alto y la revisión completa de HeyDeer no encuentre problemas, HeyDeer lo aprueba y el PR se fusiona automáticamente en la rama principal.

Llevamos 8 meses trabajando así y ni una sola vez la fusión de código con errores ha tumbado nuestro servicio en producción.

Riesgo alto: las personas juzgan la dirección y HeyDeer se ocupa de los detalles

Los PR de riesgo alto siguen necesitando la aprobación de otro ingeniero. Pero su papel ha cambiado: en lugar de buscar errores línea a línea, juzga desde un nivel más alto si el enfoque y la dirección del PR son los correctos. Esto coincide con los puntos en los que el artículo de Anthropic mantiene a las personas: decidir si construir algo, revisar la arquitectura y leer la evidencia que respalda un cambio. Los detalles finos se pueden dejar a HeyDeer.

Para ayudar a las personas a encontrar antes lo importante, HeyDeer ofrece un recorrido:

• Agrupa los cambios relacionados, marca cada grupo como Lectura obligatoria, Lectura recomendada o Vistazo, y reúne en Otros los cambios que se salen del camino principal, con el motivo de cada uno. De un vistazo sabes qué puedes saltarte y centras tu atención en lo que más importa.
• Indica el nivel de riesgo del PR y el razonamiento que lo justifica, para que sepas qué confirmar con cuidado.

Los revisores ya no leen del primer archivo al último. Van directos a los pocos puntos que más necesitan el criterio de una persona.

3. Mantener la calidad donde no mira ninguna persona

Dejar que la IA apruebe la mayoría de los PR solo funciona si su revisión es fiable: tiene que encontrar lo que hay sin ahogar a las personas en ruido. HeyDeer está diseñado para ambas cosas y permite que cada equipo lo ajuste a su forma de revisar.

Preciso: varios modelos revisan y se verifican entre sí

En la revisión con IA de Anthropic, varios agentes buscan bugs en paralelo, otros agentes votan cada hallazgo y solo se publican los que superan la votación.

HeyDeer va más allá: modelos de distintos proveedores revisan cada cambio y se verifican entre sí. Un solo modelo pasa por alto problemas con facilidad y también señala otros que no existen, y varias copias del mismo modelo tienden a cometer los mismos errores. Cada modelo tiene sus propios puntos ciegos, así que la revisión cruzada encuentra bastantes más problemas, y la verificación cruzada filtra buena parte del ruido y los falsos positivos.

Reducir el ruido también protege la atención humana. Con demasiados falsos positivos, las personas no dan abasto y acaban dejando de leer. Si en cambio se lo das todo a un agente de programación, puede seguir los falsos positivos a ciegas e inflar la base de código. Dejar la revisión a la IA solo funciona cuando sus resultados son precisos.

Exhaustivo: las comprobaciones del repositorio hacen cumplir las convenciones del equipo

El enfoque de Anthropic es que, cuando el mismo comentario de revisión aparece una y otra vez, se corrige en el origen: en skills, reglas de lint, CLAUDE.md o REVIEW.md.

Según nuestra experiencia, a las herramientas de revisión de uso general les cuesta atender las necesidades de una base de código concreta: cómo se escriben las mayúsculas en las etiquetas de los botones, el tono de los textos de la interfaz, las convenciones del equipo para usar React, etc. Escritas en AGENTS.md o en una skill, estas convenciones guían a los agentes de programación mientras escriben código, pero en una revisión de código completa se pierden fácilmente en un contexto enorme y se pasan por alto.

Las comprobaciones del repositorio de HeyDeer están pensadas para esto. Escribe en lenguaje natural en .agents/checks los requisitos que quieres comprobar, y HeyDeer asigna a cada comprobación su propio revisor, que revisa cada PR que modifica los archivos correspondientes frente a ese único requisito, para que no se escape nada.

Ajustable: un alcance de los comentarios que encaja con la forma de revisar de tu equipo

Cada equipo necesita algo distinto de los comentarios de revisión, así que HeyDeer ofrece el ajuste Alcance de los comentarios:

• Conciso: para equipos que todavía dependen sobre todo de la revisión humana, por ejemplo en el sector financiero. Solo conserva los problemas importantes, para que las personas dediquen su tiempo a lo que más importa.
• Equilibrado (el predeterminado) o Detallado: para equipos que dejan la mayor parte de la revisión y las correcciones a agentes de programación o a HeyDeer. Corregir problemas pequeños no le cuesta casi nada a la IA, así que incluso los problemas menores se resuelven.

4. Después de la revisión: Autopilot corrige hasta que el PR converge

Cuando la revisión encuentra problemas, alguien tiene que corregirlos. Si un ingeniero tiene que volver en cada ronda para leer los comentarios, pedirle cambios a un agente y esperar a la siguiente revisión, su atención sigue atada.

El artículo de Anthropic es franco sobre un problema muy real: la revisión con IA puede no converger. Uno de sus PR pasó por más de cincuenta rondas de revisión y corrección en una sola noche. Alrededor del 59 % de lo que el revisor seguía señalando era código que ya estaba ahí desde su primera pasada: cada ronda no encontraba bugs nuevos, sino unos cuantos antiguos más. Desde entonces han hecho una serie de mejoras, como limitar el número de rondas, volver a revisar solo los cambios nuevos después de las primeras pasadas y no repetir hallazgos ya publicados.

Desde el principio, HeyDeer ha tratado la convergencia como un objetivo de diseño de la revisión. Cuando HeyDeer encuentra una tanda de problemas pequeños, puedes pasárselos a Autopilot: corrige lo pendiente, sube los cambios a la rama del PR y revisa sus propios cambios, y repite hasta que el PR está listo para fusionarse o surge una pregunta que necesita a una persona. En nuestro uso, la mayoría de los PR terminan en dos rondas y los más complejos, en tres. Autopilot hace como máximo 5 rondas y, cuando se detiene, explica por qué y qué sigue necesitándote.

Esto nos importa mucho. Cambiar de contexto sale muy caro a las personas, y no queremos que los ingenieros tengan dos cosas en la cabeza a la vez: escribir una funcionalidad nueva mientras se preguntan si ya se han atendido los comentarios de su último PR. En cuanto inician Autopilot, los ingenieros pueden pasar a la siguiente tarea con tranquilidad.

Con todo junto, este es el día a día de nuestro equipo: en cuanto un ingeniero abre un PR, puede pasar a otra cosa. HeyDeer lo revisa y Autopilot corrige lo que encuentra. HeyDeer aprueba los PR de riesgo bajo y medio, que se fusionan directamente en la rama principal; en los PR de riesgo alto, otro ingeniero usa el recorrido para comprobar la dirección.

5. Qué equipos pueden trabajar así

¿Para quién es este enfoque de “solo los cambios de riesgo alto necesitan revisión humana”? Con lo que la IA puede hacer hoy, creemos que la mayoría de las startups y de las pequeñas y medianas empresas pueden trabajar así, siempre que su negocio no maneje información especialmente sensible. Puedes empezar dejando que HeyDeer apruebe solo los PR de riesgo bajo y ampliarlo al riesgo medio cuando el equipo haya ganado confianza.

Reflexiones finales

Así se corresponden, a grandes rasgos, las prácticas de Anthropic con nuestra forma de usar HeyDeer:

Las herramientas y los modelos cambiarán, pero el objetivo no: la atención humana es el recurso más escaso de un equipo, así que dedícala donde más cuenta. Si tu equipo también está viendo que la IA escribe código más rápido de lo que las personas pueden revisarlo, prueba HeyDeer.