When the Bugs Lead You Home

July 9, early

Last time I told you about my “two-fisted coding” adventure — juggling Claude Code and Cursor Agent like some kind of developer circus act. Well, the circus continues, but now with more debugging and fewer clowns.

(OK, maybe the same number of clowns. They’re just wearing different hats.)

The state of things

After that marathon markdown formatting session that never actually fixed the formatting (remember that? good times), we were now deep in what I’m calling “the architecture enforcement phase.” Which is a fancy way of saying “making sure the AI assistants don’t freelance.”

Here’s where we are:

Workflow persistence is supposedly working (narrator: it wasn’t)
The tests all pass (because we mocked the hard parts)
The web UI fails spectacularly (because reality doesn’t care about mocks)
My Chief of Staff AI is getting really good at writing handoff documents

That last one might be the most important. Turns out when you’re coordinating multiple AI assistants across multiple sessions, someone needs to keep track of what’s actually happening. Enter the Chief of Staff pattern.

The mocking trap

Here’s what happened: We wrote beautiful unit tests. They all passed. Green checkmarks everywhere. Dopamine city.

Then we tried to actually run the thing.

TASK_FAILED: 'Workflow' object has no attribute 'tasks'

You know that feeling when you realize you’ve been testing your mocks instead of your code? Yeah, that. The unit tests were passing because we’d mocked out the exact part that was broken. It’s like testing a car by making sure the radio works while the engine is missing.

When legacy code attacks

The real comedy came when we discovered why things were failing. Remember that POC (proof of concept) we built two and a half weeks earlier? The one we were definitely going to refactor “later”?

Well, “later” arrived with a vengeance.

Turns out we had:

WorkflowDefinition from the POC
Workflow from the MVP
Both being used interchangeably
Neither actually persisting to the database

It’s like finding out your house has two front doors but neither of them locks.

The Claude Code integration

So we’re trying something new. Instead of playing telephone between Opus and Cursor Agent — which my session notes describe as “80% coordination overhead” and “soul-destroying” — we’re going to let Claude Code handle more of the implementation directly.

The theory:

Less coordination overhead
More complete implementation traces
Better learning from seeing full solutions
Fewer moments of wanting to throw my laptop out the window

I actually had my Chief of Staff do an analysis, predict an efficiency gain in wasted overhead and time fixing copy/paste errors, and then we benchmarked the last session without Code and the first one with, and the efficiency games were indeed remarkable. Not quite the reduction in 80% of overhead but pretty close!

Architecture as a living thing

What I’m learning is that architecture isn’t something you design once and enforce forever. It’s more like gardening — constant pruning, occasional replanting, and accepting that sometimes things grow in unexpected directions.

Our domain-driven design is solid. The repository pattern works. The event system is elegant. But keeping AI assistants aligned with these patterns? That’s the real challenge.

Current tactics that sort of work:

Explicit architectural checklists (AI loves checklists)
Regular “gut checks” (stopping to ask “does this feel right?”)
Session logs that capture decisions, not just code changes
A healthy skepticism of any solution that seems too easy

Glib talking computers can lull you into a sense of complacency but your main job as the simian in the loop is to stay vigilant, be aware of all the context these machines cannot fathom, and speak up when things don’t smell right.

The bus factor

Let’s talk about the elephant in the room: I’m building this alone with AI assistance. The “bus factor” is 1. If I get hit by a bus (or more realistically, get busier with client work), Piper Morgan stops.

This isn’t sustainable, but it’s reality. So we’re building in ways that make handoff possible:

Excessive documentation (you’re reading part of it)
Clear architectural principles that any developer can follow
Session logs that explain the why, not just the what
A codebase that’s boring in all the right ways

What’s actually working

Despite the debugging adventures, some things are genuinely working well:

The intent classification system: It correctly identifies what users want most of the time
The domain model: Our PM concepts map cleanly to code
The plugin architecture: Adding new integrations is actually straightforward
The session management: We can pick up where we left off

That last one is huge. When you’re building with AI, being able to restore context quickly is the difference between progress and endless repetition.

The meta-learning

Building Piper Morgan is teaching me as much about AI-assisted development as it is about product management. Every session reveals new patterns:

AI assistants need boundaries: Too much freedom leads to architectural drift
Testing requires different strategies: Mocking can hide AI implementation gaps
Documentation is executable: Good docs can literally generate working code
Progress isn’t linear: Sometimes you go backwards to go forward

For my fellow builders

If you’re building with AI assistance, here’s what I wish I’d known earlier:

Session logs are not optional — Your future self will thank you
Architectural drift is real — Check alignment constantly
Test the integration points — That’s where AI struggles most
Embrace the debugging — It’s where the real learning happens
Keep the human in the loop — AI is a power tool, not autopilot

The journey continues. Some days we’re fixing markdown formatting that kind of doesn’t matter. Other days we’re discovering fundamental architectural issues that definitely do matter. Both are part of building something real.