A language model can interpret a request, calculate an answer, format a report and decide what happens next. That makes it tempting to give the model the whole workflow. But capability alone is a poor guide to architecture.
My starting point is simpler: reserve AI for ambiguity, and use systems for structure. Apply reasoning where it resolves uncertainty or improves understanding. Capture the parts that are already understood in code, rules, schemas and templates.
The cost problem is a design problem
Token budgets, usage caps and model tiers make inference costs visible. Yet repeated spending often points to something more fundamental: a workflow is asking the model to solve the same problem again.
Regenerating a stable report layout, applying established calculations or rediscovering a known mapping consumes reasoning capacity without creating new understanding. Increasing the budget may keep that workflow running, but it leaves the design problem intact.
I want the value of AI to accumulate. A resolved question should become a reusable decision, specification or component, rather than another prompt that must be interpreted on every execution.
Ask whether the step needs AI
Before choosing a model, I ask what remains uncertain in the task.
AI is well placed when the work involves interpreting incomplete information, exploring alternatives, synthesizing evidence, explaining findings or making contextual judgments. Those activities benefit from flexibility because the answer cannot be fully specified in advance.
Established calculations, repeated formatting, fixed routing and stable classification rules have a different character. If the expected behavior can be stated explicitly and tested, it should usually be implemented directly.
A high-frequency step with little ambiguity is a particularly strong candidate for removal from the model path. The question is whether each invocation adds useful reasoning or merely repeats settled work.
Structure the work before selecting the model
I use five steps to make that distinction practical:
- Define the structure. Clarify the inputs, outputs, constraints and boundaries.
- Capture repeatable logic. Put established rules into code, schemas, workflows or templates.
- Locate the ambiguity. Identify the interpretation, synthesis or judgment still required.
- Apply AI there. Give the model a bounded role with evidence and a clear way to assess the result.
- Choose the model last. Match its capability and cost to the reasoning that remains.
What this looks like in practice
Software engineering: use stronger reasoning to explore architecture, identify risks and clarify requirements. Once the design has been decomposed into clear implementation tasks, smaller coding models may be sufficient. A continuing need for frontier reasoning during routine implementation can indicate unresolved ambiguity upstream. I explore this further in Efficient Use of AI for Software Engineering.
Analytical reporting: compute facts, capture evidence, apply explicit rules and render the report through software. Use AI to explain findings and interpret their significance. The report should not depend on a model reinventing its calculations and layout each time.
Process automation: encode predictable steps in workflows and services. Use AI when the process encounters unfamiliar language, an exception or a decision that genuinely requires context. An agent can call dependable capabilities without having to reason through every operational detail.
Make placement a deliberate decision
This principle also changes how I assess AI adoption. More model calls do not necessarily mean more value. I look for useful reasoning, reusable outputs and less uncertainty in the work that follows.
Organizations need a shared understanding of where inference is justified, where explicit logic is preferable and how model tiers fit different tasks. Otherwise, scaling adoption can simply scale avoidable cost and variability.
The goal is to place AI where its flexibility matters—and preserve what it helps discover in forms that can be used reliably again.