> cat essays/the-calculator-problem.md · October 2026 · draft
The Calculator Problem
We taught everyone to press the buttons. Nobody taught them which problems the calculator is for.
In 1980 Seymour Papert wrote the sentence I wish I had written. Computer literacy, he said, “is often taken as meaning knowing how to program, or knowing about the varied uses made of computers.” Then:
“But true computer literacy is not just knowing how to make use of computers and computational ideas. It is knowing when it is appropriate to do so.”
Seymour Papert, Mindstorms (1980)[1]
Swap “computers” for “AI” and you have the problem I keep running into, and the reason this site exists.
The buttons are mostly solved
Most AI training teaches the buttons: how to write a prompt, which tool your IT department allows, what a context window is. I teach that too. It is what AI @ Workplace 101 to 401 are for, and you need it the way you need to know where the keys are. But the buttons are not where the money is lost.
A 2025 S&P Global survey found that 42% of companies had abandoned most of their AI initiatives, up from 17% the year before.[2] The models did not get worse that year. What fails, consistently and expensively, is the interface between human purpose and machine execution.
The other number everyone quotes is METR's. In July 2025 its randomized controlled trial found that experienced open-source developers took 19% longer with AI tools, while believing afterwards that they had been 20% faster.[3] I used that figure in my own documents, and it needs an update. In February 2026 METR said its newer data was “an unreliable signal”, partly because developers increasingly refused to work without AI. The point estimates moved toward a speedup, and both intervals include zero.[4] So the 2026 follow-up no longer shows a slowdown. The part that survives is the gap between feeling and fact: skilled people could not tell, from the inside, how much the tool was helping.
What the calculator taught us
We have done this before. When calculators arrived in classrooms the argument was loud and the outcome was quiet. In 1980 the US National Council of Teachers of Mathematics recommended that “problem solving should be the focus of school mathematics” and that programs “take full advantage of the power of calculators and computers at all grade levels”.[5] The machine took the arithmetic, and the human curriculum moved up.
The research afterwards is specific. A 2003 meta-analysis of 54 studies found that calculator use “did not hinder the development of mathematical skills”, and that skills improved when calculators were “an integral part of testing and instruction”.[6] The one consistent harm signal was early: sustained calculator use in Grade 4 “appears to hinder the development of basic skills in average students”.[7] Foundations first, then the tool. And redesign the checking around the tool.
That is the calculator problem. Not “should we use it”, but “for which problems, when, and who checks”.
Where the analogy breaks
I have to be careful, because the calculator is a flattering comparison. A calculator returns the same correct answer every time. A language model is probabilistic and can be fluently wrong, in the same confident tone it uses when it is right. A calculator automates a skill below the problem. An LLM reaches into the framing, the reasoning and the writing, the “math by hand” layer itself. There is no clean line beneath which delegation is safe, so you need a way to decide case by case.
What the cockpit taught us
Aviation has a name for one version of this: mode confusion. After the Asiana 214 crash in 2013, the NTSB found that autothrottle and autopilot complexities were “inadequately described in Boeing's documentation and Asiana's pilot training, which increased the likelihood of mode error”.[8] A 2013 FAA working group found that pilots “sometimes rely too much on automated systems and may be reluctant to intervene”, and that “Autoflight mode confusion errors continue to occur”.[9] Skilled crews, working automation. The failure was not knowing which mode they were in.
The finding that changed how I think about my own work is older. Parasuraman and Manzey's 2010 review found that automation complacency appears in naive and expert participants alike and “cannot be overcome with simple practice”, and that automation bias “cannot be prevented by training or instructions”.[10] Training is necessary and it is not enough. You also need structure: a plan before action, checkpoints, a deviation report, nothing consequential shipped uninspected. Aviation built that into procedure. Knowledge work has no licences, no recurrent checks and no public accident reports, so we have to build the structure ourselves.
Mode fluency
Here is the claim. Working well with AI is not one skill. It is moving deliberately along four axes:
- Stance: what am I expecting from this exchange? An answer (Oracle), a deliverable (Genie), a decoded document (Interpreter), a job done while I am not looking (Executor), and ten more.
- Structure: what must I supply for that expectation to hold? Prompt, context, intent, judgment, coherence, plus evaluation and a harness.
- Autonomy: how much of the work am I watching? Assistive, directed, autonomous, continuous.
- Ambition: how big is the ask? Speed, altitude, depth, range, in Felix Rieseberg's four types.[11]
Mode fluency is knowing which mode you are in, choosing it on purpose, and when the work goes wrong, re-entering at the right one. When output disappoints, the instinct is to rewrite the prompt. Often that is the wrong layer. The fix is adding a file to context, clarifying a priority, or deciding what the AI should do when it is uncertain, none of which involve changing the prompt at all.
The practical tool is a table. Each stance leans on one layer of the Stack, and that is where its failure lives. The Oracle fails at judgment: you took confident prose as fact. The Genie fails at the prompt: wishes are literal. The Interpreter fails at evaluation: a confabulated reading sounds more insightful than the true one. The Executor fails latest of all, in the harness and in your judgment, because not watching was the point. Name the stance, then check its layer first.
Where this sits
None of this replaces what you may already know. Anthropic's AI Fluency course and its 4Ds (Delegation, Description, Discernment, Diligence) are a good baseline; if you know the 4Ds, mode fluency is the diagnostic layer above them.[12] Andrej Karpathy's “agentic engineering” is the developer end of the same ladder.[13] Nate B. Jones made the public case for intent engineering, making AI optimize for what you actually want; it is one layer of the Stack, and the credit is his.[14] What I am adding is the part for people who are not engineers: which stance you are in, which layer that stance depends on, and what to check before anything leaves under your name.
Intelligence is now cheap, but judgment is rare. You may use the calculator. You still sign the exam.