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

Desde hace seis meses, he trabajado casi exclusivamente con vibe coding. Al principio, era escéptico respecto de las herramientas cuya ambición declarada parecía ser hacer desaparecer mi profesión principal: analista-programador. Sin embargo, con el tiempo he aprendido a valorarlos, 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: características que ya había desarrollado decenas de veces y que casi siempre lograba siguiendo los mismos principios. Crear una ficha de cliente es un buen ejemplo.

Al principio, mis prompts eran muy básicas: Créame 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 fachada estaba limpia y el programa funcionó.

Pero nada más abrir la portada descubrí un código comparable al de un becario de primer año de informática: funcional, ciertamente, 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 directivas:

Quiero una arquitectura de tres tercios. El acceso a la base de datos debe realizarse a través de una API. Utiliza una pila de tecnología 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 costos con modelos locales

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

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

Al inicio todo salió bien. Tan pronto como el proyecto creció, el agente comenzó a dar vueltas, 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 cumplen sistemáticamente los estándares 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 del contexto está mucho menos presente, pero ciertas tareas de desarrollo siguen siendo particularmente largas.

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

03De POC al uso profesional

Mi primer caso de uso profesional real fue la migración de un proyecto API desarrollado con WinDev a otra tecnología. Volveré más específicamente a mi metodología en un artículo futuro.

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

Así que decidí cambiar la pila de tecnología, aprovechando la operació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 idioma, continuaron utilizando la base de datos HFSQL existente a través de un controlador ODBC, mientras que ahora operan 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 pregunté:

Lanzar una campaña de prueba sobre mis API, proporcionarme una tabla de Excel con todos los escenarios ejecutados y corregir las averías detectadas.

Ese día tuve mi segunda gran sorpresa. El sistema identificó anomalías que no sospechaba, corrigió las fallas y luego publicó 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 administrador de fuentes 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 le permite consultar repositorios, historial, ramas y archivos, como GitHub, sin dejar de estar autohospedado.

Empujé mis fuentes al repositorio y encontré un administrador 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 sólo unos pocos pasos me encontré con un gestor de fuentes y documentación mucho más completo que el GDS que llevaba más de diez años utilizando.

05Mi archivo Markdown de reglas de desarrollo

Como muchos desarrolladores, creo firmemente en el mínimo esfuerzo. Escribir un mensaje 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 a favorecer 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;
• crear vistas y componentes reutilizables;
• el uso relevante de la herencia y el polimorfismo;
• la implementación de hilos, eventos o el jefe observador cuando esté justificado;
• el uso de llamadas asíncronas para evitar recargas innecesarias;
• limitar bibliotecas innecesarias y dependencias difíciles de mantener;
• 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 cuya formalización suele requerir largas fases arquitectónicas.

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

Llego 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.

Por otro lado, 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. Hemos estudiado, acumulado experiencia, tenido proyectos exitosos y otros que fueron más difíciles.

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

La IA no elimina 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.

07De vibe coding al desarrollo impulsado por IA

Mirando hacia atrás, lo que practico hoy ya no se corresponde realmente con la imagen improvisada 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 está acercando progresivamente 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?

Hoy convertí 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: será necesario 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.