The Work Got Faster. That Was the Easy Part.
Part 1 of an ongoing series on building an agentic engineering practice.
In June 2025 two of us started redesigning how a product organisation builds software. One from the product side, one from engineering. There was no mandate and no budget line. Fourteen months later the same practice runs across the entire engineering organisation.
The speed is the part people ask about. It is also the least interesting thing that happened.
The arithmetic didn't work
The company is a mid-size German software vendor. The core product has been in continuous development since 2001, roughly twenty-five years of accumulated business logic that no single document describes and whose original authors are mostly gone. Since 2022 there has been a successor platform, built in parallel: the thing actually sold and operated today, with genuinely new features on it.
Both at once, with one team. Roughly 19,700 work items across 24 development areas between early 2022 and mid-2026.
The honest statement of the problem was never "we should be faster." It was that the arithmetic did not close. You cannot innovate on a new platform and safely retire a twenty-five-year-old one with the same people, at the volumes required, by working harder. Something structural had to change or one of the two was going to be quietly abandoned.
We did not start by buying a tool
This is the part I would emphasise if I could only keep one fact from this article.
From June 2025 until 20 April 2026 the practice ran with no platform at all. A four-phase operating model, a defined set of artifacts, guardrails, an engineering manifesto, shared terminology. An alpha team was onboarded in September 2025. The whole organisation adopted it in January 2026. The platform — the harness, the hooks, the enforcement layer, all of it — arrived ten months after the method, as an enabler for something people were already doing.
At the time this was not strategy. It was the only option available. In retrospect it is the single most useful structural fact about the whole effort, because it settles an argument that otherwise cannot be settled: whatever worked here was not a property of a vendor. The tooling could not have caused a result that predated it by ten months.
The pilot, and what it does not prove
October and November 2025. Four developers, an alpha team, working on the real production platform inside defined guardrails. Seven features. Expected effort of roughly 154 person-days against roughly 50 actual. An average efficiency gain of 66%, and roughly six figures in direct saving.
What was compared: the measured effort we actually spent, against an estimate of what the classical path would have cost — the same seven features, built the way we had always built them, without agents. The estimate is of the road not taken. Nobody built those features conventionally, so the denominator is a counterfactual, and no amount of care makes a counterfactual an observation.
What that leaves is a single honest caveat: an unexecuted baseline can be wrong, and it cannot be checked after the fact.
One more number that gets left out when this story is told well: of 189 person-days invested, 102 went to enablement — building guardrails and capability — and 87 to productive delivery. More than half the investment was constructing the thing, not using it. The pilot paid for the practice and showed its payback inside two months, which is a better argument than the 66% and a less quotable one.
A 66% figure with its baseline problem stated is worth more than a 66% figure without one. That is the argument of this entire series, and this is the first place it applies — to my own headline number.
The team did not get smaller
Throughput rose with the same crew. What moved was where the crew spends its time: from roughly 20% specification and 80% implementation to roughly 80% specification, architecture and validation against 20% agent-executed implementation.
That inversion is the actual change. Everything else in this series is a consequence of it.
What got harder
Once execution is cheap, several things stop being protected by slowness.
A wrong decision used to take three weeks to become expensive. Now it ships. An unclear assumption used to get caught by some developer thinking about it on the way to implementing it; that person is no longer in the loop at that moment, and the assumption gets operationalised exactly as written. Architectural drift, which used to accumulate at human typing speed, accumulates at machine speed.
The bottleneck moved to whoever has to say this is what we want precisely enough that a machine cannot misread it. That job is harder than it sounds and it is not the job most product and engineering people were trained for.
And the thing that did not change at all: responsibility. It did not disappear when the typing did. It moved upstream and concentrated, and there are now fewer places where it sits, which makes those places heavier. The person who approves a specification is now approving what will actually be built, not opening a negotiation about it.
And the most expensive failure is no longer a technical one. Implementation has stopped being what separates one product from another — anyone can have working software written now. What separates them is whether the software solves a problem someone actually has, and whether it was built to survive contact with reality: maintainable, secure, defensible under the GDPR, still changeable in three years. An agent will not answer any of those questions for you. Product management answers them, which is why the bottleneck has not merely moved upstream but landed there, harder than it sat before. Skipping that work used to cost a late release. Now it buys a fast, well-tested, thoroughly documented implementation of the wrong idea.
The value of engineering work is in decisions, not keystrokes. That sentence became the operating principle. It sounds like a slogan until you notice it also assigns the blame.
Where this goes
If the bottleneck is specification, then a specification cannot stay what it was: a document someone writes, someone else skims, and everyone reinterprets during implementation. It has to become an artifact with a schema, a reviewer, and a gate that can refuse.
That is the next piece.