The gate that blocked our own agent

"AI agents can't do TDD." I hear this from people I respect: technical coaches with decades of practice, senior engineers who build with AI every day. The complaint is always the same. The agent writes the tests after the code. Or it writes all of them at once and then makes them pass in a batch. Or it quietly weakens a test to get to green. Whatever comes out the other end, it is not test-driven development, because nothing was driven.

Here is my confession: they are right. Ungoverned agents do exactly that. I know because last week one of ours tried.

Caught in the act

On the loan-servicing modernization I have written about before, the agentic team was starting a new area of the system: identity and access, beginning with the small core component that represents and verifies a password credential. First test cycle of the build. The agent sat down and produced a tidy suite of eleven tests before any real implementation existed.

A runtime gate blocked it. Not a linter warning, not a style comment in review: the cycle simply could not proceed. We run our agents under a written constitution, a set of engineering laws that a separate runtime checks at every step of the work, the way a CI pipeline checks a merge. The block cited the law it enforces, one failing test at a time, and the remediation path was specific: pare the suite down to a single failing test, then rebuild it behavior by behavior with a real test run between every step. Six of those steps were genuine red-to-green drives, where a new failing test forced new code into existence. The other five tests arrived green because the minimum code forced by the earlier drives already covered their cases, and each was kept only after a run proved exactly which behavior it locked down. Same eleven tests at the end. Completely different standing: every one of them earned its place, and the record shows the sequence.

Discipline is a system property

The mistake in the skeptic's framing is treating TDD as something a model either has or lacks, like a personality trait. Discipline was never a property of individual talent, even in humans. That is why we invented checklists, pairing, and working agreements.

Our constitution makes atomic TDD one of those laws. When the agent starts a build it commits up front to a number of test cycles, and every cycle must pass six checkpoints: before the failing test is written, after it fails, after the code goes green, after the refactor, before the commit, after the commit. At each checkpoint the agent submits evidence, actual test output rather than claims, and a violation is a hard block with a remediation path, not a note for later. Every checkpoint lands in a ledger, an append-only record a human can audit without re-reading the code. The build that caught our agent commits it to forty-two of those checks before the increment ships; the first cycles' checks are already in the ledger, and the rest land as the build does.

A failing test is a reward signal an agent cannot flatter, because the gate, not the agent, witnesses the transition.

That is why one test at a time matters for agents specifically. An agent optimizes for whatever signal it is given. If the signal is "the human seemed satisfied," you get plausible code and confident summaries. A failing test is ground truth: it fails, the implementation lands, it passes, and that transition is observed by the gate, not reported by the agent. Green is verified progress, not claimed progress. The red-to-green transition is the only currency the gates accept, which is exactly why the eleven-test suite was refused: ten of those reds were never going to be witnessed.

And that ground truth is not ceremony the agent performs for our benefit. It is the instrument the agent itself navigates by. The next two stories are about what it does with that instrument.

Gates make backtracking possible

When a gate blocks, the agent does not argue or push through. It unwinds to the last verified state and approaches again, the same way a human developer backs up to the last green commit when a change goes sideways. Here is what that buys you.

Mid-build, a session died abruptly, right at red of the first cycle. The next session did not guess. It asked the governance runtime where the work stood, found that the plan the dead session had declared did not match the agreed one, corrected the record in the open and noted the discrepancy for the audit trail, re-declared the plan correctly, re-ran the failing test to confirm red was still red, and resumed exactly where the work had stopped. A brand-new session with no memory of the last one picked up mid-cycle with zero lost work and zero silent drift, because the state of the work lives in the ledger and the tests, not in the agent's head.

Non-code work runs the same heartbeat: expect, do, verify, commit, where verification is perception. For UI work that means a screenshot or rendered output checked against the stated expectation, not an assurance that it probably looks right.

One test at a time is a design tool

Most engineers meet TDD as a testing practice. The practitioners who shaped it have always insisted it is really a design discipline, and that holds for agents too. One behavior at a time forces the same incremental decomposition that makes designs good, and the agent makes real design decisions inside that loop, just as a human pair would.

We watch it happen through mutation testing, a practice where small deliberate bugs are planted in the code to prove the tests would catch them. One planted bug survived because a calculation was duplicated purely to build an error message; the fix was to collapse it to a single expression, so that the existing test catches any tampering with the arithmetic by construction. The test did not just check the design. It changed it.

The sharper story: after one module scored perfectly against the mutation tool, the agent went further and planted a bug of its own, a kind the tool cannot generate. The change was a single word, flipping the direction the code reads the payment history. Every one of the 293 tests still passed, because the wrong number only appears once a third payment is posted, and no test had gone that far. The team wrote the missing test, one that posts three payments and checks that the third builds on the second rather than the first, and recorded a standing rule: any calculation whose answer depends on the order it reads history gets a test with at least three entries. The discipline runs past the edge of what the tooling automates.

The same bar, no matter who writes the code

The gates do not care whether a human or an agent authored a change. The floor is a mutation score of at least 90 percent maintained throughout the build, and in practice every module has shipped catching 100 percent of the planted bugs that actually change behavior. Even the verifier gets verified: when the mutation tool itself misreported a result this week, the agent re-applied the mutation by hand, watched the right test kill it immediately, and recorded the finding as a tool defect rather than a coverage gap. Trust nothing, verify everything, including the instruments.

The heartbeat is the product

The skeptics are describing agents as they mostly are: fast, plausible, and undisciplined the moment nobody is watching. Our answer is not a smarter model. It is a system in which the disciplined path is the only path that ships: gates that block, evidence the agent cannot fabricate, checkpoints any future session can resume from, and a ledger a human can audit without re-reading the code. That heartbeat is what makes long-running, multi-session agentic work safe to trust, and it is the core of what we build at ClickChain AI.

If you want to watch a gate block an agent on your codebase, book a walkthrough and we will show you live.

---

Adeel Ali is the founder of ClickChain AI, where teams use AI to amplify their best engineers instead of replacing their judgment.