Cómo escribir prompts para creadores de apps con IA (con ejemplos de antes y después)
Un buen prompt para un creador de apps con IA describe el producto, no el código: quién lo usa, qué hace paso a paso, qué datos guarda y quién puede ver qué. Una vez que existe la primera versión, pide un cambio concreto por mensaje, di qué debe mantenerse igual y describe los problemas como “hice X, esperaba Y, obtuve Z”. Esos tres hábitos arreglan la mayoría de los resultados decepcionantes.
El resto de esta guía muestra los patrones en detalle, con ejemplos de antes y después que puedes adaptar.
Por qué pedirle algo a un creador de apps es distinto de chatear con una IA
Cuando haces una pregunta a un asistente de chat, un prompt vago da una respuesta vaga y sigues adelante. Cuando le pides algo a un creador de apps con IA, la respuesta es un programa en funcionamiento. Cada hueco en tu descripción se rellena con una suposición, y esas suposiciones se convierten en código, tablas de base de datos y pantallas con las que luego tienes que convivir o que tienes que deshacer.
Así que el objetivo de un prompt no es sonar inteligente. Es dejar menos decisiones importantes al azar. No necesitas vocabulario técnico para eso. Necesitas ser específico sobre lo que solo tú sabes: tus usuarios, tu flujo de trabajo y tus reglas.
Qué incluir en un primer prompt
Antes de escribir nada, responde estas preguntas. Cada una cierra un hueco que la IA adivinaría de otro modo.
| Incluye | Por qué importa | Ejemplo |
|---|---|---|
| El producto en una frase | Marca el marco de todas las decisiones posteriores | “Una web de reservas para una barbería de dos sillas” |
| Quién lo usa | Decide las pantallas y el tono | “Clientes que llegan sin cita desde el móvil, y el dueño desde un portátil” |
| El flujo principal, paso a paso | Lo que tiene que funcionar primero | “Elegir un servicio, elegir una hora, escribir nombre y teléfono, recibir una confirmación” |
| Los datos que guarda | Se convierte en el diseño de la base de datos | “Servicios, reservas, clientes” |
| Quién puede ver o cambiar qué | Decide el inicio de sesión y los permisos | “Solo el dueño ve todas las reservas” |
| Aspecto y estilo, brevemente | Evita un estilo genérico por defecto | “Oscuro, sencillo, botones grandes” |
| Qué dejar fuera por ahora | Mantiene pequeña la primera versión | “Sin pagos ni reseñas todavía” |
La última fila se subestima. Decir lo que no quieres evita que la IA añada un blog, una página de precios y un formulario de newsletter que nunca pediste.
Antes y después: el primer prompt
Antes:
Hazme una app para mi gimnasio.
El creador tiene que adivinarlo todo: ¿miembros o personal? ¿Clases o entrenamiento personal? ¿Pagos? Obtendrás algo que parece una web de gimnasio y no hace lo que necesitas.
Después:
Construye una app de reservas de clases para un pequeño estudio de yoga. Los socios ven las clases de esta semana (nombre, profesor, hora, plazas libres) y reservan una plaza, y pueden cancelar hasta dos horas antes. Los socios se registran con correo y contraseña. La dueña del estudio inicia sesión para añadir clases, ver quién tiene reserva y marcar la asistencia. Guarda clases, socios y reservas en una base de datos. Diseño tranquilo y claro que funcione bien en el móvil. Sin pagos por ahora.
La segunda versión sigue siendo corta. Solo responde a las preguntas de la tabla de arriba.
Describe el comportamiento, no la implementación
A menudo obtienes mejores resultados describiendo lo que debe pasar en lugar de cómo construirlo.
Antes:
Añade un useEffect que cargue las reservas y un componente modal para editarlas.
Después:
Cuando la dueña haga clic en una reserva, abre un panel donde pueda cambiar la hora o cancelarla. Los cambios deben verse al instante en la lista.
El primer prompt obliga a la IA a una técnica concreta que quizá no encaje con cómo está construida la app. El segundo le dice el resultado y deja que elija el enfoque adecuado para el código que ya escribió. Si eres desarrollador y sí tienes una preferencia fuerte, dilo, pero acompáñala del resultado.
Sé concreto con las reglas
Las reglas de negocio son donde más fallan las apps construidas con IA, porque para ti son obvias y para la IA son invisibles. Explícalas.
- Límites: “Un socio puede tener como máximo tres reservas futuras.”
- Plazos: “Las cancelaciones se cierran dos horas antes de que empiece la clase.”
- Casos límite: “Si una clase está llena, muestra un botón de lista de espera en lugar de Reservar.”
- Permisos: “Los profesores ven la asistencia de sus propias clases, pero no la de otros profesores.”
Cada una cabe en una frase. Si omites alguna, la app no aplicará la regla o inventará su propia versión.
Después de la primera versión: un cambio por mensaje
Cuando algo ya funciona en la vista previa, cambia de describir todo el producto a pedir cambios pequeños y comprobables.
Antes:
El diseño no está bien, la reserva no funciona bien y quiero una vista de calendario y correos.
Después (como cuatro mensajes separados):
- Cuando reservo la última plaza de una clase, la clase sigue mostrando “1 plaza libre”. Debería mostrar “Completa” y ocultar el botón Reservar.
- Añade en la página de horarios una vista de calendario semanal, con una columna por día. Mantén la vista de lista actual como opción.
- Haz las tarjetas de clase más compactas en el móvil: menos relleno y el nombre del profesor en la misma línea que la hora.
- Envía al socio un correo de confirmación cuando reserve.
Por qué funciona:
- Cada cambio es lo bastante pequeño para que la IA lo haga bien en una sola pasada.
- Puedes probar cada uno antes de seguir.
- Si uno sale mal, puedes deshacer solo ese paso sin perder los demás.
Di qué mantener
Cuando pidas un cambio en algo que ya funciona, indica qué no debe cambiar. Es la forma más sencilla de evitar regresiones (cosas que funcionaban y se rompen tras una edición).
Rediseña la cabecera de la página de inicio con un titular más grande y una foto a la derecha. Mantén la navegación, los colores y todo lo que hay debajo de la cabecera exactamente como están.
Lo mismo vale para los datos: “Añade un campo de teléfono a los socios. No elimines ni renombres ningún campo existente.”
Usa capturas de pantalla y texto exacto
Palabras como “la cosa de arriba” son ambiguas. La mayoría de los creadores de apps con IA aceptan imágenes, y una captura con una nota breve es más rápida que un párrafo de descripción.
- Adjunta una captura y di “el botón marcado en rojo se superpone al menú en los móviles”.
- Pega el texto exacto de cualquier mensaje de error en lugar de parafrasearlo.
- Cita las etiquetas de la pantalla exactamente: “el botón Guardar cambios de la página de Ajustes”.
Para los errores, usa esta forma:
En la página de reservas, hice clic en Cancelar en una reserva para mañana. Esperaba que desapareciera de mi lista. En cambio, no pasó nada y la reserva sigue ahí tras recargar. Arréglalo y comprueba que cancelar funciona.
Nuestra guía sobre cómo depurar una app construida con IA profundiza en esto.
Planifica primero los cambios grandes
Para todo lo que afecte a muchas partes de la app (añadir cuentas de usuario a una app que no las tenía, añadir pagos, cambiar cómo se estructuran los datos), pide un plan antes de que cambie cualquier código.
Antes de cambiar nada, explica cómo añadirías cuentas de equipo: qué tablas nuevas, qué páginas cambian y qué pasa con los usuarios existentes. Todavía no edites código.
Lee el plan. Si entiende mal algo, corregir un párrafo es mucho más barato que corregir una función terminada. Muchos creadores tienen un modo específico para esto; en Mythex es el modo Plan, junto a Build y Ask.
Qué evitar
| Evita | Por qué | En su lugar |
|---|---|---|
| “Mejóralo” / “Hazlo más llamativo” | No hay objetivo, así que la IA cambia cosas al azar | Nombra el cambio: “más espacio entre secciones, titulares más grandes” |
| Un prompt gigante con diez funciones | Los errores se acumulan; es difícil de probar | Una función por mensaje |
| Pegar claves de API en el chat | Las claves quedan en el historial del chat | Usa los secretos o ajustes de entorno del creador |
| Discutir con un resultado roto | Cada arreglo se apila sobre el fallo | Deshaz y reformula |
| Especificar código que no entiendes | Fija un enfoque poco adecuado | Describe el comportamiento que quieres |
| Pedir “seguridad de nivel empresarial” | No significa nada concreto | Enumera las reglas reales: quién puede ver qué |
Sobre las claves de API: si necesitas un servicio de pagos o de correo, pon sus claves en los secretos del proyecto en lugar de en el prompt. Consulta qué son las variables de entorno y los secretos si es nuevo para ti.
Plantillas de prompts reutilizables
Adáptalas sustituyendo las partes entre corchetes.
Nueva app:
Construye una [tipo de app] para [quién]. Ellos [flujo principal, paso a paso]. [Segundo tipo de usuario] inicia sesión para [qué hace]. Guarda [datos] en una base de datos. [Aspecto y estilo]. Deja fuera [cosas para más adelante].
Nueva función:
Añade [función] a la [página]. Cuando [usuario] hace [acción], [qué debe pasar]. Solo [quién] puede [hacerlo]. Mantén [cosas existentes] tal como están.
Cambio de diseño:
En la [página], cambia [elemento concreto] a [cambio concreto]. Mantén [lo que se queda igual]. Comprueba que se ve bien en una pantalla del ancho de un móvil.
Error:
En [página], hice [pasos]. Esperaba [resultado esperado]. En cambio [resultado real, más el texto exacto del error]. Arréglalo y comprueba que el flujo funciona.
Pregunta sin cambios:
No cambies ningún código. Explica cómo funciona [parte de la app] y dónde se guardan [datos].
Escribir una especificación más larga
En proyectos más grandes puede ayudar escribir primero un brief de una página y pegarlo como prompt inicial: los usuarios, los flujos principales, los datos, las reglas y lo que queda fuera. Incluso puedes pedir a una IA que te ayude a redactarlo; nuestra guía sobre cómo escribir un documento de requisitos de producto con IA explica cómo. Limita la primera petición de construcción al flujo principal y añade el resto paso a paso.
Prompts en Mythex
Todo lo anterior funciona en Mythex. Algunos detalles que ayudan:
- Modos Build, Plan y Ask. Usa Plan para cambios grandes o arriesgados, y Ask cuando quieras una explicación sin ediciones.
- Puntos de control. Tras cada cambio correcto, Mythex guarda un punto de control, y Revert to this point en una respuesta devuelve el proyecto a ese estado. También puedes editar un mensaje anterior y reenviarlo para probar otro prompt desde ese punto.
- Tarjeta de secretos. Cuando el agente necesita una clave de API, la pide mediante una tarjeta en el chat, de modo que el valor se guarda como secreto del proyecto y no se escribe en tu mensaje.
- Imágenes. Adjunta capturas o maquetas y el agente las revisará.
La documentación tiene una página breve sobre prompts efectivos y otra sobre iterar sin reconstruir. Si empiezas desde cero, cómo crear una app con IA recorre un proyecto completo, y cómo diseñar una app bonita con IA trata los prompts para el pulido visual.
Preguntas
¿Cuánto debe ocupar un prompt para un creador de apps con IA?
Para la primera versión, basta con un párrafo corto de cuatro a ocho frases: quién usa la app, el flujo principal, los datos que guarda y quién puede ver o cambiar qué. Después, funcionan mejor prompts más cortos que piden un cambio a la vez que los prompts largos.
¿Debo decirle a la IA qué framework o lenguaje usar?
Solo si tienes una razón, como un desarrollador que se hará cargo del código o un servicio que solo funciona con una pila concreta. Si no, describe el producto y deja que el creador elija valores por defecto razonables.
¿Por qué la IA sigue cambiando cosas que no le pedí cambiar?
Normalmente porque el prompt era amplio (“mejóralo”) o no decía qué mantener. Nombra exactamente lo que quieres cambiar, di qué debe seguir igual y pide un cambio por mensaje.
¿Es mejor arreglar un mal resultado con más prompts o empezar de nuevo?
Si el último cambio empeoró las cosas, vuelve a la versión anterior y reformula, en lugar de apilar arreglos encima. Empieza un proyecto nuevo solo cuando la idea en sí ha cambiado.