Le describes a una IA la app que quieres, en español, y te la construye. Sin saber programar, sin instalar nada, sin abrir una terminal. Eso es vibe coding, y funciona mejor de lo que suena.
También truena mucho más de lo que la gente cuenta. El número que circula es que el 95% de las apps hechas así se rompen. No tengo cómo verificar esa cifra y no me hace falta: la causa sí la he visto una y otra vez, y siempre es la misma. La persona escribe un párrafo describiendo la app completa, le da enter, y espera que salga funcionando de un jalón.
Esta guía es el flujo que evita eso. Tres pasos, un prompt de brief que va entero más abajo, y la lista de errores que hacen que una app se caiga a la mitad.
Qué es y qué no es
Vibe coding es construir software describiendo lo que quieres en lenguaje normal. La IA escribe el código; tú describes, pruebas y corriges.
Lo que no es: no es magia y no te vuelve programador. El código existe, tiene errores, y en algún momento vas a tener que entender qué se rompió. La diferencia es que ahora puedes preguntarle a la misma IA qué se rompió, en vez de aprender cuatro años de sintaxis primero.
Y aterrizando el caso de uso real: esto es perfecto para la herramienta interna que nadie te va a construir. El tablero que tu área comercial pide desde hace un año. La calculadora de cotizaciones que hoy vive en un Excel con siete pestañas. El formulario que alimenta el proceso de alta de clientes. Cosas que un equipo de desarrollo nunca va a priorizar porque solo las usan ocho personas.
Con qué se construye
Hay tres herramientas que valen la pena para empezar, y se eligen por lo que quieres sacar de la experiencia, no por cuál es "mejor".
1. Lovable lovable.dev
La más amable si nunca has tocado código. Trae base de datos integrada con Supabase, así que las apps que guardan información —usuarios, registros, formularios— se arman sin que tú tengas que configurar nada por separado.
Para quién: el que quiere una app que funcione y no le interesa ver el código.
2. Bolt bolt.new
La más rápida para prototipar. Te devuelve una versión funcionando en unos ocho a diez minutos, lo cual la vuelve ideal para enseñarle una idea a alguien antes de decidir si vale la pena construirla en serio.
Para quién: el que necesita algo que se pueda tocar en la junta del jueves.
3. Replit replit.com
Te muestra el código conforme la IA lo escribe. Es la más lenta de las tres si solo quieres el resultado, y la única de las tres que te enseña algo.
Para quién: el que quiere entender qué está pasando, no solo que pase.
El flujo de tres pasos
Este es el orden que separa las apps que sobreviven de las que se caen. Ninguno de los tres pasos se salta.
Paso 1 — El brief, fuera de la herramienta
Antes de abrir Lovable o Bolt, abres Claude o ChatGPT y sacas un documento de una página que describa la app. Suena a burocracia y es el paso que más rendimiento da.
La razón es mecánica. Estas herramientas construyen a partir de lo que les dices, y si tú no tienes claro cuántas pantallas hay, qué datos guardas y quién se registra, la IA lo va a inventar. Va a inventar bien la primera vez y distinto la segunda, y para la tercera pantalla ya vas a tener tres criterios peleados adentro de la misma app.
Paso 2 — Solo la primera pantalla
Pegas el brief en la herramienta y le pides únicamente la primera pantalla. Nada más. Ni el login, ni el panel de administración, ni la vista de reportes.
Luego la pruebas de verdad: clic en cada botón, llenar cada campo, meter datos mal a propósito. Lo que falle, se arregla ahí. Una pantalla rota es un problema de veinte minutos; cinco pantallas rotas que dependen entre sí es un problema del que no sales.
Paso 3 — Una pantalla a la vez
Cuando la primera funciona, pides la segunda. Cuando la segunda funciona, la tercera. Cada vez le recuerdas qué ya existe y le pides que no lo toque.
Es lento y se siente tonto cuando la IA claramente podría hacer las cinco de un jalón. Puede hacerlas. También puede romper las dos que ya servían mientras hace la tercera, y tú no vas a tener forma de saber cuál cambio fue el que rompió qué.
El paso que todo mundo se salta: probar antes de pedir lo siguiente. La tentación es ver que la pantalla "se ve bien" y seguir. Se ve bien no es funciona. Dale clic a todo, mete un correo sin arroba, deja un campo vacío, refresca la página a media captura. El 90% de las apps que se caen es porque nadie hizo eso en la pantalla dos y el error quedó enterrado bajo cuatro pantallas más.
El prompt del brief
Este es el prompt completo. Va en Claude o ChatGPT, antes de tocar la herramienta de construcción. Te entrevista primero y luego te devuelve el documento que vas a pegar.
Vas a ayudarme a escribir el brief de una app que voy a construir
con una herramienta de IA (Lovable, Bolt o Replit). No sé programar.
Primero hazme estas nueve preguntas, UNA POR UNA, esperando mi
respuesta antes de pasar a la siguiente. Si mi respuesta es vaga,
repregunta hasta que sea concreta. No avances con respuestas
ambiguas.
1. En una frase, ¿qué hace esta app?
2. ¿Quién la va a usar y cuántas personas son?
3. ¿Cuál es el recorrido principal? Desde que alguien entra hasta
que logra lo que vino a hacer.
4. ¿Qué pantallas necesita? Nómbralas.
5. ¿Qué información hay que guardar? Lista los datos, no las tablas.
6. ¿Hay que iniciar sesión? ¿Todos ven lo mismo o hay roles?
7. ¿Cómo se debe ver? Dame dos referencias de sitios que te gusten.
8. ¿Qué es innegociable? Lo que si no está, la app no sirve.
9. ¿Qué NO debe hacer esta app? Lo que explícitamente queda fuera.
Cuando termines las nueve, escríbeme el brief con estas diez
secciones, en este orden, sin agregar ninguna otra:
1. QUÉ HACE ESTA APP — dos líneas.
2. PARA QUIÉN ES — el usuario y el contexto en el que la abre.
3. RECORRIDO PRINCIPAL — numerado, paso por paso.
4. PANTALLAS — cada una con su nombre y qué se ve en ella.
5. DATOS QUE SE GUARDAN — nombre del dato y de qué tipo es.
6. ACCESO — si hay registro, qué roles existen y qué ve cada uno.
7. DIRECCIÓN VISUAL — estilo, paleta y tono, en tres líneas.
8. REQUISITOS INNEGOCIABLES — lista corta.
9. QUÉ SE CONSTRUYE PRIMERO — una sola pantalla, la más importante,
y por qué esa.
10. INSTRUCCIONES PARA LA HERRAMIENTA — escritas en imperativo,
dirigidas a la IA que va a construir, incluyendo la orden de
construir SOLO lo que se le pida en cada turno y de no modificar
lo que ya funciona.
Reglas del brief: máximo una página. Sin adjetivos de marketing.
Nada de "moderno e intuitivo". Si algo no lo definí, ponlo en una
lista al final de "pendientes por definir" en vez de inventarlo.Los cinco errores que rompen todo
- Pedir la app completa en un prompt. Es el error número uno y es el que produce la mayoría de los desastres. La IA acepta el encargo, produce algo que parece completo, y adentro hay seis piezas a medias que no se hablan entre sí.
- Saltarse el brief. Sin brief, cada prompt es una negociación nueva sobre qué es la app. Terminas con cinco versiones de la misma idea peleando dentro del mismo proyecto.
- No probar mientras construyes. Ya lo dije arriba y lo repito porque es el que más caro sale.
- Prompts vagos. "Hazlo mejor" no es una instrucción. "El botón de guardar debe quedar abajo a la derecha y mostrar un mensaje de confirmación de dos segundos" sí lo es. La calidad de la app es proporcional a la especificidad de tus correcciones.
- Ignorar los errores. Cuando algo truena y la herramienta escupe un mensaje rojo, la reacción normal es volver a pedir "arréglalo". A veces funciona. Lo que funciona siempre es copiar el mensaje completo, pegarlo y preguntar qué significa antes de pedir el arreglo. Si no entiendes qué se rompió, la siguiente vez se rompe igual.
Antes de que alguien más lo use
Aquí va la parte que las guías de vibe coding no te dicen. En el momento en que tu app deja de ser un juguete personal y guarda información de otras personas —correos de clientes, datos de un formulario, cualquier cosa que no sea tuya— dejas de estar construyendo un prototipo y empiezas a tener una responsabilidad.
Antes de compartir el enlace con alguien fuera de tu escritorio, mínimo: pregúntale a la herramienta qué datos está guardando y quién puede verlos, revisa que no haya ninguna clave ni contraseña escrita dentro del código, y confirma que si alguien cambia el número en la dirección web no acabe viendo el registro de otra persona. Ese último es el error clásico de las apps hechas así.
Y si la app va a manejar información sensible de verdad, esa ya no es una app de vibe coding. Ahí necesitas a alguien que sepa. Reconocer ese límite es más útil que cualquier prompt de esta guía.
Por dónde empezar hoy
No empieces con la idea grande que traes en la cabeza. Empieza con la herramienta más aburrida que uses todos los días: el cálculo que haces a mano cada lunes, la lista que mantienes en una hoja suelta, el formato que llenas y reenvías.
Esa cosa aburrida tiene tres pantallas y la vas a poder probar tú mismo, que es exactamente lo que necesitas para aprender el flujo sin arriesgar nada. Cuando la termines, la idea grande te va a salir mucho mejor.