Build with AI, Run Without It: Use AI as the Architect, Not the Operator

Posted on Oct 29 • Originally published at bbonam.hashnode.dev

Teams are quietly making AI a runtime dependency. It runs their jobs, triages incidents, fixes bugs and handles daily chores. It works well, until the service is down, the price changes, or the person who wrote the prompt leaves and nobody can say what the agent was actually doing.

This article argues for a simple alternative: use AI as the architect, not the operator. Use it at build time to produce ordinary, inspectable software, then run that software yourself. Keep AI in the loop only for the genuinely ambiguous remainder.

A pattern has become common. A recurring task, such as reconciling a feed, checking a pipeline or restarting a stuck job, gets handed to an AI agent. It works, so nobody writes or maintains code. Within months, the task is simply "something the AI does."

Nobody decided to make the business dependent on a model provider. It happened one convenient delegation at a time, and it rarely appears in a risk register. The consequences are easy to list:

None of this predicts that AI services will fail. It is ordinary engineering: a system should not depend on something outside its control for work it does every day without a plan for when that thing is unavailable. We apply this rule to power, networks, cloud regions and payment processors. AI shouldn't be an exception.

Cost scales with repetition, not difficulty. The first run of a task may need intelligence. Runs two through ten thousand mostly need repetition. When a model repeats identical reasoning every time, you pay for the same thinking over and over.

Opacity erodes operational knowledge. When a person writes a script, the team can read it, diff it and reason about it. When an agent resolves an issue conversationally, the fix lives in a transcript, if anywhere. Over time the team collects outcomes without understanding. The real continuity risk isn't that the AI goes away. It's that when it does, nobody knows what it was doing.

Non-determinism is a feature in design and a defect in operations. Models are valuable because they handle ambiguity, and that means two runs on the same input can differ. For a reconciliation, a billing check or a compliance export, you usually want the opposite: identical input, identical output, with an audit trail.

Use AI to write the thing that does the work, not to do the work itself, wherever the work repeats and the logic can be stated.

The last row is a real trade-off. You give up some flexibility, because the system adapts only when someone updates it. For recurring work, reliability and predictable cost are usually worth more than instant adaptability, and AI remains fast at making the updates.

When an agent solves a recurring problem, treat the solution as a design draft. Ask it to turn what it did into four things: a script or job that runs without any model call, tests that encode expected behavior including the failures discovered along the way, a short runbook written for someone who has never seen the system, and a schedule owned by a team account rather than one person's login.

Then draw the judgment boundary explicitly. Split any recurring task into the deterministic majority, which fixed logic handles for free, and the ambiguous remainder, which needs interpretation. A rule-based classifier can often get the large majority of a recurring classification task right in microseconds. Send only the leftovers to a model. This cuts cost and also limits the damage of an outage: the routine majority keeps flowing and only a small queue waits.

For that remainder, put model calls behind a thin interface so the provider can be swapped. A locally hosted open-weight model is a credible continuity floor for private or high-volume text work. It's slower and weaker on hard reasoning, but it's available whatever happens to an external service.

There is a trap here. "The AI wrote it" can become a reason to review less, because fluent, well-formatted code reads as trustworthy. That recreates the opacity problem at build time. A concrete standard helps:

Generated code deserves more scrutiny than handwritten code, not less.

The common real-world case isn't a single script. It's a multi-step job someone babysits, such as a weekly process with several stages, checks between them and decisions along the way. Handing the runbook to an AI agent and saying "run this" saves labor but not resilience. The job still can't run if the AI can't, decisions vary from run to run, and the only record is the agent's own account.

The durable alternative is to have AI build the workflow once, then let it run itself. Split the runbook into three kinds of content:

workflow WeeklyJob (runs on a schedule, no AI involved) data = retry(fetch_inputs, times=3) # on failure: alert a person check = validate(data) # numbers and booleans, never prose if not check.schema_ok: stop_and_alert("schema changed", evidence=check) if abs(check.row_count_change_pct) > 5: # a decision rule, written down decision = wait_for_human("data variance", evidence=check) if decision!= APPROVED: end_run("rejected") result = transform(data) load_to_staging(result) decision = wait_for_human("publish", evidence=compare(result, last_week)) if decision!= APPROVED: end_run("rejected") publish(result) report_and_log() # every step and decision recorded Enter fullscreen mode Exit fullscreen mode Any workflow engine can express this. AWS Step Functions, Airflow, Temporal and similar tools provide retries, branching and a pause-until-a-person-responds mechanism. The tool matters less than four properties: every step has a machine-checkable result, every decision is an explicit rule, every unknown stops the run, and every irreversible or outward-facing action sits behind a gate.

The gate is what replaces "the AI decides":

wait_for_human(gate, evidence): save(run_id, gate, status=PENDING, evidence) notify(approvers, link_to_review_page) # sign-in required pause run (up to 48 hours) on timeout: alert, stop, publish nothing record_decision(run_id, gate, approved, comment): approver = identity_from_sign_in() # never taken from the request itself if status!= PENDING: reject duplicate log(approver, approved, comment, timestamp) # the audit trail resume run with decision Enter fullscreen mode Exit fullscreen mode One line carries real security weight. The approver's identity comes from the sign-in system, never from the request. If the form let callers type their own name, anyone who could reach it could approve as anyone else, and the audit trail would record a fiction.

Likewise, a decision counts only while the gate is pending, so a second click or a replayed request can't change the outcome.

If one risk deserves the most design effort, it's this. A rule-based system that silently passes wrong output because an upstream format changed slightly is arguably worse than an agent that adapts, because nobody knows anything is wrong. The agent at least varies visibly. The script fails quietly and consistently, week after week.

The principle is fail closed: an unrecognized situation is a stop, not a guess. In practice that takes layers:

for each run: reject input with anything unrecognized # strict contract result = process(input) assert invariants(result, input) # totals tie out assert distribution_close_to_history(result) # valid and plausible assert canary(known_input) == known_output # code and environment unchanged any failure -> stop, alert a person, publish nothing Enter fullscreen mode Exit fullscreen mode Each drift event should feed the next rule update. Over time the rules absorb the real behavior of the upstream system. That is the maintenance cost this pattern trades for token cost, and it isn't zero.

Recurring token spend falls to roughly zero, because the weekly run makes no model calls. AI is used for the occasional build or change, a bounded cost rather than a per-run one. For intuition, use abstract units, because real token counts depend on the model, the prompt and how the agent is used. Suppose one agent run of a nightly check costs 10000 Tokens. After a year that is 3650000 Tokens for one workflow, before retries, and the total grows with every workflow you add and every price change. Compiled into a scheduled script, the same check costs a one-time build effort plus small upkeep, and the model is called only for the few anomalies the rules can't classify.

The test is a single question: if the AI service is unavailable on run day, does the job still complete, or fail safely so a person on call can finish it? If the honest answer is "we'd wait for the AI," you still have a dependency, however good the runbook is.

"Code is brittle; agents adapt." True, and it's the central trade-off. That's why the failure mode must be a clean stop and escalation, and why adaptation happens deliberately, by asking AI to update the code, instead of implicitly on every run.

"This is only about cost." Cost is the most visible benefit. The more important ones are continuity and comprehension: the business keeps running if the AI doesn't, and the people responsible can still explain how.

And AI should stay in the loop for genuinely novel problems, open-ended analysis, drafting, interpreting unstructured input and diagnosing failures the code doesn't cover. The claim is narrower than "avoid AI in operations": routine, repeatable, statable work shouldn't require it.

AI has made it dramatically cheaper to build software. The temptation is to use that capability to skip building software and have the AI do the work every time, which trades a one-time cost for a perpetual one and turns a tool into a single point of failure.

A more durable use is to let AI do what it does best, turning understanding into working systems quickly, and let ordinary software do what it does best, running the same task the same way, cheaply and predictably.

The goal is not to depend on AI less. It is to make sure that depending on it is a choice the business can reverse.

Views are my own and do not represent my employer.