For thirty years there was a quiet agreement about who makes software: whoever types.
What has shifted
Nobody ever wrote the agreement down. It simply sat in the org charts, in the job ads, in every estimate. Whoever spoke the language the machine answers in held the key to the workshop. Everything upstream of that — listening, clarifying, writing it down — was preparation. Useful, certainly. Just not the place where anything came into being.
The agreement had a good reason behind it, and the reason was time. Weeks stood between an idea and something running. Weeks are expensive, so the bottleneck was wherever the weeks were spent: in the building. Nearly every method of the last three decades is an answer to that one bottleneck — reuse, frameworks, automation, shorter cycles. All of them turn the same screw.
The weeks are gone. Hand an agent a clean brief today and a few minutes later you have something that starts, that comes with tests, and that you can take apart. Not for every problem, not inside every system that has been growing since 2009, and not without somebody who reads the result. But for enough of the work that the arithmetic flips.
That does not mean programmers are finished, and this is not a politeness. Architecture is still hard. A fault that only appears under load, and only where three systems meet, is still hard. Deciding which dependency you are taking on for the next five years is still hard. What has stopped is something narrower but far more consequential: general coding is no longer the bottleneck. It is abundant, it is fast, and it is waiting.
A bottleneck never disappears. It moves. This one has moved one station upstream, into whatever goes into the brief. An agent amplifies the quality of its brief — upward and downward, and at the same speed either way. What that looks like in detail is the subject of AI-driven development starts before the prompt. What matters here is the consequence, which is less comfortable. If the brief decides, then the sentence decides.
Not what you meant. What is written down.
The sentence as a made thing
A sentence in an email is a signal to a person. It is allowed to be approximate, because at the other end sits someone who can ask, who has known the customer for four years, who still has the last three meetings in their head. Approximate is enough, because a human fills the gaps, usually without noticing. Which is exactly why nobody notices how many gaps there are.
A sentence you build from is a different object. It carries three things the email sentence does not. An origin: who asked for this, and in what context. A scope: what belongs to it and what expressly does not. A state: whether it is a draft, in review, approved or delivered. Only with all three does it stop being an opinion and become something that can be handed on without its author walking alongside it.
HOW IT ARRIVES
"The invoicing module needs to be more flexible."
HOW IT BECOMES BUILDABLE
"Accounting issues one consolidated invoice per quarter for a customer with several projects, itemised by project."
The difference between the two is not length, and it is not a matter of style. The first describes a feeling about a piece of software. The second names somebody who does something, a situation they do it in, and a result you can look at. Which means the second one can be wrong — and that is its real value. A sentence that can be wrong is a sentence you can build from. The first one cannot be wrong. It can only disappoint, three months later, in a review.
“More flexible” is not a failure of effort. It is an honest summary of something a person has not finished thinking through yet — and finishing that thought is the work this article is about. It consists of two follow-up questions, five minutes on the phone, and a willingness to commit. The same two questions cost two days once the work is under way, because by then somebody has guessed. An agent guesses faster and more convincingly than any human being.
The hardest half of scope is the explicit not. Nobody enjoys writing down what a thing is not for: it reads as small-minded, and every negation is a decision somebody has to defend later. It is still the most useful line in the document. “No part payments, no foreign currency, no cancellations across a quarter boundary” prevents three weeks of work nobody asked for — and three weeks that no longer arrive as weeks. They arrive as one afternoon in which all of it was already built.
What follows from it
This work has never had a good name. “Requirements engineering” sounds like forms. “Requirements management” sounds like somebody maintaining a list. Both describe support work, and both are why the activity spent thirty years below the level at which things were decided.
What it actually is has an older name: authorship. Somebody decides what is written down. The activity is not new; its position is. For the first time it sits on the critical path rather than in front of it. What you write gets built, very nearly as written, and very nearly at once.
That asks three things, and none of them is diligence. First, precision instead of completeness: twenty sharp sentences beat two hundred soft ones. Second, a willingness to commit — write nothing that could be wrong and you have written nothing. Third, carrying the origin along: a sentence with no answer to “who asked for this, and why?” is landfill after the next handover, because nobody can judge whether it still holds. What it looks like when that chain has already snapped is the subject of Why requirements fail.
It also asks for something less pleasant. An author is accountable. “That is not how I meant it” loses its force when what got built is exactly what was written. That shift is the price of the new position, and it is the proof of it: only somebody with something to decide carries responsibility for the decision.
And it can be learned. It has tools, it has recurring failure modes, it has practice that visibly works. Which is why the word above this article is craft and not talent. What it feels like across an ordinary working day, rather than read as a method, is A day as a Product Owner.
And what does not exist yet
In progress Three things this argument implies are not in angajuu today, and naming them is more honest than writing around them. Acceptance criteria as data of their own: a sentence can describe how you would recognise it as fulfilled, but only as running text inside its description — not as separate, checkable conditions. The handover to a development environment over MCP, meaning a connection an agent reads the requirements through live instead of receiving a copy: not built, not one line of it. And change propagation: rewrite a customer requirement today and nothing happens to the product requirements hanging off it — they are not flagged, nobody is notified, and coverage keeps counting the links rather than the text. Those are the three places where the idea in this article reaches further than the tool does.
What does exist is the beginning of the same line: one place where the sentence stands once — with its origin and its state — and a gate that will not let it through while the origin is missing or the description is too thin. That is little, measured against what still has to come. It is a great deal, measured against a spreadsheet whose filename ends in “final_v2”.
The agreement of the last thirty years was not wrong. It was a reasonable answer to time being scarce in the building. That time is not scarce any more. What is scarce now is the sentence exact enough to be built — and the person who writes it makes software. Even when they do not type.