Navegar hoy en día por las redes sociales es una misión imposible: anuncios de cursos de IA que prometen milagros gestionando carteras, pseudoinfluencers que se hacen pasar por expertos al ojo poco entrenado —consiguen el verificado pagando y se lucran con empresas deseosas de gastar ingentes cantidades de dinero en spam— y, lo que más me revienta, el clickbait fácil de los vibe coders:
“El SaaS está muerto, he construido esta increíble aplicación en 3 minutos sin tocar una línea de código y ya está en producción gracias a {inserte aquí empresa que monta una capa de agentes limitada sobre modelos comerciales}”.
Vale, respira. Yo también dejaría de leer a la tercera palabra ante semejante insulto a la inteligencia humana. Ni los bots que inflan las estadísticas de sus publicaciones se sentirían orgullosos si tuvieran alguna conciencia de su labor.
¿Está el SaaS muerto ante el avance inexorable de los LLM?
¿Es ese chaval intoxicado por su propio humo —el que intenta vender a golpe de demo— capaz de construir un producto igual o mejor que aquel que ha llevado años de desarrollo, conocimiento experto y miles de iteraciones con clientes para ajustarse a sus necesidades? Vayamos por partes.
Montar un frontend vistoso —un calendario bonito o un dashboard de finanzas personales cuyo backend, en el mejor de los casos, es una conexión sencilla a MongoDB sin apenas lógica— no es tener un SaaS. Un prototipo visual con mínima lógica de negocio no equivale a un SaaS maduro: carece de robustez, profundidad funcional y garantías operativas que se hacen evidentes cuando se intenta llevar el vibe coding más allá de generar alguna línea de código.
Hoy por hoy no hay ningún sistema potenciado con IA capaz de crear, con un prompt de tres líneas, un producto de software millonario. Así que no, no vas a tumbar a SAP o Salesforce con tu megaprompt de “Haz un SaaS que me haga rico y que yo no tenga que hacer nada”. Las únicas tres líneas que generan esos millones son las del blog de Sam Altman cuando vuelve a anunciar la AGI por enésima vez antes de sacar de nuevo un GPT que sigue creyendo que 3.11 es mayor que 3.9. Pero bueno, dejémosles algo de esperanza para que al menos los piratas que se alimentan de esas API keys expuestas en el código puedan seguir viviendo de algo.
Los agentes: herramientas de potenciación, no de sustitución
El futuro cercano del SaaS, en mi opinión, no es que cualquiera construya su propio SaaS en cinco minutos. Apunta, más bien, a la integración con modelos agénticos. Con la tecnología actual los sistemas de agentes no tienen la capacidad para sustituir y democratizar a tal escala el acceso al desarrollo de software; cumplen más una función habilitadora. Con una base de conocimientos mínima, estos agentes multiplican la productividad y facilitan la transición de las personas de un rol ejecutor a otro supervisor de mayor valor añadido.
Por el lado del producto, no consiste en construir algo nuevo, sino en una potenciación y reajuste de lo existente. La mayoría de los SaaS ya tienen una fortaleza enorme con el estado actual de la tecnología: un conjunto extenso y cohesionado de APIs y endpoints en su backend habilitados para sus servicios. Con buena documentación y una labor de armonización técnica, esas APIs pueden exponerse al LLM mediante tools o servidores MCP para que operen en una capa superior de abstracción, sin necesidad de hacer cambios estructurales profundos o desarrollos a medida, reutilizando esa lógica y herramientas que ya funcionan —y que tanto tiempo y dinero ha costado construir.
Con esto se facilita enormemente la experiencia del usuario, que no tiene que aprender a manejar procesos intrincados ni la jerga interna del producto; basta con pedir en lenguaje natural y con una interacción mucho más humana, incluso multimodal, para que el LLM haga todo el proceso internamente, automatizando y descargando al usuario de tareas de poco valor y focalizando su atención en los aspectos clave de su negocio, no en la multitud de pasos y procesos que tiene que realizar en el software para llegar al resultado.
La revolución que provocará la IA reside en cómo nos relacionamos con los productos. Por utilizar una analogía entendible: es como si el estado actual fuese utilizar la línea de comandos para comunicarnos con el ordenador y la IA supusiera el salto a las interfaces gráficas. Es evidente que el salto no va a ser homogéneo ni igual de acelerado en todas las soluciones y sectores —cuántos sistemas siguen anclados aún en COBOL— pero sí hay una realidad: adaptarse o ser irrelevante.
Habrá sectores en los que, por motivos de seguridad, fiabilidad, escalabilidad o rendimiento, se posponga la adopción, pero no cabe duda de que tarde o temprano el impulso de la demanda forzará el cambio. Los rezagados irán perdiendo cuota a favor de quienes integren IA contextualizada; la nueva barrera de entrada será la calidad acumulada de datos, la experiencia en procesos y el conocimiento estructurado.
La interfaz del futuro: un lienzo en blanco
Si bien en el backend se trata de pequeños ajustes sobre lo existente para potenciarlo, el reto es mayúsculo en el frontend: aquí está la clave, la evolución hacia algo desconocido y volátil.
En mi opinión, hay que transitar desde interfaces detallistas, modulares y cargadas de accesos y funciones, a un lienzo en blanco donde, esta vez sí, la IA construye formas de interacción que se ajustan a lo que busca el usuario. Pasamos de esa función de enlace y ejecución en el backend a un papel creativo y sustitutivo de la praxis actual en el frontend. La IA pasa a ser la encargada de generar pantallas bajo demanda en detrimento de las interfaces rígidas predefinidas y deterministas. Construir un dashboard, una pantalla de carga, un editor… lo que sea: la IA es muy buena generando componentes al vuelo, en el momento. Aunque siempre hay que tener en mente que se construyen sobre las funcionalidades existentes en el backend y que deben recibir indicaciones precisas en el system prompt para preservar uniformidad, estándares de calidad y salvaguardas mínimas (policy engine, validación de componentes).
La empresa debe cambiar: el conocimiento ya no es solo para humanos
Para que el sistema agéntico gane autonomía y capacidad, la filosofía empresarial debe cambiar. Los análisis funcionales, los documentos de desarrollo y casi cualquier otra información no deben concebirse solo para la lectura humana: todo debe orientarse a que sean legibles y procesables por una IA. Importan el formato, las referencias, el sistema de almacenamiento y la coherencia. Para que la IA pueda interactuar correctamente con usuarios, hay que suministrarle una cantidad ingente de información y hacer el esfuerzo de plasmar el conocimiento que atesora el capital humano y social de la empresa.
Es un cambio que involucra a toda la empresa, no solo a los equipos técnicos: desde atención al cliente hasta la dirección, pasando por ventas, producto y operaciones.
La clave con los LLM es evidente: el CONTEXTO
Es imprescindible condensar, estructurar y exponer el conocimiento a los modelos mediante herramientas bien definidas para que lo incorporen al generar respuestas o acciones. Solemos sobrevalorar la “potencia” del modelo y subestimar el contexto, cuando para obtener resultados fiables y reducir alucinaciones lo decisivo es precisamente el contexto. En productos complejos, con múltiples aristas y un conocimiento tácito disperso en capital humano y social no documentado, resulta difícil que una IA generativa ejecute de forma coordinada, escalable y fiable tareas funcionales o técnicas del producto. Además, las limitaciones actuales —ventana de contexto y capacidad de atención— imponen un límite operativo al tamaño y la complejidad abordables.
De ahí la necesidad de estructurar ese conocimiento y promover un cambio de filosofía en la forma de actuar y en los objetivos de toda la organización, y que no sea tan fácil construir un SaaS que cubra sus necesidades con un simple prompt.
Agentes en el ciclo de desarrollo: de la reunión a Git
El cambio no se aborda solo en el lado del producto —el qué—, también en las formas —el cómo. Agentes o sistemas de agentes más complejos, con un buen contexto e instrucciones, pueden jugar un papel crucial en la productividad, la optimización de recursos y la agilización de procesos de desarrollo para poner en producción nuevas funcionalidades o mantener las existentes.
Os voy a exponer un caso de uso inspirado en un episodio de uno de mis podcasts favoritos y que os recomiendo encarecidamente si os gustan estos temas: El Test de Turing. Es un ejemplo que expuso Víctor relacionado con Claude Code, mientras era bombardeado a preguntas por Arnau sobre las diferencias con Cursor y Álvaro trataba de contenerle, que me hizo replantear el potencial de los sistemas multiagente en desarrollo de software.
En lugar del ciclo tradicional (toma de requisitos, brainstorming, documentación, reuniones con el equipo de desarrollo, validación, arquitectura, reparto de tareas, implementación, supervisión, pruebas y documentación), podemos partir de la grabación de una reunión o de un documento de necesidades y arquitectura para activar un sistema de agentes que trabaje coordinadamente en ramas versionadas en Git. El rol del equipo de desarrollo pasa a la revisión final y a ajustes puntuales, delegando también la documentación técnica y funcional. El proceso es el siguiente, un sistema de agentes con las siguientes fases o actores:
- Ingesta de información de necesidades y arquitectura (audio / transcripción / documento).
- Agente de extracción de requisitos.
- Agente de normalización, coordinador y detección de dependencias.
- Agente generador de tareas.
- Agente de triaje que proceda a la asignación de esas tareas a agentes especialistas en nichos y tecnologías muy concretas (porque no basta con tener un agente de back y otro de front como si fuera 2015).
- Generación de código, pruebas y documentación técnica por cada uno de estos agentes.
- Validación estática, policy engine y seguridad por el agente coordinador.
- Generación de resúmenes ejecutivos y changelogs.
- Revisión humana final y merge.
- Deploy y retroalimentación al repositorio de contexto.
Resultado: se simplifican y acortan pasos del ciclo de desarrollo tradicional, pudiendo desplegar nuevas funcionalidades en cuestión de horas o días.
2025: el año de los agentes… ¿dónde están?
2025 iba a ser el año de los agentes y, aunque los avances en capacidades de los modelos han sido asombrosos si los miramos con perspectiva, todavía apenas intuimos parte de su verdadero potencial. Herramientas como Claude Code o Gemini CLI empiezan a vislumbrar el camino que parece tomar la tecnología, pero aún no existe un grado de madurez suficiente para garantizar consistencia y calidad empresarial. Aun así, en un momento en que la pendiente de la curva exponencial se acentúa, resulta complejo anticipar siquiera la situación del mes próximo, y mucho menos proyectarla a uno o varios años vista.
Todo el mundo habla de IA… pero pocos la adoptan
Por ahora se habla mucho de IA —en LinkedIn o en X parece monopolio temático—, pero pocas empresas la incorporan de forma estructural. Adoptar IA no es montar un chatbot RAG alimentado por tres PDFs de QA que solo aparenta utilidad, como aquellos viejos asistentes bancarios que estorbaban y nadie entendía. Al ser una tecnología de propósito general, antes o después se extenderá al tejido productivo igual que ocurrió con la nube o con Internet, pero, por ahora, los datos son claros en este aspecto: el grado de adopción es bajo y hay bastante margen de mejora y de oportunidades. Además, pienso que asistiremos a un regreso del ideal renacentista en el ámbito de los recursos humanos: se empezarán a valorar más perfiles transversales capaces de integrar negocio y tecnología, con pensamiento crítico y visión holística, frente a especialistas o puramente ejecutores.
No es el fin del SaaS. Es una transición
Por lo tanto, no: no estamos ante la muerte del SaaS. Estamos en una transición comparable a la que supuso Internet para el comercio. Incluso ante una AGI o una ASI, estos sistemas seguirían siendo, en el fondo, parecidos a los humanos: necesitan contexto y conocimientos para ejecutar bien sus tareas.
Ese expertise, la adecuación al cliente y los desarrollos de nicho serán el motor real de las empresas SaaS —mucho más que la pura capacidad tecnológica.
Los LLM no eliminan el SaaS: desplazan el valor hacia la calidad del contexto, la orquestación y la experiencia dinámica. Ganan quienes estructuren conocimiento antes de que la curva de adopción se acelere.