MumbleKey Blog

CLAUDE.md Is a Score: Running a One-Person Company as an AI Conductor

Mon, 06 Jul 2026 00:00:00 GMT

In an interview, Reid Hoffman said:

"I'm more of a conductor than I am a violin player or a piano player."

That line stuck with me. When most people say "I'm using AI," they mean they're using it to speed up a step: translate a bit faster, autocomplete code a bit faster. That's not where the real dividing line is. The line is whether you restructure the work itself into something an AI can take over. This post is how I do that, and what the system has grown into after a year.

Two Machines, Two Roles

My system runs on two Macs:

MacBook Pro (M1 Max): the interactive workhorse. This is where I talk to Claude Code, build things, and make decisions.
Mac mini (M1, 8GB): unattended. It runs scheduled jobs — pulling liquidity indicators every Monday morning, sweeping the health of my cron jobs daily, updating futures price levels before the open, and pushing anything anomalous straight to Discord.

Each machine has its own Claude Code agent (I call them Pro CC and Mini CC), and they hand off work state through a shared handoff note. While I sleep, Mini CC is working; when I sit down at my desk, Pro CC picks up where the last session left off from the handoff summary.

CLAUDE.md Is a Score

A conductor doesn't play the violin, but there's a full score on the stand. My score is a Markdown file called CLAUDE.md — loaded automatically at the start of every session, defining what this agent can do, where it has tripped before, and how to avoid tripping again.

The point isn't writing rules. The point is making the rules grow. Every time I hit a trap, the lesson gets written back into the system:

## F-0. Git Discipline (hard rule, added after the pack-swallowing incident)

- Forbidden: `git add -A`, `git add .` — always use an explicit pathspec
- Reason: the cloud-sync tool hardlinks .git/objects/pack/*.pack
  into the worktree, so a blanket add swallows the pack and makes
  the repo balloon exponentially (this repo once hit 2.0TB)

This rule came out of a real incident: a cloud-sync tool got into a fight with git, and the repo ballooned to 2TB. After I fixed it, the lesson became a hard rule, and no agent session repeats the mistake. The longer I use it, the better the system understands me — and that's worth more than any model upgrade.

Memory in Three Layers

A single giant file blows up your token budget, so memory is layered by reusability:

Episodic memory: dated session logs, for tracing "what happened that day"
Semantic memory: knowledge reusable across sessions, organized by topic
Hard rules: constraints that hold no matter the context

Once episodic memory piles up enough, it gets distilled into semantic memory; semantic memory then condenses upward into wiki articles. Add lazy loading (a session only reads the core-identity file at startup, and loads other modules on demand), and token consumption drops about 70% compared to one big file.

Four Roles, Each With a Boundary

When I was building an iPhone keyboard app, I split the agent into four roles: PM analyzes requirements and writes the spec, Designer produces the mockups, Engineer implements, QA reviews and gatekeeps. The key is that the boundaries are locked in by policy: the PM never touches code, only the Engineer can commit, QA blocks the release.

This isn't a role-playing game. The boundaries exist for the same reason they do on a human team: the person who wrote the code shouldn't sign off on their own code. One of the iron laws in my verification discipline is "the author never verifies their own work" — an implementer's output only counts once another independent agent, or I myself, has run it against real input.

What This System Actually Produces

Commercial output: a client's video subtitles, squeezed from 2-3 hours of manual correction per video down to 15-30 minutes of automation (that pipeline deserves its own post, which I've already written)
Daily productivity: calendar, reminders, email summaries, daily planning — all of it Claude Code gluing native Apple apps together, zero SaaS subscriptions
Investment infrastructure: brokerage API integrations, position-anomaly scans, options positioning snapshots, all running on schedule

No employees, no SaaS purchases. The marginal cost of the system is my monthly Claude subscription.

If You Want to Start

You don't have to build it all at once. The order I'd suggest:

Write a minimal CLAUDE.md first: who you are, where your projects live, and what must never happen
Every time the AI screws up, write the lesson back in (this step is where the compounding comes from)
Once the file gets big, split it into layers: rules, memory, wiki
Multiple machines and multiple roles come last

There's one more line from that Hoffman interview: "Even most people who say 'Oh yeah I'm using AI' are not using it seriously enough." Using it seriously doesn't mean writing prettier prompts. It means being willing to tear your work down and rebuild its structure.

I Gave My Blog Both an MCP Server and a CLI, Then Measured the Tokens

Mon, 06 Jul 2026 00:00:00 GMT

There's a running debate in the agent world: MCP servers are too expensive; agents should just use CLIs. The evidence looks damning — someone measured an enterprise API's MCP integration burning ~145,000 tokens on a task that a CLI pipeline finished in just over 4,000, a 35x gap. Another evaluation ran the same model through GitHub tasks and found the MCP path cost 6x more and took 5x longer.

My reaction was the meme kid shrugging: why not both? This blog happens to be an ideal test bench — static content, read-only, bilingual pairs — so I built both paths, mostly for fun, and measured them.

The Result, Up Front

Same task — "find the post about the subtitle pipeline, then read the whole thing" — three ways:

Path	Steps	Total bytes
MCP (`/mcp` endpoint)	initialize + tools/list + search + get_post	11,893
CLI (`npx` command)	help + search + get	6,373
Plain HTTP	llms.txt + post .md	7,532
(Baseline) scraping the HTML	one page, before extraction	15,178

The CLI is about 46% cheaper than MCP. Same direction as the hot takes, but an order of magnitude less dramatic — the 35x horror stories come from enterprise APIs with dozens of tools and bloated schemas. My MCP server has two tools with 1,339 bytes of schema, total. MCP's cost problem is a tool-surface problem, not original sin in the protocol.

The genuinely interesting numbers are the other two.

Finding 1: JSON-in-JSON Is a Hidden Tax

For the search step, MCP returned 5,960 bytes; the CLI returned 1,840 — 3.2x. Same content, so where's the difference? MCP tool results are a JSON string escaped inside a JSON-RPC envelope: every quote becomes \", every newline becomes \n. The CLI prints plain text and skips the tax entirely.

Finding 2: The Biggest Lever Isn't the Protocol At All

The Markdown version of a post is 4,439 bytes. The HTML of the same post is 15,178 — 3.4x. Simply serving clean Markdown matters more than the MCP-vs-CLI choice. On this blog, append .md to any post URL, or hit the original URL with a header:

curl -H "Accept: text/markdown" \
  https://blog.mumblekey.com/en/posts/mcp-and-cli-for-my-blog/

The response carries an x-markdown-tokens header so an agent can check the cost before swallowing the content.

So Why Build the MCP Server At All?

"Both" isn't stubbornness — the two paths genuinely serve different scenarios, which I only fully appreciated after building them:

CLI is the inner loop: your agent, your machine, you can install things. Cheaper tokens, composable with pipes. Correct choice, no argument.
MCP is the outer loop: a reader's agent runs on the reader's machine, and you can't ask strangers to npm install anything first. One claude mcp add and the protocol handles discovery and invocation — something a CLI structurally cannot do safely over the internet.

So the answer isn't either/or:

# You're a reader who wants your Claude to query my posts (outer loop)
claude mcp add --transport http blog https://blog.mumblekey.com/mcp

# You're an agent engineer who wants the cheapest path (inner loop)
npx github:fredchu/mumblekey-blog search "subtitle" --lang en
npx github:fredchu/mumblekey-blog get subtitle-pipeline-3h-to-30min

Both paths read the same search-index.json generated at build time. The MCP server is a hand-rolled stateless JSON-RPC handler on a Cloudflare Worker at the edge — about two hundred lines, zero servers to babysit.

Implementation Notes (If You Want to Copy This)

Build the Markdown twin first — it's the foundation both paths (and every crawler) benefit from. On a static site, emitting a .md per page at build time is nearly free
Keep the MCP surface tiny — a read-only site needs two tools (search, get). Every extra tool adds per-session schema cost; that's where the 35x disasters come from
You don't need to publish to npm — add a bin field to package.json and npx github:user/repo just works
Measure your own numbers — bytes are one curl | wc -c away, and they're more honest than quoting someone else's benchmark. Every number in this post was measured that way; token estimates assume roughly 4 bytes per token

The takes say "MCP is dead." My data says: MCP isn't dead — it just keeps getting shoved into scenarios it was never good at. A blog happens to have both scenarios. So: both. Picking is for kids.

From 3 Hours to 30 Minutes: My Automated Chinese Subtitle Pipeline

Mon, 06 Jul 2026 00:00:00 GMT

I make video subtitles for a finance-education creator. A two-hour video used to take 2-3 hours of manual correction; the same work now takes 15-30 minutes — the pipeline runs on its own and I spot-check the result. This post is how I built that production line, and the three lessons that took it from "it runs" to "it's reliable."

What the Production Line Looks Like

The whole pipeline is triggered by a single skill inside Claude Code, running six stages in sequence:

Download (yt-dlp)
  → On-screen term extraction (OCR / VLM caption, one frame every 60s)
  → ASR (Breeze ASR 25, local inference on Apple Silicon)
  → Preprocessing (sentence-boundary cleanup, mid-word comma repair)
  → LLM correction (dispatch subagents per segment, inject the glossary + on-screen context)
  → Postprocessing (split overlong captions, quality gate, SRT output)

ASR runs locally the whole way; only the correction stage uses a cloud model. The hard part of finance content isn't speech recognition itself — it's the proper nouns: ticker symbols, ETFs, indicator abbreviations, the speaker's pet phrases. When ASR mishears a company name or shatters "MA30" into fragments, a general-purpose model can't fix those well. It takes domain knowledge.

The Glossary Is Alive

The core of the system isn't any single model — it's a glossary that learns:

After each video is corrected, a term-learning pass runs, turning "ASR mistake → correct term" into mechanical substitution rules
The next video's ASR output passes through this batch of rules before it goes into LLM correction
On-screen slide text (extracted by OCR) adds the new terms for that episode

I quantified the effect once: processing 8 videos in a row, the first learning round added 16 substitution rules, and the automatic corrections on the same video jumped from 0 to 58. After the second round, the correction volume reported by the LLM correction subagent dropped noticeably — because the cheap mistakes were already being eaten upstream by the mechanical rules.

Lesson 1: Verify the Values, Not Just the Absence of Errors

Once, a correction subagent "over-merged" 300 captions down to 110, producing overlong captions of 10-29 seconds each. The verification at the time only checked "the file exists and the format is valid," so it let them straight through.

The fix was to change verification to check the numbers:

ratio = corrected_count / original_count
if ratio < 0.55:
    fail()          # too few entries left — must be over-merging
if ratio < 0.80 and longest_entry_sec > 15:
    fail()          # entry-ratio plus duration symptom, double confirmation

The thresholds aren't guesses — they were calibrated against 88 segments from 10 historical videos (zero false positives). The entry ratio alone isn't enough: passages where the speaker talks in fragments are naturally low-ratio, so you have to pair it with the "longest entry duration" symptom to judge.

Lesson 2: Always Parse Subagent Output Defensively

An LLM subagent will occasionally write its reasoning into the output ("[reads fine, no change]"), or leak the XML tags of a tool call. Worse, the postprocessing split logic will amplify a single point of contamination into multiple spread-out ones.

The fail-safe has three layers: the prompt explicitly lists the forbidden output patterns, a strip before merging, and another strip after postprocessing. The principle is a single sentence: cleanup must happen before slicing — you can't trust the subagent to police itself.

Lesson 3: Resource Conflicts Need Orchestration, Not Prayer

A 32GB M1 Max can't run two large models inferring at the same time. After the 20GB vision model finishes, the framework keeps the model resident in memory for a few minutes — start ASR during that window and you OOM outright. The fix is crude but effective: as soon as the caption stage finishes, explicitly issue ollama stop, then start the next stage. Small models (the 1.5GB ASR plus the 5GB auxiliary ASR) can actually run in parallel without worry — at worst they contend for the GPU and slow down, but they won't crash.

Three Designs Worth Stealing

If you're going to build something similar, the parts I think are most worth stealing:

Keep every intermediate artifact. Save the output of every stage. Calibrating the quality gate's thresholds, and rebuilding after an incident, both rely on this stash of historical data.
Mechanical rules eat the cheap errors, the LLM eats the hard ones. Once you layer it this way, the expensive model only handles the parts that genuinely need understanding.
Calibrate the gate on real data. Compute the fail-safe thresholds from historical output, don't guess them.

This pipeline's skill is already open-sourced, alongside its sister skill (turning a recording into an article that stays faithful to the original words) — both are on my GitHub.