Cómo iterar en una app creada con IA sin romperla

Para iterar en una app creada con IA sin romperla, cambia una sola cosa por prompt, compruébala en la vista previa y guarda un punto de control antes de seguir. Describe lo que ves en lugar de lo que crees que hace el código, planifica los cambios grandes antes de construirlos y, cuando un cambio salga mal, vuelve a la última versión buena en lugar de pedirle a la IA que arregle su propio arreglo.

La primera versión de una app suele estar lista en minutos. Lo difícil es el cambio número cincuenta, cuando cada prompt nuevo arriesga romper algo que ya funcionaba. Esta guía es el ciclo que evita que eso ocurra.

El ciclo de iteración

1. Elige un cambio. Una función, un error o una página.
2. Descríbelo en términos de lo que el usuario ve y hace.
3. En los cambios grandes, planifica primero. Pide un plan, léelo y luego construye.
4. Comprueba el resultado en la vista previa: el cambio y los flujos cercanos.
5. Guarda un punto de control o un commit.
6. Repite.

Cada paso existe para mantener los cambios pequeños y reversibles.

Paso 1: Lleva una lista corta

Antes de escribir el prompt, anota lo que quieres cambiar, por orden de importancia. Así evitas enviar un párrafo con diez deseos en un solo mensaje, y tienes una forma de decir «ahora no» a las ideas que surgen a mitad de camino.

Si un cambio es grande, divídelo. «Añadir cuentas de equipo» se convierte en: crear equipos, invitar a un miembro, cambiar entre equipos, limitar los datos al equipo actual. Cada uno es un prompt aparte. Escribir historias de usuario es una buena forma de hacerlo.

Paso 2: Describe lo que ves

La IA no puede ver tu pantalla a menos que se lo digas. Señala cosas concretas y di qué debería pasar:

En la página de precios, en un móvil, el botón de la tarjeta Pro se corta en el borde derecho. Mantén igual la maquetación de escritorio; en pantallas de menos de 640 px, apila las tarjetas y haz que los botones ocupen todo el ancho.

Compáralo con «la página de precios se ve mal en móvil». El primero se puede hacer y comprobar de una sola vez; el segundo invita a un rediseño que no pediste.

Las capturas de pantalla ayudan. Si tu constructor admite imágenes, adjunta una y marca el problema.

Paso 3: Planifica antes de los cambios grandes

Para cualquier cosa que afecte a varias partes de la app —un modelo de datos nuevo, pagos, roles de usuario—, pide un plan antes de que cambie el código:

No cambies el código todavía. Quiero que los usuarios pertenezcan a equipos y que solo vean los proyectos de su equipo. Planifica el cambio: qué tablas, páginas y rutas de la API cambian, qué pasa con los datos de los usuarios existentes y en qué orden lo construirías.

Lee el plan. Si es incorrecto, corregir un plan cuesta mucho menos que deshacer una construcción.

Paso 4: Di qué no debe cambiar

Las herramientas de IA a veces «ordenan» cosas que no pediste. Protege lo que funciona:

Añade un filtro por fecha a la tabla de pedidos. No cambies las columnas de la tabla, su estilo ni el botón de exportar.

Para las reglas que se aplican en todas partes —colores de marca, tono de voz, «nunca borrar datos sin confirmación»—, ponlas en un archivo de notas del proyecto o en un ajuste de conocimiento que la IA lea cada vez, en lugar de repetirlas.

Paso 5: Comprueba algo más que el cambio

Tras cada prompt, prueba:

• El cambio en sí. ¿Hace lo que pediste, en escritorio y en móvil?
• Sus vecinos. Las cosas de la misma página y los flujos que usan los mismos datos.
• El camino crítico. Registro, inicio de sesión, la acción principal, el pago. Una revisión de treinta segundos después de cada cambio grande detecta la mayoría de las roturas a tiempo.

Si algo no cuadra, descríbelo con precisión; consulta cómo escribir un buen informe de error.

Paso 6: Vuelve atrás en lugar de acumular arreglos

Cuando un cambio rompe algo y el primer arreglo no funciona, para. Cada «arreglo» adicional se construye sobre un estado roto, y los problemas se multiplican.

En su lugar:

1. Vuelve a la última versión que funcionaba (un punto de control o un commit de Git).
2. Averigua qué no estaba claro en el prompt.
3. Vuelve a intentarlo con una petición más pequeña o más clara.

Ese cambio rompió el guardado de borradores. He vuelto atrás. Esta vez: añade solo el indicador de autoguardado, como texto en la cabecera. No cambies cómo se guardan los borradores.

Paso 7: Sabe cuándo reconstruir es lo adecuado

Reconstruir desde cero tira a la basura muchos detalles que ya funcionan. Solo merece la pena cuando:

• La idea del producto ha cambiado por completo.
• La estructura subyacente no puede soportar lo que ahora necesitas; por ejemplo, se construyó como un sitio estático y ahora necesita cuentas y base de datos.
• El proyecto aún está casi vacío.

Si reconstruyes, haz una lista de lo que hay que conservar: nombre, colores, textos, las partes que gustaron a los usuarios.

Prompts de ejemplo

Antes de seguir, resume cómo funciona ahora la app: páginas, datos que guarda y cualquier cosa que consideres frágil.

Quiero añadir reservas recurrentes. ¿Cuál es la versión más pequeña que sería útil? Propón tres cambios separados que podamos hacer uno a uno.

Revisa los tres últimos cambios por si alguno ha podido romper el flujo de pago. No edites todavía.

Errores habituales

• Diez peticiones en un solo prompt. Algunas se hacen, otras a medias, y no sabes cuáles.
• Comentarios vagos. «Está roto» o «mejóralo» producen suposiciones.
• No comprobar los vecinos. Un cambio en un componente compartido rompe otras tres páginas.
• Arreglar arreglos. Si llevas cuatro prompts intentando arreglar un error, vuelve atrás.
• Repetir el contexto cada vez en lugar de guardar las reglas permanentes en las notas del proyecto.
• Reconstruir cuando te atascas. La mayoría de los momentos de «empezar de nuevo» en realidad son «volver atrás dos pasos».

Lista de verificación

• Un objetivo por prompt.
• Describo lo que veo y lo que debería pasar.
• Los cambios grandes tienen un plan antes de tocar código.
• Digo qué no debe cambiar.
• Tras cada cambio lo pruebo, así como sus vecinos y el camino crítico.
• Guardo un punto de control o un commit tras cada cambio que funciona.
• Cuando un arreglo falla, vuelvo atrás en lugar de apilar arreglos.
• Las reglas permanentes están en las notas del proyecto que la IA lee cada vez.

Iterar en Mythex

Mythex se basa en este ciclo:

• Modos Plan, Build y Ask. Plan analiza el enfoque antes de editar; Ask responde sin cambiar código; Build hace el cambio. Consulta Chat.
• Puntos de control. Tras cada turno exitoso, Mythex guarda un punto de control de git; Revertir a este punto vuelve atrás. También puedes editar un mensaje anterior y usar Descartar y reenviar para probar otro prompt desde ese punto. Consulta Iterar sin reconstruir.
• Conocimiento. Configuración del proyecto → Conocimiento guarda notas permanentes que el agente sigue en cada mensaje.
• /test hace que el agente recorra la vista previa como un usuario tras un cambio grande.

Las peticiones más pequeñas también consumen menos créditos. Para escribir los prompts en sí, consulta cómo escribir prompts para constructores de apps con IA; cuando algo se rompa, cómo depurar una app creada con IA.

Preguntas