Trampas del vibe coding en Flutter: 12 soluciones para lanzamientos más suaves

Por qué los proyectos Flutter fallan tarde cuando se construyen por chat

El "vibe coding" puede llevarte rápido a una demo Flutter clicable. Una herramienta como Koder.ai puede generar pantallas, flujos e incluso el cableado del backend desde un chat simple. Lo que no puede cambiar es lo exigente que son las apps móviles con la navegación, el estado, los permisos y los builds de release. Los teléfonos siguen funcionando en hardware real, con reglas reales del SO y requisitos reales de las tiendas.

Muchos problemas aparecen tarde porque solo los notas cuando sales del camino feliz. El simulador puede no coincidir con un Android de gama baja. Un build en debug puede ocultar problemas de timing. Y una función que se ve bien en una pantalla puede romperse al volver, perder la red o rotar el dispositivo.

Las sorpresas tardías suelen caer en unos pocos cubos, y cada uno tiene un síntoma reconocible:

• Problemas de navegación y estado: pantallas se reinician, volver cierra la app, los datos desaparecen al regresar
• Inconsistencias de API: una pantalla usa una base URL, headers o token distinto, así que “funciona aquí” pero falla en otro lugar
• Fallos en validación de formularios: registros aceptan input inválido, pagos fallan silenciosamente, los errores no se muestran donde el usuario los espera
• Trampas de permisos: cámara o notificaciones funcionan en un SO pero no en otro, o la app es rechazada por texto de uso faltante
• Cambios solo en release: crashes solo en release, assets faltantes, deep links rotos, arranque lento

Un modelo mental rápido ayuda. Una demo es “se ejecuta una vez”. Una app enviable es “sigue funcionando en la vida real desordenada”. “Hecho” suele significar que todo esto es verdad:

• Funciona en al menos un Android y un iPhone, no solo en un emulador
• Maneja offline y redes lentas con mensajes claros y reintento
• Mantiene el estado correctamente cuando mandas la app a segundo plano y vuelves
• Los permisos y los prompts del SO coinciden con lo que la app hace realmente
• Un build de release corre con llaves reales, firmado real y logging real

Una configuración simple que previene la mayoría de sorpresas tardías (paso a paso)

La mayoría de los momentos de "funcionaba ayer" ocurren porque el proyecto no tiene reglas compartidas. Con vibe coding puedes generar mucho rápido, pero aún necesitas un pequeño marco para que las piezas encajen. Esta configuración mantiene la velocidad mientras reduce problemas que aparecen tarde.

Una base de 30 minutos

1. Elige una estructura simple y síguela. Decide qué cuenta como pantalla, dónde vive la navegación y quién posee el estado. Un default práctico: las pantallas son delgadas, el estado lo posee un controlador a nivel de feature, y el acceso a datos pasa por una única capa (repositorio o servicio).

2. Fija unas convenciones temprano. Pon de acuerdo nombres de carpetas, convención de archivos y cómo se muestran los errores. Decide un único patrón para cargas asíncronas (loading, success, error) para que las pantallas se comporten de forma consistente.

3. Haz que cada feature venga con un mini plan de pruebas. Antes de aceptar una feature generada por chat, escribe tres comprobaciones: el camino feliz más dos casos límite. Ejemplo: “login funciona”, “muestra mensaje de contraseña incorrecta”, “offline muestra reintentar”. Esto captura problemas que solo aparecen en dispositivos reales.

4. Añade ahora placeholders de logging y crash reporting. Aunque no los actives aún, crea un punto de entrada de logging (para poder cambiar proveedores después) y un lugar donde se registren errores no capturados. Cuando un beta reporte un crash, querrás una pista.

5. Mantén una nota viviente de “lista para enviar”. Una página corta que revises antes de cada release evita pánicos de último minuto.

Si construyes con Koder.ai, pídele que genere la estructura inicial de carpetas, un modelo de error compartido y un wrapper de logging único primero. Luego genera features dentro de ese marco en vez de permitir que cada pantalla invente su propio enfoque.

Definición de listo para enviar (mantenlo corto)

Usa una checklist que realmente puedas seguir:

• La app arranca y se recupera de una llamada API fallida sin congelarse
• Los flujos principales funcionan con mal input (campos vacíos, email inválido, red lenta)
• Los permisos se solicitan sólo cuando se necesitan y se manejan si se niegan
• El build en modo release se construye (no solo debug) y pantallas clave son testeadas de forma básica
• Una persona puede instalar y usar la app en un dispositivo real sin guía

Esto no es burocracia. Es un pequeño acuerdo que evita que el código generado por chat derive en comportamiento de “pantalla de una sola vez”.

Problemas de navegación y estado que aparecen en dispositivos reales

Los bugs de navegación a menudo se esconden en una demo del camino feliz. Un dispositivo real añade gestos de retroceso, rotación, reanudar la app y redes más lentas, y de repente ves errores como “setState() called after dispose()” o “Looking up a deactivated widget’s ancestor is unsafe.” Estos problemas son comunes en flujos construidos por chat porque la app crece pantalla por pantalla, no con un plan global.

Los bugs que sientes en un teléfono

Un problema clásico es navegar con un contexto que ya no es válido. Sucede cuando llamas a Navigator.of(context) después de una petición asíncrona, pero el usuario ya salió de la pantalla, o el SO reconstruyó el widget tras una rotación.

Otro es el comportamiento de retroceso que “funciona en una pantalla”. El botón atrás de Android, el swipe atrás de iOS y los gestos del sistema pueden comportarse distinto, especialmente cuando mezclas diálogos, navegadores anidados (tabs) y transiciones de ruta personalizadas.

Los deep links añaden otra complicación. La app puede abrir directamente una pantalla de detalle, pero tu código aún asume que el usuario vino desde home. Entonces “atrás” los lleva a una página en blanco, o cierra la app cuando el usuario espera ver una lista.

Soluciones que previenen sorpresas tardías

Elige un enfoque de navegación y cúmplelo. Los mayores problemas vienen de mezclar patrones: unas pantallas usan rutas nombradas, otras empujan widgets directamente, otras gestionan stacks manualmente. Decide cómo se crean las rutas y escribe unas pocas reglas para que cada nueva pantalla siga el mismo modelo.

Haz la navegación asíncrona segura. Después de cualquier llamada await que pueda sobrevivir a la pantalla (login, pago, upload), confirma que la pantalla sigue viva antes de actualizar estado o navegar.

Guardrails que rinden rápido:

• Después de await, usa if (!context.mounted) return; antes de setState o navegar
• Cancela timers, streams y listeners en dispose()
• Evita almacenar BuildContext para uso posterior (pasa datos, no context)
• No empujes rutas desde callbacks en background a menos que manejes casos de “usuario se fue”
• Decide cuándo usar push, pushReplacement y pop para cada flujo (login, onboarding, checkout)

Para el estado, vigila valores que se resetean en rebuilds (rotación, cambio de tema, teclado abrir/cerrar). Si un formulario, pestaña seleccionada o posición de scroll importa, guárdalo en un lugar que sobreviva a rebuilds, no solo en variables locales.

Antes de considerar un flujo “listo”, haz una pasada rápida en un dispositivo real:

• Retroceso de Android desde cada pantalla, incluidos diálogos y bottom sheets
• Swipe atrás en iOS en pantallas clave (lista→detalle, ajustes→perfil)
• Rotar durante una carga y luego presionar atrás
• Mandar la app a segundo plano en medio de una petición y luego reanudar
• Abrir desde una notificación o deep link y verificar el comportamiento de atrás

Si construyes apps Flutter vía Koder.ai o cualquier flujo guiado por chat, haz estas comprobaciones pronto mientras las reglas de navegación aún son fáciles de imponer.

Consistencia del cliente API: evita bugs de “funciona en una pantalla”

Un rompedor tardío común es cuando cada pantalla habla con el backend de forma ligeramente distinta. El vibe coding facilita esto por accidente: pides una “llamada de login rápida” en una pantalla, luego “traer perfil” en otra, y terminas con dos o tres setups HTTP que no coinciden.

Una pantalla funciona porque usa la base URL y headers correctos. Otra falla porque apunta a staging, olvida un header o manda el token en otro formato. El bug parece aleatorio, pero normalmente es solo inconsistencia.

Puntos que causan “funciona en una pantalla”

Estos aparecen una y otra vez:

• Múltiples clientes HTTP con diferentes base URLs, timeouts o headers por defecto
• Lógica de refresh de auth inconsistente, provocando bucles 401 o cierres de sesión silenciosos
• Parseo y manejo de errores distinto por pantalla, de modo que el mismo error backend se transforma en tres mensajes distintos
• Estilos mixtos de parsing JSON (maps dinámicos en un lugar, modelos tipados en otro), causando crashes en algunas respuestas

Solución: un cliente, un contrato, una única forma de fallar

Crea un único cliente API y haz que cada feature lo use. Ese cliente debe poseer base URL, headers, almacenamiento de token, flujo de refresh, reintentos (si aplica) y logging de peticiones.

Mantén la lógica de refresh en un solo lugar para poder razonar sobre ella. Si una petición recibe un 401, refresca una vez y vuelve a reproducir la petición una vez. Si el refresh falla, fuerza el logout y muestra un mensaje claro.

Los modelos tipados ayudan más de lo que se espera. Define un modelo para respuestas exitosas y otro para errores para no adivinar lo que el servidor envió. Mapea errores a un pequeño conjunto de resultados a nivel de app (no autorizado, error de validación, error de servidor, sin red) para que cada pantalla se comporte igual.

Para logging, registra método, ruta, código de estado y un request ID. Nunca registres tokens, cookies o payloads completos que puedan contener contraseñas o datos de tarjeta. Si necesitas logs del body, redácta campos como “password” y “authorization”.

Ejemplo: una pantalla de signup tiene éxito, pero “editar perfil” falla con un bucle 401. Signup usó Authorization: Bearer <token>, mientras perfil mandó token=<token> como query param. Con un cliente compartido, ese desajuste no puede ocurrir, y depurar es tan simple como emparejar un request ID con un camino de código.

Fallos de validación de formularios que causan registros y pagos fallidos

Muchas fallas del mundo real ocurren dentro de formularios. Los formularios suelen verse bien en una demo pero fallan con input real. El resultado es costoso: registros que nunca se completan, campos de dirección que bloquean el checkout, pagos que fallan con errores vagos.

El problema más común es la descoordinación entre reglas de la app y reglas del backend. La UI puede permitir una contraseña de 3 caracteres, aceptar un teléfono con espacios o tratar un campo opcional como obligatorio, y luego el servidor lo rechaza. Los usuarios solo ven “Algo salió mal”, lo intentan otra vez y terminan abandonando.

Trata la validación como un pequeño contrato compartido en la app. Si generas pantallas por chat (incluido Koder.ai), sé explícito: pide las restricciones exactas del backend (min/max length, caracteres permitidos, campos requeridos y normalización como trim). Muestra errores en lenguaje claro junto al campo, no solo en un toast.

Otro fallo es la diferencia de teclados entre iOS y Android. El autocorrect añade espacios, algunos teclados cambian comillas o guiones, teclados numéricos pueden no incluir caracteres que asumiste (como el signo +), y copiar/pegar trae caracteres invisibles. Normaliza la entrada antes de validar (trim, colapsar espacios repetidos, eliminar espacios de no separación) y evita regex demasiado estrictos que castiguen la escritura normal.

La validación asíncrona también crea sorpresas tardías. Ejemplo: compruebas “¿este email ya está usado?” en blur, pero el usuario pulsa Enviar antes de que la petición devuelva. La pantalla navega, luego el error llega y aparece en una página que el usuario ya dejó.

Qué previene esto en la práctica:

• Mantén una única fuente de verdad para el estado del formulario, siguiendo isSubmitting y pendingChecks
• Deshabilita Submit hasta que el formulario sea válido y no haya checks asíncronos pendientes
• Cancela o ignora respuestas asíncronas obsoletas usando un request ID o la lógica de “gana el valor más reciente”
• Muestra un error claro por campo, más un resumen corto para errores del servidor

Para probar rápido, ve más allá del camino feliz. Intenta un pequeño conjunto de entradas brutales:

• Enviar vacío para cada campo requerido
• Valores al borde (longitud mínima, máxima, un carácter de más)
• Copiar/pegar con espacios iniciales y finales
• Números telefónicos internacionales y direcciones fuera de EE. UU.
• Red lenta (checks asíncronos devolviendo tarde)

Si esto pasa, los registros y pagos tienen mucha menos probabilidad de romper justo antes del lanzamiento.

Permisos de plataforma: trampas comunes en Android e iOS

Los permisos son una causa principal de bugs que “funcionaban ayer”. En proyectos construidos por chat, una feature se añade rápido y las reglas de la plataforma se olvidan. La app corre en un simulador y luego falla en un teléfono real, o solo falla después de que el usuario pulsa “No permitir”.

Dónde suelen atascarse los equipos

Una trampa es omitir declaraciones en la plataforma. En iOS debes incluir un texto de uso claro explicando por qué necesitas cámara, ubicación, fotos, etc. Si falta o es vago, iOS puede bloquear el prompt o la revisión de App Store puede rechazar la build. En Android, entradas faltantes en el manifest o usar el permiso equivocado para la versión del SO puede hacer que las llamadas fallen silenciosamente.

Otra trampa es tratar el permiso como una decisión única. Los usuarios pueden negar, revocar luego en Ajustes o elegir “No preguntar más” en Android. Si tu UI espera un resultado indefinidamente, obtendrás una pantalla congelada o un botón que no hace nada.

Las versiones del SO se comportan distinto también. Las notificaciones son un ejemplo clásico: Android 13+ requiere permiso en runtime, versiones anteriores no. Fotos y acceso a almacenamiento cambiaron en ambas plataformas: iOS tiene “fotos limitadas”, y Android tiene permisos “media” nuevos en lugar de almacenamiento amplio. La ubicación en background es una categoría aparte y suele necesitar pasos extra y una explicación más clara.

Maneja permisos como una pequeña máquina de estados, no como un único check sí/no:

• Solicita solo cuando el usuario active la función (no al lanzar la app)
• Si se niega, muestra una explicación breve y ofrece “Intentar de nuevo”
• Si está denegado permanentemente, explica cómo activarlo en Ajustes y proporciona un fallback seguro
• Trata “limited” (fotos en iOS) como un estado válido, no como un error

Luego prueba las superficies principales de permisos en dispositivos reales. Una checklist rápida atrapa la mayoría de sorpresas:

• Cámara: abrir cámara, tomar foto, cancelar, reintentar
• Fotos/storage: seleccionar una imagen, manejar “fotos limitadas” en iOS
• Notificaciones: prompt en Android 13+ y verificar que llegue una notificación real
• Ubicación: while-in-use vs background, y “precisa” vs “aproximada” en iOS
• Cambios en Ajustes: negar primero, luego habilitar y confirmar que la app se recupera

Ejemplo: añades “subir foto de perfil” en una sesión de chat y funciona en tu teléfono. Un usuario nuevo deniega acceso a fotos una vez y el onboarding no puede continuar. La solución no es pulir la UI. Es tratar “denegado” como un resultado normal y ofrecer un fallback (saltar foto o continuar sin ella), pidiendo permiso solo cuando el usuario lo intente.

Si generas código Flutter con una plataforma como Koder.ai, incluye permisos en la checklist de aceptación para cada feature. Es más rápido añadir declaraciones y estados correctos de inmediato que perseguir un rechazo de la tienda o una pantalla de onboarding atascada después.

Problemas de build de release: qué cambia cuando publicas

Una app Flutter puede verse perfecta en debug y aun así romperse en release. Los builds de release quitan helpers de debug, encogen código y aplican reglas más estrictas sobre recursos y configuración. Muchos issues solo aparecen después de cambiar ese switch.

Debug funciona, release crashea

En release, Flutter y la toolchain de la plataforma son más agresivos al eliminar código y assets que parecen no usarse. Esto puede romper código basado en reflexión, parseo JSON “mágico”, nombres dinámicos de iconos o fuentes que nunca fueron declaradas correctamente.

Un patrón común: la app arranca y luego crashea tras la primera llamada API porque un archivo de configuración o una key se cargó desde una ruta solo de debug. Otro: una pantalla que usa un nombre de ruta dinámico funciona en debug pero falla en release porque la ruta nunca se referencia directamente.

Ejecuta un build de release temprano y a menudo, y observa los primeros segundos: comportamiento de arranque, primera petición de red, primera navegación. Si solo pruebas con hot reload, te pierdes el comportamiento de cold-start.

Flavors y variables de entorno que no existen en release

Los equipos suelen probar contra una API dev y asumir que la configuración de producción “simplemente funcionará”. Pero los builds de release pueden no incluir tu archivo de env, pueden usar un applicationId/bundleId distinto o no tener la configuración correcta para push notifications.

Cheques rápidos que previenen la mayoría de sorpresas:

• Construir e instalar un build de release en un dispositivo real (no solo emulador)
• Verificar el firmado y el package name correcto para cada flavor
• Confirmar base URL, API keys y flags de analytics sean las de producción
• Probar login, logout y refresh de token desde una instalación limpia
• Confirmar que deep links y push abren la pantalla correcta

Las “tareas tardías” que se vuelven bloqueadores

Tamaño de la app, iconos, pantallas de splash y versionado a menudo se postergan. Entonces descubres que tu release es enorme, el icono está borroso, el splash está recortado o el número de versión/build es incorrecto para la tienda.

Haz esto antes de lo que crees: configura iconos de app correctos para Android e iOS, confirma que el splash se ve bien en pantallas pequeñas y grandes, y decide reglas de versionado (quién incrementa qué y cuándo).

Antes de enviar, prueba condiciones malas a propósito: modo avión, red lenta y un cold start después de matar la app completamente. Si la primera pantalla depende de una llamada de red, debe mostrar un estado de carga claro y un reintento, no una página en blanco.

Si generas apps Flutter con una herramienta guiada por chat como Koder.ai, añade “ejecutar build de release” a tu loop normal, no al último día. Es la manera más rápida de capturar issues reales mientras los cambios aún son pequeños.

12 errores comunes de vibe coding (y cómo evitarlos)

Los proyectos Flutter generados por chat suelen romper tarde porque los cambios parecen pequeños en un chat, pero tocan muchas piezas en una app real. Estos errores suelen convertir una demo limpia en un release desordenado.

1. Agregar features sin actualizar el plan de estado y flujo de datos. Si una nueva pantalla necesita los mismos datos, decide dónde viven esos datos antes de pegar código.

2. Aceptar código generado que no encaja con tus patrones. Si tu app usa un estilo de routing o un enfoque de estado, no aceptes una pantalla nueva que introduzca un segundo.

3. Crear llamadas API “one-off” por pantalla. Pon las peticiones detrás de un único cliente/servicio para no acabar con cinco headers/base URLs/errores ligeramente distintos.

4. Manejar errores solo donde los notaste. Define una regla consistente para timeouts, modo offline y errores de servidor para que cada pantalla no tenga que adivinar.

5. Tratar warnings como ruido. Las pistas del analyzer, deprecaciones y mensajes de “esto será removido” son alertas tempranas.

6. Asumir que el simulador equivale a un teléfono real. Cámara, notificaciones, reanudar en background y redes lentas se comportan distinto en dispositivos reales.

7. Hardcodear strings, colores y espacios en widgets nuevos. Pequeñas inconsistencias se acumulan y la app empieza a sentirse parcheada.

8. Permitir que la validación de formularios varíe por pantalla. Si un formulario hace trim y otro no, tendrás fallos de “funciona para mí”.

9. Olvidar permisos de plataforma hasta que la feature esté “lista”. Una feature que necesita fotos, ubicación o archivos no está lista hasta que funciona con permisos negados y aceptados.

10. Confiar en comportamiento exclusivo de debug. Algunos logs, assertions y ajustes de red relajados desaparecen en release.

11. Omitir limpieza tras experimentos rápidos. Flags antiguos, endpoints sin usar y ramas de UI muertas causan sorpresas semanas después.

12. No tener quien tome la “decisión final”. El vibe coding es rápido, pero alguien aún necesita decidir naming, estructura y “así lo hacemos”.

Una forma práctica de mantener la velocidad sin caos es una revisión pequeñísima después de cada cambio significativo, incluidas las modificaciones generadas en herramientas como Koder.ai:

• Confirma que el nuevo código sigue tu patrón de routing y estado
• Verifica que las llamadas API pasan por el mismo cliente y manejo de errores
• Ejecuta el analyzer y corrige los nuevos warnings inmediatamente
• Prueba el camino feliz y un camino de fallo (offline, input inválido, permiso denegado)
• Haz una rápida ejecución en dispositivo real antes de apilar más features encima

Escenario ejemplo: de demo a listo para tienda sin reescribir todo

Un equipo pequeño construye una app Flutter simple chateando con una herramienta: login, un formulario de perfil (nombre, teléfono, cumpleaños) y una lista de items traída desde una API. En una demo todo parece bien. Luego las pruebas en dispositivo real comienzan y aparecen los problemas habituales de golpe.

El primer issue aparece justo después del login. La app empuja la pantalla home, pero el botón atrás regresa al login, y a veces la UI parpadea mostrando la pantalla vieja. La causa suele ser estilos de navegación mezclados: algunas pantallas usan push, otras replace, y el estado de auth se revisa en dos sitios.

Luego viene la lista de la API. Carga en una pantalla, pero otra pantalla recibe errores 401. Existe refresh de token, pero solo un cliente API lo usa. Una pantalla usa una llamada HTTP cruda, otra usa un helper. En debug, el timing más lento y datos cacheados pueden ocultar la inconsistencia.

Después el formulario de perfil falla de una manera muy humana: la app acepta un formato de teléfono que el servidor rechaza, o permite cumpleaños vacío mientras el backend lo requiere. Los usuarios pulsan Guardar, ven un error genérico y se van.

Una sorpresa de permisos llega tarde: el prompt de notificaciones en iOS aparece en el primer lanzamiento sobre el onboarding. Muchos usuarios pulsan “No permitir” solo para continuar, y luego se pierden actualizaciones importantes.

Finalmente, el build de release rompe aunque debug funcione. Causas comunes: config de producción faltante, base URL distinta o settings de build que eliminan algo necesario en runtime. La app se instala y luego falla silenciosamente o se comporta distinto.

Así arregla el equipo todo en un sprint sin reescribir:

• Congelan el scope, exportan el código actual y trabajan desde un snapshot limpio para que los cambios sean fáciles de revertir
• Crean una única fuente de verdad para el estado de auth (y una regla de navegación: reemplazar login por home al lograr auth)
• Estandarizan en un único cliente API con interceptores para headers, refresh y mapeo consistente de errores
• Alinean reglas de formularios con el servidor (mismos campos requeridos, mismos formatos, mensajes claros a nivel de campo)
• Mueven prompts de permisos al momento en que se necesitan y verifican un build de release completo en dispositivos reales

Herramientas como Koder.ai ayudan aquí porque puedes iterar en modo planificación, aplicar fixes como parches pequeños y mantener el riesgo bajo probando snapshots antes de comprometer el siguiente cambio.

Chequeos rápidos y próximos pasos antes de enviar

La manera más rápida de evitar sorpresas tardías es hacer las mismas comprobaciones cortas para cada feature, incluso cuando la construiste rápido por chat. La mayoría de problemas no son “bugs grandes”. Son pequeñas inconsistencias que solo aparecen cuando las pantallas se conectan, la red es lenta o el SO dice “no”.

Antes de marcar cualquier feature como “hecha”, haz una pasada de dos minutos por los puntos habituales conflictivos:

• ¿Puedes alcanzar la pantalla desde un inicio en frío y volver sin bucles raros?
• ¿El estado se posee en un lugar (no se recrea en cada rebuild) y sobrevive a la navegación?
• ¿La llamada API usa el mismo cliente, base URL, headers y timeout que el resto de la app?
• ¿Los formularios validan antes de enviar, muestran mensajes claros y bloquean doble tap mientras cargan?
• Si necesita permisos, ¿probaste los flujos “Permitir” y “No permitir”?

Luego ejecuta un chequeo enfocado en release. Muchas apps parecen perfectas en debug y fallan en release por firmado, settings más estrictos o texto de permisos faltante:

• Construye y ejecuta un build de release y prueba los flujos principales de punta a punta
• Prueba en dos dispositivos reales (uno más antiguo y uno más nuevo) con distintos tamaños de pantalla
• Confirma versión, número de build y configuraciones de firmado correctas
• Verifica declaraciones de permisos en plataforma (AndroidManifest, Info.plist de iOS)
• Al reportar un bug, captura pasos para reproducir, modelo y versión del SO, logs y estado de red (Wi‑Fi vs celular)

Patch vs refactor: parchea si el issue está aislado (una pantalla, una llamada API, una regla de validación). Refactoriza si ves repeticiones (tres pantallas usando tres clientes distintos, lógica de estado duplicada o rutas que no concuerdan).

Si usas Koder.ai para un build guiado por chat, su modo planificación es útil antes de cambios grandes (como cambiar gestión de estado o routing). Snapshots y rollback también valen la pena antes de ediciones riesgosas, para poder revertir rápido, enviar un fix pequeño y mejorar la estructura en la siguiente iteración.