# Previsualizar cambios antes de aplicar: diffs, vistas previas y revisión > Previsualizar cambios de un agente de IA es revisarlos antes de que ocurran. Qué mostrar en un diff, qué hacer con acciones sin texto y cuándo basta un resumen. *Tags: ia, agentes, ux, revision* --- > [!info] Definición Rápida > **Previsualizar cambios antes de aplicar** es mostrar a la persona qué va a modificar un agente de IA antes de que el cambio ocurra, normalmente como un diff o una lista de efectos. Permite aprobar, corregir o rechazar con información, en vez de descubrir el resultado después. ## ¿Qué problema resuelve la vista previa? Un agente que escribe código o texto produce cambios que la persona debe entender. Si solo ve el resultado final, no sabe qué se perdió, qué se reescribió por error o qué cambió más de lo esperado. Si ve el cambio antes, puede revisar la intención y el alcance en segundos. La vista previa también separa dos momentos que suelen mezclarse: decidir si el cambio es correcto y aplicarlo. Cuando el sistema los une, la persona aprueba lo que cree que va a pasar, no lo que va a pasar. ## ¿Qué debe mostrar un buen diff? Un diff, la comparación entre el estado anterior y el propuesto, es la forma clásica para código y texto. Para que sirva a una persona que no programa, conviene mostrar: 1. **Qué archivos o elementos cambian.** Una lista corta primero, con el número de líneas o de cambios por cada uno. 2. **El antes y el después.** Solo las partes modificadas, con contexto suficiente para entender la línea, no el archivo entero. 3. **El motivo.** Una frase del agente sobre por qué hizo ese cambio, asociada al bloque. 4. **Lo que no cambia.** A veces importa saber que el resto del archivo quedó igual. El orden importa. Una persona que abre un diff de 600 líneas sin resumen tarda en encontrar lo que importa. Un resumen de "tres archivos, dos cambios de texto, una nueva dependencia" orienta antes de mostrar el detalle. ## ¿Qué hacer con acciones sin texto? Un pago, un envío de correo, un cambio de estado en un sistema de terceros o un registro en una base de datos no tienen un diff natural. Para esos casos, la vista previa debe describir el efecto en lenguaje claro: - **Qué se va a hacer, en una frase.** "Enviar un correo a 42 clientes con el asunto X". - **A quién o a qué afecta.** Destinatarios, cuentas, montos, fechas. - **Qué no se puede deshacer.** Dicho sin rodeos. - **Un ejemplo real.** Un correo de muestra con datos de una persona, o el cargo de un caso concreto, para validar el texto antes del envío masivo. Esa vista es parte del [[human-in-the-loop|diseño con control humano]]: la persona ve el efecto, no solo la intención del agente. ## ¿Cuándo basta un resumen? Si los cambios son repetitivos y de bajo riesgo, un diff completo de cada uno agota a la persona. Por ejemplo, renombrar cincuenta archivos con el mismo patrón. En ese caso conviene mostrar el patrón (de qué a qué), la lista de afectados y tres o cuatro casos de muestra. Si la muestra está bien, el lote se aprueba. Si una de las muestras sorprende, se abre el detalle. Hay una trampa en esto: el resumen tiene que decir cuántos cambios hay. Un lote de "algunos archivos" que en realidad son trescientos no es una vista previa. ## ¿Cómo lo resuelven las herramientas reales y cómo se conecta con deshacer? La vista previa reduce la necesidad de deshacer, pero no la elimina: un cambio aprobado puede resultar malo después. Por eso conviene que el cambio aprobado deje un punto de restauración o un commit. La página sobre [[deshacer-acciones-de-agentes|deshacer lo que hizo un agente]] describe esa segunda línea de defensa, y [[git-para-disenadores|Git para diseñadores]] explica el commit. Dos herramientas muestran cómo se reparte la revisión: - **Claude Code.** Según su documentación, el aviso de permiso muestra qué va a hacer Claude, seguido de las opciones para aprobar o rechazar. En el modo de edición automática (`acceptEdits`), Claude crea y edita archivos del directorio de trabajo sin preguntar; la documentación lo recomienda cuando prefieres revisar los cambios después, en tu editor o con `git diff`, en vez de aprobar cada edición. El modo plan es otra vista previa: Claude investiga y propone cambios sin editar tus archivos, y las ediciones quedan bloqueadas hasta que apruebas el plan (más en [[modo-plan|modo plan]]). Sus checkpoints solo siguen las ediciones hechas con sus herramientas de edición de archivos: los cambios por comandos de terminal o de otras sesiones normalmente no se registran, y la documentación aclara que no sustituyen al control de versiones. - **Replit Agent.** Según su documentación, cada tarea en segundo plano corre en una copia aislada del proyecto y no cambia la versión principal hasta que revisas su registro de trabajo, los resultados de pruebas y la vista previa en vivo, y decides aplicarla o descartarla. La diferencia entre ambas es la que el diseño debe explicar: qué se revisa antes y qué se acepta por confianza. Las reglas que deciden cuándo aparece cada aviso están en [[ux-de-permisos-de-agentes|UX de permisos para agentes]], y la pregunta concreta de aprobación, en [[aprobacion-de-acciones|aprobación de acciones]]. ## Ejemplo Ejemplo ilustrativo: un agente propone cambiar el texto de un botón de pago en la página de checkout. La persona recibe un diff con dos líneas modificadas, el motivo "el texto actual confunde con el plan de prueba" y una aclaración: "No cambia la lógica de cobro". Ella aprueba el texto, pero rechaza un segundo cambio que el agente agregó en el mismo lote: un ajuste al valor del impuesto. El diff lo mostraba con su motivo, y la persona lo vio porque el resumen decía "dos cambios de texto, un cambio de valor". Sin esa línea de resumen, el cambio de impuesto habría pasado escondido entre los cambios de texto. ## ¿Cuándo NO conviene una vista previa completa? - Cuando la acción es reversible, interna y de bajo impacto. Revisar cada línea de un borrador que nadie va a usar es perder tiempo. - Cuando la vista previa es tan larga que nadie la lee. Mejor un resumen con opción de ver el detalle. - Cuando la persona no puede juzgar el contenido. En ese caso, la vista previa tiene que venir con una explicación o con alguien que sí entienda. ## Errores comunes - Mostrar un diff sin resumen, para cambios grandes. - Mostrar el resultado final sin el antes. - Decir "cambios menores" cuando hay cambios de valor, de precio o de destinatario. - Aplicar el lote tras aprobar una muestra que no era representativa. - Presentar un diff de código a alguien que necesita entender el efecto en su negocio. ## Fuentes - [Configure permissions (Claude Code, documentación)](https://code.claude.com/docs/en/permissions) - [Choose a permission mode (Claude Code, documentación)](https://code.claude.com/docs/en/permission-modes) - [Checkpointing (Claude Code, documentación)](https://code.claude.com/docs/en/checkpointing) - [Task system (Replit Docs)](https://docs.replit.com/core-concepts/agent/task-system) --- Source: https://www.fernandoux.com/es/wiki/ia/previsualizar-cambios/