What a Reliable Coding Agent Must Prove

The question running through this series has been deliberately narrower than “How do we make language models smarter?” It is this: what evidence should an AI programming agent produce before a person or a system trusts the result? The answer is not a longer prompt and not a single universal test. A reliable coding agent needs a contract stack in which human intent, executable behavior, runtime properties, candidate selection, and collaboration each have an observable boundary.

That conclusion follows from the different failures exposed by the evidence. Static code can look plausible while interfaces are misunderstood. A benchmark can reward familiarity if its problems are not fresh. A repository harness can expose a bug while still missing a dependency or edge case. A performance score can reward a narrow optimization. A verifier can execute tests that do not distinguish candidates, or judge a trajectory by its confident language. A long translation can compile while diverging at an intermediate function. A patch can pass while violating the standards and working relationship of the team that must maintain it.

Reliability therefore means more than “the final code passed.” It means that the system has made the important properties visible at the point where they matter, has calibrated the claim to the evidence, and has kept a human in control where the specification cannot responsibly decide.

A minimum sufficient contract stack

The right design is layered, but it should not become an argument for measuring everything. Each layer earns its cost when it observes a property that the previous layer cannot establish and when the decision depends on that property. A small bug fix may need a regression test and a human review. A low-level translation may need dynamic observations and per-function equivalence. A performance change may need a workload and a resource comparison. The minimum sufficient stack depends on the task.

classDiagram class IntentContext { goal constraints project_context } class ExecutableChecks { correctness regression equivalence } class QuantitativeChecks { performance resource_target } class RuntimeEvidence { dynamic_properties per_step_observations } class CandidateVerification { trajectory_signal patch_selection } class HumanJudgment { collaboration tradeoffs approval } IntentContext --> ExecutableChecks : defines target ExecutableChecks --> QuantitativeChecks : extends when needed ExecutableChecks --> RuntimeEvidence : exposes hidden behavior RuntimeEvidence --> CandidateVerification : informs selection CandidateVerification --> HumanJudgment : presents bounded result IntentContext --> HumanJudgment : supplies values and context

The first layer is intent and context. A prompt, task description, project rule, or conversation tells the agent what a person wants, which constraints matter, and what kind of work is being done. It can identify priorities that are difficult to infer from code alone: preserve a local convention, avoid unrelated refactoring, ask before making a consequential choice, or favor maintainability over a small short-term gain. This layer is indispensable because an executable check cannot invent the purpose of the task. It can only test a property someone has chosen to encode.

But intent is not proof. The next layer turns the most important functional requirements into executable checks. Fixed tests, generated inputs, fail-to-pass regression tests, and equivalence harnesses make selected behavior observable. The choice among them should follow the failure surface. If the risk is a wrong result on an edge case, exercise the edge case. If the risk is breaking existing behavior, compare the candidate with a reference or run regression tests. If the function depends on a repository environment, preserve enough context for the test to exercise the interface that the agent must understand.

This layer should also state what its result means. A passing test supports the claim that the candidate passed that test under that environment. It does not, by itself, establish universal correctness, maintainability, or alignment with every unstated convention. That restraint is not bureaucratic caution. It is what allows a team to use a strong signal without accidentally extending it into a claim it cannot carry.

A quantitative layer is necessary when binary correctness is not the whole objective. GSO demonstrates the difference between a patch that remains correct and a patch that also reaches a performance target.