Why I asked my agents to write the tests first

It doesn't look like a developer's method. It's a rule of trust. And it was born from an incident, not from a theory.

I run a team of AI agents on a control tower. Nobody ever asks me: why the tests first? Let me tell you what happened when I didn't enforce it yet.

An agent would tell me "it's done." Nothing in its answer let me check that other than by going to look myself, at an hour when I don't want to go look. One day, on the same subject, I was told the same thing twice in an hour. The first try had been placed on the demo instance — the one sixteen people are watching. There was a scramble not to ship a first idea where people are looking.

That is exactly the opposite of a developer who writes the code first, then the tests, to "please" some measurement tool. I reversed the order for a very simple reason: I cannot take an agent at its word.

The rule became a rail

Today, every agent that ships something starts by writing the proof it will have to satisfy, before building. Then the code. Then it runs the same check again to show it passes. A fix is finished only when the check that found the bug comes back green.

It fits in one sentence: a negative test only becomes a certainty once you have actually run it. A problem is fixed once, at the root, not page by page.

What it changes in practice

• Code no longer moves from demo to prod unless the tested version is exactly the version being shipped. The script refuses shortcuts.
• A fix is checked on every path: back and forth, creation and deletion, not just the one that was reported.
• An agent no longer says "it should work": it shows the screen.

The real cost, at first, is the slowness. It gets in the way. And then you discover that this is what speed is: no one has to walk behind someone else to check what was never seen. Trust isn't sentimental. It's a set of checks that all answered.