ANTHROPIC revela cómo resuelve el MAYOR PROBLEMA de programar con IA

Resumen

El video explica cómo el equipo de Claude Code de Anthropic intenta resolver el cuello de botella que surge cuando la IA escribe código más rápido de lo que las personas pueden revisarlo. Según el narrador, Claude genera cerca del 90 % del código del equipo. La propuesta no elimina la revisión: automatiza buena parte de ella y reserva la atención humana para los cambios de mayor riesgo.

Las seis capas de revisión

1. Comprobaciones antes del pull request: Claude debe aportar pruebas de que el cambio funciona —por ejemplo, superar pruebas, compilar o comparar una captura con el diseño—, en vez de limitarse a afirmar que terminó. Después, otro agente revisa los cambios con contexto limpio. También se usan habilidades para buscar errores, reducir diffs y probar el código.

2. Revisión automatizada del pull request: varios agentes buscan problemas en paralelo y votan sobre sus hallazgos; solo se conservan los que superan un umbral. Se descartan comentarios de estilo, y los hallazgos restantes se ordenan por gravedad, incluyendo si el problema ya existía antes del cambio. Los comentarios deben resolverse o justificarse. El sistema usa documentos breves de instrucciones, como CLAUDE.md y un archivo de revisión con convenciones y errores recurrentes.

3. Análisis de seguridad automatizado.

4. Integración continua: lint, comprobación de tipos, compilación y pruebas en distintas plataformas. Los cambios no avanzan si quedan hallazgos abiertos de las revisiones.

5. Aprobación humana según el riesgo: la cantidad de aprobaciones depende del tipo de cambio. Por ejemplo, la documentación podría no necesitar aprobación, un cambio normal podría requerir una persona y el código delicado, dos. Algunas áreas, como los archivos de CI, exigen aprobación adicional. La aprobación de un agente no cuenta como aprobación humana; además, una aprobación puede dejar de ser válida si se añade otro commit.

6. Prueba y despliegue gradual: el cambio se vuelve a probar sobre la versión más reciente, se publica inicialmente detrás de un interruptor y se prueba primero con empleados. El despliegue público empieza en el canal más reciente antes de llegar al estable. Si aparece un problema, la intención es poder desactivarlo o revertirlo rápidamente.

Revisiones entre agentes y mejora del sistema

El equipo observó que una revisión entre agentes podía prolongarse durante muchas rondas y repetir hallazgos sobre problemas ya señalados. Para reducir ese ciclo, después de varias rondas el revisor debe evaluar el enfoque general y centrarse en los cambios nuevos, en lugar de volver a revisar cada línea. El video atribuye a ese ajuste una reducción de las revisiones de cinco o más rondas, del 8,9 % al 1,5 %, y una caída del promedio de revisiones de 2,1 a 1,3.

También se registra qué ocurre con cada comentario y se prueban los revisores contra cambios que se sabe que están limpios. Los incidentes y las reversiones se convierten en casos de prueba para evaluar cambios en las instrucciones, las herramientas o los modelos.

Qué sigue haciendo una persona

Las personas deciden qué vale la pena construir y aportan criterio sobre producto, arquitectura y código especialmente delicado, como pagos o actualizaciones automáticas. También deben comprobar que la revisión sea real. El criterio citado en el video es que, si no se puede identificar qué podría escaparse, no basta con pedir una aprobación rápida.

El equipo también usa Claude para explicar partes del código cuando alguien necesita entenderlas, en lugar de depender de que cada integrante memorice todo el sistema.

Lista práctica para adaptar a un repositorio

• Mantener un CLAUDE.md breve con las convenciones y las comprobaciones que debe realizar el agente.
• Automatizar formatters y linters, por ejemplo, mediante hooks.
• Hacer una revisión previa al pull request con contexto limpio, usando un comando de revisión o un subagente.
• Documentar en un archivo de revisión los errores recurrentes y las áreas que requieren atención.
• Incluir en la plantilla del pull request preguntas sobre pruebas, riesgos y cómo revertir el cambio.
• Limitar las rondas de revisión y, después de cierto punto, revisar solo lo nuevo.
• No contar la aprobación de un bot como aprobación humana; exigir una persona para cambios de pagos, accesos o despliegues.
• Registrar incidentes y reversiones para medir si el sistema de revisión mejora.

El video cita cifras internas de Anthropic —por ejemplo, un aumento de unos 2.500 cambios diarios en mayo a más de 30.000 en septiembre, y de un 16 % a un 54 % de pull requests internos con comentarios considerados útiles—. Aclara que son cifras de la propia empresa y no mediciones externas.

Fuentes y hablantes: el video está narrado por el canal XCB. La explicación se basa en información del equipo de Claude Code de Anthropic, incluido su creador, Boris Cherny, y en el artículo de Anthropic sobre su proceso de revisión de código.