Vibe Coding en la Práctica: 10 Lecciones Después de 35 Proyectos con IA

Vibe Coding No Es un Buzzword: Es Cómo Se Construye Software en 2026

“Vibe coding” suena como algo que inventó alguien en Twitter para conseguir likes. Y en parte es cierto — el término nació en redes sociales, se viralizó, y ahora todo el mundo dice que hace “vibe coding” aunque solo le pida a ChatGPT que le corrija un bug en Python.

Pero hay una versión real de vibe coding que no tiene nada que ver con prompts casuales ni con videos de TikTok mostrando cómo “crear una app en 5 minutos”. Es la versión que practicamos en IAmanos todos los días, construyendo software de producción para clientes reales en México.

Después de 35 proyectos completados — desde un SaaS veterinario completo hasta CRMs de ventas, optimizadores logísticos y plataformas de reservas — hemos destilado 10 lecciones que solo aprendes cuando el código que genera la IA tiene que sobrevivir en producción con usuarios que pagan.

No son lecciones motivacionales. Son patrones concretos que cambiaron nuestra forma de trabajar con Claude Code, y que aplican para cualquier desarrollador que esté usando IA como copiloto de desarrollo.

Si acabas de empezar con vibe coding, estas lecciones te ahorran meses de errores que ya cometimos. Si ya llevas un rato, probablemente vas a asentir con la cabeza en más de una.

Lección 1: Describe Intención, No Implementación

El error más común de un desarrollador que empieza a usar IA para codear es darle instrucciones de implementación: “crea un useState para manejar el array de productos, luego mapea los productos en un div con className flex…”

Eso es micromanagement. Y con la IA funciona tan mal como con los humanos.

Lo que funciona es describir la intención: “Necesito una página que muestre el catálogo de 33 servicios de estética canina con precios, agrupados por categoría. El usuario puede seleccionar servicios y ver un total acumulado. Estilo limpio, mobile-first.”

Cuando le das la intención a Claude Code, el resultado es más coherente porque la IA toma decisiones de implementación basándose en el contexto completo del proyecto. Conoce tu stack, tus patrones, tu schema de Prisma. Está mejor posicionada que tú para decidir si usar un Server Component o un Client Component, si la query va en una Server Action o en un API route.

Ejemplo real: WouWou Cotizador de Estética

Cuando construimos el cotizador visual de estética de WouWou, el primer intento fue darle instrucciones paso a paso a Claude Code. El resultado fue código funcional pero fragmentado — 7 archivos, 3 contextos de React, y un state management que parecía un plato de espagueti.

El segundo intento fue con intención pura: “El dueño de una mascota abre la página de estética, ve 33 servicios organizados por categoría (baño, corte, spa, dental, etc.), selecciona los que quiere, y ve un resumen con precio total antes de agendar cita. Necesita sentirse como una experiencia de compra premium, no como un formulario médico.”

El resultado: un solo componente con state local limpio, cards visuales por categoría, animación sutil al seleccionar, y un resumen flotante en mobile. Mejor código, menos archivos, y una UX que los usuarios reales elogian.

La regla práctica

Si tu prompt tiene nombres de funciones, hooks o clases CSS, estás describiendo implementación. Bórralo y empieza con: “El usuario necesita poder [acción] para [objetivo]. El contexto es [pantalla/flujo]. Prioriza [velocidad/claridad/diseño].”

Lección 2: Itera en Cambios Pequeños, No en Refactorizaciones Masivas

La tentación más grande del vibe coding es pedirle a la IA que refactorice todo el proyecto de una vez. “Convierte todas las pages a Server Components, migra el state a Zustand, y cambia el layout a un sidebar colapsable.”

Lo hicimos una vez en Lead Desk. Fue un desastre. Claude Code generó 47 archivos modificados, 12 de ellos tenían imports rotos, 3 tenían tipos incompatibles con Prisma, y el build no compilaba. Tardamos más en arreglar la refactorización que en hacer los cambios uno por uno.

La lección: cambios pequeños, validados individualmente. Un PR que cambia 3-5 archivos y puede probarse en 2 minutos. Si algo se rompe, sabes exactamente qué fue.

El flujo que funciona

1. Define UN cambio concreto (“agrega paginación a la lista de leads”)
2. Claude Code lo implementa
3. Compila y prueba
4. Si funciona, siguiente cambio
5. Si no funciona, Claude Code debuggea CON contexto del error

Este flujo iterativo es 3x más rápido que los cambios masivos. Lo medimos: en GlamBook, los primeros 12 módulos se construyeron con cambios masivos (3 horas promedio por módulo incluyendo debugging). Los últimos 12 se hicieron con iteraciones pequeñas (1 hora promedio). Mismo resultado, un tercio del tiempo.

Por qué la IA trabaja mejor en iteraciones pequeñas

Claude Code tiene una ventana de contexto grande, pero no infinita. Cuando le pides un cambio masivo, tiene que mantener en “memoria” decenas de archivos simultáneamente. La probabilidad de inconsistencias crece exponencialmente con el número de archivos tocados.

Con cambios pequeños, la IA puede concentrar toda su capacidad en 3-5 archivos. La calidad del código generado sube, los errores bajan, y tú como developer puedes verificar el resultado en minutos.

Lección 3: La IA es Espectacular para CRUD y Mediocre para State Complejo

Si hay algo en lo que Claude Code brilla es en generar operaciones CRUD (Create, Read, Update, Delete). Le describes el modelo de Prisma, le dices qué pantallas necesitas, y en 15 minutos tienes un módulo completo con formularios, validaciones, listados con paginación, y modales de confirmación para borrado.

Esto es el 80% de cualquier app. Y la IA lo resuelve con una velocidad y consistencia que un developer humano simplemente no puede igualar.

El otro 20% — la lógica de negocio compleja con estado interdependiente — es donde la IA necesita supervisión seria.

Ejemplo: Disponibilidad de citas en GlamBook

GlamBook es nuestro SaaS de reservas para salones de belleza. La pantalla de booking necesita mostrar disponibilidad horaria considerando:

• Horarios de apertura del salón (que varían por día)
• Disponibilidad individual de cada staff member
• Duración del servicio seleccionado (30 min, 60 min, 90 min)
• Citas ya agendadas (no puedes sobrelapar)
• Tiempo de preparación entre citas (15 min buffer)
• Servicios que requieren secado/procesamiento (múltiples bloques de tiempo)

Claude Code generó una primera versión que manejaba los casos simples correctamente. Pero cuando combinabas un servicio de 90 minutos con un staff que tenía una cita a las 11:00 y otra a las 14:00, mostraba horarios imposibles. La lógica de intersección de intervalos temporales con múltiples constraints es el tipo de problema donde necesitas pensar con lápiz y papel antes de codear.

La solución: yo diseñé el algoritmo de disponibilidad en pseudocódigo, lo validé con casos edge manualmente, y después le pedí a Claude Code que lo implementara. Resultado perfecto a la primera.

La regla: IA genera, humano diseña

Para CRUD: deja que la IA haga todo. Para lógica de negocio compleja: diseña el algoritmo primero, luego pide la implementación. No al revés.

Lección 4: Siempre Lee el Código Generado — SIEMPRE

Este es el error que separa a los developers que usan vibe coding exitosamente de los que terminan con apps frágiles llenas de código que nadie entiende.

Tienes que leer cada línea de código que la IA genera. No “revisar por encima”. Leer. Entender qué hace. Verificar que hace lo que pediste. Identificar assumptions que podrían ser incorrectas.

Tres categorías de bugs que la IA introduce silenciosamente

1. Manejo de errores optimista: La IA tiende a generar happy paths perfectos pero manejo de errores débil. Wraps de try/catch que silencian excepciones, redirects que pierden estado, y toasts de “Error” genéricos que no dicen nada útil. En WouWou encontramos un try/catch vacío que silenciaba errores de la API de Anthropic — los usuarios veían una pantalla en blanco sin explicación.

2. Queries N+1: Prisma hace fácil caer en queries N+1 (un query por cada item en una lista). Claude Code a veces genera un findMany seguido de un loop con findUnique dentro, en lugar de un solo findMany con include. En Lead Desk, una query N+1 hacía que la página de pipeline tardara 8 segundos en cargar. El fix fue una línea: agregar include: { lead: true, assignee: true }.

3. Hardcoded assumptions: La IA a veces hardcodea valores que deberían ser configurables. Encontramos un maxResults: 10 hardcodeado en un componente de búsqueda, un timezone: 'America/Mexico_City' que debería venir de la config del usuario, y un currency: 'MXN' que no aplicaba para todos los clientes.

El hábito que recomendamos

Después de cada generación de Claude Code, antes de probar en el browser: abre los archivos modificados, léelos de arriba a abajo. No toma más de 5 minutos y te ahorra horas de debugging posteriores.

Vibe coding no significa coding a ciegas. Significa que tú diriges y la IA ejecuta, pero tú sigues siendo el control de calidad.

Lección 5: El Testing Sigue Siendo Manual (Y Eso Está Bien)

Confieso algo que probablemente va contra todo lo que lees en blogs de ingeniería de software: no escribimos tests automatizados para la mayoría de nuestras apps.

Antes de que cierres este artículo indignado, déjame explicar el contexto.

Construimos MVPs que van a producción en 48-72 horas. El ciclo de vida típico es: build → deploy → feedback de usuarios → iterar → deploy. En este ciclo, el costo de escribir y mantener una suite de tests automatizados es mayor que el costo de hacer testing manual disciplinado.

Lo que SÍ hacemos

• Testing manual por flujo: Después de cada deploy, recorremos los 5-7 flujos principales de la app como si fuéramos usuarios reales. Login, crear entidad, editar, borrar, buscar, navegar entre secciones.
• TypeScript estricto: TypeScript es nuestro “test suite” más valioso. Los tipos de Prisma + los tipos de Next.js catch el 70% de los bugs en compile time.
• Validación con Zod: Todos los inputs del usuario pasan por schemas de Zod. Esto es testing de inputs automático en runtime.
• Health checks de Docker: Cada contenedor tiene un health check que verifica que la app responde. Si falla, Docker reinicia automáticamente.

Cuándo SÍ escribimos tests

Cuando la lógica de negocio es suficientemente compleja y crítica como para justificarlo. El motor de cálculo de rutas de Fay Route Optimizer tiene tests porque un error en la optimización de rutas afecta a 8,000 puntos de venta. El algoritmo de pricing del Cotizador tiene tests porque un error genera cotizaciones incorrectas que se envían a clientes.

Para el CRUD del 80% de las apps: TypeScript + Zod + testing manual es suficiente. No es dogma, es pragmatismo con 35 proyectos de evidencia.

Lección 6: TypeScript Atrapa Lo Que la IA Omite

TypeScript no es opcional en vibe coding. Es el safety net que te salva cuando la IA genera código que compila mentalmente pero no en la realidad.

Lo que TypeScript atrapa constantemente

Propiedades opcionales tratadas como obligatorias: Claude Code genera código que accede a user.company.name sin verificar que company no sea null. TypeScript marca esto como error inmediatamente. Sin TypeScript, sería un runtime crash en producción cuando un usuario no tiene empresa asociada.

Tipos incompatibles entre Prisma y React: Prisma genera tipos con Decimal para campos de precio. React espera number para renderizar. La IA a veces pasa el Decimal directamente a un <span>. TypeScript te obliga a hacer la conversión explícita.

Enums que no coinciden: Tienes un enum en Prisma con valores PENDING | ACTIVE | INACTIVE y la IA genera un select con opciones pending | active | inactive (minúsculas). TypeScript lo atrapa; JavaScript lo deja pasar y te enteras cuando un usuario selecciona un valor y la base de datos lo rechaza.

Configuración que recomendamos

En tsconfig.json: "strict": true. Sin excepciones. Esto activa noImplicitAny, strictNullChecks, strictFunctionTypes y todas las verificaciones estrictas. Sí, vas a ver más errores en el editor. Pero cada error que TypeScript te muestra es un bug que no llegas a producción.

Claude Code trabaja perfectamente con TypeScript estricto. De hecho, genera mejor código cuando el modo estricto está activo porque los errores de tipo le dan feedback inmediato para autocorregirse.

Lección 7: Docker Simplifica Todo (Incluyendo los Errores)

Si estás haciendo vibe coding y no estás usando Docker, estás haciendo la vida más difícil de lo necesario.

Docker no solo simplifica el deployment — simplifica el error recovery. Cuando algo sale mal (y cuando manejas 35+ apps, algo sale mal cada semana), la solución casi siempre es:

docker stop app-container
docker rm app-container
docker build -t app-image:latest .
docker compose up -d

Cuatro comandos. Menos de 2 minutos. El contenedor se reconstruye desde cero con el código limpio.

Lo que Docker resuelve que no tiene solución elegante sin Docker

• Aislamiento de dependencias: WouWou usa sharp para procesamiento de imágenes. GlamBook no. Sin Docker, instalar sharp afecta a todas las apps del servidor. Con Docker, cada app tiene sus propias dependencias en su propio filesystem.
• Versiones de Node.js: PrintDesk corre en Node 20, Terminal en Node 22. Sin Docker, necesitas nvm y scripts de activación. Con Docker, cada Dockerfile especifica su versión.
• PostgreSQL por app: Cada app tiene su propia instancia de PostgreSQL en un contenedor separado. Si la base de datos de GlamBook se corrompe, las demás 34 apps ni se enteran.
• Rollback instantáneo: Si un deploy falla, el contenedor anterior sigue existiendo. Un docker start previous-container y estás de vuelta en producción en 10 segundos.

Docker Compose como documentación viva

Cada proyecto tiene un docker-compose.yml que documenta exactamente cómo se despliega: puertos, variables de entorno, volúmenes, health checks, dependencias entre servicios. Es documentación que nunca se desactualiza porque ES la configuración de producción.

Claude Code genera Docker Compose files excelentes. Le dices “necesito un compose con la app Next.js en puerto 3000, PostgreSQL en 5432, y Traefik labels para el dominio glambook.iamanos.com” y genera un archivo production-ready a la primera.

Lección 8: El Diseño de Base de Datos Necesita Pensamiento Humano

De todas las lecciones, esta es la que más developer novatos ignoran. Y es la que más caro te sale ignorar.

La IA puede generar un schema de Prisma funcional en minutos. Pero “funcional” no significa “correcto”. Un schema mal diseñado te persigue durante toda la vida del proyecto: queries lentos, migraciones dolorosas, datos inconsistentes, y refactorizaciones que tocan 30 archivos.

Errores de diseño que la IA comete consistentemente

Normalización excesiva: Claude Code tiende a crear tablas separadas para todo. ¿El usuario tiene un teléfono? Tabla Phone con relación many-to-one. ¿Tiene una dirección? Tabla Address. Para una app enterprise con 50 entidades, esta normalización es correcta. Para un MVP con 8 modelos, es overhead innecesario que ralentiza queries y complica el código.

Falta de índices: La IA genera schemas sin índices. Para tablas con 100 registros no importa. Para WouWou, que tiene 206 razas con búsqueda por nombre, categoría y popularidad, la falta de índices hacía que las búsquedas tardaran 200ms en vez de 5ms.

Tipos de campo subóptimos: La IA usa String para todo. Precio como String en vez de Decimal. Fecha como String en vez de DateTime. Estado como String en vez de Enum. Cada tipo incorrecto es un bug potencial que TypeScript no puede atrapar porque Prisma generó el tipo como String.

Lo que hacemos nosotros

Antes de tocar Prisma, diseñamos el schema en texto plano. Definimos entidades, relaciones, cardinalidades, y tipos de campo. Luego le pasamos ese diseño a Claude Code para que genere el schema de Prisma. Resultado: schemas limpios, tipados correctamente, con índices donde hacen falta.

El tiempo invertido en diseño de base de datos se paga 10x en velocidad de desarrollo posterior. Un schema bien diseñado hace que todo el CRUD se genere correctamente a la primera.

Lección 9: La IA Acelera 10x Pero No Elimina el Pensamiento

El mito más peligroso del vibe coding es que la IA piensa por ti. No lo hace. La IA ejecuta por ti. La diferencia es fundamental.

Pensar implica: decidir qué construir, para quién, con qué prioridades, con qué trade-offs. Ejecutar implica: escribir el código que implementa esas decisiones.

Claude Code eliminó el cuello de botella de la ejecución. Lo que antes tardaba 3 días (codear un módulo CRUD completo) ahora tarda 3 horas. Pero las decisiones siguen tardando lo mismo porque requieren entender el negocio, el mercado, y las limitaciones técnicas.

Decisiones que la IA no puede tomar por ti

• ¿Qué feature construir primero? La IA no sabe qué le importa más a tu usuario. Tú sí (o deberías).
• ¿Cuánto cobrar? La IA no entiende el mercado mexicano, la sensibilidad al precio de tu segmento, ni tu estructura de costos.
• ¿Cuándo lanzar vs. seguir puliendo? La IA siempre puede agregar “una feature más”. Tú tienes que decidir cuándo el MVP es suficiente.
• ¿Qué trade-offs aceptar? ¿Velocidad vs. calidad? ¿Generalidad vs. especificidad? ¿Costo vs. funcionalidad? Estas decisiones definen tu producto.

La productividad real del vibe coding

Medimos la productividad de nuestras sesiones de desarrollo. El resultado consistente es que Claude Code reduce el tiempo de implementación en un 80-90%. Pero el tiempo total de proyecto se reduce solo un 50-60% porque el pensamiento, la toma de decisiones, el testing, y la comunicación con clientes siguen tomando su tiempo normal.

Un proyecto que sin IA tardaría 2 semanas, con vibe coding tarda 5-7 días. No 2 horas, no 1 día. 5-7 días. Es una mejora brutal, pero no es magia. Es productividad real medida en proyectos reales.

Lección 10: El Verdadero Cuello de Botella Son las Decisiones, No el Código

Esta es la lección que engloba todas las demás. Después de 35 proyectos con IA, el insight más profundo es este: el código nunca fue el problema.

Antes de la IA, creíamos que el cuello de botella era escribir código. Que si pudiéramos codear más rápido, entregaríamos más rápido. Que la velocidad de tipeo (o de generación) era el factor limitante.

Estábamos equivocados.

Ahora que Claude Code puede generar un módulo completo en 15 minutos, el cuello de botella quedó expuesto: es la capacidad de decidir.

Las decisiones que más tiempo consumen

Alcance del MVP: ¿Incluimos facturación o no? ¿El chat IA es core o nice-to-have? ¿Necesitamos la versión móvil desde el día 1? Cada decisión de alcance puede agregar días al proyecto — no por la implementación, sino por la deliberación.

Diseño de experiencia: ¿El onboarding son 3 pasos o 7? ¿El dashboard muestra métricas o actividad reciente? ¿La navegación es sidebar o tabs? Estas decisiones requieren empatía con el usuario y conocimiento del dominio.

Pricing y modelo de negocio: ¿SaaS mensual o licencia única? ¿Freemium o trial de 14 días? ¿$377/mes o $500/mes? Estas decisiones afectan todo el desarrollo (features que necesitas, onboarding, métricas) y la IA no puede tomarlas.

Priorización post-lanzamiento: Tienes 20 features que los usuarios piden. Puedes construir 3 esta semana. ¿Cuáles? La IA puede implementar las 20, pero solo tú puedes decidir el orden.

La paradoja del vibe coding

Cuanto más rápido puedes implementar, más decisiones necesitas tomar por hora. Antes, la implementación te daba “tiempo de pensar” — mientras codeabas, tu cerebro procesaba las siguientes decisiones. Ahora que la implementación tarda minutos, las decisiones se acumulan más rápido de lo que puedes procesarlas.

La habilidad más valiosa en la era del vibe coding no es saber programar. Es saber decidir rápido y con información incompleta. Es product thinking, no engineering thinking.

Si quieres ser productivo con IA en 2026, invierte menos tiempo aprendiendo frameworks y más tiempo aprendiendo a tomar decisiones de producto.

Cómo Aplicar Estas Lecciones en Tu Próximo Proyecto

No necesitas 35 proyectos para beneficiarte de estas lecciones. Aquí está el playbook condensado para tu próximo proyecto con vibe coding:

Antes de empezar

1. Escribe un documento de 1-2 páginas con: problema, usuario, 5-7 features core, modelo de datos, modelo de negocio. Este es tu CLAUDE.md.
2. Diseña la base de datos en texto plano antes de tocar Prisma. Define entidades, relaciones, tipos, e índices.
3. Decide el alcance del MVP antes de pedirle nada a la IA. ¿Qué está dentro? ¿Qué no? Escríbelo.

Durante el desarrollo

1. Describe intención, no implementación (Lección 1).
2. Itera en cambios pequeños que puedas probar en 2 minutos (Lección 2).
3. Deja que la IA haga el CRUD, pero diseña tú la lógica compleja (Lección 3).
4. Lee cada línea de código generado antes de mergear (Lección 4).
5. Usa TypeScript estricto como tu red de seguridad (Lección 6).

En deployment

1. Docker siempre (Lección 7). No negociable.
2. Testing manual disciplinado por flujos principales (Lección 5).
3. Deploy rápido — una app imperfecta en producción vale más que una perfecta en localhost.

Post-lanzamiento

1. Prioriza decisiones, no features (Lección 10).
2. La velocidad de implementación ya no es el bottleneck — tu capacidad de decidir lo es (Lección 9).
3. Itera basándote en feedback real, no en suposiciones.

El Stack Probado en 35 Proyectos para Vibe Coding en México

Si estás empezando y no sabes qué stack usar para vibe coding, este es el que hemos probado en producción con 35+ apps:

Este stack no es el “mejor” en abstracto. Es el mejor que hemos probado para construir apps SaaS de producción rápidamente con asistencia de IA en el contexto del mercado mexicano.

Si quieres ver cómo funciona este stack aplicado a tu proyecto específico, nuestra fábrica de apps ha producido 35+ soluciones con exactamente estas tecnologías. Y si prefieres explorar los resultados, aquí están las apps en producción.

El Vibe Coding Real No Es Hype — Es Disciplina con Herramientas Nuevas

Si llegas al final de estas 10 lecciones y piensas “esto no suena tan glamoroso como los threads de Twitter”, estás entendiendo el punto.

El vibe coding real — el que produce software que funciona en producción, que sirve a clientes reales, que genera revenue — no es “vibes”. Es disciplina de ingeniería amplificada por herramientas de IA.

Sigues necesitando leer código. Sigues necesitando diseñar bases de datos. Sigues necesitando tomar decisiones difíciles. Sigues necesitando testear manualmente. Lo que cambió es que la parte más mecánica del trabajo — escribir líneas de código — ya no es el cuello de botella.

Después de 35 proyectos, puedo decir con certeza: la IA no te convierte en mejor programador automáticamente. Te convierte en un programador más rápido. La calidad sigue dependiendo de ti.

Si estás listo para construir tu app con este enfoque — con un stack probado, una metodología refinada en 35 proyectos, y un equipo que entiende los límites y las capacidades reales de la IA — IAmanos está para eso.

¿Quieres una app con IA? Cotiza tu proyecto en minutos →

Preguntas Frecuentes

¿Qué es vibe coding y cómo se aplica en proyectos reales?

Vibe coding es un enfoque de desarrollo donde describes la intención de lo que quieres construir y la IA (como Claude Code) genera la implementación. En proyectos reales, se combina con TypeScript estricto, iteraciones pequeñas, revisión de código humana y testing manual. No es dejar que la IA haga todo — es dirigir la IA con disciplina de ingeniería.

¿Cuánto más rápido es el desarrollo con vibe coding vs desarrollo tradicional?

Basado en 35 proyectos en IAmanos, el tiempo de implementación se reduce 80-90% con vibe coding. Pero el tiempo total de proyecto se reduce 50-60% porque las decisiones de producto, diseño y testing siguen tomando su tiempo. Un proyecto de 2 semanas pasa a 5-7 días, no a 2 horas.

¿Qué herramientas se necesitan para hacer vibe coding profesionalmente?

El stack probado en 35 proyectos incluye: Claude Code como copiloto IA, Next.js 16 + TypeScript como framework, Prisma 7 + PostgreSQL para base de datos, Docker + Traefik para infraestructura, y Tailwind CSS para estilos. Todo corre en un VPS de $200 USD/mes.

¿Es necesario saber programar para hacer vibe coding?

Sí. Necesitas entender TypeScript, React, bases de datos y Docker a nivel funcional. La IA genera código, pero tú debes leerlo, validarlo, y debuggearlo cuando falla. Sin conocimientos técnicos, no puedes evaluar si el código generado es correcto, seguro o eficiente.

¿IAmanos usa vibe coding para construir apps para clientes?

Sí. Todas las 35+ apps de IAmanos se construyeron con vibe coding usando Claude Code. Esto incluye WouWou (SaaS veterinario), GlamBook (reservas para salones), Lead Desk (CRM), Fay Route (logística), y más. El resultado son apps de producción con IA integrada, entregadas en 48-72 horas.