Cómo Usar Vibe Coding Sin Hacer un Desastre
1 JUL 2025
El vibe coding está en todas partes últimamente, sobre todo como meme o crítica dirigida a personas que intentan construir software sin saber realmente cómo programar. Pero... ¿qué pasa cuando lo usa un ingeniero experimentado resolviendo un problema real?
El vibe coding está en todas partes últimamente, sobre todo como meme o crítica dirigida a personas que intentan construir software sin saber realmente cómo programar, o a reemplazar desarrolladores con IA.
Pero... ¿qué pasa cuando lo usa un ingeniero experimentado resolviendo un problema real?
Spoiler: el problema no era la IA. Era yo, pensando en TypeScript mientras programaba en Python.
En este post quiero compartir cómo pasé de un PoC generado por IA con vibe coding lleno de ideas forzadas a una solución robusta, limpia y 20 veces más rápida. No para convencerte de usar IA, sino para mostrarte cómo puedes beneficiarte realmente de ella sin olvidar los principios de buen diseño.
De una Prueba de Concepto a una Idea Funcional (con GitHub Copilot)
Antes de sentarme a escribir código durante horas, prefiero planificar lo que quiero construir usando Design Docs (si quieres que escriba sobre eso, dime en los comentarios). Así que empecé a pensar en la arquitectura que necesitaría para resolver mi problema: una forma de analizar fragmentos semánticos de documentos grandes para mejorar el contexto y la precisión en RAGs.
Una vez que tuve la arquitectura, empecé a pedirle a Copilot que escribiera diferentes partes. Y aquí fue donde cometí mi primer error conceptual: estaba pensando en TypeScript, no de forma "pythonica".
He estado usando Nest.js durante años, y me acostumbró a una forma específica y poderosa de construir aplicaciones, donde es común definir lógica y metadatos usando decoradores. Mi plan, descrito en el Design Doc, seguía esa filosofía:
- Definiciones de nodos con clases y decoradores de propiedades:
Imaginé clases para cada tipo de nodo (como Rule, Article, Paragraph) y decoradores como@TokenType('RULE')o@IsRequired()en las propiedades. - Un TreeBuilder centralizado e inteligente:
Introspeccionaría las clases, leería los decoradores y metadatos, y construiría el árbol. - Herencia solo para anidamiento, no para comportamiento:
La lógica principal vivía dentro del TreeBuilder, no en los nodos mismos.
Con esta mentalidad estilo TypeScript, la IA era el compañero de código perfecto. Como un desarrollador junior con mucho conocimiento pero sin criterio, hacía exactamente lo que le pedía: metaclasses, introspección, magia.
Y sí, el código funcionaba. Cumplía todos los requisitos del Design Doc. El PoC fue un éxito. Pero el código se sentía desordenado y sobreingenierizado. Parecía un proyecto TypeScript con sintaxis Python.
Refactorizando con Ingeniería de Software Real: Del "qué" al "cómo" idiomático
Aquí es donde empieza la verdadera ingeniería. Con el PoC validado, volví al Design Doc—no para cambiar el objetivo, sino para repensar la implementación.
El código era el resultado de pedir una "traducción" de un patrón, en lugar de pedir una solución "pythónica". Así que decidí refactorizarlo. Esta vez, yo era el arquitecto, y la IA era solo mi asistente.
Decisiones clave:
- Reemplazar decoradores y metaclasses con herencia básica.
- Usar
dataclassespara estructuras solo de datos. - Eliminar la lógica del constructor central y dejar que cada clase se construya a sí misma.
Seguí usando la IA, pero ahora con instrucciones más precisas:
"Convierte esto a un dataclass", "Sugiere un método para la clase base", y así sucesivamente.
El Impacto Medible de la Simplicidad
Después de refactorizar, escribí pruebas de rendimiento usando un documento grande y complejo para comparar ambas versiones. Y los resultados fueron claros:
| Métrica | PoC (versión inicial con IA) | Refactorizado (guiado por humano-IA) | Mejora |
|---|---|---|---|
| Tiempo de ejecución promedio | ~10 s | < 0.5 s | 🚀 ~2000% más rápido |
| Precisión de reconstrucción | 100% | 100% | Igual |
| Cobertura de nodos | N | N + 10 | 👍 Mejorada |
La nueva versión no solo era más rápida—también era más inteligente, más legible y más fácil de mantener. Todo porque elegí la simplicidad y el buen diseño.
Reflexiones Finales: Nuestro Rol en la Era del Vibe Coding
Este proyecto me enseñó algo importante: el vibe coding con IA es increíble para prototipado rápido. Nos permite explorar ideas rápido.
Pero cuando el código "funciona", ahí es donde empieza nuestro verdadero trabajo.
La IA no es una amenaza para los desarrolladores que entienden los principios de ingeniería de software. Es una herramienta. El mejor asistente que hemos tenido. Nuestro futuro no se trata de ser reemplazados, sino de convertirnos en mejores arquitectos, mejores guías y mejores artesanos del software.
¿Has pasado por algo similar usando IA para programar? ¿Quieres que escriba más sobre Design Docs o estructuras de proyectos Python? Me encantaría saber de ti en los comentarios.