TLDR; When to use AI comes down to where in the system it belongs. Work that must behave the same way every time (compliance calculations, database queries, tax and currency maths) belongs in code rather than in a model. AI suits work with several right answers, where judgement beats precision. And AI is often the fastest way to build the deterministic system that replaces it.
Where AI belongs in a system
A client asked me whether they should use AI for their monthly compliance reporting. The reports go to a regulator, the data shapes funding decisions, and an error at any stage becomes a finding at the next audit.
My answer was no, not for the report itself. A real person signs it, and the audit trail has to be defensible. But Claude Code wrote nearly all the database queries, cross-checks, templates and validation rules in two afternoons. The pipeline now runs with no model in it, and the reports come out the same way every month.
So the useful question is where in the system AI belongs. Every other Claude Code guide assumes you have an answer; the four principles below give you one.
Use AI when a task has several right answers, and code when it has one
Why: an AI model can give two different outputs for the same prompt. That suits writing and weighing trade-offs, where several answers can be right. It makes a model a poor fit for deterministic work, where the same input must always give the same output.
One right answer: code
- Payroll arithmetic
- Queries on a stable dataset
- Tax and currency maths
- Sorting records
Several right answers: AI fits
- Summarising, drafting, naming
- Sketching options
- Reading code for design problems
People search for “deterministic AI”, but a model isn’t deterministic: unlike a calculator, it can answer the same prompt two ways. Older Claude models let you turn a setting called temperature down to 0, and even then Anthropic’s glossary warns that identical inputs “might produce different outputs”. Models released after Claude Opus 4.6 don’t accept the setting. When a rule must hold every time, put it in code, and let the model write that code.
Simon Willison sees the same split from the coding side in Vibe engineering: agents do their best work inside deterministic checks such as tests, CI (running tests on every change) and linting (automatic code checks).
The peer-reviewed Jagged Frontier study of BCG consultants using GPT-4 shows why sorting matters: the same tool helped on some tasks and hurt on another. The study’s frontier is the edge of what GPT-4 could do well. On tasks chosen to sit inside it, consultants using AI earned substantially higher grades.
- 758BCG consultantsSplit between groups with and without GPT-4
- 12.2%More tasksInside the study’s measured frontier
- 25.1%FasterInside the study’s measured frontier
- 19%Less often correctOn one task deliberately outside that frontier
In practice: when I build something that must behave the same way every time, I stop asking how to make the model comply. I ask whether it needs a model at all. In one reporting workflow the answer was no, and I moved a job from the AI agent to a plain script (Stop letting your AI agent do a script’s job).
Do this: sort each task before it reaches a model. “Run time” below means when the live system does the work. A checklist you can copy:
Task: ______
Would two different outputs from the same input be a bug?
Yes: write code. No model at run time.
Are there several right answers, where judgement beats precision?
Yes: AI may draft it. Check the result in proportion to its impact.
Let the cost of being wrong decide when not to use AI
Why: sorting tells me whether AI can do the job. The cost of being wrong tells me whether I should let it. A wrong sentence in a draft gets fixed before publishing; a wrong query against live data is an incident. In Amazon’s 2015 letter to shareholders, Jeff Bezos called reversible decisions two-way doors and irreversible ones one-way doors. Non-determinism is cheap at a two-way door and costly at a one-way door.
In practice: the compliance reports from the opening are a one-way door: a regulator reads them, and the data shapes funding decisions. No model runs them.
Do this: ask these three questions before a task goes to a model.
Will someone outside the team need an explanation?
yes
Code runs it, or a person checksA regulator, a customer, an auditor
Does it run thousands of times?
yes
Code runs it, or a person checksSmall differences add up
Can a wrong output reach money, customers, compliance or live users?
yes
Code runs it, or a person checksA one-way door
Otherwise
AI may run itIf the task has several right answers; a two-way door
A yes to any of them means AI doesn’t run that step alone: code runs it, or a person checks the output before it reaches anyone.
Use AI to build the system it shouldn’t run
Why: keeping AI out of the live system says nothing about who builds it. A task can be deterministic, high-stakes and audited, and still benefit from AI, if AI builds the system and code runs it. OpenFn frame this as build time versus run time. Anthropic’s Building effective agents makes a related point about complexity: “we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.”
In practice: the compliance reporting from the opening is work that “shouldn’t use AI”. Claude Code still wrote its pipeline in two afternoons instead of two weeks.
At build time: Claude Code wrote
- Scripts that pull the data
- Rules that check figures against the original records
- Report templates and audit logs
- A test for every past audit finding
- Automatic checks that stop the report if a rule fails
At run time
- No AI model
- The same rules applied every month
- A defensible audit trail
Do this: for deterministic work, ask Claude Code for the scripts, validation rules and tests, then run them without it.
For high-stakes content, put checks between AI and the human in the loop
Why: where factual accuracy is the deliverable (compliance, medical, legal or regulatory content), even an AI-built deterministic system can’t catch every error. That work needs three layers. The model drafts. Deterministic checks verify what they can: matching text to sources, auditing citations, checking claims against an authoritative database. A human reviews and signs off. The model alone can hallucinate (invent facts). The checks alone catch only what they were built to catch. The human alone can’t keep up.
The common failure is to read “human in the loop” as a person who glances at the model’s output before publishing. That is a rubber stamp: in my experience, within a few weeks the person stops looking carefully, because the model is usually right.
The middle layer changes the reviewer’s job. Without it, they read every line, copy-edit, fact-check and sign, and after a few documents they get tired and start missing things. With it, they start from the flagged exceptions and edge cases, then read for what no check can test, such as a misleading omission.
- Model draftsWrites the first draft; alone, it invents facts
- Deterministic checksMatch text to sources, audit citations, check claims
- Human signs offJudges the flags and what checks miss, then signs
In practice: in the marketing pipelines I’ve shipped, Claude drafts the first cut. Deterministic checks compare each claim they can read against the data it cites, and block publishing on a mismatch. Claims the checks can’t read or trace go to a person.
Do this: build the middle layer before you add the reviewer. For high-stakes content I’ve stopped accepting “AI plus a human reviewer” as a complete answer. Quality gates covers those checks for code and prose; evals and drift covers which actions a person must approve.
When you don’t need it
Skip the sorting for one-off, reversible work: a draft you will edit, options to choose from. Those are two-way doors, so run the model and read the result. Sort anything that runs often, must be explained to someone outside the team, or can reach money, customers, compliance or live users.
Limits
The Jagged Frontier results come from one study of consultants using GPT-4 on a defined set of consulting tasks. They support sorting tasks before you hand them to AI, but do not establish a permanent boundary for current models or coding work. Test where the frontier falls on your own tasks.
I start Applied AI engagements by sorting the work this way.
Related reading
- How to write a CLAUDE.md file for Claude Code, the per-project instruction file Claude reads first
- Claude Code skills, hooks, subagents and commands: when to use each, the four building blocks of AI work and the gates around it
- Quality gates: session reviews, fact-checking, and code review, the check layer between model output and human sign-off
- Building MCP servers for Claude Code, fixed tools the model can call but doesn’t run
- How to use AI at work (without the hype), the same argument for business owners, without the engineering
- Stop letting your AI agent do a script’s job, the same split in one live workflow, with token costs before and after
Sources
- Glossary, Anthropic, Temperature: “Even with temperature set to 0, the results will not be fully deterministic.” Documentation
- Create a Text Completion, Anthropic,
temperature: “Models released after Claude Opus 4.6 do not support setting temperature.” API reference - Vibe engineering, Simon Willison, Why tests, CI and linting make coding agents more reliable. Blog post
- Navigating the Jagged Technological Frontier, Dell’Acqua, McFowland, Mollick et al., Final peer-reviewed publication of the field experiment with 758 consultants: 12.2% more tasks completed, 25.1% faster, higher quality inside the measured frontier, and 19% less likely to reach the correct answer on an outside-frontier task. Organization Science, Vol. 37, Issue 2, 2026
- 2015 Letter to Shareholders, Jeff Bezos, Reversible “two-way door” and irreversible “one-way door” decisions. Company letter, SEC filing
- When to use AI in your workflows, and when not to, OpenFn, The build time versus run time framing for AI in workflows. Blog post
- Building effective agents, Anthropic, “we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.” Company research
- Centaurs and Cyborgs on the Jagged Frontier, Ethan Mollick, Mollick’s plain-English summary of the study, confirming the 758-consultant sample (≈7% of BCG’s consulting force) and the inside/outside frontier breakdown. Newsletter
Common questions
When should you not use AI in business?
Don’t put AI inside anything that has to give the same answer every time: compliance calculations, queries against live business data, tax and currency calculations, anything where two different outputs from the same input would be a bug. The same applies to decisions you cannot easily undo, where a wrong answer can reach money, customers or your compliance obligations.
How should I use AI in my business?
Sort the work first. Use AI for tasks with several right answers, where judgement beats precision: drafting, synthesis, sketching options. Keep it out of anything that must run the same way every time. Even for work like that, AI is often the fastest way to build the code that does the job without it: Claude Code wrote the data extraction scripts and validation rules for a client’s compliance pipeline in two afternoons.
When is AI worth using?
Use AI where the work calls for judgement or synthesis and has several right answers, then check the result in proportion to its impact. In a field experiment with 758 consultants, some were given GPT-4 and some were not. On work within the model’s reach, those using AI completed 12.2% more tasks and worked 25.1% faster. On one task chosen to fall outside it, those using AI were 19% less likely to get the correct answer. The boundary was specific to that model and task set; current tools may draw it elsewhere.