Workflow Patternscritical

Verify Before Done

The 'verify before done' workflow means an agent doesn't claim success until it has run the change end-to-end — tests pass, server starts, UI renders, build succeeds. Type checking and tests verify code correctness, not feature correctness.

Memory anchor

Verify-before-done is a contractor running the water before declaring the bathroom finished. 'It looks installed' is not 'it works.' Run the faucet.

Expected depth

Concrete checks by change type: backend logic → run tests + start server + hit the endpoint; UI changes → start dev server + open in browser + check console; build tooling → run build + lint + typecheck. Don't ask the user to verify — verify and share proof (screenshot, log, test output). For UI specifically: use a preview tool (Claude Preview, browser MCP) and capture a screenshot; for APIs, use curl or the runtime test runner.

Deep — senior internals

Verification is the line between 'feels done' and 'is done.' LLMs are confident — they'll claim a feature works because the diff looks plausible. The fix is mechanical: every claim of 'done' must be backed by an artifact (test output, screenshot, log). Stop hooks can enforce this — block the agent's stop turn until the verification artifact is present. UI changes are the worst case because compile success means nothing about runtime behavior — type check passing while the page renders blank is a common failure. Always test the golden path AND adjacent flows that might regress.

🎤Interview-ready answer

Verify before done means the agent doesn't say 'done' until it has run the change end-to-end and shown proof. For UI, that's a screenshot from a real browser preview. For APIs, that's a curl or test output. For builds, that's the build log. The bug this prevents is the model's tendency to confidently claim success because the diff looks right — type checks and tests verify correctness, not feature behavior. I enforce this with Stop hooks that block turn termination unless the verification artifact is in the response.

Common trap

Verifying only the change itself, not adjacent functionality. A button works → ship → realize the form below it broke. Always test the golden path and at least one nearby flow that could regress.

Related concepts