Si alguien me hubiera dicho hace unos años que acabaría desarrollando aplicaciones completas simplemente describiendo lo que quería en lenguaje natural, probablemente habría sido bastante escéptico. Sin embargo, eso es exactamente lo que ha ocurrido.
Mi relación con la programación empezó en 1991 aprendiendo Basic en mi Spectrum 48k, mi relación con lo que hoy llamamos vibecoding comenzó a principios de 2024. En aquel momento ni siquiera utilizábamos ese término ta que lo acuñó Andrej Karpathy el 6 de febrero de 2025. Simplemente aprovechábamos los nuevos modelos de inteligencia artificial para escribir pequeños scripts en Python que resolvieran problemas concretos.
En mi caso, los primeros experimentos fueron algunos scripts para mis bots de Telegram. Eran herramientas sencillas, pero suficientes para darse cuenta de que algo estaba cambiando. Por primera vez podía describir una necesidad y obtener código funcional en cuestión de minutos. Hasta ese momento la forma que tenía que de conseguir programar algo era solo con mis conocimientos, stackoverflow y lo que otros escribían en sus blogs sobre sus propios trabajos.
Los primeros pasos con Claude y los artefactos
Cuando Anthropic presentó los Artefacts de Claude, en junio de 2024, empecé a experimentar con la creación de páginas web completas. Los resultados eran sorprendentes para la época.
El problema era que los modelos todavía tenían limitaciones muy importantes. La ventana de contexto era pequeña y los tokens se consumían con rapidez. Era relativamente fácil llegar a un punto en el que la IA olvidaba partes importantes del proyecto.
A veces modificaba un archivo y, en lugar de devolver el fichero completo, solo devolvía los cambios realizados. Otras veces perdía fragmentos enteros de código. El resultado era un proyecto roto que obligaba a reconstruir parte del trabajo.
Tampoco gestionaba bien archivos grandes. Cuando un fichero superaba unas pocas centenas de líneas o el proyecto comenzaba a crecer, era evidente que el modelo ya no tenía una visión completa de todo lo que estaba ocurriendo.
Aquellos problemas nos obligaban a desarrollar estrategias bastante ingeniosas.
Una de las más útiles consistía en pedir a la IA que documentara muy bien el código. Otra, que incluyera al principio de cada archivo una explicación detallada indicando qué hacía ese fichero y cuáles habían sido las últimas modificaciones realizadas. De esa forma conseguíamos conservar parte del contexto y evitar que el modelo se perdiera demasiado.
Visto con perspectiva, eran soluciones bastante rudimentarias, pero funcionaban sorprendentemente bien.
La llegada de Bolt.new
El verdadero salto llegó para mí a finales de 2024 cuando descubrí Bolt.new.
La primera vez que lo probé me dejó completamente sorprendido, por primera vez tenía una plataforma capaz de generar, editar, ejecutar y desplegar aplicaciones web completas directamente desde el navegador. Todo ello a partir de instrucciones escritas en lenguaje natural.
Bolt.new, desarrollado por StackBlitz, eliminaba gran parte de la complejidad técnica habitual. No había que configurar entornos locales, instalar dependencias ni preocuparse por multitud de detalles que normalmente forman parte del desarrollo de software.
Simplemente describías lo que querías construir y funcionaba, al menos hasta cierto punto, porque detrás seguían estando los mismos modelos de IA y, por tanto, las mismas limitaciones de contexto.
Cuando los proyectos crecían demasiado aparecían los problemas de siempre. Archivos que se corrompían, funcionalidades que dejaban de funcionar o cambios que rompían partes del sistema aparentemente sin relación.
Aun así, Bolt.new me permitió construir algunos de mis primeros proyectos realmente útiles, uno de ellos fue una aplicación capaz de renderizar archivos XML de Microsoft Project y transformarlos en diagramas de Gantt accesibles para cualquier miembro del equipo. Gracias a esa herramienta conseguimos facilitar enormemente el seguimiento de proyectos dentro del trabajo.
También fue la plataforma con la que desarrollé proyectos mucho más ambiciosos como Yublify.com y AlmadeAlabanza.com.
Adaptando las herramientas a mis necesidades
Había un problema adicional, la mayoría de estas plataformas estaban pensadas para trabajar con tecnologías modernas como Node.js y Supabase. Sin embargo, mi realidad era distinta. Yo utilizo habitualmente hosting compartido y, dependiendo del proyecto, trabajo con MySQL o SQLite. Eso me obligó a buscar soluciones alternativas.
Mi estrategia consistía en desarrollar inicialmente el proyecto siguiendo la arquitectura que proponía la herramienta y, llegado cierto punto, reconducirlo hacia una estructura compatible con mis servidores.
Terminaba convirtiendo aplicaciones pensadas para Node.js en proyectos capaces de funcionar con MySQL y generar versiones estáticas que podía desplegar fácilmente en mis alojamientos habituales. No era el camino previsto por los creadores de estas plataformas, pero funcionaba y bastante bien.
El problema de los créditos
Otro de los grandes inconvenientes de aquella época era el coste.
Los créditos desaparecían a gran velocidad y, además, el usuario tenía muy poco control sobre qué modelo estaba utilizando realmente la plataforma.
Existía un sistema de selección automática que elegía el modelo según sus propios criterios. Sobre el papel parecía una buena idea pero en la práctica era complicado optimizar costes o saber exactamente por qué determinadas tareas consumían más recursos que otras.
Con el tiempo añadieron más opciones de control, pero para mí seguía siendo insuficiente.
La búsqueda de alternativas
Como ocurre siempre en tecnología, cuando una herramienta deja de satisfacer una necesidad empiezas a buscar alternativas. Monté un servidor local utilizando Pinokio y probé Bolt.diy, la versión de código abierto en la que se basa Bolt.new. La idea era excelente, usaba la misma plataforma pero pagando yo mi uso de api sin intermediarios, pero la ejecución, no tanto, el proyecto open source avanzaba a un ritmo mucho más lento que la versión comercial y nunca llegó a ofrecerme una experiencia suficientemente estable para sustituirla.
Antigravity: el punto de inflexión
Entonces apareció Antigravity de Google y aquello cambió completamente mi forma de trabajar.
Es cierto que los modelos de Google nunca me parecieron los mejores para programación, pero el concepto era extraordinario, por primera vez tenía un entorno basado en VS Code donde el control sobre el proyecto era prácticamente total.
Ya no importaba si estaba desarrollando un script de Python, una aplicación web o cualquier otro tipo de software, todo ocurría dentro de un entorno profesional, familiar y flexible.
Durante un tiempo fue mi herramienta favorita, sin embargo, poco a poco Google fue limitando algunas de las características que más valor aportaban. El acceso a Claude se redujo, los modelos propios dejaron de convencerme para tareas complejas y los límites volvieron a hacerse notar.
Fue entonces cuando empecé a buscar una alternativa definitiva.
Claude Code y Codex
La respuesta llegó en forma de Claude Code.
Probé inicialmente la versión basada en terminal, pero nunca terminé de sentirme cómodo trabajando exclusivamente desde línea de comandos, a pesar de que la uso desde siempre y hago de todo ahí.
La verdadera revelación llegó cuando decidí utilizar Claude Code integrado directamente dentro de Visual Studio Code, aquello era exactamente lo que llevaba tiempo buscando.
Toda la potencia del desarrollo asistido por IA, pero dentro de una interfaz profesional, flexible y completamente bajo mi control, además, por aquellas fechas OpenAI mejoró significativamente Codex.
Cuando empecé a alternar ambos sistemas descubrí algo interesante: estaban mucho más cerca de lo que mucha gente imaginaba, hay situaciones donde Claude Code encuentra un callejón sin salida y no sabe cómo continuar y Codex sí y ocurre exactamente lo contrario en otros casos.
Hoy utilizo ambos como herramientas complementarias.
La posibilidad de elegir el modelo concreto, ajustar el nivel de esfuerzo dedicado a cada tarea y controlar mucho mejor el consumo de tokens ha supuesto una mejora enorme respecto a las primeras plataformas de vibecoding.
De los experimentos a proyectos reales
Lo verdaderamente importante es que el vibecoding ha dejado de ser una curiosidad tecnológica para convertirse en una herramienta productiva.
Gracias a estas herramientas he desarrollado aplicaciones que utilizamos en la gestión diaria de mi empresa.
También proyectos públicos como Clipsend.net y PromptRepo.eu.
Además, herramientas como Claude Code incorporan "Skills" muy interesantes para realizar auditorías de seguridad, revisar configuraciones, detectar vulnerabilidades y reforzar considerablemente la fiabilidad de una aplicación.
No sustituyen a un especialista en ciberseguridad, pero permiten elevar muchísimo el nivel de calidad de proyectos que, hace solo unos años, habrían sido imposibles para una sola persona, y lo que queda por venir.
¿Es el vibecoding el futuro?
La pregunta aparece constantemente, mi respuesta es que depende, los desarrolladores tradicionales suelen señalar, con razón, que los proyectos creados mediante vibecoding no tienen la arquitectura, escalabilidad o mantenibilidad de un desarrollo profesional realizado por un equipo experimentado, y tienen razón.
Pero también creo que muchas veces se está comparando el vibecoding con el problema equivocado, no compite contra el desarrollo tradicional de grandes plataformas tecnológicas, compite contra no hacer nada, contra esas pequeñas herramientas internas que nunca llegan a desarrollarse porque no existe presupuesto, contra esas ideas que se quedan para siempre en una libreta, contra esos procesos manuales que nadie automatiza porque el coste de hacerlo supera el beneficio esperado.
Para una pyme, un departamento pequeño o un grupo reducido de usuarios, el vibecoding ya permite construir soluciones enormemente útiles y lo hace a una velocidad que hace apenas dos años parecía ciencia ficción.
Esta revolución ha empezado por lo más obvio, si los LLM escriben texto, primero es la herramienta de los que usan texto en su dia a día, entre ellos los programadores. Los modelos generativos de imágenes, vectores, etc ya están muy avanzados, incluso los de video.
No me cabe la menor duda de que la IA mejorará exponencialmente porque la propia IA se mejorará a si misma, ahí está el ejemplo de Claude Mythos que ha ayudado a parchear miles de agujeros de seguridad importantes en todo el software que usamos de las mejores empresas de software del mundo.
¿Dónde quedarán los humanos? esa respuesta es individual, depende del humano y para eso mejor lee este otro articulo en el que reflexiono sobre qué usos de la IA te potencian o te anulan.
