Seguro que en redes has leído más de una vez que para construir con IA no hace falta saber programar (aunque si sabes, tienes mucho ganado), pero lo que sí hace falta es poseer un set de habilidades.

Este set de habilidades serán las que determinen si terminas construyendo proyectos de forma exitosa o si te quedas por el camino.

Las 6 habilidades que veremos

1. Tolerancia a la ambigüedad

2. Descomposición de problemas

3. Criterio para evaluar el output

4. Persistencia frente al error

5. Comunicación precisa

6. Curiosidad técnica selectiva

Antes de empezar te quiero comentar que me han invitado a participar en el AI Summit que ha montado donde ha reunido a 20 expert@s en distintas disciplinas para que cuenten qué usan exactamente, qué han probado, qué no les funcionó y hacia donde va todo esto.

Algunas de las personas que hablaran seguro que las conoces:

· · · · · · · ·

Las charlas se publicaran del 21 al 25 de septiembre y la mía sale el viernes.

Pilla tu entra aquí.

1. Tolerancia a la ambigüedad

Vas a construir sin saber si funciona hasta que lo pruebas. La IA te entrega una solución que parece razonable, pero puede estar mal, y tenemos la costumbre de esperar a tener una certeza total antes de avanzar, así que es la primera que hay que soltar.

La tolerancia a la ambigüedad se entrena poniéndose límites de tiempo para decidir en vez de investigar hasta sentirse seguro. Por ejemplo: “pruebo esta librería 20 minutos, si no funciona cambio de enfoque.”

Construir bajo ese límite obliga a actuar sin la información completa que preferirías tener, y esa repetición es lo que entrena la tolerancia.

2. Descomposición de problemas

“Quiero una app de gestión de tareas” no es una instrucción ejecutable. “Quiero un formulario que guarde una tarea con título y fecha en una tabla” sí.

La habilidad de partir una idea grande en piezas pequeñas y concretas es lo que separa a quien construye rápido de quien se traba contra la IA en un bucle de prompts cada vez más vagos.

Esta habilidad se entrena escribiendo la tarea en pasos numerados antes de tocar la IA, en un papel o una nota:

1. Crear tabla de tareas.

2. Formulario con título y fecha.

3. Botón guardar que inserta en la tabla.

Si no puedes numerar los pasos, todavía no descompusiste lo suficiente, y ese bloqueo es el ejercicio en sí mismo.

3. Criterio para evaluar el output

Cualquiera puede pedirle algo a la IA.

La diferencia la hace saber si lo que devolvió es correcto, si tiene sentido o si es lo que realmente pediste. Sin esto, vas a acumular código que no se entiende y que falla de formas que no se pueden diagnosticar.

Antes de aceptar un output, conviene preguntarse por escrito qué se supone que hace y probarlo específicamente para eso, no de forma genérica.

Con el tiempo merece la pena llevar una lista personal de errores típicos que la IA repite (”siempre olvida las validaciones”, “asume que hay usuario logueado cuando no lo hay”) y revisarla antes de aceptar código nuevo.

TIP: Esta lista de errores también te puede servir para crear una SKILL para Claude, para que revise ese checklist antes de dar el producto por terminado.

4. Persistencia frente al error

Va a haber bugs, deploys rotos y momentos en los que la IA arregla una cosa y rompe otra.

La reacción de “esto no funciona, no sirvo para esto” mata más proyectos que la dificultad técnica real.

Cuando algo falla, conviene:

1. Leer lo que ha ocurrido (aunque no lo entiendas).

2. Pegar el error en una conversación y pedirle a la IA que te lo explique.

Llevar la cuenta mental de los bugs ya resueltos ayuda a contrarrestar la frustración cuando aparece el siguiente.

5. Comunicación precisa

Escribir prompts claros es una habilidad de comunicación, no una habilidad técnica.

Ser específico sobre qué se quiere, qué no se quiere y qué contexto importa determina la calidad de lo que se obtiene, igual que pasa al explicarle algo a otra persona.

Se entrena reescribiendo el prompt una vez antes de enviarlo y minimizar la ambigüedad, es decir, cambiar “hazlo más bonito” por “usa más espacio en blanco entre secciones y una tipografía más grande en los títulos”.

Practicarlo fuera de las herramientas de IA también sirve. Describirle una tarea a alguien sin que pueda preguntar nada de vuelta trabaja el mismo ejercicio de precisión.

6. Curiosidad técnica selectiva

No hace falta entender todo el stack, pero sí preguntar “¿por qué hiciste esto así?” o “¿cómo funciona esto?”.

Esta curiosidad es puntual, pero debe ser continua. Esta habilidad es la que, con el tiempo, te ayudará a construir tu modelo mental.

Es gratis y rápido: cuando la IA hace algo inesperado, preguntarle directamente antes de seguir, convierte cada sorpresa en una micro-lección en vez de dejarla pasar sin más.

Hay una séptima habilidad que no he mencionado: la paciencia.

Cada una de estas 6 habilidades se van construyendo con el tiempo, proyecto a proyecto. Si quieres construir bien a largo plazo, no hay atajos.

Preguntas para seguir el hilo con Claude

Si quieres seguir ahondando en este tema, te dejo algunas preguntas que le puedes soltar a Claude.

• Tengo un prompt que la IA malinterpreta siempre de la misma forma, ¿cómo reestructuro la instrucción para eliminar esa ambigüedad concreta?

• ¿Cómo distingo si un bug viene de un problema en mi lógica o de una limitación real de la herramienta que estoy usando?

• ¿Qué preguntas debería hacerle a la IA sobre una pieza de código que generó para verificar que entiendo lo que hace antes de aceptarla?

Es la publicación que mejor ha funcionado en la (corta) historia de mi newsletter:

• 373 visitas totales

• 11 likes

• 17 comentarios

• 3 restacks

• 7 veces compartido

Lo mejor de todo es que 13 personas se suscribieron a la newsletter y otras 16 personas se instalaron la extensión. Algunas que me lo han comentado son:

, , , , , y

La compartí porque me pareció la forma más sencilla de que cualquier persona, técnica o no, pudiera ver sus números sin liarse.

Si la probaste y te sirvió, me harías un favor enorme dejando una valoración en la ficha de la extensión. En serio, ayuda muchísimo más de lo que parece.

Dejar reseña

PERO (aquí viene el pero de siempre) llevo unos días dándole vueltas a algo.

Cuando compartí la extensión, varios de vosotros (makers, builders o gente que ya construye con Claude) me escribisteis básicamente lo mismo:

“Oye Pol, esto está genial, pero [rellena aquí tu petición]”

Lo genial de la extensión es que es un plug and play (enchufar y listo), pero los datos que trae son los que he decidido yo mostrar, cómo mostrarlos y lo peor es que son estáticos.

Así que, hoy te regalo la SKILL para que puedas meterle mano a tus datos de Substack :)

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

Vamos por partes

Esta SKILL es básicamente unos archivos e instrucciones que le enseñan a Claude donde tiene que buscar los datos reales de Substack (los datos que usa la plataforma en su propio panel) y dejártelos listos para consultar.

La SKILL te construye el mismo tipo de dashboard que la extensión.

A primera vista podrías pensar que la SKILL y la extensión para Substack de la semana pasada son lo mismo, pero realmente tiene mucho más.

Pero ojo: el dashboard es solo una posibilidad, no el objetivo. Lo que hace la SKILL de verdad es enseñarle a Claude dónde están tus datos y cómo leerlos. Que eso termine en un dashboard o simplemente en la respuesta a algo puntual que quieras saber, sin montar nada visual, depende de lo que tú le pidas.

He documentado un total de 120 endpoints distintos de la API de Substack. Los puedes encontrar todos aquí.

La gracia de mezclar la SKILL y esos endpoints es que puedes hablar con ellos, puedes preguntarle a Claude directamente, en lenguaje natural, cosas tipo “qué post terminaron más personas”, “cómo es la estructura de los posts que más retienen la atención”, etc.

Algunos de los endpoints que me han gustado más son:

• Finalización de lectura. No cuantas personas abren tu post, sino cuantas terminan de leerlo. La primera vez que lo veas duele un poco ^^”

• Solapamiento de audiencia. Qué otras newsletter comparten tus mismos lectores.

• Conversión por canal. A veces el canal que te trae más tráfico no es el que más suscriptores convierte.

• Comparativa contra posts similares. Si un poz concreto lo hizo mejor o peor que la media de los que se parecen.

Cómo instalar la SKILL

Para hacerlo de la manera más ordenada posible:

1. Crea una carpeta en tu ordenador llamada “substack stats” (por ejemplo)

2. Abre la carpeta dentro de Claude Code

3. Pégale la siguiente instrucción “Instala esta skill de forma global: https://github.com/polmarza/substack-stats-skill”

Cómo usar la SKILL

Una vez instalada pídele a Claude que te muestre tu dashboard.

El agente abrirá su navegador interno y navegará hasta Substack.

Al ser la primera vez, tendrás que iniciar sesión en tu cuenta en ese navegador (pones tu email, substack te manda un código, lo pones, listo).

Claude empezará a recopilar todos tus datos.

Esto suele tardar 1-2 min ya que lo he configurado para que las peticiones estén algo separadas en el tiempo, para no saturar el servidor de Substack.

También dependerá del número de publicaciones (newsletter y Notes) que hayas hecho a lo largo del tiempo.

Una vez termine, te mostrará algo así:

Guárdalo en “Descargas”. Este archivo .json es toda la data que ha podido recopilar Claude sobre tu(s) publicación(es) en Substack.

¿Recuerdas el panel que te he enseñado al principio del post? Pues ese es el que se poblará con los datos de este json descargado.

Substack guarda muchísimos más datos de los que al final te enseña y, por el momento, no tiene una herramienta nativa para interactuar con ellos.

Esta SKILL pretende subsanar eso.

Disfrútala :)

Ese era nuestro problema (porque creo que es compartido), hasta ahora.

Hoy te voy a enseñar el plugin “Panel para Substack” (que puedes instalar desde aquí) para que sientas la misma satisfacción que experimento yo cada día.

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

Qué descubrirás

Gracias a este dashboard no muestra (solamente) métricas vanidosas. Cuatro son las preguntas que vas a poder responder:

1. Qué temas funcionan y cuáles no

2. Qué notas merecen el rato que les dedicas

3. Si tu tasa de apertura se está torciendo y desde cuándo

4. (Si tienes más de una newsletter) cuál crece más, no cuál tiene más seguidores

AVISO: Verás que el dashboard está en inglés. Arriba a la derecha puedes cambiar el idioma de la interfaz clicando en el icono de la bola del mundo.

Cómo funciona

Solo tres pasos te separan de ver tus stats:

1. Instalas la extensión desde la Chrome Web Store

2. Una vez instalada pulsala y dale al botón “Sync all publications”.

Al sincronizar, el plugin abrirá una pestaña por cada publicación que tengas (si solo tienes una newsletter, solo abre una), lee tus estadísticas con la sesión que ya tienes puesta.

Si tienes muchos posts, tarda un par de minutos. Va despacio para respetar las consultas a la API de Substack.

BONUS: Ancla la extensión a tu barra de navegación para tenerla siempre a mano.

3. Cuando haya terminado, dale a “Open the dashboard” y verás algo así (adaptado a ti):

Esto de arriba es lo primero que verás cuando todo esté sincronizado: suscriptores, vistas, tasa de apertura, media de reacciones y altas atribuidas a posts. Debajo la progresión de suscriptores y de dónde vienen.

Puedes pulsar en cualquier post de la tabla para ver sus estadísticas sin tener que cambiar de pantalla:

Ahí ves de dónde vino su tráfico, qué enlaces se clicaron más, cómo fueron sus vistas día a día la primera semana. Además, en la columna de la derecha puedes comparar este post con tu propio post medio.

Si escribes en más de un sitio, la vista comparativa las pone todas juntas y te muestra el top 10 global de posts:

Si este post te resulta útil, ¿qué te parece si lo compartes? 😜

Compartir

Un comentario que lo cambio todo

Mientras estaba construyendo este plugin, leí un comentario de en una publicación de donde este segundo publicaba sus stats (lo hace cada martes, al desnudo).

Mike comentó:

¡Y no puede tener más razón!

Un post que mandas a 1.800 personas le va a ganar siempre a uno que mandaste a 200, aunque el viejo llegara a una porción mucho mayor de personas.

Para eso el panel tiene dos modos:

En “absoluto” ves las cifras tal cual, como en cualquier dashboard. Pero en relativo el alcance se divide entre los que de verdad recibieron cada envío y la interacción entre las vistas de ese mismo post.

Te lo muestro con un par de capturas:

Absolutas

Relativas

Los datos son los mismos en ambas, pero cambia contra qué lo mides. A mi me cambió el orden de cuáles creía que eran mis mejores posts.

¿Y los datos?

Tus datos son tuyos y yo no los quiero para nada, así que todo se guarda en tu ordenador.

No hay servidor, ni cuenta, registro o analítica. La extensión habla con Substack para obtener los datos y estos van directos a tu navegador. Las estadísticas se guardan en el almacenamiento que Chrome reserva en tu propio equipo.

AVISO: Si cambias de ordenador tendrás que volver a sincronizar tus datos (un par de minutos)

Un par de cosas más antes de terminar, porque prefiero ser transparente:

1. El plugin usa la misma API interna de Substack, pero no está documentada (ni es oficial), así que si Substack la cambia, tocará actualizar (yo me encargo).

2. Como he comentado antes, la interfaz está en inglés (por si esto peta y llega lejos). Arriba a la derecha tienes un botón (globo) para pasarla a español.

Agradecimientos

Antes de terminar me gustaría dar las gracias a 3 personas:

• A porque fue el primero que vi que compartía sus stats. Él lo hace a través de un Artefacto de Claude (amo a Claude) y espero que ahora lo haga a través de mi extensión.

• A por encenderme la chispa de lo que comparto hoy. Su primera solución fue descargarse el CSV (aunque él mismo declaro que era un rollo) y hoy ha publicado su propio plugin.

• A por inconformista. Porque, charlando, me dijo que le molaría un panel donde no solo ver las estadísticas vanidosas, sino las relativas. Porque no es lo mismo ver tus stats cuando tenías 10 seguidores que cuando tengas 10k.

¿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é

¡Hola, hola!

Antes de empezar a leer fíjate que he grabado una nota de voz. Quería probar esta nueva funcionalidad de Substack y como siempre me han dicho que tengo voz de locutor… Pues vamos a darle uso. Así que te invito a escucharme :)

¿Qué tal el verano?

Ya, seguro que pensaste que no me volverías a ver por aquí…

El pre-verano estuvo lleno de cambios, mucho trabajo y nuevas responsabilidades y abandoné un poco esta newsletter porque, ya sabes, escribo por placer y por compartir, pero esto no es mi negocio.

Así que estoy feliz de retomar esto con ganas de aportar nuevos conceptos, con criterio :D

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 quiero hablarte del orden en el cual construyo mis proyectos. El orden es importante para que tengas una estructura que puedas replicar, para que cada proyecto tenga un orden.

Habitualmente construyo de dentro hacia afuera, es decir:

1. BBDD

2. Backend

3. Frontend

Esto tiene sentido la mayoría de las veces, sobretodo cuando ya tengo claro lo que quiero construir.

Por qué funciona

Funciona porque la base de datos es el “contrato” de verdad de la aplicación. Ella define:

• Qué entidades existen

• Cómo se relacionan

• Qué es obligatorio

• Qué es único

Si cambias el modelo de datos después de construir el frontend, arrastras cambios en cascada: formularios, validaciones, tipos, consultas… todo se reescribe.

El backend expone ese modelo mediante reglas de negocio y permisos, así que hay que construirlo después de la BBDD, pero antes del front para evitar diseñar pantallas alrededor de una API que aún no sabes cómo se comportará (paginación, errores y/o estados intermedios).

El frontend es la capa más barata de rehacer. Cambiar un componente cuesta minutos, pero cambiar un esquema de datos con datos reales ya insertados cuesta horas o migraciones (y cosas que se pueden romper).

Cuándo NO aplica

Si estás validando una idea de producto y no sabes si el usuario la quiere, construir la BBDD primero es prematuro. Ahí conviene “frontend-first” con datos mockeados para iterar sobre UX y descartar rápido (lo que vendría siendo vibe coding).

Con herramientas como Lovable, el coste es mejor y reduce parcialmente la penalización de invertir el orden.

Perfecto, ya tenemos claro cuando aplicar una u otra metodología. Ahora bien, ¿cómo empezar?

Cuando empiezas frontend-first (Lovable u otra herramienta similar)

Realmente no necesitas una documentación formal; necesitas responder tres preguntas básicas antes de escribir el primer prompt:

1. Qué pantalla o flujo concreto vas a enseñar (no “una app de gestión de tareas”, sino “el flujo de crear una tarea y marcarla como hecha”).

2. A quién se lo vas a enseñar y qué decisión tomará esa persona al verlo (invertir, usarlo, darte feedback).

3. Qué datos son reales y cuáles son inventados para la demo (esto evita que luego confundas mock con producción).

Con esto en mente ya puedes entrar a Lovable.

Cuando empiezas dentro-fuera (BBDD → backend → frontend)

Mientras que en la opción anterior podías improvisar más (y de hecho, esa es su gracia), aquí sí conviene un protocolo, porque el coste de un agente escribiendo código sin entender el dominio completo, es alto.

Cuando construyo así, siempre uso mi plantilla project-template

Lo que resuelve o con lo que te ayuda esta plantilla en este contexto es:

• Antes de que el agente empiece a escribir código, lee la carpeta docs/. Los documentos por defecto están vacíos, así que primero te empieza a hacer preguntas para rellenarlos.

• Cada funcionalidad (feature) se acuerda primero en una ficha (docs/features/) con criterios de aceptación comprobables antes de implementar nada.

• Un script en CI verifica que ningún requisito quede sin su test o justificación de porqué no aplica.

• El registro en changelog/ deja trazabilidad de qué se construyó y por qué, evitando así que en la siguiente sesión el agente repita contexto o se pierda.

La diferencia práctica entre ambos casos es que en Lovable clarificas en tu cabeza porque vas a iterar rápido y descartar (vibe coding), mientras que en el otro caso clarificas en documentos porque el coste de deshacer un error de modelo de datos es demasiado alto como para ir improvisando (se acerca más a SDD o Spec Driven Development).

¡Nada más por hoy! Espero que la lectura te haya resultado interesante :)

Ahora lo más importante es que empieces a aplicarlo. No te quedes solo con la teoría y el “ah, ya lo entiendo”. Hasta que no lo pruebes no verás si realmente te sirve para ti.

¡Hasta la semana que viene!

¿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é

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