¡Volvemos una semana más con vibe coding para dummies!

Aunque no te lo parezca, ya ha pasado algo más de un mes desde la primera publicación, ¡así que estamos de celebración!

¡Gracias por leer Vibe Coding para Dummies! Suscríbete gratis para recibir nuevos posts y apoyar mi trabajo.

Es como cuando, de jóvenes (o no tan jóvenes), celebrábamos cada mes de relación con nuestra pareja ❤️

Si te soy sincero, no daba un duro por mi.

La constancia siempre ha sido mi punto débil, pero compartir mis conocimientos y ver que tienen “algo” de impacto, me llena de orgullo y satisfacción 😊

Y ver que cada semana se unen más personas, me dan ánimos para seguir compartiendo mi experiencia.

Bueno, al lío.

¿De dónde venimos y hacia dónde vamos?

Venimos de tres semanas (sin contar el post de presentación) en las que básicamente hemos visto teoría.

La primera semana vimos los tres pilares fundamentales (según yo) de un viber:

• Estructurar antes de construir

• Saber qué pedirle a la IA paso a paso

• Explorar herramientas con propósito, no por FOMO

La segunda semana pasamos a ver el PRD conversacional, esa hoja de ruta que nace de conversar con tu IA favorita y evita que tu proyecto se convierta en Frankenstein.

Por último, la semana pasada pasamos del PRD al producto “real”.

Y sí, pongo comillas ya que lo que construimos fue una página web estática con ChatGPT con los datos hardcodeados.

En programación, hardcodear se refiere a la práctica de incluir valores directamente en el código fuente en lugar de obtenerlos de forma dinámica.

¿Cómo podemos obtener los datos de forma dinámica?

Aquí empieza el bloque de “hacia dónde vamos” 😀

Fuentes de datos dinámicos

Los datos dinámicos son información que cambia con el tiempo y se actualizan automáticamente en tu aplicación.

A diferencia de los datos “hardcodeados”, los datos dinámicos se obtienen de fuentes externas.

Por ejemplo, en el caso que vimos la semana pasada, en el vídeo te mostré como podíamos introducir manualmente las urls sociales a una página web tipo linktree.

Pero, ¿qué ocurre cuando este servicio lo queremos expandir y que otras personas puedan añadir sus propios links?

No podemos (bueno, sí podríamos, pero sería poco usable) tener decenas o centenares de archivos estáticos con los datos hardcodeados de todos los usuarios.

Imagínate que alguien quiere cambiar una url, su nombre o cualquier otro dato de su perfil.

Sería un rollazo, ya que (imagina) nos debería enviar un email, luego tendríamos que ir al código y cambiar manualmente ese dato.

No es viable.

Cuando hablamos de datos dinámicos, tenemos tres opciones principales para alimentar nuestra aplicación.

Opción 1: APIs Externas - Usar datos de otros

Una API es básicamente un servicio que alguien más ha creado y mantiene, y tú puedes usar sus datos.

Por ejemplo, si quieres mostrar el tiempo en tu app, no necesitas instalar estaciones meteorológicas por todo el mundo.

Simplemente usas la API del tiempo de Google, le preguntas “¿qué tiempo hace en Barcelona?” y te responde con la temperatura actual.

Otros ejemplos típicos son APIs de noticias (para mostrar los últimos titulares), APIs de libros (para buscar información sobre cualquier libro), o APIs de restaurantes (para mostrar reseñas y horarios).

Lo bueno de las APIs externas es que accedes a información súper especializada sin esfuerzo.

Lo malo es que dependes de que ese servicio funcione siempre y tenga los datos actualizados.

Opción 2: Tu propia base de datos - Guardar lo tuyo

Una base de datos es tu propio almacén digital donde guardas toda la información importante de tu aplicación.

Siguiendo con el ejemplo del linktree, aquí es donde guardamos toda la información de los usuarios.

Sus nombres, sus enlaces, sus fotos de perfil, sus preferencias de colores, etc.

Cuando un usuario quiere cambiar su nombre, tu aplicación va a la base de datos, encuentra su perfil, actualiza el nombre, y listo.

Inmediatamente se ve reflejado en su página sin que tú tengas que tocar ni una línea de código.

Para vibe coders, las opciones más populares son Supabase (súper fácil de configurar) o Firebase (de Google).

Lo bueno es que tienes control total sobre tus datos y no dependes de nadie.

Lo malo es que tienes que configurarlo y mantenerlo tú.

Opción 3: Servicios híbridos - Lo mejor de ambos mundos

Algunos servicios actúan como una mezcla entre una API y una base de datos.

Te dan la facilidad de uso de una API pero también te permiten editar y organizar los datos fácilmente.

Por ejemplo, puedes usar Notion como base de datos para tu blog.

Escribes tus artículos cómodamente en Notion (con su editor visual que ya conoces) y luego tu web va a buscar esos artículos via API.

Cambias algo en Notion y automáticamente se actualiza en tu web.

O puedes usar Google Sheets como base de datos para proyectos simples.

Imagínate una web que muestra restaurantes recomendados: tienes la información en una hoja de cálculo súper fácil de editar, y tu web la lee automáticamente.

¿Cuándo usar cada opción?

La decisión depende del tipo de datos que necesites y de quién los va a gestionar.

Usa APIs externas cuando:

Necesites información que cambia constantemente y que mantiene otra persona.

El tiempo, noticias, precios de productos, información de libros o películas, datos de redes sociales.

Básicamente, cuando no tiene sentido que tú mantengas esa información porque ya existe un servicio especializado.

Usa tu propia base de datos cuando:

La información sea específica de tu aplicación.

Usuarios, configuraciones, contenido creado por tus usuarios, históricos de acciones, cualquier cosa que sea única de tu proyecto.

Es decir, datos que solo tu aplicación genera y necesita.

Usa servicios híbridos cuando:

Quieras empezar rápido o cuando personas no técnicas vayan a editar los datos.

Contenido de blogs, listas de productos, información de empresa, datos que cambian ocasionalmente y que prefieres editar en una interfaz familiar.

¿Qué ocurre en una aplicación real?

En la práctica, la mayoría de aplicaciones usan una combinación de las tres opciones.

Imagínate una app de fitness personal.

Usa una API externa para buscar información nutricional de alimentos (proteínas, calorías, etc.).

Usa su propia base de datos para guardar los entrenamientos del usuario, su progreso, sus objetivos.

Y podría usar Notion como servicio híbrido para gestionar las rutinas de ejercicios, que el entrenador puede editar fácilmente.

El usuario abre la app, ve su progreso personal (desde la base de datos), busca un alimento y ve sus calorías (desde la API externa), y sigue una rutina (desde Notion).

Todo funciona de forma transparente, pero por detrás están trabajando tres fuentes de datos diferentes.

Esta semana, por temas de timing, no me ha dado tiempo de grabarte un vídeo en condiciones aplicando estos conceptos, ¡pero lo tengo pendiente!

Lo voy a compartir en los próximos días en Vibe Coding para Dummies en YouTube, así que si aún no lo has hecho, te invito a suscribirte y activar las notificaciones.

Tu reto para esta semana: Conviértete en detective de APIs

Como esta semana hemos hablado de teoría, tu misión es empezar a familiarizarte con el ecosistema de datos dinámicos.

El reto es simple pero muy valioso:

Encuentra 3-4 APIs diferentes que te parezcan interesantes e investiga:

1. Qué datos proporcionan (clima, libros, noticias, etc.)

2. Si son gratuitas o de pago (y qué límites tienen)

3. Qué tipo de aplicación podrías crear con esos datos

4. Si requieren registro o puedes usarlas directamente

Algunas sugerencias para empezar:

• JSONPlaceholder - Datos fake perfectos para prototipos

• OpenWeather - Datos meteorológicos

• The Cat API - Fotos aleatorias de gatos (sí, existe)

• Google Books API - Información de libros

• NewsAPI - Noticias de todo el mundo

Pero no te quedes solo con estas.

Busca APIs relacionadas con tus intereses: deportes, cocina, música, finanzas, tecnología...

¿Dónde buscar más APIs?

• Public APIs GitHub - Lista gigante de APIs públicas

• RapidAPI - Marketplace de APIs

• ProgrammableWeb - Directorio de APIs

El objetivo no es usar las APIs todavía (eso viene la semana que viene).

Solo quiero que te familiarices con la variedad de datos que existen y empieces a pensar en qué podrías crear.

Bonus points: Si encuentras una API que te emocione especialmente, compártela en LinkedIn etiquetándome. Me encanta descubrir APIs nuevas y originales.

¿Por qué es importante este ejercicio?

Porque muchas veces limitamos nuestras ideas a lo que conocemos.

Cuando veas la cantidad de datos disponibles ahí fuera, se te van a ocurrir ideas de aplicaciones que ni sabías que eran posibles.

Y esa es la verdadera magia del vibe coding: conectar datos de formas creativas para resolver problemas reales.

¡Y hasta aquí la newsletter de esta semana!

Si te ha quedado alguna duda, escribe un comentario o mándame un mensaje, estaré encantado de ayudarte.

¡La newsletter de esta semana sale con retraso!

Espero que no vuelva a ocurrir... ¡Pero fue por un buen motivo!

¡Gracias por leer Vibe Coding para Dummies! Suscríbete gratis para recibir nuevos posts y apoyar mi trabajo.

Ayer hice mi primer webinar 😀

Ya sé, no es excusa, pero me llevó mucho tiempo de preparación y nervios y descuidé un poco la redacción de la news de esta semana...

¿De qué iba el webinar?

Pues del famoso PRD conversacional, ese del que te hablé la semana pasada. La idea con el webinar fue ponerlo en práctica.

Es decir, presentar un poco la teoría vista en la newsletter y luego hacer un PRD en vivo.

No salió del todo como esperaba, cosas del directo. En mi cabeza tenía mejor pinta, pero la gente quedó contenta, así que ÉXITO total 👍

¿Qué tal tú? ¿Has podido practicar?

¿Has probado a poner en práctica el PRD conversacional?

No era obligatorio, no te sientas obligad@, pero como en el cole, si vas practicando lo aprendido, luego no se te hará una montaña.

¿Qué vamos a ver hoy?

Pues hoy el tema va de poner en práctica el PRD, de ponerlo a trabajar para crear “algo”.

Mi idea era empezar a enseñarte cosas tal cual las aprendí en su momento, es decir, empezar con ChatGPT.

Realmente no sabía exactamente cómo enfocar esta publicación de hoy. De hecho, había empezado un borrador con Claude y lo he tirado completamente a la basura.

¿Por qué?

Bueno, porque quería hacer algo SUPER práctico, y al ser algo de construcción, le veía poco sentido a hacer un tutorial por escrito.

Así que esta tarde (jueves), me he liado la manta a la cabeza y he grabado un vídeo del tirón mostrando:

✅ El PRD

✅ Cómo traspasarlo a ChatGPT y generar el código de la aplicación

✅ Cómo traspasar el resultado que nos da la IA a un editor de código

✅ Visualizar el resultado final en el navegador

Así que esta semana hay poca teoría y vamos a ver cosas en directo.

El vídeo te lo adjunto unas líneas más abajo, y creo que es una manera genial de presentarte (redoble de tambores por favor):

¡Mi nuevo canal de YouTube! 🎬

“Pero Pol... ¡Cuántas novedades esta semana!”

Yaya, no paro.

Cada vez me atrevo con más cosas.

Recuerda que llevo CASI 3 años con esto del vibe coding...

Los recursos que necesitas para el reto de hoy

Para ponerte las cosas fáciles (para dummies), te adjunto los recursos que vas a necesitar:

🔗 Google Docs con el PRD prediseñado (por si no hiciste los deberes)

🤖 ChatGPT (a estas alturas creo que no necesita presentaciones)

💻 Visual Studio Code (el editor de código que vamos a usar)

Si ya tienes tu propio PRD, ¡úsalo! Solo te he puesto el de ejemplo por si no hiciste los deberes 😝

Sobre el editor de código: He elegido este porque es el que utilizo y es uno de los más conocidos. Si quieres usar otro, úsalo.

¡Ahora sí, dentro vídeo!

¿Qué tal lo has visto? Si te queda alguna duda, escríbelo en comentarios.

Te quería contar algo más antes de terminar:

Cuando he subido el vídeo a YouTube, antes de publicarlo, se lo he pasado a Fran Conejos para que me diera su opinión y me ha hecho reflexionar sobre algo.

Sus palabras textuales han sido:

“Muy guay pero no termino de entender por qué los mandas a descargarse vs code y lo llamas para dummies 😂”

Entiendo su punto de vista, y entiendo que tú te puedas sentir un poco abrumad@ cuando te descargues e instales Visual Studio Code.

Pero... Hemos venido a jugar, ¿no?

¿Qué significa “para dummies” en esta newsletter?

La definición textual de “dummies” en español dice:

“Puede usarse para describir a principiantes o inexpertos en un tema. Además, en algunos contextos, puede tener connotaciones de tonto o bobo.”

Pero para mí va más allá.

Para mi vibe coding para dummies consiste en explicar conceptos, funcionalidades y herramientas (que a priori pueden parecer complejas) en un lenguaje que todo el mundo pueda entender.

Es como cuando trabajaba en IKEA y me decían “explícale las cosas al cliente como si tuviera 4 años”.

No en plan despectivo, sino imaginando que (el cliente) no sabía nada del tema, no dando nada por supuesto.

Así es como me planteo esta newsletter.

¿Por qué empezar con lo “clásico”?

Fran también me ha hecho notar algo importante:

“Te tengo que recordar que cuando tú empezaste no existía Lovable ni Cursor. A lo mejor la senda (del viber) se podría modernizar un poco”

Entiendo y respeto completamente que tú también te puedas sentir/pensar igual que Fran.

Es sencillo: puedes saltarte estos posts y reengancharte cuando toque temas de Lovable o Bolt (que no tardaré mucho), ¡pero creo que te estarás perdiendo cosas muy interesantes!

En la práctica de hoy hemos hecho una web con la ayuda de la IA, pero con vibe coding también puedes hacer:

🔧 Una extensión para Chrome

🖥️ Una aplicación de escritorio con Python

📱 Un script de automatización

🛠️ Una herramienta de línea de comandos

Y para construir todo eso, se puede usar ChatGPT, Gemini o Claude.

¿Te lo vas a perder?

Nah... Yo creo que eres una persona curiosa y con sed de aprender cómo construir las movidas que tienes en la cabeza.

¡Nos vemos la próxima semana!

Ah, se me olvidaba, ¡el reto de hoy! Tienes dos opciones:

1. Aplicar el PRD que (en principio) hiciste la semana pasada

2. Aplicar el PRD que te he compartido, editarlo, expandirlo, ponte creativ@

En cualquier caso, a ver qué construyes 😀

Salga lo que salga, si te animas, ¡publícalo en LinkedIn!

Compártelo en tu red para que todo el mundo vea lo que estás aprendiendo en esta newsletter (y de paso me haces un poco de publicidad que nunca viene mal).

Ahora sí, hasta la semana que viene 🙂

PD: Si el formato en vídeo te gusta, haré más contenido así. Si prefieres texto, también puedo adaptarme. Tú decides

La semana pasada hablamos de los tres pilares fundamentales del vibe coding: la mente de arquitecto, el guión mental y la curiosidad dirigida (aquí tienes el Post 1 completo si te lo perdiste). Hoy vamos a profundizar en algo que cambiará completamente tu forma de abordar proyectos: tu PRD conversacional.

Y ojo, porque el vibe coding no es solo para aplicaciones web. Puedes aplicar estos mismos principios para crear extensiones de navegador, scripts de Python, automatizaciones, o cualquier proyecto donde la IA sea tu compañera de desarrollo.

¡Gracias por leer Vibe Coding para Dummies! Suscríbete gratis para recibir nuevos posts y apoyar mi trabajo.

Porque una cosa es tener claro el proceso mental y otra muy distinta es saber aplicarlo de forma práctica cuando te sientas frente a Claude, ChatGPT o cualquier IA y no sabes ni por dónde empezar.

El error que me costó caro (y que tú puedes evitar)

Permíteme contarte algo que me costó aprender. Cuando empecé con vibe coding hace casi 3 años, mis proyectos eran sencillos. Un formulario aquí, una calculadora allá. Todo muy directo: “Hazme una app para gestionar gastos”, “Añade una función de categorías”, “Que tenga gráficos”...

Funcionaba perfecto... hasta que no.

A medida que pasaba el tiempo, esos proyectos “sencillos” empezaban a crecer. Una funcionalidad llevaba a otra, y otra, y otra. Lo que empezó como una app limpia se convertía en un Frankenstein que no sabía por dónde coger.

Mi amigo Cristian (desarrollador fullstack con varios años de experiencia) me avisaba una y otra vez: “Pol, necesitas planificar antes de construir. Esto se te va a ir de las manos.”

Y yo, en mi soberbia de vibe coder novato, pensaba: “Nah, esto es diferente. Con IA no necesito planificar tanto.”

Hasta que fue demasiado tarde. Tuve que tirar casi todo el código a la basura y empezar de cero. Dos meses de trabajo directos al contenedor.

Fue entonces cuando Fran Conejos me habló del PRD: ese documento guía donde defines todos los requisitos de tu producto y que te ayuda a no perderte durante el desarrollo. Pero adaptado al mundo del vibe coding: un PRD conversacional.

La diferencia fue brutal.

¿Qué diablos es un PRD?

PRD son las siglas de Product Requirements Document. En el mundo del desarrollo tradicional, es ese documento extenso y aburrido que define qué debe hacer un producto, cómo debe funcionar y qué problema resuelve.

Pero en el mundo del vibe coding, el PRD se convierte en algo mucho más dinámico: un Prompt Requirements Document. Tu guía de navegación que nace de una conversación inteligente con la IA y evoluciona con tu proyecto.

No es un documento de 50 páginas que nadie lee. Es tu hoja de ruta personal que te mantiene enfocado y evita que te pierdas por el camino.

Los cuatro elementos de tu PRD conversacional

Un PRD para vibe coding bien estructurado debe incluir cuatro elementos clave:

1. El Propósito: Tu “por qué”

En lugar de preguntas vagas, ve directo al grano:

• ¿Qué fricción específica eliminas? (No “resuelvo problemas de productividad”, sino “elimino los 15 minutos que pierdo cada mañana decidiendo qué desayunar”)

• ¿Quién es tu usuario exacto? (No “emprendedores”, sino “freelancers de diseño que facturan menos de 3.000€/mes”)

• ¿Qué hace tu usuario AHORA para resolver esto? (Excel, notas en el móvil, memoria...)

• ¿Por qué las soluciones actuales no le funcionan? (Muy complejas, muy caras, no se adaptan a su flujo)

Ejemplo bueno: “Elimino la frustración de freelancers novatos que pierden dinero porque olvidan facturar horas o no saben qué cobrar”

2. La Estructura: Tus funcionalidades y arquitectura

Piensa en flujos, no en botones:

• ¿Cuál es el camino feliz de tu usuario? (Desde que abre la app hasta que consigue su objetivo)

• ¿Qué 3 acciones debe poder hacer SÍ O SÍ? (El resto es secundario)

• ¿Qué datos necesitas guardar y relacionar? (Usuarios, proyectos, facturas... y cómo se conectan)

• ¿Necesitas integraciones externas? (Stripe para pagos, Gmail para emails, etc.)

Si es una aplicación web, ten en cuenta que la mayoría de constructores modernos (Lovable, Bolt, v0) trabajan con React, un framework de JavaScript muy popular.

Importante: Define los flujos y funcionalidades, no la estructura exacta de carpetas. Deja que la herramienta organice los archivos según su criterio, ser demasiado rígido puede confundir a las IA.

3. La Identidad: Tu marca

Ve más allá de “colores bonitos”:

• ¿Qué personalidad tiene tu app? (Profesional, cercana, divertida, minimalista...)

• ¿Cómo quieres que se sienta el usuario al usarla? (Confiado, relajado, empoderado...)

• ¿Qué apps admiras visualmente y por qué? (Sirve de referencia para la IA)

• ¿Colores específicos? (No “azul”, sino “azul océano #0077BE como Linkedin”)

• ¿Tipografía que encaje? (Inter para profesional, Poppins para amigable - mejor de Google Fonts)

Ejemplo bueno: “Personalidad profesional pero accesible, como Notion pero más cálida. Que un freelancer se sienta organizado, no abrumado”

4. Los Límites: Tu alcance

La clave está en saber decir NO:

• ¿Qué versión mínima viable necesitas para validar la idea? (3-4 funcionalidades máximo)

• ¿Qué funcionalidades “bonitas” puedes dejar para v2? (Gráficos avanzados, integraciones complejas...)

• ¿Cuánto tiempo/dinero tienes para la v1? (Esto define si usas servicios gratuitos o premium)

• ¿Qué NO va a hacer tu app nunca? (Para no desviarte por el camino)

Ejemplo bueno: “V1: tracking de horas, creación básica de facturas, lista de clientes. NO: contabilidad completa, múltiples monedas, equipos colaborativos”

Un truco sobre herramientas: En lugar de decidir tú qué herramientas usar, describe las funcionalidades que necesitas y pide a la IA que te recomiende las mejores opciones. Si no conoces alguna herramienta sugerida, puedes abrir una conversación paralela para investigarla sin “ensuciar” tu PRD principal.

El quinto elemento: Tu roadmap de desarrollo

Una vez que tienes tu PRD bien definido, viene la magia: pedir a la IA que divida todo el desarrollo en fases pequeñas y manejables.

Esto es lo que marca la diferencia entre tener un PRD bonito en papel y realmente construir tu proyecto sin morir en el intento.

¿Por qué en fases?

Porque intentar construir toda tu app de una vez es la receta perfecta para:

• Overwhelm total (”no sé ni por dónde empezar”)

• Pérdida de momentum (”llevo 3 semanas y aún no tengo nada que enseñar”)

• Bugs imposibles de debuggear (”algo no funciona pero no sé el qué”)

Cómo pedirlo a la IA

Una vez tengas tu PRD completo, usa esta estructura:

"Perfecto, ahora tengo mi PRD completo. Ayúdame a dividir el desarrollo en fases pequeñas y manejables.

Criterios importantes:
- Cada fase debe generar algo FUNCIONAL que pueda probar
- Máximo 3-4 funcionalidades por fase  
- Cada fase no debería tomar más de 1-2 días de desarrollo
- Las fases deben tener dependencias lógicas (no puedo hacer login sin tener usuarios)

Prioriza por impacto en la experiencia del usuario, no por complejidad técnica."

Ejemplo práctico: App de tracking freelance

Fase 1: MVP básico (Día 1-2)

• Registro/login de usuario simple

• Dashboard básico (solo layout, sin datos)

• Formulario para añadir proyecto nuevo

Fase 2: Core funcional (Día 3-4)

• Tracking de tiempo en proyectos

• Lista de proyectos con tiempo acumulado

• Editar/eliminar proyectos

Fase 3: Valor inmediato (Día 5-6)

• Generar factura básica (PDF simple)

• Configurar tarifa por hora

• Cálculo automático de totales

Fase 4: Polish y usabilidad (Día 7)

• Mejorar design visual

• Añadir validaciones y mensajes de error

• Responsive design

Pro tip: Al final de cada fase, tómate 30 minutos para probar todo lo que tienes. Si algo no funciona como esperabas, mejor arreglarlo antes de añadir más complejidad.

Cómo crear tu PRD conversacional (paso a paso)

El secreto está en tener la conversación correcta. Aquí tienes el proceso que uso:

Paso 1: Iniciar la conversación

Empieza con esta estructura de conversación:

"Quiero crear [tipo de aplicación] para [audiencia específica]. 
El problema que resuelvo es [problema concreto].

Ayúdame a definir completamente este proyecto. Hagámoslo por partes:

1. Primero, ayúdame a refinar el concepto y la propuesta de valor
2. Luego, definamos las funcionalidades principales 
3. Después, la arquitectura técnica básica
4. Y finalmente, la identidad visual y de marca

¿Empezamos con el concepto?"

Paso 2: Iterando

No te conformes con la primera respuesta. Profundiza:

"Perfecto, pero vamos a ser más específicos. 
El usuario típico sería [describe a tu usuario ideal].
Su mayor frustración es [frustración específica].
Mi solución es única porque [tu diferenciador].

¿Cómo ajustarías el concepto con esta información?"

Paso 3: La documentación automática

Una vez tengas todo claro, pide:

"Ahora genera un documento PRD completo que incluya:
- Resumen ejecutivo del proyecto
- Funcionalidades principales con priorización
- Stack técnico recomendado
- Guía de marca básica
- Roadmap de desarrollo por fases

Que sirva como guía para todo el desarrollo posterior."

Por qué tu PRD es tu superpoder

He visto a muchos vibe coders geniales perderse por el camino. Empiezan con energía, añaden funcionalidad tras funcionalidad, pero llega un momento en que el proyecto se convierte en un Frankenstein sin coherencia.

Tu PRD conversacional es tu ancla. Cada vez que vayas a añadir algo nuevo, consultas tu guía: ¿Esto está alineado con mi propósito? ¿Encaja con mi identidad de marca? ¿Es realmente necesario ahora o puede esperar?

Además, cuando trabajas con IA, tener un PRD claro mejora dramáticamente la calidad de las respuestas. En lugar de prompts sueltos y descontextualizados, tienes conversaciones coherentes donde cada interacción construye sobre la anterior.

Tu PRD vive y evoluciona

Aquí viene lo más importante: tu PRD no es un documento rígido. Es un organismo vivo que evoluciona con tu proyecto.

Cada semana, después de trabajar en tu aplicación, tómate 10 minutos para revisar tu PRD:

• ¿Sigue siendo válido el propósito inicial?

• ¿Has descubierto nuevas necesidades de tus usuarios?

• ¿Hay funcionalidades que resultaron menos importantes de lo esperado?

• ¿Tu identidad de marca necesita ajustes?

Esta revisión regular te mantiene alineado y evita que tu proyecto derive hacia direcciones que no te convienen.

Tu acción para esta semana

Antes del próximo envío, te propongo un ejercicio simple pero poderoso:

Piensa en una idea de aplicación que tengas (o invéntate una ahora mismo). Puede ser algo simple: un gestor de gastos personales, una agenda de hábitos, una calculadora especializada...

Abre una conversación con tu IA favorita y aplica el proceso que te he explicado. No se trata de construir la aplicación todavía, sino de crear tu PRD conversacional.

Cuando tengas tu PRD listo, guárdalo bien. La semana que viene lo vas a necesitar 😄

¿Qué tal? ¿Cómo has pasado la semana? Seguro que mucho mejor que yo. Llevo un estrés… Te voy a confesar algo: el post de hoy debía ser el primer post de la newsletter.

¿Por qué no lo fue? Pues porque antes de lanzar el primer capítulo se lo dejé leer a algunos amigos y uno de ellos me comentó que quizá debería hacer un post introductorio (el de la semana pasada), para informar a mis futuros lectores de qué iba el tema, qué podían esperar y qué podía ofrecer.

¡Gracias por leer Vibe Coding para Dummies! Suscríbete gratis para recibir nuevos posts y apoyar mi trabajo.

Entonces pensarás: “Si ya lo tenías escrito, ¿de dónde viene el estrés?“

Bueno, pues resulta que además de gustarme el vibe coding y escribir sobre mi experiencia con él, también soy una persona tremendamente perfeccionista e insegura, así que le he dado mil vueltas al post de hoy.

¿Creo que ya está perfecto? PARA NADA. Pero necesito soltarlo.

¿Qué veremos hoy?

Hoy aún no entraremos en materia. Lo sé, me hago esperar, pero pienso que hay una serie de pasos de preparación antes de lanzarnos a construir soluciones y aplicar herramientas y funcionalidades.

El post de hoy es como cuando el señor miyagi le enseña a Daniel lo de “poner cera, pulir cera“.

Tal como te mencioné la semana pasada, cada newsletter estará basada en tres patas: concepto, práctica y reto.

Concepto: El concepto de hoy son los tres fundamentos que (bajo mi punto de vista) debe practicar un viber¹.

Práctica: Te explicaré mi experiencia con mi primer proyecto como viber, cómo lo desarrollé, mis limitaciones de entonces y cuáles fueron los siguientes pasos. Todo ello aplicando el concepto que te habré explicado antes.

Reto(s): En principio había dicho que te propondría un reto. Bueno, como el concepto se divide en tres fundamentos, te retaré a que pongas en práctica uno de los tres (o que hagas los tres, como veas).

Sin más, ¡vamos al lío!

El concepto

Después de crear varios productos digitales con IA, he destilado tres capacidades que separan un auténtico viber de quien solo copia y pega:

1. Pensar por pasos

Todo en la vida tiene su proceso. Tú ya eres un programador natural. Todo el mundo se despierta por las mañanas y hace una serie de pasos antes de salir a la calle. El principio del “programa” es “despertar” y el último es “salir”, pero entre uno y otro, cada persona ejecuta su propia secuencia. Y todas son válidas, aunque siempre se pueden optimizar.

Algunos se despertarán automáticamente, otros necesitarán un despertador. Unos irán primero al baño, mientras que otros pondrán primero la radio y luego se tomarán un vaso de agua. El resultado final es el mismo, pero cada proceso es único.

Esta capacidad de pensar en pasos lógicos es exactamente la materia prima del vibe coding. No basta con decirle a la IA “quiero crear una app que haga esto”. Para que entienda qué debe hacer exactamente, necesitas poder describir paso a paso cómo lo debe hacer. Aquí es donde muchas personas se quedan atascadas.

Esta es tu superpotencia secreta. Necesitas desarrollar la capacidad de ordenar los pasos lógicos en cualquier tarea cotidiana. ¿Por qué? Porque esto luego te ayudará a desmenuzar los pasos lógicos que debe seguir un usuario cuando interactúa con tu aplicación y cómo esta se debe comportar.

Si ya has trabajado con herramientas de automatización como Zapier o Make, tienes ventaja. Este proceso de desmenuzar funcionalidades y aplicarles pasos ya lo tendrás “en la sangre”. Pero si nunca has hecho automatizaciones, no hay drama.

Puedes empezar practicando con actividades cotidianas. La próxima vez que hagas algo rutinario, como preparar café o planificar una salida, conviértete en tu propio observador. Identifica cada paso individual y el orden en que los realizas.

2. Comprender la arquitectura

Aquí viene la parte que asusta a muchos, pero no debería. Si estás pensando en construir páginas web o aplicaciones, necesitas entender cómo funcionan las tripas del sistema. No estoy hablando de convertirte en un experto, sino de entender el juego.

Piénsalo así: no necesitas saber reparar un coche para ser un buen conductor, pero sí ayuda saber que tiene motor, frenos y volante. Con las aplicaciones web pasa igual.

Necesitas comprender que en una página web intervienen distintos elementos:

• El frontend (lo que ve el usuario)

• El backend (las tripas de la aplicación)

• La base de datos (almacenaje, autenticación y otras movidas)

• Las APIs (servicios externos que pueden interactuar con tu aplicación)

Esta comprensión te da superpoderes. Cuando entiendes cómo interactúa cada parte —por ejemplo, cuando el usuario toca un botón— puedes explicar mucho mejor el funcionamiento que deseas para tu aplicación. Tienes más control sobre ella y sobre su desarrollo, aunque no sepas construir cada pieza desde cero.

3. Mentalidad de exploración y crecimiento

Aquí es donde se separa el trigo de la paja. Una vez que dominas los dos primeros conceptos, llega el momento de la clarificación.

Acude a tu modelo de IA favorito (ChatGPT, Claude, Gemini o el que prefieras) y explícale tu idea usando el pensamiento estructurado por pasos combinado con tu comprensión de la arquitectura web.

En este punto, el modelo te preguntará cómo lo quieres desarrollar y te propondrá distintos enfoques y herramientas.

Para cada opción, si no se lo has especificado concretamente, la IA te propondrá tanto caminos distintos como herramientas a utilizar. Aquí entra tu capacidad de autoaprendizaje y de “buscarte la vida”.

Contrariamente a lo que nos dicta nuestra naturaleza de quererlo todo para ayer, si quieres evolucionar en el vibe coding y no quedarte únicamente en la superficie, necesitas desarrollar la curiosidad técnica. Cuando la IA te ofrezca una alternativa, aunque de primeras la veas muy compleja, dale una oportunidad.

Investiga, mira cómo otros lo han hecho. Normalmente siempre hay vídeos en YouTube o alguien de tu entorno ya ha pasado por lo mismo. Si no encuentras la respuesta, la propia IA puede ayudarte a ir del punto “A” al punto “B”. El truco está en no rendirse al primer obstáculo.

La práctica

Ahora, quiero compartir contigo la historia de mi primera aplicación creada con vibe coding, porque creo que ilustra perfectamente cómo se desarrollan estas capacidades en la práctica.

La primera aplicación que creé se llamaba “yoleo” y era un recomendador de libros. Cada libro recomendado tenía un botón para comprarlo en Amazon, buscando el beneficio a través de las ventas de afiliados.

Vamos a ir por orden:

Lo primero que hice fue imaginar cómo debía ser la plataforma. Pensé “házlo fácil”:

Simplemente quería un input (caja de texto) donde el usuario pudiera escribir el título de un libro que le hubiera gustado. La idea entonces era que la aplicación le devolviera cinco recomendaciones, es decir, cinco libros relacionados con el que había introducido.

Vale, lo tenemos. Pasemos a cómo funcionaban sus tripas:

Realmente, la primera versión era bastante escuálida. Piensa que “yoleo” lo hice hace casi tres años, justo cuando apareció ChatGPT y mis conocimientos eran básicamente HTML y CSS. Pero bueno, ¿cómo funcionaba?

1. El usuario escribe el título de un libro en el input (caja de texto)

2. Le da al botón “buscar recomendaciones”

3. Esto dispara una llamada a la API de OpenAI (ChatGPT para que nos entendamos)

4. El prompt solicita 5 libros relacionados con {libro} (lo que hay entre corchetes es una variable, en este caso, es el título que el usuario ha introducido en el input), el autor/a y una breve descripción.

5. La respuesta la recibimos en formato JSON donde cada elemento tiene:

   • Título

   • Autor

   • Sinopsis

6. Cogemos el título del libro y montamos el botón de compra en una url similar a esta: https://www.amazon.es/s?k={título+del+libro}, añadiendo el código de afiliado al final.

7. Con todo esto listo, se lo mostramos al usuario en pantalla.

8. Fin.

Todo este sistema, aunque sencillo, funcionaba. Pero tenía 2 grandes problemas:

1. Al no tener backend, la API KEY de OpenAI era visible para todo el que quisiera consultarla

2. ChatGPT a veces alucinaba y se inventaba títulos de libros

Entonces me puse a conversar con ChatGPT para investigar cómo podía solucionar esos problemas:

Para el problema con la API KEY, lo que necesitaba era almacenarla de forma segura en un backend, una parte no accesible por el usuario que visitaba la web. Para ello, necesitaba dejar de construir mi sitio con simple HTML y CSS y construirlo con algo que se llamaba framework, como Vue.js o React, de manera que pudiera separar la parte del cliente (el frontend, lo que el usuario ve) y la parte del servidor (la parte trasera que hace llamadas a una base de datos y/o a una API).

Respecto a que ChatGPT se inventara los libros, tenía dos opciones: verificar que los libros propuestos por ChatGPT existieran (opción 1) o que los libros ya estuvieran en mi base de datos y solo recomendar los que ya tuviera almacenados (opción 2). Al principio me decanté por la opción 1 y, por cada libro que me daba ChatGPT, comparaba el título con Google Books para ver si el título existía.

Poco a poco fui investigando cada uno de los puntos. NO TE AGOBIES. No se trata de abrumarse y querer solucionar todos los problemas y aprenderlo todo de golpe, sino de ir paso por paso aprendiendo algo nuevo cada día.

Cuantas más herramientas conozcas, más posibles soluciones tendrás a tus problemas.

Reto(s)

Y finalmente llegamos al último punto, ese en el que te hago trabajar un poco. Como con los deberes de verano, son opcionales, ¡pero muy recomendables!

Dado que hemos tocado tres fundamentos, es justo que plantee tres retos. Elige uno, dos o haz los tres, como tú veas.

Reto 1: “Arquitecto Mental”

Desafío: Durante esta semana, fíjate en algo que hagas de forma cotidiana e intenta traducir las acciones en “pseudocódigo mental”. Esto significa anotar todos los pasos a seguir para realizar la tarea, tanto las acciones que realizas como las bifurcaciones que pueden suceder si no se cumple un requisito.

Por ejemplo:

Lavarse las manos

• SI hace frío → encender el agua caliente

• SI NO → encender el agua fría

• Mojarse las manos

• Aplicar jabón

• Limpiar la suciedad de las manos

• Aclarar el jabón de las manos

• Secarse las manos con la toalla

¡Sé preciso y no te dejes nada! No des nada por supuesto (mi ejemplo podría estar mucho mejor explicado). Cuantas menos cosas dejes en el aire, mucho más concreto será el resultado cuando estés hablando con una máquina.

Si quieres ver otros ejemplos, te recomiendo este vídeo: algoritmos en la vida diaria.

Reto 2: “Detective de Apps”

Desafío: Elegir una app que uses diariamente (Instagram, WhatsApp, Spotify...) y documentarla:

• Qué pasa cuando tocas cada botón

• Qué información se guarda

• Qué llamadas al servidor intuyes que se hacen

• Cómo crees que fluye la información

Al final, crea un “mapa mental” de cómo crees que funciona por dentro. Un poco como el reto 1. Lo puedes escribir, pero seguramente te será más fácil de representar en un diagrama de flujo.

No te compliques, puedes hacerlo con papel y boli. Si luego lo quieres compartir en LinkedIn, puedes usar Miro o Figma.

Reto 3: “Primera Conversación”

Desafío: Toma una idea de app simple que tengas en mente y mantén una conversación con una IA donde:

• Expliques la idea paso a paso

• Preguntes qué opciones técnicas hay

• Investigues al menos UNA opción que te parezca compleja

• Vuelvas a la IA con lo que aprendiste y reformules

¡Y hasta aquí la newsletter de hoy!

Espero que no se te haya hecho pesada, pero si lo ha sido, ¡házmelo saber!

Si te ha gustado, compártelo en tu red y si decides publicar la solución a alguno de los retos planteados, no olvides mencionarme :)

¡Nos vemos la próxima semana!