Language models reason. Code calculates. The distinction that saves you
A CFO's spreadsheet added up perfectly and answered the wrong question. The rule that prevents it, and the harness that makes any model worth using.
Published 26 August 2026 · Updated 12 September 2026
Language models reason. Code calculates. Give a model the questions that need judgement, give ordinary code the questions with one right answer, and never let the model do arithmetic it could have handed off. Almost every AI mistake in a business setting comes from ignoring that line.
Here is what ignoring it looks like.
The spreadsheet that added up perfectly
A good friend of mine, a CFO, had been using Copilot to work through financial spreadsheets. Upload the numbers, ask for the analysis, read what comes back.
It came back looking right, so he let it sit. Going back over it later, some of the formulas were wrong. Not wildly wrong. Wrong in a way that survives a read-through, because the shape of the answer was right and only the formula underneath it was not.
The spreadsheet added up exactly what it was told to add up. The model had reasoned its way to the wrong formula.
Every answer you will ever get arrives at the top of that chart. And unlike you, it never hedges. It has no sense of how thin the ice under it is, so knowing when it is out of its depth stays your job.
Most people stop here at "I should not trust it". That is half right. You would not publish an intern's work unread, and you would not refuse to give the intern work either. "I do not trust it" describes a feeling, not a process.
What is the difference between reasoning and calculating?
Two questions about the same spreadsheet.
"What was Q3 revenue?" One right answer, the same answer every time anyone asks, forever. That is deterministic work, and ordinary code has done it perfectly for decades.
"Why did Q3 revenue drop?" No single right answer. It needs context, judgement, and someone weighing possibilities against each other. That is reasoning, and it is the thing a language model is genuinely good at.
The rule of thumb:
- Language models reason. Code calculates.
- Give the model the questions that need judgement.
- Give code the questions that have one right answer.
- Never let the model do arithmetic it could be handed.
That is exactly what happened to the spreadsheet. The arithmetic was never the problem. The model reasoned its way to which numbers to add, which genuinely is a judgement, and nothing checked whether that judgement was right.
What is an AI harness?
An AI harness is everything you build around a model so its answers are grounded in your business: the documents it can read, the record of what you decided last month, the standing instructions you wrote once, the tools it can reach, and the checks that must pass before anything leaves.
Treat the model as an engine. The harness is the vehicle. From the outside in:
Instructionshow you work, what it must never do alone
Context and knowledgeyour business, your documents, your constraints
Memorywhat was decided, where things stand
Toolsfiles, spreadsheets, calendars, systems
Approval and checkswhat must be true, and who signs it
Look at that for a second, because it is the whole argument. The model is the small box in the middle, and everything that decides whether the work is any good is one of the layers around it.
The fix for a bad answer is almost never a better model. It is a better harness.
If you use Claude or ChatGPT in a browser you already have somewhere to put this. It is called a Project, it takes custom instructions, and almost nobody fills it in. There is a side effect worth having, too: build it this way and changing model becomes a settings change rather than starting over.
Should you delegate this to someone junior?
Not yet, and this is the part worth being honest about.
Quick question, answered the way you would answer it to yourself rather than in a board meeting: what did you actually use AI for last week?
If the answer is "drafted something, tidied an email, sanity-checked my thinking", you are where most people at your level are. Meanwhile someone three levels below you is probably better at this than you. Not smarter. They have simply had more goes at it, hit the walls, and found out where it genuinely fits. You have seen a demo, and demos are highlight reels.
Handing someone "go make this more efficient with AI" gives away precisely the judgement you need to keep: what is worth automating, what it is hopeless at, and what would be reckless to let it near. That judgement only comes from having done it.
Common questions
Why does AI get maths wrong when a calculator never does? Because the model is not calculating. It is reasoning its way to which calculation to perform, and that reasoning can be wrong while the arithmetic that follows is perfect.
What is an AI harness? Everything around the model: instructions, context, memory, tools, and the approval step. The model is the engine; the harness is what makes the engine useful and safe on your work.
Do I need a better model to get better answers? Usually not. Most bad answers come from a thin harness, not a weak engine. Fix what the model can read and what has to be true before it is used, and the same model gets noticeably better.
Where do I start without engineers? A Project in whatever assistant you already pay for. Custom instructions, your real documents, and one rule about what it must never do alone. That is the beginner version of the harness, and it takes an afternoon.
The next step is doing rather than reading. The free course sets up your own AI operating system: the harness above, done properly, a permanent place your AI reads before it starts working. The first part takes about twenty minutes and you finish it with a workspace that knows your job.
This started life as Build Notes Nº 02.