El poder del vibe coding: seis meses que cambiaron mi forma de desarrollar

Desde hace seis meses, trabajo casi exclusivamente con vibe coding. Al principio, era escéptico respecto a las herramientas cuya ambición declarada parecía amenazar el oficio que constituye el núcleo de mi carrera: analista-programador. Sin embargo, con el tiempo he aprendido a valorarlas, a comprender sus límites y, sobre todo, a medir lo que realmente pueden aportar cuando se gestionan adecuadamente.

01Mi primer POC: una fachada bonita no es suficiente

Mis primeros POC se centraron en temas que dominaba a la perfección: funcionalidades que ya había desarrollado decenas de veces y que casi siempre implementaba siguiendo los mismos principios. Crear una ficha de cliente es un buen ejemplo.

Al principio, mis prompts eran muy básicos: Crea una aplicación de gestión de clientes. El resultado probablemente le habría parecido fantástico a un cliente no familiarizado con el desarrollo. La interfaz tenía buen aspecto y el programa funcionaba.

Pero en cuanto miré bajo el capó descubrí un código comparable al de un becario de primer año de informática: funcional, sí, pero difícil de mantener y muy alejado de los estándares esperados para una aplicación profesional.

Por lo tanto, mis siguientes pruebas fueron mucho más precisas:

Quiero una arquitectura en tres capas. El acceso a la base de datos debe realizarse a través de una API. Utiliza un stack tecnológico profesional, limita las dependencias innecesarias y evita Python siempre que sea posible.

Con este tipo de instrucciones, los resultados se volvieron mucho más interesantes. Empecé a comprender que realmente podía sacar provecho de la herramienta, siempre que le proporcionara un marco técnico preciso.

02Reducir costes con modelos locales

Tras estas primeras pruebas, el siguiente paso lógico era reducir costes. Sistemas como Codex o Claude Code se basan en cuotas de uso que pueden volverse restrictivas rápidamente cuando los proyectos se encadenan.

Entonces probé varios modelos en local con LM Studio y Ollama. Los primeros resultados fueron alentadores, pero rápidamente encontré una limitación importante: el tamaño del contexto.

Al principio todo funcionó bien. Tan pronto como el proyecto creció, el agente empezó a entrar en bucle, olvidando ciertas decisiones o comprimiendo constantemente su contexto.

Una solución es utilizar modelos con menos parámetros para liberar más memoria para el contexto. Desafortunadamente, el nivel de razonamiento a menudo resulta insuficiente para un uso profesional en tareas de desarrollo complejas.

Llegué a la conclusión de que las soluciones autohospedadas aún no alcanzan de forma consistente el nivel necesario para este uso, aunque sigue siendo esencial probarlas periódicamente.

Para fines profesionales, mi cliente adquirió un DGX Spark con 128 GB de memoria compartida entre CPU y GPU. La limitación de la ventana de contexto es mucho menos restrictiva, pero ciertas tareas de desarrollo siguen siendo particularmente largas.

Sin embargo, matizo esta observación: en el momento de escribir este artículo, estoy trabajando principalmente con GPT-5.6 SOL en modo de razonamiento Ultra. También puede ser lento, pero el resultado obtenido muchas veces es correcto desde la primera ejecución.

03Del POC al uso profesional

Mi primer caso de uso profesional real fue la migración de un proyecto de API desarrollado con WINDEV a otra tecnología. Detallaré mi metodología en un próximo artículo.

PC SOFT cobra por el uso de sus servidores de aplicaciones. El año pasado, el costo de esta licencia se duplicó sin cambios suficientemente significativos que lo justificaran, en mi opinión.

Así que decidí cambiar el stack tecnológico y aprovechar la ocasión para corregir un error presente en la aplicación. Gracias a mi conocimiento funcional y técnico del proyecto, pude guiar con precisión al agente.

Aproximadamente dos horas después, se completó la migración. Las nuevas API, desarrolladas en otro lenguaje, continuaron utilizando la base de datos HFSQL existente a través de un controlador ODBC, y ahora se ejecutaban en un entorno Linux x64.

Después de una primera serie de pruebas unitarias manuales, me pregunté si Codex podría automatizar la verificación de todas las API. Entonces le pedí:

Ejecuta una campaña de pruebas sobre mis API, proporciona una tabla de Excel con todos los escenarios ejecutados y corrige los errores detectados.

Ese día tuve mi segunda gran sorpresa. El sistema identificó problemas que no había detectado, los corrigió y después desplegó los cambios en el servidor.

Un experimento iniciado casi como una prueba de concepto se había convertido en un verdadero paso de control de calidad.

04Reemplazar el GDS con Gitea

En este punto, mi nuevo proyecto se estaba ejecutando en producción, pero había perdido un elemento importante de mi entorno habitual: el GDS, el gestor de código fuente de PC SOFT.

Después de estudiar varias soluciones, elegí implementar Gitea en un contenedor Docker. Gitea se basa en Git y ofrece una interfaz web que permite consultar repositorios, historial, ramas y archivos, como GitHub, sin dejar de estar autohospedado.

Subí mi código fuente al repositorio y recuperé un sistema de control de versiones completo. Todavía me faltaba la documentación.

Sin embargo, las herramientas de inteligencia artificial son particularmente efectivas para producir documentos Markdown y Gitea sabe cómo mostrarlos de forma nativa en su interfaz.

En tan solo unos pocos pasos me encontré con una plataforma de control de versiones y documentación mucho más completa que el GDS que llevaba más de diez años utilizando.

05Mi archivo Markdown de reglas de desarrollo

Como muchos desarrolladores, soy partidario de evitar esfuerzos innecesarios. Escribir un prompt perfecto antes de cada intervención es eficaz, pero particularmente repetitivo.

Entonces creé un archivo Markdown que describe todas las reglas que el agente debe respetar durante el desarrollo.

Este documento especifica en particular:

• las arquitecturas preferidas según la naturaleza del proyecto;
• modelado de datos riguroso, inspirado en Merise;
• la clara separación entre el front-end, las API y la capa de datos;
• la creación de vistas y componentes reutilizables;
• el uso adecuado de la herencia y el polimorfismo;
• la implementación de hilos, eventos o el patrón Observer cuando esté justificado;
• el uso de llamadas asíncronas para evitar recargas innecesarias;
• la limitación de bibliotecas innecesarias y dependencias difíciles de mantener;
• procedimientos de copia de seguridad y recuperación cuando se utiliza una base de datos;
• la capacidad de configurar puertos y ajustes de tiempo de ejecución.

Estos son en definitiva los principios que ya aplicamos a diario, pero documentarlos suele requerir un largo trabajo de arquitectura.

Una vez registradas en un documento de referencia, estas reglas se convierten en una especie de contrato técnico entre el agente y yo.

06La IA siempre busca el camino más corto

Esto me lleva a un tema que me interesa especialmente. Cuando simplemente le pido a una IA que cree un programa, sin dejarle entender que soy un desarrollador y que espero un resultado mantenible, generalmente elige el camino más rápido para lograr el objetivo.

En cambio, cuando le impongo reglas de arquitectura, calidad, seguridad y funcionamiento, se convierte en un desarrollador sumamente productivo que puedo dirigir hacia un resultado específico.

Aquí es donde el vibe coding se vuelve realmente poderoso. No todo el mundo es desarrollador. Nos hemos formado, hemos acumulado experiencia, hemos entregado proyectos con éxito y hemos aprendido de otros más difíciles.

Esta experiencia nos permite distinguir una simple demostración funcional de una aplicación verdaderamente utilizable.

La IA no borra este valor. Al contrario, nos permite utilizarlo para ofrecer a nuestros clientes, incluso cuando sus presupuestos son limitados, arquitecturas, herramientas y niveles de automatización a los que antes les habría sido difícil acceder.

07Del vibe coding al desarrollo impulsado por IA

Mirando hacia atrás, lo que practico hoy ya no se corresponde realmente con la imagen de improvisación que a veces transmite la expresión vibe coding.

Ya no le pido simplemente a una IA que produzca una aplicación. Le proporciono una arquitectura de destino, convenciones de desarrollo, reglas de seguridad, procedimientos de prueba y restricciones operativas.

Mi papel se parece cada vez más al de un arquitecto o de un director técnico al frente de un equipo virtual: defino el marco, controlo las opciones, valido el resultado y sigo siendo responsable de lo que se entrega.

08¿Y ahora?

Ya he migrado todas mis aplicaciones WINDEV, WEBDEV y WINDEV Mobile a otras tecnologías.

El próximo proyecto será la migración gradual de las aplicaciones de mis clientes que aún tienen contratos de mantenimiento.

Y esa es otra historia: tendré que gestionar las dependencias existentes, los hábitos de los usuarios, los entornos de producción, la recuperación de datos y los compromisos contractuales.

Probablemente este será el tema de una futura serie de artículos.