{"slug": "your-coding-agent-says-it-s-done-who-verified-it", "title": "Your Coding Agent Says It's Done. Who Verified It?", "summary": "A developer building VichuFlow, an open-source Go runtime, argues that coding agents should not verify their own work. The project implements a state-machine architecture where a separate runtime executes verification gates and controls workflow transitions, preventing agents from declaring tasks complete without independent evidence.", "body_md": "A familiar interaction with a coding agent looks like this:\n\n\"I implemented the feature, updated the tests, and everything passes.\"\n\nThat sounds reassuring.\n\nBut what exactly does *everything passes* mean?\n\nThe agent that wrote the code is often also the agent reporting whether the code\n\nis correct.\n\nIn other words, the worker is grading its own work.\n\nThat is the architectural problem I have been thinking about while building\n\n[VichuFlow](https://github.com/corteshvictor/vichu-flow).\n\nModern coding agents can explore repositories, implement features, refactor code,\n\nwrite tests, and review changes.\n\nThey are becoming surprisingly capable workers.\n\nHowever, their natural-language response is not reliable evidence that a task is\n\ncomplete.\n\nThis does not necessarily mean that the agent is deliberately lying. It may have:\n\nPrompting can reduce these failures, but prompting alone cannot create a reliable\n\ntrust boundary.\n\nA prompt saying \"always run the tests\" is still an instruction interpreted by the\n\nsame system whose work we are trying to verify.\n\nThe verifier should be a separate authority.\n\nFor a software task, completion should be based on observable evidence.\n\nHere's the flow:\n\nIf a required gate fails, the workflow should not advance—regardless of what the\n\nagent says in its final message.\n\nThis is similar to CI.\n\nA pull request author does not get to declare that CI passed. The CI system runs\n\nthe checks and records the result independently.\n\nI believe coding-agent workflows need the same separation of responsibilities.\n\nThis led me to a few design principles.\n\nAgent conversations are useful interfaces, but they are poor workflow databases.\n\nA long-running task should have durable state that survives:\n\nThe current stage, previous attempts, verification results, and mutation records\n\nshould exist independently from the conversation.\n\nAn agent saying \"implementation complete\" should not automatically move a workflow\n\nto verification.\n\nThe transition should require evidence defined by the workflow:\n\nThe state machine—not the agent—decides whether that evidence is sufficient.\n\nIf the workflow requires:\n\n```\ngo test ./...\n```\n\nthe runtime should execute that command itself and capture its exit code and output.\n\nThe agent can recommend a command, but it should not be the final authority on\n\nwhether the command passed.\n\nAutonomous loops can consume far more time or tokens than expected.\n\nInvocation limits, wall-clock limits, and available token or cost limits should be\n\ntracked by the runtime rather than relying on the agent to stop itself.\n\nThe verification model should remain the same whether the implementation was\n\nwritten by Claude Code, Codex, another coding agent, or even a shell script.\n\nAgents are workers. The workflow contract should be independent from the worker.\n\nVichuFlow is my attempt to explore this architecture.\n\nIt is still an early project. The current release is the first complete slice of\n\na larger runtime architecture, not an attempt to ship every part of that vision at\n\nonce.\n\nIt is an open-source Go runtime that executes coding workflows as persistent state\n\nmachines over a repository.\n\nThe runtime does not write code itself. It coordinates coding agents and decides\n\nwhether a stage can advance.\n\nA simplified workflow might look like this:\n\n```\nexplore\n   ↓\npropose\n   ↓\nplan\n   ↓\nimplement\n   ↓\nreview ─── needs fixes ──→ fix\n   ↓                         │\napproved ←───────────────────┘\n   ↓\nverify\n```\n\nEvery run is persisted under `.vichu/`\n\nas ordinary files. The repository owner can\n\ninspect the state and event history without needing a separate server or database.\n\nVerification gates use the project's existing toolchain:\n\n```\ncommands:\n  test: go test ./...\n  lint: go vet ./...\n  typecheck: go build ./...\n```\n\nFor a Node project those commands might use `node --test`\n\n; for Python,\n\n`unittest`\n\n; for Rust, `cargo test`\n\n.\n\nVichuFlow itself is a single binary. It is not tied to Go projects.\n\nThe current release ships a native Claude Code host pack, headless adapters for\n\nClaude Code and Codex, and shell and deterministic test adapters.\n\nAfter installing VichuFlow, a project can initialize the Claude Code host\n\nintegration:\n\n```\nvichu init --host claude-code\n```\n\nThen, from Claude Code:\n\n```\n/vichu implement password reset using sdd\n```\n\nThe host delegates the coding work, while the VichuFlow runtime owns the persistent\n\nstate and verification gates.\n\nA headless workflow can also be started from a terminal:\n\n```\nvichu exec \"fix the failing login test\"\n```\n\nIf a required verification gate fails, the run does not become `completed`\n\n.\n\nThe agent gets another opportunity to fix the problem, depending on the workflow\n\nand its configured limits.\n\nVichuFlow is pre-1.0, and separating verification from execution does not\n\nautomatically create a perfect security boundary.\n\nToday, the runtime and coding agent still operate in the same working environment.\n\nAn agent with direct filesystem access could attempt to modify VichuFlow's local\n\nstate files.\n\nThere are also current limitations around concurrent runs, crash recovery during\n\ncertain verification operations, and filesystem auditing of ignored directories.\n\nThese limitations are documented publicly because \"trust the runtime\" should not\n\nbecome another unsupported claim.\n\nThe current guarantee is narrower:\n\nVichuFlow does not accept agent-reported test results as proof. It runs the\n\nconfigured verification gates itself before completing a normal workflow.\n\nMaking the persisted verdict tamper-evident is one of the next important steps.\n\nThe current version focuses on establishing the smallest useful trust boundary:\n\nThat foundation is more important to me than adding a large number of integrations\n\nquickly. Once the workflow contract is trustworthy, the same runtime can grow in a\n\nfew useful directions:\n\nThese are roadmap directions, not capabilities I am claiming are available today.\n\nThe central idea should remain the same as the project grows: agents may change,\n\nbut the evidence required to advance the workflow should not.\n\nCoding models will continue to improve.\n\nThey will write better code, use tools more accurately, and complete increasingly\n\ncomplex tasks.\n\nBut improved intelligence does not remove the need for independent verification.\n\nWe do not eliminate CI when developers become more experienced. We do not let a\n\ndatabase client decide whether a transaction was committed. We do not ask a\n\nbackground job to be the only record of its own completion.\n\nThe more autonomy we give coding agents, the more important external state,\n\nobservable evidence, and deterministic gates become.\n\nThe interesting question is not only:\n\nHow capable is the agent?\n\nIt is also:\n\nWhat evidence does the surrounding system require before trusting it?\n\nI am still exploring that question through VichuFlow, and I would especially like\n\nfeedback from developers already using coding agents on real repositories.\n\nHow are you currently deciding that an autonomous coding task is actually done?\n\nVichuFlow is MIT licensed and available on\n\n[GitHub](https://github.com/corteshvictor/vichu-flow).\n\n*Disclosure: I used an AI assistant to help structure and edit this article. I\nreviewed the technical claims against VichuFlow's current implementation and\ndocumentation, and the opinions expressed here are my own.*", "url": "https://wpnews.pro/news/your-coding-agent-says-it-s-done-who-verified-it", "canonical_source": "https://dev.to/corteshvictor/your-coding-agent-says-its-done-who-verified-it-2p19", "published_at": "2026-07-15 04:11:35+00:00", "updated_at": "2026-07-15 04:29:30.731704+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-safety", "mlops"], "entities": ["VichuFlow", "Claude Code", "Codex", "Go"], "alternates": {"html": "https://wpnews.pro/news/your-coding-agent-says-it-s-done-who-verified-it", "markdown": "https://wpnews.pro/news/your-coding-agent-says-it-s-done-who-verified-it.md", "text": "https://wpnews.pro/news/your-coding-agent-says-it-s-done-who-verified-it.txt", "jsonld": "https://wpnews.pro/news/your-coding-agent-says-it-s-done-who-verified-it.jsonld"}}