Para hacer vibe coding, describes en lenguaje natural lo que quieres a un agente de programación, dejas que escriba y ejecute el código, compruebas tú mismo el resultado y sigues guiándolo con mensajes cortos. Hacerlo con seguridad significa añadir algo de estructura alrededor de ese ciclo: una spec corta, pasos pequeños, tests, un commit de git tras cada paso que funcione y una revisión antes de que nada salga en vivo.
El término viene del post de Andrej Karpathy de febrero de 2025 sobre dejar que la IA escriba el código mientras tú «olvidas que el código siquiera existe»; el diccionario Collins lo eligió después como palabra del año 2025. Para la definición, la historia y los riesgos, consulta qué es el vibe coding. Este artículo trata del cómo.
El flujo de un vistazo
| Paso | Qué haces | Qué obtienes |
|---|---|---|
| 1. Idea | Escribe un párrafo: para quién es y qué hace | Un alcance al que puedes decir que no |
| 2. Spec | Pide al agente que lo convierta en un plan corto | Una lista de tareas pequeñas y ordenadas |
| 3. Pasos pequeños | Una tarea por prompt | Cambios lo bastante pequeños para comprobarlos |
| 4. Tests | Pide tests para lo que importa | Una forma de saber que sigue funcionando |
| 5. Commit | git commit tras cada paso que funcione | Un punto seguro al que volver |
| 6. Revisión | Lee el diff, o haz que lo lea otro modelo | Menos sorpresas después |
| 7. Despliegue | Publica en un host con builds de vista previa | Un enlace en vivo que puedes compartir |
Los pasos parecen obvios escritos. Saltárselos es lo que convierte una tarde divertida en un fin de semana de «hace una hora funcionaba».
Paso 1: empieza con una idea pequeña
Escribe la idea en unas pocas frases antes de abrir ninguna herramienta. Nombra al usuario, lo único que la app debe hacer y qué queda fuera del alcance de la primera versión.
Una página donde mi club de corredores registra las distancias semanales. Los miembros inician sesión con un enlace mágico, añaden una carrera y ven una clasificación del mes. Sin pagos, sin app móvil, sin panel de administración en la v1.
Esa última frase es la más importante. A los agentes les encanta construir funciones que no pediste; una lista clara de «no en v1» mantiene el proyecto lo bastante pequeño para terminarlo.
Paso 2: conviértela en una spec corta
Todavía no pidas la app. Pide un plan:
Lee esta idea. Propón un stack, una estructura de carpetas y una lista numerada de 6-10 tareas pequeñas para construir la v1. Cada tarea debe poder hacerse en una sesión y probarse por separado. No escribas código todavía.
Lee el plan y discútelo. ¿El stack se puede alojar gratis? ¿Alguna tarea son en realidad tres? Guarda la versión final como SPEC.md (o PLAN.md) en el repositorio para que cualquier sesión posterior pueda leerla. Si usas más de un agente, también ayuda un CLAUDE.md o AGENTS.md corto con los comandos y las reglas; la programación agéntica funciona mejor cuando el agente tiene siempre el mismo contexto.
Paso 3: construye en pasos pequeños
Ahora toma la tarea 1 y solo la tarea 1:
Haz la tarea 1 de SPEC.md: configura el proyecto y una página de inicio que diga «Hello». Ejecútalo y dime la URL.
Luego ábrelo, compruébalo y pasa a la tarea 2. Un buen ritmo es una tarea, una comprobación, un commit. Si un paso produce más de unos cientos de líneas de cambios, probablemente era demasiado grande; pide al agente que lo divida la próxima vez.
Cuando algo se rompa, pega el error exacto, no una descripción. «No funciona» hace que el agente adivine; el stack trace completo normalmente no.
Paso 4: pide tests para lo que importa
No necesitas el 100 % de cobertura en un proyecto personal. Sí necesitas tests en las partes que dolerían si se rompieran en silencio: las cuentas de la clasificación, el flujo de inicio de sesión, cualquier cosa que toque dinero o datos.
Añade tests para la clasificación mensual: empates, un miembro sin carreras, carreras el último día del mes. Ejecútalos y muéstrame la salida.
Pide al agente que ejecute los tests y muestre la salida, no solo que los escriba. Así, cuando cambies algo más adelante, «ejecuta los tests» será tu comprobación de seguridad de una línea.
Paso 5: haz commit tras cada paso que funcione
Git es el botón de deshacer del vibe coding. Tras cada paso que funcione:
git add -A
git commit -m "Add monthly leaderboard with tests"O simplemente dile al agente: «Haz commit de esto con un mensaje corto.» Cuando un cambio posterior se tuerza, git diff muestra qué cambió y git restore . (o un reset al último commit) te devuelve al punto anterior. Es mejor que pedirle al agente que arregle su propio arreglo por cuarta vez, lo que tiende a apilar un parche sobre otro.
Paso 6: revisa antes de salir en vivo
El vibe coding funciona porque no lees cada línea mientras construyes. Antes de desplegar, alguien tiene que hacerlo. Como mínimo:
- Echa un vistazo al diff de todo lo ocurrido desde el último despliegue.
- Pide a un segundo agente o modelo que lo revise en busca de bugs y problemas de seguridad, sin el historial de chat del primer agente. Un lector nuevo detecta lo que el autor no ve.
- Recorre la app tú mismo en un móvil y en un portátil.
La guía de revisión de código con IA profundiza en qué buscar y cómo configurarlo.
Paso 7: despliega
Para la mayoría de los proyectos web hechos con vibe coding, un host que compila desde un repositorio de GitHub es el camino fácil: Vercel, Netlify o Cloudflare Pages para sitios estáticos y frameworks como Next.js o Astro. Haz push a una rama, obtén un enlace de vista previa, compruébalo y luego fusiona para desplegar. Guarda los secretos en la configuración de entorno del host, nunca en el repositorio.
Elegir una herramienta
| Tipo | Ejemplos | Bueno para |
|---|---|---|
| Agentes de terminal | Claude Code, Codex, Gemini CLI | Proyectos completos en tu máquina, ejecutar comandos, repositorios reales |
| Agentes de editor | Cursor | Mantenerte cerca del código mientras la IA edita |
| Creadores de apps en el navegador | Varios creadores alojados | Una demo rápida con hosting incluido |
Los agentes de terminal y de editor te dejan un repositorio de código normal que es tuyo; los creadores alojados son más rápidos de empezar pero guardan el código en su plataforma. Si dudas, empieza con un agente de terminal, como Claude Code, y úsalo para un proyecto pequeño entero antes de probar otros.
Prompts que funcionan
Los buenos prompts de vibe coding comparten una forma: un objetivo, las restricciones y cómo comprobarlo.
| En lugar de | Prueba |
|---|---|
| «Constrúyeme un tracker de hábitos» | «Haz la tarea 3 de SPEC.md: el formulario de añadir hábito. Valida que el nombre no esté vacío. Ejecuta los tests al terminar.» |
| «Está roto, arréglalo» | «Al pulsar Save aparece este error: (pegar). Encuentra la causa antes de cambiar código y luego explica el arreglo en dos frases.» |
| «Haz que se vea mejor» | «Iguala los espacios y tamaños de fuente de esta captura. No cambies el layout en móvil.» |
| «Añade login» | «Añade login con enlace mágico usando la librería de auth de SPEC.md. No guardes contraseñas. Lista todos los archivos que cambiaste.» |
Tres frases merece la pena reutilizar:
- «No escribas código todavía.» Para planes e investigaciones.
- «Ejecútalo y muéstrame la salida.» Para que veas pruebas, no afirmaciones.
- «Lista los archivos que cambiaste.» Para que el diff no tenga sorpresas.
Cuándo dejar de vibrar
El vibe coding es genial para prototipos, herramientas internas y proyectos personales. Ve más despacio y lee tú mismo el código, o busca a alguien que sepa, cuando el trabajo toque:
- Logins y permisos. Una comprobación omitida expone los datos de todos.
- Pagos. Los webhooks, los reembolsos y los casos límite necesitan tests reales.
- Datos personales. A la ley de privacidad no le importa quién escribió el código.
- Migraciones de base de datos. Un
DROPo unUPDATEsinWHEREes difícil de deshacer en producción. - Todo lo público con usuarios reales. Límites de tasa, validación de entradas, gestión de secretos.
Otra señal: si le has pedido al agente que arregle el mismo bug tres veces y sigue volviendo, para. Vuelve al último buen commit, describe el problema desde cero o lee tú mismo esa parte del código.
Construye algo
Cada una de estas guías sigue el mismo flujo en un proyecto concreto:
- Crear un sitio web con IA
- Crear un MVP de SaaS con IA
- Crear una app móvil con IA
- Crear una extensión de Chrome con IA
- Crear un bot de Telegram con IA
- Crear una automatización o un scraper con IA
- Crear un dashboard de datos con IA
- Crear una tienda online con IA
- Hacer un juego con IA
Hacerlo con AgentVera
Todo lo anterior funciona con una terminal y git. AgentVera ejecuta tus agentes de programación (Claude Code, Codex, Gemini CLI y otros, con tus propios logins) uno al lado de otro en terminales reales, y añade algunas redes de seguridad alrededor del mismo ciclo:
- Deshacer por turno. Los checkpoints toman una instantánea de la carpeta de trabajo al inicio de cada turno, así que puedes deshacer un turno desde el menú del panel, y deshacer el deshacer. Es un paso atrás más rápido que un git reset, no un sustituto de los commits.
- Revisión automática. Con la revisión de código activada en los ajustes del proyecto, un modelo de Claude que eliges lee los cambios al terminar un turno e informa de los hallazgos con su gravedad y enlaces archivo:línea; puedes devolvérselos al agente.
- Comprobar contra lo que pediste. AgentVera Verify (Pro y Team) extrae los criterios de aceptación de tu mensaje y, al terminar el turno, un verificador aparte ejecuta tests y marca cada criterio como correcto o fallido con evidencias.
- Comprobación de migraciones. DB Guard analiza las migraciones nuevas al final de un turno en busca de sentencias arriesgadas como
DROPoUPDATEsinWHERE. - Vistas previas. Los entornos de vista previa dan a cada rama su propia dirección local y pueden capturar pantallas en móvil, tablet y escritorio.
- Un solo sitio para aprobar. La bandeja de revisión reúne el trabajo terminado de todos los agentes para que lo apruebes o lo devuelvas con una nota.
Lista de comprobación
- La idea cabe en un párrafo, con una lista «no en v1».
- Hay un SPEC.md corto con tareas numeradas en el repositorio.
- Una tarea por prompt; cada una comprobada antes de la siguiente.
- Hay tests para las partes que dolerían si se rompieran.
- Un commit tras cada paso que funciona.
- El diff se revisó antes de desplegar, idealmente por un modelo nuevo y una persona.
- Los secretos están en variables de entorno, no en el repositorio.
- Logins, pagos, datos personales y migraciones tuvieron una lectura humana cuidadosa.
Conclusión
El vibe coding ya es una forma real de construir software, no solo un chiste sobre ello. La diferencia entre un prototipo que te quedas y uno que tiras rara vez es el modelo; es si trabajaste en pasos pequeños, hiciste commit a menudo, probaste lo importante y revisaste antes de publicar. Deja las vibras para construir y la disciplina para los bordes.