El flujo de trabajo de vibe coding: de la idea al deploy con Claude Code (2026)

¿Qué es vibe coding? (repaso rápido)

Vibe coding es una forma de construir software en la que describes lo que quieres en lenguaje sencillo, dejas que la IA genere el código y luego juzgas el resultado por si funciona como esperabas, en lugar de teclear cada línea a mano. Andrej Karpathy acuñó el término a principios de 2025, y rápidamente se volvió una forma común de trabajar tanto para indie hackers como para desarrolladores profesionales. En resumen: tú eres quien decide y revisa, y la IA es quien hace el trabajo.

Lo único que evita que el vibe coding se convierta en un caos es un flujo de trabajo, no disparar prompts por impulso. Si todavía no dominas lo básico, lee primero qué es vibe coding y luego vuelve aquí para aprender un proceso repetible. Este artículo se centra en el "cómo" de la programación asistida por IA de principio a fin.

Resumen del flujo de vibe coding: 6 pasos de la idea al deploy

El flujo de trabajo de vibe coding completo cabe en seis pasos, cada uno con una salida clara y una "puerta de decisión": el punto en el que te detienes y decides si avanzas o vuelves a corregir algo. Esas puertas de decisión son justo lo que mantiene a la IA en el carril, en lugar de irse a la deriva con el "vibe".

Estos seis pasos encajan en un modelo mental más ágil: el framework brainstorm -> plan -> cook -> ship. El brainstorm cubre los pasos 1-2, el plan es el paso 3, el cook es el paso 4 y el ship cierra los pasos 5-6. Ilustro el flujo con Claude Code: una CLI agéntica que puede leer un repositorio, editar varios archivos y ejecutar comandos en una sola pasada (documentación de Claude Code, Anthropic), pero los mismos principios valen para Cursor o Copilot.

Paso 1 — Aclarar la idea y hacer brainstorm

El error más común es abrir una terminal y ponerse a teclear un prompt de inmediato. El resultado es que la IA adivina lo que quisiste decir, adivina mal, y pasas medio día arreglando cosas que nunca debieron existir. El Paso 1 frena el AI slop de raíz: tienes que saber lo que quieres antes de decirle a la IA qué hacer.

Antes de teclear un solo prompt, responde cuatro preguntas:

• Resultado (Outcome): ¿a quién ayuda este producto, y a hacer qué? Dilo en una frase.
• Restricciones (Constraints): qué lenguaje/stack, dónde se ejecuta, si necesita funcionar sin conexión, tu presupuesto de tiempo.
• No-objetivos (Non-goals): lo que deliberadamente no vas a hacer en esta versión (crucial para que la IA no "invente" extras).
• Criterios de "listo": dónde miras para saber que llegaste — por ejemplo, "el usuario puede agregar un gasto y ver que el total se actualiza".

Ejemplo ilustrativo: la idea "un control de gastos personal". Resultado: ayudar a una persona a registrar gastos diarios rápido y ver un total mensual. Restricciones: página web estática, corre en el navegador, guarda los datos localmente, se puede construir en una tarde. No-objetivos: sin login, sin sincronización en la nube, sin gráficas sofisticadas. Criterios de listo: puedes agregar un gasto y ver la lista y el total mensual. Esas cuatro respuestas son la "constitución" que todo prompt posterior tiene que seguir.

Paso 2 — Escribir un spec/brief para la IA (no solo un "prompt vago")

Este es el paso que marca la mayor diferencia en calidad. Un prompt vago como "hazme una app de gastos" te da un resultado al azar. Un spec estructurado te da un resultado que se queda cerca de lo que quisiste decir. Escribes el spec una vez y lo reutilizas tanto para planear como para el cook.

Aquí tienes una plantilla de spec/brief que puedes copiar y pegar y rellenar (ponla en un archivo SPEC.md o CLAUDE.md en la raíz del repositorio para que Claude Code la lea automáticamente):

# SPEC - Expense tracker

## Goal
A single-page web app that lets an individual quickly log expenses and view a monthly total.

## User flow
1. The user enters an amount + category + date, then clicks "Add".
2. The expense appears in the list, newest on top.
3. The current month's total shows at the top of the page and updates automatically.

## Sample data
- { amount: 12.50, category: "Food", date: "2026-08-09" }
- { amount: 30.00, category: "Transit", date: "2026-08-08" }

## Technical constraints
- Plain HTML + CSS + JavaScript, no framework.
- Persist with localStorage, no backend.
- Works when you open index.html directly.

## Test criteria (definition of "done")
- Add an expense -> it appears in the list.
- Reload the page -> the data is still there.
- The monthly total matches the entered expenses.

## Non-goals
- No login, no cloud sync, no charts.

Cuando el riesgo es bajo (un prototipo, una herramienta interna, una página estática) puedes hacer vibe con bastante libertad. Pero cuando el riesgo es alto — datos de usuario, lógica que maneja dinero, integraciones de terceros — cambia a desarrollo guiado por spec: un spec más detallado, criterios de aceptación estrictos y una IA que tiene que ceñirse a ellos en lugar de improvisar. Cuanto más claro el spec, menos AI slop recibes.

Paso 3 — Planear y dividir

No le digas a la IA que "escriba toda la app de una sola vez". Cuanto más tiene que sostener el modelo en la cabeza a la vez, más probable es que se salte cosas, se contradiga o invente APIs que no existen. En vez de eso, pídele a la IA que planee antes de programar, y luego tú revisas ese plan.

En Claude Code, un buen prompt de planeación se ve así:

Read SPEC.md. DO NOT write code yet.
Propose a plan: list the modules to build,
the order to implement them, and for each module
spell out its input/output. Then stop and wait for my approval.

Para la app de ejemplo, un plan razonable la divide en módulos pequeños para que revises el "vibe" de cada pieza:

1. Esqueleto HTML + formulario de entrada — construir la interfaz, aún sin lógica.
2. Guardar y leer localStorage — agregar/leer datos, aún sin totales.
3. Renderizar la lista — mostrar los gastos guardados.
4. Calcular el total mensual — la lógica de suma + actualizar en cada alta.

Dividir el trabajo tiene tres beneficios: puedes aprobar cada paso, cuando algo se rompe el espacio de búsqueda es estrecho, y mantienes el control en cada puerta de decisión en lugar de recibir de vuelta un bloque enorme de código difícil de revisar.

Paso 4 — Cook: deja que la IA escriba código un módulo a la vez

"Cook" es cuando la IA de verdad escribe código según el plan aprobado. Con Claude Code, una sesión típica de cook va así: el agente lee el repositorio y el SPEC.md -> edita o crea archivos para el módulo actual -> ejecuta comandos/pruebas -> reporta el resultado -> espera a que apruebes pasar al siguiente módulo. Trabajas un módulo a la vez; nunca "sueltas" la app entera.

El prompt de cook para el primer módulo, atado al plan:

Implement module 1 from the plan: the HTML shell + input form
(amount, category, date, Add button). No save logic yet.
When you're done, briefly describe what you created.

Algunos consejos de checkpoint mientras haces el cook:

• Ejecútalo de inmediato después de cada módulo en vez de esperar hasta el final: atrapar la desviación temprano es mucho más barato.
• Lee el diff que la IA acaba de producir. Si tocó un archivo fuera del alcance del módulo, pregunta por qué.
• Mete mano tú cuando la IA repita el mismo error dos veces seguidas: arreglar un puntito directamente suele ser más rápido que reexplicarlo con palabras.
• Mantén los commits pequeños, uno por módulo, para que sea fácil revertir si un módulo posterior rompe uno anterior.

Paso 5 — Probar, revisar y evitar el AI slop

Código que corre no es lo mismo que código bueno. Este paso es donde separas un producto de un montón de "AI slop": código que se ve bien pero está inflado, es difícil de mantener o está silenciosamente equivocado. La regla de oro: no publiques lo que no entiendes.

Una lista de revisión rápida después de cada sesión de cook:

• Corre las pruebas contra los criterios de "listo" que escribiste en el spec. Para la app de ejemplo: agrega un gasto, recarga la página, revisa el total mensual.
• Lee y entiende el código, no solo lo hojees. Si hay una parte que no puedes explicar, pídele a la IA que la explique o que la reescriba más simple.
• Caza el código muerto: funciones que nadie llama, bibliotecas instaladas pero sin usar, manejo de casos que no pueden ocurrir.
• Revisa los bordes: entrada vacía, números negativos, fechas mal formateadas — la IA suele olvidar estos casos.

Para profundizar en los "olores" que la IA tiende a producir y en cómo frenarlos, mira cómo evitar el AI slop. Cuando las pruebas se ponen rojas o el código se comporta raro, hay un proceso metódico de depuración en depurar con IA — no pegues solo el error y digas "arréglalo", dale contexto a la IA y haz que diagnostique la causa primero.

Paso 6 — Ship: despliega un producto que funciona

Muchos artículos de vibe coding se detienen en el prototipo. Pero el "ship" es cuando la idea se vuelve un producto que otras personas pueden usar de verdad. Pasar del prototipo a un deploy real implica unas cuantas cosas:

1. Build: si hay un paso de empaquetado (bundler, framework), corre el build y arregla los avisos antes de llevarlo a ningún lado.
2. Configurar env: saca las claves/variables de entorno del código; no hagas commit de secretos en el repositorio.
3. Hosting: elige el lugar correcto para ejecutarlo — una página estática se sube a un hosting estático en unos minutos; una app con backend necesita una plataforma que soporte un servidor.
4. Docs: pídele a la IA que escriba un README a partir del propio spec + código — cómo ejecutarlo, cómo configurarlo, limitaciones actuales.

Una nota honesta para que no te engañes: un buen prototipo es una herramienta para tomar decisiones, no una versión de producción en miniatura. Te ayuda a confirmar si la idea vale la pena. Una vez que lo tengas claro, dedica tiempo a endurecer el núcleo (seguridad, manejo de errores, pruebas) antes de abrirlo a muchos usuarios reales.

Un ejemplo real: construir una app pequeña por los 6 pasos

Juntándolo todo, así recorre el control de gastos el flujo completo. Este es un recorrido que hice con Claude Code, presentado paso a paso para que te imagines el ritmo del trabajo.

• Paso 1 (idea): fijar resultado/restricciones/no-objetivos/criterios de listo como arriba — web estática, localStorage, una tarde.
• Paso 2 (spec): guardar la misma plantilla SPEC.md de arriba en la raíz del proyecto.
• Paso 3 (plan): pedirle a Claude Code que lea el spec y proponga 4 módulos; aprobar el orden de implementación.
• Paso 4 (cook): hacer un módulo a la vez. Después del módulo del "total mensual", ejecutarlo y ver que el total se actualiza correctamente cuando se agrega un gasto nuevo.
• Paso 5 (probar y revisar): correr los tres criterios de "listo"; atrapar un bug de caso límite — escribir un número con coma descuadra el total — y pedirle a la IA que normalice la entrada antes de sumar.
• Paso 6 (ship): como es una página estática, basta con subir la carpeta a un host estático; pedirle a la IA que genere un README con instrucciones de ejecución.

El resultado: una app de una página que agrega, muestra y suma gastos, con datos que sobreviven a una recarga — construida con calma en una tarde. Lo que importa no es que la app sea "impresionante", sino que el flujo sea repetible para el próximo proyecto.

Cuando el vibe coding falla (una sección honesta sobre límites)

Vibe coding no es un martillo para todo clavo. Hay áreas en las que deberías ir más despacio, cambiar a un trabajo más estricto guiado por spec, o escribirlo a mano:

• Autenticación y autorización: un bug pequeño puede dejar tus datos totalmente al descubierto. No hagas "vibe" en la parte de login/control de acceso.
• Pagos y facturación: un error aquí significa dinero real perdido o confianza perdida. Esto necesita un spec estricto, pruebas minuciosas y una revisión manual.
• Datos sensibles: información personal, médica, financiera — los errores traen consecuencias legales.
• Sistemas grandes y fuertemente acoplados: cuando cambiar un punto afecta a muchos otros, la IA rompe con facilidad cosas que no puede "ver".
• Cuando no puedes leer el código generado: si no puedes revisarlo, no puedes responsabilizarte de él — es una señal para parar.

Dos riesgos silenciosos que conviene recordar: alucinación (la IA inventa APIs, funciones o resultados que no existen) y deuda técnica (código que hoy corre pero acumula enredos que hacen el mañana más difícil). Ambos se mantienen a raya con esas mismas puertas de decisión en cada paso — no con confianza ciega en la salida.

Acelerar el flujo con un kit ya hecho (AgentKit)

Los seis pasos de arriba corren más rápido y con más fiabilidad cuando cada uno tiene una herramienta hecha a medida lista — en lugar de que tú inventes un prompt de brainstorm, armes una plantilla de spec a mano y empujes a la IA a planear cada vez. Ahí es donde los kits ya hechos de skill/subagent/workflow para Claude Code se ganan su lugar.

Nota: AgentKit aquí significa el kit para Claude Code (agentkit.best, la CLI ak), que es distinto del AgentKit de OpenAI. El Engineer Kit — 20% de descuento, ahora $79.20 reúne más de 60 skills y más de 30 workflows que cubren justo los pasos de este proceso (brainstorm, plan, cook, test, code review) por $79.20 — la página no indica ninguna cuota recurrente, además de garantía de devolución y actualizaciones de por vida. Si quieres ver qué skill encaja en qué paso, lee la reseña del Engineer Kit antes de decidir. Un kit no corre el flujo por ti — solo quita el andamiaje repetitivo que, de otro modo, reconstruirías cada vez.

Preguntas frecuentes (FAQ)

¿Cuántos pasos tiene el flujo de trabajo de vibe coding?

El flujo tiene 6 pasos repetibles: aclarar la idea y hacer brainstorm, escribir un spec/brief para la IA, planear y dividir el trabajo, cook (dejar que la IA programe un módulo a la vez), probar y revisar para evitar el AI slop, y ship (desplegar el producto). Cada paso tiene una puerta de decisión para que revises antes de avanzar.

¿Hay que saber programar para hacer vibe coding?

Puedes empezar sin ser un programador fuerte, pero para publicar un producto confiable necesitas poder leer y entender el código que genera la IA. La regla es: no publiques lo que no entiendes. Cuanto más código puedas leer, mejor revisas y más bugs silenciosos evitas.

¿En qué se diferencia el vibe coding de la programación tradicional?

En la programación tradicional tecleas cada línea; en el vibe coding describes lo que quieres en lenguaje sencillo para que la IA lo genere, mientras tú diriges y das el visto bueno. Tu papel pasa de "quien escribe" a "quien decide y revisa".

¿Qué herramienta usar para vibe coding?

Claude Code encaja en un flujo agéntico de principio a fin porque lee el repositorio, edita varios archivos y ejecuta comandos en una pasada. Cursor y GitHub Copilot también pueden, y son fuertes en las sugerencias dentro del editor. Elige según tus hábitos; el flujo de 6 pasos aplica a los tres.

¿Se puede desplegar a producción un prototipo hecho con vibe coding?

Sí, para productos pequeños y de bajo riesgo. Pero un buen prototipo es una herramienta para decidir, no una versión de producción en miniatura. Antes de abrirlo a muchos usuarios, endurece la seguridad, el manejo de errores y las pruebas en el núcleo.

¿Cómo evitar el AI slop al hacer vibe coding?

Escribe un spec claro desde el principio, divide el trabajo en piezas pequeñas y revisa cada módulo: corre pruebas contra los criterios de "listo", lee y entiende el código en vez de hojearlo, borra el código muerto y revisa los casos límite. No publiques nada que no puedas explicar.

Conclusión + próximos pasos

El flujo de trabajo de vibe coding no es magia — es una disciplina de seis pasos que te deja usar IA sin perder el control: idea -> spec -> plan -> cook -> test -> ship, con una puerta de decisión en cada etapa para frenar el AI slop. Tu siguiente paso depende de lo que necesites: si quieres un spec más estricto para un proyecto de alto riesgo, lee desarrollo guiado por spec; si quieres el modelo mental ágil, mira brainstorm -> plan -> cook -> ship; y para mantener tu código limpio, aprende cómo evitar el AI slop.