I have used Test-Driven Development, TDD, since the early 2000s. It makes me faster and safer.

While developing LogEze together with a coding assistant I have a set of rules I expect the assistant to follow. They keep it on a short leash. The rules are not theory. They are what remained after many sessions where the assistant didn't follow the TDD process good enough in my opinion. I have published a snapshot of them at github.com/tsundberg/red-green-leash, so this post can explain the rules and send you there for the files to copy and adapt.

The tagline says most of it: "No green without red. No step without a human."

The assistant has made me faster, and I can measure it. I count the lines of code I touch per week, dug out of my own changes in git, so I can see exactly what I did. During 2025 I averaged 2265 lines a week. During 2026, with the assistant, 12920 lines a week. Same product, same kind of work. That is almost six times as much. Lines touched means all changes, added and deleted alike, so the refactor step in every cycle counts too.

Graph of lines of code changed per week in LogEze during 2025 and 2026

I started using the assistant in week 6 of 2026. That is where the graph jumps. The weeks with zero changes are weeks when I was on holiday, week 7 of 2026 for example.

You would think a short leash slows everything down. The leash makes the assistant show a failing test before it writes any code, and it has to stop and wait for me at every checkpoint. And yet the number went up.

The answer is who does the typing. The assistant writes all the code, and it writes it fast. I steer. I pick the next test, I confirm every red, and I approve every change to the plan. The leash only slows the assistant where running ahead would cost more than it saves, like skipping the red or taking a step too large to review. Those checkpoints cost seconds. A wrong direction taken at full speed would be more expensive.

The speed does not come at the cost of safety. TDD is all about safety and exploration: the test comes first, and I read it and question it before any code exists. The exploration comes from revising the test list after each cycle, with what the cycle taught us. The leash keeps that part intact. The assistant types fast, but I still read and question every test.

How it works

It's simple. No production code without a failing test that demands it. The assistant writes one test, runs it, and shows that it fails for the expected reason. Only then does it write the code. One test, one behaviour, one change at a time, so the diff stays small enough to review. And I stay in the loop. The assistant proposes, I decide, and it waits for approval at the checkpoints instead of carrying on.

A session runs in cycles. We write the test list, it proposes the next test, we go red, I confirm the failure, it goes green, we refactor, we revise the list with what the cycle taught us, and then we start over with the next test on the list.

The files

The repository contains the rule files I actually use: CLAUDE.md for Claude Code, AGENTS.md for Mistral Vibe and other agents that read it, and a rules/ directory with one file per topic. Copy them to your project and adapt them to your stack: test command, language, conventions. The class names and file paths in the rules are examples, so replace them with your own. The rules are a starting point, not a standard. Remove what does not fit, sharpen what does, and add the rules your own project needs.

A non-deterministic process

The leash does not make the assistant perfect, and it cannot. The assistant is a non-deterministic process: the same input does not always give the same output, and the rules only nudge the probabilities. As an example, around Friday 2026-10-16 it slipped: it named the asserted value something other than actual and dropped the blank lines between arrange, act and assert. Small things, caught because the rules say what a test must look like, but a real slip. When the assistant jumps ahead I pull the leash and we redo the step. My name is on the commits, and the responsibility for a working product is mine, so the human stays in the loop.

The assistant is very pedantic, following the rules to the letter. Shortcuts I might have taken before are simply not taken anymore. That is the leash doing its job, but it is irritating at times.

This post is about the rules and the speed. If you copy the rules, see them as inspiration and adapt them as needed. They work for us, but they are not another silver bullet. Copying without understanding will not move you forward, the same way letting an assistant run loose will build what you almost managed to specify instead of what you need.

Conclusion

The leash slows the assistant down only where running ahead costs more than it saves, and lets it type at full speed everywhere else. I steer, the assistant types, and my lines per week went from 2265 to 12920. The rules are in the repository, as inspiration for your own.

Resources