Vibe coding: qué es, herramientas, método y límites

El vibe coding es una forma de programar en la que describes en lenguaje natural lo que debe hacer un software y una IA escribe el código por ti: juzgas el resultado usándolo, no leyendo el código. El término lo lanzó Andrej Karpathy, cofundador de OpenAI, en un mensaje publicado en X el 2 de febrero de 2025, y el diccionario Collins lo eligió palabra del año 2025.

Se ha convertido en una forma creíble de fabricar herramientas, siempre que sepas exactamente dónde termina. He entregado herramientas reales así, y he tirado otras a la basura al cabo de tres semanas. Aquí tienes qué es el vibe coding, las herramientas de vibe coding con sus precios, el método para empezar, un ejemplo real y sus límites.

Antes de lanzarte, evalúa tu proyecto. Cuatro preguntas bastan para saber si estás en el terreno adecuado.

Qué es el vibe coding: definición y origen

Es una forma de programar en la que describes la intención en lugar de la implementación. No tecleas bucles ni condiciones: dices «quiero una herramienta que tome un archivo de pedidos, detecte los duplicados y me saque una tabla limpia», y un modelo genera el programa correspondiente.

La diferencia con el autocompletado asistido no es de grado, es de naturaleza. En un editor clásico aumentado, escribes código y la máquina completa tus frases. Aquí, ya no lees necesariamente el código generado: ejecutas, compruebas el resultado y corriges reformulando. El programa vuelve a ser una caja negra, juzgada por su comportamiento.

De dónde viene el término vibe coding

La expresión viene de Andrej Karpathy, investigador en IA, cofundador de OpenAI y antiguo responsable de IA en Tesla. El 2 de febrero de 2025 describe en X una nueva forma de programar en la que se deja llevar por «las vibes» y se olvida de que el código existe: habla con su herramienta, acepta los cambios sin revisarlos y pega los mensajes de error hasta que funciona. El tono es medio en serio, medio en broma, y eso es justo lo que hizo circular la palabra.

En pocos meses, la broma de desarrollador se convirtió en una práctica de trabajo, porque la calidad del código generado había cruzado un umbral. Merriam-Webster lo añadió a su lista de expresiones en tendencia ya en marzo de 2025, y el diccionario Collins lo eligió palabra del año 2025. En español, igual que en francés, se ha impuesto el término inglés tal cual.

Lo que no es

Hay tres confusiones que aparecen continuamente, y aclararlas evita muchas decepciones.

No es no-code. Una plataforma sin código te encierra en un catálogo de bloques preexistentes: montas lo que el proveedor ha previsto. Aquí no hay catálogo, hay un programa de verdad, en un lenguaje de verdad, que puedes alojar donde quieras. La libertad es total, y la responsabilidad también.

No es el fin de la programación. El código sigue existiendo, sigue ejecutándose en un servidor y sigue pudiendo caerse a las tres de la madrugada. Lo que cambia es quién lo escribe, no si existe.

No es magia. Un modelo genera un programa que corresponde a lo que has dicho, no a lo que querías decir. La distancia entre ambas cosas es exactamente la que siempre ha separado un pliego de requisitos de un software logrado. No ha desaparecido, se ha desplazado.

Cómo funciona el vibe coding

El bucle tiene cuatro tiempos y se repite decenas de veces en cada sesión.

1. Describes. En español o en inglés, lo que debe hacer el programa, con qué entradas y qué salidas. Cuanto más precisa sea la descripción del resultado esperado, menos idas y vueltas harás.
2. El modelo genera. Escribe los archivos, instala las dependencias necesarias y, a menudo, lanza él mismo el programa para comprobar que arranca.
3. Pruebas. No leyendo el código, sino usándolo. Le das un archivo real, pulsas los botones reales y miras si el resultado es el que esperabas.
4. Corriges describiendo. «La tabla no ordena en el orden correcto», «se cae cuando el archivo está vacío», «añade una columna con la fecha». El modelo relee su propio código y lo corrige.

Este ciclo es el centro de la práctica, y ahí se juega el éxito o el fracaso. Un usuario que prueba en serio, con casos reales y datos reales llenos de imperfecciones, obtiene una herramienta sólida. Un usuario que prueba el caso ideal obtiene una herramienta que se rompe con el primer archivo mal formado.

Por qué funciona justo ahora

Se han juntado tres evoluciones. Los modelos escriben código mucho más correcto que hace dos años. Manejan contextos mucho más largos, así que tienen en la cabeza un proyecto entero en lugar de un archivo aislado. Y sobre todo se han convertido en agentes: ejecutan los comandos, leen los mensajes de error y corrigen solos, en lugar de limitarse a proponer texto. Es el mismo principio que el de un agente de IA aplicado al desarrollo.

Esta tercera evolución es el verdadero punto de inflexión. Un modelo que ve su error y lo repara cambia la naturaleza del trabajo: ya no eres el intermediario que copia mensajes de error, eres quien hace el encargo y juzga el resultado. Conectado a tus herramientas mediante un servidor MCP, puede incluso leer tus archivos, tus bases de datos o tus exportaciones sin copiar y pegar.

Las herramientas de vibe coding

Hay tres familias de herramientas de vibe coding, y la elección depende sobre todo de tu punto de partida.

Los agentes de código

Son los más potentes. Trabajan directamente en una carpeta de tu ordenador, crean y modifican los archivos, lanzan los comandos y leen los errores. Claude Code, de Anthropic, y Codex, de OpenAI, pertenecen a esta categoría. Uso Claude Code a diario, y mi tutorial para instalar Claude Code parte de cero.

Su fuerza es la autonomía: puedes confiarles una tarea larga y dejar que la desarrollen. Su punto débil es la entrada, que exige manejarse con un terminal. Para alguien que nunca ha abierto una línea de comandos, no es el primer escalón.

Los editores aumentados

Un editor de código con un asistente integrado a fondo: ve todo el proyecto, propone cambios en varios archivos y los aplica tras tu validación. Cursor y GitHub Copilot en modo agente son dos ejemplos conocidos.

Es el término medio adecuado para no perder de vista lo que pasa. Ves los archivos, ves las diferencias antes de aceptarlas y puedes intervenir a mano cuando es más rápido. Es la puerta de entrada que recomiendo a quien ya tiene nociones.

Las plataformas todo en uno

Describes una aplicación en un navegador y se genera, se aloja y se publica sin que veas nunca un archivo. Lovable, Bolt.new o Replit funcionan así. Es la vía más accesible para un principiante absoluto, y la más rápida para enseñarle una idea a alguien.

El precio que pagas es la dependencia: tu aplicación vive en un proveedor, con sus límites y sus tarifas. Para un prototipo o una herramienta interna, es perfectamente aceptable. Para un producto que piensas mantener durante años, la cuestión de la portabilidad debe plantearse desde el primer día.

Comparativa de las principales herramientas y sus precios

Precios públicos en dólares, consultados el 7 de octubre de 2026 en las páginas de precios de los editores. Cambian a menudo: compruébalos antes de suscribirte.

Para el detalle de los planes del agente de Anthropic y lo que cuestan de verdad con el uso, mira mi artículo sobre el precio de Claude Code.

¿Se puede hacer vibe coding con ChatGPT?

Sí. El chat de ChatGPT basta para un script pequeño: describes, escribe, copias el código y lo ejecutas tú. Es la versión artesanal, en la que sigues siendo el intermediario que copia los errores. Codex, el agente de código de OpenAI incluido en las suscripciones de ChatGPT, hace el trabajo completo: modifica los archivos, lanza el programa y corrige solo.

¿Cuál es la mejor herramienta de vibe coding?

No hay una, hay un buen punto de partida según tu perfil. Empieza por la más accesible y sube cuando te atasques. Si nunca has programado, empieza por una plataforma, entrega algo y gana confianza. Si sabes un poco, elige un editor aumentado. Si ya tienes perfil técnico, un agente de código te dará un techo mucho más alto.

No busques la herramienta perfecta: todas avanzan rápido y cada vez se parecen más. Lo que marca la diferencia en el resultado es la forma de hacer el encargo, no la marca.

Qué ventajas tiene el vibe coding

Cuatro ganancias, y solo una es realmente evidente.

La velocidad. La evidente. Una herramienta interna que habría requerido una semana se entrega en una tarde, al menos en un perímetro pequeño.

La accesibilidad. Personas que nunca programarán pueden fabricar la herramienta que necesitan. Es el cambio más profundo, y afecta a oficios enteros: marketing, contabilidad, logística, todos los que apañaban en una hoja de cálculo cosas que merecían un programa de verdad.

El prototipo como lenguaje común. Enseñar una maqueta que funciona sustituye a veinte páginas de especificaciones que nadie lee de la misma manera. En un proyecto con varias personas, acelera más las decisiones que el propio desarrollo.

El derecho a probar. El más infravalorado. Cuando una prueba cuesta dos horas en lugar de dos semanas, se vuelve razonable intentar cosas que nunca habrían tenido presupuesto. La mayoría no dan nada; unas pocas cambian una forma de trabajar. Esta economía de la prueba es lo que más ha cambiado mi manera de trabajar.

Los límites del vibe coding

Esta es la parte que los artículos entusiastas callan, y sin embargo es la que decide tus problemas futuros.

La deuda invisible

Un código que no lees es un código cuya calidad desconoces. Mientras el programa funciona, la ilusión se mantiene. El día que hay que modificar un comportamiento, añadir un caso particular o entender por qué una cifra está mal, la ignorancia se paga de golpe.

He visto ese momento varias veces, y siempre sigue el mismo guion: una herramienta que funcionó muy bien durante dos meses se vuelve imposible de evolucionar, porque nadie, ni tú ni el modelo, sabe ya qué parte hace qué.

El muro de las dos mil líneas

En mis proyectos, aparece un umbral en torno a las mil o dos mil líneas. Por debajo, el modelo mantiene una visión de conjunto y sus correcciones son quirúrgicas. Por encima, empieza a reparar un sitio rompiendo otro, porque ya no tiene toda la lógica en la cabeza.

Este muro no avisa. Se manifiesta con un síntoma preciso: corriges un problema, aparece otro en otro sitio, corriges ese y vuelve el primero. Si das tres vueltas en ese bucle, no es un mal día: es la señal de que hay que dividir el proyecto en trozos más pequeños o pedir a una persona que lo revise.

La seguridad

Es el punto que debería recibir más atención y el que menos recibe. Un modelo genera código que funciona, no necesariamente código seguro. Los fallos clásicos (datos sin validar, secretos escritos en claro, ningún control sobre quién tiene derecho a hacer qué) no se ven con el uso: la aplicación funciona perfectamente hasta el día en que alguien se interesa por ella.

La regla que aplico sin excepción: en cuanto una herramienta es accesible desde internet o maneja datos personales, pasa por los ojos de alguien que sabe leer código. No es prudencia excesiva, es lo mínimo. La herramienta de evaluación del principio de la página te dice a partir de cuándo esa revisión se vuelve obligatoria.

La trampa del casi terminado

El último escollo es psicológico. Estas herramientas te llevan muy rápido al ochenta por ciento del resultado, lo que da la sensación de haber casi terminado. El veinte por ciento restante (los casos límite, la gestión de errores, los comportamientos raros) lleva en realidad tanto tiempo como el resto, o incluso más.

No es exclusivo de esta práctica: es la ley del desarrollo de software desde siempre. Pero la velocidad del principio hace la decepción más brusca, y muchos proyectos se detienen justo ahí.

Vibe coding para principiantes: cómo empezar

Este es el camino que recomiendo a alguien que nunca ha escrito una línea de código.

Elegir el primer proyecto adecuado

El mejor proyecto para empezar tiene cuatro características: te sirve personalmente, solo lo usas tú, no toca ningún dato sensible y puedes tirarlo sin consecuencias. Un conversor de archivos, un panel de control personal, una herramienta que ordena tus fotos, una calculadora para tu oficio.

El peor proyecto para empezar es el que tiene usuarios, dinero en juego o datos de clientes. No es una cuestión de dificultad técnica, es una cuestión del coste del error mientras aprendes.

Las cinco reglas que lo cambian todo

• Describe el resultado, no el método. Di lo que el programa debe producir, no cómo te imaginas que debería hacerlo. Te equivocarás más que él sobre el cómo.
• Una petición cada vez. Cinco cambios pedidos a la vez dan cinco cambios aproximados. Uno solo da un resultado limpio que puedes validar.
• Prueba con datos reales y sucios. El archivo con tildes, la fila vacía, la fecha en el formato equivocado. Ahí se esconden los defectos.
• Pide tests automatizados desde el principio. Son pequeños programas que comprueban que el programa principal hace lo que debe. Es la única red que permite retomar un proyecto tres meses después.
• Guarda el historial. Usa una herramienta de control de versiones, aunque solo sea para poder volver atrás cuando un cambio lo rompa todo. El modelo te lo puede configurar en dos minutos.

Los primeros días, en concreto

Elige una necesidad real, no un ejercicio. Descríbela en tres frases a la herramienta que prefieras, deja que genere una primera versión y úsala de inmediato. Anota lo que no funciona, pide una corrección cada vez y vuelve a empezar.

En una tarde tendrás algo que funciona. En una semana habrás entendido que la dificultad no está en conseguir que genere código, sino en saber decir lo que quieres. Ese descubrimiento es el verdadero contenido del aprendizaje.

Ejemplo de vibe coding, de la necesidad a la herramienta

Lo más elocuente sigue siendo un caso real. Este es, resumido, el desarrollo de una herramienta que todavía uso.

La necesidad. Cada mes recibía exportaciones de posiciones de varios clientes, en formatos distintos, y dedicaba una hora a uniformizarlas antes de poder compararlas. Un trabajo sin ningún valor añadido, repetido doce veces al año.

La primera instrucción. Tres frases, no más: un programa que lee todos los archivos de una carpeta, sea cual sea su formato de columnas, los reduce a una tabla única con fecha, palabra clave, posición y dominio, y escribe el resultado en un solo archivo. La primera versión llegó en cuatro minutos y funcionaba con dos archivos de cada tres.

Las correcciones. El tercer archivo usaba el punto y coma como separador y fechas en formato estadounidense. Dos peticiones, dos correcciones, diez minutos. Después, un caso que no había previsto: algunas filas no tenían posición, porque la palabra clave había salido del ranking. Pedí que se conservaran con un valor vacío en lugar de eliminarse, porque la desaparición de una palabra clave es precisamente la información interesante.

La red. Pedí tests automatizados que cubrieran los tres formatos y el caso de la fila vacía. Cinco minutos más. Fueron ellos los que me permitieron, cuatro meses después, añadir un cuarto formato sin romper nada.

El balance. Una hora de trabajo en total, y una hora ahorrada cada mes desde entonces. Y sobre todo: nunca habría escrito este programa a mano, porque el cálculo de rentabilidad nunca lo habría justificado. Es exactamente lo que quería decir con la economía de la prueba.

Fíjate en lo que hizo que este caso saliera bien: un perímetro minúsculo, ningún dato sensible, un solo usuario y tests pedidos antes de que el proyecto creciera. Los cuatro criterios de la herramienta de evaluación, reunidos.

Lo que cuesta

El gasto en dinero se conoce de antemano: una suscripción de 8 a 25 dólares al mes basta para empezar con la mayoría de las herramientas de la tabla, y varias tienen un plan gratuito para probar. Para un uso individual habitual, la suscripción casi siempre sale más a cuenta que el pago por uso, y hace el gasto previsible, algo que importa cuando todavía no sabes dosificar.

Las plataformas todo en uno suelen cobrar a la vez la generación y el alojamiento. Es cómodo al principio y se convierte en la partida que vigilar si la aplicación crece, más aún porque migrar a otro sitio no siempre es sencillo.

El coste real está en otra parte: en el tiempo. Una sesión productiva de dos horas produce una herramienta; una sesión mal planteada produce tres horas de correcciones en bucle y un proyecto abandonado. La diferencia depende casi siempre de la claridad de la descripción inicial, y eso es una buena noticia: es el único parámetro que controlas por completo.

Cómo aprender vibe coding

No hay gran cosa que aprender en sentido académico, y mucho que practicar. La competencia no tiene que ver con una sintaxis, sino con tres cosas.

Saber especificar. Descomponer una necesidad difusa en comportamientos precisos, anticipar los casos límite antes de que ocurran, decir lo que el programa debe hacer cuando las cosas van mal. Es el oficio de analista, y nunca ha sido tan útil. Es también lo que abarca de verdad el prompt engineering: dar el contexto adecuado importa más que encontrar la fórmula perfecta.

Saber juzgar. Reconocer un resultado falso, un comportamiento sospechoso, una respuesta demasiado bonita. Se adquiere probando mucho, con tus propios datos, con la obsesión del caso retorcido.

Entender los conceptos, no la sintaxis. No necesitas saber escribir un bucle. Necesitas saber qué es una base de datos, por qué una contraseña nunca se guarda en claro, qué es una clave de API y por qué no se pone en una página web. Una decena de nociones de este tipo cubre la mayoría de los errores graves.

Por eso la mejor formación sigue siendo un proyecto real cuyo resultado te importe. Los cursos teóricos sobre cómo formular instrucciones envejecen en pocos meses; la capacidad de especificar y de juzgar no envejece.

Vibe coding y empleo: lo que cambia

Es la pregunta que inquieta, así que mejor responderla con franqueza.

El oficio de desarrollador no desaparece, se desplaza hacia arriba. Escribir la primera versión de un programa pierde valor; diseñar una arquitectura que aguante, revisar código generado por una máquina, garantizar la seguridad y arbitrar los compromisos lo ganan. El trabajo se desplaza de la producción al diseño y al control.

Dos perfiles ven su situación mejorar claramente. Los desarrolladores con experiencia, cuyo criterio se convierte en el cuello de botella y, por tanto, en el recurso escaso. Y los expertos de negocio que ahora saben fabricar sus propias herramientas sin pasar por una cola de espera de informática: un controller financiero que genera su panel de control, un jurista que automatiza la clasificación de documentos.

El perfil debilitado es el del desarrollador junior limitado a tareas sencillas y repetitivas, justo las que mejor hacen estas herramientas. El consejo que se deriva es duro pero útil: no construyas tu valor sobre la producción de código; constrúyelo sobre la comprensión de los sistemas y la capacidad de decidir.

A quién pertenece el código generado

La pregunta sale en todas mis formaciones en empresa, y merece una respuesta clara en lugar de un encogimiento de hombros.

En principio, el código generado es tuyo, dentro de los límites de las condiciones de uso del servicio que utilizas. Eso se comprueba antes de construir un producto encima, no después: lee la cláusula de propiedad del servicio una vez y archívala.

Dos puntos exigen más atención. Las dependencias, primero: un modelo instala de buena gana librerías de terceros, y cada una viene con su licencia. Algunas imponen condiciones a un uso comercial. Pide la lista de dependencias y de sus licencias: es una pregunta que la herramienta responde en unos segundos. Tus datos, después: si pegas fragmentos de archivos de clientes en una conversación, esos contenidos salen de tu sistema. Para un uso profesional, esta cuestión se resuelve a nivel de organización y de contrato, no a nivel de usuario.

Nada de esto es un obstáculo insalvable. Pero una empresa que descubre estos temas después de poner una herramienta en producción siempre los descubre en el peor momento.

Lo que hago con él en la práctica

Lo uso todos los días, y siempre en el mismo perímetro: herramientas internas, para mí o para un cliente, que no manejan datos sensibles y cuyo fallo solo cuesta una mañana.

Ejemplos reales: un script que compara dos exportaciones de rastreo y me saca las URL que han cambiado de estado, un generador de archivos de redirecciones a partir de una tabla, un pequeño panel que agrega las posiciones de varios clientes, las herramientas interactivas que encuentras en mis artículos. Ninguno de estos programas existiría si hubiera tenido que escribirlos a mano: nunca habrían compensado el tiempo que habrían costado.

Lo que no hago: la web de un cliente, una aplicación con cuentas de usuario, nada que toque un pago. No por principio, sino porque sé que no revisaré el código con la seriedad suficiente para asumir la responsabilidad.

La línea está ahí, y es fácil de recordar: fabrica todo aquello cuyo fallo solo te cueste a ti. Para lo demás, usa estas herramientas para ir rápido, pero haz que lo revise alguien que se dedique a ello. Cuando una herramienta tiene que durar, ese es el marco de mis proyectos de automatización con IA: tests, revisión y puesta en producción incluidos.

Escrito por

Anthony Courtin

Consultor SEO, GEO y automatización con IA

Acompaño a pymes y profesionales independientes en su visibilidad (Google, ChatGPT, Perplexity) y en el uso real de la IA en el trabajo. Trabajo con empresas para formar a los equipos y replantear sus procesos. Todo lo que escribo aquí lo uso en mis proyectos.

Sígueme en LinkedIn Mi canal de YouTube (en francés)