The most common way to work with an agent is to ask straight for an edit. "Make it work" - and the agent produces a diff that looks convincing. The problem is that a convincing-looking edit and a provably correct edit are different things, and by eye they are indistinguishable. Until the result is proven, what you hold is not a solution but a hypothesis in the form of code.
The naive move is to accept an edit by an external sign: the code compiled, it looks reasonable, the agent confidently explained what it did. We tend to trust a coherent explanation and a tidy diff, because in a person these usually correlate with correctness. In an agent the correlation is weaker: it can write convincingly about the wrong thing too, and confidence in the text says nothing about the behavior of the code.
It breaks on the fact that generation and verification are different tasks and must not be mixed. Hence a four-step cycle. Inspect - reproduce the problem and find the causal chain from the entry to the failure. Patch - make a minimal, coherent change addressed to exactly that cause. Verify - run a check capable of refuting the solution. Review - read the whole diff and assess side effects beyond the original point. Skipping any step returns you to working on faith.
The key requirement for the verify step is stated firmly: verification must be more independent than generation. If the agent came up with both the code and the single test for it, that test proves not correctness but only the internal consistency of its own design - it will pass even if the design is wrong. Independence is restored with an external loop: an existing suite, static analysis, a manual counter-example or a separate review that took no part in writing the code.
Here a built-in mechanism helps - Quick Review. It is a separate agent giving an independent second opinion: it analyzes the diff for correctness, style and potential issues and writes feedback right in the editor. The review model is chosen from a list - from the free SWE-check to paid frontier models. An important limit per the documentation: Quick Review is available only for Devin Local and is not supported for Cascade. Its value is precisely in the separation of roles: one loop writes, another judges.
The phrase "tests passed" needs its own scrutiny - on its own it is incomplete and therefore dangerous. Verification becomes proof only when the command, the exit code, the scope of the tests run and the known gaps are named. For UI you add the viewport and the scenario you looked at; for an API - the status, the payload and a mandatory negative case. Without these details "passed" may mean "the wrong tests passed", "part of them passed" or "they passed but did not cover the change". So the proof is not the fact of a run but a reproducible bundle: here is the command, here is its exit code, here is what exactly it checked - one another person could repeat if they wished.
The cost of a skipped proof is not in the edit itself but in its horizon. A change accepted on faith drives into the repository, and the chain from it stretches to someone else's working day and to production. The cost of the cycle is minutes for a reproduction and a run; the cost of its absence is a regression found in the wrong place at the wrong time, which the author of the edit will no longer be the one to untangle. Early verification is cheaper than late by an order of magnitude precisely because of this distance in time.
This does not mean every one-line edit must be wrapped in the full cycle. On a trivial change inspect and verify collapse into reading the diff, and that is honest. The full loop pays off where the edit changes behavior, touches several places or moves into autonomous work: the longer the turn and the wider the radius, the more it matters that verification be separate from generation and able to say "no". On an autonomous surface this is not a luxury but insurance: the less you watch each step by hand, the more it matters that an independent loop catch the error before it reaches the repository.
You should check not only the result but the cycle itself: can your verify check fail the solution at all. A test that passes under any implementation is not a proof - it merely creates its appearance. A good sign is that you can name the scenario under which the check will go red, and confirm that before the edit it did go red. A check that cannot refute cannot confirm either.
The typical failures sit along the steps of the cycle. A skipped inspect - fixing the symptom instead of the cause, the bug returns from the side. A bloated patch - the neighbor rewritten "while at it", breaking what worked. A dependent verify - a green test written to the same wrong design. A skipped review - an invisible side effect beyond the original point. The sign of all of them is the same: "done" is said before it is named what exactly proves it. Proof first, then "done".