If you've worked with AI agents like Cursor AI or GitHub Copilot over the past few months, you know the feeling: something fundamental is shifting. It's probably the biggest change in how software developers work since the publication of the Agile Manifesto in 2001 and its breakthrough as a mainstream phenomenon about a decade ago.
Hardly any company, regardless of industry, still relies on the infamous Waterfall – agile development with Scrum as its best-known framework and countless offshoots has won.
But the question needs asking: with the breakthrough of AI coding agents, is the golden age of Scrum Masters, retros, and sprints coming to an end?
"Over time, complexity started to look like sophistication. Overhead kept growing, and the process became the work." — Linear, "Issue tracking is dead"
When Development Time Is No Longer the Bottleneck
Yes, AI coding has weaknesses. Hallucinations, missing system context, questionable architecture decisions – human review remains essential. But even the harshest critics will admit that the results are, at times, extremely impressive. And we're at the beginning of this curve, not the end.
Used correctly, development time for new features shrinks dramatically. Developers shift from being implementers to reviewers and guardians of system coherence.
Where developer capacity used to be the bottleneck – the backlog filling up faster than the team could say Daily Standup – an interesting shift is taking place: the focus is no longer on churning through tasks, but on precisely specifying what the AI should build during your next coffee break.
Tickets Are for Humans, Requirements Are for Machines
This is the core challenge going forward: identify problems, design solutions, and describe it all as precise requirements – implementation then comes practically for free.
What would be better suited for this than that trusty old thing everyone loves to hate – the specification?
The difference from tickets matters: a ticket is typically narrative, context-dependent, written for a human developer. "As a user, I want to..." – that's prose. A specification, by contrast, is inherently unambiguous, testable, and follows a semi-formal language. Exactly what machines need.
| Ticket | Specification | |
|---|---|---|
| Language | Narrative, prose | Semi-formal, structured |
| Audience | Human developer | Human + machine |
| Testability | Implicit, open to interpretation | Explicit, verifiable |
| Ambiguity | Context-dependent | Unambiguous by definition |
The pattern isn't new. It follows the core idea of software engineering since the NATO Conference in 1968, where the term was first coined: define, (implement), test, manage, maintain. Except that implement is increasingly being delegated to the machine.
So instead of writing elaborate ticket descriptions, poker-estimating the effort, tracking it all in GANTT charts, and then translating that into prompts for the machines – why not put a machine-oriented specification front and center?
A well-curated requirements document with priorities, a complete set of test cases – and the team could honestly take two weeks off while the agents do the work. Well-rested and back just in time for delivery.
But it's not that simple.
The Product Is Only as Good as Its Specification
This shift will happen. But it won't mean less cognitive load for the team – quite the opposite. The product will never be better than its specification. And anyone who has tried to write truly unambiguous, complete, and testable requirements knows how hard that actually is.
On most developers' popularity scale, specification ranks somewhere around meetings without an agenda. And fair enough – traditional spec work is often bureaucratic, slow, and completely disconnected from the code.
A primary goal must therefore be to make specification work more attractive.
Specification, Reimagined
This is exactly what we're working on with OakCore. The specification is where the product is decided – it stands or falls here. So the tooling can't be an afterthought: no rigid lists in tools from the '90s, no Excel sheets bouncing between departments via email, no copy-pasting between requirements, risk assessments, and test plans.
OakCore brings it all into one place. Requirements, tests, risk management, and traceability in a connected structure – a single source of truth across project roles. Product managers, developers, QA, and compliance all work from the same foundation. AI checks specs for contradictions and gaps before the first agent writes a single line of code. Test results from the pipeline flow directly back into the graph – you see immediately which requirements are covered and where things are on fire.
The goal: specification work that doesn't feel like paperwork, but like what it should be – the interface between human thinking and machine execution.
Less how, more what and why. The specification becomes the central artifact. Whoever masters it, controls the machine.