Coding agents can write code, add tests, and confidently announce that a task is complete. The problem is that an agent’s confidence and a green test report do not prove that the change actually works.
The failure often appears later: in the built package, the deployed application, or a scenario the tests never covered. The code passed a check, but the check answered the wrong question.
The problem: an agent grading its own work
The same agent usually implements the task, writes the tests, and evaluates the result. In that loop, it tends to confirm its solution instead of looking for a way to falsify it.
Even a completely green test suite may not reveal:
- which existing behavior the change broke;
- whether the observed result matches the requirement;
- whether the intended revision was built and deployed;
- whether the code works across the real delivery boundary;
- whether important checks are capable of detecting a failure;
- what remains untested.
This does not make tests useless. Tests provide evidence within the scenarios they actually exercise. The mistake is treating that limited evidence as proof of the entire task.
The solution: a separate adversarial role
Gopnik is an adversarial verification skill for coding agents. Once an implementation is declared complete, it starts from the opposite assumption: the change contains a failure, and the job is to find it.
Instead of rereading the implementation agent’s report, Gopnik identifies behavior that could have broken, attacks the code inside the repository, and then checks the built or deployed revision where people use it whenever possible. It also requires evidence that an important check can fail.
A typical result looks like this:
BLOCKER — discounted orders are rounded twice.
Reproduce:
POST /orders with {"discount": 0.1}
Observed: 23.94
Expected: 23.95
Verified revision: 8f31c2a
Verdict: NOT READY
The verdict is bound to a specific revision and verification scope. If the required environment is unavailable, Gopnik narrows the conclusion and states what could not be proven instead of treating missing evidence as success.
How it fits into the workflow
The project contains three related skills:
gopnik-criticchallenges an important claim or proposed solution before implementation;gopnik-setuplearns how the current project can actually be verified;gopnikattacks a completed change.
This does not replace tests, review, or the team’s responsibility for a release. It adds an independent pass with a different objective: not to confirm completed work, but to find a reason why it is not complete.
Try it on a real change
Gopnik is free, MIT licensed, and has no paid tier. Install it, choose a completed change, and ask your agent to run the skill before moving the task to Done.
The best way to evaluate the approach is to run it against a task your coding agent already considers finished and see which claims survive an attempt to falsify them.