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 tomar forma en minutos. Lo difícil es el cambio número cincuenta, cuando cada prompt nuevo arriesga romper algo que ya funcionaba. Esta guía describe el ciclo que evita que eso pase.

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 a la vez, 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 desde el móvil, el botón de la tarjeta Pro se corta por el borde derecho. Mantén igual el diseño de escritorio; en pantallas de menos de 640 px, apila las tarjetas y haz los botones de ancho completo.

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

Las capturas ayudan. Si tu creador acepta 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 nuevo modelo de datos, pagos, roles de usuario), pide un plan antes de que cambie ningún código:

No cambies código todavía. Quiero que los usuarios pertenezcan a equipos y vean solo 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 está mal, corregir un plan es mucho más barato que deshacer una construcción.

Paso 4: di qué no debe cambiar

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

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

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

Paso 5: comprueba más que el cambio

Después de cada prompt, prueba:

• El cambio en sí. ¿Hace lo que pediste, en escritorio y en móvil?
• Sus vecinos. Lo que hay en 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. Un repaso de treinta segundos tras 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: revierte en lugar de acumular

Cuando un cambio rompe algo y el primer arreglo no funciona, para. Cada parche extra 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.

El último cambio rompió el guardado de borradores. He revertido. Esta vez: añade solo el indicador de guardado automático, como texto en la cabecera. No cambies la forma en que se guardan los borradores.

Paso 7: sabe cuándo reconstruir

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 necesitas ahora; por ejemplo, se construyó como sitio estático y ahora necesita cuentas y una 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 la app ahora: páginas, datos que guarda y lo que creas que es 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 últimos tres 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 «hazlo mejor» provoca 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» son en realidad «retrocede dos pasos».

Lista de comprobación

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

Iterar en Mythex

Mythex está construido en torno a este ciclo:

• Modos Plan, Build y Ask. Plan discute 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; Revert to this point (volver a este punto) revierte. También puedes editar un mensaje anterior y usar Discard & resend (descartar y reenviar) para probar otro prompt desde ese punto. Consulta Iterar sin reconstruir.
• Conocimiento. En Ajustes del proyecto → Knowledge (Conocimiento) están las 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.

Los pedidos más pequeños también cuestan menos créditos. Para escribir los propios prompts, consulta cómo escribir prompts para creadores de apps con IA; y cuando algo se rompa, cómo depurar una app creada con IA.

Preguntas