Sesgo declarado, como siempre: enseño Claude Code a equipos de ingeniería, así que cualquier cambio en cómo se verifica y se revisa el propio código que Claude escribe me toca de lleno. Precisamente por eso esta pieza va de hechos verificables y de qué te toca decidir esta semana, no de vender un cambio de comportamiento como una revolución.
En la última tanda de versiones hay un cambio callado pero con consecuencias
directas para tu calidad de código: Claude ya no ejecuta por su cuenta las
skills /verify y /code-review. Si dabas por hecho que Claude se
autorrevisaba antes de darte por buena una tarea, esa red de seguridad ha pasado
a ser manual.
Los hechos
Según el changelog oficial de Claude Code,
la versión v2.1.215 (19 de julio de 2026) introduce el cambio con estas
palabras: "Claude ya no ejecuta las skills /verify y /code-review por su
cuenta; invócalas con /verify o /code-review cuando las quieras".
Para situarlo, conviene recordar qué hacen esos dos comandos, que son skills integradas de Claude Code:
/code-review"revisa el diff actual en busca de errores de corrección y de oportunidades de reutilización, simplificación y eficiencia", según la referencia de comandos. Es el comando de revisión que Anthropic presentó en la semana 21 para reportar bugs de corrección; admite--fixpara aplicar los hallazgos y--commentpara dejarlos como comentarios en línea en una PR de GitHub./verifycomprueba que un cambio hace de verdad lo que debe, ejercitándolo de punta a punta en lugar de conformarse con que compile o pasen los tests.
El cambio no toca lo que hacen esas skills: siguen igual. Lo que cambia es
quién dispara el gatillo. Antes, Claude podía lanzarlas por iniciativa
propia durante su trabajo —por ejemplo, después de un cambio no trivial— como
parte de su flujo. Desde la v2.1.215, no lo hace salvo que se lo pidas tú,
escribiendo /verify o /code-review.
No es un experimento en preview: es comportamiento estable a partir de la v2.1.215. Para tenerlo, actualiza.
Por qué esto importa (y no es un simple ajuste de comodidad)
El titular fácil es "un comando menos que se ejecuta solo". El titular real, para un equipo que trabaja con Claude Code todos los días, es dónde vive tu control de calidad. Que Claude se autorrevisara tenía una ventaja y un coste. La ventaja: una comprobación gratis, sin que nadie se acordara de pedirla. El coste: tiempo y tokens gastados en revisiones que a veces no querías, y la falsa sensación de que "ya está verificado" cuando quizá la comprobación no aplicaba a tu caso.
Al pasar a manual, Anthropic devuelve la decisión a tu lado: verificas y
revisas cuando tú decides que toca, con el nivel de esfuerzo que quieras
(/code-review acepta desde low hasta max). Ganas control y previsibilidad.
Pero pierdes el automatismo, y ese es justo el punto que no puedes ignorar: si tu
proceso se apoyaba, aunque fuera de forma implícita, en que Claude se revisara
solo, ese eslabón ha desaparecido de un día para otro.
Qué te afecta, según quién seas
Si usas Claude Code a diario. El cambio de hábito es sencillo pero real:
acostúmbrate a cerrar tú el ciclo. Antes de dar por buena una tarea no
trivial, lanza /verify para comprobar que el cambio funciona de verdad y
/code-review para pasarle una lectura crítica al diff. No des por hecho que ya
ocurrió: ahora solo ocurre si lo pides. Es justo la disciplina de revisar el
diff antes de confiarlo que trabajamos en el curso de
revisión de código y CI con GitHub Actions.
Si tenías el review automático como red de seguridad. Aquí tienes un deber
concreto. Si tu forma de trabajar era "Claude termina, se autorrevisa y yo miro
el resultado", ese segundo paso ya no llega solo. Tienes dos caminos. El manual:
integrar /verify y /code-review en tu rutina como un paso explícito antes de
commitear. El automático: volver a atar esa comprobación con un hook
determinista —por ejemplo, disparar la revisión al cerrar una tarea— para que
no dependa de que alguien se acuerde. Montar ese tipo de automatismos de forma
fiable es justo lo que vemos en el curso de
hooks deterministas.
Si administras Claude Code o mantienes el onboarding del equipo. Ojo con un
detalle: el comportamiento por defecto cambió, así que cualquier guía interna que
diera por supuesto que Claude "revisa solo" antes de terminar ya no describe lo
que pasa. Actualiza esas instrucciones y deja explícito en vuestro CLAUDE.md o
en vuestro flujo cuándo se espera pasar /code-review y /verify, con qué nivel
de esfuerzo y sobre qué diff. Entender estos comandos como skills que se invocan
—no como magia de fondo— es parte de lo que trabajamos en el curso de
slash commands y skills.
Qué llevarte
/verifyy/code-reviewya no se ejecutan solos (v2.1.215): Claude no los lanza por su cuenta; ahora los invocas tú cuando los quieres.- Las skills no cambian, cambia el gatillo: siguen haciendo lo mismo (verificar de punta a punta y revisar el diff); lo que cambia es que la decisión de lanzarlas vuelve a tu lado.
- Cierra tú el ciclo: en tareas no triviales, haz de
/verifyy/code-reviewun paso explícito antes de commitear. - Si dependías del automatismo, recupéralo con un hook: un hook determinista puede volver a disparar la revisión sin depender de que alguien se acuerde.
- Actualiza tu documentación: cualquier guía que diera por hecho la autorrevisión ha quedado obsoleta.
Preguntas rápidas
¿Tengo que hacer algo si nunca conté con la autorrevisión?
No mucho. Si ya lanzabas /verify y /code-review a mano cuando los querías,
sigues igual. El único deber es para quien se apoyaba, aunque fuera sin darse
cuenta, en que Claude se revisara solo.
¿Siguen funcionando --fix y --comment en /code-review?
Sí. El cambio es sobre cuándo se ejecuta el comando, no sobre lo que hace.
--fix sigue aplicando los hallazgos a tu árbol de trabajo y --comment sigue
dejándolos como comentarios en línea en la PR.
¿Puedo volver a que se ejecute automáticamente? El comportamiento por defecto ya no lo lanza solo, pero nada te impide reintroducir esa comprobación en tu propio flujo con un hook que la dispare en el momento que decidas. Es más trabajo inicial, pero a cambio controlas cuándo y sobre qué diff se ejecuta.
¿Vais a fijar dónde vive el control de calidad de vuestro código asistido?
Decidir cuándo se pasa /verify y /code-review, con qué nivel de esfuerzo y si
conviene atarlo a un hook para que no dependa de la memoria de nadie es justo el
tipo de criterio que trabajamos en la
formación en directo para equipos — sobre vuestro repo, vuestro
flujo de revisión y vuestra política real.