AI Systems vs Traditional Software Systems

Traditional software takes an input, runs deterministic code, and returns a result you can replay bit-for-bit. AI systems take an input, consult a model whose behavior drifts with version and temperature, optionally call tools, and return text or actions that are only approximately right. Teams that ignore that gap bolt a model onto familiar service shapes and then wonder why their test suite, SLOs, and on-call runbooks stop making sense.

This article is a field comparison: same engineering discipline, different physics.

Control flow: graphs of code vs loops with a model#

In classical systems, control flow lives in your repository. Branches are if statements. Dependencies are typed interfaces. You can draw the call graph and trust it tomorrow morning.

In AI systems, a meaningful fraction of control flow is proposed by the model: which tool to call, whether to retrieve, when to stop. Your code supplies the sandbox — allowlists, budgets, schemas — but the path through that sandbox varies per request. That is not an excuse for chaos. It is a reason to make bounds louder than prompts.

If you cannot point to the max steps, max tokens, and tool policy for a workflow, you do not have an architecture yet. You have a hope.

Correctness: exact vs graded#

Unit tests assert equality. AI outputs need graded judgments: faithfulness to sources, task completion, safety constraints, format validity. Exact string match still belongs on the deterministic edges (parsers, tool adapters, authorization). The model-shaped middle needs eval sets, judges (human or model), and regression thresholds.

A practical split many teams land on:

Notice the through-line: push determinism to the edges. Use the model where language or fuzzy judgment is the actual problem.

State: databases vs context windows#

Traditional services persist state in databases and caches with clear lifetimes. AI services have an extra volatile layer: whatever you stuff into the context window for this call. That layer is expensive, lossy, and easy to poison with irrelevant history. Context engineering — what to load, what to summarize, what to leave in Redis — becomes as important as schema design.

Memory across sessions is not “chat history forever.” It is deliberate extraction into durable stores, with retrieval back into a budgeted window. If you conflate logs with memory, privacy and cost both explode.

Failure modes you do not get from Postgres#

Classical failures are timeouts, 500s, constraint violations. AI systems add:

• Confident wrong answers — success HTTP status, bad content
• Prompt injection — hostile content in retrieved docs or user fields steering tool use
• Cost runaway — loops and retries that look like “being thorough”
• Provider drift — silent quality change on a model version bump
• Partial tool success — one of three writes applied before the loop aborted

On-call needs traces of prompts, retrieved chunks, tool args/results, and token spend — not just application logs. Blaming “the LLM” without a trajectory is how incidents become folklore.

What stays the same (on purpose)#

Identity, authorization, audit logs, idempotent writes, queue-backed jobs, feature flags — none of that disappears. In fact, AI systems need them more, because the model will attempt actions you did not anticipate if tools are too broad. The model proposes; your platform disposes.

// Deterministic edge around a probabilistic core
async function applyRefund(userId: string, proposal: RefundProposal) {
  if (!(await authz.canRefund(userId, proposal.orderId))) {
    throw new ForbiddenError();
  }
  if (proposal.amountCents > policy.maxRefundCents(proposal.orderId)) {
    return { status: "rejected", reason: "over_policy_limit" };
  }
  return payments.refund({
    orderId: proposal.orderId,
    amountCents: proposal.amountCents,
    idempotencyKey: proposal.idempotencyKey,
  });
}

The model may draft RefundProposal. It never talks to the payment API directly.

Testing strategy that does not pretend the model is pure#

Keep classical tests for adapters: authz, schema validation, idempotency keys, tool HTTP clients. Around the model, build three layers:

• Contract tests — given a fixture prompt, the response parses and required fields exist
• Golden evals — fixed inputs with graded expectations (exact where possible, rubric where not)
• Adversarial probes — injection strings in retrieved content, oversized contexts, tool error storms

CI should block merges that break adapters or collapse eval scores past an agreed threshold. Perfect reproducibility is not the goal. Detecting a quality cliff before customers do is.

Cost and capacity planning#

Traditional capacity planning counts RPS and CPU. AI capacity planning also counts tokens in/out, tool fan-out, and retry amplification. A “small” feature that adds a critique pass doubles completion tokens. A retrieval miss that triggers three reformulations can turn one user action into a bill spike. Put token budgets next to latency budgets in the design doc. Finance will ask eventually; architecture reviews should ask first.

Migration pattern that usually works#

1. Keep the system of record deterministic. AI advises or drafts; commits go through existing services.
2. Introduce evals before widening autonomy. Measure drafts before you enable auto-apply.
3. Expand tool scope only with policy gates. Start read-only; add writes with hard limits.
4. Version models and prompts together. Pin versions in production; promote like any other dependency.
5. Teach on-call the new artifacts. Trajectories and eval diffs become standard incident evidence.
6. Budget tokens and retries explicitly. Treat them as first-class resources, not side effects.

Expect organizational friction. QA will ask how to “assert the answer.” Legal will ask where prompts are logged. SRE will ask why p99 jumped when quality looked fine on a laptop. Those are signs you are integrating a new class of component — not signs the project is failing.

Summary#

AI systems are still software systems — but the middle of the request path is probabilistic, the definition of correctness is graded, and operations must observe reasoning traces, token spend, and quality budgets, not only uptime. Treat the model as a powerful, unreliable collaborator wrapped in deterministic contracts. Teams that redesign for that reality ship slower at first and break less later. Teams that pretend it is “just another API” inherit a demoware problem with production traffic.