Buenas prácticas de prompt
El builder es bueno traduciendo descripciones concretas a código. Es malo adivinando qué tienes en la cabeza. Estas son las reglas que más diferencia hacen entre un primer intento que sale rodado y media hora pidiendo cosas distintas.
Cada regla viene con un ejemplo mal y uno bien. Los "mal" no son inventados — son los errores que más vemos.
1. Sé específico con la forma de la app
El modelo elige una pila técnica y un layout por defecto. Si no le dices cuál quieres, elige la más probable para una descripción genérica — y suele no ser la que tú tenías en mente.
| ✗ Mal | ✓ Bien |
|---|---|
| Una app para gestionar mi tienda. | Una sola página HTML con un listado de productos a la izquierda y un panel de detalle a la derecha. Sin login, sin backend — los datos en un JSON dentro del propio HTML. |
2. Nombra las entidades explícitamente
"Cosas", "elementos", "items" son palabras vacías. El modelo no puede inferir el dominio de eso.
| ✗ Mal | ✓ Bien |
|---|---|
| Quiero gestionar mis cosas. | Quiero gestionar plantas de interior: nombre, fecha del último riego, frecuencia de riego en días, y una nota libre. |
Pista: si tu primer prompt no contiene al menos un sustantivo concreto del dominio, párate y reescríbelo.
3. Da ejemplos de datos desde el primer turno
Tres filas de ejemplo le dicen al modelo más que dos párrafos de descripción. También fijan el formato sin tener que negociarlo después.
| ✗ Mal | ✓ Bien |
|---|---|
| Una lista de gastos con categoría. | Una lista de gastos: fecha, importe, categoría, descripción. Empieza precargada con: 2026-05-12, 23.40€, comida, comida india; 2026-05-14, 8.90€, transporte, taxi; 2026-05-18, 45.00€, ocio, cine + cena. |
4. Pide el esqueleto antes que la lógica
En el primer turno: estructura, navegación, datos de ejemplo estáticos. La lógica de negocio (cálculos, filtros, persistencia) en el segundo o tercero, cuando ya tienes algo en pantalla.
| ✗ Mal | ✓ Bien (turno 1) | ✓ Bien (turno 2) |
|---|---|---|
| Quiero un dashboard que calcule mi runway, descontando suscripciones recurrentes y ajustando por inflación al 3%, con proyecciones a 12 y 24 meses. | Un dashboard con tres tarjetas arriba (saldo, ingresos del mes, gastos del mes), un gráfico de barras debajo, y datos de ejemplo. Estilo limpio, sin librerías de UI. | Ahora añade el cálculo de runway: divide el saldo entre los gastos mensuales medios de los últimos 3 meses. Muéstralo en una cuarta tarjeta. |
5. Cuando algo no funcione, describe lo que ves, no lo que pediste
El modelo no se acuerda de tu intención original tan bien como tú. Pero si describes el síntoma actual sabe exactamente qué tocar.
| ✗ Mal | ✓ Bien |
|---|---|
| Eso no es lo que te pedí. | El botón "guardar" está abajo del todo, fuera del formulario, y no hace nada al pulsarlo. Quiero que esté dentro del formulario, debajo del último campo, y que añada una fila a la tabla. |
6. Una idea por turno
Cuanto más mezcles, peor el resultado. El modelo intenta atender a todo y deja cada cosa a medio hacer.
| ✗ Mal | ✓ Bien (4 turnos) |
|---|---|
| Cambia el color a azul oscuro, añade un campo de email, valida que sea válido, manda un correo de bienvenida, y pon una animación al header. | (1) Cambia el color principal a azul oscuro #1e3a8a. (2) Añade un campo email al formulario, requerido. (3) Valida que tenga formato email; muestra un mensaje rojo debajo si no. (4) Cuando se envíe correctamente, anima el header con un fade-in. |
(El envío real de correo no se hace desde el builder — es lógica de backend; eso es para otro contexto.)
7. Cita fragmentos visibles cuando algo es ambiguo
Si dices "el botón de arriba", puede haber tres. Pega el texto literal.
| ✗ Mal | ✓ Bien |
|---|---|
| Haz el botón de arriba más grande. | Haz el botón cuyo texto es "Crear cuenta" un 20% más grande y centrado. |
Lo mismo aplica a textos que quieres cambiar: pega el original, pega el nuevo. No describas el cambio en abstracto.
8. Evita pedir lógica de negocio compleja sin validarla a mano antes
Reglas con muchas condiciones (impuestos por país, descuentos por volumen, tarifas escalonadas) producen código plausible que está mal en los bordes. Si las necesitas:
- Escribe dos o tres casos de prueba concretos en el propio prompt: "para 5 unidades a 10€, IVA 21%, descuento 5% — el total debe ser 49,88€".
- Pide al modelo que implemente y verifique con tus casos.
- Si falla un caso, dáselo de vuelta tal cual.
| ✗ Mal | ✓ Bien |
|---|---|
| Calcula el precio final con impuestos y descuentos según la lógica habitual. | Calcula precio final = unidades × precio_unidad × (1 - descuento) × (1 + IVA). Casos: (1) 5 × 10€, sin descuento, IVA 21% → 60,50€. (2) 10 × 20€, descuento 10%, IVA 0% → 180,00€. (3) 1 × 99,99€, descuento 0%, IVA 4% → 103,99€. Si tu implementación no coincide, ajústala. |
9. Especifica el estilo con referencias concretas, no con adjetivos
"Moderno", "limpio", "elegante" son ruido. Da paletas, espaciados o referencias.
| ✗ Mal | ✓ Bien |
|---|---|
| Que tenga un diseño moderno y limpio. | Tipografía sans-serif, ~16px base. Fondo blanco, texto #1a1a1a, acentos en azul #2563eb. Bordes redondeados 8px. Espaciado generoso entre secciones (mínimo 48px). Sin sombras pesadas. |
10. No prometas integraciones externas que no has cableado
El builder construye apps front-end completas, pero no puede llamar a Stripe, Mailgun o tu CRM sin claves que tú no le has pasado.
| ✗ Mal | ✓ Bien |
|---|---|
| Cuando el usuario pague, mándale un email de confirmación y crea el usuario en Supabase. | Al enviar el formulario, simula el pago con un timeout de 1,5 s y un toast que diga "Pago recibido (demo)". La integración real con pasarelas la añadimos después por código. |
deferred Las integraciones reales (Stripe, email, OAuth, bases de datos externas) se conectarán desde la página de la app publicada, no desde el builder.
11. Itera con diffs, no con rewrites
Cada turno ya aplica diffs por defecto. Aprovéchalo: pide cambios pequeños y nombrados, no descripciones de la app entera.
| ✗ Mal | ✓ Bien |
|---|---|
| Vale, ahora quiero la app entera otra vez pero con el campo email obligatorio y el botón verde y un footer con copyright. | (1) Haz el campo email obligatorio. (2) Cambia el color del botón principal a verde #16a34a. (3) Añade un footer con "© 2026 — mi-app". |
Si de verdad necesitas regenerar todo, dilo: "rehaz la app entera desde cero con estos requisitos…" — y el modelo lo entenderá como una intención explícita, no como un descuido.
12. Cuando dudes, lee los ficheros generados
La pestaña files no es solo para curiosos. Si un cambio que pediste
no aparece en el preview, abre el fichero relevante y mira si el
modelo lo aplicó. Muchas veces el modelo sí hizo el cambio y el
problema es de caché del navegador o de un componente que no lee la
variable nueva — eso lo diagnosticas en 10 segundos mirando el
fichero, no escribiendo otro prompt.
Resumen de bolsillo
- Específico con la forma.
- Nombra las entidades.
- Ejemplos de datos.
- Esqueleto antes que lógica.
- Describe el síntoma.
- Una idea por turno.
- Cita el texto visible.
- Lógica compleja → casos de prueba.
- Estilo con paletas, no con adjetivos.
- No prometas integraciones que no tienes.
- Itera con diffs.
- Lee los ficheros generados.
Pega este resumen junto al editor las primeras semanas. Después no te hará falta — se vuelve automático.