Resumen ejecutivo

• Vibe coding funciona para prototipar rápido, pero sin un método el prototipo se convierte en una caja negra que nadie quiere tocar. La solución no es dejar de usar IA: es ponerle carriles.

• Este tutorial propone un flujo de un día en 4 etapas: prompt con spec → scaffold con Vite + TypeScript → tests mínimos con Vitest y Testing Library → review humano antes de cada commit.

• Incluye una plantilla de prompt, los comandos para arrancar el proyecto, qué testear (y qué no) y un checklist de revisión para no acumular deuda técnica desde el primer día.

El término lo popularizó Andrej Karpathy en un post en X donde describía "un nuevo tipo de programación" en el que te entregás a las vibras y "te olvidás de que el código existe". Prendió porque es real: con un asistente podés tener una app andando en horas. El problema aparece al día siguiente, cuando querés sumar una feature y no sabés qué hace la mitad de los archivos. Ya hablamos de los riesgos de arquitectura en otras notas del blog; acá vamos a lo práctico: cómo hacerlo bien con React, paso a paso, para que tu prototipo de un día pueda convertirse en un producto sin reescribirlo de cero.

El ejemplo: una app de gastos compartidos

Vamos a prototipar una app para dividir gastos entre amigos: cargás quién pagó qué y la app calcula cuánto le debe cada uno a quién. Es chica, pero tiene formularios, estado, lógica de negocio y una vista de resultados. Podés cambiarla por tu propia idea.

Paso 1: escribí la spec antes del prompt

El error más común es escribir "haceme una app de gastos" y dejar que el modelo decida stack, estructura y alcance. Antes, dedicá 30 minutos a una spec de una página:

• Problema y usuario: "Grupos de amigos que comparten gastos de un viaje y no quieren hacer cuentas a mano".

• 3 historias de usuario: agregar participantes; cargar un gasto con quién pagó y entre quiénes se divide; ver el resumen de deudas.

• Criterios de aceptación: por ejemplo, "si tres personas comparten un gasto de $9.000 pagado por una, las otras dos le deben $3.000 cada una".

• Fuera de alcance: login, backend, múltiples monedas. Escribirlo evita que el asistente lo agregue "por las dudas".

Esos criterios de aceptación después se convierten, casi literalmente, en tus tests.

Plantilla de prompt base

Usá un prompt que fije las decisiones y le pida al asistente un plan antes de escribir código:

• Contexto: pegá la spec completa.

• Stack fijo: "React con TypeScript sobre Vite, sin librerías de estado externas, estilos con CSS Modules. No agregues dependencias sin pedirme permiso".

• Estructura: "La lógica de negocio va en funciones puras dentro de src/lib, separada de los componentes".

• Forma de trabajo: "Primero proponé un plan en pasos chicos. Implementá un paso por vez y esperá mi confirmación".

Guardá estas reglas en un archivo de instrucciones del repo para no repetirlas en cada sesión.

Paso 2: scaffold con Vite y TypeScript

La documentación oficial de React recomienda frameworks como Next.js para apps nuevas y deja la opción de arrancar desde cero con Vite; para un prototipo de un día sin backend, Vite es lo más liviano. Según la guía oficial de Vite, podés crear el proyecto con una plantilla en un solo comando:

npm create vite@latest gastos -- --template react-ts

Después: cd gastos, npm install, npm run dev, y apenas lo veas funcionando, git init y un primer commit. Generá el scaffold con la herramienta oficial en lugar de pedirle al asistente la configuración a mano: es más rápido y evita configuraciones inventadas.

Definí la estructura antes de la primera feature: src/lib para la lógica pura (el cálculo de deudas), src/components para la interfaz y un archivo de tipos compartidos. Si te interesa ver cómo se aplica esto a un MVP más grande, mirá cómo usar vibe coding para crear un MVP en días.

Paso 3: iterá en pasos chicos, con tests mínimos

Acá está la diferencia entre un prototipo descartable y uno que podés hacer crecer. La regla: una historia de usuario por iteración, un test por historia y un commit por iteración.

Instalá el entorno de testing

Vitest es un framework de testing que funciona sobre Vite y lee su misma configuración, así que se integra sin fricción. Para probar componentes, sumá React Testing Library y un entorno de DOM:

npm install -D vitest @testing-library/react @testing-library/dom jsdom

Agregá "test": "vitest" a los scripts de package.json y configurá el entorno jsdom en la sección test de tu configuración de Vite.

Qué testear en un prototipo (y qué no)

• Siempre: la lógica de negocio. La función que calcula las deudas es el corazón de la app. Escribí los tests a partir de los criterios de aceptación de tu spec, idealmente antes de pedirle la implementación al asistente. Si el modelo genera código que no pasa tus tests, lo sabés al instante.

• Un test de componente por historia: por ejemplo, "al cargar un gasto, aparece en la lista". Testing Library parte de un principio útil: cuanto más se parecen tus tests a la forma en que se usa el software, más confianza te dan. Buscá elementos por su texto o etiqueta, como lo haría una persona.

• No todavía: estilos o tests que repiten la implementación; en un prototipo cambian demasiado.

Si el asistente escribe los tests, revisalos vos contra la spec: un test que verifica lo que el código hace y no lo que debería hacer no te protege de nada. Para profundizar en herramientas, tenés nuestra guía de testing de software con IA.

Paso 4: review antes de cada commit

Aceptar cambios sin leerlos es exactamente lo que convierte al vibe coding en deuda técnica. Antes de cada commit, recorré el diff con este checklist:

1. ¿Entiendo cada archivo que cambió? Si no podés explicar una función en una frase, pedile al asistente que la simplifique o que te la explique.

2. ¿Agregó dependencias? Cada paquete nuevo suma mantenimiento y riesgo de seguridad.

3. ¿Respeta la estructura? La lógica sigue en src/lib, no mezclada dentro de los componentes.

4. ¿Hay atajos de TypeScript? Tipos any, aserciones forzadas o reglas desactivadas suelen esconder problemas.

5. ¿Maneja casos borde y evita duplicación? Montos vacíos, participantes repetidos, componentes que crecieron demasiado.

6. ¿Pasan los tests? Corré npm test y no commitees en rojo.

Sumá una pasada extra: pedile al asistente una revisión crítica del diff ("buscá bugs, duplicación y problemas de accesibilidad"). No reemplaza tu lectura, pero ayuda.

Cierre del día: dejá el prototipo listo para crecer

• README corto: qué hace, cómo correrlo, qué decisiones tomaste.

• Lista de deuda conocida: todo lo que resolviste rápido a propósito (sin persistencia, sin validaciones completas). Deuda anotada es deuda gestionable.

• Decisión explícita: ¿este prototipo se tira después de validar la idea o evoluciona? Si evoluciona, el próximo paso suele ser migrar a un framework como Next.js y sumar tests end-to-end con Playwright.

Si tu prototipo arranca desde un diseño, el flujo es el mismo; mirá lo que contamos sobre Figma y su compra de una app de vibe coding.

Cursos recomendados de Coderhouse

• Curso de React JS: para entender componentes, hooks y estado, y poder revisar con criterio lo que genera la IA.

• Carrera de Desarrollo Frontend: la ruta completa de HTML, CSS y JavaScript a React si estás empezando.

• Curso de AI Engineering: si tu próximo prototipo integra modelos de lenguaje, RAG o agentes.

• Carrera de Desarrollo Full Stack: para sumar backend y persistencia.

CTA: elegí una idea chica, escribí hoy su spec de una página con 3 historias y sus criterios de aceptación, y bloqueá un día en tu agenda para prototiparla con este flujo.

Preguntas frecuentes

¿Puedo hacer vibe coding con React sin saber programar? Podés generar un prototipo, pero no vas a poder revisarlo ni mantenerlo. Conocer los fundamentos de React y JavaScript es lo que te permite detectar errores y decidir qué cambios aceptar.

¿Conviene usar Vite o Next.js para prototipar? Para un prototipo sin backend, Vite es más liviano y rápido de arrancar. Si necesitás rutas del lado del servidor, SEO o vas directo a producción, la documentación de React recomienda empezar con un framework como Next.js.

¿Cuántos tests necesita un prototipo? Pocos y bien elegidos: los de la lógica de negocio y uno de componente por historia. El objetivo es cambiar código sin miedo, no una cobertura alta.

¿Qué hago si el asistente genera código que no entiendo? No lo aceptes. Pedile que lo explique paso a paso o que lo reescriba de forma más simple; si sigue sin cerrar, escribí esa parte vos.