Steampunk Engineering

The metaphor

I like my shit to break into component parts that can be replaced. I hate magic, especially when it breaks.

Steam engines look complicated with all their pipes and valves. But every piece has a clear purpose. You can see the steam moving, feel the pressure building, watch the pistons turning. When something goes wrong, you trace the problem.

Compare that to a "smart" system: it just works until it doesn't. Then you're staring at logs that mean nothing, waiting for someone else to fix their black box.

What this means for AI tools

AI is matrix multiplication plus nonlinear functions plus lots of parameters. Once you download the weights, it's your computation. No different from having a compiler or database on your machine.

This matters because most AI tooling treats models as services you rent. You send requests to someone else's server, pay per token, and hope the API doesn't change or the company doesn't pivot.

Local models flip this. ollama pull mistral and it's yours forever. Works offline, on a boat, in a submarine, wherever you can run code.

The debugging test

When something breaks, can you:

• See what it's doing? (logs, files, clear state)
• Test each piece separately? (modular components)
• Replace the broken part? (swappable tools)
• Understand the failure mode? (no black boxes)

If you can't answer yes to all four, your system has too much magic. Search broken? Swap it out. Want better embeddings? Drop in a replacement. Context acting up? Replace the whole thing. This only works when components have clear boundaries.

Human in the loop, actually

Everyone talks about "human oversight" but usually means a rubber-stamp approval step. Real human control means humans decide what to do and why, while automation handles how.

Automate the boring parts: boilerplate, setup, execution patterns. Keep the interesting parts: choosing what problems to solve, defining what success looks like, reviewing what matters.

The pattern that works: Human → AI → Information → Human Decision → Automated Execution.

The pattern that doesn't: Human → AI → Decision → Action. That's not assistance, that's replacement.

100 Rabbits principles

The sailing programmers at 100 Rabbits wrote about surviving a "software winter" - building tools that work in extreme conditions. Their principles translate directly to AI tooling:

• Immediate: Works right now, not after setup/login/payment
• Repairable: When something breaks, you can fix it yourself
• Portable: Runs anywhere you can run code
• Durable: Will work in 10 years without updates
• Efficient: Doesn't need massive resources to be useful

Applied to AI: local ollama models (no internet required), file-based storage (no databases to maintain), bash/Python tooling (runs on any Unix system), human-readable formats (debug with cat and grep).

When magic breaks

OpenAI goes down. Your local ollama keeps working.

New Claude model changes behavior. Your saved prompts work the same way they always did because you're not dependent on one provider.

GitHub Copilot suggests garbage. Your manual scripting skills haven't atrophied because you never stopped using them.

Vector database service gets expensive. You own your embeddings and can move them anywhere.

In two years, steampunk tools will still work (maybe need minor updates). Magic AI systems will have broken three times and been "reimagined" twice.

The tradeoff

This approach is slower to start. Setting up local models takes more effort than signing up for an API key. Writing shell scripts isn't as flashy as a "no-code AI solution."

But you end up understanding what you built. When it breaks at 3am, you can fix it. When requirements change, you can adapt. When a component gets better, you can swap it in.

Building steampunk deathtraps with levers and whistles while others zoom around in self-replicating gundam cybersuits. But your monkey paw is pulling those levers, you can feel the spring tension, you know when the bolts need oiling.

Compute is computation. Use the computer.