Construí software con IA (Cursor, v0, Claude Code)

Vibe coding es construir software real diciéndole a la IA qué querés, en lenguaje natural, en vez de escribir cada línea a mano. En 2026 las herramientas dejaron de ser un juguete: podés levantar una app que funciona en una tarde. Pero acá está la parte que nadie te aclara: dirigir bien a la IA es una habilidad, y la diferencia entre un prototipo que sirve y un pozo de código que no entendés está en el flujo de trabajo, no en la herramienta. Esta guía es para que construyas dirigiendo, no rezando.

Las herramientas y cuándo usar cada una

No hay una que gane siempre. Cada una es fuerte en una parte del trabajo:

• v0 (de Vercel) genera interfaz. Le describís una pantalla y te devuelve componentes React con Tailwind, listos para pegar. Brillante para el front, no para la lógica del backend.
• Lovable / Bolt arman la app entera desde cero: front, base de datos y login, todo desde una descripción en texto. Lo más rápido para pasar de idea a prototipo que anda. Ambos exportan código estándar que después seguís donde quieras.
• Cursor es un IDE (editor de código) con un agente adentro. Trabaja sobre tu proyecto: lee el código, edita varios archivos, corre comandos en la terminal e itera hasta terminar. Es donde vas cuando ya tenés algo y querés seguir construyendo con control.
• Claude Code es un agente que vive en la terminal. Entiende todo tu repo, hace cambios, corre los tests, y maneja los commits y pull requests. Ideal para automatizar sobre un proyecto real.

Elegí la herramienta por el tipo de trabajo, no por la moda. Una guía rápida:

Querés esto...                     → Usá esto
Una pantalla o componente lindo    → v0 (te devuelve React listo)
Una app entera desde cero          → Lovable o Bolt (front + base + login)
Trabajar sobre tu propio código    → Cursor (IDE con un agente adentro)
Automatizar en tu repo de verdad   → Claude Code (agente en la terminal)

Y sí, se combinan: prototipás en Lovable, exportás el código y lo seguís en Cursor o Claude Code.

Planificá antes de tocar una línea

El error número uno es tirarle "haceme una app de turnos" y aceptar lo primero que sale. La IA te va a dar algo, pero sin rumbo se va por las ramas y a los tres prompts ya no entendés qué construyó. La solución no es técnica: es planificar antes.

Dejá el plan escrito antes de pedir una sola línea de código. Definí el objetivo, el usuario y los pasos, y que la IA te los devuelva por escrito para revisarlos:

Antes de escribir nada de código, quiero que planifiquemos.

Objetivo: una app web para que un gimnasio gestione turnos de clases.
Usuarios: el dueño (crea clases) y los socios (reservan un lugar).
Stack: Next.js + Supabase (lo que ya venía usando).

Devolveme, sin código todavía:
1. Las pantallas mínimas para la primera versión (nada de extras).
2. El modelo de datos: qué tablas y qué campos.
3. Los pasos en orden para construirlo, del más chico al más grande.
4. Qué decisiones necesitás que yo confirme antes de arrancar.

Cuando esté de acuerdo con el plan, avanzamos paso por paso.

Ese plan escrito es tu mapa. Cada vez que la IA se desvíe, lo traés de vuelta al plan. Diez minutos acá te ahorran una tarde de idas y vueltas.

El flujo que sí funciona

Con el plan en la mano, construís de a pedazos chicos. La tentación es pedir todo junto; no lo hagas. Un cambio grande que sale mal es imposible de revisar y peor de arreglar.

Un cambio por vez, revisado y commiteado, antes del siguiente. El loop es siempre el mismo:

1. Pedí UN cambio chico y concreto (una pantalla, una función).
2. Leé el diff completo antes de aceptar. Si no lo entendés, preguntá.
3. Probalo: corré la app y verificá que hace exactamente lo que pediste.
4. Commiteá con un mensaje claro: "agrega login con email".
5. Recién ahí pedí el siguiente cambio.

Commitear seguido es tu red de seguridad. Si el próximo prompt rompe todo, volvés al último commit que andaba y perdés cinco minutos, no una tarde. En Cursor y Claude Code el agente puede hacer los commits por vos: pedíselo.

Pedile tests y nunca aceptes lo que no entendés

La IA escribe tests tan rápido como escribe código. Aprovechalo: los tests son los que te avisan cuando un cambio nuevo rompe algo viejo, que es exactamente donde el vibe coding se cae.

Escribí tests para la función de reservar turno.
Cubrí estos casos:
- Reserva válida en un horario libre.
- Intento de reservar un horario ya ocupado.
- Intento de reservar en el pasado.

Después corré los tests y arreglá lo que falle. Mostrame qué cambiaste.

Y la regla que no se negocia: nunca aceptes código que no entendés. No hace falta que puedas escribirlo de memoria, pero sí que puedas leer el diff y decir "sí, esto hace lo que pedí". Si aparece algo que no reconocés, pará y preguntá: "explicame qué hace esta parte y por qué". La IA es buenísima explicando su propio código. Aceptar a ciegas es cómo terminás con una app que anda hasta que un día no, y no tenés idea de por qué.

Los pozos: el 80% fácil y el 20% que te come

El primer 80% es mágico. Describís lo que querés y en minutos tenés un prototipo que hubiera llevado días. Ese es el gancho, y es real. El problema es el otro 20%.

• El último 20% es donde vive el trabajo de verdad. Los casos borde, los errores raros, el rendimiento cuando entran usuarios de verdad, la seguridad. Ahí se va el 80% del tiempo, y la IA sola no lo resuelve: necesita que la dirijas con criterio.
• La deuda técnica no se ve hasta que te explota. Cada vez que aceptás código sin leerlo, sumás complejidad invisible. Anda hoy. Pero el día que algo se rompe, no sabés ni por dónde empezar a buscar, porque nunca entendiste cómo estaba armado.
• Seguridad y secrets: acá no se improvisa. Las claves de tu base de datos o de pagos NUNCA van escritas en el código ni subidas al repo. Van en variables de entorno.

# .env.local  → este archivo queda solo en tu máquina, no se sube.
DATABASE_URL="..."
STRIPE_SECRET_KEY="..."

# Asegurate de que nunca termine en el repo:
echo ".env*" >> .gitignore

Pedile siempre a la IA que revise seguridad antes de publicar: "revisá este código buscando claves expuestas, validación de datos faltante y accesos sin permiso". Claude Code incluso trae un /security-review para eso.

¿Alcanza con vibe coding o necesitás saber programar?

Respuesta honesta: depende de qué construís y de cuánto duele si se rompe. El vibe coding te lleva rapidísimo al prototipo, pero producción real todavía pide criterio técnico.

Vibe coding solo probablemente te alcance si:
- Es un prototipo, una demo o una herramienta interna.
- Los datos no son sensibles y son pocos usuarios.
- Si algo se rompe, no pasa nada grave.

Vas a necesitar saber programar (o traer a alguien) si:
- Manejás pagos, datos personales o algo regulado.
- Un montón de gente depende de que no se caiga.
- El proyecto va a crecer y alguien lo va a mantener por años.

No es todo o nada. Lo más común es que vos lleves el 80% con IA y traigas a alguien técnico para el 20% difícil: la arquitectura, la seguridad, el momento de escalar. Saber dónde está ese límite ya te pone adelante de la mayoría.

Próximo paso

Agarrá una idea chica —una herramienta interna, un prototipo que venís posponiendo— y construila esta semana aplicando el flujo: plan escrito primero, cambios chicos, cada uno revisado y commiteado. Vas a aprender más en un proyecto real que en diez tutoriales. Si querés que definamos juntos qué herramienta te conviene y armemos el plan de tu caso concreto antes de que arranques, agendá una llamada en /agenda y lo trabajamos sobre tu proyecto.