Y es normal, ya que la mayoría de creadores de contenido, cuando hablan de vibe coding hablan de hacer páginas web.

Pero ya tu sabes que yo no soy la mayoría.

Hoy vamos a hablar de cómo, cuándo y por qué construir una app en mobile. ¿Por qué piensas que me decidí por este formato? Vamos a verlo 😜

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

Antes de entrar al tema quiero explicarte qué he desarrollado exactamente: se trata de un juego de rol y exploración urbana. El mapa del mundo (si, porque puedes jugarlo desde cualquier rincón del planeta) aparece cubierto de niebla y se revela a medida que caminas por la ciudad, en la vida real.

Pero no se queda en el mapa. El mundo esta poblado de lugares con narrativa propia: tabernas, academias, bosques, torres… En cada lugar puedes interactuar con un DM (un director de juego, en este caso una IA) que te narra una historia y responde a tus decisiones.

A partir de ahí puedes construir equipamiento (espadas, escudos, cascos…) para enfrentarte a maleantes que aparecen en tu camino mientras exploras el reino.

La decisión que definió el proyecto desde el inicio fue la necesidad de tener el GPS activo aunque el móvil esté bloqueado en el bolsillo. Eso es lo que hace que puedas ir caminando tranquilamente sin tener el móvil en la mano y que este vibre cuando te cruzas con un malhechor.

Otra característica técnica que me hizo decidirme por una aplicación nativa fue la necesidad de persistencia (de datos) garantizada. En el caso de una PWA (Progressive Web App), el sistema operativo Android o (sobretodo) iOS pueden borrar datos de las aplicaciones si consumen mucho o hace tiempo que no se usan.

Ahora sí, al lío.

Como todo desarrollo, este consistió en tres fases:

Clarificación → Construcción → Distribución

Clarificación

En esta primera fase no hay diferencia respecto a clarificar el desarrollo de un sitio web; el PRD es el mismo ejercicio, es decir, definir para quién es la aplicación, qué hace y qué decide no hacer.

La arquitectura, el modelo de datos, el flujo de usuario, la monetización… Aunque sean plataformas distintas, todas tienen el mismo esqueleto.

Recuerda que en la clarificación también piensas en el stack, y aquí es donde viene el gran cambio, ya que al ser una app nativa no puedes desarrollar con React, Astro o Vue si no que tienes que hacerlo con Flutter o Swift (entre otras).

PRO TIP: Es muy importante que antes de decidir en que builder quieres construir (Lovable, Bolt, Cursor…) definas qué stack necesitas, ya que eso te va a condicionar todo lo demás.

Construcción

En mi caso me decidí por Flutter ya que te permite escribir el código una vez y compilarlo para iOS y Android.

Con Claude Code como agente, la construcción sigue la misma lógica que cualquier otro proyecto vibe codeado:

1. Te apoyas en un agente para redactar las specs (clarificación)

2. Adjuntas dichas specs al proyecto (Local o en la nube)

3. Empieza de dentro hacia fuera (datos → backend → frontend)

4. Revisas

5. Iteras

La diferencia con una web no está en el método de trabajo con la IA, es una diferencia de herramienta, no de filosofía.

Distribución

El gran cambio, para mí, llegó aquí.

Una web se despliega en Vercel y en segundos la tienes viva y accesible por URL, actualizable al momento. Una app móvil, no.

Una app pasa por tiendas de aplicaciones, revisión de Apple y de Google, procesos de testers (antes de llegar a producción); tiempos con los que no contabas. Sin menospreciar el pago de las licencias de desarrollador 😅 (99€/año en el caso de Apple y 25€ para Android).

Actualmente me encuentro en esta fase, la de testeo. Para que la aplicación salga adelante y cualquier persona se la pueda descargar, necesito que varios usuarios la estén probando, rompiendo y dándome feedback.

Así que si has llegado hasta aquí, ¿te animas a jugar?

Jugar a Wanderlore

Hoy vengo a hablarte sobre las 3 preguntas/respuestas que te ahorrarán muchísimo tiempo cuando construyes con IA.

Ya te adelanto que hoy vas a ver muchos treses 😂

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

Vivimos en la era de la inmediatez, lo queremos todo para ayer y el problema es que muchas veces aplicamos esta filosofía cuando nos sentamos delante del ordenador y nos ponemos a construir nuestro próximo proyecto.

Es posible que este método (el vibe coding puro y duro) funcione durante las primeras horas o para proyectos pequeños, pero cuando quieres empezar a construir algo con cierta seriedad, el no haber planificado nada de antemano te va a salir muy caro.

Yo aprendí esto a la fuerza.

Hace 3 años construía sin criterio. Pensaba: “¿para qué voy a perder tiempo en redactar lo que quiero construir si lo tengo todo en la cabeza?”

¡Me sentía invencible!

• Invencible hasta que las cosas empezaban a no cuadrar.

• Cuando me empezaba a contradecir.

• A no recordar las decisiones.

Entonces un buen amigo me recomendó que “cómo mínimo tienes que responder a estas 3 preguntas”:

1. QUÉ quieres construir

2. Para QUIÉN

3. POR QUÉ

La tercera pregunta responde a la pregunta de por qué debe existir tu app, qué problema resuelve concretamente. Es quizá la pregunta más importante de las tres, ya que si solo te sirve a ti, esta bien construirla, pero si quieres que tu app tenga éxito, debe resolver un problema real.

La respuesta a estas 3 preguntas es la especificación mínima que debes redactar antes de empezar a construir nada.

Y no, no es perder el tiempo, es lo que va a evitar que construyas al tuntún y que acabes pariendo un Frankenstein.

Con esto ya puedes empezar a construir con Lovable, pero si lo tuyo es Claude Code, te recomiendo que uses esta plantilla que creé hace algún tiempo:

Project Template

Entre otras cosas, dentro encontrarás:

CLAUDE.md

Archivo de referencia que lee cualquier agente de codificación antes de tocar el proyecto. Si docs/ está vacío, obliga al agente a preguntar "qué quieres construir y para quién" y a rellenar la documentación en orden antes de escribir código. Define stack tecnológico, convenciones, qué NO hacer, y protocolo obligatorio de cambios: changelog, actualización de docs, revisión de seguridad.

docs/

Carpeta de documentación estructurada: prd.md, business.md, design-system.md, architecture.md, data-model.md, roadmap.md, user-flows.md. Es donde viven las respuestas a qué, quién y por qué, convertidas en especificación real.

changelog/

Registro de cada cambio relevante: fecha, tipo (feature, fix, refactor, migración, documentación, configuración), qué se hizo, qué se modificó, por qué.

mejoras/

Backlog de ideas que no entran en el sprint actual: título, descripción, motivación, prioridad.

No es perfecto y seguro que se puede mejorar, pero es un punto de partida mucho mejor que empezar a promptear sin criterio.

¿Cuál es tu método? Te leo en los comentarios 🤓

Así que me planté delante de una bifurcación.

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

Local con el Mac despierto, o la nube

La primera opción era quedarme en local y obligar al Mac a no dormirse: evitar el reposo, programar un despertador, mantener la sesión viva. Funcionaría… mientras el Mac estuviera encendido, enchufado y de buen humor. Frágil.

La segunda era sacarlo todo de mi máquina y meterlo en la nube. Más trabajo de montaje, pero a cambio: corre aunque el Mac esté apagado, sin permisos de macOS de por medio, sin servidores que mantener. Elegí la nube. Si el objetivo era “olvídate y que funcione”, no había color.

Pero la nube traía una pregunta que tuve que decidir con criterio: mi agente guardaba su memoria —los posts, las métricas, lo aprendido— en una base de datos local. Una tarea en la nube no puede leer un archivo de mi disco. ¿Dónde vivía entonces la memoria?

La respuesta resultó casi indolora: Cloudflare D1, que es literalmente SQLite en la nube. Migré la base sin apenas tocar el código. La memoria dejó de ser un archivo en mi disco para ser algo que el sistema alcanza desde cualquier sitio.

La decisión de la que más orgulloso estoy

Aquí viene la parte con criterio de verdad. Cuando moví la lógica a la nube, tenía dos caminos:

1. Dejar que la IA, además de escribir los posts, razonara también los números: qué ángulo funcionó mejor, qué puntuación tenía cada uno.

2. Que la IA solo escribiera, y que el cálculo lo hiciera código determinista.

Elegí el segundo, y creo que es la decisión clave de todo el proyecto. Porque esto es un experimento: el sentido es medir qué funciona y aprender con el tiempo. Y en un experimento, el instrumento de medida tiene que ser constante. Si le pides a un modelo de lenguaje que puntúe, con los mismos datos puede darte resultados ligeramente distintos un día u otro — y peor aún, ese ruido se realimenta, porque la puntuación de hoy condiciona el contenido de mañana. Una regla que cambia de longitud cada vez no sirve para medir nada.

La frase que me quedó grabada: la IA escribe, el código calcula. Para lo que es juicio —redactar, elegir el ángulo— la IA. Para lo que es un cálculo fijo —puntuar, rankear— código. Mezclarlos te da lo peor de los dos mundos.

Lo que aprendes solo cuando lo enchufas

Sobre el papel todo encaja; al conectarlo aparecen las sorpresas. Tres que me llevo:

Pagar calderilla a propósito. En local, la IA escribía los posts con mi suscripción de Claude, gratis. Pero una tarea en la nube no puede usar mi suscripción. Para que el sistema fuera de verdad autónomo, el agente llama directamente a la API de pago. Cuesta unos céntimos al mes — y los pago encantado a cambio de independencia total. A veces la decisión correcta es dejar de optimizar el “gratis”.

Los detalles de integración que ningún tutorial cuenta. El conector “oficial” de Buffer hablaba con un servidor interno; mi token personal iba contra otra dirección distinta. Media hora de errores 401 hasta dar con ello. La fiabilidad de una automatización casi nunca está en la idea, está en estos detalles.

La IA no sabe contar. Bluesky limita los posts a 300 caracteres, pero el modelo se pasaba una y otra vez por mucho que se lo pidiera. La solución no fue rogar más fuerte, sino poner una red: si un post se pasa, el sistema le pide que lo reescriba más corto, hasta que cabe.

El último ajuste: que sonara a persona

Cuando por fin publicaba, los textos salían correctos pero telegráficos: frase corta, punto, frase corta, punto. Sonaban a lista, no a alguien contando algo. Curiosamente, la culpa era mía: para respetar el límite de caracteres le había pedido al modelo “frases secas”, y eso producía justo ese estilo a trompicones. Cambié las instrucciones hacia una prosa más narrativa y humana, y el cambio se nota.

[VISUAL 4: antes/después del tono — telegráfico vs narrativo, mismo contenido]

Qué me llevo

El agente quedó funcionando: cada mañana, en la nube y sin mi Mac de por medio, recogía métricas, escribía y publicaba, y guardaba lo aprendido. Y aunque ahora paro este experimento para llevar la idea a LinkedIn, me llevo tres cosas en la mochila:

• Entiende la herramienta antes de forzarla. Medio drama me lo ahorraba sabiendo qué era /loop.

• La IA para el juicio, el código para los números. No los mezcles.

• La fiabilidad vive en los detalles, no en la idea. Lo difícil no es construir el agente; es que corra solo cuando no estás mirando.

Que, mira, es exactamente la tesis con la que empecé: el problema no es construir, es la distribución. Solo que esta vez el experimento me lo demostró a mí mismo.

Fin de la serie.

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

El plan era sencillo. Cada mañana, el agente escribiría tres versiones de un post (tres ángulos distintos), las publicaría en Bluesky a través de Buffer, recogería las métricas del día anterior y ajustaría el contenido del siguiente. Y lo más bonito: el contenido iría sobre cómo se estaba construyendo el propio agente. El medio como mensaje.

Para el disparo diario tiré de lo que tenía más a mano: /loop, el comando de Claude Code que repite una tarea cada cierto tiempo. “Que se lance solo a las ocho”, pensé. Dejaba el Mac en reposo por la noche y, en teoría, a la mañana siguiente el agente habría publicado.

Spoiler: no funcionó 🥲

El muro

Lo primero que descubrí es que /loop no estaba pensado para esto.

/loop vive dentro de una sesión abierta y necesita el ordenador despierto: cuando el Mac entra en reposo, macOS suspende los procesos y el temporizador, sencillamente, no dispara.

Pero el problema de verdad llegó cuando intenté forzarlo.

Para que el agente publicara sin pedirme permiso cada mañana, edité a mano la configuración de permisos. Y ahí Claude Code empezó a bloquearse: cada vez que enviaba un mensaje, ocurría esto: process exited with code 1 — an internal error occurred (EPERM). Treinta minutos sin poder trabajar, desinstalando y reinstalando para recuperar el control.

EPERM significa “operation not permitted”. Es un error del sistema de archivos, no de la configuración de Claude. ¿La causa de fondo? Tenía todo (el proyecto y la carpeta de configuración de Claude) en un disco externo. Las escrituras y los bloqueos que Claude hace constantemente empezaron a chocar con los permisos del volumen externo.

La lección que me llevé

Pasé un buen rato culpando a mi configuración. Estaba equivocado: un EPERM casi nunca es culpa de tu config, sino del sistema de archivos que tienes debajo. Pero la lección más útil no fue esa, fue otra:

Había confundido dos cosas que parecen iguales y no lo son: lo atendido y lo desatendido.

/loop es una herramienta atendida: brilla cuando estás delante, con la máquina despierta y la sesión viva. Para vigilar un deploy mientras trabajas, para iterar sobre una tarea hasta terminarla, es perfecta. Lo que yo necesitaba era lo contrario: algo desatendido, que corriera cada mañana durante semanas, con el Mac apagado y sin nadie delante. Dos mundos distintos.

Y ahí estaba el verdadero problema de diseño: no era de permisos, era de arquitectura. Mi automatización dependía de mi portátil, y un portátil se duerme, se apaga y vive en un disco que se queja. Si quería que aquello corriera de verdad solo, tenía que sacarlo de mi máquina.

En la segunda parte cuento cómo lo hice: moverlo todo a la nube, qué decisiones tomé con criterio por el camino (incluida una que me hizo pasar de “gratis” a pagar unos céntimos al mes, a propósito), y cómo quedó un sistema que, literalmente, se cuenta a sí mismo.

Hoy vengo a hablarte de una elegante solución para resolver un problema común.

Cada vez que monto un proyecto aparece la misma situación: necesito un correo profesional con mi dominio, estilo “hola@tuproyecto.com”

La solución que aplicaba hasta hace unos meses era contratar un plan de email de Hostinger (porque el 99% de los dominios los registro desde ahí).

El tema es que hacerlo de esta manera comporta pagar unos 4 euros al mes por buzón (que casi no vas a usar).

Así que hoy te quiero plantear la alternativa que estoy usando desde principios de año.

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

Cloudflare + Gmail

Cloudflare tiene un servicio gratuito llamado Email Routing. La idea es simple: en lugar de contratar un buzón de correo para cada proyecto, creas un alias.

Un alias es una dirección como hola@tuproyecto.com que no tiene buzón propio. Cuando alguien te escribe ahí, el mensaje llega directamente a tu Gmail.

La diferencia con Hostinger u otros hostings de email es que ellos te alojan un buzón real en sus servidores. Cloudflare no aloja nada, solo reenvía. Para el 95% de proyectos es más que suficiente, y el coste es cero.

Puedes crear tantos alias como quieras y repetirlo con todos los dominios que tengas. Todo llega al mismo Gmail (o a la dirección que desees).

El paso que mucha gente se salta es el del envío. Es decir, puedes configurar Gmail para que al responder, el correo salga con la dirección de tu dominio. El destinatario ve hola@tuproyecto.com, no tu cuenta personal. Recibir y enviar, sin pagar nada.

Cómo se configura

Parte 1: Recibir correo

1. Entra a tu dominio en Cloudflare y ve a Compute > Email Service > Email Routing

2. Haz clic en “Onboard Domain” y selecciona tu dominio. Cloudflare añade los registros necesarios automáticamente

3. Ve a Destination Addresses, añade tu Gmail y confírma el email de verificación que te mandan

4. Ve a Routing Rules > Create routing rule, escribe el alias que quieres (hola, contacto, soporte...) y selecciona tu Gmail como destino

Parte 2: Enviar desde Gmail con tu alias

5. En Gmail ve a Ajustes > Cuentas e importación > Enviar correo como > Añadir otra dirección

6. Escribe el nombre y la dirección del alias. Desmarca “Tratarlo como un alias”

7. Servidor SMTP: smtp.gmail.com, puerto 587. Usa tu cuenta Gmail con una contraseña de aplicación (necesitas el 2FA activado en Google)

8. Verifica con el código que llega al Gmail

9. Al redactar un correo ya puedes elegir desde qué dirección envías

Nota importante para usuarios de España

En España, durante los días de partido de LaLiga, las operadoras bloquean rangos de IPs de Cloudflare para cortar retransmisiones ilegales. Tu web puede quedar inaccesible como daño colateral, sin que hayas hecho nada mal.

Si usas Cloudflare solo para Email Routing esto no te afecta. Pero si también tienes la web con el proxy activo, conviene saberlo: en el panel de DNS verás un icono de nube junto a cada registro. Si está naranja, el tráfico pasa por Cloudflare. Si está gris, va directo a tu servidor. Durante los días de partido puedes ponerla en gris para evitar el bloqueo.

¡Nada más por hoy! Guía cortita, al pie, como a mi me gustan :)

Si tienes alguna duda puedes dejar un comentario y estaré encantado de ayudarte. Y si te ha gustado la publicación, no olvides compartirla.

Compartir Con Criterio

Si me has estado siguiendo, sabrás que cuando empecé a construir con IA, lo hice con ChatGPT. Mi segundo gran salto fue Lovable, una herramienta que me permitió tener un producto funcionando en horas, sin saber prácticamente nada de código.

Pero con el tiempo aparecen los roces.

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

Con Lovable, la documentación que te permite adjuntar la herramienta es limitada. Puedes añadir una pequeña base de conocimiento, pero no una documentación viva que el agente consulte y actualice de forma dinámica. Además:

• Solo puedes construir con React y Vite, lo que cierra la puerta a otros stacks.

• Cada conversación queda dentro del chat, sin una forma sencilla de convertirla en conocimiento reutilizable.

• La personalización del agente tiene un techo bajo.

• Las integraciones disponibles son las que son: no puedes conectar MCPs propios ni usar Skills.

No es una crítica a Lovable. Para empezar, es fantástico. Pero llega un momento en que necesitas más.

Claude Code Desktop: dos modos de trabajo

La app de Claude tiene una pestaña llamada Code.

Cuando se habla de Claude Code en LinkedIn, casi todo el mundo lo asocia a la terminal: comandos, CLI y con perfiles técnicos.

Y es comprensible, porque así es como se presentó al principio. Pero existe otra forma de usarlo que muy poca gente menciona: la versión de escritorio. Con grandes funcionalidades, una interfaz visual, y que yo, personalmente, nunca he abandonado. Todo lo que he construido con Claude Code lo he hecho desde ahí.

Confesión: Con Claude, nunca he tocado el terminal.

Desde la versión de escritorio puedes trabajar de dos formas distintas:

a. Modo remoto (con GitHub)

Seleccionas un repositorio de GitHub y una rama.

Claude crea un entorno temporal en la nube donde trabaja con ese código. Haces tus peticiones en lenguaje natural, él implementa los cambios, y cuando estás conforme le pides que lo suba a GitHub. Limpio, trazable y sin salir del chat.

b. Modo local

En lugar de un repositorio remoto, apuntas a una carpeta de tu máquina. Aquí es donde aparece algo que te resultará muy familiar si vienes de Lovable: el preview en tiempo real.

Mientras Claude va haciendo cambios, los ves reflejados al instante. Y cuando quieres subir el proyecto a GitHub, simplemente se lo pides. A través del MCP de GitHub, Claude crea el repositorio, sube el contenido y gestiona los cambios. Sin terminal.

Una experiencia muy similar a la que ya has experimentado con Lovable, pero con todo el potencial y libertad de Claude.

Por qué me parece relevante para ti

Porque en Claude Desktop tienes acceso a todo el ecosistema que ya conoces si sigues esta newsletter: Skills, MCPs, SDD desde el primer momento. Es más, puedes:

1. Planificar y clarificar desde el mismo chat del proyecto.

2. Diseñar a través de Claude Design (y exportar lo que has hecho).

3. Construir y desplegar a través del chat con Claude Code.

No estás limitado a un stack ni a un conjunto cerrado de integraciones. Y el modelo que hay detrás es el mismo que usa Lovable, solo que sin la capa intermedia que te recorta las posibilidades.

Tengo ganas de grabar o de hacer un directo. Si tienes ganas de ver el proceso completo desde la ideación con SDD, pasar por Claude Design y terminar cosntruyendo con Claude Code Desktop, dejame un buen comentario y montamos algo 😊

Deja un comentario

¡Y hasta aquí la newsletter de hoy! Si te ha gustado lo que has leído no te olvides de compartirlo 😉

Pol Marzà - AI Product Builder

¿Cómo estás? :)

El jueves pasado estuve en Valencia. Di una charla en NTT Data, organizada por Product Beers Valencia, sobre mí: sobre cómo construyo con IA desde 2023 y cómo ha cambiado por completo mi forma de hacerlo en estos casi 4 años. De programar con ChatGPT y VSCode a orquestar agentes que hacen el 80% del trabajo pesado.

Pero lo interesante no pasó en la charla. Pasó después, con una cerveza en la mano.

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

Hablando con la gente que había venido, una idea salía una y otra vez en distintas conversaciones: construir ya no es el problema. Hoy, levantar un SaaS, una app, una web o un agente está al alcance de muchísima más gente. La barrera técnica, esa que durante años dejó fuera a los no-técnicos, se ha difuminado. Cualquiera con una buena idea y constancia puede tener un producto funcionando en un fin de semana.

¿Y entonces cuál es el problema? El mismo de siempre, solo que se ha movido de sitio: la distribución.

Puedes construir algo brillante y que no lo vea nadie. Lanzas en X, en Product Hunt, en LinkedIn… y tienes muy poco impacto. Porque las redes premian a quien ya tiene audiencia, y la mayoría de los que construimos en solitario tenemos audiencias pequeñas. Un producto técnicamente superior puede morir en el lanzamiento simplemente porque nadie lo vio.

Esa noche, de vuelta en el hostal, no me lo podía quitar de la cabeza.

Y se me ocurrió una idea.

La idea: solos llegamos a mil; juntos, a diez mil

Imagina que lanzas tu proyecto tú solo y tu audiencia es de 1.000 personas. Llegas a 1.000 personas. Punto.

Ahora imagina que diez builders de una comunidad publican sobre tu proyecto el día del lanzamiento. Si cada uno tiene 1.000 seguidores, de repente tu alcance potencial no es 1.000: son 10.000. La comunidad no te suma, te multiplica. Te catapulta.

Esa es toda la filosofía de Swapicorn.

Qué es Swapicorn

Swapicorn es un ecosistema de distribución colaborativa para builders de IA. No es publicidad ni un directorio más donde subir tu link y rezar. Es un sistema de apoyo mutuo, meritocrático y de suma positiva. Lo defino como un “sindicato de creadores”: donde el éxito de uno impulsa al resto.

Funciona con un sistema de créditos llamados Swapis:

• Te registras, conectas tus redes y el sistema te asigna un nivel del 1 al 5 según tu alcance.

• Publicas tu proyecto y le asignas un presupuesto de swapis.

• Otros builders lo promocionan en sus redes y, a cambio, ganan tokens (swapis).

• Tú, a tu vez, ganas swapis promocionando los proyectos de otros.

Es un círculo virtuoso: ayudas a la comunidad y la comunidad te ayuda a ti. Nadie depende de tener ya un público enorme ni de gastar un euro en ads. El mérito y la reciprocidad sustituyen al algoritmo y al presupuesto.

Y lo mejor: cuando alguien promociona tu proyecto, no es un bot ni un anuncio frío. Es otro builder, con su voz y su audiencia real, contándole a su gente lo que has construido.

Lo construí este fin de semana (y eso es parte del mensaje)

Hay algo que me hace gracia y que encaja perfecto con la tesis de la charla: monté Swapicorn entero este fin de semana, construyendo con IA. Lo que antes habría sido un proyecto de meses, hoy es un finde. La parte difícil ya no era hacerlo. La parte difícil sigue siendo que llegue a la gente adecuada.

Así que Swapicorn es, en cierto modo, una solución construida con la propia herramienta que crea el problema. Me parece poético.

Lo lancé hace apenas un par de días, lo he ido enseñando en grupos pequeños y ya hay seis proyectos publicados. Está en beta: puede tener errores, cosas a medio pulir, detalles que mejorar. Cuento con ello.

Esto es para ti si construyes con IA

Si estás leyendo esto y construyes productos (solo o en equipo) y te suena eso de “lo lancé y no lo vio nadie”, Swapicorn es para ti.

Entra, sube tu proyecto y deja que la comunidad lo amplifique. Y si por el camino te encuentras un bug, una fricción o algo que no cuadra, déjamelo en los comentarios: estoy puliendo la plataforma en directo y cada feedback me ayuda a hacerla mejor.

👉 Únete a Swapicorn

Lo vi. Entendí el argumento. Y creo que está equivocado, aunque no por las razones que imaginas.

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

Déjame contarte cómo uso yo el vibe coding, porque creo que ahí está la clave.

Cuando tengo una idea, lo primero que hago no es sentarme a planificar. Lo primero que hago es construirla. Sin estructura, sin documentación y sin pensar demasiado.

Abro Lovable o Claude Code y les describo lo que tengo en la cabeza. En media hora tengo algo que puedo tocar. Algo que funciona más o menos, que tiene agujeros por todos lados y que probablemente tire a la basura en dos días.

Y eso es exactamente lo que quiero.

Porque lo que me da ese prototipo no es código. Me da claridad. Cuando construyes algo rápido y mal:

• Descubres los problemas reales antes de invertir tiempo en resolverlos bien.

• Descubres que el flujo que imaginabas no tiene sentido cuando lo usas.

• Que la funcionalidad que creías central resulta secundaria.

• Que hay un problema técnico concreto que no habías visto desde la descripción.

Después de ese prototipo, lo tiro. Y construyo de nuevo, esta vez con SDD. Pero ya no estoy construyendo a ciegas. Sé lo que quiero que haga la aplicación. Sé los retos a los que me voy a enfrentar. Tengo criterio para tomar decisiones porque ya he tropezado con los problemas una vez.

El vibe coding no es una metodología de desarrollo. Es una metodología de exploración. Y los que dicen que ha muerto están comparando dos cosas que no compiten entre sí.

Los datos que citan esos vídeos son reales: la gente que intentó lanzar productos serios solo con vibe coding se encontró con código frágil, deuda técnica imposible de gestionar y aplicaciones que no escalaban. Pero ese no es un problema del vibe coding; es un problema de usarlo para lo que no fue pensado.

Para recapitular antes de cerrar:

1. Vibe codea tu idea → Sin pensar demasiado. El objetivo no es el código, es entender si la idea tiene sentido cuando la tocas con las manos.

2. Clarifica tus hallazgos → Antes de tirar el prototipo, documenta lo que has aprendido. Qué funcionó, qué no, qué problema real has descubierto debajo del problema que creías tener.

3. Redacta los docs en SDD → Ahora sí. Con ese conocimiento encima de la mesa, define la arquitectura, el modelo de datos, el comportamiento esperado. Ya no estás especulando, estás describiendo algo que entiendes.

4. Construye con Claude Code → Con los docs como contexto, el agente tiene todo lo que necesita para generar código que no tendrás que tirar.

Hablo en pasado porque esto acaba de cambiar.

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

Para entender qué ha pasado, primero necesitas saber por qué estaba roto.

Cuando visitas una web, tu navegador recibe un documento HTML y lo muestra. Pero hay dos formas de generar ese documento:

• SSR (Server-Side Rendering): el servidor te lo manda ya construido, con todo el contenido dentro.

• SPA (Single Page Application): el servidor te manda un esqueleto casi vacío y un montón de JavaScript que se ejecuta en tu navegador para construir la página.

Tú, como usuario, no notas la diferencia. Ves el título, el texto, las imágenes. Todo normal. El problema es que los robots no funcionan como tú.

Cuando Google rastrea una web, manda un programa que descarga el HTML inicial y lo lee tal cual. En una web construida con Lovable, ese HTML inicial era básicamente un <div> vacío (era una SPA). El contenido real lo generaba React después, en tu navegador, pero para cuando eso ocurría el robot ya se había ido. Lo mismo le pasaba a ChatGPT, a Perplexity, a cualquier herramienta que intentase leer el contenido de tu app a partir de su URL.

Llevaba meses señalando esto en LinkedIn cada vez que el tema salía. Si necesitabas posicionamiento, recomendaba Astro, Next.js, o trabajar directamente con Claude Code. Herramientas que generan el HTML completo en el servidor (SSR) antes de mandártelo, para que cuando llegue el robot encuentre algo que leer.

Lovable acaba de hacer exactamente eso. Los proyectos nuevos se construyen sobre TanStack Start, un framework con renderizado en el servidor nativo. Las páginas llegan al navegador ya completas. Google las puede leer desde el primer momento. ChatGPT también. Y los proyectos existentes reciben automáticamente un sistema de snapshots estáticos que hace accesible el contenido a los crawlers sin que tengas que migrar nada ni tocar ningún ajuste.

Es un cambio técnico, sí. Pero lo que representa va más allá de la técnica. Lovable lleva tiempo siendo la herramienta favorita para construir prototipos rápidos, pero con este movimiento está diciendo que quiere ser algo más: una plataforma desde la que lanzar productos reales, que compitan, que el mundo pueda encontrar.

Hoy el post ha sido algo más cortito, con un par de enlaces a las definiciones de SSR y SPA en nexy.ai y otros enlaces a las webs de frameworks. ¿Qué te parece este formato? Déjame tu opinión en los comentarios :)

Por cierto, el próximo jueves 28 de mayo estaré en Valencia dando una charla con los compañeros de Product Beers Valencia. Explicaré como ha sido mi camino de AI CODING, desde mis inicios con ChatGPT en noviembre de 2022 hasta Claude Code. Hablaré de la mentalidad maker más que de las herramientas, explicaré mi experiencia construyendo, desde los proyectos Frankenstein hasta el SDD.

Si estás por Valencia, ¡apúntate que las reservas están volando!

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

Hoy hablaremos de seguridad en nuestros desarrollos 🤓

Te hago un pequeño resumen por si quieres ir directamente a ese apartado que más te interese:

• Las imperdibles— Variables de entorno, RLS en Supabase y rotación de keys: lo que ninguna herramienta puede compensar si lo ignoras.

• /security-review en Claude Code — El comando nativo de Anthropic que audita tu código antes de cada deploy, sin configuración.

• Aikido: escaneo continuo — Conecta tu repositorio y vigila vulnerabilidades en segundo plano, gratis hasta 10 repos.

• Bonus: pentesting en Lovable — Agentes que atacan tu app en vivo para encontrar lo que el análisis estático no ve.

Ahora sí, ¡empezamos!

1. Las imperdibles

Antes de hablar de herramientas, hay decisiones de arquitectura que ningún escáner puede compensar si las ignoras desde el principio.

Nunca hardcodees credenciales en el código. Las API keys, tokens de base de datos y secrets no deben estar escritos en ningún archivo de tu repositorio, ni en comentarios, ni en archivos de configuración que subes a GitHub. Esto parece obvio hasta que ves a alguien publicar un repo con las keys de Stripe expuestas.

La alternativa es usar variables de entorno. En Vercel las gestionas desde el panel del proyecto (Settings → Environment Variables). En Supabase tienes las claves de servicio accesibles desde Project Settings → API. Tu código lee esas variables pero nunca las contiene.

Activa Row Level Security en Supabase desde el inicio. Si construyes con Supabase y no activas RLS en tus tablas, cualquier usuario autenticado puede leer (o modificar) los datos de cualquier otro usuario. No es una vulnerabilidad avanzada, es la configuración por defecto cuando creas una tabla sin políticas.

Actívalo al crear la tabla, no después. Añadirlo retroactivamente cuando ya tienes datos y lógica construida es más costoso y más fácil de hacer mal.

Rota las keys si sospechas una exposición. Si en algún momento una key estuvo en un commit, en un mensaje de chat, o en cualquier lugar fuera de las variables de entorno, invalídala y genera una nueva. El tiempo que tardas en rotar es menor que el daño potencial.

2. Auditoría con Claude Code: el comando /security-review

Claude Code incluye por defecto un slash command mantenido por Anthropic llamado /security-review. No hay que instalarlo ni configurarlo: está ahí desde el primer momento.

Lo que hace es analizar los cambios pendientes en tu codebase buscando vulnerabilidades reales y explotables. No es una búsqueda por patrones superficiales: examina el código en contexto, entiende qué hace cada parte y filtra los falsos positivos para darte solo hallazgos que merecen atención.

Las categorías que cubre:

• Inyección de SQL, comandos y otros vectores de inyección

• Problemas de autenticación y autorización (escalada de privilegios, bypass de sesiones)

• Exposición de datos sensibles y secrets en el código

• Problemas criptográficos

• Configuraciones inseguras

Cómo usarlo: abre Claude Code en tu proyecto, escribe /security-review y deja que analice. El momento ideal es antes de cada deploy relevante, especialmente si has tocado autenticación, esquema de base de datos o endpoints de API.

También puedes integrarlo en GitHub Actions para que revise automáticamente cada pull request. El repositorio oficial de Anthropic (anthropics/claude-code-security-review) tiene el workflow listo para copiar.

Un par de enlaces de interés:

• Documentación oficial sobre /security-review en el blog de Anthropic.

• Repositorio oficial en Github.

3. Aikido: escaneo continuo del repositorio

/security-review analiza tus cambios de forma manual y bajo demanda. Aikido hace algo diferente: conecta con tu repositorio de GitHub, lo escanea de forma automática cada pocos días y te avisa cuando encuentra algo.

El plan gratuito incluye hasta 10 repositorios, 2 usuarios y escaneo básico. Para un builder individual o un equipo pequeño es suficiente para tener visibilidad continua sin pagar nada.

Lo que escanea en el plan gratuito:

• SCA (Software Composition Analysis): vulnerabilidades conocidas en tus dependencias npm. Las librerías que instalas también tienen CVEs, y Aikido los detecta antes de que alguien los explote.

• SAST (Static Application Security Testing): análisis estático del código buscando patrones de vulnerabilidad.

• Detección de secrets: credenciales que pudieran haberse filtrado en el repositorio.

• Escaneo de cloud: misconfigurations en tu cuenta de Vercel, AWS o GCP si la conectas.

La diferencia respecto a otras herramientas similares es la reducción de ruido. Contextualiza los hallazgos según tu entorno real y descarta los que no suponen un riesgo efectivo. Menos alertas, más señal.

Cómo empezar: entra en aikido.dev, conecta tu cuenta de GitHub y selecciona los repositorios que quieras monitorizar. El primer escaneo tarda entre 1 y 5 minutos.

Bonus track: pentesting con Aikido en Lovable

Si construyes con Lovable, hay una capa adicional disponible desde marzo de 2026: pentesting con IA directamente integrado en el editor.

La distinción importante es que el escáner de seguridad de Lovable (que ya existía) hace análisis estático: lee el código y detecta patrones problemáticos. El pentesting de Aikido hace análisis dinámico: despliega agentes que atacan la aplicación en vivo, como lo haría un atacante real. Prueban flujos de autenticación, intentan acceder a datos de otros usuarios, sondean las APIs.

Las dos cosas son complementarias:

• El estático detecta lo que podría ir mal en el código.

• El dinámico detecta lo que efectivamente se rompe cuando alguien lo intenta.

Para proyectos en Lovable, el precio de lanzamiento es de 100 dólares por test. También hay “Security weekends” gratuitos anunciados puntualmente. El modelo de pago es cómodo: puedes iniciar el pentest sin pagar y solo desbloqueas el informe completo si decides que los hallazgos merecen el coste.

El flujo desde Lovable: Settings → Connectors → App connectors → Aikido. Desde ahí puedes lanzar el test y los hallazgos se sincronizan directamente en tu proyecto para corregirlos sin salir del editor.

El orden lógico

Las tres validaciones no son alternativas, son capas:

1. Las buenas prácticas son el suelo. Sin ellas, nada de lo demás importa.

2. /security-review es la revisión activa antes de cada deploy importante.

3. Aikido es la vigilancia continua en segundo plano.

El pentesting es el siguiente paso cuando el producto ya está en producción y quieres poder demostrar, no solo suponer, que es seguro.

Construir rápido no obliga a construir inseguro. Solo requiere que estas validaciones sean parte del flujo desde el principio, no algo que se añade cuando ya hay un problema.

¡Y hasta aquí la newsletter de esta semana! Espero que no haya sido muy densa.

Lo bueno de todo esto es que, como digo al final, ¡lo puedes empezar a aplicar desde YA! No esperes a que salgan errores.

¡Nos vemos la próxima semana!

Un abrazo.

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