Abstract
The progressive integration of large language models into software systems does not seem destined to produce merely an acceleration of development processes, nor can it be interpreted solely as a new phase in the automation of code writing. The most significant transformation concerns, rather, the very structure of application software and the way in which the functions of analysis, decision-making, and control are distributed within it.
Traditional business software has historically been built by translating processes, operating rules, and interaction paths into deterministic procedures, defined in advance and explicitly coded. The introduction of systems based on the analytical capabilities of LLMs makes possible a different organization of the application, in which part of the behavior is no longer rigidly prescribed, but is determined dynamically based on context, available data, and the goal expressed by the user.
In this scenario, the concept of harness takes center stage, understood not simply as a set of mechanisms designed to control a language model, but as the application infrastructure through which the general capabilities of the model are turned into operational capabilities specific to a domain. Data, tools, permissions, constraints, memory, verification procedures, observability, and failure handling thus make up the new design space within which the developer exercises their expertise.
The thesis argued in this paper is that, to the extent that application software evolves from systems made up mainly of predefined functions toward systems based on composable capabilities, the developer's role will tend to shift from directly programming individual behaviors to designing and orchestrating the harness that makes those behaviors possible, reliable, and governable.
1. Introduction
For much of the history of applied computing, developing software has meant turning a process into a finite sequence of instructions. The analysis of a domain led to the formalization of its entities, the relationships among them, the rules governing their behavior, and the paths through which the user could interact with the system. The result of this process was an application in which the operational possibilities were, to a large extent, defined in advance by the designer and subsequently translated into code.
The business management system is one of the most complete expressions of this paradigm. The user's activities are organized through forms, menus, procedures, filters, reports, workflows, and specific functions, each of which embeds part of the knowledge of the domain and of the ways in which that knowledge is meant to be used. The system, in other words, does not merely store information, but contains an explicit representation of the intended paths for querying, modifying, and transforming it.
This model has ensured, and continues to ensure, high levels of predictability and control. It does, however, have an unavoidable structural rigidity: every new function requires its behavior to be analyzed, modeled, and implemented; every new operational path must be anticipated; every different way of querying the body of information must correspond to an explicitly designed function.
In this respect, the emergence of large language models introduces a significant discontinuity. The decisive aspect lies not so much in their ability to produce code as in the possibility of using a software component endowed with general capabilities for language comprehension, analysis of heterogeneous information, semantic correlation, and dynamic tool selection.
It is precisely this capability that makes a different organization of application software conceivable. Instead of a system in which every path must be described in advance, it becomes possible to design applications in which the user expresses a goal and the system determines, within defined limits, what information to acquire, which tools to use, and what sequence of operations to adopt to achieve it.
This is not simply a matter of adding a conversational component to an existing business system. It is, at least potentially, a matter of changing the principle by which the system itself is built.
2. From Functions to Capabilities
In traditional application software, the relationship between the user's intent and the system's behavior is generally mediated by an explicit function. If you need to view the status of a case file, compare two documents, identify a particular anomaly, or produce a report, the system must have a procedure designed to carry out that operation.
Application intelligence therefore resides, to a large extent, in the quantity and quality of the functions the software makes available.
The use of LLMs makes it possible to envision a different organization, in which the system is built not exclusively around discrete functions, but around general capabilities that can be used and combined depending on context. Understanding a request, extracting information from a document, querying a database, comparing different sources, recognizing inconsistencies, producing a summary, or identifying the most suitable tool to complete an operation no longer have to be standalone functions and can become elementary capabilities of a broader system.
The difference is not merely terminological.
In the first case, the designer defines in advance the path leading from a request to a result. In the second, the designer defines a set of operational possibilities and the conditions under which they can be used, letting the concrete sequence of operations be determined by the specific situation.
Consider, by way of example, an administrative system in which an operator wants to identify the case files at risk of missing their deadlines and understand why. In a traditional business system, this need would have to be met by a dedicated function, built by combining queries, filters, rules, and presentation methods defined in advance. A system based on the capabilities of an LLM can instead interpret the user's goal directly, query the necessary sources, retrieve the relevant documents, relate dates and procedural statuses, and return a reasoned assessment.
The point of interest is not the more natural interface. It is that the path needed to reach the result does not necessarily have to coincide with a procedure designed in advance in all its steps.
From this standpoint, the most radical possibility introduced by LLMs is the shift from software in which functions are programmed to software in which capabilities are made available.
3. The Harness as a New Application Structure
It is within this transformation that the concept of harness takes on a broader meaning than the one traditionally associated with testing or, more recently, with the mechanisms for controlling a language model.
The harness can be understood as the set of structures through which the general capabilities of a model are made usable within a specific application domain. It defines the informational and operational perimeter within which the system can act and establishes the conditions necessary for a probabilistic component to take part in processes that must continue to meet requirements of reliability, security, and verifiability.
The model, considered in isolation, has general capabilities. However, it does not know, except to the extent that they are made available to it, the correct information sources, the user's permissions, the current state of processes, the systems through which certain operations are carried out, the regulatory limits of the domain, or the criteria by which a result is to be considered acceptable.
These are precisely the elements that make up the harness.
Context management determines what information must be retrieved, from which sources, and with what priority. The definition of tools establishes how the model can interact with databases, APIs, document repositories, or other services. Authorization systems circumscribe what a given subject can know or modify. Formal constraints and validation procedures reduce the space of admissible actions. Memory and state management ensure continuity for processes that cannot be exhausted in a single interaction. Verification procedures make it possible to distinguish a plausible result from a usable one. Finally, observability makes it possible to reconstruct the operations performed and the information that led to a given conclusion.
Taken together, these elements are not an accessory wrapper around the model. They are a substantial part of the application.
From this standpoint, saying that value shifts from the model to the harness does not mean claiming that the model is irrelevant, but recognizing that the general capability offered by an LLM acquires application value only when it is placed within a structure capable of turning it into operational behavior.
4. The Shift in the Differentiating Factor
Language models are destined to become ever more widespread, accessible, and, in many cases, interchangeable. Different organizations can use models in the same capability class, sometimes even the very same model, without obtaining equivalent systems as a result.
The difference depends on what is built around the model.
A harness embeds knowledge that does not belong to the general model and that can hardly be purchased as a standardized service. It holds an organization's information sources, the structure of its processes, its authorization rules, the ways of interacting with existing systems, the constraints of the domain, the exceptions that have emerged in real-world operation, and the criteria by which the quality of a result is assessed.
In this sense, the harness progressively becomes a form of codified organizational knowledge.
This is particularly significant in regulated domains. In healthcare, finance, or public administration, it is not enough to have a model capable of understanding a document or answering a question. It is necessary to establish which documents may be used, which information is accessible to a given subject, which operations require confirmation, which must be logged, and which decisions can never be left to the model's probabilistic judgment alone.
The advantage therefore lies not simply in the intelligence of the model, but in the ability to embed it correctly within the organization.
5. The Inversion of the Bottleneck
The adoption of systems based on general capabilities also shifts the bottleneck of development.
In the traditional model, a significant part of the effort consists of implementing the various ways in which a user will be able to use the system. Because every function must be built explicitly, the complexity of the software grows with the number of behaviors one wants to make available.
In the paradigm described here, at least part of this complexity can be shifted from the application code to the system's ability to interpret a goal and dynamically combine the tools needed to achieve it.
This does not eliminate complexity. It changes its nature.
The developer must decide what data to make available, which tools to expose, which relationships to allow among them, which operations require deterministic control, which results must be verified, and which conditions should trigger a halt or a request for human intervention.
The programming of individual paths thus tends to give way to the design of the space within which those paths can be built.
It is precisely in this shift that the harness gains relevance as a design category. The developer does not necessarily have to code every possible sequence, but must rigorously design the conditions that make some sequences possible and prevent others.
6. The New Role of the Developer
The reduced centrality of writing code directly does not imply a reduced need for technical expertise.
On the contrary, it is plausible that it makes it even more important.
Anyone designing a system in which an LLM can analyze data, choose tools, and dynamically determine an operational path must deeply understand the consequences of the actions they make available. They must understand data models, interfaces between systems, authentication and authorization mechanisms, the problems specific to distributed systems, consistency conditions, the limits of transactions, and the ways of verifying the correctness of a result.
These skills do not become obsolete just because part of the behavior is no longer programmed directly. Rather, they become the instruments through which it is possible to delimit and govern a behavior that is no longer entirely expressed as deterministic code.
The professional change can therefore be described as a shift from programming to orchestration.
The term should not be understood in a reductive sense, as the mere coordination of services or composition of APIs. It denotes a broader design function, in which the developer builds the context within which the system operates, selects the available capabilities, defines their boundaries, establishes the relationships between probabilistic and deterministic components, and introduces the mechanisms through which the system's decisions are verified.
Programmers might therefore progressively write less code while continuing to make substantial use of the skills they have developed through programming.
What changes is the level at which those skills are exercised.
7. From Predetermined Workflows to Dynamic Orchestration
The transformation is particularly evident when viewed from the standpoint of workflows.
In traditional software, the process is generally represented as a sequence of states and transitions defined in advance. The system knows the path because that path has been programmed.
The introduction of components with analytical capabilities makes it possible, at least for certain categories of problems, to separate the definition of the goal from the detailed definition of the path needed to reach it.
The harness can establish what information is available, which tools can be used, which constraints must not be violated, and which conditions must be met for an operation to be considered valid. Within that space, the system can dynamically determine the most appropriate sequence.
This does not necessarily mean the disappearance of deterministic workflows. In many areas they will remain indispensable. The novelty lies in the possibility of not having to explicitly represent every variation of a path when the problem calls for interpretation, adaptation to context, or the combination of heterogeneous sources.
The workflow does not disappear, but it may cease to coincide entirely with the code.
8. The Persistence of Determinism
Any reflection on a new generation of LLM-based software must avoid a misunderstanding: the possibility of entrusting part of the analysis work to a model does not imply that every function must become probabilistic.
One of the main design skills lies precisely in distinguishing what can benefit from the model's interpretive capability from what must remain deterministic.
Understanding a request can tolerate a margin of uncertainty; an authorization check cannot. The analysis of a set of documents can be entrusted to a model; the application of an accounting rule must produce a reproducible result. The selection of relevant information can be probabilistic; the execution of a transaction must remain subject to precise formal conditions.
The result is an inevitably hybrid architecture.
LLMs can be used where interpretation, analysis, and adaptation produce value, while deterministic software continues to govern what requires certainty, repeatability, and formal control.
The harness is precisely the place where these two levels are joined.
9. The Harness as the New Core Competency
If this transformation were to take hold, a significant part of the developer's expertise will focus less and less on the ability to implement individual functions and more and more on the ability to design systems within which functions that are not rigidly predetermined can emerge from the interaction among model, data, and tools.
This requires a different form of design, but one that is no less rigorous.
The quality of the system will depend on the choice of accessible information, the structure of the tools, the clarity of contracts, the proper separation of privileges, the ability to verify results, and the possibility of observing and reconstructing what the system has done.
In this respect, the harness plays a role analogous to the one played by new levels of abstraction at other stages in the history of computing.
It does not eliminate earlier skills, but relocates them.
Programmers do not necessarily need to know less about algorithms, systems, or architecture. They must be able to use this knowledge to design the context within which a component with general capabilities can act without compromising the overall reliability of the application.
10. Limits and Objections
A first objection concerns reliability. Software whose behavior is not entirely coded in advance is, by definition, less predictable than a deterministic system. The objection is well founded and is one of the main limitations of the paradigm. But it is precisely this difficulty that makes the harness important: the greater the degree of autonomy granted to the system, the higher the quality must be of the constraints, checks, and control mechanisms that delimit its behavior.
A second objection concerns complexity. Systems based on dynamically orchestrated capabilities can be harder to test, observe, and maintain than a traditional application. This limitation, too, is real. However, it does not diminish the developer's role; if anything, it makes the need for it more evident, since managing this complexity requires deeper architectural and systems expertise than the superficial use of a model.
A third objection is that the evolution of LLMs themselves might progressively make the harness superfluous. More capable models could certainly reduce some forms of explicit control, but they would not eliminate the need to establish which data is accessible, which actions are allowed, which responsibilities belong to the system, and which must remain with the organization. Greater capability does not eliminate the problem of governance; rather, it tends to broaden its scope.
11. Conclusions
The most significant impact of language models on software development may not coincide with their ability to generate code. It may concern a deeper change in the structure of applications.
Traditional business software is built by programming in advance the functions and paths through which a user can reach a given result. Systems based on the capabilities of LLMs, by contrast, make it possible, at least for some application problems, to build environments in which the result is reached through the dynamic combination of data, tools, and analytical capabilities.
In this scenario, the model does not simply replace existing software. It helps change its shape.
The harness becomes the architecture through which the model's general capability is turned into application behavior, bounded by the constraints of the domain and integrated with deterministic components.
Consequently, the developer's role changes as well.
Their work may progressively move away from directly writing every individual behavior without thereby losing the need for the skills that programming has historically required. These skills are exercised at a different level: in choosing which capabilities to make available, in designing data and tools, in defining constraints, and in building the conditions that allow the system to operate correctly.
The shift from algorithm to harness therefore does not mean the end of programming, but a shift in its center of gravity.
Software is no longer necessarily built by describing every possible behavior.
It is increasingly designed by defining the environment within which different behaviors can be produced, verified, and governed.
It is in this space that the developer's new core competency may lie.