Tests first, and woe to the agent that changes them: TDD imposed on machines

TDFlow reaches 88.8% on SWE-Bench Lite when tests are supplied before code. At Maestro, tests have been written BEFORE each story since July, with one simple rule: an agent modifying a test, even a pre-existing one, is flagged.

A recent research paper shows TDFlow reaching 88.8% success on SWE-Bench Lite when human-written tests are supplied before code is written (arxiv.org/pdf/2510.23761). At Maestro, each story's verification contracts have been fixed before development since July, with a strict rule: an agent modifying a test, even a pre-existing one, is flagged.

AI cheating on the exam

The problem documented by developers working with agents is precise. On Hacker News: ‘it's impossible for a coding agent to restrain itself from delivering a fully-formed implementation FIRST, in one fell swoop. And THEN it generates the test afterward’ (burnerToBetOut, news.ycombinator.com/item?id=46580108). Another, on the order that matters: ‘if you don't do this, it will churn out tests that pass but don't actually identify when things break’ (0xbadcafebee, news.ycombinator.com/item?id=48416641). A test written after code bends to the code; a test written before it imposes a constraint the code must satisfy.

Why order matters, not merely the presence of tests

An agent that first writes an implementation, then generates tests to cover it, grades its own homework. Reversing the contract, tests before code, fixed from the story breakdown, prevents that drift: code must satisfy a requirement established upstream, independently of what the implementation eventually does. It is the same principle answering the third criticism in the ‘waterfall strikes back’ thread about the LLM as a non-deterministic compiler: the model remains probabilistic; what it must satisfy no longer is.

What an altered test reveals

The hardest part is not writing the test first; it is preventing a later repair from quietly rewriting it to pass. A test modified during a fix, even if it existed before the agent touched it, triggers an explicit report. This is an implementation detail, but it makes the guarantee real: without that report, nothing stops a stuck agent from simply relaxing the requirement instead of correcting the code.

What it cost us

Introducing this rule surfaced 13 real defects during the subsequent cross-check, defects that would otherwise have stayed invisible until a real user discovered them in production. The price also affects restraint: express mode, the fastest, consumes a method budget multiplied by 1.000, the reference, and standard mode by only 1.075, a measured overhead deliberately contained rather than allowed to grow. All the extra depth TDD requires goes into standard and complete modes, never express, which remains tailored to a prototype discarded without regret.

What you see: green lights, not code

You never have to read a line of test code or know what a test is. What human approval asks is whether the story does what you wanted, not whether you can verify the technical machinery proving it behind the scenes. TDD imposed on agents is an insurance policy: you do not read the contract line by line; you check it was signed before the loss, not after.