Field Notes from a Solo Builder — Shipping the Beloved Claude Code Buddy Into the Wild - Part II

#claudecode #mcp #architecture #ai

The alpha was out. But I wasn't satisfied with the architecture.

The original Buddy had a fundamental fragility: tightly coupled to Claude Code. Every version upgrade could wipe it. And if you weren't running Claude Code specifically, you were excluded entirely. I didn't want to rebuild the same fragility.

The First Principle: No CLI Dependency

The core architectural decision was simple to state: Buddy must work with any CLI. Not just Claude Code. Whether you're running Gemini CLI, GitHub Copilot CLI, or something that doesn't exist yet — the feature should be available to you.

That constraint pointed directly to MCP — the Model Context Protocol. By implementing Buddy as an MCP server, we could decouple the personality layer from any specific CLI's version cycle and make it compatible with any harness that supports the protocol.

🏗️ Architecture Decision
"If it only works with Claude Code today, it dies the next time Claude Code updates. We needed a layer that could outlive any single CLI."

What We Learned About CLI Hooks

This is where reality checked us. Not all CLIs are built the same.

Claude Code has hooks. GitHub Copilot has hooks. Codex CLI has hooks. Cursor has hooks. But beyond those, support gets sparse fast. And the ability to customize the status line — that small but satisfying UI touch that shows Buddy's mood and level — is something only Claude Code cleanly exposes right now.

For Codex, we couldn't do it through normal means; it required patching the binary on an experimental branch, which directly violated our first principle of no hard harness dependency. That's an honest limitation we're sitting with as the ecosystem catches up.

The Token Tax Question

The second major design decision: do we pass the full diff to the model, or a summary?

Full diff means richer, more specific feedback. But our users are running Buddy on top of their own API subscriptions. They're paying for every token. I went with the summary approach — and when we launched on Friday and someone immediately posted on Reddit asking exactly how much overhead this adds per interaction, I knew we'd made the right call.

💡 Lesson Learned
"Build for your user's constraints, not your ideal conditions. Our users are paying their own token bills. Every unnecessary token is friction."

Three Modes, One Default

We shipped with three interaction modes:

Mode	What it does
Skill Coach	Code review feedback delivered in character
In-Character	Personality only, no review
Hybrid (default)	Both — full experience out of the box

Default is hybrid. Give users the full experience, let them dial back if needed.

My Build Workflow

For anyone curious how I actually built this, here's the process I follow:

Regular features → plan mode in Claude Code
Complex features → have Codex review the plan first
Complex implementations → have Codex review after building
Always → /simplify before committing
Big strategic decisions → gstack /office-hours for a long design conversation before touching code

Stack used:

Claude Code (plan mode + implementation)
MCP (Model Context Protocol)
One-line npm install
Summary-based code review (not full diff)
Codex for complex plan review
gstack /office-hours for architecture decisions

Next up → By Friday we had stars, a Reddit thread, and organic Google pickup. But a comparison table in the README almost caused a community problem — and what fixing it taught me about open source.

This is part 2 of the "Shipping Buddy Into the Wild" series about how we shipped https://github.com/fiorastudio/buddy v1 release in one week.