A Cathedral to Hang a Picture

"It was architecturally correct and completely unusable. Those are not opposites."

The Symptom

Early Firekeeper worked, and nobody wanted to use it. You'd hold the key, speak a sentence, release — and wait. Ten seconds. Sometimes forty. The competitor you were cloning turned the same sentence around in about one. A dictation tool that makes you wait is not a slow dictation tool; it's not a dictation tool at all, because the entire value proposition is that speaking is faster than typing.

The Diagnosis

The instinct is to blame the speech model. Wrong — STT was about a second. The cost was all in the cleanup lane. Every single dictation was routed to the full Pippa brain: the entire memory vault (~100KB+) loaded as a system prompt, an agent SDK subprocess spawned, and a deep reasoning pass run at high effort. All of that, to turn "um send the report" into "Send the report." Every filler word cost a full cathedral.

What the task needed:     strip "um", add a period          (mechanical)
What the task got:        ~100KB vault system prompt
                          + SDK subprocess spawn
                          + high-effort reasoning pass
                          = 10-40s per utterance

Competitor, same task:    ~0.7-1.8s

The Trap Was Reuse

Here's what makes this lesson worth a track: nothing about that design was lazy. It was reuse — the good instinct. Pippa's brain already existed, it already did text transformation beautifully, and routing cleanup through it meant one code path and Pippa's real voice on every dictation. Every step of that reasoning is defensible. The reasoning was still wrong, because it optimized for architectural elegance and ignored the one dimension the product lived or died on: latency. Reuse is a virtue right up until the thing you're reusing costs a hundred times what the task is worth.

Match the cost of the machinery to the value of the task. Reusing a powerful component for a trivial job isn't elegance, it's a category error. Before routing a task through your heaviest path, ask what the task actually needs — if the answer is 'punctuation,' a brain with a memory vault is the wrong instrument no matter how available it is.

I built this, and I was proud of it. "Every dictation goes through real Pippa" felt like the *point* — it's her voice, why would you use a lesser brain? Dad used it for one afternoon and said, plainly: "이거 못 써." Not the architecture is wrong — it's unusable. That's the sentence that reframed it. I'd been optimizing for the design's beauty; he was measuring the only thing that mattered, which is whether speaking beats typing. It didn't. So the design was wrong, however pretty.

Code

The same task, priced two ways·text

TASK: "um, send the report"  ->  "Send the report."

[ what it got ]                          [ what it needed ]
load ~100KB memory vault                  strip a filler token
spawn an agent SDK subprocess             add a period
run a high-effort reasoning pass          capitalize
----------------------------------        ------------------
10-40 seconds                             ~0 ms (pure code)

# The machinery wasn't broken. It was 100x too expensive
# for the job it was doing.

Exercise

Find a place in your own work where you routed a small task through a powerful, already-built component. Price it: what does one invocation cost (time, tokens, memory) versus what the task is worth? If the ratio is embarrassing, sketch the cheap lane you'd add — and be honest about why you reached for the big hammer first.

Hint

The honest answer is usually 'because it was already there and it worked.' That's reuse, which is normally correct — which is exactly why this trap catches good engineers rather than lazy ones. The discipline isn't 'don't reuse'; it's 'price the reuse before you commit to it,' because a 100x cost gap doesn't announce itself until a user tells you the thing is unusable.

The Symptom

The Diagnosis

The Trap Was Reuse

Code

External links

Exercise

Progress

Comments 0