AI Is a Fantastic Tool and a Terrible Machine

A power sander removes material dozens of times faster than sandpaper. It has a handle shaped for a human grip and a guard to protect your fingers. The human decides what to work on, how much pressure to apply, and when the job is done. The sander just makes them faster at something they were already doing.

That’s a tool. Tools are designed for humans. They fit the way we work, multiply our capabilities, and require us to do the work.

Machines are different. Watch an episode of Unwrapped and you’ll see a production line canning 10,000 tomatoes an hour. No team of humans is doing that. Machines do the work themselves, at speeds and scales that are dangerous or impossible for people. Humans maintain them and step in when something breaks. The whole point of a machine is to get humans out of the loop.

Both are valuable. Both have contributed enormously to how we live. But they are fundamentally different, with very real tradeoffs. And right now, most of the conversation about AI is confusing the two.

Where AI Shines as a Tool

AI-assisted software development is remarkable when it’s used as a tool. A senior developer with good AI tooling can write, refactor, and debug code at a pace that would have seemed unreasonable two years ago. But this works best when the developer brings something AI can’t: judgment earned through experience.

A senior developer knows the traps that codebases fall into, not because anyone is incompetent, but because the easy path and the wrong path are often the same path. Views that do too much work. Architectures that skip layer separation because defining boundaries is harder than putting everything in one place. These are patterns that AI will reproduce and even accelerate, because the naive approach is always the most direct one. It takes a human who has seen these decisions play out in production to steer toward something better.

This is what makes AI a powerful tool: it multiplies the output of someone who already knows what good looks like. The developer is still the one with the vision for the system, still the one who knows why a particular abstraction exists and when a piece of code is actually done. AI handles the labor. The human owns the craft. I’ve found that for great developers, AI actually makes them more diligent about things like clean architectures, solid documentation, and thorough tests. We always valued those things, but they took so much effort. With AI, you can have the better patterns while ditching the busywork.

And because humans own the craft, we praise people for things made with tools. No one looks at a beautifully finished piece of furniture and says “well, the sander did the real work.” We credit the craftsperson, because while the tool amplified their capability, they owned the outcome. That’s the right relationship.

Where It Falls Apart as a Machine

The problems start when we treat AI as a machine: something that should operate on its own, produce finished output, and remove people from the process. When we treat AI as a machine, we stop owning the work. We stop checking what the agent outputs and start just feeding tasks into it. Less ownership, less understanding, less craft.

In software, this shows up as the growing complaint that AI agents produce an overwhelming volume of code nobody fully understands. The agent generates so much so fast that humans can’t meaningfully review it. The codebase becomes something that was generated rather than designed. The code might ship, but nobody can tell you why it works the way it does.

This pattern extends well beyond software. Content farms, AI-slop videos, automated communications that strip out any human voice. The common thread is the same: an overwhelming volume of output that humans can’t meaningfully oversee. This is Cory Doctorow’s “reverse centaurs” analogy, where humans are forced to serve as appendages of an AI system rather than the other way around.

The Zero-Sum Trap

The current conversation about AI leans heavily toward a zero-sum framing: AI will eliminate jobs, replace industries, make human skills obsolete. That framing only makes sense if you think of AI exclusively as a machine.

If you think of it as a tool, the picture changes. Tools don’t eliminate workers. They make workers more capable. The industrial revolution created enormous disruption, but it also created entire categories of work that nobody anticipated. The same will be true with AI. There will be things AI does better as a machine, fully automated, humans out of the loop. But there will be far more cases, especially in knowledge work and anything requiring judgment, where the right answer is to design AI for human use, to make tools.

Who Is It Designed For?

The real question isn’t “how powerful is the AI?” It’s “who is it designed for?”

When we build tools, we think about the human first. How they work, what they need, where they struggle. A well-designed tool disappears into the workflow. It amplifies our abilities and helps us achieve more of our creative vision.

A poorly designed machine makes people feel like they’re working for it rather than with it. Instead of feeling a sense of owning the craft, it makes us feel that the machine owns us. We take on the busywork of keeping up with the never ending stream; we lose the sense of direction and control.

AI will get better. Some applications will move from tool to machine as the technology matures. But the distinction will always matter, because tools and machines ask fundamentally different things of the humans around them.

Right now, today, AI is a remarkable tool. It makes senior developers more productive, more thorough, and more ambitious about the quality of what they build. It helps writers explore more ideas, researchers move faster, and teams tackle problems that used to feel too expensive to attempt.

That’s worth celebrating, not because AI is magic, but because great tools have always deserved celebration. They make us better at the work we care about. The trick is making sure we keep building tools, not machines we aren’t ready for.

You Might Also Like…

Claude wrote this?

Here is how the post you’re reading right now got made. I keep an index of my past writing and a backlog of ideas: things I find myself saying in conversations that never quite made it onto a page. Each week I brainstorm with Claude about which idea is timely/relevant/interesting. Then I have Claude ask […]