Leadership Garden
Last week I asked an agent to read about 260 comments for me.
Rich Hickey had published a short piece called “‘AI’ is Not a Tool”, and it started two fights at once: 85 comments under the LinkedIn post and well over 170 on Hacker News. I wanted the shape of both threads without giving up an evening, so I pointed an agent at them and got back a tidy digest. Halfway through reading it, I realized I’d just done the thing the essay is about. I didn’t read the threads. Something else read them, and I read its summary.
(I went back and read the parts that mattered. That ate the evening anyway.)
If you run an engineering org, you’ve heard “it’s just a tool” in a rollout meeting, usually from someone who wanted the meeting to end. I think Hickey is right about that phrase. I also think managers should take him more seriously than anyone, because most of us already made this trade with our own careers.
What Hickey actually argues
Most of the angry replies argue with an essay he didn’t write. On HN, people demanded rulings on gdb, cameras, catapults and ffmpeg, as if he’d published a taxonomy. When someone on LinkedIn tried the same with lathes and CNC machines, he answered that sorting the world into two bins was never the point. He even agreed with a commenter who called the model itself a lossy knowledge base you query in plain English. His target is the chat products sold as tools for homework, research, writing and coding.
His test for a tool is narrow on purpose: “A tool is something you wield.” You hold it, it pushes back, you correct, and the correcting is where expertise comes from. A drive-thru is useful, but nobody learns to cook at one. You ask, something else does the work, and what you learn is how to phrase the order. The next model release can make even that knowledge worthless.
He also conceded in the replies that toolness is a spectrum. The more using a thing feels like ordering a sandwich, the less of a tool it is. That concession matters, because most of us use these products near the sandwich end, and the word “tool” hides it.
Where the objections are fair
I went through both threads looking for pushback that actually lands, and some of it does.
Power tools misbehave too. Several people pointed out that a table saw isn’t deterministic, that no two boards are alike, and that a router can throw a workpiece back at you. All true. But nobody hands a table saw a description of a cabinet and walks off to get coffee. The saw goes wrong in your hands, while you watch, and you make the correction. One HN commenter drew the line better than I could: a lathe gets more useful as its operator gets more skilled, while the chat products mostly hand you an accept or reject decision on output you didn’t shape.
“It depends on how you use it” is harder to wave away. A retired engineer on HN described building a data pipeline of close to 200,000 lines in about six weeks. He reads the agent’s reasoning as it runs and interrupts when it heads somewhere he dislikes. He has it build competing prototypes and compare them. Half the codebase is tests, property checks, Lean proofs and TLA+ models. Another commenter framed it as a spec problem: one-shot a whole app and you have a wish machine, but give it a tight interface and your own test suite and it starts to behave like a tool.
I believe both of them, and I’d happily work with either. Read what they actually do, though. They rebuilt the feedback loop by hand, through their own effort, against the defaults of the product. The retired engineer even granted that Hickey is probably right about it not being a tool for writing code. What he wields is the engineering around the code. Nothing in the product nudges anyone toward working that way, and one commenter offered a simple check: look at how these products get pitched to your employer.
Managers already made this trade
Hickey’s essay describes the move I made when I went into management.
When I stopped shipping code for a living, I moved from wielding to requesting. I describe outcomes, other people do the work, and I review what comes back. Most of what Hickey says about automation applied to me. I lost the continuous feedback. My sense of how long things take began to drift. After a few years I could judge a design faster than I could write one, and now that I lead leaders, I sit two steps away from the code.
I don’t regret it. I did make the trade knowingly, with a rough sense of what it would cost. Management has plenty of words for that cost, starting with the director who is “out of touch”. We built rituals against it too, like skip-levels and the occasional week spent back on the on-call rotation.
Two HN commenters got to the same place from opposite directions. One said an agent is closer to an employee than to rm, which is why the industry calls it an agent. Another, less charitably, said paying for Claude and paying a contractor amount to the same act: you’ve stopped working. I’d call both of those delegation, the one skill managers get trained on, badly, in their first year. Delegation buys you output and costs you contact with the work. And it only holds up while the person delegating can still tell good output from plausible output.
That last condition is the one that worries me.
The judgment has to come from somewhere
My judgment came from years of wielding. I can review a pull request because I wrote hundreds of bad ones and had them torn apart in review. A senior engineer can steer an agent off a doomed approach because she tried that approach by hand once and watched it collapse.
Hickey’s list of what you lose when something else does your reading (noticing things, learning how an argument hangs together, working out whose work to trust) reads a lot like a junior engineer’s first three years. It’s also the stock every delegator draws down later.
When a senior engineer hands a task to an agent, she’s spending judgment she already has. When a junior does it, there’s nothing to spend yet, and the task that would have built some just got done by something else. “Just a tool” flattens those two cases into one.
One line from the HN thread stuck with me: a camera is an excellent tool for producing photographs and a poor one for becoming a better painter. (I take a lot of photos. I never learned to paint, and the camera is part of why.) Whether that matters depends on whether your organization still needs painters. Every engineering org I know does. Somebody has to catch the bug the agent keeps putting back. Somebody has to hold a whole system in their head when the agent’s context runs out, and notice when a confident answer is wrong.
Why the word matters in a rollout
One HN commenter dismissed the whole essay as a stipulated definition followed by a “so what?” Inside a company, the “so what” is easy to find.
Another made the opposite case on political grounds. Keep calling it a tool, he argued, so humans stay accountable and nobody gets to blame the machine. I see the appeal in public debate. In a planning meeting, I think it backfires.
The usual rollout announcement says new tool, licenses for everyone, and an adoption target. Nobody in that meeting asks what the team will stop learning, because nobody asked that about the last IDE either. So the plan tracks adoption and has no line for skills.
Call it automation, or delegation, and different questions show up:
- What does this team stop practicing if the rollout works?
- Who still needs to do the task by hand, and how do they keep that ability?
- When the output is wrong in a plausible way, who notices, and what experience lets them notice?
- If the vendor swaps the model next quarter, what do we lose?
You’d ask these before automating any other workflow. Calling it a tool is how a team gets to skip them.
What I’d ask of other leaders
I’m not going to ban anything, and I doubt the no-AI Fridays fix much.
Start by naming the mode, task by task. The same product can sit anywhere on Hickey’s spectrum. An engineer who asks it to explain an unfamiliar codebase while she traces the calls herself is close to the tool end. An engineer who prompts a feature, skims the diff and merges is ordering a sandwich. Either can be right for the task. I want people to know which one they’re doing, and to have picked it.
For early-career engineers, keep some work by hand: debugging their own incidents, writing the first draft of a design, reading the actual RFC instead of a summary of it. Some of them will feel hazed. I’d still rather they build the judgment now than find out in five years that they never did.
Count the feedback loop as work. The retired engineer spent a lot of those six weeks on proofs and property tests that no product asked him to write. In plenty of performance conversations, that effort would read as slowness. It should read as the job.
And drop “just a tool” from your own vocabulary. When someone on my team reaches for it, I’d rather hear what they’re automating and what it costs.
Hickey closes with a warning about what automation does to the people who rely on it. Managers learned the delegation version of that lesson the slow way. We’re now handing the same trade to every engineer in the building, mostly without saying so out loud. They deserve to hear it plainly: you can stop doing the work, but know that you stopped.