Last week I gave Claude an issue from one of my side projects and walked away. Ten minutes later it came back with a pull request that touched 95 files. I reviewed every change by hand. It was on par with a senior engineer with five to ten years of experience.
That’s not a typo, and it’s not vibe coding. It’s the opposite.
Agentic coding means handing a well-specified task to an AI agent and letting it implement, test, and raise a PR with no human in the loop during execution. The interesting question isn’t whether the agent can write code. It’s what has to be true around the agent for the output to clear an enterprise quality bar.
This post is about what that harness looks like, why stock spec-driven development doesn’t quite get you there, and why it’s mostly a requirements problem wearing a coding hat.
What Actually Happened
The project is NetPace, a C# .NET network speedtest command-line tool I maintain. The issue was a meaningful refactor — the kind of change that, done badly, leaves a trail of subtle bugs across the codebase.
I raised the issue, ran the workflow, and went to make a coffee. When I came back, the branch was green, tests passed, and the PR was waiting for review. I read every diff. There were no shortcuts, no hallucinated APIs, no dead code. The naming was consistent. The tests mapped to the spec. It would have passed code review from me as a senior reviewer without a single major comment.
Here’s the receipt if you want to see it: the issue and the resulting PR. Both have conversation threads between me and Claude so you can see the shape of the work.
The uncomfortable part for the “AI will never be good enough” crowd: this isn’t a cherry-picked demo. It’s a repeatable workflow. The harness is the interesting bit, not the model.
Why Stock SDD Isn’t Enough
Spec-driven development — the idea that you write a rigorous spec before touching code and let the agent implement from it — is the right starting point. It’s genuinely better than prompting an agent with a Jira ticket and hoping.
But stock SDD has two weaknesses that people don’t talk about enough.
No upfront tests. The spec describes what the system should do, but nothing locks that intent in a form the agent can be held to. The agent writes the implementation and the tests in the same pass, which means if it misinterprets a requirement, it’ll write a test that confirms the misinterpretation. Everything will look green.
No automated feedback loop confirming the agent did what it was told. You read the spec. The agent reads the spec. The agent writes code. Somewhere in the middle, scope drifts, edge cases get quietly dropped, and the only way to catch it is to re-read everything yourself. At which point you’ve saved no time at all.
Stock SDD, in other words, is manually governed verbose guardrails. It’s better than nothing, but it leans hard on the human reviewer to catch problems that the workflow itself should be catching mechanically.
The version I use fixes both weaknesses. Two custom slash commands — /speckit.testplan and /speckit.testchecklist — trace acceptance criteria in the spec to unit tests in the code, and verify after the fact that every named scenario has (at least one) real, non-trivially-passing test. The test plan is committed to the branch before implementation starts, which means intent is locked on disk and any drift shows up in the PR diff.
That’s the difference between “the agent followed the spec” as a hope and as a mechanically verifiable property.
Why It Worked — The Harness
The best way I can describe the underlying philosophy: imagine a 200-page single chat conversation that’s been compacted a dozen times, context fraying at the edges, the model half-remembering what it agreed to fifty turns ago. That’s what most people’s “agentic coding” actually looks like, and it’s why the output quality is uneven.
Now imagine the same work orchestrated as 50 isolated chats, each with a crisp outcome and a clean context, each completing to high quality, each needing a little manual review before the next one starts.
The measure of quality comes from the latter, not the former.
That’s the whole game. Everything in the workflow below is in service of that principle — decomposition, locked intent, fresh context, mechanical gates between stages.
The workflow itself runs roughly like this:
1. Write a rigorous spec first. Requirements as normative SHALL/MUST statements. No test scenarios in here, no implementation hints. I iterate on this with Claude until it feels airtight, and run a checklist to surface gaps before moving on.
2. Generate a test plan from the spec. Named WHEN/THEN scenarios derived from the spec, committed to the feature branch as test-plan.md. This is the locked intent. The agent can’t quietly change what “done” means partway through, because the test plan is already on disk.
3. Break the work into tasks, informed by the test plan. The decomposition reflects the full verification surface, not just the happy path.
4. Implement. The agent runs to suite-green, hands off. This is the ten-minute part everyone focuses on, and it’s the least interesting step.
5. Verify the test plan was honoured. Static analysis confirms every named scenario has a real, non-trivially-passing test with a comment pointing back to it. Not just “the suite is green” — every WHEN/THEN from the locked test plan accounted for. A pre-commit hook also calls dotnet test on the whole solution.
6. PR review as the integrity gate. My job as a human reviewer isn’t to re-read 95 files looking for bugs. It’s to diff the test plan against the original spec and check the coverage report. If the intent was locked and honoured, the code below it is trustworthy.
The full workflow lives in this document if you want to steal it. It builds on spec-kit and is inspired by OpenAI’s harness engineering work.
Why This Is a Requirements Problem
Here’s the bit that will annoy people who think agentic coding is a pure engineering problem.
A reader recently put it better than I could: SDD requires very good BA skills that the industry has not been respecting for a long time. That’s the whole story in one sentence. The quality gate isn’t the model. It’s the spec. Claude didn’t produce senior-quality code because it’s secretly a senior engineer — it produced senior-quality code because the spec was unambiguous, the test plan was locked before a line of implementation existed, and the PR couldn’t be raised without passing mechanical gates.
I’ve seen this movie before. It’s the same story as offshore delivery.
Offshore teams don’t fail because the engineers are bad. They fail because the requirements were vague and the specification discipline was missing. When requirements are tight, offshore delivery works beautifully. When they’re sloppy, you get exactly what you asked for — which is never what you wanted.
Agentic coding is offshore delivery at 1000x the speed with zero timezone lag. Every structural problem that plagues distributed teams applies. Every solution that works for distributed teams applies too.
This is also why business analysts aren’t being replaced by AI — they’re becoming the precondition for it. Someone has to write the spec the agent implements from. Someone has to own the test plan. Someone has to notice when a requirement is ambiguous before the agent cheerfully picks an interpretation and ships it.
The people who have been quietly insisting on clear requirements for twenty years just got a massive tailwind.
What This Means for You
If you’re a technical lead or an engineering manager thinking about agentic coding, four things are worth noting.
The agent amplifies your existing discipline, in both directions. If your team writes good specs and has rigorous review practices, agentic coding will multiply your throughput. If your team ships from Jira tickets that say “users want dark mode” with no acceptance criteria, you’ll generate 95-file pull requests of confident-looking garbage faster than you can review them.
Stop thinking about prompts. Start thinking about harnesses. The industry is currently obsessed with prompt engineering — tweaking the words you send to the model. That’s the least durable part of the stack. The durable part is the workflow around the agent: the spec template, the test plan format, the review gates, the commit hooks that run format and test before a PR can be raised. Those don’t go stale when the model changes.
Commit the specs, not just the code. The spec, the test plan, and the task breakdown all live on the feature branch alongside the implementation. The commit history becomes an audit trail of intent, which is something most teams have never actually had. Worth the effort on its own, agent or no agent.
Review the diff of intent, not the diff of code. When the agent has changed 95 files, reading every line is neither scalable nor the right job. Reading the test plan against the spec, and the coverage report against the test plan, is. This is a genuinely new reviewing skill and I suspect it’s what senior engineers will spend most of their time doing within two years.
Common Traps
A few patterns I’ve seen people fall into when they first try this.
❌ Skipping the spec because “Claude can figure it out.” It can’t. Or rather, it will, and you won’t like what it figured out. Write the spec.
❌ Letting the agent write the test plan and the implementation in the same pass. You lose the locked intent. The test plan needs to be committed before implementation starts, or it’s worthless as an integrity gate.
❌ Treating PR review as line-by-line code reading. You’ll burn out, miss things, or both. Diff the artefacts of intent instead.
❌ Using this workflow for ill-defined exploratory work. The harness is for production-quality changes to a known codebase. If you’re spiking an idea to see if it’s viable, the overhead isn’t worth it — different job, different tools.
In my last post, Software Development as Craft, I wrote about treating software development as a vocation and about heading up to “the shop” to do the work properly. Agentic coding, done with a proper harness around it, doesn’t threaten craftsmanship. It rewards it.
The engineers who still write specs carefully, who lock test intent before implementation, who review for quality rather than presence — those engineers are about to be absurdly productive. The ones shipping tickets they barely read were already in trouble. This just makes the gap visible faster.
Ten minutes, 95 files, senior-engineer quality. The headline number is real. The reason it’s real is boring, and it’s the same reason good software has always been good: somebody took the requirements seriously before anyone started writing code.