Crear una app con IA eliminó la necesidad de escribir código, pero no la de pensar con claridad. El cuello de botella simplemente se movió: en lugar de escribir sintaxis, ahora redactas un brief. Un prompt vago produce una app vaga — pantallas genéricas, funcionalidades inventadas, casos límite olvidados — mientras que uno preciso se acerca notablemente a lo que realmente necesitabas desde el primer intento. Esta guía explica qué contiene realmente un buen prompt para crear una app, muestra ejemplos malos y buenos lado a lado, y explica cómo iterar sin romper lo que ya funciona.
La anatomía de un buen prompt para crear una app
Piensa en tu prompt como el brief que le darías a 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 cosa principal que alguien debe poder hacer — vender un servicio, seguir proyectos, gestionar una lista de espera.
- Usuarios: quién la usa realmente — una sola persona, un pequeño equipo interno, clientes externos, o varios roles con accesos distintos.
- Pantallas clave: las cuatro a seis páginas más importantes, nombradas explícitamente — panel principal, lista de clientes, detalle de factura, ajustes.
- Entidades de datos: los "sustantivos" de tu app y cómo se relacionan — un cliente tiene varios proyectos, un proyecto tiene varias facturas.
- Restricciones: todo lo que no es negociable — inicio de sesión obligatorio, pagos, prioridad móvil, una integración concreta.
- Tono y marca: el estilo visual deseado — colores, referencias de estilo, formal o distendido.
Un prompt malo vs un prompt bueno
La diferencia entre una app mediocre y una realmente útil casi nunca es el modelo de IA usado — casi siempre es el prompt. Aquí tienes la misma idea, escrita dos veces.
Prompt malo: "Créame una app para gestionar mis clientes."
Esta frase no tiene contexto, pantallas definidas, modelo de datos ni restricciones. La IA tendrá que inventarlo todo, y lo que invente rara vez coincidirá con lo que realmente tenías en mente — campos genéricos, un flujo de trabajo inventado, ninguna idea de si trabajas solo o en equipo.
Prompt bueno: "Dirijo una pequeña agencia de diseño con otros dos freelancers. Créame un portal de clientes donde podamos ver todos nuestros clientes, los proyectos asociados a cada uno, y las facturas de cada proyecto. Necesito un panel que muestre los proyectos activos, una lista de clientes con sus datos de contacto, y una página de proyecto con las tareas y facturas junto a su estado (borrador, enviada, pagada). Los clientes deben poder iniciar sesión y ver solo sus propios proyectos y facturas — no los datos de otros clientes. Mantén un diseño limpio y minimalista, en azul y blanco."
Esta versión da el contexto (una agencia de diseño, tres usuarios), el objetivo (centralizar clientes, proyectos y facturas), las entidades de datos y sus relaciones (cliente → proyecto → factura), las pantallas clave, una restricción real (acceso por roles para que cada cliente vea solo sus propios datos) y un tono (limpio, minimalista, azul y blanco). A la IA casi no le queda nada que adivinar.
Empieza amplio, luego afina pantalla por pantalla
Intentar describir cada pantalla, cada campo y cada regla en un único prompt gigante suele salir mal: la IA tiene que retener demasiado a la vez y algo se pierde o queda a medio implementar. Un ritmo mejor es empezar con un prompt amplio que defina toda la forma de la app — las entidades, las pantallas principales, la navegación — y luego avanzar pantalla por pantalla, afinando una pieza a la vez.
- Primer prompt: describe el propósito de la app, sus usuarios y el puñado de pantallas necesarias, para que la IA construya el esqueleto general.
- Segunda ronda: elige una pantalla y profundiza — "en la lista de clientes, añade una barra de búsqueda y un filtro por estado."
- Tercera ronda: pasa a la siguiente pantalla una vez que la anterior te convenza, en lugar de saltar entre varias a la vez.
Esto refleja cómo se construye un producto real: primero un esqueleto sólido, luego se añade profundidad función por función, pantalla por pantalla — nunca todo a la vez.
Re-promptear vs micro-parches
No todas las peticiones deben formularse igual. Un cambio estructural — añadir una entidad completamente nueva, replantear la navegación, cambiar cómo se relacionan dos pantallas — merece un prompt nuevo y completo que vuelva a explicar el contexto de esa parte de la app. Un cambio pequeño y contenido — renombrar una etiqueta, ajustar un color, ordenar una lista de otra forma — se gestiona mejor como un mensaje de chat corto que describe exactamente el resultado que quieres.
- Re-promptea cuando: estás añadiendo un concepto nuevo al modelo de datos, fusionando o dividiendo pantallas, o cambiando cómo funcionan los roles y permisos.
- Micro-parchea cuando: estás ajustando un texto, un estilo, un orden, o un solo campo en una pantalla existente.
- Incluso en un micro-parche, nombra la pantalla y el elemento exacto — "en la página de detalle de factura, cambia la etiqueta 'Pagada' a verde" es mucho más seguro que "hazlo más bonito".
Errores comunes que sabotean tus prompts
- Ser demasiado vago. "Hazlo moderno y profesional" no le da nada concreto a la IA — describe qué significan moderno y profesional para ti: un sitio de referencia, un color, un layout.
- Pedir demasiadas funcionalidades a la vez. Un prompt que cubre autenticación, pagos, un panel y un sistema de notificaciones de golpe obliga a la IA a repartir su atención entre todo eso a la vez.
- Describir la implementación en vez del resultado. "Usa un useEffect para obtener los datos y guardarlos en un reducer" explica cómo programar, pero no qué debe hacer realmente la pantalla para el usuario — describe el resultado que quieres, no la técnica.
- Olvidar los casos límite. ¿Qué pasa con una lista vacía, un pago fallido, un cliente sin ningún proyecto? Nombrarlos desde el principio ahorra todo un ciclo de depuración más adelante.
Consejos para el vibe coding con un AI app builder
- Nombra la pantalla de la que hablas. "En el panel principal" o "en la página de ajustes" elimina cualquier ambigüedad sobre dónde se aplica un cambio.
- Da ejemplos reales. En lugar de "añade una tabla de precios", pega los nombres reales de los planes y los precios que quieres mostrar.
- Cambia una cosa a la vez al afinar. Es mucho más fácil saber qué funcionó cuando un prompt tiene una única intención clara.
- Prueba con datos reales pronto. Una pantalla que se ve perfecta con tres filas de ejemplo puede romperse con cincuenta filas reales — compruébalo cuanto antes.
- Di qué debe quedar igual. Si estás afinando una pantalla, menciona que el resto de la app debe quedar intacto.
La misma anatomía funciona para sitios vitrina, apps web y móviles
El marco de contexto, objetivo, usuarios, pantallas, datos y restricciones no cambia según lo que estés creando — solo cambia dónde pones el énfasis. Para un sitio vitrina, dale más peso al tono, la marca y los textos de cada sección (portada, servicios, testimonios, contacto). Para una app web, dale más peso a las entidades de datos y sus relaciones, porque eso es lo que tiene que aguantar con el tiempo. Para una app móvil, añade restricciones sobre patrones de navegación, comportamiento sin conexión y cómo debe sentirse la experiencia en una pantalla pequeña. El mismo prompt claro y estructurado simplemente se aplica a un tipo de producto distinto.
Cómo te ayuda Cadrant
Cadrant está construido en torno a describir lo que quieres en lenguaje natural e ir afinándolo mediante la conversación. Empiezas con un prompt amplio que describe tu app — su propósito, sus usuarios y sus pantallas clave — y Cadrant genera una primera versión funcional. A partir de ahí, iteras por chat, pantalla por pantalla, exactamente como recomienda esta guía: un mensaje concreto para añadir una funcionalidad, uno corto para ajustar un detalle, uno más completo cuando introduces algo nuevo en el modelo de datos.
Este mismo flujo en lenguaje natural se aplica tanto si estás creando un sitio vitrina, una app web completa con autenticación y base de datos, o una app móvil — describes el resultado, Cadrant se encarga de la implementación, y sigues afinando hasta que cada pantalla coincide con lo que tenías en mente.