Un ciclo que solo se repite

El Vibe coding está muy cerca de cumplir una promesa que lleva más de 40 años dando vueltas: democratizar el desarrollo de software y reducir, si no eliminar, la barrera de entrada. Esta idea no es nueva, en los 80 las herramientas CASE intentaron construir software simplemente uniendo componentes pre escritos, ya no necesitabas escribir código, solo unir cajas en un diagrama, simple, limpio. Spoiler: no funcionó. El software probó ser más complejo, necesitabas entender bien los componentes y para complicarlo cada nuevo caso requería hacer cambios en los componentes así que al final igual necesitabas saber programar.

Saltamos a mediados de los 90, Excel ya incluye VBA y está en cada escritorio, con la inclusión de macros vuelve a aparecer la promesa: ahora podías programar y manipular datos, si sumabas Access VBA Enabled tenías una base de datos y con eso todo lo necesario para una aplicación funcional en tu computadora de escritorio. Aún necesitabas saber programar, pero saber lo básico era algo que podía aprenderse en un par de meses o menos, y esa combinación de facilidad de acceso a las herramientas y al conocimiento creó a “Dave”.

Dave es ese profesional que ya trabajaba o que era contratado por un área para atender todo lo que no era prioridad para el área de IT, desarrolló sus propias aplicaciones: una macro de 5,000 líneas que corría el sistema de reportes. Dave se jubiló hace cinco años: nadie sabe cómo funciona lo que hizo, cómo arreglarlo, ni cuándo va a explotar, fuera del radar de IT, fuera de los estándares y controles de seguridad y sin documentación, pero: resolvía problemas de la organización. Todo esto recibió un nombre: Shadow IT.

Luego tuvimos el Low Code, que era un reframe del CASE (y para confirmar que la historia se mueve en ciclos): manejo de flujos, conectores y uso de APIs, solo era conectar y configurar y así automatizar flujos y apps internas sin escribir una línea. Funcionó parcialmente, ya que aún se necesitaba que aprendieras sobre flujos de datos, APIs y parámetros, esto seguía siendo una barrera significativa.

La idea siempre ha sido la misma: tener la capacidad de resolver algo cuanto antes. En una época donde el volumen de información es inmanejable de manera manual, esto es una necesidad para sobrevivir, y el problema siempre es el mismo: se baja la barrera, los usuarios la cruzan y la organización se da cuenta tarde. El problema es que hasta ahora tenías que aprender algo: código, macros, parámetros y APIs, algo, aunque sea un poco. Hasta ahora.

Entra el vibe coding

En febrero de 2025 nace el término vibe coding de la mano de Andrej Karpathy y se produce un punto de inflexión, donde la barrera, si es que aún está, llegó a su punto más bajo. Como ya dije, siempre había alguna barrera, una puerta que abrir. Hoy cualquiera con un navegador y acceso a internet puede usar herramientas de IA, describir lo que quiere y listo, lo tienes. No tienes que entender cómo se hizo ni cómo funciona, de hecho probablemente ni siquiera interesa, y ahí está el real peligro: si eso no interesa, tampoco interesan los problemas de seguridad, ni los estándares, ni el impacto más allá de resolver tu problema. Solo acceso a la herramienta, y ese es un detalle importante, porque ese acceso muchas veces lo da la propia empresa.

Había mencionado el Shadow IT y este es su regreso, pero patrocinado. El renacimiento de Dave, solo que ahora no necesita saber programar: tú, yo, ellos, todos somos Dave.

Una moneda de dos caras

Hay algo que es importante aclarar: no veo algo malo per se en el vibe coding. Lo considero una herramienta y como tal resuelve un problema específico, y es tan buena o mala como quien la usa, fuera de la calidad o la buena ingenieria se trata de poder ir de la idea a algo que funciona. Además hay un movimiento muy fuerte de solopreneurs que justamente hace eso: una persona usando vibe coding prepara un MVP en un fin de semana, no necesitas un equipo, solo la idea, acceso a la herramienta y a probar. Todo es de la persona: sus datos, su riesgo, su responsabilidad, y siempre dentro de una prueba. Ese es el caso de uso adecuado y funciona porque los límites están claros desde el inicio.

Pero tenemos otro lado de la moneda. En QCon los llamaron builders: empleados de una organización con acceso a sistemas y datos que no les pertenecen, necesitan resolver algo: un reporte que tarda 3 días en hacerse, un proceso manual que consume horas cada día, tienen el mismo entusiasmo, pero un nivel de riesgo e impacto totalmente distintos. Es una fuerza que nace del equipo, que si se deja sin control puede causar daños, pero que si se aprovecha puede ser una ventaja decisiva frente a la competencia. Para eso es necesario entender sus necesidades y ayudarlos a entender que construir dentro de una organización no es lo mismo que hacerlo para ti mismo. El verdadero desafío es integrarlos de manera que haya beneficio para ambas partes.

La tarea pendiente

Estamos en una época de inmediatez. Hoy un builder puede construir algo en un fin de semana, y con las herramientas que la propia compañía le dio.

Líderes Empiecen a mirarlo como un desafío. Se dieron las herramientas correctas, pero por alguna razón (hype, presión de mercado, lo que sea, no importa) se hizo antes de definir el governance adecuado y están ahí, no sabemos ni cuántas aplicaciones ni a qué datos acceden, y más importante, están resolviendo algo. La solución no es restringir el acceso, ese momento ya pasó y envía el mensaje equivocado. Una mejor alternativa es crear canales formales para canalizar los esfuerzos y ganar visibilidad: sandboxes con datos de prueba, aligerar procesos cuando sea posible, y dejar reglas claras de qué tanto se puede hacer sin una aprobación, pero dando visibilidad a IT.

Builders La intención es buena, estás resolviendo un problema que nadie más priorizó, y eso tiene valor y debe ser reconocido. Dicho eso: construir dentro de una organización implica más de lo que se ve a simple vista y va más allá del problema puntual que quieres resolver. Si además es una industria regulada, hay temas de compliance que observar. Esto no es para asustar ni para que no se haga, sino para tener las conversaciones adecuadas y dar visibilidad antes de hacerlo.

Hoy tenemos un renacimiento del Shadow IT, hay miles de Dave resolviendo problemas con herramientas más poderosas y muchas veces dadas por la propia empresa. Usar la vieja estrategia de prohibir y restringir solo pone trabas que penalizan esta creatividad. Son las organizaciones y sus líderes quienes deben trabajar en mantener el ritmo creando canales adecuados, quienes lo hagan mostrarán que han aprendido algo de una historia que se repite y vuelve a empezar.