September 19
I had dreams about the project last night.
Not the usual anxiety dreams where code refuses to compile or demos crash in front of stakeholders. These were deep processing dreams — my brain working through architectural patterns while I slept, making connections I couldn’t quite see during the day.
I woke up Friday morning with a clear view of the patterns: we were drowning in unfinished refactors.
The solo developer problem
When you’re working with a team, gradual refactors make perfect sense. You start a migration, other people pick it up, natural handoffs happen during code reviews and sprint planning. The work gets finished because there are multiple brains tracking the incomplete pieces.
But I’m a solo developer with AI assistance. There’s no one else to remember that we’re halfway through converting the query routing system or that the orchestration engine initialization got commented out “temporarily” four weeks ago.
Multi-week gradual refactors are a recipe for exactly the kind of architectural drift that led to Thursday’s investigation revealing a system held together by sophisticated workarounds.
The answer isn’t better tracking or more discipline. It’s a completely different approach: inchworm style execution.
The inchworm protocol
An inchworm doesn’t try to stretch across the entire leaf. It plants its front end, pulls its back end forward, then repeats. Each movement is complete before the next one starts.
“We can just hunker down like good inchworms and systematically fix/refactor/or finish one system at a time, refusing to move on until it works for some core set of user stories.”
This has become my new governing principle: Cannot begin the next epic until the current one is 100% complete, tested, and documented. No exceptions.
Not 90% complete with “just a few edge cases to clean up later.” Not “basically working but needs some polish.” One hundred percent complete.
For a solo developer, this isn’t rigidity — it’s sanity preservation.
The mood transformation
Between cognitive overload, unrelated life stress, the whole (gestures vaguely…), and lack of sleep, I seriously considered throwing in the towel the day before.
Just Thursday night I was wondering if this whole project was getting away from me and proving literally impossible. Was it the “Rocket to Mars” antipattern striking again, leading me on and endless wild goose chase?
Too many moving pieces, too much accumulated complexity, too many partial solutions that never quite connected.
But Friday morning I woke up feeling confident that if I just stopped starting new things and got back to finishing existing work, there was a clear path forward.
Now all I needed was a deep huddle with the Chief Architect session to turned fifteen scattered issues into seven (notional) weeks of clear, sequential work.
The archaeological inventory
The first step was admitting we didn’t actually know what needed to be finished. Thursday’s investigation had revealed some issues, but how much other unfinished business was lurking in the codebase?
Time for comprehensive archaeology. The Chief Architect and I spent the morning creating an inventory of every incomplete refactor, every TODO comment with actual implications, every “temporarily disabled” feature that had become permanent technical debt.
Fifteen major items emerged, naturally clustering into three categories:
Core Architecture Restoration (5 items):
- QueryRouter/OrchestrationEngine restoration (75% complete — just needs proper reconnection)
- Plugin architecture extraction (existing integrations just need standardized interfaces)
- Intent classification universal (no more bypasses — everything goes through the same pipeline)
- Domain model separation (pragmatic enforcement of existing boundaries)
- GitHub service integration (consolidate into single orchestrated pattern)
Integration Pattern Consolidation (5 items): Standardizing how external services connect to the system, from MCP protocols to spatial intelligence integration.
Configuration and Validation (5 items): Cross-validation systems, documentation link repair, and the systematic gaps that accumulate when you’re moving fast.
The revelation? Most of this work was already 50–80% complete. We weren’t facing fifteen new projects — we were facing fifteen finishing jobs.
“Create GitHub issue”: Story number one
“It was the first one we made, even in the POC. Our system has to work for this first story! That’s table stakes.”
This became our litmus test. Before any epic could be considered complete, it had to support the most basic user story: a product manager asking Piper Morgan to create a GitHub issue.
End-to-end. From conversational interface through intent classification, orchestration engine, workflow creation, GitHub API integration, and back to user confirmation.
If that flow works reliably, everything else becomes an extension rather than a fundamental question.
It was a weird callback to that moment when I realized the prototype was a dead-end precisely because it was so fully centered on being a GitHub machine. But this was different. This is the full Piper Morgan vision, the domain models, the nuance, and being able to make a dang GitHub ticket.
The interface hierarchy insight
One of the breakthrough moments came when we mapped out how all the different interfaces should relate to each other.
- CLI commands should mirror Slack slash commands.
- Conversational behavior shouldstays consistent whether you’re in the Web UI or Slack.
- Shared vernacular across all interfaces.
- All interfaces are siblings that converge at the intent layer.
This wasn’t just an architectural decision — it was a complexity management strategy. Instead of building four different systems that happen to share some backend services, we were building one intent processing system with four different front doors.
Suddenly the scope felt manageable instead of exponential.
The configuration clarity
Another source of ongoing confusion got resolved through simple naming clarity:
- PIPER.md: Configuration for Piper Morgan itself
- CLAUDE.md: Instructions for the human assistants (that’s me and the AI agents)
This had always been the idea but at some point my architect thought PIPER.md was for our agents. (It’s not: It’s Piper’s basic instruction set and the basis for any customer configurations or system prompts to be layered above it.)
The Chief Architect gets instructions through the Claude.ai project knowledge. Claude Code reads from the CLAUDE.code file in the project root. Cursor Agent uses .cursor/rules/ configuration.
Each tool gets briefed appropriately for its context and capabilities. No more confusion about who needs what information when.
Seven weeks of clear work
By afternoon, we had transformed “this feels impossible” into a concrete execution plan with realistic timeframes. We make a new set of epics in our CORE track:
GREAT-1: QueryRouter/OrchestrationEngine restoration
GREAT-2: Plugin architecture standardization
GREAT-3: Intent classification universal
GREAT-4: Domain boundaries enforcement
GREAT-5: Integration pattern consolidation
GREAT-6: Configuration and validation
GREAT-7: Documentation and polish
Each epic governed by inchworm protocol. Each one bringing the “create GitHub issue” story closer to bulletproof reliability.
The beauty of this approach? I don’t have to hold all fifteen problems in my head simultaneously. I just have to focus on completing the current epic properly before moving to the next one.
From anxiety to confidence
The session ended with something I hadn’t felt in weeks: confidence that the project was not only feasible but systematically achievable.
“Thank you for a refreshing and calming planning session. My dream of Piper Morgan lives on!”
(Yes, I’m polite and appreciative like that the conversational processes that assist me, elaborate on my ideas, and do my bidding.)
The technical debt hadn’t disappeared. The architectural challenges were still real. But having a clear, sequential plan transformed overwhelming complexity into manageable work.
This is why planning sessions matter. Not because they eliminate problems, but because they transform chaotic anxiety into systematic progress.
The meta-lesson
The real insight wasn’t about Piper Morgan’s architecture — it was about solo developer workflow optimization.
Traditional software development practices assume team contexts: code reviews, sprint planning, natural handoffs between specialists. When you’re working solo with AI assistance, you need different patterns.
Inchworm protocol isn’t just about technical discipline. It’s about cognitive load management. It’s about preventing the kind of architectural drift that accumulates when no one person is responsible for remembering every incomplete piece.
It’s about building systems that support the way solo developers actually work instead of forcing solo developers to work like teams of twenty.
Next on the journey
Monday morning starts GREAT-1: QueryRouter/OrchestrationEngine restoration. The 75% complete work that got derailed by Thursday’s implementation attempt.
But this time we’re approaching it systematically. Full archaeological understanding before any implementation. Clear success criteria before starting. Inchworm protocol governing the work.
The goal isn’t just to fix the orchestration engine. The goal is to prove that systematic, sequential execution can reliably transform incomplete work into solid foundation.
One epic at a time. One hundred percent complete before moving on.
The Great Refactor begins.