Codificación de vibraciones, después de la luna de miel.
· 6 min read · Filippo Spinella · AI, Coding, Agents, Developer Tools
La codificación de vibraciones es una de esas expresiones que parecen nacidas para ser odiadas y luego, poco a poco, se vuelven útiles.
Al principio suena así: no pienso, le pregunto a la IA, acepto lo que sale, sigue adelante. Una forma alegre de producir deuda técnica con trasfondo musical.
Pero sería demasiado fácil descartarlo así. La verdad es que vibe coding ha interceptado algo real: programar con un modelo cambia la relación entre idea y prototipo.
Primero tuviste un pensamiento y luego una larga subida. Muchas veces tienes un pensamiento y media hora después algo se mueve en la pantalla. Es difícil no dejarse seducir por ello.
La pregunta interesante, en 2026, no es si la codificación de vibraciones es cierta. Es. La pregunta es: ¿qué pasa después de la luna de miel?
El prototipo se ha vuelto económico.
Esta es la parte más importante.
Las herramientas de inteligencia artificial han reducido el costo emocional de comenzar. Antes, si querías probar una idea, ya tenías que esforzarte: elegir pila, crear proyecto, recordar texto estándar, escribir diseño, conectar API, discutir con detalles aburridos.
Ahora puedes decir: dame una primera versión.
Y llega una primera versión.
No siempre hermosa. No siempre es correcto. A menudo frágil. Pero llega. Y cuando llega, cambia la conversación. Ya no estás discutiendo en el vacío. Estás tocando algo.
Esto es muy poderoso para diseñadores, fundadores, gerentes de producto, desarrolladores senior cansados de reescribir andamios, personas curiosas que antes no habrían abierto un editor.
La codificación Vibe es una exageración porque le da a más personas la sensación física del software que se está creando.
El problema es que el software sigue vivo.
La parte que menos cuenta el meme es el día después.
El prototipo debe ser leído. Correcto. Probado. Implementado. Asegurado. Lo conseguí de otra persona. Conectado a datos reales. Hecho accesible. Se mantiene cuando cambia una dependencia.
Aquí la codificación de vibraciones puras choca contra la pared.
Un modelo puede generar una gran cantidad de código rápidamente, pero el código no es valor en sí mismo. Es una promesa de comportamiento. Y una promesa debe ser verificada.
El riesgo de la codificación vibe no es escribir código feo. Siempre lo hemos hecho incluso sin IA. El riesgo es perder el sentido de propiedad: "el modelo lo hizo" se convierte en una excusa para no entender lo suficiente.
Pero el tiempo de ejecución no acepta excusas. Si el código se ejecuta en producción, es tuyo.
De la codificación de vibraciones a la ingeniería de agentes
La versión madura de la codificación vibe es no dejar de usar agentes. Es para usarlos con un ciclo más serio.
No: genera todo y esperamos.
Pero:
- describir la intención;
- dejar generar un borrador;
- pedirle al agente que le explique el plan;
- hacer pequeñas diferencias;
- pruebas de lanzamiento;
- hacer revisiones;
- correcto;
- solo entonces únete.
Esta cosa merece un nombre diferente. Me gusta la ingeniería de agentes, aunque suene un poco solemne. Significa utilizar agentes no como máquinas tragamonedas, sino como colaboradores dentro de un proceso de ingeniería.
El punto no es quitarle energía a la codificación de vibraciones. Le está dando pistas.
Donde funciona muy bien
La codificación Vibe funciona cuando el costo del error es bajo y el valor de la exploración es alto.
Ejemplos:
- prototipos de interfaz;
- herramientas personales;
- paneles de control internos;
- pequeños juegos;
- guión único;
- Escaneos API;
- prueba de concepto;
- refactores mecánicos con buenas pruebas;
- contenidos técnicos que se transformarán en demostraciones.
En estos casos la velocidad es el punto. Quieres ver si la idea tiene piernas. Quieres descubrir lo que no entendiste. Quieres llegar a una conversación concreta.
La codificación Vibe es perfecta para hacer emerger la forma.
Donde se vuelve peligroso
Se vuelve peligroso cuando el sistema tiene consecuencias y nadie frena.
Pagos, datos personales, autenticación, permisos, infraestructura, migraciones de bases de datos, código heredado confidencial, cumplimiento, producción. Aquí la vibra no es suficiente. Necesitamos rigor.
Eso no significa que la IA no pueda ayudar. De hecho, puede ayudar mucho. Pero debe funcionar dentro de límites estrechos: rama, zona de pruebas, prueba, pelusa, revisión, indicador de función, reversión.
La frase a tatuar en el monitor es sencilla: cuanto más rápido sea el agente, más legible debe ser el proceso.
Si no puedes explicar qué ha cambiado, no has acelerado. Simplemente transfiriste la deuda del tiempo al entendimiento.
El nuevo rol del desarrollador
Lo más interesante es que el trabajo del desarrollador no desaparece. Cambiar densidad.
Menos tiempo en texto estándar. Más tiempo para la intención, la descomposición, la revisión, la integración, las pruebas, los límites.
El desarrollador se convierte en una especie de editor técnico. No en el poco convincente sentido de "correcciones". En sentido fuerte: decide qué debe existir, qué debe recortarse, qué es coherente con el sistema, qué merece confianza.
Un buen editor no se queda con todo lo que recibe. Ni siquiera lo reescribe todo por orgullo. Reconoce el buen material, le da forma, protege al lector.
Con los agentes, el lector es también el futuro mantenedor. A menudo, ese eres tú en tres semanas.
El patrón que veo emerger
El patrón más saludable es este:
- humano: intención, limitaciones, gusto, responsabilidad;
- agente: variantes, andamiaje, búsqueda, modificaciones locales, pruebas repetitivas;
- infraestructura: sandbox, CI, rastreo, permisos, implementación;
- equipo: revisión, propiedad, estándares.
Cuando falta una de estas piezas, algo se deforma.
Sólo humano: lento, a menudo empantanado por un trabajo repetitivo.
Sólo agente: rápido, pero sin juicio situado.
Infraestructura justa: proceso elegante para producir cosas inútiles.
Solo equipo: reuniones muy ordenadas en torno a un prototipo que nunca llega.
Lo mejor sucede cuando las piezas hablan entre sí.
Una pequeña lista de verificación
Antes de dejar crecer un prototipo codificado por vibración, me haría estas preguntas:
- ¿Entiendo la estructura del código?
- ¿Existen pruebas de comportamiento crítico?
- ¿Sé qué archivos tocó el agente?
- ¿He eliminado el código generado pero no utilizado?
- ¿Algún secreto, token o información falsa ha terminado en el lugar equivocado?
- ¿Se respeta la accesibilidad mínima?
- ¿La implementación tiene reversión?
- ¿Alguien además de mí puede quedárselo?
Si la respuesta a demasiadas preguntas es no, no es un fracaso. Es sólo un prototipo que necesita seguir siéndolo un poco más.
Mi lectura
Vibe coding es una palabra fuerte para algo tierno: la alegría de ver cómo una idea toma forma antes de que el miedo la detenga.
No quiero tirarlo. Eso sería esnob. Muchas cosas buenas nacen así, medio torcidas y vivas.
Pero el software restante necesita más. Necesita comprensión, pruebas, propiedad, infraestructura, límites. Necesita que alguien diga: genial, ahora hagámoslo realidad.
Quizás el futuro no se trate de elegir entre programación "seria" y programación "vibratoria". Tal vez sea aprender a cambiar de marcha: explorar a la ligera y luego consolidar con respeto.
La parte humana está ahí. Sepa cuándo correr y cuándo sentarse y leer la diferencia.
Fuentes
- Simon Willison: No toda la programación asistida por IA es codificación por vibración
- OpenAI: Cómo la gente usa ChatGPT
- Blog de GitHub: agente de codificación GitHub Copilot
- [Antrópico: Construyendo agentes efectivos](https://www.anthropic.com/engineering/building- Effective-agents)
- [Blog de Stack Overflow: Por qué la codificación vibe es el futuro] (https://stackoverflow.blog/2025/04/21/why-vibe-coding-is-the-future/)