The matter before this bench arose at eleven past eleven on a Wednesday night. A pull request, filed by a junior PM who had over lunch asked an agent to "build the rate limiting middleware we discussed," ran two thousand lines of new code, 93 tests, and 92 percent line coverage; CI returned green inside three minutes. The senior reviewer, examining the matter the following morning over a second cup of cha at his Dhanmondi desk, recorded his approval. By Friday afternoon the rate limiter was quietly admitting traffic it had been designed to refuse, and an apologetic email was being drafted in Gulshan.
The rate limiter, your lordships will appreciate, was not broken in any conventional sense. The tests asserted what the code did, the code did what the tests asserted, and both halves had been authored by the same agent inside a window of forty five seconds against the same shaky reading of what the team had meant. The failure mode is not isolated. The test suite has displaced both the specification and the source code as the artefact carrying the most weight in any codebase touched by agents, and the consequences require setting down.
I had occasion, in an earlier essay, to consider how a specification ages. By the thirtieth day the document is out of step with the running system, by the ninetieth it has hardened into folklore, and somewhere past the first year it survives only as a ghost behind a deactivated single sign on seat. Source code, until recently, decayed at a more dignified pace. Engineers rewrote it on quarterly schedules, refactors had review rituals attached, and the version on main bore at least passing resemblance to the document it had shipped against. That equilibrium is over.
In a codebase touched by an agent, the source rewrites at the speed of pull requests, roughly the speed of conversation. A function that existed last Tuesday may be gone by Friday, replaced by something the agent decided was equivalent after reading three threads on the team's chat. A class hierarchy that took a quarter to shape may be flattened on a Saturday by an agent that found composition cleaner. Code that once aged in months now ages in days.
The single artefact that does not decay is the test suite, and only because the build server does not permit it to. Every push runs the suite in full, every failure blocks the merge, and every stale test is caught the moment the system underneath has moved on. CI forces the suite to remain current with the system in a manner no specification document was ever forced to.
The code reflects whichever agent last touched the file. The specification reflects whoever wrote it three quarters ago and has since moved teams. The test suite, executed on every push and broken by the smallest deviation, is required to keep being true between this morning's standup and the quarterly business review in November.
That mechanical constraint, this bench respectfully submits, is what makes the test suite the new specification. It is not chosen for the role; it is conscripted into it by the build server. Like a precedent, it is binding because it is enforced; unlike a precedent, it is enforced not by the dignity of the institution but by a YAML file in the project root.
First, the tests have become the only durable record of intent anyone in the loop actually consults. The code embodies the agent's reading of intent at the moment of generation, quick and confident and quietly off by a degree or two from what the team had in mind. The specification embodies the human's reading at the moment of writing, already decaying by the time anyone refers back to it. The tests, by virtue of daily execution, are the only artefact saying "this is what we mean" in a form the build server enforces.
The second consequence is darker. When tests are authored by the same agent that authored the code, they do not carry intent at all; they carry the agent's reading of what was built, the same shaky reading that produced the code. The tests pass because the agent designed them to, and the suite remains green because the agent rewrites both halves any time the system shifts. CI being green has stopped meaning the code is correct, and started meaning the agent is internally consistent with itself, a meaningfully weaker property that most engineering culture has not yet adjusted its priors to handle.
The shape of pull request review must therefore change. The senior engineer was the person best positioned to answer "does this code do what the diff claims it does," hard work done in the diff viewer at eight in the morning with a fresh cup of cha. CI now answers that faster and more thoroughly than any human can. What is left is the slower question of whether the tests describe what the team had wanted or merely what the agent had built. That review is closer to a magazine copy edit than an engineering review, and the engineering teams of 2026 are not yet organised to do it well.
A technique long obscure, ignored by practising engineers for the better part of a decade, has quietly returned to relevance. Mutation testing instruments the suite by introducing small deliberate defects into the code, such as flipping a > to a >=, nudging a loop bound off by one, or negating a boolean. A tool like Pitest or Stryker generates these mutants, runs the suite against each, and reports whether the suite caught the change. If a mutation passes undetected, the suite is not testing behaviour at that branch, regardless of what coverage claims. The technique has always been more honest than line coverage, but it was slow and the profession left it on the shelf.
The arithmetic changes when an agent has authored both halves. Line coverage becomes theatre, because the agent hit every line by construction; it had to read the lines to write the test. The question that matters is whether the tests are sensitive to changes in behaviour, which is what mutation testing was designed to answer. This bench has made it a practice, on any pull request where an agent authored both code and tests, to run mutation analysis as a step before review.
Exhibit C · forensic mutation analysis
in re. PR #2174
Line coverage
92%
the agent touched every line
Mutation score
92%
the suite knew almost nothing
A coverage report of 92% paired with a mutation score of 92% is what an agent-generated false positive looks like in 2026, the kind a Dhanmondi reviewer at his second cha would mark for another round.
A gap of fifty points between line coverage and mutation score is what an agent generated false positive looks like in 2026. Treat any such pull request as untested, regardless of the colour of the CI dot, and require either a mutation gate or a set of plain English assertions authored by a human before merge. The background reading on why the assertion language matters sits inside Anthropic's work on contextual retrieval; a model behaves better the more clearly the question is framed, and so do the engineers who will read your tests in November.
I am not myself an engineer, and I do not write test code in any serious capacity. What I have begun to do, on every feature whose outcome is mine to defend, is write the assertions in plain English first and let the agent translate. They live in a small markdown file checked in beside the test code, and test names correspond one to one with lines in that file. When the suite breaks in six months on a rewrite I will not be in the room for, the next reader is not asked to reconstruct my meaning from the test name. They read the assertion in the language it was written in, decide whether the test still encodes it, and either fix the test or fix the code.
I keep returning, in my mind, to a brown notebook on a hook in a mudi dokan in Mohammadpur, the one Mostofa bhai has kept by the calendar for thirteen years. The notebook is the only artefact in the shop that survives every change. Workers rotate; the wholesaler shifts every two years when somebody offers a better deal on Pran biscuit; and the shop owner's son will take over the till without having watched the early years from behind it. None of those people inherits the inventory, which turns over weekly, nor the customer base, which is mostly a neighbourhood that itself moves every few years. The notebook is what gets inherited, page by page, and the modest economic engine of the place has been resting on it for thirteen years.
The test suite in an agentic codebase is that notebook. The code corresponds to the inventory, turning over weekly; the specification document to last quarter's wholesaler list, already superseded by the time it is consulted; and the team itself to the worker rotation behind the till. What the next engineer inherits, and what the next agent reads when it refactors a service in 2027, is the suite. It is the only artefact continuously executed and continuously updated since the first commit, with the system's actual behaviour quietly anchored to it the entire time.
The work in an agentic codebase has, this bench concludes, very little to do with writing tests faster. The work is encoding what you meant in a form the build server will keep verifying after you have moved teams. It must survive the agent being replaced and the function under test being rewritten on a Saturday by someone you have never met. The agent will ship working code by Tuesday regardless. The plain English assertion file is the part that survives three handovers, and writing it takes about forty minutes that no sprint board has a column for.