Qué es y de dónde sale

Describes lo que quieres con tus palabras, el asistente escribe el código y tú lo pruebas. Si no hace lo que esperabas, se lo dices o le das el error, y vuelta a empezar. Eso, en pocas palabras, es el vibecoding: programar describiendo lo que quieres, sin escribir tú el código.

Ha hecho posible que gente que nunca había programado se haga en una tarde una hoja que calcula sola, una página para su negocio o un programa que ordena sus fotos. También ha llenado las redes de promesas que no se cumplen.

En este curso verás las dos caras. En esta primera lección, qué es exactamente, de dónde sale la palabra, cómo es una sesión de trabajo y qué herramientas hay. Al final describirás una herramienta pequeña que te vendría bien, que es por donde empieza todo.

De dónde sale la palabra

La usó por primera vez Andrej Karpathy, investigador de IA y uno de los fundadores de OpenAI, en un mensaje publicado en X en febrero de 2025. Describía una forma de programar en la que uno se deja llevar: acepta los cambios que propone el asistente sin leerlos y, si algo falla, le pega el error hasta que se arregla. Él mismo la pensaba para proyectos de fin de semana, de usar y tirar.

La palabra corrió tanto que el diccionario Collins la eligió palabra del año en noviembre de 2025, con una definición más amplia: usar la IA, guiada por lenguaje natural, para escribir código.

Esa diferencia importa en todo el curso. En sentido estricto, el vibecoding es no mirar el código. En sentido amplio, es programar con un asistente al que le describes lo que quieres. Lo primero sirve para jugar y probar; lo segundo, bien hecho, sirve para mucho más.

En español no tiene traducción asentada. Aquí la escribimos junta y en cursiva.

Cómo es una sesión

Una sesión de vibecoding se parece a una conversación con alguien que escribe muy rápido y no conoce tu problema:

1. Describes qué quieres, para quién y qué debe hacer, en pocas frases.
2. El asistente propone cómo hacerlo o escribe el código directamente.
3. Lo pones a funcionar y miras qué hace: si se abre, si responde, si sale lo que esperabas.
4. Algo falla, casi siempre. Copias el mensaje de error tal cual y se lo das.
5. Cuando funciona, guardas una versión, para poder volver atrás si el siguiente cambio lo rompe.
6. Pides el siguiente cambio, uno pequeño cada vez.

El bucle se repite: describir, probar, corregir y guardar. El paso que más se salta es el quinto, y es el que más disgustos ahorra. Lo verás a fondo en la lección 3.

Qué herramientas hay

No hace falta ninguna en concreto, y cambian cada pocos meses. Lo útil es saber qué tipo de herramienta tienes delante, porque cambia cuánto ves y cuánto controlas:

• Asistentes de conversación, como ChatGPT, Claude o Gemini. Les pides el código, te lo escriben en la conversación y tú lo copias donde haga falta. Lo ves todo, pero lo montas tú.
• Plataformas que hacen la aplicación entera en el navegador, como Lovable, Bolt o Replit. Describes la aplicación y la tienes funcionando en la misma página. Es lo más rápido para probar una idea y lo que menos enseña lo que hay detrás.
• Editores de código con IA, como Cursor o Visual Studio Code con GitHub Copilot. El asistente trabaja dentro de tus archivos y ves cada cambio antes de aceptarlo.
• Agentes que trabajan en tu ordenador, como Claude Code o Codex. Les das una tarea y la hacen paso a paso: crean archivos, ejecutan órdenes y prueban. Son los más potentes y los que más cuidado piden con los permisos.

Para empezar, cualquiera vale. El curso no depende de ninguna.

Lo que no es

No es programar sin saber nada para siempre. Puedes empezar sin saber, y mucha gente lo hace. Pero en cuanto lo que haces crece, entender lo básico de lo que tienes delante deja de ser opcional: qué archivos hay, dónde se ejecuta y dónde se guardan los datos.

No es que la IA lo haga todo. Tú decides qué se hace, para quién y cuándo está bien. El asistente escribe rápido, pero no sabe qué necesitas si no se lo dices, ni se da cuenta de lo que no ve.

No es lo mismo para ti que para otros. Una herramienta que solo usas tú y que, si se rompe, no deja a nadie colgado admite el vibecoding en sentido estricto. Algo que usan otras personas, con sus datos o su dinero, pide revisar, probar y que alguien responda. Lo verás en la lección 2.

Lo que sí es: una forma muy rápida de pasar de una idea a algo que funciona y que puedes probar.

Hazlo: describe tu primera herramienta

1. Piensa en una tarea pequeña y repetitiva de tu día a día: algo que haces a mano cada semana, una cuenta que repites o una lista que ordenas.
2. Descríbela en cinco líneas: qué problema resuelve, quién la va a usar, qué le das, qué te devuelve y qué no debe hacer nunca.
3. Pégasela a tu asistente con esta petición: «Antes de escribir código, hazme las preguntas que necesites para entender lo que quiero».
4. Responde a sus preguntas y apunta cuáles no te habías planteado.

Todavía no hace falta que escriba el código. Describir bien es la mitad del trabajo, y lo que apuntes aquí lo usarás en el resto del curso.