Once you stop prompting a coding agent after every step and switch to loop engineering, the work you were doing doesn’t disappear. Context, tool selection, environmental feedback, evaluation, retry, and stopping all have to move somewhere. Loop engineering is therefore a functional-allocation problem: which jobs belong to the model, which to deterministic software, and which must remain human. Better models expand the choices; they do not determine the architecture.

What follows are the general principles and architecture we’ve developed after ten months of testing and building looping pipelines for reliable, unattended code generation: how and where to add safeguards to catch common AI failure modes while they’re still cheap to correct, and how to build a Learning Loop that performs postmortems on all runs (both failed and successful) to detect new failure modes, design and propose safeguards against them, and make sure existing safeguards continue to earn their time and tokens. We close by picking apart “the model eats the harness” and providing some guidance to help you decide whether your model should eat a piece of your harness just because it can.

Systems-engineering concepts & other defined terms

Below is a glossary of systems-engineering and other terms to ensure we are using the same conceptual framework throughout this article:

• Capability: an outcome that the system as a whole can produce.
• Function: work that must be performed to produce that capability.
• Functional allocation: assigning each function to a system element (NASA calls the human–machine division of this problem “human/systems function allocation”).
• Responsibility: which element is expected to perform the allocated function.
• Authority: what actions or decisions that element is permitted to take.
• Configured system (the agent): the actual models, harnesses, tools, and deterministic components arranged to perform the work—the unit this article analyzes.
• Operating envelope: the tasks, tools, permissions, and conditions within which a qualification or safeguard has been shown to hold.
• Qualification: demonstrating—against known-good, known-bad, and bypass cases—that a check or evaluator can discriminate the condition it is trusted to decide, within a stated operating envelope.
• Requalification: establishing that the reconfigured system still satisfies its requirements.
• Authority separation: keeping evaluation, admission, and acceptance outside the producer’s control. Distinct from error independence, which must be separately earned.

From outside a system we see the system’s capabilities and externally required properties. Inside, we see functions allocated among components. Several components may be capable of performing the same function. That does not mean all should perform it. The allocation must be explicit; responsibility must be supported by appropriate authority; and some authority deliberately remains separated from the producer.

From prompts to loops

Prompt engineering and loop engineering can satisfy the same required capability envelope: pursue authorized coding work through feedback and return a result, an escalation, or an honest stop. The difference is inside the system boundary. With prompt engineering, the developer performs or coordinates nearly every required function. Loop engineering reallocates the ordinary running of that work to the model and harness, leaving authorization, genuine exception resolution, and acceptance with the human. That reallocation can do more than preserve attention. It allows the inner loop to carry feedback across steps without requiring the developer to initiate every transition, making persistent, repeatable, parallel, and unattended pursuit of outcomes possible.

scroll horizontally to compare →

With prompt engineering, the model supplies reasoning and generation, but the developer supplies much of what a modern harness now provides: continuity between steps, relevant context, tool invocation, environmental feedback, evaluation, repair coordination, and the decision to continue or stop. McAteer’s account of the history of the agent harness can be read as a history of repeatedly reallocating those functions as models and harnesses became more capable—from ReAct’s loop expressed through prompting, through the premature autonomy of AutoGPT and BabyAGI, through IDE assistants that returned ordinary coordination to the developer, to modern harnesses that returned the loop to the model. A loop does not improve the model’s per-step judgment: when that judgment was brittle, removing the human did not produce dependable autonomy; it gave early mistakes more opportunities to shape every later action. Progress did not come from moving every function into software as quickly as possible. It came from finding allocations that matched the capabilities of the components available at the time.

Coding was particularly well suited to this shift. Repositories, compilers, tests, linters, and version control already produce machine-readable signals after an action. A harness can execute the action, preserve its result, and return feedback from outside the model’s own judgment; the model can use that feedback to revise its next move. The harness made a different allocation of the inner-loop work practical, taking over functions the developer had previously performed manually and giving the model a controlled way to perceive and act on the development environment.

Osmani describes the resulting transition succinctly: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.” Loop engineering moves ordinary inner-loop orchestration from the developer into software the developer designs. The human remains responsible for authorizing the work, resolving genuine exceptions, and accepting the result, but no longer drives every ordinary transition. The loop-engineered system typically also provides the human with persistence, repeatability, parallelism, and unattended execution.

A loop is a control-flow pattern, not an execution topology. The system executing its body may be organized as a single agent, a linear pipeline, or a graph of cooperating agents and deterministic components. In the architecture described below, the model and harness together implement the Construction Loop. The model reasons about the code and selects actions; the harness preserves state, executes tools, returns repository, compiler, and test feedback, enforces bounds, and controls permitted transitions. Together, they perform and coordinate the inner-loop work without requiring the developer to compose every subsequent prompt.

The advantage of a loop is not repetition itself. It is feedback-driven adaptation. Each action can reveal information the model did not have when the task began: a repository search changes its understanding of the design, a compiler error invalidates an implementation choice, and a test failure identifies another constraint. The system can use those observations to revise its plan and choose another action. This makes loops useful for work whose path cannot be specified in advance and whose first attempted solution is unlikely to be final.

For coding, that changes the unit of delegation from generating a suggestion to pursuing an outcome. The developer authorizes a set of obligations; the loop pursues them until it produces a conforming candidate, reaches an honest stop, or escalates. That process can run repeatedly, on a schedule, or in parallel with other work—the system, not the developer, carries feedback from one step into the next.

Although we call these loops, the closer comparison, based on the caller’s experience, is async/await. The developer supplies inputs and invariants, yields control, and waits for a result. Inside that call, the loop differs from a conventional for loop in several ways:

• the number of attempts is not known in advance;
• progress is established through evaluation, not guaranteed by iteration;
• an attempt may entirely replace the previous candidate rather than accumulate on it; and
• the loop returns a conforming candidate, an escalation, or an honest stop without the developer continuously driving every transition.

The same mechanism that lets a loop recover from an error can also let an undetected error shape every subsequent action. Loops extend capability by allowing earlier results to influence later decisions; whether that produces recovery or compounding failure depends on the per-step reliability of the components and on the obligations, feedback, safeguards, and stopping conditions surrounding them.

The responsibilities outside construction remain as well. Authority-separated evaluation determines what the prescribed evidence establishes about the exact candidate; a deterministic controller decides whether to repair, escalate, or stop; and an admission gate determines whether the candidate may advance to human review. The developer is removed from ordinary iteration, not from defining the work, resolving exceptions, or accepting the result.

Once ordinary inner-loop work is delegated to a configured system rather than coordinated response by response, the model alone is no longer a sufficient unit of analysis. The relevant unit is the configured system: the actual models, harnesses, tools, and deterministic components arranged to perform the work. A loop does not change the base model itself, but it can dramatically increase system-level capability by supplying action, observation, durable state, and feedback-driven adaptation. From outside the system boundary, what matters is whether the configured system reliably discharges its obligations. Inside that boundary, allocation matters greatly: moving a function from deterministic software into probabilistic behavior changes how it fails, how those failures can be observed, and what evidence is needed to trust the result. Reallocation is a design decision—not progress by definition—and should be judged by the resulting system’s capability, reliability, observability, and maintainability. We return to this question, with evidence, in “Why the model does not simply eat the harness.”

Building a better inner loop therefore means building a better system for performing, coordinating, constraining, and observing the inner-loop work—not merely using a more capable model.

Loops do not automatically preserve attention

An overwhelming percentage of developers are using AI to write code (80%, more in other estimates). The Sonar State of Code Developer Survey found that ~42% of committed code is now AI-generated or AI-assisted, and that while 96% of developers do not fully trust that AI-generated code is functionally correct, only 48% always verify AI-assisted code before committing. The same survey found that 61% agree that “AI often produces code that looks correct but isn’t reliable.” Verifying more plausible-looking code is more difficult and more time-consuming. AI has made code generation fast and cheap, but not trustworthy.

Adding reviewers can increase verification capacity, but not at the same rate as automated code production, and reviewers increasingly begin without the contextual advantage of having written the code themselves. That mismatch has moved the software development lifecycle bottleneck downstream to verification and understanding, and AI-generated code removes even the familiarity its author once brought to review—widening what Osmani, building on Margaret-Anne Storey’s “cognitive debt”, calls comprehension debt.

The attention dividend is real but conditional. A poorly engineered loop consumes more attention than prompting ever did—it wanders longer, generates more code, hides failures, and hands the developer a larger verification problem than the one it replaced. Loop engineering may also increase comprehension debt: removing the developer from the iteration path removes the familiarity gained by watching the solution develop. In favorable cases, reviewing one admitted candidate and its evidence is a more productive use of attention than following every intermediate attempt, but a safeguard preserves attention only when the human effort it avoids exceeds the effort required to operate it and resolve its false signals. It is not write once and forget; it is engineer for reuse, then observe and requalify as the system changes.

The architecture described below concentrates human judgment at two deliberate boundaries:

1. pre-run: define the obligations and the required evidence,
2. pre-merge: review the admitted candidate and its evidence, then accept, reject, or redirect it.

At the second boundary, the reviewer consumes the evidence package against the obligations—trusting qualification rather than re-verifying the run. That trust, earned by the machinery below, is what keeps this boundary from becoming the old bottleneck with extra metadata.

The contract deliberately leaves room the producer may decide within; ordinary discovery—an ambiguous detail, an unanticipated case—resolves inside that room without ending the run. Re-versioning is the exception path, not the normal one. Occasionally, a loop raises an issue that exceeds that room and requires human resolution. Some resolutions allow the existing run to continue within its existing authority; others end that run and require a newly authorized contract version or a stop. When construction reveals that the obligations themselves are wrong, the exception path is doing its job—and repeated trips through it are the signal that the work was dispatched before its design was ready for an unattended loop. Humans generally should not be involved inside the ordinary construction cycle.

Not every task deserves this machinery. A loop earns its cost when the work is long-running or repeated, the obligations are clear enough to support evaluation, and late discovery would be expensive or difficult to reverse. Direct collaboration and ordinary review may be cheaper for exploratory work, unresolved design questions, and small reversible changes for which inspecting the diff costs less than preparing a contract and evaluation package.

Osmani argues that human judgment does not leave the software factory; it relocates—to intent, system design, verification, and acceptance. This article explores the engineering question that follows: what responsibilities must the system assume between those boundaries, and what evidence is sufficient to return the work to human attention? The sections that follow answer with specific machinery: explicit obligations as the stopping condition, nested Construction and Conformance Loops, separated evaluation and admission authority, evidence bound to the exact candidate, qualified safeguards, and honest stopping.

Engineering Recommendations

Our experiences building code-generation loops have led us to the following general principles, which drive the architecture described below.

General principles

Five principles underlie the architectural decisions:

1. Use deterministic control to own the process. A deterministic controller should own authorized inputs, stage order, budgets, retries, state transitions, effects, logging, and terminal outcomes. A model may recommend a next action, but it should not decide whether its own recommendation is authorized or give its own completion claim terminal effect.

2. Use deterministic mechanisms wherever the proposition is mechanically decidable. Prefer schemas, precondition checks, permission boundaries, type checks, tests, artifact hashes, diff-scope checks, budget limits, and explicit state machines. AI judgment should not be used where a deterministic method can establish the same proposition reliably.

3. Constrain the AI judgment that remains. Give each model invocation a bounded responsibility, purpose-specific context, only the tools and permissions it needs, and a clear definition of done. Validate its inputs before invocation and validate its outputs before they can affect shared state or another stage. Treat every AI output as a proposal: a prompt can describe an output contract, but it cannot enforce the identity, shape, scope, authority, or permitted consequence of what comes back. Continuity should live in versioned external state rather than in an accumulating conversation that gradually becomes an unofficial source of truth.

4. Separate construction, evaluation, control, admission, and acceptance. A producer constructs a candidate. An evaluator determines what the prescribed evidence establishes. The controller selects an authorized transition. The admission gate determines whether a candidate is eligible for human consideration: it checks that the evidence package is bound to, and complete for, the exact candidate, and a binding failure returns the candidate for re-evaluation rather than admitting it. The human decides whether to accept, reject, or redirect it—merging or deploying what is accepted. Combining these responsibilities may save an invocation, but it also removes the separation that makes the resulting evidence informative. A second model call is not independent merely because it is a second call.

Separating these responsibilities, enforced through permission boundaries, provides authority separation—not error independence. Keeping the evaluator and admission decision outside the producer’s write authority prevents the producer from grading or admitting its own work. It does not make the evaluator’s mistakes uncorrelated with the producer’s. Error independence must be earned through evidence produced by a meaningfully different mechanism: execution in an externally controlled environment, adversarial or withheld cases, differential or metamorphic checks, a different model family or context, or authorized human judgment. Each can reduce a particular shared-blind-spot risk; none makes an evaluator universally independent.

5. Keep human authority at the outer boundaries. Humans authorize the contract before construction, resolve genuine exceptions the configured system cannot decide honestly, and make consequential acceptance decisions afterward. The loop can construct candidates, collect evidence, and admit work for review. It cannot accept its own work on the humans’ behalf.

The architecture

Before construction begins, the development team defines the intended behavior and outcomes as explicit obligations in a Design Conformance Contract, or just a Conformance Contract. The contract freezes what must be true and what evidence will be accepted as establishing it. It does not tell the Construction Loop what candidate it must produce.

The Construction Loop investigates, implements, checks, and repairs until it has a candidate it believes is ready to submit. It then seals that candidate against further mutation and submits a construction record identifying what it claims to have produced. Sealing preserves currentness; it does not authenticate the producer’s claims. The surrounding Conformance Loop acquires the candidate independently, calculates the identity of what it actually received, treats any mismatch as an invalid evaluation, and only then evaluates the candidate against the frozen contract. It routes violated obligations back for repair, stops or escalates when it cannot proceed honestly, and admits only a conforming candidate for human review. The Learning Loop operates later, across completed runs, and may propose changes for future versions without silently changing a run already in flight.

Conformance does not compel acceptance. A candidate can satisfy every obligation in the Conformance Contract and still be rejected by the team. Seeing the solution made concrete may reveal that it is materially different from what the team wanted, that the design was not sufficiently developed, or that the contract omitted or misstated an important obligation. Conformance establishes that the candidate satisfies the authorized contract—not that the contract perfectly captured human intent.

Rejecting a conforming candidate does not by itself require a new contract: the team may redirect the work for another attempt under the unchanged obligations. Only when the change of mind reaches the contract itself—an obligation was wrong or missing, or the accepted evidence was inadequate—must the contract be corrected, reauthorized, and versioned before construction resumes. The team should not quietly reinterpret the existing contract or record a conforming candidate as nonconforming merely because seeing it changed their minds.

A green signal is not yet evidence

These principles rely heavily on types, tests, builds, static analysis, and other familiar engineering signals. Their familiarity should not be mistaken for adequacy. A passing signal becomes useful evidence only when:

• the check is capable of detecting the failure relevant to the obligation;
• its result belongs to the exact candidate being evaluated;
• the controlling inputs, environment, and check version are known;
• the producer could not silently bypass, weaken, or replace the check; and
• the raw result and its provenance are preserved for authority-separated evaluation.

Not every obligation should be forced through the same kind of evaluation route. In our design, each obligation declares one authorized route: a deterministic check when the proposition is mechanically decidable, a qualified model assessment when semantic interpretation is necessary and machine judgment is permitted, or a named human judgment when the question is genuinely subjective or carries authority that a model cannot exercise. Those routes are not interchangeable conveniences. A model cannot convert a human-judgment obligation into machine conformance, and a repeatable check is not useful merely because it is deterministic.

Before a run, the concrete checks, fixtures, model configurations, environments, and evidence requirements are assembled outside the producer into an evaluation package. That package is exercised against known-good, known-bad, and relevant bypass cases, then human-authorized and frozen. For task-generic safeguards—scope, receipts, binding—that qualification amortizes across runs. Task-specific obligations may have no known-good subject before the work exists; discrimination then comes from mutations of the candidate itself, differential or metamorphic checks, or an authorized route to named human judgment—a real cost, not a hidden one. The Conformance Loop executes the authorized package; it does not improvise a more convenient evaluator after seeing the candidate. Nor can it qualify itself. Qualification is a bounded claim that a particular evaluation package can discriminate the relevant conditions in a particular operating envelope—not a declaration that the evaluator is universally trustworthy. Outside that envelope, the honest result is that the obligation is undetermined: the evaluation was invalid, the evaluator unsupported, or the judgment still pending with a named human.

A green build can establish that a build completed under a particular configuration. It cannot, by itself, establish that the resulting behavior matches the intended design. A passing test suite may be genuine but non-discriminating. A check may prove a property that no obligation requires. A model may repair the check instead of the code. These are reasons to qualify checks, not reasons to abandon ordinary engineering signals.

A larger pile of signals does not solve the problem either. Unless each signal is connected to a proposition it is capable of establishing, the pile demonstrates activity rather than conformance.

Put each safeguard where its failure is cheapest to catch

The figure makes an ordering claim rather than assigning exact costs, and the ordering is marginal cost per defect caught; whether the qualification apparatus amortizes at all is the earlier question of when a loop earns its cost. A defect is generally cheapest while the relevant state is still in context, the candidate is still mutable, and repair remains part of the normal construction path. Once the candidate crosses the admission boundary, a developer must reconstruct context and determine whether the evidence can be trusted. After acceptance, the same defect may require incident response, downstream repair, renewed review, and reversal of an earlier decision.

The practical rule is therefore:

Catch a failure at the earliest boundary that can recognize it reliably, while preserving an authority-separated boundary that determines whether the finished candidate deserves human attention.

The caveat “reliably” matters. An early check that cannot discriminate, can be bypassed by the producer, or proves the wrong property does not save attention. It creates false confidence earlier.

Birgitta Böckeler describes two useful dimensions of the surrounding machinery. Guides are feedforward controls intended to prevent a bad result; sensors are feedback controls intended to detect one and enable repair. Both may be computational—tests, types, linters, structural rules—or inferential, such as semantic review. Addy Osmani describes the broader effect as back pressure: the system should expose enough trustworthy resistance that autonomy cannot outrun verification.

Agent failure is not synonymous with task failure. A run can finish successfully after several serious mistakes because a safeguard, a test, or a supervising human caught each one—and continuous supervision experiences those catches as conversation, not as failure recovery. Our additional step is to begin with an empirical failure portfolio. We currently track more than thirty recurring failure modes across context, specification, scope, execution, coordination, evidence, evaluation, and long-running trajectories. That portfolio is neither an exhaustive taxonomy nor a checklist to install on every run. It is a body of observed failure knowledge from which task-relevant safeguards can be engineered.

The transformation runs: observed failure → required invariant → control mechanism → placement → response → retained evidence → residual uncertainty.

The producer also sees the obligations and most visible checks before it begins. That creates a specification-gaming problem: a capable optimizer can satisfy the measured proxy without producing the behavior the team intended. This is Goodhart’s law applied to the stopping condition. The possible evasions are not enumerable, so a failure portfolio cannot promise complete protection. Known-good, known-bad, bypass, and legitimate-variation cases are useful because they ask whether a safeguard discriminates—not merely whether the current candidate passes. Withheld cases stay discriminating only if evaluation inputs are read-isolated from the producer; a withheld case that fires becomes visible in the repair packet and is treated as visible thereafter, and replenishing withheld discriminating power is Learning Loop maintenance. They reduce known proxy failures without proving that no unknown one remains.

Scope drift supplies a simple example. Restrict the writable surface, compare the final diff with the authorized scope, retain the resulting manifest, and block or repair unauthorized changes before the candidate advances. More difficult failures occur when the safeguard itself produces a convincing but non-discriminating green signal.

Consider a candidate that passes every test written during construction, even though those tests do not discriminate between an implementation that satisfies the relevant obligation and one that does not. They may exercise only the happy path, restate the implementation’s behavior, or stop at a mocked boundary before the intended system effect occurs. The failure is not that the tests did not run. The failure is that their green result does not establish the proposition for which it is being offered as evidence.

Construction tests and conformance checks serve different purposes. A producer-written test can provide fast feedback and help the Construction Loop repair its work. It does not become authoritative merely because it passes. When a test result is offered as evidence that a contract obligation has been satisfied, the mapping and the check must be qualified outside the producer’s authority.

• Observed failure: The candidate passes its construction tests, but a test offered as evidence does not discriminate between code that satisfies the relevant obligation and code that does not.
• Required invariant: No test result may discharge a contract obligation unless the exact check has demonstrated relevant discriminating power. Passing must say something about the intended behavior or impact, not merely confirm the implementation author’s expectations.
• Control mechanism: Bind each load-bearing conformance check to a specific obligation and qualify it against independently selected cases. Where practical, include a known-good subject, a known-bad subject containing the relevant defect, and a mutation that weakens or bypasses the intended behavior.
• Placement: Keep producer-authored tests inside the Construction Loop. Place qualified conformance checks and their expected outcomes outside the producer’s write authority. A test proposed during construction cannot contribute authoritative evidence unless it is qualified outside the producer’s authority first.
• Response: A construction test may remain useful for repair even when it is not conformance evidence. A non-discriminating conformance check cannot satisfy the obligation; it routes to another evidence method, test repair and requalification, or an honest stop when the obligation cannot be evaluated reliably.
• Retained evidence: Preserve the exact check version, subjects, environment, outputs, expected reasons, and candidate identity so the evaluator can determine what was actually established.
• Residual uncertainty: Even a check that catches the known defect may omit an unanticipated path, interaction, or consequence. It establishes only the behavior it has demonstrated an ability to discriminate.

This is not a theoretical concern. EvalPlus expanded HumanEval’s test cases approximately eighty-fold and found substantial amounts of previously undetected incorrect code, reducing reported pass rates by as much as 19.3–28.9%. Weak tests had been admitting false success. EvalPlus But more or stricter tests are not automatically better. OpenAI later audited 138 SWE-bench Verified tasks that a frontier model failed inconsistently and found flawed tests that rejected functionally correct submissions in at least 59.4% of that audited subset. Some tests also required behavior the task never specified. SWE-bench Verified audit A deterministic oracle is repeatable; it still has to be qualified to decide the proposition we give it.

Before an adverse result is routed to construction, the system must determine whose failure it is. That classification is itself allocated: deterministic rules decide what is mechanically decidable—binding checks, environment attestation, exhausted bounds—and everything else escalates to a named human. A candidate shown not to satisfy an obligation belongs on a repair path. An invalid evaluation should be corrected or rerun without changing the candidate. An unsupported evaluator or environment requires an evaluation-capability decision. A missing authorized human judgment remains pending with the named human, while a gap in the contract returns to design. A red signal does not, by itself, establish that the code is wrong.

This classification matters because sending every red result back to the producer encourages it to alter correct code until it satisfies a broken measuring apparatus. When the candidate really is defective, the repair packet should bind the violated obligation and evidence to the artifact and earliest construction stage that owns the problem. Repair begins a new preserved attempt. Changed bytes create a new candidate identity and require fresh evaluation; evidence from the earlier candidate does not transfer. A repeated candidate-and-failure pair, oscillation, lack of progress, or an exhausted bound should end in an honest stop rather than another hopeful retry.

The same method applies across the failure portfolio. Unverified claims that a command ran call for execution receipts bound to the exact candidate. Scope drift calls for external write boundaries and diff checks. Evaluator tampering calls for controlling inputs outside the producer’s write authority. Retry laundering calls for preserving every attempt instead of selecting the convenient green one.

These controls should be enforced as close to the failure as the trustworthy signal permits. Telling an agent to run a check is guidance. A runner or hook that executes the check, records the result, and prevents an unauthorized transition is a safeguard. Böckeler reports the same distinction in practice: instructions to run her maintainability sensors were unreliable, while enforced structural rules exposed violations and supplied useful repair feedback. She also found that additional sensors could produce irrelevant findings and provoke over-engineering, which is why safeguard cost and false positives must be measured rather than assumed away. Maintainability sensors for coding agents

We should not respond to a catalog of thirty-plus failures by accumulating thirty-plus permanent controls on every task. Safeguards consume tokens, compute, time, maintenance, and attention. They can conflict, become stale, or move complexity elsewhere. Each run should carry a small core of structural controls plus the additional safeguards justified by its task, tools, and permissions—its operating envelope.

Finally, a stage-local safeguard is not conformance authority. The qualified test above can still prove the wrong thing. A real execution receipt can faithfully record an irrelevant command. An inferential reviewer can share the producer’s blind spot. Construction safeguards make known failures cheaper to prevent, detect, and repair; the authority-separated Conformance Loop still determines whether the complete evidence establishes the frozen obligations. That distinction is exactly what the claim that “the model eats the harness” tends to erase.

The Learning Loop

Every run should therefore leave behind more than its final code. Its run record should preserve the candidate identities, relevant inputs, check and model versions, raw results, repair packets, retries, evaluator findings, controller transitions, human dispositions, and—when available—later outcomes.

Across completed runs, the Learning Loop can use those records to identify recurring failures that are not yet represented in the failure portfolio and propose safeguards that would detect, prevent, or contain them earlier. It can also determine whether installed safeguards are running, which failures they catch, which failures escape them, how often they falsely block legitimate work, and how much repair and human attention they save.

A safeguard that stops firing has not necessarily become unnecessary. The underlying failure may have disappeared, but the safeguard may instead be stale, broken, bypassed, or no longer exposed to the behavior it was designed to detect. Retirement requires evidence that the failure is no longer recurring within the intended operating envelope, that the safeguard still detects preserved bad and bypass cases, and that removing it does not increase escapes or human correction cost. That evidence can be gathered without exposure: run the safeguard observe-only, or stage its removal with escape monitoring and rollback.

The Learning Loop has failure modes of its own. A persuasive post-mortem can launder a plausible diagnosis into a permanent rule without establishing what actually caused the failure. One memorable incident can produce a safeguard overfit to that exact example. Controls can accrete until they become a second brittle system, while successful catches are remembered and legitimate work rejected by false blocks disappears from view.

Before an observed failure earns a permanent safeguard, retain the raw subject, a minimized reproducer, the expected outcome, and a causal discriminator showing that the proposed mechanism actually matters. Exercise the proposed safeguard against known-good, known-bad, and bypass cases, then replay the wider suite to detect regressions and false blocks. Agent summaries can help explain the record, but they do not replace it.

The Learning Loop ends with proposed changes. A human must authorize those changes, create a new version of the configured system, and require scoped requalification before that version is used. There is deliberately no path by which cross-run learning can silently modify a run already in flight. The Learning Loop is also subject to the same balance it enforces: retention depth, postmortem cadence, and authorization overhead are configured choices—tiered or sampled where full depth does not pay—judged, like any safeguard, by whether they earn their time and tokens.

The Learning Loop therefore does not “teach” the running agent by quietly rewriting its instructions. It turns observed successes, failures, escapes, false blocks, and repair costs into explicit proposals for the next version of the configured system. The next question is what happens to safeguards—and to the rest of the harness—as models improve.

Why the model does not simply eat the harness

“From prompts to loops” argued that the unit of analysis is the configured system and that allocation inside it matters. “The model eats the harness” is the strongest challenge to that claim: as models improve, work once done by prompts, procedural scaffolding, or deterministic routing can move into the model. Some of it should. A more capable model can make one part of the harness thinner while making another part more important. This section asks the opening’s question at the second boundary: as models improve, which functions belong in the model, which in deterministic software, and which must remain human.

There is an important caveat to the slogan. Logan Kilpatrick sometimes uses model broadly enough to include provider-hosted tools, execution environments, orchestration, and other machinery absorbed into the native product. A provider can absorb a deterministic mechanism without converting it into probabilistic model behavior. That changes the product boundary, not necessarily the mechanism. In this section, “the model eats the harness” refers more narrowly to model-dependent behavior replacing a function previously performed outside the model. Why the Model Eats the Harness

Capability does not determine allocation

The system-level question is not whether the model can perform a function, but whether model-directed execution improves reliability, failure detectability, recoverability, cost, and inspectability.

AWS states the deterministic-first principle plainly in its guidance for agentic systems: “Use deterministic execution logic unless AI is needed.” If the harness already performs a required function through ordinary code, the model’s ability to perform that function is not, by itself, a reason to replace code that performs it cheaply, predictably, and reliably.

There is real evidence that stronger models are absorbing some scaffolding. A 2026 analysis of 9,374 coding-agent trajectories found that the underlying model was the largest driver of both results and behavior, while the performance differences among agent frameworks shrank with newer model generations. Framework prompts still affected tactics, but less as models improved. Beyond Resolution Rates

There is equally real evidence that the harness still matters. Harness-Bench evaluated 5,194 trajectories under shared tasks, environments, budgets, and evaluators and found substantial differences in completion, process quality, efficiency, and failure behavior across model–harness pairings. Its conclusion is the one that matters here: agent capability should be reported at the configured-system level rather than attributed to the base model alone. Harness-Bench

Both results can be true. Better models can make particular prompts, interfaces, and recovery procedures obsolete. Harness design still determines whether the remaining capability is exercised within useful bounds and produces verifiable work.

Structural controls and transient safeguards

The strongest economic version of “the model eats the harness” is not that all control disappears. It is that bespoke scaffolding loses value as models and agent platforms absorb its functions. Some of that should happen.

Structural controls protect responsibilities that do not disappear with model capability: binding evidence to the exact candidate, keeping evaluation and admission outside the producer’s authority, enforcing permissions and resource limits, stopping bounded work, preserving failed attempts, and leaving acceptance with humans. A platform may eventually provide these controls as standard infrastructure instead of each team building them. The implementation can become thinner without moving those responsibilities into the producer.

McAteer, writing at Latent Space, reaches the same boundary from the other direction: keep deleting everything the model can absorb, and what remains—permissions, identity, trust, legibility—is the harness as the interface to human attention. A model that absorbs permissions has dissolved them. The same dissolution applies to every authority in this architecture. A producer that absorbs the authority to define success dissolves the contract. Absorbing the authority to judge evidence dissolves independent evaluation. Absorbing the authority to admit its own candidate dissolves the admission boundary. Absorbing the decision of when humans should care converts the attention interface into another producer-controlled claim. These are not capabilities the model has not yet learned; they are relationships deliberately established outside the producer.

Transient safeguards address the particular weaknesses of a model, tool, or workflow: a brittle output-format check, a prompt workaround, or a repair rule for a failure that later models no longer exhibit. These controls should be eaten when requalification shows that removing them does not increase failures, escapes, or human correction within the intended operating envelope. The Learning Loop is partly a retirement mechanism for this category, not a ratchet that preserves every workaround forever.

Long-running reliability is a system property

This distinction becomes more important in a long-running loop. A coding agent must repeatedly interpret an obligation, inspect state, choose a tool, supply valid arguments, understand the result, modify an artifact, preserve progress, test the change, recognize failure, and decide whether to continue. A model may be capable of each activity in isolation and still encounter a failure during the complete trajectory, fail to recognize it, and carry it into every subsequent decision. Performing a task once demonstrates possibility; exercising every required capability at the right time, across a long and variable trajectory, without allowing an undetected failure to propagate, is a property of the configured system.

Where particular obligations require exact results, dependable operation requires more than a generally capable model. It requires a model whose behavior has been empirically characterized within the intended operating envelope, surrounded by a harness designed around the limitations actually observed. “Well understood” does not mean understanding the model’s internal cognition. It means knowing enough about how the model, as configured, behaves to bound its role and detect when the system cannot establish the required result.

This is why self-correction does not make external feedback obsolete. Models often can repair a defect once a trustworthy signal identifies it. They are much less dependable at locating their own mistakes without that signal. Tyen and colleagues found this separation across five reasoning tasks: models struggled to locate errors but corrected them much more successfully when given the error location. Huang and colleagues found that ungrounded attempts at self-correction could even turn correct answers into incorrect ones. These are bounded reasoning studies rather than repository-scale coding trials, but they support the architectural distinction between producing a candidate and supplying a trustworthy error signal. Tyen et al., Huang et al.

A successful agent run therefore does not establish that the model operated without failure. It may establish that the configured system detected, contained, and repaired the failures well enough to finish: compilers, tests, schemas, tool output, environmental observations, and authority-separated evaluation do part of the epistemic work. When only the outcome is preserved, model reliability cannot be distinguished from harness effectiveness—or which safeguards made the success possible. Asking the producer to reconsider its answer may improve the answer; it does not manufacture an independent source of truth.

The Remote Labor Index provides a useful end-to-end example. When it launched, the best agent completed 2.5% of 240 real freelance projects to a standard that human evaluators believed a paying client would accept. Eight months later, the leading configured system reached 15.8%. Both the models and the scaffolding changed, so the comparison cannot tell us how much of that improvement came from either one. It demonstrates rapid configured-system progress—and that even the leading system still failed to produce an acceptable deliverable on most projects. The newer configurations included mature industry scaffolds, computer use, long execution budgets, professional applications, and a worker–critic loop. RLI update

The same experiment also exposed the evaluation problem. An automated judge calibrated on earlier systems overestimated the absolute success of configurations built on two newer models by approximately 2.9 and 2.3 times compared with human evaluation. It ranked them reasonably well while substantially overstating whether their deliverables were professionally acceptable. Improving the “worker” changed the evaluator’s failure surface too.

A model upgrade changes the failure surface

Moving a function into the model is therefore not a monotonic sequence in which harness code simply disappears. It is a boundary change:

• Model-directed tool selection may replace fixed routing while requiring stronger permission checks, argument validation, tracing, and rollback.
• Model-generated tests may replace hand-authored checks while requiring test-quality qualification and evidence the producer cannot silently weaken.
• Model-managed context may replace explicit context assembly while requiring provenance, currentness, and omission detection.
• Model-directed retry and recovery may replace fixed workflows while requiring hard budgets, nonprogress detection, preserved attempts, and deterministic stopping.
• Model self-evaluation may reduce routine human review while requiring calibration, evidence from other mechanisms, and protection against false admission.

Replacing the model changes the agent even if every other component remains frozen. Requalification must therefore ask not only what the new model can do, but which previous failures disappeared, which persisted, which moved, which new failures appeared, how visible they are, how far they can propagate, and whether the installed safeguards still recognize them.

I do not claim that every new model fails as often as the model it replaces. Aggregate failure rates are falling on many benchmarks. The narrower claim is both stronger and more defensible: better aggregate performance does not establish that a particular failure mode has disappeared. It may have become less frequent, moved to different tasks, or become harder to detect. In our own work, newer frontier models have not eliminated the failures that motivated the surrounding safeguards. Their incidence and appearance change, but we have not seen enough evidence to assume that a safeguard needed by last year’s model is unnecessary for this year’s.

Some functions should move inward as models improve. Others remain cheaper, safer, or more legible when implemented deterministically. McAteer’s deletion criterion—measure harness progress by how much machinery can be removed while capability holds—is the strongest version of the absorptionist view. His destination is right; his metric is wrong: score parity is not assurance parity. A configured system can keep its task-completion score after a safeguard disappears while becoming worse at detecting failures, respecting authority, preserving evidence, or stopping honestly. If the harness’s successful interventions are invisible, deleting it can appear safe precisely because it worked.

The goal is neither to preserve nor to delete harness code. It is to compose the most capable, reliable, and maintainable configured system for the intended operating envelope. Capability is only one dimension of that evaluation: moving a function into the model may improve flexibility and reduce maintenance while making failures harder to detect or behavior harder to bound; keeping it in deterministic software may improve predictability while adding complexity, brittleness, and maintenance cost. Neither direction is inherently progress.

Model capability expands the available design space; it does not select the best system architecture.

The safeguard principle follows: add, retain, redesign, or remove a safeguard when evidence shows the resulting configured system offers a better balance of capability, reliability, maintainability, cost, and human attention within its intended operating envelope. The burden of proof sits with the change, not with the incumbent—the incumbent is the currently qualified configuration, not the harness. Continuous monitoring of that incumbent is the Learning Loop’s job; the burden here governs the decision to reconfigure.

Osmani suggests that verification can earn greater autonomy in later runs and that constraints should change as trust changes. I agree with the direction, but an increase in autonomy changes the configured system’s operating envelope. Prior success is evidence to evaluate, not standing authorization: the new configuration should be requalified before the changed boundary is relied upon.

That turns “the model eats the harness” from a prediction into a configuration hypothesis: each proposal to add, remove, or reallocate a function claims that the new allocation yields a better system while preserving its required capability envelope. Testing that claim requires the run records introduced with the Learning Loop—and a more systematic way to compare configured systems.

---

The evidence needed to make those comparisons does not yet exist in a form most teams can use. What that shared infrastructure should look like—an open failure portfolio and requalification suite for configured systems—is the subject of a follow-up article. A shared portfolio can supply candidate failure modes and discriminating cases; each team still qualifies them within its own operating envelope. How the obligations themselves are designed—the process that decides what a contract should contain and when work is ready for dispatch—is deliberately out of scope here. The readiness criterion above is retrospective as stated; making it predictable ex ante is part of what that process owes.

This article was written the way it says software should be built. I set the goal and the obligations; AI agents drafted candidates, ran research, and argued with each other about structure; every empirical claim was verified against archived primary sources and is enforced by a publish gate that refuses unverified numbers; I reviewed, redirected, and accepted every candidate that survived. I work with AI all day, every day, to amplify and speed up my thoughts. It would have been strange to write about it any other way.