An AI agent writes as much code in an hour as your team writes in a week. That looks like a speed problem somebody has solved — and it is really a requirements problem that has only just started.
The hour got cheap. What comes after it did not. At the end of the hour you have eight hundred lines in front of you, cleanly formatted, with tests, and next to them the ticket they came from: three sentences, written for a colleague who sat in the meeting. Somebody now has to decide whether the eight hundred lines match the three sentences — and, more to the point, whether the assumptions in between are the right ones.
The week did not disappear. It moved off the keyboard and onto the screen, to a place nobody has practised and nobody has budgeted for.
And there it is invisible. Nobody logs “read the output” on a timesheet. It looks like reading, it feels like checking, and at the end of the day you have the sense of having produced nothing — even though that was the actual work.
An agent amplifies what it is given
An agent is not a faster developer. It is an amplifier. It takes the brief it is handed and multiplies it — the clarity as much as the gap. A good brief turns an hour into a week of work. A bad one turns an hour into a week of rework, and the rework arrives looking like a finished result.
That is the uncomfortable part: what an agent guesses does not look like a guess. A person who gets stuck on an unclear point leaves a TODO, posts in the team channel, or waits until tomorrow. An agent leaves an implementation at exactly that point — named, commented, tested, in the style of the rest of the project. The assumption is now indistinguishable from a decision. It surfaces when somebody sees the behaviour: in review if you are lucky, in the demo if you are not.
For twenty years, building was the expensive part of a project, and everything else arranged itself around that fact — estimates, sprints, the question of how many developers a team can still absorb. The arithmetic has changed. The bottleneck is no longer the building. It is the question of what exactly should be built, stated precisely enough that nobody has to answer it on your behalf.
Review does not absorb the shift. Read generated code against a vague ticket and what you end up checking is naming, structure and style — the questions the code can answer about itself. Whether the behaviour is the wanted behaviour cannot be settled there, because the thing you would hold it against is missing. A review with no solid requirement behind it is a verdict on readability. Two colleagues can give that quickly, and it says nothing about correctness.
This is the point where good engineers go quiet. Not because they are missing something, but because they realise they are being asked to answer a question nobody asked before them: was any of this what was meant?
“Context” is the word everyone reaches for, and it sounds like tooling. It is work. Somebody has to produce the context, write it down, keep it current and make it findable — the same work a new colleague needs in their first week. Except that an agent needs it every single time. It has no first week. It has this one run, and whatever is not in the brief does not exist for it.
What a requirement an agent can build from looks like
Four properties, none of them new. What is new is that their absence costs you something today rather than in three weeks.
- Bounded. One outcome, one boundary. Not “reporting”, but the one report — plus the sentence saying what is explicitly not part of it.
- Checkable. An observable result nobody can argue about afterwards: a number, a condition, a behaviour.
- Self-contained. Everything needed to build it is in the text or reachable from it: who asked for this, which neighbouring requirement it touches, which rule already applies. An agent was in no meeting.
- In the language your team thinks in. “Beleg”, “Vorgang”, “Sachbearbeiter” do not survive translation into English intact — and after that the model is building against an approximate word.
Here is one as it arrives on an ordinary day: “the approval process for quotes needs to get simpler.”
An agent will build something from that. It will find an approval, simplify a rule, and deliver. What it cannot know: which approval was meant, above which amount one is needed at all, whether discounts are an exception, and what happens when somebody works around the rule. Four decisions it makes because they have to be made — not because it presumes to make them.
The same thing, written so it holds: as a sales lead I want to send quotes up to 10,000 euros without a second approval, so that a standard quote reaches the customer the same day. Scope: the threshold is configurable per organisation, special discounts still require approval, every exception is noted on the record. Not included: framework agreements and their renewal. It is met when a quote of 9,800 euros goes out without a second click and one of 10,200 euros does not.
Four sentences and ten minutes separate the two. The agent takes the same time over the first as over the second. You take two days longer afterwards.
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."
None of this preparation is specific to AI. A team that keeps its requirements this way wins without a single agent anywhere near it — shorter reviews, fewer follow-up questions, less arguing in the demo. The agent only makes the arithmetic visible, because it turns a weak brief into code faster than a person can correct it.
The prompt is not where the work starts. It is what the work produces.
Handover: what actually leaves the building today
At some point a requirement leaves the tool it is maintained in. There are three ways out today, and each has a limit worth knowing in advance.
The first is Jira. One click turns a requirement into an issue, and exactly five fields make the trip: project, summary, description, issue type and priority. angajuu picks the type itself — Epic for a product requirement, Story for a customer requirement. No labels, no components, no assignee. And above all: the issue is created once and never touched again. Edit the requirement afterwards and Jira stays exactly as it was.
Little comes back, deliberately. The status sync is switched off by default, and it only ever reads — nothing is ever written back. Switched on, it takes four readings from the issue: its status, its resolution date, which version it carries, and whether that version is marked released. Customer requirements are one-way anyway, and only product requirements with their own epic are affected at all. There is no screen for mapping your Jira workflow onto the states in angajuu: whatever is unmapped quietly lands on In Progress. And angajuu never re-plans itself — when Jira drifts from the plan, the drift becomes a work queue for a human, not a silent correction.
The second way out is the Product Requirements Document. It belongs to a project and describes that project's customer requirements: ordered by priority, grouped, with a coverage figure built from confirmed links. Out comes a PDF or a Markdown file. Know the limit before you send the first one: the content is produced and stored in both languages, and both export formats emit the English half only.
The third is the vendor package per release, again as PDF or Markdown. It is rendered at the moment you ask for it and stored nowhere. Send it and you have sent the state of today — tomorrow the state is a different one.
All three share one trait: they produce a copy. The moment the issue sits in Jira or the PDF sits in an inbox, that copy starts to age. For a person this is survivable, because a person asks. For an agent it is the failure itself. It reads the copy and takes it for the current state — with the same confidence it brings to everything else it reads.
In progress The next step is an MCP server: your requirements as live, retrievable context inside the agent's own tool — no copy, no handover, nothing going stale.
What to write down before the next run
Half a page, and four things on it.
- The outcome, not the route. An agent does not need a procedure. It needs a goal and a boundary.
- What is explicitly not included — and what it must not touch. The second half of that saves the most rework.
- The context it cannot look up anywhere: why this was asked for, by whom, and which existing rule stands in the way.
- The sentence by which you will recognise that it is done. If none comes to mind, the requirement is not finished — and the agent will invent that sentence for you.
Then a check that takes twenty seconds: read the text again and mark every place where you filled something in from memory as you read. Those are exactly the places the agent fills too — only with something else.
It is an unremarkable half page, and while you are writing it, it feels like a detour. You notice the difference when the run comes back and you no longer have to take the result apart to work out whether it is the right thing.
The discipline underneath all of this, for people and models alike, is in VSDD — Verified Spec-Driven Development: spec first, test first, a review that pushes back, and a “done” that answers two questions instead of one. And to see what both feel like in an ordinary week, once the requirement genuinely holds, A day in the dev team walks through one day, from the ticket in the morning to the question of what the work actually covered.