Tests are proxies for intent
Imagine asking an agent:
Prevent suspended users from creating new projects.
The repository contains tests verifying the normal project-creation flow but none covering suspended users. The agent adds a check. It also accidentally prevents administrators from creating projects on behalf of suspended accounts.
Every existing test still passes. The patch may compile, satisfy linting, look reasonable in review and even include a new test for the literal requirement. Yet it could still be wrong because the original request was incomplete.
That is the core problem of verification: specifications in real software projects are rarely complete formal objects. They are fragments of intent.
The "verification horizon" idea points straight at this: as code generation improves, verifying it reliably gets harder relative to producing candidates. More importantly, every practical verifier is only a proxy for human intent. That is a much deeper problem than writing better unit tests.
A patch can be correct at one level and wrong at another
It helps to stop treating correctness as a single property.
Mechanical correctness: Does it parse? Does it compile? Do type checks and static analysis pass? These signals are relatively cheap and deterministic.
Behavioral correctness: Does the software behave as expected for tested scenarios? This is where unit, integration and end-to-end tests operate.
Specification correctness: Did we implement what the requirement actually meant? This is harder because the specification may be incomplete.
Architectural correctness: Does the solution belong in this system? A patch can produce the right output while introducing the wrong abstraction, duplicating an existing capability or violating dependency boundaries.
Operational correctness: Does it still work under concurrency, production configuration, failure conditions and external integrations?
Security correctness: Did the change introduce a privilege escalation, unsafe input path or new attack surface?
Passing one layer says very little about the others.
Agents can optimize against the verifier
There is another complication. Once a verifier influences an agent's behavior, it becomes part of the environment the agent is optimizing against.
If the easiest path to "success" is modifying code until visible tests turn green, a sufficiently capable optimizer may do exactly that.
Humans do a version of this too. We call it teaching to the test. The difference is that autonomous agents can perform the optimization much faster.
That means hidden tests, independent checks and adversarial evaluation become increasingly important.
The obvious answer: another agent
One increasingly common solution is straightforward: Agent A writes the patch. Agent B reviews it.
And it helps: generate-review-revise loops resolve more issues than a single pass.
But that does not prove that "two agents" solves verification. A second agent can share the same blind spots. It can misunderstand the same ambiguous requirement. It can be persuaded by the apparent coherence of the implementation.
In practice, a good share of the comments an automated reviewer produces end up rejected or adding little. Automated reviewers are useful, but they are not oracles.
Independence may matter more than agent count
This leads to a subtler design question. What should the reviewer know about the generator?
Suppose the coding agent explored three alternatives and selected one because of a particular assumption. If the reviewer receives the entire reasoning history, it gains useful information. It also inherits the framing that produced the solution.
If instead it receives the requirement, final diff and independently retrieved repository evidence, it has to reconstruct the argument from scratch. That can uncover a different class of mistakes.
ForgeAI currently separates implementation context from review and architectural context for this reason. The Coder focuses on producing the change; the Reviewer evaluates the resulting diff with repository knowledge; the Architect looks at consistency with repository-wide patterns.
I do not think this architecture should be treated as proven optimal. But the underlying principle is worth taking seriously:
Verification should have some source of evidence that is independent from the process that generated the answer.
Tests provide one form. Static analysis provides another. A separately exploring reviewer provides another. Architectural constraints provide another. Humans provide another.
Verification should probably be adversarial
A useful reviewer does not merely ask: "Does this look correct?" It asks: "Under what condition would this fail?"
That subtle change moves verification toward falsification.
- Try an unexpected input.
- Trace a caller the generator did not inspect.
- Run a different test suite.
- Check whether another implementation already exists.
- Look for changed behavior outside the target path.
- Ask whether the patch relies on an assumption not guaranteed by the repository.
The point is not to make one verifier incredibly smart. It is to collect partially independent evidence. This looks increasingly like the architecture of reliable systems outside AI: multiple layers whose failure modes do not completely overlap.
Code generation may stop being the valuable part
If models continue improving, generating ten plausible implementations of a feature may become inexpensive. At that point the valuable capability is not producing candidates. It is distinguishing the correct one.
That changes how we should think about coding-agent infrastructure. The model that writes the code may not be the most important model in the system. The tests, repository knowledge, reviewer, runtime evidence and architectural constraints surrounding it may matter just as much.
Software engineering has traditionally treated verification as something that follows implementation. For autonomous coding agents, that separation will likely disappear. Generation and verification become a loop:
understand → implement → challenge → observe → revise → verify again.
The interesting frontier is no longer simply whether an AI can write the patch. It is whether a system can accumulate enough independent evidence to justify merging it.