Executive Summary: Every generation of tooling redraws the line between foundational knowledge and mechanical busywork. When calculators arrived, educators panicked that students would forget how to think mathematically — yet the engineers who learned on calculators built systems their predecessors couldn’t have imagined. The current worry that AI will leave programmers helpless if it goes down deserves scrutiny, because it’s essentially the same argument. The real question isn’t whether to use the tool — it’s whether you understand enough to know when the tool is wrong.

There was a time when calculators weren’t allowed in exams. The reasoning seemed obvious: you need to understand the math, not just push buttons. Not long after, they weren’t just allowed — they were required. The floor had shifted, and nobody seriously argued we’d lost something essential.

I was reminded of this recently talking to a surveyor. I asked how he confirmed his survey closed — meaning, how did he know his final measurement looped back to exactly where he started. He held up a handheld device. “I plug it in.” I went home and worked it out the old way, sines and cosines, the way I’d learned it. It closed. So did his. Same answer, very different paths.

Now I’m hearing a version of the old calculator argument applied to AI: if developers rely on AI to write code, what happens when the AI goes down? Will they be helpless?

It’s worth sitting with that question honestly rather than just dismissing it or panicking about it.

The Dependency That Already Exists

Here’s something I think gets glossed over in these conversations: programmers are already deeply dependent on tools they couldn’t replicate from scratch on a bad afternoon. Your IDE catches type errors you’d miss. Stack Overflow (or its AI successor) supplies patterns you haven’t memorized. Package managers pull in libraries representing hundreds of thousands of person-hours of work. Cloud providers handle infrastructure that would take teams years to build.

Nobody seriously argues that a developer who uses pip install instead of writing their own HTTP library from scratch is dangerously dependent on tooling. We accepted that abstraction a long time ago.

The calculator isn’t even the best analogy here. A better one might be: when electric adding machines replaced human “computers” — the people whose actual job title was computer, who did arithmetic for a living — did we lose something critical? In a narrow sense, yes. In any practical sense, no. The people who kept their jobs learned to use the machine and moved on to harder problems.

What You Actually Need to Know

The real concern with calculator dependency — the one that had some merit — was never “what if the batteries die.” It was: will you recognize a wrong answer?

If a student blindly trusts a calculator result that’s off by an order of magnitude and doesn’t notice, that’s a problem. Not because the calculator failed, but because the student lost the intuition to sanity-check the output.

The same thing applies to AI-generated code. If you accept a function that looks plausible but has an off-by-one error in a loop boundary, or subtly mishandles a null case, you’ve got a bug — and you’ll have a hard time finding it if you never developed the instinct to read code critically.

That’s the skill worth preserving. Not the ability to write boilerplate from memory. The ability to read what the tool produced and recognize when something smells wrong.

I’ve seen this distinction play out clearly. Developers who understand what the AI is attempting — who can look at generated code and think “wait, that’ll break on an empty list” — catch problems before they ship. Developers who treat the output as authoritative find bugs in production. The tool is the same. The difference is whether the human in the loop has enough understanding to be a real check on it.

The Italy Test Case

If you want actual data on this rather than just analogies, there’s a useful natural experiment. In April 2023, Italy’s data protection authority banned ChatGPT over GDPR concerns — suddenly, with little warning. Researchers from Monash University tracked GitHub activity from over 8,000 developers in Italy and comparable European countries before and after the ban.

Output dropped roughly 50% in the first two business days. Then it recovered. Developers found workarounds — VPNs, Tor — and got back to normal productivity within about a week.

The dependency concern gets real traction here. A 50% output drop is not trivial, and it happened fast. But the recovery is equally telling. Developers didn’t sit helpless waiting for the ban to lift. They adapted. The tool had become load-bearing infrastructure, and when it got yanked, people found another way to get to it.

What the Italy data doesn’t tell us — and this matters — is whether the code produced during those two disrupted days was worse, or whether developers were just producing less of it. That’s the more interesting question. Output volume is measurable. Code quality is harder to study.

The Shifting Floor

Every generation in engineering has this argument about whatever the new tool is. Spreadsheets would make accountants sloppy. GPS would destroy spatial reasoning. ORM frameworks would produce developers who couldn’t write SQL. Some of these concerns had a grain of truth. None of them turned out to be the catastrophe predicted.

What actually happened, consistently, is that the floor of required knowledge shifted. You don’t need to know how to dead-reckon a ship’s position using a sextant anymore. You probably do need to understand enough about GPS coordinate systems to debug why your location service is returning coordinates in the wrong hemisphere.

This is already happening with AI-assisted coding. The floor is shifting right now. I don’t memorize the exact syntax for every library call anymore — I describe what I need and the AI produces something reasonable that I then read critically and refine. What I use constantly is the understanding of data types, indexing behavior, what happens when date columns arrive with mixed formats. That knowledge doesn’t get abstracted away. If anything, the bugs that survive AI generation tend to be subtler than the ones we used to make manually, and catching them requires more understanding, not less.

The Recharge Question

So — is depending on AI to code meaningfully different from needing a calculator to be charged?

Honestly, not much. Both represent tooling that extends what you can do. Both create a dependency. Both shift the floor of what you need to carry in your head.

The surveyor with his handheld device still needs to understand what a closed traverse means and why it matters. He just doesn’t need to work through 40 trig calculations by hand to verify it. That seems like a reasonable trade.

What I’d want to know about any developer leaning heavily on AI is the same thing I’d want to know about the student with the calculator: do you understand the problem well enough to know when the answer is wrong?

If yes — use the tool. That’s what it’s there for.