AI coding agents have a consistency problem. Ask one to add authentication to your project and it'll tell you it's done. Commits made, tests passin...
For further actions, you may consider blocking this person and/or reporting abuse
Strong piece, and CrisisCore's "proof of execution is not proof of correctness" is the line I keep coming back to.
The gap I keep hitting sits one step past the artifact checks: a lot of an agent's most load-bearing claims have no artifact to diff. "I escalated this to the human", "I stopped because it was outside my authority", "I left the migration for review instead of running it" — there's no build or test that proves those happened the way the transcript says. Kalpaka's no-op example is the same root one move earlier: the artifact is present, the claim about what it means is false. Outcome-based gates close proof-of-execution; the residual is proof-of-claim on the decisions that never produce an artifact.
The other one that bites is continuity across a model switch. A boundary the agent honored under one model at step 3 isn't automatically re-checkable under a different model at step 30 — the diff/build/test trail can stay green while the decision provenance silently resets.
We've been treating those two — non-artifact decision/boundary claims, and provenance that has to survive a model swap — as the part outcome-based verification doesn't reach yet, and trying to instrument checks around them specifically. Does your next-release semantic pass touch the decision layer, or does it stay on the code artifacts?
Decision claims can't be checked here, no trace of them in a diff. Transcripts don't count as evidence. The model-switch case is the same: it only sees the finished diff, not the live session. Catching that needs a signed log of what the agent actually did at runtime, then claims checked against it. Out of scope for this tool.
This is the exact boundary we keep hitting. Outcome/diff checks catch "did the output match," but the two you name — decision claims and mid-session model-switch — leave no trace in the artifact, only in the live run. We added a small detector for the model-switch case (it flags the model id changing mid-session, because the inherited context goes quietly unreliable), but that's a tripwire, not the signed log you're describing. "A signed log of what the agent actually did at runtime, then claims checked against it" is the right shape; the hard part is making that cheap and routine rather than another bespoke harness. Transcripts-don't-count is the crux: a transcript is the agent's own narration, so it's self-authored evidence. Curious what you'd accept as the signing authority — the runtime/harness emitting the log out-of-band from the model, or something cryptographic?
this hits home. i’ve had agents swear they fixed a broken hook when the code literally didn’t change — it’s a massive vibe killer when the tool tells you one thing and the browser says another. focusing on the actual outcome instead of the agent’s chat log is the only way i can stay productive. vibe first, polish later, but you’ve got to verify the work actually happened.
Hi Jill, appreciate your comment! Yes, that exact reason is why Swarm skips the chat log and only pushes forward on real git diffs, builds, and test results. Appreciate you chiming in!
that's the right call — git diffs don't lie. i've started doing the same thing manually, just checking what actually changed instead of trusting the agent's summary. if swarm automates that verification layer, that's worth watching. have you listed it on stackapps.app? fits right in with the indie dev tool crowd there.
Strong post. The core move here is shifting trust from transcript to artifact.
An agent saying it changed files, passed tests, or completed the task is not evidence. A real diff, a real build, and real test execution at least move the system back onto something observable.
The next gap, like you pointed out in the comments, is semantic completion. Passing checks proves the branch is less broken. It does not yet prove the branch actually did the thing.
That is the boundary more teams need to get serious about:
proof of execution is not proof of correctness
proof of correctness is not proof of safe merge
and self report is not proof of anything
Still, this is exactly the right direction. Verification has to be outcome based, branch grounded, and hostile to agent narration by default.
The priority shift on the final attempt -- "get something working over something complete" -- is the detail that sticks. It mirrors what experienced developers do under time pressure: reduce scope to protect correctness. Most retry logic just throws the same prompt again.
One thing I'd push on: does the verification layer track whether the RepairAgent "fixes" a build by quietly dropping the feature? I've seen agents pass all checks by producing a no-op implementation. Technically green, semantically empty. Outcome-based verification handles "did it break?" well, but "did it actually do the thing?" is still mostly an open problem.
Correct on the semantic completeness problem. Closest I have to it right now is verifyExpectedOutputs, which does term pattern matching against diff. It could definitely be bypassed by an agent giving a technically present, but behaviorally empty implementation.
In the next release, I'm thinking about adding a semantic verification pass. Small, seperate, agent that reviews the final diff against original goal and flags (if it looks like a no op or scope reduction.) Adding it shouldn't be hard at all.
Hi Brad, thank you for the mention and the great article. I‘m Arne, one of the Emdash founders and wanted to state that Emdash is not „local-only“ - we allow you to connect to any remote server via SSH and our users love it.
Arne
Good to meet you Arne and thanks for the clarification on this. I have edited my post to better state the true state of things at this time. Appreciate the heads up. I also took out the direct references to similar tools. Naming them specifically wasn't intended. We address two different areas and its not right to call anyone out like that. Swarm Orchestrator is a CLI-first verification and governance layer with no dashboard or UI at all. It's built purely for native CI execution and outcome-verified gates inside pipelines, not for interactive desktop workflows. Different tools for different needs. Appreciate the comment and hope my edits are sufficient!