Those Dam Machines

September 3, 2025

When building dams, beavers will use whatever the river sends their way. But they're very particular about where they put each twig, stick, or branch, and they're quick to make changes of their own.

In E.M. Forster's "The Machine Stops," humanity becomes so dependent on their vast mechanical system that when it finally fails, they've forgotten how to do anything without it. Civilization collapses not because the technology was inherently bad, but because people stopped understanding how it worked.

Does that strike a nerve?

Just over six months ago, before I touched any AI coding assistant, I built a complete website using nothing but the "Goat Book" (Test-Driven Development with Python), a terminal, and vi. No AI. No fancy IDE. Just me, the command line, and error messages.

That experience got me comfortable again with the fundamentals: reading stack traces, understanding test failures, debugging step by step. When something broke, I had to figure out why. When a test failed, I had to understand what it was actually testing.

Then, when I finally started using AI coding tools, I made a deliberate choice about which ones to use. I stuck with AI that works through IDEs like VSCode—first GitHub Copilot, then Augment Agent. I avoided the more popular approaches that work directly on the command line: Claude Code, Gemini, Cursor, Lovable, and others.

Why? Because I want to see what's happening.

When I use Augment Agent, I watch the tests being written. I see the code being generated. I observe the debugging process. I can step through the logic and understand why the AI made certain choices.

This visibility lets me guide the AI toward better solutions. When a test fails, I can see why it failed and help the AI understand what needs to be fixed. When the code doesn't work as expected, I can trace through the problem and suggest corrections.

Most importantly, I'm learning the system while it's being built.

The Out-of-Order Test Here's the test I apply to any AI coding workflow: Would I be able to manage this system if I suddenly couldn't use AI anymore?

If the answer is "I have no idea how this code works," then I'm building a dependency I can't afford.

And if you can manage the system without AI, you're also prepared for these possibilities:

What if I run out of credits? What if the pricing jumps 10x overnight? What if I need to switch AI models and the new one doesn't understand my existing code? What if energy constraints make AI coding prohibitively expensive? What if the AI service shuts down entirely?

It's not enough to build systems that work when everything goes right. You need to build systems you can maintain when things go wrong.

The temptation is enormous to just trust that the AI can handle everything. Let the AI write the code, run the tests, fix the bugs, deploy the system. It's faster and easier, and it feels more productive. But it's also more fragile.

When you don't understand what you're building while you're building it, you end up with a system you can't maintain, extend, or debug. You become dependent on the Machine.

Will you still understand your systems when there's another AI winter? Or when pricing models change? Or when new regulations restrict AI usage? Or when energy costs make AI coding uneconomical?

Or will you wait for the Machine to start working again?

My advice: Build systems you can maintain when the AI stops.

Because eventually, it will.