Qué es el vibecoding en 2026: definición, herramientas y antipatrones

El vibecoding es una forma de escribir software en la que la principal herramienta de producción es el lenguaje natural, no la sintaxis. Andrej Karpathy popularizó el término en 2025: sesiones de viernes por la noche en las que se dejaba llevar por las sensaciones (“catch the vibe”), un modelo iba encajando cambios en la app y él aceptaba casi todo lo que le devolvía. En 2026 este estilo ha pasado de ser un experimento de fin de semana a usarse en apps SaaS reales, agencias y equipos de I+D.

La definición que usamos en vibecoding.pl

Vibecoding = un trabajo en el que:

• la tarea se describe en lenguaje natural (polaco o inglés), no en pseudocódigo;
• el modelo produce la mayoría de los cambios en los archivos (desde una línea hasta un módulo entero);
• la persona actúa como product owner + revisor, no como alguien que copia y pega;
• un ciclo de feedback corto (cambiar, ejecutar, comprobar, corregir) sustituye a una larga fase de diseño previa.

Eso no significa que el ingeniero deje de leer código. Lo lee, pero en modo revisión y no en modo autor. Tampoco significa que nunca escriba una línea a mano. Lo hace cuando el modelo se equivoca o cuando una edición quirúrgica de un solo carácter es más rápida que volver a escribir el prompt.

Por qué ahora y no hace dos años

Por fin coincidieron tres cosas: modelos que manejan más de 100k tokens de contexto (Sonnet 4.6, GPT-5, Gemini 2.5), herramientas que modifican archivos de forma segura (Claude Code, Cursor Composer, Aider) y una arquitectura de aplicaciones que el modelo ya conoce (Next.js App Router, tRPC, Drizzle, shadcn/ui). Ese tercer punto es el cambio más infravalorado de 2024-2025: la convergencia silenciosa en torno a unas convenciones comunes hace que el modelo rara vez tenga que adivinar nombres de carpetas o rutas de import.

Los tres niveles del vibecoder

Nivel 1: aceptar a ciegas. Todo lo que propone el LLM acaba en el commit. Funciona hasta que te topas con la primera tabla que no querías borrar. Sirve para prototipos y hackatones.

Nivel 2: aceptar tras revisar. Generas, lees el diff, aceptas o rechazas. Aquí empieza el verdadero ahorro de tiempo. Cada cambio pasa por tus ojos, pero no lo tecleas tú.

Nivel 3: spec → implementación → revisión. Escribes la especificación en un archivo .md y le pides al agente que la implemente; después compruebas que la implementación se ajusta a la especificación. Este nivel es la base del vibe engineering, al que dedicamos una categoría propia.

Antipatrones: cuando el vibecoding se vuelve en tu contra

Un megaprompt para todo. Si tu prompt tiene 30 requisitos, el modelo ignorará la mitad. Divídelo en cinco subtareas y reutiliza el mismo bloque de contexto en cada una.

Ningún commit por el camino. A la quinta iteración ya no tienes ni idea de qué se rompió. El vibecoding obliga a ser disciplinado con git: commit después de cada cambio en verde y push cada pocos commits.

Confiar a ciegas en los tests que escribe el LLM. A los modelos les gusta escribir tests que siempre pasan (assert true, mocks que sobrescriben el comportamiento). O una persona da el visto bueno a cada test, o ejecutas mutation testing para verificar que la suite de verdad pone a prueba el código.

Ignorar el esquema de la base de datos. Los modelos generan sin pestañear migraciones que funcionan en local y explotan en producción. Regla: toda migración es reversible, se ensaya contra una copia de los datos de producción, y un ALTER TABLE sin batching nunca se acerca a una tabla grande.

El stack real del vibecoder en 2026

El stack que vemos en el 80% de los proyectos de vibecoding.pl:

• IDE/CLI: Cursor (Composer + Agent Mode) o Claude Code (pensado para la terminal).
• Modelos: Sonnet 4.6 (revisión, refactorización), GPT-5 (investigación, tareas muy cargadas de prompts), Haiku 4.5 (iteraciones rápidas).
• Creación web: v0, Bolt y Lovable para landing pages y MVP, Next.js App Router para producción.
• Backend: tRPC + Drizzle + Postgres en Vercel o Fly.io.
• Tests: Vitest para tests unitarios, Playwright para e2e, Promptfoo para evals.
• Observabilidad: Sentry + Langfuse para las llamadas al LLM, Tinybird para los logs.

Qué leer para empezar

El mejor material gratuito: el tuit original de Karpathy de 2025, la documentación de Claude Code, la de Cursor Composer y la categoría de vibe engineering de este blog. En polaco: el canal de YouTube de vibecoding.pl, donde cada semana publicamos una sesión de live coding desde la idea hasta el deploy. Empieza con un proyecto que ya entiendas desde el punto de vista del negocio (por ejemplo, tu propia landing page) en lugar de con un clon abstracto de Twitter.

En resumen

El vibecoding no es un atajo para convertirte en peor ingeniero. Es un cambio de rol: pasas de autor a product owner del código. En 2026 ya es mainstream, pero exige disciplina: especificación, commits, revisión y evals. Si te saltas la disciplina, tu proyecto se convierte en un espagueti imposible de mantener después de cinco prompts. Si la aplicas, lanzas en un fin de semana lo que antes te llevaba dos semanas.