Hola, ¿cómo va el verano? 😃
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í:
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”:
QUÉ quieres construir
Para QUIÉN
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:
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 🤓