English

Step The Diff With Review Next File

El agente termina. Nueve archivos aparecen como modificados y el botón más grande y más amable de la pantalla dice Accept All. Hacer clic toma un segundo y se siente como progreso. Lo que realmente hace es entregar la forma de tu código a algo que después no te podrá explicar su razonamiento. Cursor pone la alternativa justo ahí, en el mismo panel: un botón llamado Review Next File.

Lo que realmente cuesta aceptar a ciegas

El problema no es que los agentes escriban mal código. Muchas veces no lo hacen. El problema es que dejas de saber qué hace tu código. Como lo resumió un desarrollador con experiencia después de construir una app entera así: lo peor de indexar todo tu código y resolverlo de un tirón es que no vas a poder entender tu código y vas a perder el control de él. Más adelante aparecen bugs que jamás habrías imaginado, del tipo que rompe en producción de formas que habrías jurado imposibles.

Eso es deuda de comprensión, y se acumula distinto a la deuda técnica común. Cuando un colega te manda un pull request, ambos comparten un modelo mental: sabes más o menos qué intentaba, puedes preguntarle por qué, y el diff está acotado a un objetivo declarado. El diff de un agente no tiene nada de eso. Puede haber renombrado en silencio una variable en un archivo que ni mencionaste, fusionado dos funciones porque así su edición era más simple, o cambiado la firma de una llamada y todos sus usos. Cada una de esas decisiones es razonable por separado e invisible en bloque. Leer el diff es el único momento en que te enteras.

Qué hace Review Next File

Después de que una ejecución del agente toca varios archivos, Cursor muestra un botón Review Next File. Te presenta, uno por uno, todos los archivos que cambiaron. Haces clic y caes en el diff de un solo archivo a nivel de línea: esta línea se quitó, esta línea se agregó. Lees el cambio, decides si es lo que querías y aceptas ese archivo. Luego pasas al siguiente.

La condición de término viene incorporada y es notablemente limpia: cuando todos los archivos modificados fueron revisados, el botón desaparece. Su ausencia es la señal de que todos tus cambios ya se atendieron; no tienes que recordar cuántos archivos había en el lote ni llevar la cuenta aparte.

Esa granularidad por archivo es todo el punto. Accept All es una sola decisión sobre una cantidad desconocida de cambios. Review Next File la convierte en una secuencia de decisiones pequeñas, cada una tomada con el diff real delante.

Cómo ejecutar el bucle

1. Deja que el agente termine su turno. No toques Accept All.
2. Haz clic en Review Next File.
3. Lee el diff a nivel de línea de ese archivo: qué se quitó, qué se agregó y si el cambio corresponde a lo que pediste.
4. Acepta ese archivo. Listo.
5. Vuelve a hacer clic en Review Next File para el siguiente.
6. Repite hasta que el botón desaparezca. Ese es el lote completamente revisado.

Mientras lees, sirven las mismas preguntas que harías al revisar el trabajo de una persona, más una extra. ¿Este cambio hace lo que pedí? ¿Hizo además algo que no pedí? ¿Lo habría escrito así, y si no, la diferencia es una mejora real o solo otra costumbre? La extra, propia de los agentes: ¿esta edición asume algo sobre el resto del código que yo sé que no es cierto?

Ve paso a paso desde el principio

El bucle de revisión se vuelve mucho más llevadero si arreglas la causa. Una instrucción del tipo "constrúyeme la app entera y veamos qué pasa" produce un diff tan grande que revisarlo con honestidad cuesta más que haber escrito el código, que es exactamente la situación en la que la gente se rinde y aprieta Accept All. Pide un paso coherente, revísalo y luego pide el siguiente. Los lotes pequeños son los que hacen sostenible la revisión por archivo, y la revisión por archivo es la que mantiene honestos a los lotes pequeños.

En qué se diferencia de las redes de seguridad vecinas

• Review Next File es el control previo al aterrizaje. Lees el cambio antes de aceptarlo. Es el único de los tres que protege tu comprensión y no solo tus archivos.
• Restaurar un checkpoint es recuperación después de que una mala edición ya aterrizó. Devuelve tus archivos a un punto anterior de la conversación. Es indispensable, pero para entonces el cambio ya ocurrió, y restaurar se lleva las ediciones buenas de ese turno junto con la mala.
• Ejecutar el código antes de quedarte con todo es verificación en tiempo de ejecución. Responde "¿esto funciona?", que es una pregunta distinta de "¿entiendo y respaldo este cambio?". Un diff puede estar mal de maneras que igual corren perfecto: un valor por defecto cambiado sutilmente, un error que se traga en silencio, un atajo que solo se sostiene con la entrada que probaste.

Usa los tres. Pero fíjate en que solo el primero te deja sabiendo qué cambió.

Errores comunes

• Pasar el scroll por un diff no es leerlo. Si estás reconociendo patrones de "se ve bien" en vez de leer qué se quitó y qué lo reemplazó, estás haciendo Accept All en cámara lenta.
• Las eliminaciones merecen más atención que las adiciones. Las líneas nuevas se anuncian solas. Una línea eliminada —una guarda, un await, una rama de error— es el cambio con más probabilidad de importar y menos de llamarte la atención.
• Un lote imposible de revisar es un problema de instrucción, no de revisión. Si la respuesta honesta ante un diff de veinte archivos es que no lo vas a leer, la solución está más arriba: pide un paso más chico y revisa ese.
• Aceptar no es verificar. Revisar cada archivo te dice que el código es lo que querías. No te dice que funciona. Haz las dos cosas.