Vibe coding frente al SaaS: la otra cara del conflicto
El artículo parte de una imagen que circula en LinkedIn y que viene a argumentar que el software generado por IA (lo que se ha popularizado como 'vibe coding') nunca puede llegar a producción real, porque para servir a cientos o miles de usuarios hace falta un stack técnico completo —con capas de seguridad, gestión de…
Por David Hurtado · 23 de junio de 2026.
El artículo parte de una imagen que circula en LinkedIn y que viene a argumentar que el software generado por IA (lo que se ha popularizado como 'vibe coding') nunca puede llegar a producción real, porque para servir a cientos o miles de usuarios hace falta un stack técnico completo —con capas de seguridad, gestión de datos, cumplimiento legal, escalabilidad y despliegue en equipo— que quien programa mediante prompts a una IA simplemente no se plantea. David Hurtado acepta esa premisa como cierta, pero señala que es solo una de las dos caras del problema.
La segunda cara es la que el autor desarrolla en extenso: existe un enorme mercado de software de usuario único —aplicaciones para un autónomo, un equipo de tres personas, o el propio creador— donde ese stack completo es completamente innecesario. Las capas del stack sirven para resolver tres problemas que un usuario en solitario no tiene: escala (mucha gente a la vez), datos compartidos (separar los datos de un usuario de los de otro) y obligaciones con terceros (clientes, contratos, reguladores). Sin esos tres problemas, casi ninguna de las capas adicionales es necesaria.
El autor repasa capa por capa qué se queda y qué desaparece en el escenario de usuario único. Lo que permanece es la aplicación en sí —pantalla, lógica, funcionalidad— y un lugar donde guardar los datos con copia de seguridad, aunque en versiones mucho más simples. Lo que casi desaparece incluye: los permisos por roles (existen para gobernar a muchos usuarios con distintos accesos; con un único usuario-dueño, basta un login sencillo o ninguno), el aislamiento de datos entre usuarios (sin segundo usuario no hay nada que separar), los límites de peticiones (nadie se colapsa a sí mismo), la caché y las redes de distribución de contenido (resuelven la lentitud ante tráfico global; un usuario solo no genera ese tráfico), el cumplimiento legal y los acuerdos de servicio (son promesas a terceros; sin terceros, no hay nadie a quien prometérselas) y toda la maquinaria de despliegue en equipo (existe para que varias personas toquen el mismo código sin pisarse; si programas solo y a ratos, sobra).
En cuanto al aspecto económico, el artículo señala que es la parte que más duele. Durante años, el usuario individual ha estado pagando suscripciones mensuales que incluyen decenas de funcionalidades diseñadas para que el producto pueda servir a cualquier tipo de cliente. Quien solo necesita la herramienta para sí mismo paga por una capacidad enorme que nunca usa. En palabras del autor: 'el SaaS de un solo usuario estaba subvencionando al resto'.
En este punto se introduce evidencia del impacto real. En diciembre de 2024, una frase de Satya Nadella en un podcast sobre el colapso del SaaS se hizo viral. En febrero de 2026, la prensa financiera habló de la 'SaaSpocalypse': el sector software perdió aproximadamente 285.000 millones de dólares en bolsa. Lo llamativo, según el autor, es que la causa no fue que la IA fallara, sino que funcionaba bien: los clientes empezaban a eliminar licencias de usuario en lugar de añadirlas, atacando directamente el modelo de cobro por usuario que sostiene al SaaS tradicional.
Otro dato que apunta en la misma dirección: el 51% de las licencias de software que compran las empresas no se usan, un récord histórico. Es decir, la mitad de lo que se paga no lo toca nadie. A nivel de caso concreto, la empresa Blinkist sustituyó unos 60.000 dólares anuales en SaaS por aplicaciones construidas con herramientas de vibe coding. De ahí emerge lo que el autor llama la 'regla del 90/10': si una herramienta cubre el 90% de lo que necesitas y no te cobra licencia, ese 10% que falta no justifica un pago recurrente.
El artículo subraya una ventaja estructural de quien se programa su propia herramienta: no compite en funciones, gana quitando. El SaaS tiene que servir a todos los casos de uso de todos sus clientes. El vibe coder solo tiene que servir el suyo. Por eso 'el 90% que necesito' le gana al '200% que me venden'.
En cuanto al perfil de quienes practican el vibe coding, el 63% se declaran no-desarrolladores: personas de producto, de marketing, fundadores, diseñadores. El autor ilustra esto con un vídeo de Dot CSV donde, probando la herramienta Fable 5, el creador se monta su propia versión de Notion con, en sus propias palabras, 'las funcionalidades mínimas que necesita'. También menciona que en el último batch de startups de Y Combinator, una de cada cuatro tenía el 95% del código generado por IA, y que Gartner calcula que para 2028 el 40% del nuevo software empresarial se creará con técnicas de vibe coding.
Sin embargo, el artículo matiza la versión más optimista: mucha gente no sabe qué necesita hasta que lo ve. Y ahí el SaaS empaquetado, donde alguien ya hizo ese trabajo de descubrimiento y diseño por ti, todavía tiene valor.
Sobre cuándo sigue ganando el stack completo, el autor es claro: la frontera no está en empresa contra individuo ni en el tamaño ni en el dinero. Aparece exactamente cuando más de una persona necesita ver o tocar los mismos datos. En ese momento son necesarios los roles, los permisos, el aislamiento de datos y casi todo el stack. Y ese coste no sube gradualmente: da un salto brusco al pasar de uno a dos usuarios.
Por último, el autor señala que hay un elemento que nunca desaparece del todo incluso en el escenario de usuario único: guardar bien los datos, hacer copias de seguridad y mantener una higiene mínima de seguridad (no dejar contraseñas expuestas, no abrir la aplicación a internet sin necesidad). Aunque apunta que esto podría resolverse fácilmente fuera de la propia app, siguiendo conceptos como 'file-over-app' y 'local-first software'. El artículo queda inconcluso en el punto de la seguridad del código generado por IA, tema que el autor parece tratar en otras entregas.