Construir vs APRENDER a construir
Ayer di una charla sobre fundamentos de vibe coding a un grupo de emprendedores. La he convertido en el artículo más extenso (y visual) que he escrito nunca.
¡Hola viber!
Venga, que ya está terminando el año. Yo voy con las pilas a tope, ¿y tú?
Hoy quiero contarte que ayer di una charla para la comunidad de Gupi, un all-in-one para emprendedores que ofrece formación, marketplace de servicios, y apoyo en fundraising, legal, tech y todo lo que una startup necesita para crecer.
Todo surgió a raíz del VibeCodeDay, donde di una charla con NocodeHackers. Entre los asistentes estaba Arnau Ortiz Amenós, Founder y CPO de Gupi. Desde entonces he estado asesorándolo para construir algo nuevo dentro de Gupi con vibe coding, y hace unos días me propuso dar una charla para su comunidad sobre fundamentos de vibe coding.
El contenido fue tan bueno que decidí convertirlo en este artículo: una guía paso a paso de todo lo que necesitas antes de abrir Lovable, Cursor o cualquier herramienta de vibe coding.
Construir vs aprender a construir
Hay dos formas de hacer vibe coding:
Construir sin más: Abres Lovable, le dices “hazme una app de tareas” y en 10 minutos tienes algo funcionando. Rápido, emocionante y mágico. Hasta que quieres modificarlo y todo se rompe. No sabes por qué falla, no entiendes la estructura y cada cambio es una ruleta rusa que te acerca a la autodestrucción.
Aprender a construir: Más lento al principio, pero te da autonomía técnica. Entiendes qué estás construyendo, por qué funciona así, y cómo modificarlo sin romperlo todo. A largo plazo, construyes mejor y más rápido.
Este artículo es para los que eligen aprender a construir.
El framework: los 3 documentos base
Antes de abrir ninguna herramienta, necesitas tres documentos que definen tu proyecto:
PRD (Product Requirements Document) - El mapa de tu proyecto
Sistema de diseño - Consistencia visual
Schema de base de datos - Estructura de datos (solo si tu app guarda información)
Con estos tres documentos, el desarrollo deja de ser magia y se convierte en un proceso controlado.
Vamos paso a paso.
Paso 0: Clarifica tu idea
Antes de hablar con ninguna IA, necesitas tener claro qué quieres construir. Suena obvio, pero la mayoría de proyectos fallan aquí.
Hay dos formas de clarificar:
1. Cierra los ojos e imagínalo
Si puedes visualizar toda la aplicación en tu cabeza (qué ve el usuario cuando entra, qué puede hacer, cómo navega), ya tienes medio camino hecho. Pero no todo el mundo tiene esta capacidad.
2. Dibújala
Si no puedes visualizarlo mentalmente, dibuja pantallas en papel. Líneas sencillas. Cuadrados que representan botones, rectángulos para texto, flechas mostrando qué pasa cuando haces clic. Esto te obliga a pensar en flujos de usuario antes de construir nada.
Ejemplo: si quieres crear una app de tareas estilo Trello, dibuja:
La pantalla inicial: ¿qué ve el usuario?
Las columnas: ¿cuántas hay? ¿son fijas o el usuario las crea?
Las tarjetas: ¿qué información tienen? ¿título, descripción, fecha?
Interacciones: ¿qué pasa cuando arrastras una tarjeta?
Cuanto más claro tengas esto, mejor será la conversación con la IA.
Paso 1: La conversación inicial con la IA
Abre Claude, ChatGPT o Gemini. Explícale tu idea. Trata a la IA como tu colega experto en desarrollo.
No busques prompts mágicos. Mantén una conversación.
Ejemplo de conversación:
Tú: Quiero construir una aplicación de tareas estilo Trello.
Tablero con columnas (por hacer, en progreso, hecho), poder
arrastrar tarjetas entre columnas, guardar el estado.
¿Qué necesito?
IA: [Te explicará stack, arquitectura, consideraciones]
Tú: ¿Qué es React? ¿Por qué lo necesito?
IA: [Te explica]
Tú: ¿Necesito base de datos? ¿Por qué?
IA: [Te explica que sí, para guardar las tarjetas y su estado]
Esta conversación te orienta sobre:
Qué stack usar (React, Astro, Next.js, etc.)
Qué funcionalidades son críticas para que funcione lo básico
Qué arquitectura necesitas (frontend solo, o frontend + backend + base de datos)
Si necesitas autenticación y por qué
La clave es hacer preguntas. Si no entiendes algo, pregunta. Si la IA menciona un término técnico que no conoces, pregunta.
Cuando empecé con ChatGPT en 2022, no existían Cursor ni Lovable. Todo se hacía en Visual Studio Code. Le pedía al chat que me explicara cada cosa que no entendía.
Era más lento, sí. Había fricción. Pero aprendía.
Ahora las herramientas son tan rápidas que puedes construir sin entender nada. Pero entonces estás vendido cuando algo falla. Y siempre falla.
La fricción es tu aliada. Te obliga a entender.
Paso 2: Construir el PRD
Una vez has tenido la conversación y todo está claro, pídele a la IA:
“Con todo lo que hemos hablado, redáctame el PRD completo.”
Como ya tiene todo el contexto de tu proyecto, te generará un documento estructurado.
¿Qué incluye un PRD?
Descripción general: Qué hace la app, para quién, qué problema resuelve
Funcionalidades principales: Lista específica de qué puede hacer el usuario
Arquitectura técnica: Stack elegido, estructura de carpetas, dependencias
Flujos de usuario: Qué pasa cuando el usuario hace X
Consideraciones técnicas: Autenticación, permisos, manejo de estados
Ejemplo práctico:
Si construyes una app de notas personales, el PRD descompone:
¿Qué hace el usuario cuando entra? → Login
¿Con qué se loguea? → Email/password o Google
¿Qué ve una vez dentro? → Lista de sus notas anteriores
¿De dónde salen esas notas? → Base de datos, filtradas por user_id
¿Puede ver notas de otros usuarios? → No, permisos por usuario
¿Puede crear nueva nota? → Sí, botón que abre formulario
¿Qué pasa cuando guarda? → Se envía a base de datos, aparece en lista
¿Puede editar/borrar? → Sí, solo las suyas
El PRD responde estas preguntas ANTES de construir. Es tu mapa.
Paso 3: Definir el sistema de diseño
Disclaimer para diseñadores: esto es una versión simplificada. No pretende ser exhaustiva.
Un sistema de diseño básico incluye:
1. Tokens de color
Primario, secundario, neutros
Estados: hover, active, disabled
2. Tipografía
Familias (una para títulos, otra para cuerpo)
Tamaños (h1, h2, h3, body, small)
Pesos (regular, medium, bold)
3. Espaciado
Sistema consistente (4px, 8px, 16px, 32px, 64px)
4. Componentes base
Botones (primary, secondary, ghost)
Inputs, cards, modales
5. Jerarquía visual
Cómo se organizan los elementos en la pantalla
Cómo conseguir esto sin ser diseñador
Tres opciones:
Opción 1: Inspírate en otras apps
Ve a Behance, Dribbble, Awwwards. Busca apps similares a la tuya. Haz capturas. Pásaselas a Claude y dile: “Extrae el sistema de diseño de esta app.”
Opción 2: Usa herramientas
Hay herramientas (como ds101 que creé hace algún tiempo) donde eliges colores primario/secundario y tipografías, y te genera todo el sistema en Markdown. Luego exportas y lo pegas en tu knowledge.
Opción 3: Deja que la IA lo haga
Si le dices a Claude “necesito un sistema de diseño minimalista con tonos azules y tipografía moderna”, te lo genera. No será perfecto, pero será un punto de partida.
Lo importante: tener un sistema antes de construir garantiza consistencia visual. Sin sistema, cada pantalla parece de una app diferente.
Paso 4: Schema de base de datos (opcional)
Este paso solo aplica si tu app necesita guardar datos.
Si es una landing estática, no necesitas esto. Si es una calculadora que no guarda nada, tampoco. Pero si necesitas usuarios, contenido, relaciones entre datos... necesitas base de datos.
¿Qué incluye el schema?
1. Tablas: Qué información guardas
Usuarios, publicaciones, comentarios, etc.
2. Campos: Qué datos tiene cada tabla
Tabla usuarios: id, email, password_hash, created_at
Tabla publicaciones: id, user_id, título, contenido, created_at
3. Relaciones: Cómo se conectan las tablas
Un usuario tiene muchas publicaciones (one-to-many)
Una publicación tiene muchos comentarios (one-to-many)
4. Permisos (RLS - Row Level Security): Quién puede leer/escribir qué
Los usuarios solo pueden ver sus propias publicaciones privadas
Los usuarios pueden ver todas las publicaciones públicas
Cómo conseguir el schema
Si ya tuviste la conversación inicial con Claude y le explicaste todas las funcionalidades, simplemente dile:
“Dame las instrucciones SQL para crear esta base de datos en Supabase.”
Te dará el código completo. Luego vas a Supabase, abres el SQL Editor, pegas el código, ejecutas, y listo.
Nota importante: Recomiendo Supabase porque tiene integraciones nativas con Lovable y otros builders. Te facilita la vida.
Si hay errores al ejecutar el SQL (y probablemente los haya), copias el error, se lo pasas a Claude, te lo corrige, vuelves a pegar. Así aprendes qué está pasando.
Este proceso tiene fricción, sí. Pero la fricción te enseña.
Paso 5: Elegir tu herramienta
Con los tres documentos listos (PRD + Design System + Schema), decides qué herramienta usar según las necesidades de tu proyecto.
Para principiantes: Builders visuales
Stack: React + Vite
Integración: Supabase nativa
Deployment: Automático a Netlify
Mejor para: Apps completas con backend, MVPs rápidos
Limitación: No optimizado para SEO (no sirve para landings que necesitas posicionar en Google)
Stack: React + Next.js
Mejor para: Componentes UI, landing pages, prototipos visuales
Ventaja: Preview instantáneo, export directo a código
Limitación: Más enfocado en componentes que en apps completas
Para avanzados: Control total
Stack: Cualquiera (Astro, Next.js, Python, lo que sea)
Ventaja: Control total del código, mejor para SEO
Mejor para: Proyectos complejos, landings que necesitan posicionamiento
Requiere: Más conocimiento técnico
Stack: Cualquiera
Interfaz: Terminal (CLI)
Mejor para: Desarrolladores que prefieren workflows existentes
Ventaja: Manejo autónomo de dependencias
La decisión es informada
Como ya sabes qué stack necesitas (lo definiste en el PRD), la elección es clara:
¿App React con backend? → Lovable
¿Landing con SEO? → Cursor + Astro
¿Componentes visuales? → v0
¿Control total desde terminal? → Claude Code
Hay herramienta correcta para cada caso.
Paso 6: Alimentar el knowledge
Ahora, ya tienes los tres documentos:
PRD.md
DesignSystem.md
DatabaseSchema.md
El siguiente paso es pegarlos en el knowledge de tu herramienta elegida.
En Lovable:
Vas a cualquier proyecto → Knowledge (en el menú lateral) → Pegas los tres documentos.
¿Por qué en el knowledge y no en el primer mensaje?
Si pegas todo en el primer mensaje, después de 50 mensajes el contexto se pierde. La IA empieza a hacer cosas raras porque “olvidó” las especificaciones iniciales.
Si lo pegas en el knowledge, siempre está accesible. No importa cuántos mensajes lleves, la IA puede consultar el PRD, el sistema de diseño, las especificaciones de base de datos.
Además, si en el PRD estructuraste el desarrollo por fases, puedes simplemente decir:
“Empieza a construir siguiendo el plan.”
Y la IA ya sabe qué hacer primero, qué después, y cómo.
Las limitaciones del vibe coding
No todo es posible con vibe coding. Las limitaciones vienen de tu nivel técnico.
Si no sabes qué es una base de datos, te costará explicarle a la IA qué necesitas. Si no entiendes qué es una API, no podrás pedirle que conecte servicios externos.
Pero esto no significa que necesites ser desarrollador. Significa que necesitas aprender conceptos básicos mientras construyes.
Y esa es la gran diferencia: antes, aprender a programar significaba años de estudio antes de construir nada útil. Ahora puedes construir mientras aprendes. La IA te explica conceptos en tiempo real, adaptados a tu proyecto específico.
Es aprender haciendo, pero con un tutor infinitamente paciente.
¿Quieres que dé una formación sobre vibe coding en tu empresa o academia?
Contacta conmigo en LinkedIn. También puedes seguirme en Substack o YouTube para más contenido sobre vibe coding.