Qué es el vibe coding: el significado original y cuándo es buena idea

¿Qué es el vibe coding? Es crear software describiéndole a un modelo lo que quieres y aceptando el código que escribe sin leerlo. El término sale de una publicación de Andrej Karpathy, investigador de aprendizaje automático, en X el 2 de febrero de 2025, en la que describía «un nuevo tipo de programación» en el que te dejas llevar del todo por las sensaciones («the vibes») y te olvidas de que el código existe. El diccionario Collins la eligió palabra del año 2025. Desde entonces la expresión se ha estirado hasta abarcar casi cualquier forma de programar con asistentes, y de ahí sale casi toda la confusión. Esta explicación recoge la definición original, la frontera entre el vibe coding y programar con ayuda de un modelo, cuándo es seguro y sus riesgos, con las fuentes originales.

De dónde viene el término

La publicación de Karpathy, que el programador Simon Willison cita completa, describe una forma de trabajar muy concreta. Le habla al editor con la voz y casi no toca el teclado. Pide cambios pequeños como «reduce a la mitad el margen de la barra lateral» porque le da pereza buscarlo. Pulsa siempre «Accept All» y ya no lee las diferencias del código. Los mensajes de error se los pega al modelo sin comentario. Cuando el modelo no consigue arreglar un fallo, lo rodea o pide cambios al azar hasta que desaparece. Su propio balance: no está mal para proyectos de usar y tirar de fin de semana, y resulta bastante divertido. Añade que en realidad no es programar: ve cosas, dice cosas, ejecuta cosas y copia y pega cosas, «y casi siempre funciona».

Dos detalles que conviene guardar. La publicación nombra las herramientas que usaba: Composer, de Cursor, con un modelo Claude Sonnet, y un programa de dictado. Y X fecha la publicación el 2 de febrero de 2025 a las 23:17 UTC, mientras que el artículo de Willison, y las páginas que lo copian, dicen 6 de febrero.

Collins anunció el vibe coding como su palabra del año el 6 de noviembre de 2025 y lo definió como el uso de un modelo, dirigido con lenguaje natural, para escribir código informático, señalando que los expertos discuten si es revolucionario o temerario.

Vibe coding frente a programar con ayuda de un modelo

El artículo de Willison, del 19 de marzo de 2025, sostiene que el término ya se estaba saliendo de su intención original y se aplicaba a cualquier código escrito con ayuda de un modelo. Su definición de trabajo es estrecha: crear software con un modelo de lenguaje sin revisar el código que escribe.

La diferencia no está en la herramienta, sino en lo que haces con lo que produce:

• Vibe coding: juzgas el resultado solo por si parece funcionar. No lees el código y muchas veces no sabrías explicarlo.
• Desarrollo con ayuda de un modelo: el modelo escribe parte o casi todo el código, pero tú lo revisas, lo pruebas y lo entiendes. La regla de Willison es no guardar en su repositorio código que no sepa explicar a otra persona, y si revisaste, probaste y sabes explicar el código que escribió un modelo, eso no es vibe coding, es desarrollo de software.

La misma persona puede hacer las dos cosas el mismo día: un prototipo de usar y tirar por la mañana y, por la tarde, el mismo asistente usado con cuidado sobre código de producción. Las herramientas para lo segundo están en nuestra guía de asistentes para programar, y Claude Code vs Cursor compara dos de las más usadas.

Cuándo tiene sentido el vibe coding

Willison, que dice haber publicado más de 80 experimentos hechos así, lo defiende en su sitio. Lo ve como una forma de que gente sin estudios de informática automatice tareas tediosas de su vida, y como la mejor manera de que los programadores con experiencia aprendan qué pueden y qué no pueden hacer los modelos.

Sus condiciones, pensadas para quien empieza:

1. Que haya poco en juego. Piensa cuánto daño podría causar un fallo o un agujero de seguridad, sobre todo si otras personas van a usar el programa.
2. Secretos. Todo lo que se parezca a una contraseña o a una clave de API exige cuidado, y eso supone entender cómo funciona el código.
3. Datos privados. Asegúrate de entender si los datos pueden salir de tu ordenador.
4. Los servicios de otros. Un código que llama a otras plataformas les añade carga y coste.
5. Tu dinero. Mucho cuidado con el vibe coding contra cualquier servicio que cobre por uso; Willison cuenta casos de gente que acumuló miles de dólares de cargos en una API sin límite de gasto.

Usos típicos que encajan: un programa de un día para renombrar archivos, un panel personal, un prototipo para enseñar una idea a un programador o un juego pequeño para tus hijos.

Los riesgos y cómo reducirlos

Los riesgos salen de la propia definición: si nadie lee el código, nadie ve lo que tiene mal.

• Código creíble pero equivocado. Los modelos de lenguaje producen textos fluidos que pueden ser falsos; el mismo mecanismo de las alucinaciones de los modelos puede dar código que funciona y hace en silencio otra cosa.
• Agujeros de seguridad. Claves a la vista, entradas sin comprobar o permisos de más son invisibles si nunca miras.
• Código que no puedes mantener. El propio Karpathy reconoce que el código crece más allá de lo que entiende. El siguiente cambio, tuyo o del modelo, cuesta más.

Salvaguardas prácticas que mantienen la velocidad sin lo peor:

• Usa un entorno aislado. Willison elogiaba en marzo de 2025 los Artifacts de Claude porque el código se ejecuta en un marco cerrado que no puede conectarse a otros sitios, y señalaba que herramientas como Cursor tienen muchas menos barreras.
• No metas secretos. Las claves, en variables de entorno, nunca en la petición ni en el código que compartas, y pon un límite de gasto en cada API de pago.
• Pide pruebas y ejecútalas. Aunque no leas el código, puedes comprobar lo que hace.
• Pide una revisión antes de compartirlo. El consejo de Willison es que alguien con más experiencia le dé el visto bueno antes de enseñarlo al mundo.

Si quieres pasar del vibe coding a construir bien con un modelo, empieza por cómo usar Claude Code y nuestra guía de ingeniería de prompts: unas instrucciones claras y con ejemplos pesan tanto en el código como en los textos.