Schema, Refactor, Feature: Code's Holy Trinity

Every code change falls into one of three categories:

1. Schema/Interface Changes
2. Refactoring
3. Feature Changes

Don't believe me? Here is an example:

• Bug fix? That's a Feature Change (we're modifying behavior to match intended functionality)
• Performance optimization? That's Refactoring (same behavior, different implementation)
• Adding validation? That's Schema/Interface Change (modifying the contract)

TDD Isn't Just Another Methodology

This is why Test Driven Development (TDD) isn't just another programming methodology - it's the foundation of reliable software development, especially as AI code generation becomes mainstream. Think about it: when you're using AI to generate code, you need a systematic way to verify it does exactly what you want, no more and no less. You can't just eyeball the code and hope it works. Each of those three types of changes requires its own specific testing approach, and TDD gives you the framework to handle them all.

The Real Bottleneck Isn't Code Writing

The pushback I usually hear is that TDD is too tedious or time-consuming, especially for "small" changes. But here's the reality: with AI accelerating the actual code writing, the bottleneck isn't typing out implementation anymore - it's ensuring correctness. By writing tests first, you're not just checking your code works, you're creating a precise specification of what you want your AI to generate. This isn't just about catching bugs - it's about steering the AI to write exactly the code you need. The result? Software that's not just built faster, but is actually maintainable and reliable in the long run.