Crear una app con IA eliminó la necesidad de escribir código línea a línea, pero no la de pensar con claridad. El cuello de botella se movió: en lugar de teclear sintaxis, redactas un brief. Un prompt vago produce una app vaga (pantallas genéricas, funciones inventadas, casos límite olvidados). Uno preciso se acerca notablemente a lo que necesitas desde el primer intento. Esta guía muestra cómo escribir prompts para crear una app: una anatomía reutilizable, ejemplos malos vs buenos, y un ritmo de iteración que no rompe lo que ya funciona.
Los mismos principios aparecen en la guía oficial de los modelos. La guía de prompt engineering de OpenAI insiste en instrucciones claras y pruebas iterativas. En un AI app builder, eso significa describir resultados que el usuario puede ver, no patrones de React que el modelo deba inventar por ti.
La anatomía de 7 partes de un buen prompt para apps
Trata tu primer prompt como el brief para un desarrollador freelance que nunca te ha conocido y no puede hacer preguntas antes de empezar. Cuantos más de los siguientes puntos responda por sí solo, menos tendrá que adivinar la IA, y menos tendrás que corregir después.
- Contexto, quién y qué: para quién es la app y qué problema resuelve, en una o dos frases.
- Objetivo: la única tarea principal que alguien debe completar, vender un servicio, seguir proyectos, gestionar una lista de espera.
- Usuarios: usuario individual, pequeño equipo interno, clientes externos, o varios roles con accesos distintos.
- Pantallas clave: las cuatro a seis páginas que más importan, nombradas explícitamente, panel, lista de clientes, detalle de factura, ajustes.
- Entidades de datos: los sustantivos de tu app y cómo se relacionan, un cliente tiene muchos proyectos; un proyecto tiene muchas facturas.
- Restricciones: lo no negociable, inicio de sesión obligatorio, pagos, prioridad móvil, una integración concreta.
- Tono y marca: colores, referencias de estilo, formal vs distendido, “minimalista como Stripe” funciona mejor que “hazlo moderno”.
Prompt malo vs prompt bueno
La diferencia entre una app mediocre y una útil rara vez es el modelo. Casi siempre es el prompt. Aquí tienes la misma idea, escrita dos veces.
Malo
"Créame una app para gestionar mis clientes."
Bueno
"Dirijo una pequeña agencia de diseño con otros dos freelancers. Crea un portal de clientes donde veamos clientes, proyectos por cliente y facturas por proyecto. Necesito un panel de proyectos activos, una lista de clientes con contactos, y una página de proyecto con tareas y estado de factura (borrador, enviada, pagada). Los clientes inician sesión y ven solo sus propios datos. UI limpia y minimalista en azul y blanco."
La versión mala obliga a la IA a inventar contexto, pantallas, datos y reglas de acceso. La buena aporta el contexto de la agencia, el objetivo, las entidades y relaciones (cliente → proyecto → factura), pantallas nombradas, una restricción dura (acceso por roles) y un tono visual. Casi no queda nada que adivinar.
Recuerda
Si un compañero con casi ningún contexto no sabría qué construir a partir de tu prompt, el modelo tampoco. La guía de prompting de Anthropic usa la misma prueba: claridad para un fichaje brillante = claridad para la IA.
Para el principio de fondo, sé explícito, añade contexto, evita adjetivos vagos, consulta las buenas prácticas de prompting de Claude de Anthropic.
Empieza amplio, luego afina pantalla por pantalla
Meter cada campo y cada regla en un solo prompt gigante suele salir mal: el modelo hace malabares con demasiado y pierde la mitad. Un ritmo mejor encaja con cómo se construyen productos reales, primero el esqueleto, luego la profundidad. Así es también como el vibe coding se mantiene productivo: primero la intención, luego bucles de feedback cortos.
- Primer prompt: propósito, usuarios y el puñado de pantallas para que la IA construya el esqueleto general.
- Segunda ronda: elige una pantalla, “En la lista de clientes, añade búsqueda y un filtro por estado.”
- Tercera ronda: pasa a la siguiente pantalla solo cuando la anterior te convenza.
- Pulido: textos, espaciado, estados vacíos y casos límite una vez que la estructura aguanta.
Guías de app builders como los patrones de prompts de IA de Knack llegan a la misma conclusión: empieza con pocas entidades y relaciones claras, luego amplía. Resiste la tentación de especificar todo el producto en el primer mensaje.
Re-promptear vs micro-parches
No toda petición merece la misma formulación. Los cambios estructurales necesitan un prompt más completo que reexplique el contexto de esa parte de la app. Los ajustes mínimos funcionan mejor como mensajes cortos y quirúrgicos.
| Situación | Usa | Ejemplo de formulación |
|---|---|---|
| Nueva entidad, nuevo rol o navegación reestructurada | Re-prompt | "Añade facturas vinculadas a cada proyecto. Estado: borrador, enviada, pagada. Muéstralas en la página del proyecto." |
| Etiqueta, color, orden, un solo campo | Micro-parche | "En la página de detalle de factura, haz la etiqueta Pagada en verde." |
| La IA ha destrozado una pantalla | Re-prompt de esa pantalla | Reexplica qué debe hacer la pantalla; di qué debe quedar igual en el resto. |
Incluso en un micro-parche, nombra la pantalla y el elemento. “Hazlo más bonito” no es un prompt, es un deseo.
Errores que sabotean tus prompts
- Ser demasiado vago. "Moderno y profesional" no es accionable. Nombra una referencia, un color o un layout.
- Pedir demasiadas funciones a la vez. Auth + pagos + panel + notificaciones en un mensaje obliga a repartir la atención a todo a la vez.
- Describir la implementación en vez del resultado. Olvida “usa un useEffect y un reducer.” Di qué debe ver y hacer el usuario.
- Olvidar los casos límite. Listas vacías, pagos fallidos, un cliente sin proyectos, nómbralos pronto.
Consejos que funcionan con cualquier AI app builder
- Nombra la pantalla. "En el panel…" elimina la ambigüedad sobre dónde se aplica un cambio.
- Da ejemplos reales. Pega nombres y precios reales de planes en lugar de “añade una tabla de precios.”
- Cambia una cosa a la vez. Una intención clara por mensaje deja claro qué funcionó.
- Di qué debe quedar igual. Al afinar una pantalla, protege el resto de la app de forma explícita.
- Prueba pronto con datos con forma real. Tres filas de ejemplo pueden ocultar roturas de layout que aparecen con cincuenta.
Cuando el prompting te resulte sólido, la elección de herramienta importa para la propiedad y la seguridad al iterar, empieza por nuestra comparativa de los mejores AI app builders.
La misma anatomía para sitios, apps web y móviles
El marco no cambia según el tipo de producto, solo cambia el énfasis.
| Producto | Enfatiza en el prompt |
|---|---|
| Sitio vitrina | Tono, marca y textos de sección (hero, servicios, prueba social, contacto). |
| App web / MVP | Entidades, relaciones, roles y el trabajo principal a realizar. |
| App móvil | Patrones de navegación, acciones cómodas con el pulgar, necesidades offline, layout en pantalla pequeña. |
Para un recorrido específico de móvil, ver cómo crear una aplicación móvil. Para validar una idea de producto con la misma disciplina de prompts, combina esta guía con cómo construir el MVP de una startup.
Poner el marco en práctica
La anatomía, el ritmo de iteración y los hábitos de re-prompting de esta guía sirven para cualquier builder de apps con IA. Empieza con un brief amplio que cubra propósito, usuarios y pantallas clave; afina pantalla por pantalla; distingue los cambios estructurales de los micro-ajustes.
Regla de oro
Un prompt = un cambio. Los mensajes cortos y enfocados superan a las peticiones largas que intentan rediseñar media app de golpe.
Antes de generar, somete tu prompt a la misma prueba que usarías con un nuevo colaborador competente: ¿alguien con casi ningún contexto podría entregar la primera versión correcta solo con este brief? Si sí, estás listo para iterar pantalla por pantalla hasta que cada pantalla coincida con lo que tenías en mente.