用 AI 建構、執行時不依賴 AI：讓 AI 擔任架構師，而非操作員

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.

The quiet dependency

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:

• If the service is unavailable, the daily jobs stop, and there is no written procedure because the agent never needed one.
• If prices rise, a task that cost pennies a day becomes a line item, and there is no cheap fallback.
• If a model is retired or its behavior shifts, a workflow that "just worked" changes subtly, with no code diff to explain why.
• If the person who prompted the agent leaves, the knowledge of what it was asked to do leaves with them.

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.

What "the AI just handles it" really costs

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.

The thesis

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.

Compile the judgment

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.

Hold generated code to a stricter standard

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:

1. Every rule traces to a source, such as a runbook line or an incident. A rule with no source is deleted or justified.
2. A named reviewer can explain each rule in one sentence. If nobody can, it doesn't ship.
3. Tests come from real cases, including known-bad inputs, and some must fail first. A suite the AI wrote only against its own code proves little.
4. A second, independent pass hunts for what's missing, such as the implicit rules that experienced operators carry in their heads.
5. Shadow-run before trusting. Run the new workflow beside the manual process for several cycles and treat every disagreement as a finding.
6. Keep changes small, because large generated diffs get skimmed.

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

A reference pattern: the approval-gated workflow

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:

The whole idea fits in a few lines:

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

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 approval 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

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.

Drift: the central operational risk

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:

• Strict input contracts that reject unknown columns, unexpected values and changed types instead of coercing them.
• Invariant checks on output, such as totals that reconcile to the source and counts in equal to counts out.
• Comparison against history, so a change that is technically valid but wildly different gets noticed.
• A known-answer canary, a small fixed input processed every run, so a changed result reveals changed code or environment.
• Human sampling on a schedule, because checks only catch what someone thought to check.

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

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.

Where AI fits, and the test that matters

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.

What you take on

• You now own a system: monitoring, access control, updates and a named owner.
• Rules are only as good as their review, which is why the standard above matters.
• Approval gates can become rubber stamps. Keeping gates few, showing real comparison data and logging decisions all help, but process erodes. Add structure: a second approver for high-impact actions, a cooling-off delay on irreversible ones, occasional seeded known-bad items to test the approver, and rotation with sampling of past approvals.
• Start with one job. Run it beside the manual version for a few cycles, measure, then expand.

Objections

"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.

Conclusion

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.