How to prove an AI code change did what you asked
AI writes plausible code that quietly does the wrong thing. Proving a change means tying the commit to the goal it was meant to deliver and recording a verdict — verified, partial, or not wired — you can audit. How it works.
To prove an AI code change did what you asked, tie the commit to the goal it was meant to deliver and record a verifiable verdict, which functions were wired in, which code paths now exist, and whether the stated intent matches the actual change. A green build and a confident summary aren't proof; agents produce plausible code that compiles and reads well while quietly doing the wrong thing. Proof is a durable, checkable link between a goal and the exact commit that satisfied it.
Why "it compiled" isn't proof
An agent's own report is the weakest possible evidence: it's the same model that wrote the code, grading its own homework. Tests help, but they only cover what you thought to test. And a plain Git diff shows you the lines that changed, not whether the change actually delivers the behaviour you asked for. The gap between "the code changed" and "the goal is met" is where AI regressions live.
The goal ↔ commit verdict
Aura closes that gap with a proof ledger. Every unit of work carries a goal, stored in .aura/goals.jsonl. When a commit lands, Aura proves it against the goal and records a verdict:
- verified: the goal's functions exist and are wired into a reachable path.
- partial: some of the goal is in place, but not all of it is connected.
- not_wired: the code exists but nothing calls it; the goal isn't actually reached.
You can read the whole ledger from the CLI. aura goals list --json returns every goal with its runs, each carrying the commit, the verdict, and the checks that passed. Because the verdict is tied to a specific commit and signed, it's portable: you can hand it to a reviewer, an auditor, or a teammate and they can confirm it without re-running your agent.
Proof vs an evaluator model
Some loops verify a goal by asking an evaluator model whether the condition looks satisfied. That's useful for fuzzy goals, but it's another probabilistic opinion, and it evaporates the moment the session ends. A recorded goal ↔ commit verdict is deterministic and durable: it's still there, and still checkable, long after the agent that produced the code is gone. For an autonomous work-loop, that difference is the whole game. You can let agents run unattended because every merge is gated on real proof, not a hopeful self-assessment.
Provenance: who, which agent, and why
Proof answers "did it work?"; provenance answers "where did this come from?" In Aura, git blame finds the commit, the commit links to a checkpoint, the checkpoint links to the agent session, and the session holds the full transcript, so you can trace any function back to the exact reasoning, the human, and the agent that produced it. Together, proof and provenance make AI-written code reviewable and auditable instead of a black box.
This is the layer a bare coding-agent loop skips. See how it fits an autonomous run in Aura Crew vs Claude Code loops, or the honest head-to-head on Aura vs Claude Code.
How do you verify AI-generated code actually works?
Tie the change to the goal it was given and check the goal, not the diff. That means a stated objective before the work, a machine-checkable outcome after it, and a record connecting the two — so the verdict survives after everyone has forgotten the session.
Can you trust code written by an AI agent?
Not on the strength of how it reads. Agent-written code is fluent by construction, which removes the surface cues reviewers rely on. Trust has to come from evidence outside the text: tests that fail without the change, and a record of what was asked versus what landed.
What does it mean to prove a code change?
To show the change delivers a stated behaviour, rather than that it compiles. In practice: name the goal, identify the logic that implements it, confirm the paths are wired, and record the result — so a later reader sees a verdict instead of re-deriving one.
Why do tests pass on AI code that is still wrong?
Because an agent that can see the tests optimises for them. Passing suites confirm the cases you already thought of. The failures specific to agents live outside that set — a deleted guard clause, a widened permission, a case that used to be handled and now is not.
Aura Crew vs Claude Code Loops: the autonomous work-loop, compared
Claude Code defines four loop types — turn-based, goal, time, and proactive. Aura Crew is the same idea productized: a dependency-ordered work-loop with proof, collision-safety, and any agent. Full comparison.
Autonomous coding agent loops, explained: turn-based, goal, time, and proactive
A coding agent loop is an agent repeating cycles of work until a stop condition is met. The four types explained — turn-based, goal-based, time-based, proactive — with when to use each and how to keep quality high.
How to run multiple coding agents in parallel without merge conflicts
Running several AI coding agents at once collides on shared files. The fix: a worktree per agent, a live team radar, and soft-to-hard zone claims so parallel agents never touch the same symbol. How Aura Crew does it.
Goal-based agent loops: giving a coding agent a definition of done
A goal-based loop keeps a coding agent iterating until a success criterion is met. The trick is a deterministic definition of done — tests, a score, a proof — not an LLM guessing at "good enough." How to write one.