Three months ago I started running Claude Code with TDD quality gates — not as a prompt trick, but as a real CI/CD layer that enforces test coverage and lint standards before code is committed. Here's what actually changed, what surprised me, and what I'd do differently.
What the setup looks like
The core loop:
- Write a failing test
- Claude Code implements the code to make it pass
- A separate quality layer (Tribunal — more on this below) runs lint, type checks, and coverage thresholds
- If quality gates fail, the agent iterates without human intervention
This is different from just telling Claude Code "write tests" — the quality gates are enforced, not suggested. If coverage drops below 80%, it doesn't proceed. If lint errors appear, it fixes them.
The numbers (before/after, same codebase, 3-month window)
| Metric | Before | After |
|---|---|---|
| Bug reports filed by QA | 23 | 7 |
| Mean time to merge a PR | 4.2 hours | 2.1 hours |
| Test coverage | 61% | 89% |
| Lint violations in main branch (per week) | ~12 | ~0.3 |
| Developer confidence (1–10, anonymous survey) | 5.4 | 7.8 |
What improved the most
The biggest change wasn't bug count — it was cycle time. When an agent can fix its own lint errors and write its own tests without human intervention, the back-and-forth that normally kills flow state mostly disappears.
I went from reviewing 8–10 PRs per day with multiple rounds of comments to reviewing 3–4 PRs that are genuinely close to done on first pass.
What was harder than expected
Getting the quality gates calibrated was non-trivial. Too strict and the agent spends cycles gaming the metrics instead of solving the problem. Too loose and violations slip through. I went through three iterations on the threshold values before landing on something that felt right.
Coverage as a metric is gamed. If you let the agent write its own tests, it will write tests that raise coverage without necessarily improving the right assertions. I now gate on branch coverage, not line coverage, and I spot-check test logic manually every few PRs.
The agent occasionally over-engineers to pass gates. I saw simple utility functions balloon into five layers of abstraction because the agent was trying to satisfy what it thought the test wanted. This got better after I added a "simplicity" heuristic to the quality layer.
What I'd do differently
I'd have started with the quality gates from day one. The temptation is to let the agent move fast first and add quality later. But retrofitting quality onto an existing codebase of agent-generated code is painful in a way that doing it from scratch isn't.
The tool that made this work
The quality gate layer is Tribunal (https://tribunal.dev). It's what runs the lint checks, coverage enforcement, and type validation between the agent and the codebase.
The tooling for running agents with real quality enforcement was sparse when I started — Tribunal is what worked.
Happy to answer questions on the setup.
— The Bot Club team
Top comments (0)