Shifting Gears: What TDD Taught Me About Using AI Assistants

#ai #programming #webdev #career

If you’ve ever studied the TDD Gears model from TDD Buddy , you’ll know it’s one of the clearest ways to explain how our thinking evolves when practicing Test-Driven Development. Each gear represents a different scale of thought and a level of strictness in applying practices, while the underlying principles remain constant.

In recent months, I’ve found myself drawing a strong parallel between the TDD Gears model and how we use AI assistants such as ChatGPT, GitHub Copilot, or Claude. The way we “shift gears” when coding, designing, or debugging feels remarkably similar to how we move through the gears of TDD. In both, the key is to maintain discipline, reflection, and professionalism regardless of speed.

This article maps the TDD Gears to AI Assistant Gears showing how we can approach AI as a thinking partner, not an autopilot.

Understanding TDD Gears
In TDD, each gear represents both a degree of adherence to core practices and a scale of thought. As we shift gears, we adjust how rigidly we apply certain practices, but the principles of professionalism, maintainability, and quality never change.

Low Gear: Used when we’re unsure of the domain or algorithm. We move slowly, deliberately, and follow every core practice strictly. The goal is to build context and understanding.
Medium Gear: Applied when we’ve gained some familiarity. We begin to refine our design and can short-circuit some rules, mixing core and advanced practices.
High Gear: Reserved for when we’re confident. We work on larger problems or follow existing patterns. We take more risks because we’ve earned that confidence through lower gears.
Reverse Gear: Used when stuck. We back out of the problem, return to a green state, and restart in low gear.

This model teaches us that mastery isn’t about speed, it’s about control. The same applies to using AI.

The AI Assistant Gears Model
AI assistants can dramatically accelerate our work, but only if used thoughtfully. Without structure, it’s easy to fall into the trap of asking AI to “do everything”, skipping understanding entirely. To use AI responsibly and effectively, we can think of our interaction with it as shifting through four gears.

Low Gear: Exploring with AI
When entering a new domain, framework, or problem space, we start in low gear. In this mode, AI acts as a teaching assistant rather than a code generator.

We focus on small, incremental learning:

Ask focused, narrow questions (“What does this error mean?” or “Show a minimal example of configuring HttpClientFactory”).
Validate all answers against official documentation or trusted sources.
Avoid copy-pasting code into production without fully understanding it.
Write tests or small experiments to verify correctness.

In this gear, the goal is to build context and understanding, not to ship code. Just as low gear in TDD helps us form accurate mental models through micro-tests, low gear with AI helps us build accurate mental models through micro-prompts.

Medium Gear: Designing with AI
Once you have a basic understanding of the domain, you can shift into medium gear. This is where AI becomes a design partner rather than just an explainer.

Here, we begin using AI for reasoning about structure and elegance:

Request design alternatives or architecture suggestions.
Ask it to propose test cases, error handling, or interface designs.
Use it to review or refactor code for clarity and maintainability.
Compare trade-offs between technologies or design patterns.

You might allow AI to generate slightly larger pieces of code, but every suggestion still passes through your professional judgment. You review, rewrite, and reason through it as though it came from a junior developer.

In TDD, medium gear is where we build elegance through deliberate design. With AI, medium gear is where we amplify that design through guided collaboration, without surrendering ownership.

High Gear: Scaling with AI
High gear is for those moments when you are fully comfortable with both the domain and your assistant. You understand its strengths, its blind spots, and its limitations. You also have solid guardrails comprehensive tests, static analysis, and peer review.

In high gear, you can use AI to scale your efforts responsibly:
Draft large feature scaffolds or API endpoints.
Generate documentation or consistent code patterns across services.
Automate repetitive refactors using verified patterns.
Combine human judgment with AI speed to tackle broader changes.

You may allow AI to take on more of the work, but your principles remain unchanged. You still review every significant output, validate assumptions, and maintain accountability for quality. As with TDD, the higher gears don’t remove the need for discipline they only expand the scale of what can be safely achieved.

Reverse Gear: Getting Unstuck
Every developer reaches a point where things stop making sense. Prompts yield worse results, refactors become tangled, or code starts breaking in unexpected ways. This is when you shift into reverse.

Reverse gear means backing out safely and regaining clarity.

Use source control. Every AI-driven change should exist in a branch or commit you can easily revert. Source control is your safety net when experimentation fails.
Return to a** known-good green build** and start again from a stable point.
Reduce scope. Create a minimal example that reproduces the problem and focus your AI prompts on that smaller context.
Change your angle of attack ask “What’s the smallest change to fix this test?” instead of “Fix the whole class.”
Use “learning prompts” to explore misunderstood areas (e.g., “Show a minimal working example of this API”).
If the conversation context is polluted, start a fresh session.

TDD has a rule of thumb called red/red/reverse if you’ve made two failed attempts to fix a red test, back out and try again from green. The same rule applies here: after two failed attempts or confusing AI outputs, reverse, clean up, and restart smaller.

The Principles That Never Change
In both TDD and AI-assisted development, the principles are what ensure professionalism:

You remain fully responsible for the code you ship.
Everything important must be tested and verified.
Clarity and maintainability outweigh cleverness.
Accuracy and truth matter more than convenience.
Continuous learning is the real measure of progress.

The practices may evolve with experience, but these core values never change.

Bringing It Together
Here’s how the two models align:

Low Gear TDD Focus: Build context and understanding. AI Assistant Focus: Learn through small, verified prompts.

Medium Gear TDD Focus: Build elegance through design. AI Assistant Focus: Co-design and refactor with critical review.

High Gear TDD Focus: Solve large or integrated problems. AI Assistant Focus: Scale safely with guardrails and validation.

Reverse Gear TDD Focus: Back out and restart smaller. AI Assistant Focus: Use source control, revert, and reset scope.

Both models are about deliberate thinking, not speed. They remind us that professionalism lies not in how fast we produce code, but in how consciously we evolve it.

Final Thought
AI assistants, like TDD, are tools for thinking better, not thinking less. The magic happens when we learn when to slow down, when to shift up, and when to reverse.

The next time you’re working with AI, ask yourself: