Describing an Outcome Instead of Specifying a System

For fifty years, getting software built meant handing IT a specification — a description of the system you wanted them to construct. The contract is quietly being rewritten, and the new version asks for something entirely different: not the system, but the outcome.

Somewhere in every large company there is a document that begins with the words "the system shall." It is a requirements specification, and it is the artifact through which a business has always asked for software. A regional manager wants a way to catch pricing exceptions before they ship, so a business analyst sits with her for a week and translates that want into a language IT can build against — data fields, validation rules, a screen with these inputs and that button, an integration to the ERP, a report that runs nightly. The want, which she could have stated in a sentence, becomes forty pages of specification. The specification goes into a queue. Two quarters later, something arrives that is recognizably related to what she asked for, and by then the pricing problem has changed shape and half the spec describes a world that no longer exists. Everyone involved treats this as the natural order of things, the unavoidable friction of getting a computer to do a new thing, because for the entire history of enterprise software it was.

The reason it worked this way is not that anyone preferred it. It is that a computer could only ever be told exactly what to do, step by step, in a form precise enough to be executed without judgment. Software was a machine you had to fully specify before it could run, and specifying a machine is a specialized skill, so a translation layer grew up between the people who had outcomes they wanted and the people who could render those outcomes as systems. That layer — the analysts, the architects, the long requirements documents, the change-request forms — was never the point. It was the cost of the fact that the outcome in the manager's head could not be handed to a computer directly. It had to be disassembled into a specification first, and the disassembly is where the months went.

The old contract asked for a system; the new one asks for a result

What is actually changing right now is not that software got faster to build. It is that the object of the request has moved. The old contract with IT was a specification of a system: you described, in the vocabulary of the machine, the thing you wanted constructed, and you were responsible for getting that description right down to the field level, because whatever you failed to specify would simply be absent. The new contract is a description of an outcome: you state, in the vocabulary of your own business, what you want to be true — pricing exceptions caught and corrected before they ship, with a human signing off on anything above a threshold — and the platform is responsible for composing the system that makes it true. The burden of translation moves off the person asking and onto the platform. You bring the intent; it assembles the mechanism.

This sounds like a small semantic shift and it is a profound one, because a system and an outcome are specified in completely different languages. A system is specified in nouns and steps: tables, endpoints, jobs, the exact sequence of operations. An outcome is specified in conditions and judgments: what should be true when this is done, what counts as an exception, who needs to approve what. The first requires you to already know how the thing should be built, which is precisely the knowledge the business person does not have and the analyst was hired to supply. The second requires only that you know your own domain well enough to say what good looks like, which is the one thing the business person has always had and the analyst never fully did. When the platform can take a description of the outcome and compose the system, the translation layer stops being necessary — not because the work it did disappeared, but because the platform now does it.

That composition is what an Enterprise AI Platform actually provides, underneath the marketing. When someone describes an outcome to a system like StudioX, what gets assembled is not a static application but an AI Mission carried out by Autonomous AI Workers — a Reasoning Core that interprets the intent, Specialist Agents that handle the distinct parts of the work, Enterprise Knowledge that grounds them in how this specific company operates, and connections to the surrounding systems through the Model Context Protocol so the work can actually reach the ERP and the ledger and the inbox where the real data lives. The manager did not specify any of that. She described a result and a boundary — catch the exceptions, escalate the big ones to me — and the composition of agents, knowledge, and integrations that delivers it was the platform's problem to solve, not hers to draft.

Composition is a different act than construction, and it moves at a different speed

The reason this changes the clock so dramatically is that composing and constructing are not the same kind of activity, and they do not obey the same physics. Construction is additive and sequential: every field, every screen, every integration is a thing someone has to build, test, and wire, and the total time is the sum of all those parts, which is why the estimate always came back in quarters. Composition is closer to arrangement — the capabilities already exist as general faculties, the ability to read a document, reason over a policy, call an external system, ask a human for a decision, and the work is assembling them against a described outcome rather than fabricating each one from nothing. When the parts are faculties instead of custom code, adding a new outcome does not mean starting a new construction project. It means describing the outcome and letting the same underlying workers compose themselves around it, which is the difference between building a new machine and giving an existing team a new instruction.

That difference is also why the current wave of this is failing so often where it is done badly, and it is worth being honest about that failure rather than pretending the shift is frictionless. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear value, and "agent washing" — old tools relabeled without the substance changing underneath. Read against the shift in contract, most of those doomed projects share a diagnosis: they took the new tools and kept the old contract, using an agent to construct a rigidly specified system with a fixed path, which buys you the cost of AI and none of its point. A platform that only executes a pre-drawn workflow is still asking you to specify the system; it has just made the specification more expensive. The projects that clear the bar are the ones that let the person describe the outcome and trusted a reasoning layer to compose the path, including the paths nobody drew in advance, which is where the exceptions that consume real operations actually live.

When describing is enough, the author of software changes

The consequence that matters most is not speed, though the speed is real. It is that the identity of the person who builds software changes. For half a century, the author of a piece of enterprise software was whoever could hold the system in their head — the engineer, the analyst, the architect — because authorship required fluency in the machine's language, and the domain expert who actually understood the outcome was a source of requirements, never an author. When the contract becomes a description of an outcome, the fluency that matters is fluency in the domain, not the machine. The regional manager who knows exactly what a pricing exception looks like, what should escalate and what should not, where the judgment sits and where the rules are firm, is now the person best positioned to author the software, because authoring it has become a matter of describing the outcome precisely and setting the Human-in-the-Loop boundaries — work she was always the world's expert at and was never before allowed to do directly.

This is the quiet redistribution underneath the movement toward the autonomous enterprise: not that software gets built faster by the same people, but that the population able to build it expands from the few who could specify systems to the many who can describe outcomes. The bottleneck was never the engineers' capacity; it was the translation step that only they could perform, and that step is dissolving. When it dissolves, the queue of forty-page specifications waiting two quarters for a build slot stops being the shape of how work reaches software at all.

So the useful way to think about what is happening is not that AI writes the code faster. It is that the unit of a software request has changed from a blueprint to an intent. The old question — "can you specify exactly what the system should do?" — was always a filter that kept most of the people with the best outcomes in their heads out of the authoring room. The new question is simply "can you describe what you want to be true, and where you want to be asked?" — and almost everyone who runs a real operation can already answer it. The measure of an organization's software capacity used to be how many people it employed who could specify systems. It is becoming how many people it employs who can clearly describe an outcome, which turns out to be nearly everyone who understands the work.