Antes de nada, discúlpame por no escribir desde principios de mes… Pero hoy si, hoy vamos a hablar de algo que ya adelanté hace unos días en LinkedIn. Hoy vamos a hablar de yoleo.

Hola, soy Pol Marzà, AI Product Builder y cada semana escribo una nueva edición de Con Criterio, la newsletter sobre construir productos digitales con IA, con planificación, método y sin atajos. Si te han reenviado este email, puedes suscribirte aquí:

Suscríbete ahora

yoleo v1

La primera vez que construí yoleo no tenía ni idea de programar.

2023 acababa de empezar. Unos pocos meses antes había llegado a nuestras vidas la versión comercial de ChatGPT y, con ella, la promesa de poder construir cualquier cosa con la ayuda de la IA. O eso pensaba yo 😅

Pero si, lo construí.

Para esa primera versión solo usé HTML, CSS y JS. El funcionamiento era sencillo: tenías un input (una caja de texto) donde escribías el título de un libro que te había gustado. Luego, por detrás, yo lanzaba una petición a la API de OpenAI (ChatGPT) con un prompt tipo:

“Actúa como un librero y dame 5 libros que tengan relación semántica con {libro}”

Pero esta primera versión tenía dos problemas:

1. ChatGPT alucinaba bastante (se inventaba títulos)

2. ¡ALERTA! La clave API estaba expuesta en el código

El primer problema tenía un pase, no era crítico. Pero el segundo… Ese sí que podía ser un problemón 🙃

Lo intenté ocultar, lo intenté enmascarar, pero si sabías lo que buscabas… No era difícil de encontrar.

yoleo v2

Unos meses más tarde de construir esta primera versión, un compañero de trabajo me presentó a un desarrollador llamado Pablo.

Con él, construí la segunda versión de yoleo. Pablo se encargó de toda la parte de backend y base de datos. Yo me encargué del front y de la dirección de producto.

Juntos fuimos tomando decisiones importantes y resolvimos los problemas de la primera versión:

1. Alucinaciones → Comparábamos cada libro devuelto por ChatGPT con la API de Google Books. Si existía lo mostrábamos al usuario y si no, no.

2. API expuesta → Ahora ya en variables de entorno. Lejos de ojos fisgones.

3. Añadimos la opción de que el usuario se pudiera registrar para tener un historial de sus libros buscados.

Con todo esto, en 2024 presentamos el proyecto en LinkedIn y a alguien le pareció interesante qué y cómo lo habíamos construido, así que nos fuimos para Madrid a presentarlo.

yoleo v3

Y aquí llegamos a la versión actual del proyecto 🥳

¿Qué ha cambiado?

1. Para las peticiones de la API ya no uso (solamente) ChatGPT, sino que uso la API de Openrouter y voy cambiando de proveedores. Al principio empecé con Gemini 2.5 Flash, pero ahora estoy usando Deepseek v3.2 que ofrece resultados parecidos a un coste menor.

2. En la v2 de yoleo usábamos MongoDB. Ahora uso Supabase tanto para almacenar los datos (libros, autores, portadas, preferencias de los usuarios…) como para el OAuth con Google.

3. En un principio, esta versión usaba la search_tool (a través de la API), tanto para buscar libros nuevos como para ofrecer las recomendaciones (en cada ficha se ofrecen hasta 8 libros relacionados), pero era MUY caro. Ahora funciona con embeddings de libros que ya se encuentran dentro de yoleo. Es decir, he vectorizado los 50k libros.

Lo que más me gusta de esta nueva versión es:

• Las portadas → Tenía un problema con ellas, ya que la API de Google Books y la de Open Library, la mitad de las veces no me devolvían la portada del libro en su idioma o directamente no me devolvían nada 🤣 Así que dije “hasta aquí” y, lo que tenía que ser un parche se ha convertido en una de sus señas.

  Las portadas son generadas al vuelo y se toma su main_category como referencia para elegir el color de la portada. Además, también se añade el autor/a, el título y año de publicación.

• Afinidad → Esto es algo que no he encontrado en otras páginas y se trata de mostrarte como de posible es que te guste un libro en función de los libros que hayas valorado o leído previamente. Lo mejor de todo es que no usa IA sino que se basa en los libros que has leído o puntuado. Pura lógica. Puedes desbloquear la afinidad cuando hayas valorado/añadido un mínimo de 5 libros a tu biblioteca 🥰

Hay más cosas y muchas más que espero ir añadiendo (poco a poco) a yoleo.

Y muchas otras cosas que ya existen, pero no puedo explicarlas todas. Así que te dejo que seas tu quien las descubras 🤗 Actualmente la plataforma cuenta con:

Una de las cosas que he decidido hacer en este proyecto es intentar ser lo más transparente posible, tanto en cuanto a los datos de la plataforma (número de libros, autores y usuarios) con contadores dinámicos que encontrarás mientras navegas por yoleo, como lo que me cuesta mantener el proyecto en marcha (lo puedes ver al final de la landing).

De cara a las próximas semanas, me gustaría seguir mejorando la plataforma pero eso solo tendrá sentido si te registras, compartes y le das cariño a yoleo.

¿Hay hueco para otra plataforma de libros?

¿Qué echas de menos en la plataforma actual?

Déjamelo en los comentarios 👇

¡Y hasta aquí la newsletter!

Nos vemos próximamente :)

Suscríbete ahora

Esta es una nueva sección dentro de la newsletter donde hablo sobre distintas herramientas que encuentro. Te explico qué es, cómo funciona, cómo integrarla y luego te muestro una demo que he construido y que cuelgo en concriterio.tools

Hoy hablamos de Fabric

Cuando Figma no existía y Flash empezaba a morir, los desarrolladores que querían crear editores gráficos en el navegador, se encontraban con un problema: el canvas de HTML era muy limitado para un trabajo interactivo. Podías dibujar formas, sí, pero no podías seleccionarlas. No podías moverlas y el navegador no recordaba nada de lo que habías pintado.

Fabric.js nació en 2010, creado por Juriy Zaytsev, como solución a esa complejidad. Surgió de la necesidad práctica de tener una forma más accesible de crear aplicaciones gráficas interactivas en el navegador. Su autor estaba construyendo un editor para personalizar ropa online. La interactividad que necesitaba solo existía en Flash. Así que construyó la capa que faltaba.

Qué es exactamente

Fabric.js es como una caja de herramientas que te permite trabajar de manera más intuitiva: en lugar de pensar en píxeles individuales, trabajas con objetos (rectángulos, imágenes, textos) que puedes mover, rotar y modificar fácilmente.

La librería maneja automáticamente las cosas complicadas: detecta cuándo haces clic en una forma, permite arrastrar objetos, rotar figuras con el ratón y gestiona el redibujado de todo el canvas. Tú defines qué hay en el canvas y Fabric se encarga del resto.

Cuándo usarlo vs cuándo no

Usa Fabric cuando el usuario necesita manipular elementos visuales directamente: editores de imágenes, constructores de slides, herramientas de anotación, configuradores de producto. Cualquier aplicación donde los usuarios necesiten interactuar visualmente con elementos en pantalla.

No lo uses para visualizaciones de datos o juegos donde el rendimiento del render importa más que la interactividad de objetos. Para eso hay opciones más ligeras. Fabric es un editor de objetos, no un motor de juego.

Pricing: MIT, libre. Sin tokens, sin tiers. Es una librería npm.

Cómo se integra

bash

npm install fabric

typescript

import { Canvas, FabricImage, FabricText } from 'fabric'

const canvas = new Canvas('canvas-element', { width: 800, height: 600 })

// Cargar imagen
const img = await FabricImage.fromURL('/foto.jpg')
canvas.add(img)

// Añadir texto que el usuario puede mover y escalar
const text = new FabricText('Tu texto aquí', {
  left: 100, top: 100,
  fontSize: 32, fill: '#ffffff',
})
canvas.add(text)

// Exportar como PNG
const dataURL = canvas.toDataURL({ format: 'png' })

Con eso tienes selección, movimiento y escala de objetos funcionando por defecto. .toJSON() serializa el estado completo del canvas para guardarlo. .loadFromJSON() lo restaura. Un detalle: si encuentras ejemplos con fabric.Canvas son de v5 — en v6 el API cambió a imports con nombre.

La demo

He montado un editor de memes en fabric.concriterio.tools para que veas cómo funciona en real. Puedes cargar una imagen, añadir capas de texto con distintas tipografías, moverlas y escalarlas directamente sobre el canvas, y descargar el resultado como PNG.

Todo el código está en el repositorio público de Github, listo para que te lo puedas descargar y modificar a tu gusto.

(Accede a él a través de enlace)

Recapitulemos

Hay una categoría de interfaces que no se resuelven bien con HTML y CSS: las que el usuario edita visualmente, donde los elementos se mueven, se superponen y se transforman. Para eso existe el canvas. Y para trabajar con el canvas sin volverte loco, existe Fabric. Si alguna vez tienes que construir algo donde el usuario “diseña” en lugar de solo “rellenar formularios”, esta librería es el punto de partida.

Si esta entrega de Con Criterio te ha resultado útil, no olvides compartirla :)

Compartir

El SDD Clarifier es una skill para Claude con el que te guía el proceso de clarificación de un proyecto digital antes de escribir código. Tomas una idea —puede ser una frase, un párrafo, una nota de voz transcrita— y al final tienes un conjunto completo de artefactos de especificación: PRD, arquitectura, modelo de datos, design system, roadmap y specs funcionales compatibles con OpenSpec.

El problema que resuelve no es técnico. Es anterior a lo técnico.

Frameworks como OpenSpec, GitHub Copilot Workspace o BMAD asumen que ya sabes qué quieres construir. Entran en la fase de implementación. El SDD Clarifier cubre el tramo previo: las decisiones de negocio, las decisiones de diseño y la fase exploratoria donde todavía hay más preguntas que respuestas.

Descárgate la skill desde aquí:

Descargar SDD Clarifier

Cómo funciona

El proceso tiene tres fases secuenciales.

Fase 1 — Exploración (conversacional). Claude no genera nada todavía. Pregunta. Extrae del usuario las decisiones necesarias agrupadas en cuatro áreas: negocio (modelo de monetización, métricas de éxito, restricciones), diseño (plataforma, estilo visual, tono), técnica (stack, integraciones, despliegue) y alcance (MVP vs. visión completa). Máximo tres preguntas por turno. Al final, presenta un resumen de todas las decisiones para validación explícita.

Fase 2 — Formalización (generación de artefactos). Una vez confirmado el alcance, genera la estructura de carpetas completa con todos los documentos. Los specs funcionales siguen el formato OpenSpec (SHALL/MUST/SHOULD según RFC 2119), organizados por dominio. Los docs adicionales cubren lo que OpenSpec no cubre: business.md, design-system.md, architecture.md, data-model.md y roadmap.md. Se incluye un CLAUDE.md con instrucciones para el agente de codificación.

Fase 3 — Entrega y siguiente paso. Presenta la estructura generada y da el paso concreto a seguir: inicializar OpenSpec y continuar con el flujo estándar de implementación.

Filosofía

La skill implementa un principio simple: 80% planificación, 20% ejecución.

Claude no decide por el usuario. Pregunta, confronta, propone opciones y espera. El usuario mantiene el control y la comprensión total del proyecto en todo momento. Si durante la generación falta alguna decisión, Claude para y pregunta antes de asumir.

La potencia sin control no sirve de nada.

Cómo instalarla

Una skill es un archivo Markdown que Claude carga como contexto de sistema. No es un plugin ni una extensión del navegador. No requiere instalación en el sentido tradicional.

En Claude.ai (web y móvil). Ve a Configuración → Skills → Añadir skill. Carga el archivo sdd-clarifier-skill.md. A partir de ese momento, Claude lo usará automáticamente cuando detecte que estás describiendo un proyecto.

En Claude Code (terminal). Copia el archivo en ~/.claude/skills/sdd-clarifier/SKILL.md. Claude Code lo cargará en cada sesión.

En Claude Desktop. El proceso es equivalente al de Claude Code: el archivo va en la carpeta de skills de tu configuración local.

¿Funciona con la API de Anthropic? No directamente. Las skills son un mecanismo de Claude Code y Claude Desktop. Si usas la API, puedes incluir el contenido del archivo como system prompt manualmente, pero el sistema de skills no se aplica en llamadas directas a la API.

Compatibilidad con OpenSpec

Los artefactos que genera esta skill son directamente compatibles con OpenSpec CLI. Una vez que tienes la carpeta generada:

1. Instala OpenSpec: npm install -g @fission-ai/openspec@latest

2. Ejecuta openspec init en el directorio del proyecto

3. Los specs generados por el SDD Clarifier se integran como fuente de verdad

4. Para nuevas funcionalidades, usa el flujo estándar: /opsx:propose, /opsx:apply, /opsx:archive

¿Te ha resultado útil este recurso?

Todos los recursos y materiales de Con Criterio son gratuitos, pero si me quieres apoyar para que siga construyendo y compartiendo de esta manera, puedes invitarme a un café :)

Invítame a un café

Para construir dicha web usé un combo ganador como es Astro, Sanity y Vercel, pero mientras lo construía me encontré una serie de problemas que no esperaba.

Los he documentado para que, si también quieres montar algo con este tándem y luego lo despliegas en Vercel, puedas tener una ayuda para no entrar en los bucles con los que me encontré yo :)

1. Arquitectura general

Sanity Studio (CMS) → Sanity API → Astro (SSG) → Vercel (hosting)
       ↓                                              ↑
   Webhook ──────────────────────────────────────── Deploy Hook

• Sanity es donde se guarda y gestiona todo el contenido: textos, imágenes, documentos.

• Astro genera las páginas HTML del sitio web en el momento de la construcción (build), pidiendo los datos a Sanity.

• Vercel aloja el sitio y lo reconstruye automáticamente cada vez que Sanity le avisa de que algo ha cambiado.

Por qué generar páginas estáticas (SSG) y no renderizar en servidor (SSR)

Para webs donde el contenido no cambia constantemente (corporativas, portfolios, blogs, sitios de proyecto), generar páginas estáticas es la mejor opción:

SSG (PÁGINAS PRE-GENERADAS)SSR (GENERADAS EN CADA VISITA)VelocidadInstantáneo, el HTML ya está listoCada visita hace una consulta a la APICosteGratis o casi gratisCada visita consume recursos de servidorResilienciaSi Sanity se cae, la web sigue funcionandoSi Sanity se cae, la web deja de funcionarContenido actualizadoTarda ~30-40 segundos en reconstruirseInmediato

Regla general: si el contenido cambia pocas veces al día, las páginas estáticas son suficientes. Solo necesitas renderizado en servidor si tu contenido cambia constantemente (tiendas online, dashboards, feeds en tiempo real).

2. Configuración del cliente Sanity

import { createClient } from '@sanity/client';

export const sanityClient = createClient({
  projectId: 'tu-project-id',
  dataset: 'production',
  apiVersion: '2024-01-01',
  useCdn: false, // ← CRÍTICO
});

La trampa de la caché (useCdn)

Este es probablemente el error más difícil de detectar en toda la integración.

El problema: con useCdn: true, Sanity devuelve datos desde su caché en lugar de ir a buscar los más recientes. Cuando un editor publica contenido y se dispara la reconstrucción del sitio, el build pide datos a Sanity, pero la caché todavía tiene la versión anterior. El resultado: el sitio se reconstruye con datos desactualizados.

Cómo se manifiesta:

• Los cambios hechos en Sanity no aparecen en la web después de reconstruir

• Los tiempos de construcción de las páginas son sospechosamente rápidos (~15ms en vez de ~3s)

• No hay ningún error en los registros del sistema: simplemente los datos son viejos

Solución: usar useCdn: false para los builds. En sitios estáticos no hay penalización real, porque las consultas solo se ejecutan una vez durante la construcción, no en cada visita del usuario.

Regla: useCdn: true es para aplicaciones que renderizan en servidor con mucho tráfico, donde la velocidad de respuesta importa mucho. Para sitios estáticos, siempre useCdn: false.

3. Esquemas de contenido

Singletons vs. Colecciones

• Singletons: documentos que solo existen una vez (la sección hero de la home, la página “sobre nosotros”, el formulario de contacto, la configuración general). Se crean una vez y después solo se editan.

• Colecciones: documentos que se repiten (miembros del equipo, entidades, publicaciones del blog).

// Singleton: se le asigna un _id fijo para que no se pueda duplicar
defineType({
  name: 'heroSection',
  type: 'document',
  // ...
})

// En sanity.config.ts: se impide que los editores creen o borren singletons
document: {
  actions: (input, context) =>
    singletonTypes.has(context.schemaType)
      ? input.filter(({ action }) =>
          action && ['publish', 'discardChanges', 'restore'].includes(action))
      : input,
}

Internacionalización a nivel de campo

En vez de crear un documento separado por cada idioma, se crean campos que contienen ambos idiomas dentro del mismo documento:

// localeString: un campo corto con versión en cada idioma
defineType({
  name: 'localeString',
  type: 'object',
  fields: [
    { name: 'es', type: 'string', title: 'Español' },
    { name: 'en', type: 'string', title: 'English' },
  ],
})

Hay tres variantes según el tipo de texto:

• localeString para textos cortos (títulos, etiquetas)

• localeText para textos largos (párrafos, descripciones)

• localeBlockContent para texto enriquecido (con negritas, cursivas, enlaces)

Ventaja: el editor ve los dos idiomas en el mismo formulario, sin tener que cambiar de documento. Esto reduce errores y hace mucho más fácil mantener ambos idiomas sincronizados.

4. Patrón de respaldo (fallback)

Nunca dependas al 100% de una fuente de datos externa. Si Sanity no está disponible o el contenido todavía no se ha cargado, la web tiene que seguir mostrando algo.

// En el componente Astro
let hero, about, settings;
try {
  const data = await getHomePageData();
  hero = data.hero;
  about = data.about;
  settings = data.settings;
} catch {
  // Sanity no está disponible, usamos los textos de respaldo
}

// Función auxiliar que decide de dónde sacar el texto
function s(
  sanityValue: { es?: string; en?: string } | null,
  fallbackKey: string,
  lang: string
): string {
  if (sanityValue) {
    return sanityValue[lang] ?? sanityValue.es ?? t(fallbackKey, lang);
  }
  return t(fallbackKey, lang);  // textos de respaldo estáticos
}

Regla: mantén un archivo de textos estáticos (translations.ts) como red de seguridad. Sanity es la fuente principal de datos; los textos estáticos son el plan B.

5. Consultas GROQ

Pide solo lo que necesitas

Siempre especifica qué campos quieres en lugar de traerte el documento entero:

// ❌ Malo: trae todo, incluidos campos internos de Sanity que no usas
*[_type == "teamMember"]

// ✅ Bueno: solo los campos que vas a usar
*[_type == "teamMember"] | order(order asc){
  _id,
  name,
  role,
  institution,
  "photoUrl": photo.asset->url,
  initials,
  order
}

Resuelve las referencias de imágenes en la propia consulta

Sanity guarda las imágenes como referencias internas. Puedes convertirlas en URLs directamente dentro de la consulta:

"logoUrl": logo.asset->url
"photoUrl": photo.asset->url

Carga en paralelo

Usa Promise.all para pedir todos los datos a la vez, en lugar de uno detrás de otro:

const [hero, about, team, entities] = await Promise.all([
  getHeroSection(),
  getAboutSection(),
  getTeamMembers(),
  getEntities(),
]);

6. Reconstrucción automática: Vercel + Sanity Webhooks

Configuración

1. En Vercel: crear un Deploy Hook en Settings → Git → Deploy Hooks. Esto genera una URL del tipo https://api.vercel.com/v1/integrations/deploy/...

2. En Sanity: crear un Webhook en manage.sanity.io → API → Webhooks

   • URL: la del Deploy Hook que acabas de crear en Vercel

   • Disparadores: Crear, Actualizar, Eliminar

   • Filtro: vacío (cualquier cambio dispara la reconstrucción)

Flujo completo

El editor publica algo en Sanity
  → Sanity envía una notificación (webhook) a Vercel
    → Vercel descarga el código y ejecuta la construcción del sitio
      → Astro pide los datos a Sanity (con useCdn: false)
        → Se genera el HTML con los datos actualizados
          → El sitio está online (~30-40 segundos en total)

Problemas habituales

1. La caché te da datos viejos (ya explicado arriba): usar useCdn: false.

2. Condición de carrera en el webhook: el webhook se dispara inmediatamente al publicar. Si Sanity tarda unos milisegundos en propagar los datos internamente, la construcción puede capturar datos a medio actualizar. En la práctica es raro, pero si ocurre, una segunda reconstrucción lo soluciona.

3. Actualizar el panel de edición no es lo mismo que actualizar la web:

   • npm run sanity:deploy actualiza el Sanity Studio (la herramienta de edición). Solo hace falta cuando cambias la estructura de los datos (esquemas).

   • El webhook de Vercel reconstruye la web pública. Se dispara cuando cambia el contenido.

7. Sanity Studio: buenas prácticas

Organizar el panel de navegación

Agrupa los documentos en el menú lateral para que los editores encuentren todo fácil:

structureTool({
  structure: (S) =>
    S.list().title('Contenido').items([
      S.listItem().title('Inicio').child(
        S.list().title('Secciones de inicio').items([
          S.listItem().title('Hero').child(/* singleton */),
          S.listItem().title('Sobre el proyecto').child(/* singleton */),
          S.listItem().title('Contacto').child(/* singleton */),
        ])
      ),
      S.divider(),
      S.listItem().title('Equipo').child(/* lista filtrada */),
      S.listItem().title('Entidades').child(/* lista filtrada */),
      // ...
    ]),
})

Proteger los singletons

Impide que los editores puedan crear duplicados o borrar documentos que deberían ser únicos:

document: {
  actions: (input, context) =>
    singletonTypes.has(context.schemaType)
      ? input.filter(({ action }) =>
          action && ['publish', 'discardChanges', 'restore'].includes(action))
      : input,
}

Acceso y permisos

• Para iniciar sesión en local: npx sanity login (no sanity login directamente, puede que no esté en el PATH)

• Los colaboradores acceden al Studio desde el navegador, a través de la URL donde lo hayas desplegado

• Los permisos de cada usuario se gestionan en manage.sanity.io → Members

8. Imágenes

Proporciones y recorte

Define las proporciones en CSS y deja que el navegador se encargue del recorte:

.team-photo {
  aspect-ratio: 3/4;    /* Proporción vertical tipo retrato */
  object-fit: cover;     /* Recorta sin deformar la imagen */
  width: 100%;
}

Indicación para editores: subir fotos de al menos 600×800px para retratos. Si son más grandes no pasa nada, el CSS se encarga de ajustarlas.

Transformación de imágenes con URL builder

Sanity permite redimensionar y recortar imágenes automáticamente a través de URLs:

import { createImageUrlBuilder } from '@sanity/image-url';

const builder = createImageUrlBuilder(sanityClient);

export function urlFor(source) {
  return builder.image(source);
}

// Ejemplo: urlFor(photo).width(400).height(533).url()

Nota: usa createImageUrlBuilder (importación con nombre), no la importación por defecto que está marcada como obsoleta.

9. Carga masiva de contenido

Para no tener que introducir todo el contenido inicial a mano en el Studio, crea un script de carga:

import { createClient } from '@sanity/client';

const client = createClient({
  projectId: 'tu-project-id',
  dataset: 'production',
  token: process.env.SANITY_TOKEN, // token con permisos de escritura
  apiVersion: '2024-01-01',
  useCdn: false,
});

// createOrReplace: se puede ejecutar muchas veces sin crear duplicados
await client.createOrReplace({
  _id: 'heroSection',
  _type: 'heroSection',
  tag: { es: 'Proyecto de investigación', en: 'Research project' },
  // ...
});

Importante: usa createOrReplace en vez de create. Así el script se puede ejecutar varias veces sin duplicar contenido (es idempotente).

Seguridad: nunca subas tokens de API al repositorio. Guárdalos como variables de entorno y revócalos cuando ya no los necesites.

10. Checklist de integración

• useCdn: false en el cliente Sanity para builds estáticos

• Textos de respaldo si Sanity no responde

• Deploy Hook de Vercel configurado

• Webhook de Sanity apuntando al Deploy Hook

• Singletons protegidos para que no se puedan duplicar ni borrar

• Campos bilingües (ES/EN) en todos los textos

• Consultas GROQ pidiendo solo los campos necesarios

• Carga de datos en paralelo con Promise.all

• Script de carga inicial para el contenido

• README con instrucciones de setup, comandos y flujo de despliegue

• Studio desplegado para que los colaboradores puedan acceder (npm run sanity:deploy)

• Proporciones de imagen definidas en CSS con aspect-ratio + object-fit: cover

Resumen

La combinación Astro + Sanity + Vercel funciona muy bien para sitios donde el contenido lo gestiona un equipo no técnico:

1. Sanity da a los editores una interfaz cómoda para gestionar contenido.

2. Astro genera HTML rápido y barato.

3. Vercel despliega automáticamente con webhooks.

Los puntos críticos son:

• useCdn: false para que los builds siempre obtengan datos actualizados.

• Textos de respaldo para que la web nunca se quede en blanco.

• Entender que actualizar el Studio y actualizar la web son procesos distintos con disparadores distintos.

Con estas prácticas, el flujo es: el editor cambia contenido en Sanity → la web se actualiza sola en ~30 segundos → sin intervención técnica.

Suscríbete ahora

Hace unos días terminé dos proyectos en sesiones de pocas horas cada uno. Sin arquitecturas de agentes. Sin orquestadores automáticos. Sin sistemas de coordinación.

Lo que sí hubo: yo tomando decisiones constantemente.

• Qué construir primero.

• Qué ignorar.

• Cuándo el resultado era suficientemente bueno para avanzar.

• Cuándo reescribir algo desde cero.

• Cuándo parar.

Eso se llama orquestar. Y la IA solo era el agente que ejecutaba mis instrucciones.

El problema es que nadie te lo cuenta así. Las conversaciones sobre agentes suelen arrancar desde la complejidad técnica y parece que si no tienes un sistema sofisticado, es como si lo estuvieras haciendo mal.

Pero no es verdad.

¿Qué significa orquestar en la práctica?

Un orquestador decide qué se hace, en qué orden, con qué criterio y cuándo el resultado es aceptable.

Cuando abres una conversación con Claude Code, le das contexto, le defines el alcance, interpretas lo que genera, decides si sigue o si cambia de dirección, ya estás orquestando. No lo parece porque no hay un dashboard con nodos conectados, pero el proceso es exactamente el mismo.

Tu ventaja como orquestador humano es el juicio: saber cuándo algo que “funciona” no es lo que realmente se necesitaba. Eso no se delega fácilmente.

Los tres escenarios donde los agentes autónomos ganan

Hay situaciones concretas donde tiene sentido sacar al humano del bucle:

1. Volumen repetitivo con inputs distintos. Imagina que tienes que analizar 5.000 contratos PDF para extraer cláusulas específicas. El proceso es idéntico en todos los casos, solo cambia el documento. Un agente hace eso en serie; diez agentes lo hacen en paralelo. Aquí no hay juicio que aplicar, hay escala que conseguir.

2. Pipelines con pasos verificables. Cuando el flujo es predecible (extraer datos, limpiar, analizar, publicar) y cada paso tiene un output que se puede validar antes de pasar al siguiente, un orquestador automático gestiona los reintentos y las dependencias mejor que un humano mirando la pantalla.

3. Dominios muy separados que necesitan especialización. Un agente con un contexto muy acotado comete menos errores en su dominio que un agente generalista al que le has mezclado demasiadas cosas. Si tu proyecto tiene capas radicalmente distintas (base de datos, lógica de negocio, interfaz, comunicaciones), separar los agentes por dominio reduce el ruido y mejora la calidad del output.

El patrón común en los tres casos es que el trabajo es volumétrico y repetible. El proceso ya está decidido, solo falta ejecutarlo a escala.

Si te está gustando lo que estás leyendo, ¡ayúdame a que llegue a más personas!

Compartir

El criterio para saber cuándo escalar

La pregunta no es “¿debería tener agentes?” sino “¿qué parte de mi trabajo es un procedimiento operativo estándar y qué parte requiere criterio?”

Opción A

Si puedes describir el trabajo como un proceso con inputs predecibles y outputs verificables, los agentes automáticos escalan bien.

Opción B

Si el trabajo consiste en decidir qué construir, cómo, para quién y por qué, el orquestador humano es el activo, no el cuello de botella.

Tengo un colega que es project manager que el otro día me contaba que tiene agentes porque su equipo procesa volumen:

• Revisiones de código repetitivas sobre patrones conocidos.

• Generación de documentación desde estructuras existentes.

• Análisis de tickets con categorías predefinidas.

Tiene sentido para él porque el proceso ya está resuelto y lo que necesita es escala.

Yo construí Kumio y Nexy tomando decisiones de diseño de producto en tiempo real que ningún sistema automático podría haber tomado por mí. Ahí el orquestador humano no era el problema, era la solución.

La sofisticación técnica no es un objetivo; es una herramienta para un problema específico. Antes de añadir complejidad, vale la pena preguntarse si el problema que tienes es de volumen o de criterio.

Casi siempre, cuando estás construyendo algo nuevo, es de criterio.

¡Y hasta aquí el post! Nos vemos la semana que viene :)

— Pol

PD: Quizá has visto palabras subrayadas y resaltadas con el color de acento de la newsletter. Realmente son enlaces para definir el concepto con más precisión y esta definición la puedes leer en nexy.ai. Puedes consultar estos conceptos y muchos más si te registras (con Google y la plataforma es gratuita).

Suscríbete ahora

Esta tarde doy un webinar sobre SDD para TecnoFor. Mientras estructuraba la charla, me di cuenta de que había una distinción que nadie estaba haciendo explícita. La escribo aquí antes de que se pierda 😅

¿Qué veremos hoy?

Por qué SDD no es un concepto único, qué diferencia hay entre la versión orientada a agentes y la versión orientada al desarrollador humano, y por qué esa distinción importa antes de que nadie empiece a construir nada. Quédate hasta el final, porque al cierre comparto una skill descargable para aplicar todo esto desde hoy.

Dos lecturas del mismo término

Spec-Driven Development aparece cada vez más en conversaciones sobre desarrollo con IA. El problema es que hay dos versiones del concepto circulando a la vez, y casi nadie las distingue.

La primera es SDD orientado a agentes. Es lo que ves en OpenSpec, en Cursor Rules, en los workflows de Claude Code. Los documentos de especificación son instrucciones operativas para que múltiples agentes trabajen en paralelo sin perder contexto entre ellos. El foco es la coordinación técnica: cómo hacer que varios sistemas autónomos construyan hacia el mismo objetivo sin colisionar.

La segunda es SDD orientado al desarrollador humano. Es lo que llevo practicando desde que empecé a construir productos con IA. Los documentos de spec no son instrucciones para agentes, son artefactos de clarificación que externalizan el pensamiento antes de escribir una sola línea de código. El 80% del trabajo ocurre antes del primer prompt de ejecución. El LLM no actúa como agente autónomo, sino como colaborador informado.

Son enfoques distintos en su premisa, no versiones del mismo proceso en distinto nivel de sofisticación.

Por qué la distinción importa

El SDD agéntico asume que el desarrollador ya sabe qué construir y necesita coordinar la ejecución entre sistemas. El problema de coordinación ya está resuelto en la cabeza del humano, y los documentos de spec son el mecanismo para trasladarlo a los agentes.

Mi versión asume que la calidad del output del LLM es proporcional a la calidad del contexto que le das, y que ese contexto se construye iterativamente con el propio LLM antes de ejecutar. El problema que resuelve es anterior: no la coordinación, sino la claridad. Qué construir exactamente, por qué así, qué significa cada requisito cuando lo traduces a comportamiento real.

No son enfoques que compiten. Son prerequisito y consecuencia. Un sistema multiagente que parte de specs mal definidas produce código perfectamente coordinado hacia el objetivo equivocado.

OpenSpec no incluye una fase de clarificación porque no la necesita: asume que llegas al proceso ya sabiendo qué construir. Cubre la coordinación técnica, no el pensamiento previo.

Ese hueco es exactamente lo que he intentado sistematizar.

La skill SDD-clarifier

Hace unas semanas publiqué en concriterio.dev una skill llamada SDD-clarifier. Es un protocolo de clarificación conversacional que puedes usar con cualquier LLM antes de empezar a construir.

El proceso tiene tres fases:

1. Exploración (conversación para extraer todas las decisiones necesarias).

2. Formalización (generación de artefactos: PRD, arquitectura, diseño, modelo de datos).

3. Entrega (los archivos listos para que un agente de codificación los use como contexto).

Lo que la diferencia de otras herramientas del ecosistema es que no empieza por el código ni por la estructura técnica. Empieza por las preguntas que un buen product manager haría antes de que nadie escribiera nada: qué problema resuelve esto, para quién, qué significa que funcione, qué queda fuera del alcance.

La skill está disponible en concriterio.dev. Es un archivo Markdown que puedes descargar y usar directamente en Claude, en Cursor o en cualquier entorno que soporte instrucciones de sistema.

La semana que viene publicaré el post sobre orquestación humana vs. agéntica, que es el otro lado de esta misma conversación. Si entiendes cuándo tú eres el orquestador y cuándo tiene sentido delegar la coordinación a agentes automáticos, SDD como prerequisito cobra todo el sentido.

Son dos posts que se leen mejor juntos. Este explica qué construir y cómo definirlo. El siguiente explica quién lo ejecuta y bajo qué criterio.

Y recuerda, si te ha gustado este artículo, ¡no olvides compartirlo!

Compartir

Hasta la semana que viene :)

— Pol

Suscríbete ahora

El próximo miércoles 25 de marzo, a las 19:00 (hora española), daré una charla en directo en TecnoFor sobre esto que llevo tiempo dándole vueltas: qué pasa cuando el vibe coding deja de ser suficiente. Es gratuita y abierta. Si te interesa, aquí tienes el enlace para apuntarte:

Apúntate aquí

Esta newsletter es una introducción a lo que contaré allí. Si el tema te interesa, el miércoles lo desarrollo en profundidad.

El problema que nadie quiere ver

El vibecoding funciona. Escribes un prompt, la IA genera código, iteras, y en un rato tienes algo que se parece a lo que querías. Para prototipos rápidos, pruebas de concepto o proyectos pequeños, es un método válido.

El problema aparece cuando quieres ir más allá. Cuando el proyecto crece, cuando necesitas que varias partes encajen, cuando hay autenticación, base de datos, roles de usuario, lógica de negocio real. En ese punto, el vibe coding se convierte en una conversación caótica con un modelo que no tiene contexto suficiente para tomar buenas decisiones.

No porque la IA sea mala. Sino porque tú no le has dado un mapa de lo que estás construyendo.

Spec-Driven Development: primero el qué, después el cómo

El Spec-Driven Development (SDD) parte de una idea sencilla: antes de escribir una sola línea de código, defines con precisión qué vas a construir. Requisitos, flujos, decisiones técnicas, restricciones, casos límite. Todo queda documentado en una especificación que sirve como fuente de verdad tanto para la IA como para ti.

No es un concepto nuevo. Los ingenieros de software llevan décadas escribiendo especificaciones. Lo que cambia ahora es que esa especificación no es solo documentación para humanos, es el input que determina la calidad del código que genera la IA.

La diferencia práctica es directa: en lugar de ir ajustando sobre la marcha (“no, esto no era así, cámbialo”), empiezas con un documento que describe exactamente lo que necesitas. La IA trabaja con un contexto completo y produce resultados más coherentes desde el primer intento.

Los 5 documentos que sostienen un proyecto SDD

En la práctica, una especificación no es un solo archivo enorme. Son documentos separados, cada uno con una función clara:

1. Propósito. Qué resuelve el producto, para quién lo resuelve y (igual de importante) qué no resolverá nunca. Este documento te obliga a tomar decisiones de alcance antes de escribir código.

2. Usuarios y flujos. El camino concreto de cada tipo de usuario dentro del producto. No hablamos de personas abstractas, sino de secuencias reales: “el usuario llega, hace esto, ve aquello, el sistema responde así”.

3. Arquitectura básica. Stack tecnológico, tablas de base de datos y sus relaciones. No hace falta un diagrama de 50 páginas. Con que quede claro qué tecnologías usas y cómo se conectan los datos, es suficiente.

4. CLAUDE.md (o AGENTS.md). Este es el archivo que mantiene el contexto vivo entre sesiones. Cuando cierras una conversación con la IA y abres otra, este documento le dice dónde estabas y qué decisiones ya se tomaron. Sin él, cada sesión empieza de cero.

5. Changelog. Un registro de cada decisión que modifica la especificación. No es un log de commits, es un historial de “por qué” cambiaron las cosas, no solo “qué” cambió.

Compartir

No son cosas opuestas

El SDD no sustituye al vibe coding. Son etapas de madurez distintas.

Si estás explorando una idea, validando si algo tiene sentido o construyendo un prototipo rápido para enseñar a alguien, el vibe coding es perfecto. Es rápido, es flexible y el coste de equivocarte es bajo.

Pero cuando decides que ese proyecto va en serio (que necesita escalabilidad, mantenibilidad, que otras personas van a usarlo), necesitas pasar a un modo de trabajo más estructurado. Ahí es donde entra el SDD.

En mi caso, llevo casi tres años trabajando así sin que existiera el término. Lo que yo llamo “clarificación” (esa fase larga de conversación y planificación antes de tocar código) es esencialmente SDD en versión artesanal. La industria ha formalizado lo que muchos product makers ya hacíamos por necesidad.

El miércoles, en directo

Esto ha sido un primer vistazo. El miércoles 25 a las 19:00 en TecnoForo hablaré en detalle sobre cómo aplicar SDD en la práctica: qué documentos generar, cómo estructurar la especificación y cómo conectar todo esto con las herramientas que ya usas.

Si quieres profundizar, apúntate aquí (es gratuito):

Apúntate aquí

— Pol

Suscríbete ahora

Por qué esta nueva newsletter?

Llevo más de tres años construyendo productos digitales con inteligencia artificial. Antes de que existiera un nombre para lo que hacía, ya lo hacía. Antes de que “vibe coding” fuera tendencia, yo ya estaba sentado delante de Claude planificando bases de datos, definiendo arquitecturas y pensando en quién iba a usar lo que estaba a punto de construir.

Hoy quiero contarte por qué he cambiado el nombre de esta newsletter, qué significa “Con Criterio” y por qué creo que es el único término que va a sobrevivir a todo lo que viene.

El origen: construir con IA antes de que tuviera nombre

Cuando empecé a crear productos con IA, no había una etiqueta para eso. Simplemente decía que hacía “programación asistida por IA” o “AI coding”, y la gente me miraba raro. No era programador de formación (vengo del diseño UX y la fotografía) pero descubrí que podía construir cosas reales si dedicaba suficiente tiempo a pensar antes de ejecutar.

Eso era lo que hacía: pensar mucho, construir después.

Llega el vibe coding (y me subo al tren)

A principios de 2025, el término “vibe coding” explotó. Y cuando lo leí, pensé: esto es lo que llevo haciendo todo este tiempo. Así que en junio de ese año lancé Vibe Coding Hacks, una newsletter donde compartía los trucos, la experiencia y las lecciones que había acumulado durante años construyendo con IA.

Le puse ese nombre porque, en ese momento, era el único paraguas que existía para definir lo que hacía.

El problema: vibe coding empieza a significar otra cosa

Con el paso de los meses, vi cómo “vibe coding” se iba asociando con algo que no me representaba. Se convirtió en sinónimo de construir sin pensar. Sin arquitectura, sin seguridad, sin criterio. Si funcionaba, valía. Si se rompía, se le pedía a la IA que lo arreglara. Y si no lo arreglaba, se empezaba de cero.

Eso chocaba frontalmente con mi forma de trabajar. Yo dedicaba el 80% del tiempo a planificar y el 20% a ejecutar. Definía PRDs, diseñaba schemas de base de datos, pensaba en la escalabilidad antes de escribir la primera línea. Pero cada vez que explicaba esto, tenía que añadir un matiz: “hago vibe coding, pero con criterio“.

Ese “pero” me empezó a pesar.

Aparece el SDD y la historia se repite

A principios de 2026, descubrí el concepto de Spec-Driven Development (SDD): un enfoque donde todo parte de una especificación detallada antes de tocar código. Cuando lo leí, pensé lo mismo que con el vibe coding: esto se parece mucho a lo que ya hago.

Pero esta vez no me lancé a adoptar el término. Porque me di cuenta de algo importante.

Lo que he aprendido: los nombres cambian, el criterio no

Vibe coding fue útil hasta que dejó de representarme. SDD se acerca más a mi método, pero tiene sus propias limitaciones cuando los proyectos escalan. Y seguramente, dentro de un año, aparecerá otro término nuevo que defina otra forma de construir con IA.

Lo que me di cuenta es que vibe coding y SDD no son incompatibles. Son complementarios, y cada uno tiene su momento:

• Vibe coding tiene sentido cuando quieres validar una idea rápido, cuando estás explorando si algo merece existir.

• SDD tiene sentido cuando el proyecto necesita escalar, cuando necesitas que la IA tenga un esquema claro de cómo está construido todo para que pueda ayudarte de verdad.

La clave no está en elegir un bando. Está en saber cuándo usar cada herramienta. Cuándo tirar de Lovable para un prototipo interno y cuándo montar un proyecto en Next.js porque necesitas SEO. Cuándo Astro es la respuesta y cuándo no lo es. Cuándo planificar durante días y cuándo lanzar en una tarde.

Eso es criterio.

Bienvenido a Con Criterio

He repasado todo lo que he compartido en estos meses y lo que se ha mantenido constante no es la herramienta ni la metodología. Es la forma de pensar. El criterio para decidir qué construir, cómo construirlo y con qué hacerlo.

Por eso, a partir de hoy, esta newsletter se llama Con Criterio.

No es un rebrand cosmético. Es una corrección de rumbo. El contenido sigue siendo el mismo: builds reales, metodología, herramientas, lecciones aprendidas construyendo productos con IA. Lo que cambia es que ya no estoy atado a un término que no controlo y que puede significar cualquier cosa mañana.

Con Criterio es lo que siempre debería haberse llamado. Solo que necesité un año para darme cuenta.

Nos vemos la semana que viene.

Pol Marzà

PD: Si te ha gustado este post y crees que puede gustar a otras personas me ayudaría mucho si lo compartes 😊

Compartir

¡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!