Skip to content
HyperProductive

Insights

Don't shoot the lamp

HyperProductive June 14, 2026

Homer Simpson used his new gun to turn off the lights. We're starting to use AI the same way — for things the tool already in front of us does instantly, and for free.

The lamp didn’t need shooting

In one of the great Simpsons episodes, Homer buys a handgun and promptly decides it’s the answer to everything. He uses it to get the TV remote working, to open a beer, and — the image that sticks — to turn off the lights by shooting out the lamp. The switch was eighteen inches away. We laugh because the absurdity is so clean: a powerful new tool, aimed at a problem that already had a perfectly good solution.

I’ve been thinking about that lamp a lot lately, because we’re starting to do the same thing with AI.

Everything looks like a prompt

Abraham Maslow gave us the phrase decades ago: “If all you have is a hammer, everything looks like a nail.” The law of the instrument. Hand someone a shiny new capability and they’ll start applying it to everything — not because it fits, but because it’s the tool in their hand.

Right now the shiny capability is the AI prompt, and the reflex is real. Rename a method? Ask the assistant. Migrate a project off an old framework? Prompt it. Reorganize imports, extract a function, rename a variable across forty files? Prompt, prompt, prompt.

Here’s the catch: most of those aren’t AI problems. They’re solved problems — and the solution is already sitting in your editor.

The IDE quietly wins the deterministic stuff

Renaming a method is one keystroke: F2 in VS Code, Shift-F6 in a JetBrains IDE. It’s instant, it’s exact, and it understands scope — it won’t accidentally rename a same-named method on an unrelated class, because it works from the syntax tree, not a guess. Extract-method, move-class, change-signature, organize-imports: each one a shortcut, each one deterministic.

Even the big jobs have purpose-built tools. Migrating a Java codebase? OpenRewrite runs recipes that transform thousands of files predictably. Modernizing .NET? The Upgrade Assistant exists. JavaScript has codemods and jscodeshift. There’s a whole category of this, and it shares one trait: it does the transformation the same way every time, so you can read the diff and trust it.

Point an LLM at that same rename and you get something slower, non-deterministic, and fully capable of slipping a subtle wrong edit into the change — which you now have to catch in review, for a task the IDE would have finished correctly before you’d typed the prompt. That’s shooting the lamp.

This is where the cost lives

It would be one thing if the reflex were merely inelegant. But it has a price — and a lot of teams are now hunting for it. (We’re doing exactly that research for a client right now: how to reduce AI token spend. The single most effective recommendation turned out to be almost embarrassingly simple — stop using AI for everything.)

Every reflexive prompt spends something: tokens, latency, and the scarcest resource of all, your attention reviewing output that didn’t need to exist. The cheapest token is the one you never spend. “Reduce AI usage” doesn’t mean switch it off; it means don’t reach for it when a deterministic tool would be faster, free, and more reliable.

And the risk compounds in exactly the place it’s most tempting. MIT Sloan Management Review’s research on generative AI in software is blunt about it: the headline productivity numbers — GitHub’s “up to 55% faster,” McKinsey’s “twice as fast” — come from controlled studies of isolated tasks. In real, legacy-laden systems, careless AI use tends to create technical debt rather than remove it, especially in less experienced hands. The tool that felt like a shortcut becomes the thing the next rescue is about.

The actual skill is knowing which tool

None of this is anti-AI. AI is a genuinely powerful instrument, and there’s a long list of work where it’s the right one: drafting from a spec, exploring an unfamiliar API, generating boilerplate you’d otherwise hand-type, rubber-ducking a design, writing the first ninety percent of a test. Ambiguous, generative, judgment-shaped work — that’s where it earns its keep.

The failure isn’t using AI. It’s using it for everything — letting the newest tool quietly become the only tool. And noticing the difference is, not coincidentally, a senior move. A junior reaches for the prompt because it’s the exciting thing in their hand. A senior reaches for F2, because the answer is deterministic and the lamp has a switch.

That judgment — match the tool to the problem, don’t shoot the lamp — is the same discipline behind everything we build. Software that’s too important to get wrong is also too important to hand to whichever tool happens to be shiny this year.


Sources & further reading

Have a system that is too important to get wrong?

Tell us what you are facing and we will tell you, straight, what it will take to turn it around.

Start a conversation →