I keep my coding assistant on a short leash with a set of TDD rules. With them, I change almost six times as many lines a week, without giving up safety.

I have used Test-Driven Development, TDD, since the early 2000s. It makes me faster and safer. The rules grew out of many sessions developing LogEze together with the assistant, where it 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 of the repository is "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. It is the same product and the 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.

A short leash sounds like it would slow things down. The assistant has to show a failing test before it writes any code, and it has to stop and wait for me at every checkpoint. But the number went up anyway, and I think the reason is that the assistant does all the typing. It is much faster at typing than I am. I pick the next test, confirm every red and approve changes to the plan. The checkpoints only take a few seconds, and they stop the assistant from skipping the red, taking a step too large to review, or running off in the wrong direction.

The speed does not come at the cost of safety. TDD is 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. Working with the assistant hasn't changed that.

How it works

The main rule is that no production code is written 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. It works on one behaviour at a time, so the diff stays small enough to review. The assistant proposes changes and waits for my 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, i.e. your test command, language and conventions. The class names and file paths in the rules are examples, so replace them with your own. Remove the rules that don't fit your project and add the ones it needs.

A non-deterministic process

The leash does not make the assistant perfect. The assistant is a non-deterministic process. The same input does not always give the same output, and the rules can only make the right behaviour more likely. As an example, around Friday 2026-10-16 it named the asserted value something other than actual and dropped the blank lines between arrange, act and assert. These are small things and I caught them because the rules say what a test must look like, but it shows that the rules are not always followed. 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.

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 them without understanding them will not move you forward. Neither will letting an assistant run loose. It will build something close to what you asked for, and that is seldom exactly what you need.

Conclusion

Keeping a coding assistant on a short leash doesn't have to make you slower. My lines per week went from 2265 to 12920 while the assistant followed strict TDD rules. The rules in the repository are meant as inspiration, an idea to build your own rules upon. Take what makes sense in your project and leave the rest.

Resources