Seis decisiones antes de tu primer prompt, y por qué está ahí cada una

Nadie quiere gastar una tarde en setup. La tentación es abrir un chat y empezar a describir la cosa, y para un prototipo ése es el instinto correcto — la primera semana tiene su propio post y casi todos los consejos de allí son ve más rápido.

Éste es el otro post. Es para el momento en que decides que la cosa seguirá existiendo el mes que viene, y son seis decisiones. Cada una cuesta minutos. Cada una cierra una forma concreta de que la segunda semana salga mal, y la razón de tomarlas juntas es que las seis son baratas ahora y caras después.

Ninguna de ellas va sobre qué modelo es el mejor.

1. GitHub, que es un botón de deshacer con el que puedes hablar

Si no lo has usado nunca, ignora cómo se suele describir. GitHub no es una red social para programadores y no estás ahí para leer el código de nadie. Es un sistema de guardado con historial, alojado en un sitio que no es tu portátil.

Cinco palabras cubren casi todo lo que necesitas:

• Repositorio — la carpeta de tu proyecto, más todas las versiones que ha tenido.
• Commit — un punto de guardado con una nota pegada. «La pantalla de login funciona» es un commit.
• Rama (branch) — una copia del proyecto donde puedes romper cosas sin romper el original.
• Push / pull — sincronizar entre la copia de tu máquina y la copia en GitHub.
• Pull request — «aquí hay un cambio, míralo antes de que entre». Estando solo no lo necesitarás; lo necesitarás el día en que otra persona toque el proyecto.

Y aquí está por qué le importa específicamente a quien hace vibe coding. En algún momento — no «quizá» — una sesión reescribirá algo que ya funcionaba. Refactorizará un fichero que te gustaba, o borrará una función que decidió que no se usaba, o arreglará un bug metiendo dos. Sin commits, ese trabajo desaparece y tu única recuperación es describirlo otra vez de memoria. Con commits, la recuperación es una frase.

Lo que lleva a la parte que nadie le cuenta a los principiantes: no tienes que aprender Git. Tienes que aprender tres frases que decirle a tu agente.

• Haz commit de esto con un mensaje claro.
• ¿Qué ha cambiado desde el último commit?
• Deshaz todo desde el último commit.

Ésa es toda la interfaz durante el primer mes. El agente ejecuta los comandos.

Móntalo así y deja de pensar en ello: crea la cuenta, haz el repositorio privado por defecto, y antes que nada asegúrate de que .env está en .gitignore. Esa única línea es lo que impide que tus claves de API se publiquen la primera vez que hagas push. Las claves se filtran constantemente desde repositorios de principiantes, y se rastrean en cuestión de minutos.

Luego un hábito, que es lo de mayor rendimiento de todo este post: cuando algo funcione, haz commit. No al final del día. En el momento en que funciona.

Con eso basta para empezar. El resto — leer un diff sin leer código, los cuatro tipos distintos de deshacer y cuándo aplica cada uno, qué hacer el día que hagas commit de una clave de API — está en la guía completa.

2. Un modelo, y importa menos de lo que crees

Claude Code, Codex, o un modelo de pesos abiertos que ejecutes tú. Dicho con franqueza: ésta es la decisión que puedes revertir gratis. El repositorio es portable, tus prompts son portables, y nada de lo que construyas queda atado a la herramienta que lo escribió.

Lo que de verdad los separa no son las puntuaciones en benchmarks, es si la herramienta vive dentro de tu proyecto:

La recomendación: elige una herramienta agéntica de pago y quédate en ella un mes. No porque las otras sean peores, sino porque la habilidad que estás construyendo es saber qué pedir y cómo detectar que la respuesta está mal, y esa habilidad se transfiere despacio mientras sigues cambiando de herramienta cada semana.

Sobre open source, con franqueza: es real, es más barato, es privado, y es el primer movimiento equivocado. Te gastarás la primera semana en setup en lugar de en la cosa que querías construir, y los trabajos agénticos largos — muchos ficheros, muchos pasos, sostener el plan hasta el final — son exactamente donde la brecha sigue siendo más ancha. Vuelve a ello en el mes dos, cuando sepas qué estás comparando.

Y elijas la que elijas, la palanca no está en el modelo. Está en lo que el modelo puede ver de tu proyecto, que son las decisiones 4, 5 y 6.

3. Un host, y una sola cuenta si puedes

Vas a necesitar dónde ponerlo. Las dos respuestas obvias son Cloudflare y Vercel, y la pregunta que decide no es el rendimiento.

Es cuántas cuentas quieres sostener.

Cloudflare es el todo-en-uno: hosting, una base de datos (D1), almacenamiento de ficheros (R2), clave-valor, el propio dominio, DNS, enrutado de correo — un login, una factura, un sitio donde están mal las cosas cuando están mal. Para alguien que empieza, esa consolidación vale más que cualquier funcionalidad concreta. El precio es un runtime que no es exactamente Node, así que un puñado de paquetes de npm no correrán ahí, y te enteras al desplegar y no al instalar.

Vercel te da el despliegue más suave que existe si estás en Next.js. El intercambio es que las piezas de datos vienen de socios del marketplace, así que la base de datos es el panel de otro, el almacenamiento es otro más, y acabarás reconectando tres servicios un domingo por la noche intentando recordar cuál tiene la credencial que falla.

Elige Cloudflare salvo que tengas un motivo concreto para estar en Next.js.

Y compra el dominio el primer día, del mismo proveedor. Cuesta unos diez euros, lleva cuatro minutos, y cambia cómo tratas el proyecto. Una cosa con dominio es una cosa que existe.

4. Un stack — elegido por ti, y por escrito

La tentación es dejárselo al modelo. No lo hagas, y el motivo no es que su elección fuera a ser mala.

Es que el modelo elige por conversación. La sesión del lunes elige Next.js. La del miércoles, sin memoria del lunes, elige Vite y React Router. La del viernes añade una biblioteca de componentes que duplica la que ya tienes. Nada falla cuando esto pasa — simplemente acabas con un proyecto que son tres proyectos con una gabardina puesta, y cada sesión futura tiene que adivinar en qué convención está.

Así que: React + Tailwind, y dile al modelo que use shadcn/ui.

Por qué esa combinación concreta, cuando hay montones de otras perfectamente buenas:

• Es la combinación mejor documentada en los datos de entrenamiento de cualquier modelo. Estás eligiendo la región del mapa donde el modelo es más certero y menos inventivo, y eso vale más que cualquier ventaja técnica el primer día.
• Tailwind mantiene el estilo en el marcado, así que cuando dices «haz esta card más compacta», el agente cambia una línea en el fichero que estás mirando en vez de perseguir una hoja de estilos.
• Los componentes de shadcn se copian a tu repositorio, no se instalan como dependencia. Ésta es la parte infravalorada. Cuando pides un cambio en un botón, el agente edita tu botón. Con una biblioteca de componentes tradicional, tiene que pelearse con la API de la biblioteca, y normalmente pierde envolviéndola en tres capas de tontería.

Una excepción, y es común. Si lo que construyes es sobre todo contenido — un sitio, una landing, un blog, un conjunto de documentación, con un pequeño panel de administración pegado — usa Astro en su lugar. Envía casi nada de JavaScript por defecto, las páginas van rápidas sin que hagas nada, y escala hasta ser una aplicación de verdad cuando lo necesitas. Este sitio es Astro.

Skills: cómo dejas de repetirte

Una skill es una carpeta con un fichero SKILL.md dentro que tu agente lee sólo cuando es relevante. Esa última parte es todo el sentido: son instrucciones disponibles sin estar estorbando.

La anatomía es pequeña. Un fichero en .claude/skills/<nombre>/SKILL.md, que empieza con:

---
name: my-design-system
description: Úsala al construir o reestilizar cualquier UI de este proyecto —
  colores, tipografía, espaciado, patrones de componentes.
---

Todo lo que el agente debería saber, en markdown normal.

La línea description es la importante, porque es contra lo que el agente compara para decidir si carga la skill siquiera. Descripción vaga, skill que no dispara nunca.

Dos sitios donde ponerlas: .claude/skills/ dentro de tu proyecto, lo que significa que va commiteada a GitHub y sigue ahí mañana y en tu otra máquina, o ~/.claude/skills/, para cosas que quieres en todos los proyectos que toques. Prefiere la del proyecto — una skill que describe este producto pertenece a este producto.

Para instalar una que te hayan dado: suelta la carpeta dentro, arranca una sesión nueva, y pregunta qué skills tienes disponibles. Si no la lista, la descripción es lo primero que hay que revisar.

Ésa es la forma que tiene. Por qué la descripción es la única parte que siempre se carga, qué va en una skill frente a AGENTS.md, y la manera más rápida de escribir la primera — la guía completa.

(Las skills son una funcionalidad de Claude Code. Si te fuiste con Codex, la palanca equivalente es el fichero AGENTS.md descrito en la sección extra — la misma idea, con una carga menos selectiva.)

La de diseño merece la pena el primer día. Si tienes una idea pero ni marca, ni colores, ni opinión visual todavía, ve a startpow.com, elige lo que te guste, exporta, y escoge la descarga de skill. Suéltala en .claude/skills/. Desde ese momento cada pantalla que construya el agente llega con tus colores, tu tipografía y tu espaciado, sin que los describas otra vez — que es la diferencia entre un producto y una demo, y cuesta unos diez minutos.

5. Algo que recuerde, para que mañana no sea reconstruir

Éste es el fallo del que va esta decisión, y merece la pena ser preciso porque la versión popular es falsa.

El modelo no es malicioso. Es complaciente y rápido, en sitios donde equivocarse sale caro. La base de datos no la tira una IA rebelde; la tira porque una migración estaba rota, tirar la tabla era el camino más corto a un test en verde, y no se le preguntó a nadie. El auth no se reescribe en un acto de sabotaje; se reescribe porque un test fallaba y la comprobación de auth era lo que lo hacía fallar.

Dos capas de defensa, y la primera es gratis:

Los hábitos. Una base de datos de desarrollo que no es la de producción. Credenciales de producción que el agente nunca tiene. Un commit antes de empezar nada. Y la instrucción que casi nadie da — qué no debe tocar. Los modelos son complacientes; harán encantados algo útil que tú no querías.

Las herramientas. Esto es lo que es CommitCycle: el trabajo empieza como una task con un alcance declarado, el agente recibe acceso atado a esa única task y a una única rama y caduca por sí solo, los paths que de verdad harían daño llevan un owner que tiene que decir que sí, y cada task cierra con un registro de lo que se declaró frente a lo que se tocó.

Ahora el límite honesto, que es también la frase más importante de aquí: no elimina la posibilidad. La responsabilidad final siempre es de la persona que aprueba lo que el agente pide. El agente ejecuta; tú consientes. Lo que las herramientas eliminan es la clase de accidente en la que nadie pudo decir que no, porque no se preguntó a nadie — y esa clase son la mayoría.

Si lo quieres: /plugin install commitcycle@commitcycle en Claude Code, o npm i -g commitcycle para la CLI. El board alojado es sólo por invitación mientras esto es pequeño.

6. ¿Y ahora qué? Empieza por la forma, no por la pantalla

Ya tienes las seis piezas. El instinto es pedir constrúyeme la home, y es el primer movimiento equivocado — no porque la home no importe, sino porque es consecuencia de decisiones que aún no has tomado.

La primera pregunta útil es: ¿esto necesita cuentas? Casi todo se ordena en cuatro superficies a partir de ahí.

Si la respuesta honesta es «sobre todo parte pública, admin pequeño», constrúyelo en Astro y no añadas un sistema de autenticación que vas a mantener para un solo usuario. Si es «sobre todo producto», el auth y el modelo de datos son lo primero, porque todo lo demás cuelga de ellos.

Los prompts

Primero, el que no escribe código. Éste es el prompt de más valor de todo el proceso y es el que más gente se salta:

Quiero construir: [descríbelo en tres o cuatro frases, incluyendo para
quién es y por qué pagan, si es que pagan algo].

No escribas código todavía. Entrevístame — hazme las preguntas que
necesites que responda para planificar esto bien, por tandas.

Cuando tengas suficiente, devuélveme:
1. Las pantallas, agrupadas en público / auth / producto / admin
2. El modelo de datos, como lista de entidades y cómo se relacionan
3. Cualquier servicio de terceros que esto necesite y por qué
4. Qué construirías primero, y qué dejarías deliberadamente para
   más adelante

Estás haciendo que el modelo produzca una pregunta, y revisar una pregunta es mucho más barato que revisar trescientas líneas de una respuesta construida sobre un supuesto que nunca viste.

Segundo, los cimientos. Despliega la cosa vacía el primer día — «ponerlo en producción» no debería convertirse nunca en un proyecto aparte más adelante:

Monta el esqueleto del proyecto:
- [Astro | React + Vite], TypeScript, Tailwind, shadcn/ui
- Destino de despliegue: Cloudflare
- Un repositorio Git con un primer commit, subido a GitHub

Deja una página vacía desplegada y dame la URL en vivo antes de añadir
ninguna funcionalidad.

Después escribe AGENTS.md en la raíz recogiendo: el stack y las
versiones, la estructura de carpetas, las convenciones de nombres, los
comandos para ejecutar y compilar, y cualquier cosa que nunca debas
hacer en este proyecto.

No añadas todavía autenticación, base de datos ni ninguna dependencia
más allá de lo anterior.

Tercero, las superficies que necesitan un sistema detrás:

Construye registro y login: alta, inicio de sesión, cierre de sesión,
recuperación de contraseña, verificación de correo.

Usa [el proveedor de auth que elegiste] en vez de hacerlo a mano.
Las pantallas usan nuestros componentes existentes — no introduzcas una
segunda biblioteca de componentes.

Dame también la página de admin más pequeña que liste usuarios, porque
necesito poder ver si esto funciona.

NO toques: pagos, las páginas de marketing, nada bajo [path].
Si te encuentras con una decisión que yo no he tomado — precios,
duración de sesión, qué pasa con las cuentas sin verificar después de
una semana — párate y pregunta en vez de elegir.

Fíjate en las dos líneas que casi nadie escribe: qué no debe tocar, y párate y pregunta en vez de elegir. Esas dos líneas evitan más retrabajo que cualquier cantidad de finura en prompt engineering.

Cuarto, una vez funcione, hazlo tuyo: instala la skill de diseño y pide que se reestilice una pantalla con ella. Revisa ésa. Luego déjala correr con el resto.

7. Historias de usuario, que es donde esto se pone real

Si puedes narrar lo que hace una persona, puedes construirlo. Coge la frase del propio usuario:

Alguien ve un anuncio, aterriza en el sitio, se crea una cuenta, se suscribe a un plan, paga con tarjeta, y su suscripción se activa.

Léela otra vez despacio, porque esa única frase es una especificación. Contiene:

• Una landing a la que apunta el anuncio, que no es la home
• Registro, y por tanto verificación, y por tanto correo que llega de verdad
• Probablemente onboarding, porque una cuenta nueva y vacía es donde la gente se va
• Un proveedor de pagos — Stripe, en la práctica — y un checkout
• Un webhook, porque el pago tiene éxito en los servidores de Stripe y tu aplicación tiene que enterarse
• Entitlement: algún estado que diga que esta cuenta ya es suscriptora
• Feature gating guiado por ese estado, en todos los sitios donde importe
• La ruta de fallo: tarjeta rechazada, pago correcto pero webhook que no llegó, suscripción cancelada a mitad de mes
• Una vista de admin, para que cuando alguien te escriba diciendo que pagó y no se activó nada, puedas mirar

Una frase, nueve elementos de trabajo, y los tres últimos son los que se descubren en producción, por un cliente, si nadie los escribió.

Esto también es trabajo que el modelo hace bien — dale la historia y pregúntale qué implica, y producirá una lista muy parecida a la de arriba. Lo que no puede hacer es recordar la lista el martes que viene. Para eso está un board: cada elemento se convierte en una task con un alcance, una task se convierte en una rama, y la rama cierra con un registro de lo que cambió de verdad.

Esto suena aburrido. Lo es, un poco. Y por no vender de más: tres prompts de verdad pueden darte algo que corre y se ve bien, y el subidón de verlo funcionar es real y merece la pena tenerlo. Ve y tenlo.

Pero la cosa que sigue en pie en el mes tres, la que puedes entregarle a otra persona, la que puedes cambiar sin contener la respiración — ésa la construyó alguien que escribió qué se suponía que tenía que hacer. La consistencia es poco glamurosa y es toda la diferencia.

Pista extra

Cosas pequeñas, en orden aproximado de cuánto arrepentimiento evitan:

• AGENTS.md en la raíz del repositorio. El fichero de mayor retorno que escribirás. Stack, convenciones, comandos, y la lista de cosas que nunca hay que hacer. Toda herramienta agéntica lo lee. El nuestro genera uno por task y lo limpia al entregar, pero uno escrito a mano ya es la mayor parte del valor.
• Dos bases de datos desde el primer minuto. Desarrollo y producción, nunca las mismas credenciales, y el agente sólo tiene la de desarrollo. Ésta es la defensa concreta contra el desastre concreto.
• Los secretos nunca en el repositorio. .env en .gitignore, los valores reales en el almacén de secretos de tu host. Rota cualquier cosa que llegara a commitearse — borrar el fichero no lo quita del historial.
• Despliegues de preview por rama. Tanto Cloudflare como Vercel te dan una URL por rama gratis. Ver el cambio en una URL real antes de que esté en producción vale más que cualquier cantidad de pruebas locales.
• Deja que el agente vea lo que construyó. Capturas, o una herramienta de navegador que pueda manejar. Un agente construyendo UI sin mirarla nunca trabaja a ciegas, y se nota.
• Seguimiento de errores, más exactamente un número de analítica que mires de verdad. Más de uno y no mirarás ninguno.
• Términos y política de privacidad antes de cobrar una tarjeta. Stripe pedirá un sitio funcionando con ambos antes de activar la cuenta, y enterarse de eso el día del lanzamiento es un mal día.
• Conoce tu restauración, no sólo tu copia de seguridad. Una copia sin probar es una creencia, no una copia.
• Un fichero de decisiones. Tres líneas por decisión: qué, por qué, qué descartaste. Seis semanas después es lo único que separa que vuelvas a litigarlo todo con un modelo que no estaba allí.
• Espera que el modelo cueste más que el hosting. Esa proporción es correcta y no es señal de que lo estés haciendo mal.

Todo el setup de arriba es una tarde. Lo que compra es que la segunda semana sea una continuación en vez de un proyecto de arqueología — y si quieres los hábitos que van encima, ése es el post de la primera semana.