Si ejecutas sesiones largas, tarde o temprano llega este momento:

Vuelves al cabo de una hora (o al día siguiente) y no sabes responder a una pregunta muy simple:

¿Qué ha cambiado?

La transcripción es larga.

Las llamadas a herramientas están dispersas.

Y si estás en el móvil, hacer scroll se convierte en un problema en sí mismo.

Así que deja de intentar "leerlo todo".

En su lugar, monta un pequeño ciclo de revisión alrededor de los diffs y la línea temporal de herramientas.

Esta guía es ese ciclo.

En resumen

1. No releas toda la transcripción. Empieza por una vista de "qué ha cambiado":
   • archivos modificados
   • diffs
   • llamadas a herramientas
2. Si tu herramienta lo permite, usa una línea temporal que unifique las llamadas a herramientas de Claude Code/Codex/OpenCode.
3. Usa un ciclo al final del turno:
   • repasa por encima las filas de la línea temporal
   • salta a los diffs
   • decide: mantener / revertir / dividir
4. Happier es una opción que lo facilita en el móvil, porque la transcripción muestra las llamadas a herramientas con una presentación propia (tarjetas o un feed de actividad) y al tocarlas te lleva directamente a las vistas de archivo o diff.

El problema

Lo que quieres evitar no es el trabajo.

Es una revisión sin límites.

Si no puedes ver rápido "qué ha cambiado", o bien:

• te fías de cambios que no has revisado
• o pierdes tiempo reconstruyendo el contexto

El ciclo de revisión tiene que tener límites.

Enfoques habituales y sus contrapartidas

• Leer la transcripción de arriba abajo: vale para ejecuciones cortas, es horrible para las largas.
• Mirar solo git diff: bien, pero te pierdes por qué se hicieron los cambios.
• Pedir al modelo un resumen: útil, pero sigues queriendo ver los diffs reales.

Si Happier es nuevo para ti

Si no conocías Happier: es una app complementaria de código abierto (móvil/web/escritorio) para sesiones de programación.

En esta guía, lo relevante es el ciclo de revisión de la interfaz:

• las llamadas a herramientas se muestran como filas de una línea temporal (o tarjetas)
• puedes tocar las filas para ver los detalles
• las llamadas a herramientas enlazan directamente con diffs y archivos

Para empezar:

• Cómo usar Happier desde el móvil
• GitHub: https://github.com/happier-dev/happier
• Instalación/descarga: https://github.com/happier-dev/happier#how-it-works
• Discord (comunidad y soporte): https://discord.gg/W6Pb8KuHfg

Un ciclo de revisión que funciona

La versión de 2 minutos (móvil)

En el móvil, no intentes hacer "una revisión completa".

Haz una pasada con límites:

1. Repasa las filas de la línea temporal.
2. Salta al diff que parezca de más riesgo.
3. Decide: mantener / revertir / pedir un resumen.

Y para.

La versión de 10 minutos (teclado)

De vuelta al teclado, haz una pasada más profunda:

1. Revisa la lista de archivos cambiados.
2. Revisa los diffs por bloques.
3. Divide los cambios en commits.
4. Decide qué mantener tal cual y qué rehacer.

El resto de la guía hace que ambas pasadas sean predecibles.

1) Usa la herramienta de "resumen del diff" al final del turno (cuando aparezca)

En sesiones de Claude Code, Codex y OpenCode, Happier puede mostrar una herramienta de resumen del diff del último turno al final de un turno.

Cuando aparece, es un punto de partida con mucha información, porque ya está acotado a:

• "qué archivos cambiaron en el último turno"
• "qué editó realmente el agente"

Un buen procedimiento por defecto:

1. Toca el resumen del diff del último turno.
2. Abre primero el archivo que parezca de más riesgo.
3. Si se ve bien, sigue.
4. Si se ve raro, para y pide una justificación por archivo (o revierte solo ese archivo).

2) Revisa el último turno desde Control de versiones (la vista del "diff real")

Si quieres una revisión de verdad (no solo un vistazo), ve a Control de versiones (Source Control).

En escritorio o diseños anchos:

1. Abre la sesión.
2. Abre la barra lateral derecha → Control de versiones (Source Control).
3. En la lista de archivos cambiados, abre el archivo que te interesa.
4. Revisa el diff.

Si encuentras algo que quieres cambiar pero no quieres reescribir las instrucciones en el chat, añade comentarios de revisión por línea directamente en el diff.

Luego, cuando quieras convertir los comentarios en acciones:

• toca el selector Comentarios de revisión (N) (Review comments (N)) en el compositor
• si quieres, añade una frase de contexto ("aplica esto y vuelve a ejecutar las pruebas")
• envía

Eso produce un mensaje estructurado de "aplica exactamente estos cambios" en lugar de un ir y venir impreciso.

En el móvil o en diseños estrechos el flujo es el mismo, solo que usa una vista a pantalla completa en lugar de una barra lateral acoplada.

Cómo mantenerlo en "solo el último turno" en lugar de una "revisión sin límites":

• Empieza por la herramienta de resumen del diff del último turno, elige de 1 a 3 archivos y revisa esos mismos archivos en Control de versiones.
• Si la sesión lleva varios turnos, no intentes revisar todo lo que ahora mismo está sin commit.

3) Usa Archivos como "navegador acotado" (filtro de solo modificados)

La pestaña Archivos (Files) es útil cuando quieres una lista corta de lo que ha cambiado sin pensar en la semántica de Git.

1. Abre la sesión.
2. Abre la barra lateral derecha → Archivos (Files).
3. Activa el filtro de solo modificados.
4. Usa ese árbol reducido para saltar entre archivos.

Para una revisión seria del diff, toma la decisión final de "¿mantener o revertir?" en Control de versiones. Archivos es una buena forma de no perderte.

Así tienes una vista de revisión limpia que no requiere hacer scroll por la transcripción.

4) (Opcional) Usa la línea temporal de herramientas como índice del "¿por qué ha pasado esto?"

Si aún no tienes claro por qué cambió algo, la línea temporal de herramientas es una vista secundaria para responder:

• ¿qué comandos se ejecutaron?
• ¿qué salida dieron las instalaciones o las pruebas?
• ¿qué secuencia llevó al diff?

Pero es opcional: el resumen del diff + el diff de Control de versiones deberían bastar para la mayoría de las revisiones.

5) Decide cuánto detalle de las herramientas quieres (por encima o a fondo)

Trata los detalles de las herramientas como un zoom:

• Modo vistazo: lo justo para ver "qué herramientas se ejecutaron" y detectar pasos arriesgados.
• Modo a fondo: abre una llamada concreta cuando necesites el comando o la salida exactos.

La clave: que los "detalles de herramientas" no se conviertan en una segunda transcripción que relees sin fin.

6) Termina cada turno largo con una decisión (mantener / revertir / dividir)

La decisión de revisión al final del turno siempre es una de estas:

• mantenerlo todo
• revertir un archivo
• dividir los cambios en 2 commits

La clave es decidir de forma intencionada.

Una opción más que ayuda mucho (sobre todo en el móvil): deja comentarios de revisión en lugar de intentar "arreglarlo en directo".

Si algo está casi bien pero quieres un par de cambios precisos, a menudo es más rápido:

1. añadir unos cuantos comentarios de revisión por línea directamente en el diff
2. enviarlos como un único mensaje estructurado con el selector Comentarios de revisión (N)

Así el agente recibe una lista muy literal de qué cambiar, anclada a las líneas exactas que te importaban.

7) Una lista reutilizable de "¿qué ha cambiado?"

Si solo recuerdas una lista, que sea esta:

• ¿Qué archivos cambiaron?
• ¿Se tocó configuración, autenticación o migraciones?
• ¿Se ejecutaron pruebas?
• ¿Cambiaron las dependencias?
• ¿Hay algún resultado generado que no deba ir en el commit?

8) Pide el tipo de resumen adecuado (cuando el diff es demasiado grande)

Si el diff es demasiado grande para revisarlo en el móvil, no pidas "un resumen".

Pide una ayuda de revisión estructurada:

• "Enumera cada archivo que has cambiado y por qué, con una frase por archivo."
• "¿Qué cambios son mecánicos y cuáles conceptuales?"
• "¿Qué cambios se podrían revertir sin romper la build?"

Así la siguiente revisión con teclado será mucho más rápida.

Un flujo útil: comentarios de revisión en línea → un único mensaje estructurado de "aplica estos cambios"

Es útil al revisar desde el móvil o cuando quieres dejar claro exactamente qué debe cambiar.

En lugar de enviar un mensaje vago como "arregla el diff", puedes dejar comentarios de revisión por línea directamente en los diffs o archivos y luego enviarlos al agente como un único mensaje estructurado.

Flujo general:

1. Activa Comentarios de revisión de archivos (File review comments) en Configuración (Settings) → Características (Features) (es experimental).
2. Abre un diff (desde Control de versiones o cualquier vista de diff).
3. Añade unos cuantos comentarios de revisión en las líneas exactas que quieres cambiar.
4. Toca el selector Comentarios de revisión en el compositor (muestra Review comments (N)), añade una frase si quieres y envía.

El agente recibe un bloque estructurado "Review comments:" con rutas de archivo, anclas de línea y fragmentos, lo que hace mucho más probable que aplique los cambios con precisión en lugar de reescribir código no relacionado.

Si te parece "comentarios de revisión de un PR de GitHub, pero dentro de tu sesión", esa es justo la idea.

Solución de problemas

No consigo saber qué ha cambiado

• empieza por la línea temporal de herramientas
• luego salta a los diffs
• si no hay diffs disponibles, pide una lista por archivo con su justificación

La línea temporal tiene mucho ruido

Cambia a un modo de vistazo (compacto) y busca:

• herramientas de edición o escritura
• herramientas de git
• instalaciones

Me preocupa pasar por alto cambios arriesgados

Haz una pasada con "filtro de riesgo":

• migraciones
• autenticación
• archivos del gestor de paquetes
• configuración de CI

Aunque ignores todo lo demás, revisa eso.

Preguntas frecuentes

¿Debería revisar cada turno?

No cada turno.

Pero si un turno produjo cambios de archivos significativos, haz al menos la versión de 2 minutos.

¿Cuál es un error grave al revisar?

Dejar que la revisión no tenga límites.

El objetivo de un flujo con resumen del diff es que la revisión tenga un principio y un final.

Guías relacionadas

• Cómo hacer commit desde el móvil
• Cómo revisar diffs desde el móvil