El 15 de octubre Anthropic sacó Code Review de research preview y lo abrió a las organizaciones Team y Enterprise. Uso Claude Code todos los días, pero este servicio no lo he usado. Lo que sigue sale de la nota de lanzamiento, de la documentación y del anuncio de ClaudeDevs, no de mi experiencia con él.

El revisor comenta, pero no firma

La documentación lo dice sin rodeos: "a review never approves or blocks the pull request" (un review nunca aprueba ni bloquea el pull request), y el check run “Claude Code Review” no concluye nunca como fallo. Termina en neutral, o se omite. Un status check obligatorio no lo va a frenar.

Eso cambia la pregunta. Ya no es si la IA encuentra los bugs. Ahora es quién decide qué hacer con lo que encontró.

Anthropic dice que hoy la mayoría de los reviews termina unas 3 veces más rápido que en el preview, entre 6 y 10 minutos en lugar de unos 20. Y en el post de marzo reporta, sobre su propio código, que los PRs con comentarios sustanciales pasaron de 16% a 54%, y que en los de más de 1.000 líneas el 84% recibe hallazgos, con 7,5 en promedio. Son cifras de Anthropic sobre sus repositorios, no de los tuyos.

Más hallazgos por PR significa más decisiones por PR. Es el mismo desplazamiento que describí en el cuello de botella que ya no es escribir código: el tramo rápido se hizo más rápido y la cola de decisiones humanas se alarga.

Decisión 1: quién resuelve el hilo

Cada hallazgo llega como comentario en la línea, con tres severidades: Important (un bug que conviene arreglar antes del merge), Nit y Pre-existing. La documentación aclara que puedes hacer merge sin responder a un hallazgo, salvo que la protección de rama de tu repositorio exija resolver las conversaciones. Y para descartar uno sin cambiar código tienes que resolver el hilo tú. Responder no basta.

Entonces quien resuelve un hilo Important sin tocar el código está firmando. Define quién puede hacerlo antes de que lo decida el primero que tenga prisa.

Hay algo que el servicio no hace. Trabaja leyendo el diff y el código alrededor, sin compilar ni ejecutar nada. En mi análisis sobre revisión de código con IA sostuve que el revisor necesita a un autor que pueda explicar sus decisiones. Code Review no sustituye esa conversación, y la documentación avisa que un review sin hallazgos no significa que el código esté libre de errores.

Decisión 2: cuánto gastas y cuándo se detiene

No hay precio fijo por review. Se cobra por tokens, con créditos de uso, y la factura le llega a la organización, no al desarrollador. En marzo el post de lanzamiento hablaba de un promedio de 15 a 25 dólares por review. La documentación actual ya no promete un número, así que yo no presupuestaría con ese.

Lo que sí dice la documentación es dónde se dispara el gasto. Un repositorio recién agregado arranca en After every push, el modo que más reviews corre. Un ejemplo hipotético para ver la mecánica: 100 PRs al mes con 4 pushes cada uno son 400 reviews en ese modo y 100 en Once after PR creation. Multiplica por tu promedio real.

Los niveles también mueven el costo. Quick, Standard (el predeterminado) y Deep: un Owner elige uno para la organización y puede dar otro a cada repositorio. Deep para el código que mueve dinero, Quick para el resto.

Y hay un límite mensual de gasto. Si se agota, el servicio omite reviews y deja un comentario en el PR que nombra la causa. Si tu política dice “todo PR pasa por Code Review”, ese tope es parte de la política. Anthropic sugiere un piloto de pocos repositorios con un límite bajo y leer el costo promedio por repositorio en el panel. Las organizaciones Enterprise elegibles pueden reclamar al menos 10.000 dólares en créditos hasta el 15 de enero, con vencimiento a los 30 días de reclamarlos. Úsalos para medir tu promedio, no para decidir la política.

Decisión 3: qué puede frenar un merge

Por defecto, nada. Si quieres un gate, la documentación enseña a leer la última línea del detalle del check run con gh y jq: si el conteo normal (los Important) es mayor que cero, haces fallar tu propio job. También advierte que una línea ausente significa sin veredicto, no cero hallazgos. Un review que falló o expiró no tiene esa línea.

Mi criterio es mover el gate al final. Mide primero cuántos Important de tus repositorios resultan falsos. Anthropic reporta que sus ingenieros marcan como incorrectos menos del 1% de los hallazgos, pero es su código y su equipo. Los PRs en borrador y los que vienen de forks tampoco se revisan solos, y GitHub es el único host compatible.

La política cabe en cuatro líneas por repositorio

Nivel de review. Cuándo corre. Quién puede resolver un hilo Important. Si hay gate o no. Si no puedes llenar esas cuatro líneas para tu repositorio más crítico, el servicio va a funcionar igual y nadie sabrá qué se prometió con él.

Eso es lo que sacamos en el discovery de AI Maestro cuando el equipo ya genera código con agentes: quién firma, con qué evidencia y con qué tope de gasto.

Cuéntame cómo hacen merge hoy y armamos las cuatro líneas