Skip to content
BSWEN
Blog

How to Enforce TDD and Code Quality with AI Coding Assistants

Cowrie
Cowrie
Dev @ Bswen

Problem

When I use AI coding assistants, they generate code quickly—but often without tests. The same AI that wrote the code also reviews it. This creates a problem: there’s no external enforcement mechanism.

I asked myself: how do I ensure AI-generated code follows test-driven development (TDD) and passes quality checks before I accept it?

What Happened

I noticed a pattern when working with AI assistants:

Typical AI workflow
Me: "Add a login feature"
AI: Writes code
AI: "Done! Here's the implementation."
Me: "Did you write tests?"
AI: "Oh, I can add those now..."

The AI skipped the TDD cycle entirely. It wrote implementation first, then tests as an afterthought. This defeats the purpose of TDD.

The core issues I found:

  1. No test-first enforcement – AI generates code, then “remembers” to add tests
  2. Self-review bias – The same AI that wrote code reviews it (and is biased toward accepting it)
  3. Mixed quality concerns – Trying to check both “did we build the right thing?” and “did we build it well?” at the same time

How to Solve It

I discovered that the solution requires structural mechanisms built into the workflow itself—not just better prompts.

Solution #1: Build TDD Into Every Plan Step

Instead of hoping the AI follows TDD, make test steps explicit in every task:

TDD steps embedded in plan
Every task includes these checkboxes:


- [ ] Step 1: Write failing test
- [ ] Step 2: Run test, confirm failure (RED)
- [ ] Step 3: Write minimal implementation code
- [ ] Step 4: Run test, confirm pass (GREEN)
- [ ] Step 5: Refactor if needed (REFACTOR)
- [ ] Step 6: Commit

This is how the Superpowers framework handles it. During planning, every step already includes test code. The AI implementer can’t skip tests because the plan explicitly requires them.

Solution #2: Use Independent Reviewers

The key insight: don’t let the same AI that wrote the code review it.

Multi-agent review flow
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  Implementer    │ ──→ │  Spec Reviewer  │ ──→ │ Quality Reviewer│
│  (Agent A)      │     │  (Agent B)      │     │  (Agent C)      │
└─────────────────┘     └─────────────────┘     └─────────────────┘
        │                       │                       │
   Writes code            Fresh context            Another fresh
   with tests             No "I wrote this"       context
                         bias                    Focuses on quality

Each reviewer gets an isolated context. The Spec Reviewer doesn’t know “I wrote this code” because it didn’t write it. This eliminates self-review bias.

Solution #3: Two-Phase Review

I realized that reviewing correctness and quality at the same time is confusing. Split them into two phases:

Two-phase review architecture
Phase 1: Spec Reviewer (Correctness)
Question: "Did we build the right thing?"
Checks:
  - Requirement coverage: Are all requirements implemented?
  - Scenario completeness: Are edge cases handled?
  - Scope adherence: Is there over-engineering?
Output: ✅ Pass / ❌ Fail with specific issues
Gate: Phase 2 cannot start until Phase 1 passes


Phase 2: Code Quality Reviewer (Quality)
Question: "Did we build it well?"
Checks:
  - Code quality: Readability, maintainability
  - Architecture: Patterns, separation of concerns
  - Security: Vulnerabilities, secrets handling
  - Tests: Coverage, edge cases, assertions
Output: Critical / Important / Minor severity ratings

Why separate phases? Reviewing code quality of wrong implementation is meaningless. Fix correctness first, then worry about quality.

The Reason

I think the key reason AI assistants skip TDD is structural, not intentional:

  1. Default workflow has no checkpoints – AI generates, then moves on
  2. Single agent = self-review bias – The AI “trusts” its own output
  3. Mixed concerns create confusion – Trying to review everything at once

By building TDD into the plan and using independent reviewers, we create external enforcement. The workflow itself becomes the quality gate.

Summary

In this post, I showed how to enforce TDD with AI coding assistants. The key points are:

  • Build test steps into every plan task (write test → confirm failure → implement → confirm pass)
  • Use independent reviewers with isolated contexts to eliminate self-review bias
  • Split review into two phases: correctness first, then quality
  • Only move to quality review after correctness passes

The Superpowers framework demonstrates this approach works. By making TDD structural rather than optional, AI-generated code accumulates less technical debt and catches bugs earlier.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: