When Tools Build Understanding
In the late 1980s I was a manager in an Arby’s Roast Beef restaurant. Along with dryly answering the occasional customer who thought they were the first person to ask, “Where’s the beef?”, I trained counter staff.
We hired for customer focus. Politeness. Speed. A willingness to smile through the lunch rush and keep moving when the line pushed back toward the door. Out of hundreds of applicants, we tried to choose the ones who would handle people well.
Arithmetic was not one of the traits we were selecting for.
One afternoon, during a busy lunch rush, a customer handed over a $2 bill. A newly trained employee entered the amount into the till and pressed the Cash/Tender key. The display showed the change required, and the drawer opened. So far, everything looked normal. The employee provided the change and moved on to the next customer.
What she didn’t know was that she had typed $20.00 instead of $2.00.
What was given. What the machine thought it saw. (Source: Bank of Canada)
Nothing in the machine signaled that anything was wrong. It had done exactly what it was told to do. On those tills, it was easy to make that kind of mistake. There was a 0 key and a 00 key. Employees used them constantly, sometimes too quickly, and sometimes without really noticing. A two-dollar bill could become $20 with one extra press. A five-dollar bill could also go sideways because the keypad entries sat close enough together to invite mistakes under pressure.
When we counted out the drawer at the end of her shift, the employee looked stricken. She was $18.85 short. A few cents off was not uncommon. Almost twenty dollars was.
She did not understand what had happened. She knew only that the drawer was short and that it had happened on her register. She was worried I would think she had taken money from the till.
After I explained the most likely reason, that she had entered the wrong amount, she was embarrassed. She had given the wrong change to a customer in full view of everyone, and she wanted to know how to stop it from happening again.
That part stayed with me.
She was not trying to avoid responsibility. She wanted a way to verify what the machine had already made too easy to trust.
Before tills calculated change automatically, an employee had to do two things: figure out the change, then count it back to the customer. The till removed the first step. But verification step had disappeared from the workflow.
So I taught her to count the change back from the item price to the bill the customer had handed over. Not to the number on the screen, but to the cash received.
Then I taught everyone else.
Not because the till was useless. It was fast, consistent, and far better than doing the arithmetic in your head through a lunch rush. But the till had shifted verification away from the person standing in front of the customer. The total appeared on the screen. The drawer opened. The answer looked finished.
If the amount entered was wrong, the machine did not know. It could not know. It counted out money that had never been received and did so with complete confidence.
Counting back slowed the line by a few seconds. It also made the arithmetic visible again. The customer could hear it. The employee could track it. The transaction was no longer just completed. It was checked.
The arithmetic was correct. The grounding was not.
The till was useful. It mostly reduced errors. But what happened when it was wrong, and who was in a position to notice, that was what I had to identify and fix.
Calculators provoked their own panic when they began appearing in classrooms. People thought students would stop learning math. Mental arithmetic would disappear. Buttons would replace thought.
Some of that fear made sense. Mental arithmetic did decline. I had to teach employees how to count back change.
Before calculators, mathematical competence had been tied to visible effort. Long division and multiplication done by hand. Memorization of the times tables. If the machine handled the arithmetic, it was easy to assume the understanding would go with it.
But memorization is only one part of learning.
What calculators removed was clerical burden. They shortened the distance between setup and result. They made it easier to test an idea, check an answer, and move on without spending most of the work on arithmetic itself. But they did not remove the need to know what problem was being solved, or to enter the right numbers.
That part still belonged to the user.
A calculator will return an answer to whatever you enter. It will not tell you whether the structure behind the question makes sense.
I saw this when people tried to check mortgage interest calculations. In Canada, mortgage rates are usually quoted with semi-annual compounding. In the United States, monthly compounding is common. People would take a posted rate, divide by twelve, and then wonder why their own calculation never matched the bank’s number. The calculator looked exact. The result was still wrong.
Over the life of a mortgage, that difference can amount to thousands of dollars.
To match the payment to the penny, I had to explain the conversion. The calculator could perform it instantly. A financial calculator could do it with a single function key. But neither one could tell the user that the setup was wrong.
A calculator executes the model you give it.
It cannot choose the model for you.
That is the difference.
A calculator does not carry understanding in your place. It speeds up the mechanical part that comes after understanding begins to form. You still have to know what operation belongs, what units must match, and whether the result fits the world you are trying to describe. If the answer is wrong, there is still something available to push back: your grasp of the setup, your sense of scale, your recognition that the numbers do not belong together.
Calculators changed where effort was spent. They did not remove the need for judgement. They compress labor. They do not absorb judgement.
Navigation tools changed something else. They did not just speed up execution. They began to replace orientation itself.
I saw this most clearly driving near Vernon. I had an old desk to take to the landfill. Google Maps provided an authoritative route. The app gave its instructions in the same voice it used for every other trip: calm, even, and certain. Turn right in 300 meters. Continue straight. Recalculating. It got me moving immediately, which is part of why it was so easy to trust.
It also sent me down the wrong road.
The system had no difficulty producing a route. It had no hesitation. No visible uncertainty. It did not ask whether the destination made sense, whether the road fit the context, or whether a person who knew the area would have paused. It simply completed the task it had been given and kept issuing instructions.
And because I was following turn by turn, there was very little inside the act of driving that required me to build an internal map of the Spallumcheen Valley. I did not need to understand how the roads related to one another. I did not need to notice landmarks, compare routes, or keep a mental picture of where I was relative to where I meant to be. I only had to comply with the next instruction.
Until I arrived at a farmer’s fence.
Source: Pixabay Photographer ShoneJai
“You have arrived at your destination,” echoed through the vehicle.
That was the moment the dependency became obvious.
I was not just wrong. I was stuck. To get out, I had to reprogram the destination and wait for the app to tell me what to do next. The alternative was to ask the farmer for directions, and those directions would have been a list of roads I did not know and turns I could not judge. I had no internal map. I could not move confidently without the system that had just failed me.
Older navigation methods had friction built into them. I would shake out a map. Check street signs. Compare what I expected with what I saw. Overshoot a turn. Correct. Turn back. Even those mistakes taught structure. A place slowly became legible because I had to orient myself inside it.
Turn-by-turn systems smooth all that away.
The trip still succeeds. Usually it succeeds better than before. I arrive faster. I avoid congestion. I take fewer wrong turns. From the outside, nothing appears to have been lost.
But an internal map often does not form.
So when the system was wrong, there was nothing in me strong enough to notice early. The instructions sound like every other instruction. The confidence I had was borrowed. The route continued until something in the world became too obvious to ignore.
With GPS each trip normally ends cleanly and leaves very little behind for the next one. I arrive, but I do not know the place any better than when I began.
Navigation apps did not help me navigate. They navigated for me.
Calculators and navigation tools operate differently.
One builds understanding. The other borrows it.
A tool that builds understanding leaves something behind. After using it, you know the task better than you did before. You may still need help and you may still prefer the tool. But some structure has formed. You can see the shape of the problem more clearly and detect mistakes earlier. You can push back when results feel wrong.
A tool that borrows understanding does something else. It carries the task for you. It may get you to the right answer and it may do so faster and more smoothly than you could on your own. But when it is finished, very little remains in the user. There is no accumulation. The next attempt begins from the same place of dependence as the last.
When using tools I ask two things:
After using the tool, do I understand the task better?
When the tool fails, do I notice?
Calculators usually pass both tests. Navigation apps often fail the second. They complete the trip, but they do not necessarily leave a map behind.
That distinction is important because useful tools are often treated as though they all work the same way.
They do not.
Some reduce effort while preserving judgement.
Others reduce effort by carrying judgement away.
I saw this happen in student work.
A student submitted an assignment. It looked polished. The structure was almost perfect and the sentences were clean. The transitions arrived where they should. The argument sounded finished.
So did the footer ChatGPT left behind. “If you want I can also generate a PowerPoint presentation…”.
Another student had applied a router configuration in a lab. Buried in it was a security mode that would not normally appear in beginner work. When the lab output did not match the manual, the student called me over. I pointed to the configuration and asked where he had learned about security (trying to hold the sarcasm in my voice). He admitted, a little sheepishly, that he had simply copied what AI had supplied.
That is the peculiar thing about generative AI in education. The output can arrive looking like the final stage of thought before the student has done the work that usually produces it. Structure appears. Fluency appears. Revision options appear. The answer does not look partial. It looks complete. A plausible answer that looks like thinking happened.
And that changes the learning sequence.
With a calculator, the user still has to know what to ask. With AI, the system can supply not only words but organization, tone, and apparent reasoning. It can produce something that resembles understanding without building much of the structure underneath it.
In some uses, it can function like a calculator. It can help a student test an idea, compare phrasings, debug a small problem, or see an error more quickly. Used that way, it can lower friction without removing responsibility. It can help build understanding.
But the path of least resistance is often different. A student using a calculator must construct the question, interpret the domain and recognize when the output is absurd. AI can also provide an absurd answer, but recognition is much harder.
Ask for a paragraph. Get a paragraph. Ask for a configuration. Get a configuration. Ask for an explanation. Get one that sounds calm, complete, and authoritative whether it is grounded or not. The system does not merely accelerate expression. It can supply expression before the learner has built anything solid enough to evaluate it.
That makes it less like a calculator than people often claim. Calculators supply mechanical answers where AI supplies plausible answers, so that in many classroom uses, it behaves more like GPS.
It gets the student moving. It reduces hesitation. It smooths over uncertainty and reaches something that looks like a destination. But if the system is wrong, there may be very little in the student strong enough to notice early.
Confidence is attached to output that the student did not generate, test, or fully understand. The words are there. The structure is there. The resistance that would normally force learning to happen is not.
The answer arrives before the mind has built something that would let it resist the answer.
When I taught staff to count change back at Arby’s, I was not rejecting the till.
The till was useful.
It was fast, consistent, and far better than doing arithmetic in your head through a lunch rush. But it had shifted verification away from the person nearest the transaction.
That is the question institutions now face with far more powerful systems. Where is the verification?
Most of the time, we ask whether a tool improves outcomes. Does it save time? Does it reduce error? Does it make complex work easier? Those are reasonable questions. They are also incomplete.
We should also ask what the tool trains users not to notice.
We should ask where verification now lives. We should ask what survives after the tool is removed. We should ask whether judgement remains with the user or gets left behind in the workflow.
These questions do not have simple answers.
Efficiency can hide the loss of verification. A system can improve visible performance while weakening the user’s ability to detect failure. It can produce smoother workflows, faster outputs, and fewer obvious mistakes while leaving less inside the person to resist error when error appears.
This is not just a classroom problem. It is a design problem. A management problem. An institutional problem.
Tools do not merely change how work gets done. They change what the worker must still know to do it well.
That is what design chooses. Counting back the change, or driving into a farmer’s fence.
Top comments (0)