The 5-Minute Day: When TDD Meets AI-Assisted Development
July 17
I had just heard about MCP from my colleague Josh Mills at Kind, and I had asked my Chief Architect (Claude Opus) if Piper ought to be savvy about this new-ish Model Context Protocol thing.
Now I was staring at Claude Code’s week-long implementation plan for MCP integration and thinking, “OK, domain models and content extraction. That’s supposed to be a full day of work, right?”
Five minutes later, it was done.
All of it. Forty-one tests written first, then perfect domain logic with sophisticated content analysis that actually understands what’s in your files, not just what they’re named.
Mind you, it took us ten and a half hours to get to those five minutes. But that’s the thing about building with AI assistance — the preparation work isn’t overhead, it’s compound interest.
The long road to five minutes
Let me back up. The previous day had started at 7:18 AM with what I thought would be straightforward MCP research.
First: Claude Code delivered a comprehensive 40-section technical analysis of the Model Context Protocol. JSON-RPC 2.0, stateful connections, three-layer architecture. The kind of deep dive that makes you realize a “simple integration” is never simple.
Next: A perfect proof-of-concept plan emerges. Enhanced file search — exactly the low-risk, high-value demo we needed. Three-day timeline. Sensible risk mitigation.
Then: Code builds the entire POC in 25 minutes. I mean the entire thing. What we estimated as three days of work, done before I finished my coffee.
But here’s where it gets interesting.
When POCs tell the truth
Code’s architectural review of its own POC was brutally honest:
“Content scoring is FAKE — still just filename matching!”
“Connection management — new connection every search!”
“Config scattered across five files!”
This is why I keep Code around, kind of like having a brutally honest mirror that also happens to be a software architect.
The POC did its job perfectly: It proved MCP could work, identified the real challenges, gave us data for decision-making. But it also revealed the gap between prototype and production.
Classic engineering tradeoff: you can build it fast, or you can build it right. Usually.
Meanwhile, back in PM numbering hell
While Code was revolutionizing our content search architecture, I discovered that PM-013 had three different definitions across my own documentation. Roadmap said “knowledge search improvements.” Backlog said “learning and feedback implementation.” My new MCP epic was also claiming PM-013.
(This is what happens when you’re the PM building a PM assistant — you get to experience your own organizational dysfunction in real time.)
So we took a break from changing the world to fix my basic project management hygiene. Systematic renumbering, conflict resolution, and a proper numbering guide to prevent future chaos. Because if you can’t manage your own PM numbers, maybe don’t build software to help other PMs. Just saying.
The TDD moment
By the end of the day, we had a strategic decision: “Let’s do Option C” — limited 1–2 week implementation instead of the full 3–5 week version. Fix the POC shortcuts, deploy behind a feature flag, get feedback before going all-in.
Smart. Measured. Classic PM discipline.
And then Code delivered the Week 1 implementation plan.
Day 1: Domain models and content extraction using proper Test-Driven Development.
Remember TDD? Write the test first, watch it fail, implement just enough to pass, refactor if needed? The discipline that every developer swears by and half of them skip when deadlines loom?
Well, AI agents don’t have deadline anxiety.
Red, green, refactor (in five minutes)
Red Phase: Code wrote 41 comprehensive tests covering every edge case, every validation rule, every piece of business logic we needed.
ContentExtractor service, ContentMatch value objects, RelevanceScore calculations, SearchQuery handling.
All failing, as they should be.
Green Phase: Implement the domain logic. Smart content analysis that ranks files by how well they match your search (like Google does with web pages), context-aware matching that finds relevant snippets, keyword extraction that ignores filler words like “the” and “and.” Pure business logic with zero external dependencies — meaning it’s bulletproof and testable.
Refactor Phase: Clean up the scoring algorithm, improve partial match handling.
Total time: Five minutes.
Original estimate: One full day.
The compound intelligence effect
But here’s the thing — those five minutes were only possible because of everything that came before. The ten hours of research, architectural analysis, POC building, honest assessment, strategic decision-making, and project management cleanup weren’t overhead. They were foundation.
You know how compound interest works? The early investments seem small, but they create the conditions for exponential growth later. Building with AI assistance works the same way.
The research phase gave us complete protocol understanding. The POC revealed the real challenges. The architectural discipline ensured we were building the right abstractions. The TDD approach meant the implementation was correct by construction.
None of those five minutes would have been possible without the ten hours of preparation. And none of the preparation would have been valuable without the discipline to implement it properly.
The meta-lesson
When I started this MCP integration work — again that’s Model Context Protocol, a new standard for AI systems to talk to external tools — I was thinking about technical challenges like connecting multiple services together, managing complex communication patterns, and handling resource pooling.
What I learned is that the biggest challenge in AI-assisted development isn’t getting the AI to write code fast. It’s getting yourself to think clearly first.
It reminds me of how as human PMs level up in our careers we naturally progress from mastering the basic tasks to making the strategic observations and decisions.
The AI can implement your domain logic in five minutes. But it can’t decide what that domain logic should be. It can write comprehensive tests if you tell it what behavior to test. But it can’t figure out what behavior actually matters.
The human work is still the hard work: understanding the problem, making strategic decisions, ensuring architectural coherence, maintaining quality discipline.
The AI work is the easy work: turning clear intentions into working code.
Search and ye shall find
We now have real content extraction logic with sophisticated relevance scoring, 100% test coverage, and pure domain models ready for integration. The foundation for search that actually understands what’s in your files, not just what they’re named.
Next up: connection pooling, repository integration, and turning those domain models into something users can actually benefit from. Supposedly days 2–5 of the implementation plan.
But I’m not estimating anymore. For one thing, I realize these language bot thingies are making their estimates semantically, using human parameters. Of course they keep crushing those goals!
Still, fast is fast. When you combine proper architectural preparation with TDD discipline and AI implementation speed, estimation becomes less prediction and more… discovery.
Who knows? Maybe Day 2 will also be five minutes.