The Design Pattern AI Companies Don't Want You to Know
Most teams wire generative AI into their routine tasks and call the model on every run. The better pattern: have AI build the routine, let a job orchestrator run it, and bring AI back only for exceptions.
There is a quiet architectural mistake spreading through almost every company that has gotten excited about AI. It looks productive. It demos beautifully. And it is slowly turning predictable, repeatable work into something slow, expensive, and impossible to trust.
The mistake is simple: teams are wiring generative AI directly into their routine, repetitive tasks. Every time the task needs to run, the model gets called to figure it out all over again.
There is a better way, and the AI vendors are not in a hurry to tell you about it, because it means you call their models far less often.
The better pattern is this: do not use AI to do the repetitive work. Use AI to build the thing that does the repetitive work.
The anti-pattern: embedding AI inside the routine
Here is what most teams are shipping right now. A task needs to happen on a schedule or in response to an event. Instead of writing the logic once, they hand the whole job to a large language model on every single run. Parse this invoice. Categorize this ticket. Pull these fields. Rename these files. Format this report. Every execution is a fresh API call where the model reasons from scratch.
It feels like magic the first time. It also quietly creates four problems that compound at scale.
You burn tokens on work you already solved. The task was the same yesterday and it will be the same tomorrow, but you are paying for full inference every single time. A routine that runs ten thousand times a day is ten thousand model calls a day for a problem whose answer never changed.
The output is non-deterministic. The same input can produce a slightly different result on the next run. For creative work that is a feature. For a routine, repeatable process, it is a liability. You cannot build reliable systems on a component that gives you a different answer depending on the weather inside a model you do not control.
It is slow. A deterministic script returns in milliseconds. A model call has network latency plus inference time, often seconds. Multiply that across a high-volume pipeline and your throughput collapses.
You inherit a hard third-party dependency. Every run now depends on a vendor's API being up, on their rate limits, on their pricing, and on them not silently changing model behavior underneath you. Your routine, boring, mission-critical process now has its reliability capped by someone else's status page.
To be clear, this is the right approach for genuinely novel, judgment-heavy, one-off work. The error is using it for the repetitive part. Generative AI is a fantastic author. It is a wasteful, unreliable assembly-line worker.
The pattern: AI generates the routine, an orchestrator runs it
Now flip the architecture. Use the model once, at design time, to produce the actual routine: code, a script, a SQL query, a workflow definition, a set of rules. Then hand that artifact to a job orchestrator (a cron job, a queue worker, a CI pipeline, a workflow engine) and let it execute the routine as many times as you need.
The AI does the hard, creative part one time: figuring out how to do the job. The orchestrator does the easy, repetitive part forever: actually doing it.
Look at what every one of those four problems turns into.
| Embed AI in the routine | AI builds the routine | |
|---|---|---|
| Cost | Pay for inference on every run | Pay for inference once, run for free |
| Determinism | Different output run to run | Same input, same output, every time |
| Speed | Seconds (network + inference) | Milliseconds (local execution) |
| Dependency | Vendor API on the critical path | No vendor needed at run time |
| Auditability | A black box you re-prompt | Real code you can read, test, and version |
This is not a new idea. It is the oldest idea in software, applied to AI. We have always used expensive, slow, expert effort to write programs, and then let cheap, fast, dumb machines run them billions of times. Generative AI is the most powerful program author we have ever had. Pointing it at the run-time loop instead of the authoring step is using a master architect to lay one brick at a time.
The hybrid pattern: a routine that heals itself
The obvious objection to a static, generated routine is that the real world drifts. A new edge case shows up. An upstream format changes. The routine that was correct last month hits a case it was never written to handle.
This is exactly where you bring AI back in, and where the architecture gets genuinely powerful. You do not put the model back in the hot path. You put it on call.
The hybrid pattern works in four moves:
- AI generates the routine. Same as before. You get real, deterministic code.
- The orchestrator runs it. The vast majority of executions succeed with zero model calls. Fast, cheap, predictable.
- AI handles the exceptions. When a run fails or hits a case the routine cannot handle, that event triggers the model. AI reasons about the specific failure and resolves that one case. You only pay for intelligence exactly when the deterministic path runs out.
- AI submits the fix back to the routine. This is the move that makes it compounding. After resolving the exception, the AI proposes a change to the routine itself, the orchestrator picks up the improved version, and the same exception never needs a model call again.
The system gets more complete over time instead of more expensive. Every novel situation becomes permanent, deterministic logic. Your token spend trends toward zero per run even as your coverage trends toward complete.
The mental model is the one that matters most here: AI is the architect and the on-call engineer, not the assembly-line worker. It designs the machine, it gets paged when the machine hits something new, and it upgrades the machine so it does not get paged for that again. It does not stand on the line turning the same bolt ten thousand times a day.
How this shows up in testing
This is not abstract for us at Testery. Software testing is one of the most repetitive, high-volume processes a team runs, and it is exactly the place this anti-pattern is tempting. You could ask a model to re-derive what to click and what to assert on every single run of every single test. It would work in a demo, and it would be slow, flaky, costly, and non-deterministic in production. A flaky test is just a non-deterministic routine, and putting a non-deterministic model in the run loop is a great way to manufacture flakiness on purpose.
The right shape is the one above. Use AI to author the tests and the page objects, run them deterministically on every commit and deploy through the orchestrator, and bring AI back in when a test breaks: to diagnose the failure, decide whether it is a real bug or a test that needs updating, and submit the fix. The suite gets faster and more reliable over time, not more expensive.
The takeaway
When you reach for AI on a repetitive task, ask one question first: am I using this model to do the work, or to build the thing that does the work?
If the answer is "do the work," you are probably on the anti-pattern. You are paying a premium, on every run, for non-deterministic output, gated by someone else's API.
Move the AI up a level. Let it author the routine. Let a boring, reliable orchestrator run it. Bring the AI back only for the exceptions, and have it teach the routine what it learned.
That is the pattern. It costs the model vendors a lot of tokens, which is roughly why it is not the first thing you hear about. It also happens to be how you build AI systems that are fast, cheap, deterministic, and genuinely yours.
