Aprende el patrón “no cambiar” para hacer una pequeña actualización manteniendo congelados los flujos críticos, reglas de negocio y comportamientos esenciales, evitando deriva.
Un cambio “pequeño” rara vez se mantiene pequeño. Pides ajustar la etiqueta de un botón, y de repente el diseño de la página se desplaza, un formulario deja de validar o un paso de checkout se comporta de forma distinta. Las apps son sistemas conectados. UI, lógica, datos e integraciones dependen unos de otros.
Una causa frecuente son los límites poco claros. Si una solicitud dice “haz el registro más simple”, la persona (humana o IA) tiene que adivinar qué significa “más simple”. Adivinar conduce a ediciones extra: quitar campos, cambiar pasos, ajustar copys o reescribir validaciones. Otra causa son las dependencias ocultas. Un pequeño cambio visual puede reutilizar un componente que aparece en cinco pantallas distintas.
Una iteración segura significa que obtienes la mejora prevista mientras todo lo demás permanece efectivamente idéntico. Para un equipo no técnico, eso quiere decir que el flujo sigue sintiéndose igual para los usuarios, los scripts de soporte siguen coincidiendo con el producto y los informes siguen teniendo sentido. Para un equipo técnico, significa no introducir cambios inesperados en rutas, shapes de datos, contratos de API o comportamientos en casos límite.
Para que eso sea posible, debes congelar lo que no se puede mover. En la práctica, eso suele incluir flujos críticos (los pasos exactos que recorren los usuarios), detalles de UI/UX (diseño, espaciado, comportamiento de interacción), reglas de negocio (precios, permisos, validaciones), comportamiento de datos (qué se almacena y cuándo) e integraciones (eventos de analytics, emails, pagos, APIs externas).
Este patrón de "no cambiar" reduce el riesgo al eliminar la conjetura y mantener el cambio acotado. No es una garantía. Aún puedes tener deriva si el comportamiento original está mal definido, si el cambio toca componentes compartidos o si no verificas el resultado. El objetivo es menos sorpresas y aprobaciones más rápidas.
El patrón “no cambiar” es una forma simple de pedir una actualización específica mientras bloqueas claramente todo lo demás. Nombras el único cambio que quieres y luego escribes una lista corta de congelados con las partes que deben permanecer idénticas tras la actualización.
Esto importa porque los modelos suelen intentar ser útiles refactorizando, renombrando, reorganizando archivos o “limpiando” lógica al tocar el código. Incluso si la salida sigue funcionando, esos cambios adicionales pueden introducir bugs, modificar comportamientos o complicar las revisiones.
Compara estas dos solicitudes:
“Mejora la página de ajustes.” Esto invita a cambios de diseño, copys nuevos, desplazamientos de layout y ajustes lógicos.
“Cambia solo el texto de la etiqueta de ‘Teléfono’ a ‘Teléfono móvil’. No cambies el layout, la validación ni el comportamiento de guardado.” Esto es estrecho, comprobable y más seguro.
Una buena lista de congelados suele cubrir tres áreas:
Cuando usas este patrón en una herramienta de construcción basada en chat como Koder.ai, las iteraciones tienden a moverse más rápido porque el modelo se concentra en la edición única en lugar de hacer “mejoras” amplias que no pediste.
Este patrón funciona mejor cuando tu solicitud se lee como un pequeño contrato: un objetivo claro, una lista de congelados y algunas comprobaciones para confirmar el resultado.
Copia esta plantilla y rellena los corchetes. Manténla corta pero específica.
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -> checkout -> receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
1) [a simple before/after check]
2) [a user path that must still work]
3) [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
Un ejemplo concreto: si quieres cambiar el color del botón de checkout, tu objetivo es “Actualizar el color del botón primario de checkout a #1A73E8.” Tus items DO NOT CHANGE deberían congelar todo el flujo de checkout, el texto del botón y el cálculo de precios.
Si usas Koder.ai, este formato también agiliza las revisiones porque puedes comparar las comprobaciones de aceptación contra la vista previa y el resumen de cambios antes de aprobar nada.
Cuando pides un cambio pequeño, no digas simplemente “no rompas nada.” Nombra los recorridos de usuario exactos que deben comportarse igual, desde el primer clic hasta el resultado final. No estás congelando toda la app; estás congelando las partes donde las regresiones hacen daño.
Empieza listando los flujos críticos en lenguaje llano: login (incluyendo restablecimiento de contraseña), onboarding, checkout, ajustes. Para cada flujo, indica cómo se ve “hecho”. Ejemplo: “El usuario puede iniciar sesión con email + contraseña, aterriza en el Dashboard y permanece autenticado tras refrescar.”
Luego bloquea los casos borde que la gente olvida. El comportamiento del botón atrás es una fuente clásica de deriva: “Atrás desde Checkout vuelve al Carrito (no al Home), y los artículos del carrito permanecen.” Señala estados de error (“contraseña incorrecta muestra el mismo mensaje”), estados vacíos (“sin proyectos muestra el mismo texto”) y estados de carga (“spinner aparece en 200ms, sin salto de layout”).
Si la performance y la seguridad importan, congélalas también. Si no las mencionas, el modelo puede “mejorar” añadiendo llamadas extra, nuevo logging o cambiando cheques de auth.
Una forma concisa de especificarlo sin escribir una novela:
Sé específico sobre el flujo de datos en una frase por ítem. Por ejemplo: “La dirección se guarda solo tras pulsar Guardar, se almacena en el registro de perfil de usuario y debe persistir tras cerrar sesión/iniciar sesión.” Ese nivel de detalle evita autosaves accidentales, campos nuevos o cambios de timing que rompen usuarios reales.
La deriva de UI suele ocurrir porque el modelo “útilmente” limpia estilos, espaciado o estructura de componentes. La solución es la misma que con la lógica: nombra lo que debe permanecer idéntico y nombra lo único que puede cambiar.
Fija la estructura visible. Señala layout (columnas/filas, ubicación del header y footer), reglas de espaciado (padding, gaps, alineación) y comportamiento de los componentes (hover, estado deshabilitado, spinners, mensajes de error). Si un componente tiene un “feeling” específico, dilo claramente: “Tamaño, radio y color del botón deben permanecer exactamente igual.”
El comportamiento responsive necesita reglas explícitas. Si no mencionas móvil, las herramientas pueden “mejorarlo”. Indica los breakpoints que te importan y qué debe ocurrir en cada uno: orden de apilado, elementos ocultos, barras fijas y objetivos de toque.
También congela las palabras. Indica al modelo que todo el copy, las etiquetas, los placeholders y los textos de ayuda deben mantenerse sin cambios, salvo la única etiqueta que estás editando. Esto evita reescrituras silenciosas que cambian el significado.
Un prompt compacto que puedes pegar en una solicitud de cambio:
Si puedes, pide capturas antes/después. Si no hay capturas, solicita una breve “diferencia UI” (qué se movió, qué cambió de tamaño, qué color cambió) para aprobar con confianza.
Las reglas de negocio son uno de los sitios donde un pequeño cambio de UI puede crear una regresión silenciosa. Una actualización de etiqueta puede cambiar accidentalmente un cálculo, una transición de estado o quién puede ver un registro. Trata las reglas y el comportamiento de datos como contratos congelados.
Empieza por nombrar las pocas reglas cuya deriva causaría más daño. Escríbelas como tests: entradas, salidas y quién puede hacer qué.
En lugar de “mantener precios igual”, fíjalo:
Añade un ejemplo numérico para eliminar la interpretación. Por ejemplo: “Subtotal del pedido $120, descuento 10% (aplica antes de impuestos), impuesto 8.25% sobre el monto con descuento. Total esperado = (120 - 12) * 1.0825 = $116.91. Redondeo a 2 decimales solo en el total final.”
Señala la visibilidad basada en roles, no solo las acciones. Ejemplo: “Los agentes de soporte pueden ver estado y email del pedido, pero no deben ver los detalles completos de la tarjeta. Solo los admins pueden emitir reembolsos.”
Si las validaciones importan, congélalas explícitamente. Menciona el trigger exacto y el mensaje que aparece al usuario: “Si la fecha de inicio es posterior a la fecha de fin, bloquear guardar y mostrar: ‘La fecha de fin debe ser posterior a la fecha de inicio.’ No cambiar este texto.”
No olvides los efectos fuera de la app. Si envías emails, webhooks o llamas APIs de terceros, congela qué debe permanecer igual: nombres de eventos, campos del payload, timing (inmediato vs retrasado) y comportamiento idempotente (sin envíos duplicados en reintentos).
Trata una pequeña actualización como un mini contrato. El patrón funciona mejor cuando el cambio es estrecho y todo lo demás está explícitamente congelado.
Escribe el cambio como una frase comprobable. “En la página de ajustes, añade un toggle para activar modo oscuro” es comprobable. “Mejorar la UI de ajustes” no lo es. Si no puedes probarlo en 30 segundos, sigue siendo demasiado amplio.
Escribe una lista de congelados para las partes que causarían daño si se desviaran: flujo de usuario, elementos UI clave, reglas de negocio, comportamiento de datos y APIs o tablas que deben permanecer igual.
Añade checks de aceptación y un plan de prueba rápido. Aquí previenes sorpresas del tipo “funciona en mi entorno”. Incluye verificaciones como: el nuevo toggle aparece, los ajustes existentes siguen guardándose y nada más en la página se mueve.
Antes de empezar a editar, pide al asistente que repita tus restricciones. Que confirme qué cambiará y qué debe permanecer idéntico. Si el resumen está mal, corrige el prompt antes de permitir cambios.
Solicita la implementación más pequeña posible: sin refactors, sin renombrados, sin cambios de formato más allá de las líneas tocadas. Compras un cambio, no un rediseño.
Una lista corta para revisar:
Esto funciona especialmente bien en Koder.ai: pega la lista de congelados en Planning Mode, pide que la repita, y luego genera el parche mínimo.
La mayoría de las ediciones “pequeñas” salen mal por la misma razón: la solicitud protege el objetivo, pero no el comportamiento. Un modelo puede alcanzar tu objetivo de una forma nueva que cambie pantallas, lógica o datos sin que te des cuenta.
Una trampa común es congelar el resultado (“hacer el onboarding más fluido”) en lugar de los pasos exactos que recorren los usuarios. Otra es escribir “mantener todo igual” y asumir que el sistema sabe qué significa.
Errores que más causan deriva:
Un ejemplo pequeño: pides “hacer el botón más visible” y congelas el color, pero olvidas congelar el estado deshabilitado. La actualización podría habilitar siempre el botón, cambiando el comportamiento de forma que solo notas más tarde.
Lo que ayuda es ser específico sobre lo que no puede moverse. Antes de aceptar la actualización, haz una rápida verificación de regresión:
Si algo difiere, la solicitud carecía de un detalle congelado, no fue “mal código”.
Una iteración segura común es una pequeña mejora visual donde el flujo no puede cambiar.
Escenario: un fundador tiene una pantalla de registro simple con un formulario corto (Nombre, Email, Tamaño de compañía) y un botón primario que envía el formulario y lleva al usuario al dashboard.
Solicitud exacta (una frase): “Renombrar el botón primario de 'Create account' a 'Continue' y cambiar el campo 'Company size' de entrada libre a un dropdown.”
Ahora aplica el patrón congelando lo que debe permanecer idéntico:
Checks de aceptación que puedes correr en minutos:
Una buena respuesta del asistente debe repetir los ítems congelados, confirmar ambigüedades (por ejemplo: opciones exactas del dropdown y qué valor se guarda) y luego producir solo el cambio mínimo de código/UI necesario. Debe también indicar explícitamente lo que no tocó (routing, lógica de validación, shape del payload).
Antes de aceptar un “cambio pequeño”, haz un pase rápido que busque deriva silenciosa. El objetivo no es QA completa; es confirmar que la app sigue comportándose igual en todo lo que dijiste “no cambiar”, salvo por la edición prevista.
Hazlos siempre en el mismo orden. Mantiene las revisiones tranquilas y facilita detectar regresiones.
Reviértelo si cualquier ítem congelado cambió, aunque la app “siga funcionando”. Una etiqueta cambiada, un campo nuevo o una regla ligeramente distinta es señal de que el modelo se tomó libertades.
Re-emite la solicitud con restricciones más ajustadas: repite el cambio en una frase, lista las pantallas y flujos congelados por nombre y añade “sin cambios de esquema, sin cambios de endpoints, sin cambios de comportamiento fuera de X.” Si usas Koder.ai, crear una snapshot antes de probar hace que el rollback sea un paso cuando algo deriva.
Si construyes en Koder.ai, el patrón “no cambiar” funciona mejor como hábito: un cambio pequeño, todo lo demás bloqueado y una vía clara para volver si algo se desvía.
Antes de pedir el cambio, cambia a Planning Mode y pide al asistente que repita tu alcance en palabras llanas. Pídele que confirme dos cosas: (1) el cambio exacto, y (2) una lista clara de congelados (flujos, detalles de UI y reglas de negocio que no deben moverse).
Un prompt de planificación útil: “Repite mi solicitud. Luego lista lo que no debe cambiar. Si algo no está claro, pregunta antes de editar.”
Trata cada solicitud de cambio como un checkpoint. Crea una snapshot antes de aplicar la actualización y otra después de verificarla. Si algo se rompe, el rollback es más rápido que intentar parchear un mal cambio.
Por ejemplo, podrías ajustar una etiqueta en una pantalla React. El cambio parece mínimo, pero aun así puede desplazar espaciados, provocar un rerender o romper un test automatizado. Una snapshot te permite comparar comportamiento y revertir rápidamente.
Un flujo simple:
Koder.ai puede generar web (React), backend (Go + PostgreSQL) y móvil (Flutter). El patrón se mantiene aunque el código varíe. Congela las partes que definen el comportamiento, no solo los archivos.
Si cambias un endpoint backend, congela la forma request/response, reglas de validación y escrituras de datos. Si cambias una pantalla móvil, congela el orden de navegación, valores por defecto de campos y mensajes de error. Si tocas lógica de base, congela el significado de filas existentes y mantén migraciones seguras.
Copia tu plantilla, haz un cambio pequeño hoy y verifícalo con la checklist antes de aceptarlo. Guarda el texto de la plantilla y sustituye el siguiente cambio, uno por vez.
Usa este patrón siempre que quieras un cambio específico y te importe que el resto permanezca igual. Es especialmente útil para procesos como checkout, autenticación, facturación o cualquier flujo donde una pequeña deriva cause problemas reales a los usuarios.
Porque las partes de una app comparten componentes, datos y reglas. Una pequeña edición de UI puede tocar un componente reutilizado, lo que desplaza layouts en otras pantallas, altera validaciones o cambia payloads de API sin que lo notes hasta más tarde.
Escribe un objetivo claro y luego enumera lo que debe permanecer idéntico tras el cambio. Lo importante es congelar el comportamiento (flujos, reglas, datos, integraciones) y los detalles visibles de la UI, no limitarse a decir “no lo rompas”.
Manténlo corto pero específico: flujos críticos, detalles de UI/UX que no deben moverse, reglas de negocio, comportamiento de datos e integraciones. Si no puedes nombrar lo que debe permanecer igual, el modelo tendrá que adivinar, y adivinar provoca deriva.
Álcala al área más pequeña que aún te proteja. Por ejemplo, congela el flujo de checkout y sus componentes compartidos, pero no congeles toda la aplicación si solo vas a cambiar una etiqueta en una pantalla.
Nombra los recorridos paso a paso y define qué significa “hecho”. Añade los casos límite comunes como comportamiento del botón atrás, mensajes de error, estados vacíos y de recarga para que el flujo permanezca idéntico en los puntos que más notan los usuarios.
Congela explícitamente la estructura de la UI, el espaciado, los estados de los componentes (hover/disabled/loading) y todo el texto, excepto la única cadena que vas a cambiar. Si no lo haces, los modelos pueden “limpiar” estilos o reescribir textos de forma que cambien el significado o el diseño.
Congela contratos: shapes de request/response, reglas de validación, permisos, cálculos y lo que se persiste y cuándo. Añade un ejemplo numérico para reglas sensibles como precios, para que no haya interpretaciones durante la implementación.
Pide checks de aceptación que puedas ejecutar rápido y un breve resumen tipo diff de qué cambió y dónde. Luego verifica los flujos congelados de extremo a extremo, desencadena al menos un estado de error y comprueba que los datos e integraciones no hayan variado.
Haz una snapshot antes del cambio, ejecuta una fase de planificación que repita el alcance y la lista de congelados, y luego aplica el parche mínimo. Tras verificar, toma otra snapshot para que el rollback sea un solo paso si algo se desvió.