Revisión de código

Cuando le das a Claude Code una tarea para completar en tu base de código, Claude a menudo informará de vuelta de manera sucinta. Debajo de la descripción de lo que Claude cambió, puede haber una variedad de archivos que fueron modificados (desde cambios pequeños hasta cambios importantes). A menudo, la sesión que escribió los cambios de código (y los explicó) no es el juez de mayor calidad de esos cambios. Es una buena práctica revisar tú mismo cada cambio antes de conservarlo, y luego hacer que Claude lo revise de nuevo desde un contexto limpio, sin el historial de esta sesión.

Revisa los cambios reales

Un diff es el antes y después de un cambio: las líneas eliminadas y las líneas agregadas, archivo por archivo. El comando /diff abre un visor interactivo de tus cambios sin confirmar en esa forma, y también puede mostrar lo que cambió cada uno de los turnos de Claude. Usa las flechas arriba y abajo para moverte entre archivos y Enter para abrir uno.

Las cosas más importantes que merecen una segunda mirada cada vez son:

• Cambios que no pediste. Un valor de configuración que fue editado mientras Claude estaba en el archivo o un método auxiliar reescrito que no mencionaste.
• Pruebas que se debilitaron. Si el proyecto en el que estás trabajando contiene pruebas, identifica cualquiera que haya sido omitida, eliminada o relajada hasta que pasara.
• Paquetes nuevos y valores codificados directamente. Una dependencia que se agregó para una sola función, una URL o una clave escrita directamente en el código.

Si todo el cambio está mal, ejecuta /rewind (o presiona Esc dos veces en una indicación vacía), elige la indicación que lo produjo, y selecciona Restaurar código y conversación. Un límite que vale la pena conocer: los archivos modificados por comandos de shell que Claude ejecutó, como una instalación de paquete, no se revierten.

El ejercicio de abajo usa una pequeña tarea de formulario de registro: el resumen de Claude arriba, los ocho archivos que Claude tocó debajo.

Pide una segunda opinión

La lección Explorar → Planificar → Codificar → Confirmar decía que debes tener un segundo revisor en un cambio antes de confirmarlo. Una sesión larga lleva consigo todo lo que ha leído y decidido. Ese es el contexto que aprendiste a gestionar en la lección anterior, y es exactamente el historial que no quieres en un revisor. /code-review es ese segundo revisor: revisa el cambio en un contexto limpio, sin nada del historial de tu sesión, e informa lo que encuentra. No edita nada a menos que se lo pidas.

La revisión se ejecuta en segundo plano, desde unos segundos hasta unos minutos, y cuenta contra tu uso como cualquier otra tarea, así que resérvala para cambios que merezcan una segunda mirada. Los hallazgos llegan a tu conversación cuando termina. También puedes pedirlo en palabras simples, y Claude puede iniciar la misma revisión a partir de la solicitud. Si Claude responde en línea en lugar de iniciar una revisión, ejecuta el comando tú mismo.

Para el cambio del formulario de registro, la revisión regresó con cuatro hallazgos:

Decide qué hacer con cada hallazgo

Clasifica cada hallazgo en una de tres pilas:

1. Arreglar ahora. Este es un problema real, importa, y debe arreglarse.
2. Preguntar por qué. Esta es la pila para hallazgos que no puedes verificar del todo o que parecen extraños. Es posible que los revisores que leen cambios de código en frío también pasen cosas por alto.
3. Dejarlo. Este es un problema real pero pequeño o sin consecuencias. Estos a menudo se pueden agrupar en un conjunto de arreglos que cubrirás en una sesión futura.

Para preguntar por qué, cita el hallazgo de vuelta a Claude y pídele a Claude que lo revise de nuevo. Para el segundo hallazgo anterior, escribirías:

Siempre que pidas un arreglo, es bueno pedir evidencia junto con él:

Si un arreglo eventualmente crece hasta convertirse en un cambio grande por sí mismo, ejecuta la revisión de nuevo.

Cuándo vale la pena revisar las cosas más de cerca

Un cambio simple de una sola línea a menudo solo necesita un vistazo rápido al diff y nada más. Deberías usar una revisión humana y una revisión de Claude cuando un cambio es más grande de lo que podrías retener en tu cabeza, cuando toca algo sensible o hace algo destructivo, y antes de entregar el trabajo a un compañero de equipo.

Pruébalo: clasifica los cuatro hallazgos

Resumen

• Lee el diff real de los cambios de archivos antes de confiar solo en el resumen. Ejecuta /diff y busca cambios que no pediste, pruebas debilitadas, y paquetes nuevos o valores codificados directamente.
• Obtén una segunda opinión desde un contexto limpio con /code-review (o pídelo en palabras simples y deja que Claude lo inicie). El revisor informa, y Claude no edita a menos que se lo pidas.
• Trata cada hallazgo como arreglar ahora, preguntar por qué, o dejarlo, y pide evidencia con cada arreglo.

Cuando el revisor señala el mismo problema varias veces, podría ser una buena idea escribir una regla para que Claude la lea al comienzo de cada sesión. Ese archivo es CLAUDE.md, y es lo siguiente.