Building in the Agentic Era, Part 4. By Mike.
When an agent says every test is green, it’s telling you it passed the tests it could see. Whether it built what you asked for is a different question. If you lead a team that ships agent-written code, or you’re the engineer signing off on it, that second question is yours now.
Review can’t keep up with how much code agents write, so more of the checking lands on the test suite. Left alone, agents write their own tests, and they make sure nearly all of them pass.
We’ve all seen it, and I’ve hit it more than once on my own projects. On a photo app I’m building on the side, the suite was green at 2,923 tests the same day I looked at it on my phone and said it looked wrong. Every screen had the right pieces. The spacing, the borders and the font weights were off, and not one test knew what right was supposed to look like. Other times it’s an error nothing ever tested. In spec-factory, my personal project, one test checked a file’s hash by calling the same hash function as the code it was testing. If that function had broken, the test would have agreed with it and stayed green.
I’m not saying I have a magic fix for it. There are ways to improve the intent we give the LLM, though. One I love is Anthropic’s The AI-native SDLC playbook on Claude Academy, a set of plays for using Claude at each stage of the software development lifecycle (SDLC).
In Issue 06 I wrote about keeping specs true once agents build from them, and the rule under it: agents draft, humans sign. This issue takes the next step. Say the spec is true. How do you know the build matches it?
In this issue
What a new benchmark found when it graded agents on tests they never saw
Why a green suite tells you less as the code grows
Two kinds of tests, and which kind you should write yourself
A checklist for the next build an agent hands you
The problem
A benchmark on arXiv this year puts numbers on the gap. SpecBench, from Weco AI, grades coding agents on 30 tasks, twice. First on the tests the agent could see, then on held-out tests that combine features. In a SQL task, the visible tests check SELECT, JOIN and GROUP BY one at a time, and the held-out tests combine all three. The agents pass nearly all of the visible tests. On the held-out tests the gap stays open, and it grows by about 23 points on average for every tenfold increase in code size. At the bad end of the spread (the 90th percentile), it’s about 28.
It’s 30 tasks in a benchmark, so I’d hold the exact figures loosely. SpecBench handed the agents their visible tests, so it didn’t measure suites the agents wrote themselves. Still, the direction lines up with what I’ve seen when agents write their own tests. An agent that can see the tests will keep working until they pass, which is what you asked it to do. So a suite the agent wrote mostly measures whether the agent thinks it’s finished.
The cost shows up later, at the outcome. In Issue 02 I put one item on the checklist for the end of a build: check the result against the use cases, not just green tests. If nobody wrote the use cases down before the build, that check has nothing to stand on, and the green suite is all you’ve got. The benchmark says that suite tells you less as the code gets bigger, which is exactly when you can least afford to read it all.
The model
My answer is to take the time up front so the agent builds the right tests. There are two kinds of tests in any agent build, and they do different jobs.
The first kind is the tests the agent writes while it builds. It will write plenty of them, and nearly all of them will pass.
The second kind is the tests you’ve thought through before the build starts. They’re tests for the core use cases of your application or platform, written so they fail for the right reasons. A test fails for the right reason when it breaks because the behavior is wrong, and stays green only when the behavior is right. These are the tests that define done, and a person writes them, or at least decides them.
In order, it looks like this:
Write the core use cases down before the build. The newcomer test from Issue 02 applies: could someone who knows nothing about the project read them and tell whether the outcome is right?
Turn each use case into a test that fails for the right reason, and watch it fail before any code exists.
Let the agent build, and let it write its own tests along the way.
Keep a few checks the agent never sees, especially ones that combine features, and run them at the end.
Read the outcome against the use cases, then sign.
The fourth step is the one SpecBench measures.
How much to write up front
This costs time, and I won’t pretend it doesn’t. Go light and the agent is off to the races, but the gaps surface at the outcome, or after a user finds them. Go heavy and you spend real hours writing tests before anything exists, some of them for cases that never come up.
I’d size it with the cost-and-rollback grid from Issue 02. A change that’s expensive if it’s wrong and slow to back out gets the full set of use-case tests and some held-back checks. A cheap change you can roll back in minutes can lean harder on the agent’s own tests.
Back in spec-factory, I keep a list of must-have requirements, written up front, that the agents are told never to open. Only a separate judge reads it, after the run. On one run every visible check passed: every document approved, lint clean, traceability passing. The hidden list still caught a requirement that had quietly dropped out, a rollout order (which team goes first). That run cost about $200, and the release stayed unfinished. It was worth it, because nothing else would have told me.
Try it this week
If you try one thing this week: pick the last feature an agent built for you and write down its three most important use cases, without looking at its tests. Then check each one against the tests it wrote. If a use case has no test that would fail when it breaks, you’ve found your gap.
A checklist you can steal
Copy it, change it, make it yours.
Before the build:
Write the core use cases down, in words a newcomer could check.
Turn each one into a test that fails for the right reason, and watch it fail first.
Place the work on the cost-and-rollback grid to decide how much to write up front.
While the agent builds:
Let it write its own tests, and keep them separate from the tests that define done.
Hold back a few checks it never sees, especially ones that combine features.
At the outcome:
Run the held-back checks.
Read the result against the use cases before anyone signs.
The takeaway
A green test suite tells you an agent passed the tests it could see, and that’s all it tells you. Whether the build does what you asked depends on tests that came from a person: the core use cases, written down before the build, with tests that fail for the right reasons. Engineers get a clear definition of done to build against, and leaders get a check they can trust when nobody can review every line.
I’m curious where other teams have landed on this. Who writes the tests that define done on your team, the people or the agents? Hit reply and tell me. The best answers will turn into future issues.
Reading list
SpecBench, from Weco AI, for the visible and held-out test numbers in this issue.
The AI-native SDLC playbook, from Anthropic’s Claude Academy, for plays that sharpen the intent you give an agent at each stage of the lifecycle.
Rishi is back Thursday.
The opinions expressed here are our own and do not represent any employer, past or present. Nothing in this publication describes any specific company’s internal systems, data, vendors, teams, metrics, or plans. Sponsored placements and sponsored briefs are clearly labeled.
Till next time,
Ellis & Kherdekar