Nacho SeoaneNacho Seoane

Vibecoding: cómo construyo productos con Claude

Vibecoding08.05.2026 · 6 MIN
Vibecoding: cómo construyo productos con Claude

"Vibecoding" suena a meme, pero describe bien algo real: construir software conversando con un modelo en vez de escribir cada línea a mano. El término lo popularizó Andrej Karpathy en febrero de 2025, y desde entonces dejó de ser una curiosidad para convertirse en cómo trabaja mucha gente que construye productos. No es para todo, y no reemplaza entender qué estás haciendo. Pero para prototipar y para sacar productos reales rápido, me cambió la forma de trabajar.


TL;DR

  • El vibecoding es construir software describiendo lo que querés mientras un modelo como Claude genera el código. Vos dirigís; el modelo ejecuta.
  • El término lo acuñó Andrej Karpathy en febrero de 2025 y hoy es un flujo habitual para construir prototipos y MVPs.
  • No te ahorra pensar, te ahorra tipear. El criterio de diseño y producto sigue siendo 100% tuyo.
  • Mi regla es 80/20: el modelo acelera el 80% mecánico para que yo me concentre en el 20% que define si el producto es bueno.
  • Funciona mejor en prototipos, herramientas internas y MVPs, donde iterar en horas vale más que optimizar de entrada.
  • No todo se vibecodea: la seguridad crítica, la lógica sensible y la arquitectura las reviso a mano.
  • Veredicto: si ya tenés criterio de diseño, el vibecoding con Claude convierte semanas de build en días.

Qué es el vibecoding

El vibecoding es construir software describiendo en lenguaje natural lo que querés, mientras un modelo de IA genera el código por vos. Andrej Karpathy popularizó el término en febrero de 2025 para describir un modo de programar en el que aceptás el código que propone el modelo e iterás por conversación en vez de escribir cada línea:

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." — Andrej Karpathy, febrero de 2025

La diferencia con el autocompletado de siempre es de grado: no te sugiere la línea siguiente, construye la pantalla entera y vos la ajustás.

El criterio sigue siendo tuyo

La IA es buenísima ejecutando y mala decidiendo, así que si no sabés qué querés construir vas a obtener algo que funciona pero que no sirve. El vibecoding no te ahorra el pensar; te ahorra el tipear. Esa distinción es todo: el cuello de botella deja de ser cuánto código escribís y pasa a ser cuán claro tenés el problema.

Yo arranco igual que siempre: en Figma, definiendo qué es esto, para quién, y cómo se siente. Recién cuando tengo eso claro abro el editor. El modelo amplifica el criterio que ya traés; no lo sustituye.

Mi flujo real, paso a paso

Mi forma de trabajar es lanzar algo funcional lo antes posible y mejorar sobre lo que veo, y el vibecoding hace que ese "lo antes posible" sea cuestión de horas, no de días. En la práctica son tres movimientos que repito en bucle:

  • Describo la pantalla y el comportamiento que quiero.
  • Lo veo corriendo en minutos, no en una semana de setup.
  • Ajusto con feedback concreto, no con un brief perfecto de entrada.

La mejor forma de entender la IA es usarla todos los días para resolver problemas de verdad. Leer sobre el tema no te da la intuición; construir sí.

Vibecoding vs. escribir el código a mano

El vibecoding gana en velocidad de iteración; escribir a mano gana en control fino y en sistemas críticos. No es una guerra: es saber qué parte de cada proyecto cae de cada lado. Así lo reparto yo:

| Criterio | Vibecoding con Claude | Escribir a mano | |---|---|---| | Tiempo a primer prototipo | Horas | Días | | Trabajo mecánico (UI, CRUD, boilerplate) | Ideal | Lento | | Control línea a línea | Medio | Total | | Seguridad crítica / lógica sensible | Riesgo | Recomendado | | Curva si ya sabés diseñar | Baja | Alta | | Mejor para | Prototipos, MVPs, tools internas | Núcleos críticos, librerías |

Ganador para prototipar y validar rápido: vibecoding — porque el primer prototipo pasa de días a horas y podés iterar sobre algo real.

Ganador para seguridad y arquitectura crítica: escribir a mano — ese 20% del producto que define si se rompe o no lo reviso yo, línea a línea.

Dónde poner el límite

No todo se vibecodea: la lógica sensible, la seguridad y las decisiones de arquitectura las reviso a mano. El modelo me acelera el 80% mecánico para que yo me concentre en el 20% que define si el producto es bueno. Ese es el truco entero: no preguntarte si la IA puede hacerlo, sino qué parte vale la pena que hagas vos.

Dos condiciones que me hacen la vida más fácil cuando vibecodeo: tener un design system definido (el modelo se apoya en tus tokens en vez de inventar) y trabajar con Git, para revertir sin miedo cuando una iteración sale mal.

Preguntas frecuentes

¿Qué es el vibecoding?

Es construir software describiendo en lenguaje natural lo que querés mientras un modelo como Claude genera el código. Vos dirigís el diseño y las decisiones; el modelo tipea. El término lo popularizó Andrej Karpathy en febrero de 2025.

¿Reemplaza saber programar o diseñar?

No. Acelera la ejecución, pero necesitás criterio de producto y diseño para dirigirlo. Si no sabés qué querés, el resultado es ruido que funciona pero no sirve.

¿Con qué herramientas se hace vibecoding?

Con un asistente de código sobre tu repo, como Claude Code. Ayuda mucho tener un design system definido y control de versiones (Git) para revertir sin miedo cuando una iteración no sale.

¿Para qué tipo de proyectos funciona mejor?

Para prototipos, herramientas internas y MVPs, donde iterar en horas importa más que la optimización prematura. Es donde más se nota pasar de días a horas.

¿Cuándo NO conviene vibecodear?

Cuando el problema exige seguridad crítica, garantías formales o arquitectura compleja que necesita revisión humana línea a línea. Ese 20% lo reviso a mano siempre.

En resumen

  • El vibecoding es construir software describiendo lo que querés y dejando que un modelo como Claude genere el código; el criterio de diseño sigue siendo tuyo.
  • Andrej Karpathy acuñó el término en febrero de 2025, y en un año pasó de meme a flujo habitual para construir productos.
  • La regla 80/20 lo resume: el modelo cubre el 80% mecánico y vos te quedás con el 20% que decide si el producto sirve.
  • El primer prototipo pasa de días a horas, que es lo que cambia de verdad cuando ya sabés qué querés construir.
  • Funciona mejor en prototipos, MVPs y herramientas internas, no en núcleos con seguridad crítica.
  • Dos condiciones lo potencian: un design system definido y Git para revertir sin miedo.
  • Veredicto: la IA es buenísima ejecutando y mala decidiendo; usala para tipear, no para pensar.

Fuentes y referencias

  • Andrej Karpathy, definición original de "vibe coding" (X/Twitter, febrero de 2025).
  • Claude Code — Anthropic, asistente de código que uso en mi flujo.

Artículos relacionados

Ver todos