I banned Claude from saying 'looks reasonable' and it started finding my blind spots

A developer building a SaaS product created a "skeptic" review sub-agent explicitly instructed to disprove design documents rather than verify them, then ran it against an execution plan written minutes earlier. The agent surfaced four major findings, including a self-contradiction where the developer added a second outbound-communication loophole to a design that declared exactly one. The developer argues that flipping the reviewer's success condition — failing to disprove equals defeat — is what forces the model past its default "looks reasonable overall" approval.

I'm in the middle of launching a SaaS product, and the deliverable from one particular session wasn't code. It was an execution plan, plus the design of the quality gates. In other words: writing down "how we're going to build this" and "how we're going to inspect what we built", as documents a later session the implementer could pick up and run with. As part of the quality gates, I defined a few review sub-agents. One of them is alarming from the name alone. skeptic . Its job: "go disprove the claims in the design doc." A normal reviewer's job is to verify. Not this one. Its definition says: I have to admit, I built a genuinely unpleasant agent. I saved the skeptic's definition file. And immediately thought, as if it were the obvious thing to do: What if I point this thing at the design doc I just finished writing? Handing my own execution plan to an agent I defined as "its job is to disprove you." Bit of a masochist move, but I ran it. Result: 4 findings, all MAJOR . From a design doc I had written minutes ago. The ink wasn't even dry. The one that hit hardest was this. I had written a statement that contradicted a rule I set myself. This project has a strict rule: "block all outbound communication." And that rule carries an invariant: "there is exactly one loophole, and it's here" I defined it myself as the only hole . Yet somewhere else in the design doc, I had casually written "add a new loophole by reusing the existing procedure." Opening a second hole in the thing I had declared to have exactly one. I had walked straight through my own invariant. The other three findings were the same species of hole. Every one of these is something I'd spot in ten seconds in someone else's PR. In a document I wrote fifteen minutes earlier, they were completely invisible. If you just ask "review this design", the AI puts on its honor-student face. "Great work. A few minor improvements..." Those four findings never make it into the "minor improvements." What worked, I think, was flipping the success condition upside down. A reviewer for whom "finding no problems = success", and a reviewer for whom "failing to disprove = defeat", read the same document and do completely different things. The latter loses unless it hunts for flaws, so it digs for holes like its life depends on it. Cutting off the "looks reasonable overall" escape route in the definition itself is what did it. When you run development doc-driven, you eventually hit a wall that no amount of source-of-truth hygiene fixes: the person who wrote the source of truth is the least qualified to review it. Right after writing, the "what I meant to say" in your head overwrites the actual characters, and you see assumptions that aren't on the page. So the reviewer you should hire isn't one that approves you. You unleash a reviewer whose job is to disprove you on the person who wrote the deliverable: yourself. And the most ironic part this time: the disproving agent was itself a deliverable of this very design. I shot my freshly written design with a freshly built inspection tool. An inspection tool shows its true value the moment you aim it at yourself. After fixing the findings, I hesitated over whether to run the same skeptic for another round. It feels like it could keep punching forever.