La próxima característica de software empresarial no será enviada. Será generada.

      TL;DREl software empresarial se acerca a un cambio donde los asistentes de IA generan características bajo demanda en lugar de enviarlas a través de las listas de tareas del producto. En lugar de presentar una solicitud y esperar meses, un usuario describe lo que necesita y el sistema genera un pequeño programa para hacerlo. El artículo explora lo que esto significa para los equipos de producto, la seguridad, la gobernanza y la definición de una 'característica' en sí misma.

      La lista de tareas de características empresariales es donde las buenas solicitudes de los usuarios van a esperar. Esa espera está a punto de acortarse mucho, no porque los equipos de producto se vuelvan más rápidos, sino porque la característica faltante ahora puede generarse en el momento de la solicitud y descartarse treinta segundos después.

      Un líder de equipo de soporte abre su aplicación de mesa de ayuda y pregunta:

      “Muéstrame todos los tickets de este mes que se resolvieron y luego se reabrieron dentro de las 48 horas, agrupados por el agente que los cerró primero.”

      Ningún informe hace esto. Ninguna combinación de filtros puede expresarlo. No existe ningún mosaico de panel de control.

      Hace unos años, esto se habría convertido en un ticket para el equipo de producto, registrado, priorizado y a menudo entregado tarde o no entregado en absoluto. Más recientemente, un asistente de IA podría haber recuperado un artículo de conocimiento explicando cómo podría exportar datos de tickets y analizarlos en una hoja de cálculo.

      Ahora hay una tercera posibilidad. El asistente genera un pequeño programa para exactamente esta solicitud. El programa escanea los registros de tickets, cruza cada evento de resolución con las reaperturas posteriores, verifica si la brecha fue inferior a 48 horas y devuelve un resumen agrupado. El modelo recibe esa tabla y explica el patrón.

      El equipo de producto nunca construyó el informe. El usuario nunca escribió código. Para una tarea, la característica faltante existió exactamente donde se necesitaba.

      Eso no es una mejor recuperación. Es el comienzo del contexto programable.

      La recuperación selecciona evidencia. El código computa nueva evidencia.

      RAG resolvió un problema genuino: los usuarios podían hacer preguntas en lenguaje natural y obtener respuestas fundamentadas en fuentes que la interfaz nunca mostró. Pero la recuperación selecciona de evidencia que ya existe, un documento, un pasaje, una fila.

      Muchas preguntas empresariales no son respondidas por ningún artefacto existente. Se responden mediante un procedimiento: filtrando, uniendo, calculando y resumiendo a través de fuentes.

      ¿Qué tickets se reabrieron solo después de ser transferidos a un equipo diferente? ¿Qué informes de gastos superan el promedio del departamento en más de la mitad? ¿Qué implementaciones fallaron esta semana que también fallaron la semana pasada, y qué cambió entre medio?

      Un equipo de producto puede preconstruir los procedimientos comunes. No puede anticipar todos ellos.

      Esa es la brecha que cierra el contexto programable. El modelo traduce la intención de un usuario en un programa temporal. La aplicación lo ejecuta contra capacidades aprobadas y coloca solo el resultado computado en la ventana de contexto. Esto no es un intérprete de código de propósito general con acceso a todo el lenguaje, la aplicación define exactamente qué operaciones puede llamar el código generado. El código puede vivir para una sola solicitud, generado, ejecutado, registrado, descartado.

      Los usuarios decidirán lo que la IA realmente ve.

      Cada modelo de IA tiene una memoria de trabajo limitada, la ventana de contexto, que determina sobre qué puede razonar en cada solicitud. Gestionar esa ventana ha sido una plomería invisible propiedad de los equipos de plataforma. Eso sigue siendo crítico. Pero un cambio más grande se está volviendo posible: los usuarios definen lo que entra en el contexto al describir el cálculo que necesitan.

      “Muéstrame tickets resueltos donde el cliente respondió dentro de un día, ¿cuáles son los temas comunes?” “Compara el tiempo de primera respuesta por agente este mes frente al pasado y marca a cualquiera que se haya vuelto más lento.” “Encuentra informes de gastos presentados el último día del trimestre, agrupados por aprobador.”

      Cada solicitud es una característica temporal. El programa generado computa un artefacto con forma de respuesta, y solo ese artefacto entra en el contexto. Esta es una personalización del contexto por intención, no por ajuste de aviso.

      ¿Dónde se ejecuta realmente el código generado?

      Si un modelo puede generar un programa confiable, algo aún tiene que ejecutarlo. Los entornos de arena del lado del servidor son la opción obvia para cálculos pesados y uniones entre sistemas. Pero hay un tiempo de ejecución que la mayoría de los usuarios empresariales ya tienen abierto: el navegador.

      Cada aplicación web empresarial envía un motor JavaScript a cada usuario que inicia sesión. Ese motor puede ejecutar código generado sin un servicio backend separado, paso de implementación o solicitud de infraestructura. El usuario no instala nada ni cambia de herramientas, el cálculo ocurre dentro del producto que ya está utilizando.

      La ejecución del lado del cliente también conlleva una ventaja arquitectónica importante: la sesión del navegador ya representa al usuario que ha iniciado sesión.

      Supongamos que la aplicación de mesa de ayuda le da a JavaScript generado una interfaz estrecha, listTickets, getTicketTimeline, getAgentStats. Cada llamada viaja al backend usando la identidad delegada del usuario actual. Las mismas reglas basadas en roles y niveles de registro que rigen las pantallas de la aplicación rigen el cálculo generado. No se necesita una cuenta de servicio separada con acceso más amplio.

      Eso elude un problema recurrente de arquitectura de agentes: una identidad central que puede ver más que la persona que hace la pregunta. El programa recupera solo los registros a los que el usuario actual tiene derecho a ver, los procesa localmente y envía un resultado compacto al modelo, reduciendo tanto el uso del contexto como el movimiento innecesario de datos.

      La ejecución del lado del cliente se convierte en una estrategia de ingeniería de contexto: calcular cerca del usuario, bajo la identidad del usuario, y dar al modelo evidencia con forma de respuesta en lugar de registros en bruto.

      La identidad es necesaria pero no suficiente.

      Hay una versión peligrosa de esta idea: generar JavaScript y ejecutarlo con eval() dentro de la página principal de la aplicación, dándole acceso completo al DOM, almacenamiento del navegador, puntos de escritura y red saliente.

      Un camino más seguro existe en el lenguaje. El nuevo constructor Function() compila una cadena en una función que no puede capturar las variables locales del ámbito de llamada, pero aún se ejecuta en el ámbito global a menos que se contenga más. Combinado con un iframe o trabajador en sandbox, se convierte en un límite de ejecución práctico donde la aplicación le entrega a la función generada solo las capacidades que elige.

      Ejecutar en el cliente no hace que la autorización sea automática. El navegador proporciona identidad; el servidor aún debe autorizar cada solicitud de API.

      Un diseño creíble da capacidades al código generado, no credenciales. Se ejecuta en un trabajador aislado, marco en sandbox o tiempo de ejecución restringido, sin acceso irrestricto al documento, cookies, red o sistema de archivos. La aplicación expone un pequeño conjunto de operaciones tipadas y auditables. Las lecturas son predeterminadas. Las escrituras requieren una concesión separada y, para acciones consecuentes, confirmación explícita.

      El tiempo de ejecución necesita límites en el tiempo de ejecución, memoria, tamaño de resultado y conteo de llamadas a la API. Cada ejecución debe registrar el programa generado, la identidad solicitante, las capacidades invocadas y la procedencia de los datos.

      Un límite más importa y es fácil de pasar por alto: el permiso para ver un registro no implica permiso para enviarlo a cualquier punto final del modelo. Antes de que un resultado computado entre en la ventana de contexto, la aplicación debe aplicar sus políticas de manejo de datos y elegibilidad del modelo.

      El principio es simple: dejar que el código generado compute. Nunca dejar que escape.

      De catálogos de características a entornos de cálculo

      JavaScript del lado del cliente y habilidades del lado del servidor son dos instancias del mismo patrón emergente.

      Una habilidad reutilizable podría contener un script de Python revisado para una tarea recurrente. Un programa efímero podría generarse para una pregunta y nunca ejecutarse nuevamente. Un tiempo de ejecución de navegador se adapta al análisis interactivo bajo identidad delegada. Un sandbox de servidor maneja cálculos costosos y acceso entre sistemas.

      Los equipos de producto aún envían características, y los cálculos repetidos deberían graduarse en permanentes. Pero los constructores también crean la superficie de ejecución gobernada desde la cual se pueden ensamblar características no anticipadas: capacidades seguras, propagación de identidad, aplicación de políticas, sandboxes y procedencia.

      Los usuarios no obtienen acceso irrestricto, y no se convierten en ingenieros de software. Obtienen algo más práctico: la capacidad de solicitar cálculos que el equipo de producto no sabía construir, dentro de los límites que ese equipo diseñó deliberadamente.

      Esto aún no es una práctica estándar, pero cada componente está listo para producción. RAG permitió a los usuarios hacer preguntas que la interfaz no anticipó. El contexto programable permite a los sistemas calcular respuestas que la hoja de ruta de características no anticipó.

      ¿La líder de soporte que quería saber qué agentes siguen cerrando tickets