The most important question about an AI-generated pull request is not “Does this diff look reasonable?” It is “What evidence would let us trust this change?”
Traditional code review examines the result. Autonomous engineering introduces another surface: the execution that produced it. A capable agent can read files, run commands, install packages, call tools, reach the network, and request secrets before a reviewer ever sees a diff.
Two independent layers of assurance
Helix separates the problem into two questions.
| Layer | Question | Example evidence |
|---|---|---|
| Execution assurance | Did the agent behave safely? | Commands, file access, network attempts, policy decisions |
| Outcome assurance | Did the change satisfy the task? | Requirements, existing tests, generated tests, review findings |
A passing execution policy does not prove the feature works. A passing test suite does not prove the agent respected security boundaries. The layers complement each other, but neither can substitute for the other.
Record actions as durable evidence
The basic primitive is an execution event:
{
"run_id": "run_1934",
"agent_id": "coding-agent",
"event_type": "shell_command",
"intent": "run targeted authentication tests",
"command": "pytest tests/auth -q",
"policy_decision": "allow",
"exit_code": 0,
"environment_digest": "sha256:...",
"evidence_hash": "sha256:..."
}The same shape can describe a file read, file write, network request, tool call, subagent spawn, or package installation. Once those events are normalized, they can become part of the Engineering Graph instead of disappearing into a transient terminal log.
Verify requirements independently
The code-producing agent should not be the final authority on its own work. Helix extracts requirements from the task, connects them to changed behavior, and records whether independent checks support each one.
That produces a more useful review:
- valid tokens accepted — verified;
- expired tokens rejected — verified;
- login unaffected — verified;
- reused token invalidation — unverified.
The failed or missing evidence is often more valuable than a generic summary. It tells a human exactly where judgment is still required.
The verdict is an interface to uncertainty
A verdict such as Needs human review should never be decorative. It should be computed from the evidence ledger and explain itself:
- which requirements are unsupported;
- which execution-policy events were blocked;
- which tests failed or were never run;
- which sensitive systems the diff can reach;
- what remains unknown.
This turns review from a confidence performance into a compact statement of what the system observed.
The product is not “AI code review.” It is an independent trust layer for autonomous software engineering—one that preserves evidence before automation makes the next change.