No cambies el patrón de prompt para iteraciones pequeñas y seguras

Por qué los cambios pequeños suelen romper otras partes

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.

Qué es el patrón de prompt “no cambiar”

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:

• Flujos (recorridos de usuario): los pasos que siguen los usuarios y qué pantallas aparecen.
• Detalles de UI y UX: layout, espaciado, orden de campos, ubicación de botones y comportamientos de interacción.
• Reglas de negocio y comportamiento de datos: reglas de validación, cálculos de precios, permisos, escrituras en la base y respuestas de API.

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.

La plantilla básica que puedes reutilizar

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.

Cómo congelar flujos críticos sin ser vago

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:

• Flujos a congelar: Login, Signup, Checkout, Ajustes (sin pasos nuevos, sin reordenar pantallas)
• Casos límite a congelar: comportamiento del botón atrás, mensajes de error, estados vacíos, comportamiento de refresco
• Comportamiento de datos a congelar: qué se guarda, cuándo se guarda y dónde aparece tras recargar
• Seguridad a congelar: permisos, cheques de auth, límites de tasa, sin endpoints públicos nuevos
• Performance a congelar: sin llamadas API extra en estos flujos, tiempo de respuesta no peor que el actual

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.

Cómo congelar detalles de UI y UX

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:

• Mantener idéntico: rutas/pantallas, orden de navegación y comportamiento del botón atrás
• Mantener idéntico: grid de layout, espaciado, tipografías, colores y estados de componentes
• Mantener idéntico: todo el texto y las etiquetas excepto: <la única cadena>
• Reglas móviles: mantener comportamiento actual en <breakpoints>, no reflowear otras secciones
• Output: describe cada cambio UI realizado y lista archivos/componentes tocados

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.

Cómo congelar reglas de negocio y comportamiento de datos

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é.

Explica las reglas que no deben cambiar

En lugar de “mantener precios igual”, fíjalo:

• Precios: fórmula exacta, redondeo (hacia arriba/abajo), moneda, comportamiento de impuestos/IVA y cuándo se aplican descuentos
• Permisos: qué roles pueden crear, editar, borrar, aprobar, reembolsar, exportar o ver campos sensibles
• Estados: estados permitidos y transiciones válidas (y qué las dispara)
• Cálculos: totales, comisiones, créditos, límites y cualquier tope o mínimo
• Escrituras de datos: qué tablas/registros se crean o actualizan y qué debe seguir siendo inmutable

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).

Paso a paso: cómo pedir un cambio seguro

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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:

• Solo cambió el comportamiento solicitado
• Los flujos y pantallas congeladas siguen coincidiendo
• Reglas de negocio y escrituras de datos sin cambios
• Tests (o pasos manuales) pasan según lo escrito
• No se colaron commits de “limpieza”

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.

Errores comunes que siguen causando deriva

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:

• Ser abstracto: proteges la intención, pero no el flujo paso a paso y los resultados esperados.
• Olvidar casos límite: estados vacíos, de carga, errores, permisos, comportamiento offline.
• Agrupar cambios: dos o tres ajustes en una misma solicitud favorecen compensaciones y regresiones más difíciles de detectar.
• No definir “idéntico”: mismo layout, mismas llamadas API, mismas escrituras en BD, mismos emails/notificaciones, mismos eventos de analytics.
• Aprobar por sensación: “se ve bien” sin verificar rutas clave.

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:

• Ejecuta el flujo principal de extremo a extremo (el que congelaste).
• Fuerza al menos un estado de error y uno vacío.
• Comprueba permisos (admin vs usuario normal) si aplica.
• Confirma efectos secundarios: registros creados/actualizados, notificaciones enviadas y métricas/logs sin cambios.

Si algo difiere, la solicitud carecía de un detalle congelado, no fue “mal código”.

Ejemplo: un ajuste pequeño de UI sin cambiar el flujo

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:

• Congelado de flujo: al enviar aún se crea la cuenta, se muestran las mismas validaciones y el usuario va a la misma pantalla siguiente.
• Congelado UI: layout de la página, espaciado, colores y posición del botón permanecen igual.
• Congelado de datos: keys y tipos del payload backend no cambian; el valor almacenado para company size mantiene el mismo formato que antes.
• Congelado de reglas: campos obligatorios siguen siendo obligatorios y el botón continúa deshabilitado hasta que el formulario sea válido.
• Congelado analytics: se disparan los mismos eventos de tracking en submit y en errores de validación.

Checks de aceptación que puedes correr en minutos:

• El texto del botón muestra “Continue” en todos los estados (por defecto, cargando, deshabilitado).
• Company size es un dropdown con el mismo valor por defecto que antes.
• Enviar aún llega al dashboard y la cuenta se crea.
• Usuarios existentes que editan perfil siguen viendo el tamaño de compañía guardado correctamente.
• No hay warnings nuevos ni tests fallando en el área de registro.

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).

Lista rápida antes de aprobar la actualización

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.

5 checks rápidos (10 minutos)

Hazlos siempre en el mismo orden. Mantiene las revisiones tranquilas y facilita detectar regresiones.

• Flujo crítico completa de extremo a extremo: Empieza desde el mismo punto de entrada que usa un usuario real (login, landing, dashboard) y termina la tarea principal.
• La UI es idéntica excepto el cambio previsto: Abre las pantallas clave que congelaste. Revisa layout, etiquetas, espaciado y navegación.
• Las reglas de negocio siguen siendo las mismas: Revisa 2 o 3 casos que suelen romperse, como un cálculo de descuento, un permiso o una transición de estado.
• La forma de los datos no cambió: Confirma que no hay campos nuevos, renombrados o eliminados, ni migraciones inesperadas.
• Las integraciones no se modificaron: Verifica que no hay cambios en endpoints ni en payloads (nombres de campos, obligatorios, códigos de estado).

Cuándo revertir y volver a emitir la solicitud

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.

Próximos pasos: aplicarlo en Koder.ai para iteraciones más seguras

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.

Empieza con una pasada rápida de planificación

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.”

Protege cada iteración con snapshots

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:

• Crear snapshot: “Antes - cambiar solo etiqueta del botón”
• Ejecutar la pasada de planificación y confirmar la lista de congelados
• Pedir el cambio y solicitar un breve resumen tipo diff de lo modificado
• Verificar con tu checklist (UI, flujos, reglas, datos)
• Crear snapshot: “Después - verificado”

Reutiliza el mismo patrón en toda la stack

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.