Introducción
Últimamente, YouTube parece un desfile de gurús del código enseñando a programar sin tocar el teclado. Todo el mundo habla del vibe coding, ese estilo de desarrollo en el que tú aportas el contexto, te relajas, y la IA te teclea el código. Claro, eso si tienes suerte y no te monta un microservicio de treinta archivos para hacer algo que podrías resolver con dos líneas de Bash.
Pero reconozco que la propuesta es llamativa: trabajas desde un IDE (Cursor, Windsurf…), escribes cuatro indicaciones y el modelo (cualquiera de los LLM principales) se encarga de escribir, ejecutar, revisar, volver a probar, etc. Mediante la conversación con el modelo puedes ir refinando el código (o si el modelo no se aclara, puedes cambiarlo tú mismo) y, con un poco de disciplina y documentación, puede hacer cosas sorprendentes o, al menos, bastante decentes. A continuación explico mi experiencia, que empezó como un proyecto pequeño y acabó… bueno, todavía no ha acabado.
Proyecto diminuto (primeras pruebas)
Comencé con una idea sencilla: un programa pequeño que me resumiera los mensajes de grupos de WhatsApp configurados y me los enviara por correo a una hora concreta. Quería evitar distracciones durante el día sin perderme nada. ¿El resultado? Todo el proyecto perfectamente estructurado en archivos, funcional a la primera y sin escribir ni una sola línea de código. Yo solo miré, probé y aluciné. Así de claro.
Proyecto pequeño (pongámonos formales)
El proyecto funcionaba, pero estaba pensado para programadores. Las preferencias se debían escribir en un archivo JSON y la arquitectura no era escalable. Ni siquiera podía compartirlo con amigos o familia, porque tendrían que venir a casa para vincular el WhatsApp a mi equipo. Como lo primero salió bien, pensé: «¿y si lo escalo a una plataforma SaaS? Quizás hasta me genere unos ingresos». El modelo empezó a crear una arquitectura casi sin preguntar. Sin validar nada, para bien y para mal.
Aquí echaba en falta un agente que preguntara antes de construir algo, y otro que programara una vez definida la hoja de ruta. Quizás fue culpa mía: no le di instrucciones lo suficientemente concisas ni detallé los flujos.
Con el paso de horas y días (sí, se alargó mucho más de lo previsto), mientras el proyecto crecía en desorden empecé a notar los errores que había cometido.
Primero, me di cuenta de que si no tienes claro con qué tecnologías trabajarás —y para qué—, el modelo decidirá por ti. Y eso no siempre es bueno. Es imprescindible que maximices el uso de los lenguajes y tecnologías que conoces; así, cuando algo falle, puedes intervenir tú antes de perder horas intentando que lo arregle el modelo. A veces es más eficiente “ensuciarse las manos”.
La gran ventaja de estos IDEs es que el modelo escribe, ejecuta, detecta errores y vuelve a probar. Pero no siempre sabe cuándo detenerse, y muchas veces se queda colgado esperando que pase algo que ya pasó. Aquí hay que estar atento e interpretar qué ha fallado para no perder el hilo. El modelo te va diciendo por qué cree que ha fallado. A veces se centra en arreglar el síntoma y no la causa, y ahí tienes que intervenir.
Creo que la mejor estrategia es, después de planificar con cierto detalle las funcionalidades, la arquitectura y los flujos, ir por partes, implementando una funcionalidad cada vez. Y aquí es donde el vibe coding tiene sentido: no es un milagro, ni puedes dejar el ordenador desatendido, pero si sabes jugar tus cartas, es una pareja de baile eficiente.
También empecé a usar las funcionalidades de Cursor y Windsurf que te permiten mantener dos elementos esenciales: un archivo con instrucciones generales que el modelo siempre tiene en cuenta, y otro con la documentación viva del proyecto. Este segundo archivo me ha salvado más de una vez de perder el rumbo.
Tengo que seguir probando modelos, pero el GPT‑4.1 es el que más me ha convencido para este tipo de trabajo. Es menos impulsivo, pregunta antes de hacer y te explica qué va a hacer. Puede parecer lento, pero cuando estás tratando de evitar catástrofes arquitectónicas, es un lujo.
Coste de estas plataformas
Todo esto, obviamente, no es gratis. Tienes versiones básicas para juguetear, pero si quieres montar un proyecto serio prepárate para pagar. Estamos hablando de 20 € al mes con un plan personal (unos 500 prompts, siempre puedes pagar más por más créditos) o 40 € o más en entornos colaborativos. Si te dedicas en serio, es una inversión que tiene sentido.
Conclusiones
¿El proyecto? Aún está a medias. Y, sinceramente, no sé si merece la pena arreglarlo o tirarlo y empezar desde cero. Pero tengo claro que estas herramientas pueden ser brutales si sabes lo que quieres y lo sabes detallar. Te pueden salvar deuda técnica, pero solo en temas concretos. No intentes abordar algo que te sobrepase: no sabrás guiar al modelo.
Es un salto gigante respecto a cómo se programaba hace poco: antes decías al LLM lo que querías, te generaba algo, y cada vez que fallaba tenías que meter logs y más código manualmente. Con el vibe coding la IA tiene una visión global del proyecto, así que es menos propensa a inconsistencias.
Con el vibe coding, yo lo comparo con un buen becario recién llegado: tiene muchísimo talento, pero poca experiencia. Potencial brutal, pero debes darle tareas poco a poco, guiarle, estar pendiente, y si hace falta, echarle un cable.
No sustituye al programador, pero lo hace mucho más eficiente, por lo que puede permitirte hacer muchas más cosas, mucho más rápido.