Tesis central: el estado actual de los LLM no reemplaza los sistemas de software duraderos. Hace mucho más inteligente la capa de intención que vive encima de esos sistemas.
La reacción del mercado no es toda la historia
En las últimas semanas, tal vez unas 10 aproximadamente, hemos visto una fuerte reacción en los mercados de capitales alrededor del querido segmento de software como servicio. La categoría que era tan valorada por sus costos operativos relativamente no lineales ha visto caer sus múltiplos últimamente.
Estoy de acuerdo con la idea de que los mercados son algo eficientes, y esto podría ser algún tipo de corrección saludable. Pero no estoy de acuerdo con la narrativa que he visto en los medios y en X, donde se habla de un apocalipsis SaaS.
Esa narrativa malinterpreta en qué parte del stack de producto y de la experiencia de usuario encaja mejor el estado actual de los LLM.
Los LLM pertenecen a la superficie de intención
Como he explicado antes, para garantizar una experiencia de usuario hermosa necesitamos resultados consistentes. Los motores inherentemente probabilísticos no van a generar ese tipo de resultado de manera constante.
Lo que sí serán es una capa más inteligente sobre la superficie de intención.
Los LLM quizá sean la mejor tecnología que veremos en los próximos cien años para:
- Análisis de sentimiento
- Búsqueda semántica
- Coincidencia de intenciones entre un usuario y un algoritmo
Pero eso no significa que sean inherentemente la forma más eficiente, o la mejor, de generar resultados consistentes dentro de una máquina de estados.
La consistencia sigue perteneciendo a sistemas determinísticos
Hay otras arquitecturas, incluidas las arquitecturas computacionales tradicionales, que están mejor diseñadas para ese tipo de consistencia. A largo plazo, millones de usuarios no usarán LLM en producción para ejecutar las mismas operaciones que pueden escribir en una calculadora, porque no es eficiente.
Tal vez en ejemplos triviales, como dos más dos, se pueda agregar algún tipo de caché al sistema de inferencia de un LLM.
Pero en la mayoría de los casos hay miles de usos donde un algoritmo de dos líneas en C será órdenes de magnitud más eficiente que ejecutar esos cálculos a través de sistemas basados en LLM.
Por qué esto importa para SaaS
El problema principal es que los múltiplos actuales están restando importancia a productos de software realmente buenos, que requirieron muchísima experiencia y tiempo para perfeccionarse, como si fueran algoritmos y ejecuciones fáciles de inferir.
Un ejemplo sería SAP. Cualquiera que trabaje en una empresa transnacional sabe que SAP es una pieza de software muy especial que puede tomar meses configurar.
No porque SAP carezca de inteligencia, sino porque estos son sistemas integrados que operan muy cerca de interacciones del mundo real y generan información contable, entre muchas otras cosas.
Aunque los LLM puedan generar código a cierto ritmo, y aunque el código escrito una vez pueda reutilizarse muchas veces, eso no significa que todos los cálculos dentro de una ventana de contexto reemplacen la máquina de estados y las interfaces creadas por SAP.
Hablo de este ejemplo porque viene de un par de industrias que entiendo, pero este mismo patrón seguramente aparece en muchas otras.
La corrección no es un apocalipsis
Tal vez esto sí fue una corrección saludable. Aun así, no creo que estemos viendo un apocalipsis SaaS.
En el peor de los casos, en el mediano y largo plazo veremos que los jugadores menos optimizados del espacio de software se vuelven obsoletos y eventualmente son reemplazados por otras compañías de software.
Pero no por alguien ejecutando IA desde su sótano, porque eso no alcanza para llegar tan lejos hoy.
Las empresas que van a superar a las demás serán las que:
- Se adapten mejor a la nueva forma de escribir código
- Ofrezcan servicios confiables a los mejores precios
- Se integren fácilmente con un stack más amplio de aplicaciones y software
El mejor patrón de integración
Para los consumidores de empresas de software como servicio, no tiene ningún sentido desarrollar una versión propia de QuickBooks solo para integrar su sistema con una función como TurboTax.
En muchos casos, el mejor uso del tiempo será:
- Usar una API LLM-first para generar o interpretar registros contables.
- Usar un LLM para crear las transacciones correctas dentro del sistema.
- Dejar que un producto con estado y bien diseñado, como QuickBooks o SAP, preserve la fiabilidad y la consistencia.
Probablemente esa sea la mejor experiencia de usuario posible.
Por un lado, obtienes la fiabilidad de un software con estado. Por el otro, obtienes una mejor interfaz.
En vez de memorizar toda una estructura contable, la interfaz puede volverse basada en intención. En sistemas contables, un Plan de Cuentas funciona como un mapa clave-valor: de un lado guarda la cuenta y del otro define qué entra en esa cuenta. No creo que los usuarios tengan que memorizar eso nunca más.
Deberías poder usar una interfaz de texto o de voz y decir: “Quiero vender 10 bicicletas por x cantidad”. Después, el sistema debería enviar la solicitud correcta al endpoint de la API.
Así se verá la integración máxima.
No apuestes contra todo SaaS
Así que no apuestes contra todas las empresas de software como servicio.
En todo caso, a largo plazo las mejores compañías podrían estar mejor posicionadas conforme evolucione el mercado total direccionable. Hay que observar a las empresas que se están adaptando: las que no hacen despidos tecnológicos masivos, sino que están ampliando sus equipos de tecnología para ponerse al día con los agentes y los sistemas de software agénticos que queremos construir hoy y mañana.
Eso es todo lo que pienso. Muchas gracias.
Publicado originalmente en LinkedIn.