I Stopped Running Long Enough to Build the Bicycle

A former coworker told me, decades ago, that sometimes we get too busy running to stop and get on the bicycle.

I’ve taken that to heart over the years. It’s the argument for tooling, made without saying the word “tooling” — you are moving, you are making progress, and you are still slower than the version of you who paused, built the thing, and rode.

I’ve adjusted it slightly for the times: I’ve stopped running long enough to build the bicycle and ride it.

What I was running from

I’d been building a lot with Claude Code, and it works. That’s the part people get right. What people undersell is how much of you it consumes to keep it working. You write a spec. You paste in a chunk of it. You wait. You read the output. You catch the thing it got wrong. You paste in the correction. You remember which file it was supposed to touch. You answer its question. You wait again.

Multiply that by a real project and you haven’t automated your work. You’ve turned yourself into a very expensive message queue.

The models had gotten good enough that my attention had become the bottleneck. That’s a good problem — it means the thing beneath you is working — but it’s still the thing you have to fix next, and no amount of running faster fixes it.

What I’m building instead

Project Lumbergh. Named after Office Space, because if I’m going to build a management layer I’m going to be honest about what it is.

The design goal is a pipeline that can:

• Take a design spec and divide the project into manageable chunks.
• Give Claude Code the instructions for each chunk.
• Apply a repeating QA layer until the code actually works, rather than until it merely compiles.
• Provide an escalation path that answers Claude Code’s questions automatically — and knows which questions it must not answer on its own, and route to me instead.
• Keep complete project plans, write and maintain its own documentation, and push the code to GitHub.

None of those pieces is exotic on its own. The interesting part is the seam between them: what happens when a step fails, who decides, and how a human stays in the loop without being in the loop for everything. That distinction is most of the design.

The one rule it’s built around

AI is powerful, it’s wrong a lot, and you keep humans in the loop.

Which in practice means the escalation path matters more than the happy path. Anything consequential comes back to me. Anything mechanical does not. Getting that line in the right place is the whole job, and I expect to spend a long time moving it.

Where this stands now

Added September 2026. It got built. Sparky came online in November 2025; the pipeline has been filing and building real work since March 2026 — past seventeen hundred intakes filed, around twelve hundred of them carried all the way through to complete, with a QA gate that has genuinely rejected work I would have shipped.

The cast grew, too. There’s a VP tier that plans and decomposes, PMs that dispatch parallel builders, a panel of outside models called The Bobs that reviews high-stakes specs before anything gets built, and Milton — who lives in the basement of the org chart doing maintenance and housekeeping, and who turns out to be the one keeping the whole thing upright.

The bicycle works. I’m still building parts for it while riding, which I’m told is normal.

The projects, experience and opinions here are mine. AI helped me turn my notes and build records into this piece and polished it for Cairoglyphics.ai.