Vibe coding: rápido para empezar, caro para sostener

En pocos minutos hay algo que funciona. Alguien le pide a una IA una pantalla, un servicio o una integración, la IA la escribe, y anda. Es difícil no entusiasmarse, y el entusiasmo tiene fundamento: la IA escribe código mucho más rápido que una persona. Pero que algo funcione hoy no dice si va a escalar, si es seguro o si respeta los estándares del equipo.

A esa forma de trabajar se la llama vibe coding: ir pidiéndole a la IA lo que se necesita, con las palabras que cada uno encuentra en el momento (el prompt), y validar por el resultado: si funciona, se sigue. Privilegia el diálogo y la prueba rápida por sobre definir antes qué se va a construir.

Para explorar una idea o armar un prototipo, es una forma excelente de trabajar. El problema empieza cuando ese código exploratorio pasa a ser software que la organización tiene que mantener, y cuando se vuelve la forma de desarrollar de todo un equipo.

Lo que el vibe coding no construye: una forma de trabajar

Cuando cada desarrollador trabaja con la IA a su manera, lo que se construye depende de dos cosas: el criterio de esa persona y lo que la IA interpretó del pedido que se escribió sobre la marcha. No hay una forma de hacer las cosas que sea de la empresa. Hay tantas como personas, y cada una cambia con cada pedido.

Eso tiene cuatro consecuencias:

• Lo que sale bien no queda incorporado. Aunque una iniciativa individual sea exitosa, depende de esa persona y de ese pedido, y no pasa a ser parte de la forma de trabajar del resto del equipo.
• Lo que sale mal es difícil de explicar. Aunque las conversaciones queden guardadas, revisar todas las interacciones es trabajoso, y comparar si un pedido funcionó mejor que otro, más todavía.
• El conocimiento se va con la persona. Cuando alguien deja el equipo, se lleva su forma de trabajar con la IA, y con ella la explicación de buena parte de lo que construyó.
• La calidad queda librada a cada uno. Sin reglas comunes, cada funcionalidad sigue un criterio distinto: soluciones que funcionan pero no escalan, seguridad que no respeta ningún estándar, y una deuda técnica que crece como una bola de nieve, porque cada arreglo apurado se apoya en el anterior.

El conocimiento tiene que quedar en la empresa, no en el prompt de alguien

La alternativa es que los agentes de IA que usa el equipo trabajen con reglas compartidas: cómo se estructura el código, qué patrones se usan, qué no se hace nunca y cómo se prueba. Esas reglas no se escriben una vez y se olvidan. Se van alimentando: cada vez que algo sale bien o mal, se ajustan, y todo el equipo trabaja con la versión mejorada.

No es una idea nueva. La estudié hace años en mi tesis del MBA, que trató justamente sobre la gestión del conocimiento en las empresas de software de Rosario. El problema es el mismo de siempre; lo que cambió con la IA es la velocidad a la que se paga no resolverlo. Es lo que Ikujiro Nonaka e Hirotaka Takeuchi describieron en The Knowledge-Creating Company (1995): el conocimiento que una organización necesita suele estar en la cabeza de las personas, en lo que saben hacer pero no está escrito. Una empresa aprende cuando ese conocimiento se vuelve explícito, se comparte, se combina con el de otros y vuelve a las personas como una mejor forma de trabajar.

Las reglas compartidas hacen eso con la IA: convierten el criterio de los mejores del equipo en algo que todos usan. Son una parte; las otras dos son las especificaciones y las pruebas.

Especificar, sí. Burocracia, no.

Para trabajar así, lo primero es especificar: escribir qué se va a construir antes de pedírselo a la IA. Es la idea del desarrollo guiado por especificaciones (Spec-Driven Development, o SDD), que ya tiene varios marcos de trabajo en el mercado: Spec Kit, de GitHub; Kiro, el entorno de desarrollo de Amazon; o el método BMAD, por nombrar los más conocidos.

El problema de adoptar uno de esos marcos tal cual es que no necesariamente se adapta a la forma de trabajar de un equipo ni al tamaño de lo que construye. En un sistema chico, donde trabajan dos o tres personas, un marco pensado para proyectos grandes es pura burocracia.

Y hay una trampa peor. Si el proceso genera tanta documentación que nadie la puede leer, nadie la revisa. Se pierde a la persona que revisa lo que hace la IA, lo que se conoce como human-in-the-loop (HITL), y se vuelve al mismo lugar que el vibe coding, con más papeles.

El criterio es simple de decir y difícil de sostener: la especificación tiene que ser tan precisa como para que la IA sepa qué construir, y tan breve como para que una persona la lea y la apruebe antes de que exista el código. Si falta información, la IA la completa por su cuenta; si sobra, nadie la revisa.

Queda una objeción razonable: ¿no estamos cambiando escribir código por escribir especificaciones? En parte, sí, y está bien que así sea. La especificación dice qué se quiere y con qué restricciones; el código, cómo se hace. Si la IA abarata el cómo, tiene sentido que el esfuerzo de las personas se corra hacia decidir qué construir y cómo verificarlo.

Las pruebas son las que dicen si se construyó bien

Una especificación dice qué hay que construir. Las pruebas dicen si lo que se construyó es eso. Sin ellas, no hay forma de saberlo: que el código funcione no significa que haga lo que se pidió.

Importa de dónde salen. Si la misma IA escribe primero el código y después deriva las pruebas de ese código, las dos comparten los mismos supuestos, y también los mismos errores: las pruebas pasan, pero no prueban lo que se pidió. Por eso conviene que salgan de la especificación. Así, especificación y pruebas funcionan como una fuente de verdad independiente del código.

Nada de esto contradice a las metodologías ágiles: el manifiesto prioriza software funcionando por sobre documentación exhaustiva, no propone no documentar, y escribir las pruebas antes que el código es una práctica ágil de hace veinte años. Y el código, por más claro que sea, dice lo que hace, no lo que se quería que hiciera.

Y lo que se mide tiene que ser el recorrido completo

Con reglas, especificaciones y pruebas, la IA rinde, pero que el código se escriba más rápido no significa que al cliente le llegue más rápido. La codificación es solo una parte del tiempo que pasa desde que surge una necesidad hasta que está en producción, y cuando se acelera, el cuello de botella se corre al requerimiento, a la revisión y a la validación.

Además, hay que contar las iteraciones: las veces que algo vuelve para corregirse. Si se mide hasta la primera versión, el vibe coding gana siempre, porque ahí es donde es rápido. El costo aparece después: cada error que vuelve, cada corrección y cada vez que algo que “ya estaba” hay que abrirlo de nuevo. La pregunta no es cuánto se tardó en escribir el código, sino cuánto se tardó en poner en producción la funcionalidad que se pidió, con todas las correcciones incluidas. Medido así, el resultado puede ser otro: puede haber mejora, puede no moverse, o puede empeorar. Es el número que importa, y además dice dónde está el próximo problema.

La pregunta de fondo

La discusión sobre IA en el desarrollo suele girar alrededor de qué herramienta o qué modelo usar. Es una decisión que hay que tomar, pero no la más importante: los modelos y las herramientas cambian todo el tiempo.

La que importa es qué forma de trabajar le queda a la empresa cuando cambie la herramienta, o cuando alguien deje el equipo. Con vibe coding, ninguna. Con reglas compartidas, especificaciones que se pueden leer y pruebas que dicen si se construyó bien, queda un conocimiento que es de la empresa, una calidad que no depende de quién escribió qué, y las dos mejoran con el tiempo.