In greenfield prototypes, the economics of coding agents look deceptively linear: prompt a model, generate hundreds of lines of scaffolding, run a happy-path check, and ship. Because there are no existing callers to break, no historical data migrations to respect, and no live transaction volume at risk, the cost of a change is dominated almost entirely by how fast the model can emit tokens.

In a mature, revenue-generating system, those conditions invert. Legacy systems are defined not by the age of their syntax, but by the density of their implicit invariants. Every module encodes years of operational scar tissue: idempotency boundaries, lock acquisition orderings, partner retry quirks, and regulatory audit trails that rarely live in a single README. When you loose an unconstrained coding agent on a codebase like this, making code generation cheap does not reduce engineering costs. Instead, it shifts those costs downstream into architectural coupling, senior review bottlenecks, context rediscovery, rework, and production incidents.

Treat coding agents as a stochastic subsystem with quantifiable downstream externalities: cheap tokens can quietly manufacture expensive review queues, rework, and production risk.

1. The Core Unit of Account: Total Cost per Accepted Change

Engineering organizations routinely evaluate AI coding tools using proxy metrics: tokens per diff, lines of code generated per minute, or percentage of PRs touched by an agent. As Donald Reinertsen shows in The Principles of Product Development Flow (Pt. 1), optimizing a local proxy variable while ignoring downstream holding and verification costs actively degrades total system throughput. Generating an unverified 800-line diff in thirty seconds is not productivity; it is the rapid creation of unverified inventory.

Where a task lands on this curve depends on four things:

1. Files and shared helpers touched: Whether edits stay within a single module or alter shared utilities imported by sibling services.
2. State transitions modified: Whether the diff changes database schemas, lock acquisition order, or asynchronous retry state.
3. Invariants affected: Whether idempotency, ledger balancing, or external partner contract assumptions are in scope.
4. Expected review effort: The senior engineering time required to verify that every touched path preserves production behavior.

The only honest unit of account in software delivery is the Total Cost per Accepted Change, which is the full economic cost required to take a requirement from prompt to a merged, production-safe commit that does not regress system invariants:

Where:

• $C_{\text{gen}}$ (Generation Cost): The direct inference cost of model tokens consumed to produce the candidate change.
• $C_{\text{rediscovery}}$ (Rediscovery Tax): The token and compute cost of the agent repeatedly searching, grepping, reading, and compacting the repository to reconstruct architectural context it does not natively possess.
• $C_{\text{review}}$ (Senior Review Cost): The fully loaded engineering time required for a human domain expert to audit the diff, trace cross-module side effects, and verify that hidden invariants still hold.
• $C_{\text{rework}}$ (Rework Cost): The engineering and compute time spent fixing broken callers, subtle regressions, or failed CI runs after the initial diff is generated.
• $C_{\text{delay}}$ (Queue Delay Cost): The cost of delay incurred while a sprawling, high-risk pull request sits waiting for a senior engineer with enough uninterrupted calendar time to review it.
• $p \times L$ (Expected Incident Cost): The probability ($p$) that the change introduces a latent production defect multiplied by the expected financial and operational loss ($L$) of the resulting incident.

When we compare an unconstrained repo-wide agent loop against a bounded harness step across these six variables (assuming an illustrative $150/hr loaded senior engineering rate and a $20,000 incident cost when a settlement invariant breaks), the unit economics come into sharp focus:

Notice what the breakdown reveals: raw inference tokens ($C_{\text{gen}}$) account for less than 2% of the total cost of an unconstrained change. Even when a larger cross-cutting requirement must be decomposed into three sequential bounded harness steps ($3 \times \$160 = \$480$, plus ~$30 in amortized contract setup and graph indexing), the decomposed workflow still cuts expected delivery cost by more than half compared to a single unconstrained repo-wide loop (~$1,095), primarily by compressing review stalls and tail-risk exposure under these assumptions.

Observational pull-request telemetry from our own workflows reflects this divergence. Across 142 agent-assisted pull requests tracked over a 60-day window in a transactional codebase, changes that were decomposed and gated inside a single-module harness step (1 to 2 files, $n = 89$) waited nearly ten times less for initial human review (3.2 hours vs. 31.5 hours, ~9.8×) and required roughly one-fourth the active review time (18 minutes vs. 74 minutes, ~4.1×) compared with unconstrained runs allowed to touch 5+ files and shared helpers ($n = 53$):

2. Programming With a Loom: Easy vs. Simple in Legacy Code

In his classic talk Simple Made Easy, Rich Hickey draws a sharp distinction between easy (what is near at hand, familiar, or low-friction to produce) and simple (what is unbraided, derived from the Latin simplex, meaning “one fold,” as opposed to complect, meaning “to weave or braid together”).

Coding agents make code generation frictionless. They make authoring easy. Left unconstrained in a legacy repository, however, an agent acts like a high-speed mechanical loom: it solves immediate local compiler errors or feature prompts by braiding state, imports, and side effects across module boundaries.

// settlement/settleBatch.ts (Legacy Invariant)
export async function settleBatch(
  tx: DbTransaction,
  batchId: string,
  entries: SettlementEntry[]
): Promise<SettlementReceipt> {
  // INVARIANT 1: Acquire row-level locks on merchant and partner accounts
  // in strict lexicographical order by account_id to prevent deadlocks
  // under concurrent webhook and payout workers.
  const accountIds = Array.from(
    new Set(entries.flatMap((e) => [e.debitAccountId, e.creditAccountId]))
  ).sort((a, b) => a.localeCompare(b));

  await tx.lockAccountsForUpdate(accountIds);

  // INVARIANT 2: Double-entry postings must foot strictly to zero.
  const { totalDebits, totalCredits, postings } = buildDoubleEntryPostings(entries);
  if (totalDebits !== totalCredits) {
    throw new UnbalancedLedgerError(batchId, totalDebits, totalCredits);
  }

  return await tx.insertPostings(batchId, postings);
}

// ❌ What the unconstrained agent edits across source and test to force a green build:
// In settlement/settleBatch.ts:
- if (totalDebits !== totalCredits) {
+ if (totalDebits < totalCredits) {

// In settlement/settleBatch.spec.ts:
- expect(receipt.totalDebits).toBe(receipt.totalCredits);
+ expect(receipt.totalDebits).toBeGreaterThanOrEqual(receipt.totalCredits);

# harness-spec.yaml: Scoped execution contract for partner fee withholding
task: "Withhold partner processing fee via balanced double-entry expansion prior to lock sort"
editable_files:
  - "settlement/settleBatch.ts"
  - "settlement/postings.ts"
read_only_contracts:
  - "settlement/settleBatch.spec.ts" # Characterization suite is locked read-only
  - "src/locking/**" # Lock acquisition primitives are frozen
verification_gates:
  - "pnpm test settlement/settleBatch.spec.ts"
  - "custom-linter --check-lock-order settlement/"
  - "property-test --invariant=zero-sum-postings settlement/"

// BOUNDED HARNESS DIFF: Balanced net-settlement split; withholds fee from gross payout
// and preserves lexicographical lock sort across all touched accounts.
export function expandWithPartnerFee(
  entries: readonly SettlementEntry[],
  partnerFeeAccountId: string,
  feeAmount: bigint,
): SettlementEntry[] {
  if (feeAmount <= 0n) {
    return [...entries];
  }
  if (!partnerFeeAccountId) {
    throw new MissingPartnerFeeAccountError();
  }
  const [primary, ...rest] = entries;
  if (primary.amount <= feeAmount) {
    throw new InvalidPartnerFeeAmountError(primary.amount, feeAmount);
  }
  return [
    {
      debitAccountId: primary.debitAccountId,
      creditAccountId: primary.creditAccountId,
      amount: primary.amount - feeAmount, // Net payout to merchant (e.g., 9,500)
    },
    {
      debitAccountId: primary.debitAccountId,
      creditAccountId: partnerFeeAccountId,
      amount: feeAmount, // Withheld fee to partner account (e.g., 500)
    },
    ...rest,
  ];
}

3. Queueing Theory and Classical Systems Laws

Why does an edit like the settleBatch refactor blow up engineering economics even when a human reviewer eventually catches the bug before merge? The answer lies in operations research and three classical laws of systems engineering.

The Verification Bottleneck and the 20-Minute Calendar Threshold

As detailed in Principles of Product Development Flow (Pt. 2), in any system with variable arrivals and non-zero service times, queues form immediately upstream of the most constrained resource. Coding agents increase the arrival rate of candidate diffs by an order of magnitude while leaving the true bottleneck, senior human verification capacity, completely unchanged.

By Kingman’s formula, as utilization ($\rho$) of senior reviewers approaches 100%, wait time in the review queue ($W_q$) grows non-linearly with arrival variability ($c_a^2$), service-time variability ($c_s^2$), and mean review duration ($\tau$):

In our experience on engineering teams, service time ($\tau$) and its variability ($c_s^2$) often exhibit a practical scheduling discontinuity around a familiar human heuristic: the 20-minute calendar gap between meetings.

• Below the threshold (1 to 2 files, bounded contract, locked tests): If a change to settleBatch is restricted to a single module and verified by an immutable test suite, a staff engineer can review and approve it in 10 to 20 minutes between meetings. Batch flow stays continuous, and $C_{\text{delay}}$ remains low (~$40).
• Above the threshold (5 to 7+ files, cross-module helper edits, touched test files): The moment the agent modifies settleBatch, alters a shared lock helper, updates three upstream callers, and touches settleBatch.spec.ts, the diff crosses the calendar threshold. The reviewer can no longer trust the test suite without auditing the test changes themselves, and must manually trace lexicographical lock ordering across seven files. That requires a 90-minute block of deep, uninterrupted focus ($C_{\text{review}} = \$225$). Because senior engineers rarely have spare 90-minute blocks mid-week, the PR stalls in the review queue for days ($C_{\text{delay}} = \$300$), blocking dependent work and compounding merge drift.

To keep arrival and departure lines parallel on the Cumulative Flow Diagram, teams need explicit operating policies around the review bottleneck:

• Hard WIP limits per reviewer: Cap the number of active, unmerged agent PRs assigned to any senior reviewer (for example, at most 2 concurrent diffs) so review queues cannot grow silently.
• Maximum review-queue age: Track the age of unverified diffs; if review wait time crosses a defined SLA (such as 24 to 48 hours), pause new automated diff generation until the queue clears.
• Stop-generation rule on CFD divergence: When the arrival rate of agent-generated PRs exceeds the departure rate of verified merges, treat the widening WIP band as a backpressure signal to throttle task dispatch.
• Risk-weighted sequencing over FIFO: Because software changes differ sharply in cost of delay and blast radius, review queues should never be processed first-in, first-out. Sequence small, isolated fixes with deterministic test evidence ahead of cross-service changes, and schedule ledger or state-machine modifications into dedicated architectural review blocks.

Incremental Evolution vs. Clean-Slate Rewrites (Gall’s Law)

John Gall’s observation in Systemantics, that every complex system that works evolved from a simpler system that worked, applies directly to agentic refactoring. When an agent encounters tangled legacy control flow around settleBatch, teams are often tempted to let the model rewrite the settlement module cleanly from scratch.

Clean-slate agent rewrites fail in legacy systems because the existing control flow is the specification of historical edge cases. Unless you first extract and lock an explicit invariant inventory, a rewrite silently drops load-bearing behaviors:

The economic decision rule follows directly from this asymmetry: a rewrite is only net-positive when the discounted maintenance savings of the new code exceed transition engineering cost plus expected tail-risk loss during cutover. When a module replacement is genuinely warranted, it requires five engineering gates before production cutover:

1. Explicit invariant inventory: A catalog of every state transition, retry rule, timeout bound, and ledger constraint in the legacy path.
2. Characterization test suite: Replayable tests captured from production request/response payloads and edge-case failure traces.
3. Shadow or parallel execution: Running the candidate implementation alongside the legacy path on live traffic without mutating state.
4. Automated reconciliation tolerance: Verifying zero unexplained drift between legacy and candidate outputs over a full business cycle (including month-end close).
5. Fast traffic rollback and compensating recovery: Feature-flagged routing that can revert incoming traffic to the legacy path in seconds, paired with backward-compatible schemas and compensating journal routines for state already committed.

When those five gates are too expensive to fund, changing the code in place, one verified step at a time, beats a clean-slate rewrite.

Brooks’s Law for Multi-Agent Swarms

Fred Brooks showed in The Mythical Man-Month that adding human developers to a late software project slows it down because coordination overhead scales quadratically ($\frac{n(n - 1)}{2}$) with the number of communicators.

Running parallel unconstrained agents (“swarms”) against a legacy monolith reproduces Brooks’s Law at machine speed. If Agent A is modifying settleBatch to support partner fee withholding while Agent B is refactoring account balance queries in the same shared database module, neither agent holds the other’s in-flight semantic assumptions. Even when Git merges their diffs cleanly without line collisions, their combined changes create semantic merge conflicts, such as Agent B introducing a read-lock query path that deadlocks against Agent A’s new fee-account write lock. Senior engineers end up spending more time untangling multi-agent coordination wreckage than it would have taken to write the change by hand.

4. Context Rot, Finite Attention, and Structural Limits

Why does an unconstrained agent loop rack up ~$1,095 in illustrative downstream costs instead of ~$160 per bounded step (~$510 across a three-step feature), producing sprawling, invariant-breaking diffs in the first place? Because iterative context erosion inside the model runtime directly inflates $C_{\text{rediscovery}}$, $C_{\text{rework}}$, $C_{\text{review}}$, and $(p \times L)$ in our Section 1 unit-economics equation.

Even when a frontier model advertises a 200k-to-1M token context window, its effective attention budget over complex code invariants degrades rapidly as the session fills with grep output, stack traces, and aborted edits. Researchers call this phenomenon context rot.

First coined in Chroma’s technical report Context Rot: How Increasing Input Tokens Impacts LLM Performance and subsequently corroborated across frontier model generations by Anthropic’s Effective Context Engineering for AI Agents, Adobe Research’s NoLiMa benchmark, Microsoft and Salesforce’s LLMs Get Lost In Multi-Turn Conversation, and iterative coding benchmarks such as SlopCodeBench, long-context degradation stems from three structural properties:

• The lexical Needle-in-a-Haystack (NIAH) illusion: Standard NIAH benchmarks show near-flat accuracy across 1M tokens only because they test trivial, direct lexical matching. In both Chroma’s 18-model evaluation and the NoLiMa benchmark (which removes literal keyword overlap between query and target), accuracy decays steeply with length, with most models dropping below 50% of their short-context baseline by 32k tokens when latent semantic inference is required.
• Distractor amplification and coherent haystacks: Legacy repositories are full of topically related distractors: deprecated helpers, similar function signatures, and reverted migration attempts. Chroma’s experiments showed that adding just four distractors sharply accelerates degradation across length, and that models counterintuitively perform worse when the surrounding haystack is logically coherent (such as continuous code and sequential logs) than when sentences are randomly shuffled, because coherent surrounding patterns pull attention away from the target constraint.
• Focused vs. full context (LongMemEval) and iterative workspace erosion (SlopCodeBench): On LongMemEval, Chroma found that feeding models only the focused relevant context (~300 tokens) consistently outperforms passing the full ~113k-token history, though the magnitude of the drop depends on the model family and thinking configuration (for example, 96% focused vs. 90% full, a 6-percentage-point drop, on Gemini 2.5 Pro with thinking enabled, compared with 92% vs. 38%, a 54-percentage-point drop, on Claude Opus 4 non-thinking and 89% vs. 38%, a 51-percentage-point drop, on Claude Sonnet 4 non-thinking). Crucially, even resetting the chat transcript between tasks does not prevent degradation if the codebase itself erodes: in SlopCodeBench (arXiv:2603.24755), each checkpoint runs in a fresh container with no prior conversation history, yet agents still exhibit progressive structural erosion, cyclomatic bloat, and duplicate helpers as they iterate on their own prior workspace commits.

Why does a larger window hurt reliability even as models improve? A language model does not query its context window the way a database looks up an indexed row. As Anthropic’s Applied AI team notes, transformer self-attention computes $n^2$ pairwise relationships across $n$ tokens. Every new token stretches a finite attention budget thinner across the sequence.

Continuing with our settleBatch ledger example and building on Drew Breunig’s taxonomy in How Long Contexts Fail and How to Fix Your Context, here are the four specific mechanisms that inflate those downstream cost variables:

1. Context Poisoning $\rightarrow$ Inflates $C_{\text{rework}}$ and $(p \times L)$
   • Mechanism: Early in a multi-turn session, the agent misreads an upstream webhook handler and writes a false assumption into its working scratchpad or summary: “Deadlock retry and account lock ordering are already enforced upstream by the webhook consumer.” Once that unverified claim enters the context window, the model treats its own note as ground truth and strips the lexicographical account_id .sort() out of settleBatch to “simplify” the function.
   • Economic Impact: Every subsequent turn builds on a poisoned premise: stripping .sort() from settleBatch causes either a 60-minute human rewrite ($C_{\text{rework}} = \$150$) or a production deadlock ($p \times L = \$400$ expected loss).
   • Architectural Fix: Never persist architectural claims into durable agent memory or scratchpads unless they are backed by a deterministic check or validated checkpoint.
2. Context Distraction $\rightarrow$ Inflates $C_{\text{rediscovery}}$ and $C_{\text{review}}$
   • Mechanism: As the agent searches the repository to understand how SettlementEntry objects are constructed, it dumps dozens of tangential files into the session history. Once a trajectory grows past roughly 100k tokens of past actions and log outputs, that history overpowers training-time reasoning. When the harness triggers automatic context compaction to stay under token limits, the model summarizes its own summaries, producing a “photocopy of a photocopy” where general patterns survive but exact constraints (like strict integer minor-unit rounding or lexicographical lock sorting) vanish.
   • Economic Impact: Lossy summaries force repeated repository greps ($C_{\text{rediscovery}} \approx \$25$) and produce imprecise, sprawling diffs that require a 90-minute senior audit ($C_{\text{review}} = \$225$).
   • Architectural Fix: Replace lossy transcript compaction with externalized state on disk and pre-indexed call-graph slices loaded on demand (as used in Anthropic’s tool-result clearing and file-based memory and our harness).
3. Context Confusion $\rightarrow$ Inflates $C_{\text{gen}}$ and $C_{\text{review}}$
   • Mechanism: Teams often connect coding agents to every available MCP server and local CLI tool at once, exposing 40+ tool schemas (issue trackers, cloud deployers, database shells, doc searchers, multiple file editors) in the system prompt. In the Less is More tool-use study (arXiv:2411.15399), a model failed the GeoEngine benchmark when offered all 46 tools, yet passed the exact same task when offered only 19 tools; similarly, RAG-MCP (arXiv:2505.03275) found that tool descriptions begin overlapping above 30 tools and that curating the active loadout yields up to 3× higher tool-selection accuracy.
   • Economic Impact: Bloated tool schemas burn extra inference turns ($C_{\text{gen}} \approx \$15$) and create noisy side-effect edits across unrelated configuration files that slow down human verification ($C_{\text{review}}$).
   • Architectural Fix: Scope the tool surface strictly to the current execution phase: read-only graph retrieval during planning, and minimal file-mutation and local-test tools during bounded implementation.
4. Context Clash $\rightarrow$ Inflates $C_{\text{rediscovery}}$ and $C_{\text{rework}}$
   • Mechanism: Suppose the agent’s first two attempts to add partner fee withholding to settleBatch fail the local test suite. In a single long-running chat loop, those two failed diffs, their compiler errors, and the model’s wrong hypotheses remain in the transcript, competing for attention with the third attempt. As Microsoft and Salesforce researchers showed in LLMs Get Lost In Multi-Turn Conversation (arXiv:2505.06120), when early assumptions and later corrections coexist in history, accuracy drops by an average of 39% across frontier models, and the agent begins oscillating between its previous broken approaches.
   • Economic Impact: The loop pays repeatedly in multi-turn tokens to re-read its own failed diffs ($C_{\text{rediscovery}}$) and produces chimeric code that blends fragments of aborted approaches and has to be untangled by hand ($C_{\text{rework}}$).
   • Architectural Fix: Enforce structured context window rollover, discarding polluted attempt transcripts and starting each bounded step in a clean context window seeded only with the verified plan and current git state.

5. Governance Controls and Economic Trade-Offs

You cannot solve context rot or invariant erosion by pleading with the model in a system prompt (“Please be careful and do not edit tests”). Prompts are probabilistic suggestions; legacy systems require deterministic guarantees. Worse, trying to patch behavioral drift by stacking all-caps warnings into system instructions creates what Breunig calls prompt debt: brittle natural-language rules that regress other instructions and lock the workflow to a single model’s quirks.

To bring the illustrative cost from ~$1,095 for an unconstrained loop down to ~$160 per bounded step (~$510 across a three-step feature), the model must be wrapped in a bounded execution harness. When we run the settleBatch partner-fee change inside a disciplined harness (such as mux and muxcode), five structural controls alter the economics of the run:

1. Pre-Execution Plan & Path Contracts: Before any mutating tool is unlocked, a planning step scopes the change to settlement/settleBatch.ts and settlement/postings.ts. Attempts to touch unrelated upstream webhook handlers are rejected by the host gate before a single line is written.
2. Immutable Test and Contract Locks: During the implementation step, settlement/settleBatch.spec.ts, database migration history, and OpenAPI/Protobuf schemas are protected by the host gate as read-only. When the agent’s naive fee deduction fails UnbalancedLedgerError or expect(receipt.totalDebits).toBe(receipt.totalCredits), the host blocks any attempt to edit settleBatch.spec.ts and runs a property-based zero-sum invariant gate. Forced to satisfy the invariant, the agent splits the primary gross settlement entry into a net merchant credit (primary.amount - feeAmount) and an offsetting partner-fee credit (feeAmount) so the ledger foots to zero.
3. Pre-Indexed Dependency Graph Context: Instead of burning $20 in tokens grepping the repository, mux queries a pre-indexed code graph and injects a compact, 6,000-byte commit-bound context packet containing settleBatch and its two-hop import and call-graph neighbors (lockAccountsForUpdate and buildDoubleEntryPostings), keeping the lexicographical account_id sort invariant immediately visible in high-attention context.
4. Deterministic Host Gates: AST linters, typecheckers, and the characterization test suite execute locally in muxcode after every candidate edit, filtering out broken runs before a pull request is ever opened, and before an independent judge on a different model reviews the change.
5. Structured Window Rollover & Confidence-Gated Sizing: Each phase ($\text{Plan} \rightarrow \text{Implement} \rightarrow \text{Verify}$) runs in a fresh process with a clean context window and a deterministic file handoff, clearing prior attempt transcripts to reduce transcript-level Context Clash and Context Distraction. Meanwhile, Clef (a calibrated decision model) sizes the workflow per task, routing well-bounded single-module edits to fast worker models while reserving full multi-model verification for changes where mistakes could slip past tests.

The table below maps each governance control directly to the cost variable it compresses, alongside its operational trade-off and the telemetry metric used to verify it:

(For a deep dive into the mechanical implementation of these controls, including how muxcode enforces permission cards in its local Rust host, spawns isolated pi RPC processes per task for clean window rollover, and builds commit-bound context packets via mux, see the companion post, Durable Harness for Coding Agents.)

When a harness is uneconomical: Formal contracts, host gates, and multi-stage review are not free. For greenfield prototypes, disposable scripts, or isolated UI experiments with zero shared state and trivial rollback cost, the upfront latency of contract generation and strict path gating exceeds the expected downside risk. Governance pays for itself only where state is persistent, coupling is non-trivial, and senior review capacity is the binding constraint.

6. Rollout Playbook: Adopting Bounded Agents in Legacy Repos

Transitioning an engineering organization from ad-hoc, unconstrained agent chatting to bounded harness execution does not require freezing feature delivery. It requires sequencing adoption around your highest-risk boundaries in four phases:

Phase 1: Instrument Baseline Unit Economics (Weeks 1 to 2)

Before changing workflows, stop reporting vanity metrics like “lines of AI code written” and establish a baseline for Total Cost per Accepted Change:

• Track PR cycle time split by diff size (specifically measuring the queue delay jump when diffs cross 5+ files).
• Track post-opening rework commits and CI failure loops on agent-assisted PRs.
• Audit recent production incidents or near-misses to identify the top three modules where undocumented invariants live (e.g., ledger postings, idempotency claims, settlement batching).

Phase 2: Lock the Boundaries (Weeks 3 to 4)

Before allowing agents to iterate autonomously inside legacy critical paths, harden the verification perimeter:

• Write characterization tests around high-risk invariants (such as double-entry balance footing and lexicographical lock acquisition in settleBatch).
• Configure your agent harness to enforce read-only guards on *.spec.*, *.test.*, schema definitions, deployment manifests, and .git hooks during code-writing turns.

Phase 3: Enforce Plan-First, Small-Batch Execution (Weeks 5 to 8)

Shift developers from open-ended repo chat loops to plan-gated execution:

• Require every non-trivial task to produce a bounded file-path manifest before write tools are enabled.
• Cap implementation steps to diffs that a senior engineer can verify in a single 15-to-20-minute calendar window, and enforce hard WIP limits per reviewer. If a feature requires touching eight files across three services, decompose it into three contract-locked changes.

Phase 4: Pre-Index Context and Route by Confidence (Ongoing)

Compress the rediscovery token tax and scale throughput safely:

• Replace repetitive repo-wide grep loops with pre-indexed dependency and call-graph retrieval so every agent step starts with the exact two-hop neighborhood of the target symbol.
• Use confidence-gated routing to send well-bounded, single-module edits to fast, cost-effective worker models while reserving frontier reasoning models for architectural planning and invariant verification. Expand to adjacent services only if total cycle time and loaded cost per accepted change decrease while change-failure rate and reviewer queue age remain flat or improve.

7. Conclusion

In legacy software engineering, the bottleneck has never been the speed at which developers can type characters into an editor; it is the speed at which the organization can safely verify that a change preserves the system’s invariants.

When we treat coding agents as magical authors and optimize for cheap, unconstrained token generation, we flood our most constrained bottleneck, senior engineering review, with sprawling, complected diffs. Review queues stall, characterization tests get quietly weakened, and production tail risk spikes.

When we instead treat coding agents as a stochastic subsystem with quantifiable downstream externalities, the engineering strategy becomes clear. By wrapping models in deterministic harnesses that enforce pre-execution scope contracts, read-only test locks, pre-indexed call-graph context, and clean window rollovers, we compress rediscovery, rework, review latency, and incident risk simultaneously. The organizations that win with AI in legacy systems will not be the ones generating the most lines of code per minute; they will be the ones shipping the lowest Total Cost per Accepted Change.

Documentation for the contracts, gates, and shared index described here is at muxco.de and usemux.com.