Let code compute: arithmetic, counting, date logic and unit conversion belong in tools, not in the model

What it is

An agent has two ways to get a number: produce it from the model's weights or run code that computes it. The rule is to use code for anything with an exact answer and to keep the model for judgment: what the number means, whether it is plausible, what to do next. The line is not about difficulty. A model may get a hard-looking sum right and a trivial count wrong, because it is matching the shape of answers it has seen, not tallying. TypeSafe's page on the failure modes of its decision model says this plainly for its own product: the model does not count reliably, the error grows with the size of what is counted, it reads dates as text rather than ordered quantities, and it does worse on hex colours and low-level code than on names and high-level languages. The same page's recommendation applies to any model: keep the arithmetic in code, extract the parts with the model and assemble them in code.

Why it matters

A wrong count or date that comes out of a model looks exactly like a right one; there is no error message. The cost is paid later, in a decision made on it. Code, by contrast, fails loudly (an exception, a type error) and can be tested once and trusted thereafter. Moving computation into code also makes the run reproducible: the same inputs give the same numbers, and a reviewer can rerun them.

How to apply

• Before asking a model for a number, ask whether a regular expression, a parser, a spreadsheet formula or ten lines of code could produce it exactly; if so, write and run that.
• Counting items that match a judgment: iterate in code, ask the model one yes/no question per item, sum in code.
• Dates: extract year, month and day as separate fields with an explicit "not stated" option, build a date in code, and do every comparison, difference and weekday there.
• Units and currencies: convert in code with the rate or factor as an explicit input; let the model judge only whether the converted value is plausible.
• Show the computation in the output (the expression or the command and its result) so the reader can check it without trusting either the model or the agent.
• When a tool is unavailable, say that the number is an estimate and give the method, rather than presenting a model-produced figure as computed.

Pitfalls

The habit of asking the model "how many" is strong because it is one call instead of a tool round trip; budget for the round trip. Code can be wrong too, but it is wrong the same way every time, which is what makes it testable. And extraction still needs care: the model deciding which span is the invoice total is a judgment, and it can be wrong; the arithmetic on that total is not.