Cómo escribir prompts para AI app builders (con ejemplos de antes y después)
Observa a dos personas usando el mismo AI app builder durante una hora. Una tiene una app funcionando; la otra tiene un desastre y la opinión de que "la programación con IA está sobrevalorada". La herramienta era idéntica. Los prompts no.
Promptear a un app builder es una habilidad distinta de promptear a un chatbot. No estás haciendo preguntas — estás dando órdenes de trabajo a un agente que tomará docenas de decisiones basándose en lo que dijiste y lo que no dijiste. Esto es lo que funciona de verdad, con ejemplos de antes y después a lo largo del texto.
El primer prompt: adelanta decisiones, omite la implementación
Tu prompt inicial establece la base del proyecto. El agente rellena cada hueco que dejes con una suposición, y aunque los buenos agentes suponen con sensatez, cada suposición es un volado sobre si coincide con tu intención.
Antes:
Hazme una app de fitness.
Después:
Construye un rastreador de entrenamientos para levantadores de pesas. Datos: los entrenamientos tienen una fecha; cada entrenamiento tiene registros con nombre de ejercicio, series, repeticiones y peso. Pantallas: (1) el registro de hoy con entrada rápida, (2) historial agrupado por semana, (3) un gráfico de progreso por ejercicio. Un solo usuario, sin necesidad de login. Diseño oscuro y minimalista.
La versión del "después" decide la audiencia, el modelo de datos, las pantallas, el alcance de la autenticación y la dirección visual — las cinco decisiones que son caras de cambiar más tarde. Fíjate en lo que no incluye: ni stack tecnológico, ni elección de base de datos, ni librerías de componentes. Una buena plataforma toma esas decisiones mejor de lo que puede hacerlo un prompt, y saturar tu brief con términos técnicos entendidos a medias hace daño activamente ("usa MongoDB" cuando la plataforma está construida alrededor de Postgres solo crea fricción).
Una estructura que funciona consistentemente:
- Qué es, en una frase, con la audiencia.
- Los datos, como sustantivos y campos simples.
- Las pantallas, numeradas.
- Exclusiones explícitas — "sin login", "sin pagos". Las exclusiones previenen el alcance que el agente inventaría amablemente por su cuenta.
Prompts de iteración: un cambio, anclado a un lugar
Después de la primera construcción, tus prompts cambian de carácter: de arquitectura a cirugía. Dos reglas hacen la mayor parte del trabajo.
Un cambio por mensaje. Las peticiones empaquetadas fallan como unidad — cuando uno de los cinco cambios sale mal, terminas re-prompteando alrededor de los otros cuatro.
Ancla cada cambio a una ubicación.
Antes:
Las fechas se ven mal.
Después:
En la página de historial, los encabezados de semana muestran "Semana 32". Muestra un rango de fechas en su lugar, como "4 ago – 10 ago".
Nombra la pantalla, cita el texto incorrecto, describe el texto correcto. El agente encuentra el punto exacto en lugar de andar cazando — menos suposiciones erradas, menos créditos.
Describe resultados, no implementaciones
Tendrás la tentación de hablar como desarrollador. Resístela, a menos que lo seas.
Antes:
Añade un useEffect que refetchee al montar y memoiza el renderizado de la lista.
Después:
Cuando vuelvo al dashboard después de añadir un gasto, el total sigue mostrando el número viejo hasta que refresco. Debería estar actualizado.
La primera versión compromete al agente con tu diagnóstico, que puede estar equivocado. La segunda le da el defecto real — aquello de lo que estás seguro — y le deja encontrar la causa. Describe los síntomas con la confianza de un usuario; deja los diagnósticos a la cosa que puede leer el código.
Usa referencias — le ganan a los adjetivos
"Moderno y limpio" no significa nada; todo diseño desde 2010 lo ha proclamado. Las referencias transmiten órdenes de magnitud más información:
Haz que la sección de precios se sienta como la página de precios de Linear: mucho espacio en blanco, bordes finos, un solo color de acento.
Mejor aún, adjunta una captura de pantalla — de una app que te guste, de un boceto a mano, del layout roto concreto que estás describiendo. Las plataformas que aceptan imágenes adjuntas (Massvai lo hace) resuelven la ambigüedad visual a partir de una imagen mucho más rápido que a partir de prosa. Una captura del bug con una leyenda de una línea es el formato de prompt de mayor valor que existe.
Cuando sale mal: deja de cavar
El error de prompting más caro no es un mal prompt — es el cuarto intento consecutivo de parchear una dirección que está fundamentalmente mal.
Si dos intentos del mismo arreglo no han funcionado, cambia de estrategia:
- Haz rollback. Restaura el checkpoint anterior al desastre (Massvai guarda una instantánea de cada generación) y reintenta con una descripción distinta. Retroceder se siente como una pérdida; suele ser el camino más rápido hacia adelante.
- Aleja el zoom. En lugar de re-describir el arreglo, describe el objetivo: "Olvida las instrucciones anteriores sobre el dropdown de filtros. Esto es lo que intento que los usuarios puedan hacer: …" Los agentes manejan objetivos frescos mejor que instrucciones de parche acumuladas.
Una chuleta rápida
| Situación | Haz | No hagas |
|---|---|---|
| Empezar un proyecto | Audiencia + datos + pantallas + exclusiones | "Hazme una app para X" |
| Pedir un cambio | Un cambio, anclado a una pantalla | Cinco cambios en un mensaje |
| Reportar un bug | Síntoma, dónde, comportamiento esperado | Tu suposición de la causa a nivel de código |
| Dirección de diseño | Apps de referencia y capturas de pantalla | Sopa de adjetivos |
| Atascado tras 2 intentos | Rollback y re-describir el objetivo | "Intenta de nuevo" por quinta vez |
Nada de esto es exótico. Es la misma claridad que le deberías a un contratista humano — solo que este contratista lee con atención, nunca se molesta por el detalle y empieza a trabajar en segundos. Dale un brief digno de eso.