¿Cómo revisas un cambio que un asistente de IA hizo en tu juego antes de quedártelo?

Compara los archivos cambiados con tu tarea, lee el diff empezando por lo borrado, corre las verificaciones tú mismo, juega el cambio y solo entonces haz el commit.

Mira cuatro cosas, en este orden: qué archivos cambiaron, qué quitó y qué agregó el diff, qué dicen las verificaciones cuando las corres tú mismo y cómo se juega el juego donde cayó el cambio. Quédate con el cambio solo cuando las cuatro coincidan con lo que pediste, y guárdalo como commit. Si alguna no coincide, deshazlo y vuelve a pedirlo con una tarea mejor. El informe del asistente te dice dónde mirar; no es la revisión.

¿Por qué no basta con «listo»?

Porque es una afirmación, y la prueba es el cambio mismo. Un asistente puede decir que una función anda cuando solo comprobó que el código compila, o que tocó un archivo cuando un comando que ejecutó reescribió tres.

Parte de esto ni siquiera se ve en el editor. La página de Visual Studio Code sobre revisar ediciones hechas por IA dice que las ediciones pendientes ya están guardadas en disco, que los cambios hechos con comandos de terminal o scripts no aparecen en su lista de ediciones y que sus puntos de control no deshacen comandos de terminal ni despliegues. Así se leía la página el 29 de octubre de 2026, con última actualización del 21 de octubre. Uses la herramienta que uses, la vista confiable es la que da el control de versiones: cada archivo que difiere de tu último commit.

Por eso el primer paso ocurre antes de que el asistente empiece: guarda una versión que funcione como commit. Sin él no hay con qué comparar el cambio ni adónde volver.

¿Qué mirar primero?

La lista de archivos cambiados. Dos comandos la dan:

git status
git diff --stat

git status nombra cada archivo cambiado y cada archivo nuevo. git diff --stat agrega cuántas líneas ganó y perdió cada archivo. Ten en cuenta que git diff solo no muestra archivos nuevos que todavía no se agregaron a Git; git status sí, así que lee los dos.

Ahora compara la lista con tu tarea. Si escribiste una tarea que dice dónde va el cambio y qué no debe cambiar, esto toma segundos.

Nada de esto está mal por sí mismo. Pero cada punto es algo que no tenías pensado revisar, así que va primero.

¿Cómo lees el diff si no eres programador?

Léelo como una lista de líneas quitadas (en rojo, marcadas con -) y líneas agregadas (en verde, marcadas con +), y empieza por las quitadas. Una línea que desaparece es el cambio más fácil de pasar por alto y el más difícil de notar al jugar: una comprobación que impedía al jugador atravesar paredes, el reinicio del puntaje, una protección contra una partida guardada vacía.

Después busca algunos patrones fáciles de ver sin conocer el lenguaje:

• Números que cambiaron: velocidades, vidas, temporizadores, precios. Cada uno debería estar en tu tarea.
• Código convertido en comentarios, o un bloque entero borrado y escrito de nuevo en otro lugar.
• Una función nueva que se parece a una vieja: el mismo trabajo hecho dos veces, y con el tiempo las dos copias se separan.
• Texto que ve el jugador: menús, pistas, mensajes de error. ¿Sigue siendo correcto y está en su lugar?

Por cada línea que no sepas leer, pregúntale al asistente qué hace y qué la llama. La pregunta no cuesta nada, y una respuesta que no coincide con el código ya es un hallazgo.

¿Qué verificaciones corres tú mismo?

Las que nombró tu tarea, corridas por ti y no informadas. Si la tarea pedía una prueba, corre las pruebas y lee el resultado. Si pedía que la página cargue sin errores, abre el juego con la consola del navegador abierta. Una verificación que viste pasar vale más que una frase que dice que pasó.

Una prueba en verde solo demuestra lo que prueba. Si en el mismo diff cambió un archivo de pruebas, lee esa parte: una prueba que antes esperaba un puntaje de 0 después de reiniciar y ahora espera lo que devuelva el código ya no verifica nada.

¿Qué jugar antes de quedarte con el cambio?

Primero el cambio mismo, como lo describió tu tarea. Después un recorrido corto por el resto del juego, siempre el mismo, porque un cambio en un lugar a menudo rompe otro:

1. inicia el juego desde una página nueva;
2. usa cada control una vez, con teclado y en el teléfono si el juego tiene controles táctiles;
3. pausa, pierde, reinicia;
4. guarda, recarga la página, carga.

El recorrido toma unos minutos y atrapa lo que las pruebas rara vez cubren: un botón que ya no responde, una pantalla de la que no se puede salir, una partida guardada que no vuelve. Si el cambio agregó una tecla o una pantalla, comprueba que también funcionen al tacto; es la regla que seguimos con KittenGalaxy desde que le agregamos controles táctiles.

¿Cómo te quedas con el cambio, o lo tiras?

Para quedártelo, haz un commit con un mensaje que diga qué cambió en palabras del jugador: «cada oleada un 10 % más rápida, hasta el doble de la velocidad inicial». Una tarea, un commit. Más adelante, cuando algo se rompa, podrás encontrar qué cambio lo hizo y deshacer exactamente ese.

Para tirarlo, vuelve a tu último commit. En Git, git restore . deja los archivos que Git ya sigue como estaban en tu último commit, salvo que los cambios se hayan preparado con git add; los archivos que creó el asistente no se borran con él, así que revisa git status otra vez y bórralos a mano. Los editores con su propio deshacer o con puntos de control pueden hacer lo mismo, dentro de los límites que describen. Después escribe una tarea mejor: di qué salió mal y agrega una verificación que lo habría detectado.

Tienta quedarse con un cambio que está casi bien y arreglar el resto en la próxima tarea. Hazlo solo si puedes nombrar qué está mal y es poco. Un cambio que no entiendes no se vuelve más fácil de entender cuando el siguiente se construye encima. Así se descontrolan los juegos hechos con asistentes, y por eso un primer juego pequeño es más fácil de mantener funcionando.

¿Puede otra IA hacer la revisión?

Puede leer el diff contigo: explicar líneas, señalar comprobaciones quitadas, preguntar para qué sirve una función nueva. Eso ayuda, sobre todo si no lees código. Pero no puede decidir si el juego todavía hace lo que querías, porque eso solo lo sabes tú, y no puede jugar por ti. Úsala como segunda lectora, nunca como aprobación.

Preguntas frecuentes

¿Cuánto debería tardar una revisión? Más o menos tan poco como pequeño sea el cambio. Si leer el diff tarda más que escribir la tarea, la tarea probablemente era demasiado grande; divide la siguiente.

¿Necesito Git para esto? Necesitas alguna forma de ver qué cambió y de volver atrás. Git es la habitual y es gratis; la mayoría de los editores y asistentes trabajan con él.

¿Y si el cambio está bien pero el código se ve desordenado? Quédatelo si funciona y lo entiendes, y escribe una tarea aparte para ordenarlo, con las mismas verificaciones. No mezcles el orden con una función nueva.

¿Reviso los cambios en gráficos, sonido y archivos de niveles? Sí, mirando y jugando en lugar de leer el diff. La lista de archivos cambiados igual te dice cuáles mirar.

¿Cuándo pueden jugarlo otras personas? Cuando el recorrido de arriba pasa en una página nueva y un desconocido puede terminar el juego sin tu ayuda. Entonces puedes enviarlo a HeapPlay.