The next feature of your enterprise software won’t be delivered. It will be created.

      TL;DR

      Enterprise software is on the verge of a transformation where AI assistants create features on demand instead of relying on product backlogs. Rather than submitting requests and waiting months for completion, users can simply articulate their needs, and the system will generate a small program to fulfill those needs. The article examines the implications for product teams, security, governance, and even the concept of a "feature."

      The backlog for enterprise features is where valuable user requests often languish. This wait time is set to decrease significantly, not because product teams are working more quickly, but because the missing feature can now be produced instantly upon request and discarded shortly after.

      For instance, a support team lead might open her helpdesk app and ask:

      “Show me all tickets from this month that were resolved and then reopened within 48 hours, categorized by the agent who initially closed them.”

      Currently, no report provides this information, no combination of filters can yield it, and no dashboard tile exists for it.

      A few years ago, this would have been submitted as a ticket for the product team, prioritized, and often delivered late or not at all. More recently, an AI assistant might have found an article explaining how to export ticket data for analysis in a spreadsheet.

      Now there's a third option. The assistant can create a small program tailored for this request. This program will scan ticket records, check each resolution event against subsequent reopenings, verify if the gap was less than 48 hours, and return a summarized grouping. The assistant presents the findings and explains the pattern.

      The product team did not create the report. The user did not code anything. For this particular task, the necessary feature was generated precisely where it was needed.

      This represents not just improved retrieval but the introduction of programmable context.

      Retrieval seeks existing evidence, while code generates new evidence. RAG effectively addressed a legitimate issue: users could pose natural-language questions and receive answers based on sources that were not readily accessible through the interface. However, retrieval is limited to selecting from existing evidence, like documents or data rows.

      Many enterprise inquiries cannot be answered by pre-existing artifacts; they require a procedure involving filtering, joining, calculating, and summarizing across different sources. For example, which tickets were reopened after being assigned to a different team? Which expense reports exceed the departmental average by more than half? Which deployments failed this week that also failed last week, and what changes occurred in between?

      Product teams can configure common procedures in advance but cannot anticipate every possible need.

      This is the gap that programmable context addresses. The model interprets a user's intent and translates it into a temporary program. This program is executed using approved functionalities, and only the computed results are presented in the context window. This is not a general-purpose code interpreter with access to the entire programming language; rather, the application specifies which operations the generated code can perform. This code exists only for a single request: it is generated, executed, logged, and then discarded.

      Users will determine what the AI actually processes.

      Each AI model has a constrained working memory, known as the context window, that dictates what it can reason about for each request. Managing this window has typically been a behind-the-scenes responsibility of platform teams and remains crucial. However, a significant shift is now emerging: users can define what enters their context by explaining the computations they require.

      "Show me tickets that were resolved where the customer replied within a day; what are the common topics?" "Compare first-response times by agent for this month and last month and identify anyone who has slowed down." "Find expense reports submitted on the last day of the quarter, categorized by approver."

      Every request represents a temporary feature. The generated program produces an answer-oriented artifact, which is the only item that enters the context. This represents context customization driven by user intent rather than prompt tuning.

      But where does the generated code actually run?

      If a model can generate a dependable program, there must still be an execution environment. Server-side sandboxes are ideal for heavy computations and cross-system operations. However, there is also a runtime that many enterprise users are already familiar with: the browser.

      Every enterprise web application includes a JavaScript engine that is available to every logged-in user. This engine can execute generated code without needing a separate backend service, deployment, or infrastructure request. Users do not have to install anything or switch tools; the computation takes place within the product they are currently using.

      Client-side execution also offers a crucial architectural benefit: the browser session naturally represents the signed-in user.

      Imagine the helpdesk application's generated JavaScript presenting a narrow interface with functions like listTickets, getTicketTimeline, and getAgentStats. Each function call communicates with the backend using the current user's delegated identity. The same role-based and record-level access controls that apply to the application's screens also govern the generated computations, eliminating the need for a separate service account with broader permissions.

      This model avoids a common architecture issue where a central identity can access