El vibe coding es el nuevo Excel (y está bien)

Hace unos días, Klaas (@forgebitz) publicó esto en X:

"i have no time to maintain all my vibe coded tools
we need a business model where someone else maintains the code and i just pay a monthly fee"

En castellano: no tengo tiempo de mantener todas las herramientas que armé con vibe coding; necesitamos un modelo de negocio en el que otro mantenga el código y yo pague un abono mensual.

Es un chiste, claro. Ese modelo de negocio existe hace más de veinte años y se llama software como servicio. Pero como todo buen chiste, dice algo cierto: construir una herramienta con IA hoy lleva una tarde, y mantenerla viva lleva el resto de su vida útil. Lo que pasa con esas herramientas ya lo vimos antes, con otra tecnología.

Antes fue Excel

Cuando aparecieron las planillas de cálculo, las personas que llevan adelante el negocio las adoptaron enseguida. No necesitaban pedirle nada a nadie: armaban una planilla para controlar el stock, otra para las comisiones, otra para el presupuesto del área. Simplificaban su gestión y resolvían problemas reales, en el momento.

Con el tiempo, esas planillas evolucionaron. Sumaron fórmulas, macros, hojas vinculadas, datos que alimentaban otras planillas. Muchas se volvieron imprescindibles. Y muchas terminaron siendo el punto de partida de aplicaciones: el día que la planilla ya no alcanzaba, alguien la tomaba como especificación y construía el sistema que hacía lo mismo, pero bien.

Las planillas no fueron un error. Fueron la forma en que el negocio expresó lo que necesitaba, antes de que alguien lo convirtiera en software.

El vibe coding es el nuevo Excel

Con el vibe coding pasa lo mismo, a otra escala. Hoy una persona que conoce bien su proceso le describe a un asistente de IA lo que necesita y en poco tiempo tiene una aplicación funcionando: con pantallas, con una base de datos, con usuarios.

Muchas empresas grandes lo están alentando de manera explícita: quieren que los responsables de cada área se hagan sus propias apps, sin esperar un lugar en la planificación de Sistemas. Y tiene sentido. Esas apps son útiles, las construye quien mejor entiende el problema y la productividad sube.

En Flowing Code no estamos en contra. Nos parece bien. Igual que con Excel, es la forma más rápida de que el negocio diga qué necesita, y muchas veces de que lo resuelva sin ayuda.

Nacen, se usan, se multiplican

El ciclo es conocido. Las apps nacen para resolver algo puntual, se usan, funcionan y se multiplican: una para el área de compras, otra para seguir reclamos, otra para aprobar gastos.

Algunas pueden quedarse así para siempre, y está bien. Una herramienta que usan tres personas para ordenar su trabajo no necesita más que eso.

Otras crecen. Suman usuarios de otras áreas, empiezan a guardar datos sensibles, se conectan con otros sistemas o las terminan usando clientes externos. En ese momento, mantenerlas y encarrilarlas pasa a ser responsabilidad de Sistemas. Es lo que pasaba con las planillas críticas, y es lo que hoy están viviendo las áreas de Sistemas de muchas empresas grandes: un inventario creciente de aplicaciones que nadie planificó, que funcionan, que el negocio necesita, y que alguien tiene que sostener.

Señales de que una app necesita pasar de nivel

No todas las apps tienen que dar el salto. Pero hay señales bastante claras de que una lo está pidiendo:

• Seguridad. Maneja datos personales, financieros o de clientes, y nadie revisó cómo autentica, quién puede ver qué ni cómo se protegen esos datos.
• Rendimiento. Con pocos usuarios andaba bien; con más datos o más gente, empieza a tardar.
• Escalabilidad. Se pensó para un área y ahora la quieren usar otras, u otras empresas.
• Auditoría. Alguien pregunta quién cambió un registro, cuándo y por qué, y no hay forma de responder.
• Nadie sabe cómo funciona. El código lo escribió la IA, funciona, y nadie del equipo podría explicar qué hace cada parte.
• Depende de una persona. Si quien la armó se va de vacaciones o cambia de puesto, la app queda huérfana.

Si una app de tu organización muestra dos o tres de estas señales, ya no es una herramienta personal: es un sistema, y necesita que la traten como tal.

Un caso real

Hace poco nos pasó con un cliente. Tenía una aplicación construida con vibe coding que había funcionado muy bien, tan bien que fue creciendo y, todo indica, va a terminar siendo un producto que ofrezcan a sus propios clientes.

Con ese crecimiento detectaron que no era escalable ni tenía el rendimiento necesario para lo que se le venía, y nos llamaron para hacer un análisis. Lo hicimos, y hoy estamos trabajando con ellos para hacerla evolucionar, aplicando lo que sabemos de seguridad, rendimiento y escalabilidad.

Lo importante de este caso es que no tiene nada de raro. Que una app nacida en el negocio crezca más de lo previsto es normal; es casi la prueba de que era una buena idea. Lo que hay que hacer es resolverlo a tiempo, antes de que el problema lo detecten los clientes.

Dos caminos para la siguiente etapa

Pasarla en limpio

Cuando una app ya se volvió seria, importante y compleja, en Flowing Code la tomamos, la pasamos en limpio y la convertimos en un producto interno o externo con todo lo que un desarrollo empresarial necesita: una arquitectura que se pueda entender y mantener, seguridad revisada, rendimiento medido, pruebas, auditoría, despliegues ordenados y un equipo que la conoce.

No se trata de tirar lo que hizo el negocio. La app existente es la mejor especificación posible: muestra qué se necesita, cómo se usa y qué funciona. Igual que pasaba con las planillas, es el punto de partida.

Darle un carril desde el principio

El segundo camino sirve para las apps que todavía se están construyendo, o para las que conviene encauzar antes de que crezcan. Casi todas las aplicaciones de negocio necesitan lo mismo: usuarios y permisos, auditoría, envío de correos, reportes, configuración. Si cada app vibecodeada resuelve eso a su manera, Sistemas termina manteniendo diez logins distintos y diez formas de auditar.

AppJars da ese carril. Lo común viene en componentes vivos, que se mantienen y actualizan afuera de cada app, y la IA se dedica solo a lo propio de cada aplicación. Es, en serio, el modelo que pedía el tuit: alguien más mantiene esa parte del código. Lo explicamos en detalle en el artículo AI made building apps cheap. Owning them still isn't. (en inglés).

Que el negocio construya

El vibe coding llegó para quedarse, como llegó Excel. Las áreas van a seguir construyendo sus herramientas, y está bien que lo hagan: es una de las mejores formas de mejorar la productividad que tienen hoy las empresas.

Lo que conviene es tener claro qué pasa después. La mayoría de esas apps van a estar bien como están. Algunas van a crecer, y para esas hace falta un camino.

Si en tu organización hay una app que empezó como una solución rápida y hoy pide más, hablemos. Podemos ayudarte a llevarla al siguiente nivel.