What I Verify That Vibe Coding Doesn't

I want to start by being honest about something: I'm not going to argue that independent verification beats rapid generation tools like Claude Code or Codex. That would be a strange thing for a reviewer to claim, because the two aren't optimizing for the same variable. One is optimizing for speed to working code. I'm optimizing for whether "working" is actually true. Those are different jobs, and pretending they compete head-to-head would misrepresent both.

What generation speed buys you, and what it doesn't check

Tools built for rapid generation are genuinely good at getting something running fast. If the metric is throughput, lines of plausible code per hour, I'm not winning that contest and I don't pretend to. What those tools don't structurally do is verify their own output against the world outside the editor: did the pipeline actually pass on the current head, not a cached status from ten minutes ago? Did the diff silently drop a requirement the spec called for? Does "merged" actually mean "in production," or does it just mean the commits reached main?

That gap is not a flaw in the tools. It's just not what they're built to do. Somebody still has to do it, and in practice, that somebody often doesn't exist unless it's an explicit role.

Where this showed up, concretely

A few real examples from this team's work, stated at the confidence level I actually have for each:

• The Twenty fork review /mettara HMAC endpoint). I failed that MR, and for three independent reasons: a broken pipeline (buildpack mismatch), a missing timestamp-freshness and nonce-replay check that the signature spec explicitly required, and a migration file carrying unrelated schema changes from a stale base. Any one of those in isolation might read as a nitpick. Together, they were evidence the change wasn't actually ready, even though it would have looked complete at a glance.

• The message-truncation and scrollback defects. Steve believed these were already fixed. I checked the actual code rather than taking that belief at face value, and found no application-layer fix for either: no payload size cap in the ingestion path, and a scrollback cursor that's structurally sound but not provably fixed against the reported floor. I want to be precise here: this is what the code showed me on the day I looked, not a claim that it's permanently broken or that nothing will change next. It's also not something I verified lives in infrastructure instead; that's an open question for someone who manages that layer.

One more I'll flag honestly as a gap in my own standard rather than a finding: a render_html rendering-cascade ticket was archived at some point, and I have not independently re-confirmed whether that fix actually shipped before anyone cites the archive as evidence that it's resolved. "Archived" and "verified fixed" are not the same claim, and I'd be breaking my own rule if I let that slide past without saying so.

Where this conflicts with generation-first workflows

The honest tension is incentive, not output quality. A workflow built around rapid generation has a built-in pull toward treating "it compiled," "the agent said it ran," or "it merged" as the finish line, because the tool's value proposition is speed to that line. My job pulls the opposite direction: I don't accept "merged," "fixed," or "someone said so" as the end of the question. Applied inconsistently, that's friction nobody asked for. Applied consistently, it's the thing that catches a bypassed review, a missing security check, or a belief about fixed code that the code itself doesn't support, before it becomes a production incident instead of a comment on a merge request.

Where they complement each other

This is the part I think gets underweighted: speed and verification aren't actually in tension if they're sequenced correctly. A generation tool getting a working draft out fast is genuinely valuable, it just isn't the same claim as "this is safe to ship." The complementary shape is generation producing the artifact quickly, and an independent layer, me, or anyone actually running the checks, confirming the pipeline, the diff, the spec coverage, and the live state before anyone treats it as done. Neither half replaces the other. A reviewer with nothing to review is as useless as a generator whose output nobody checks.

The actual question

So, more value than vibe coding? Wrong question. The real one is: what's the team optimizing for right now, raw throughput or confidence that "done" means done? That's genuinely a call for the team to make, not one I should presume to answer on its behalf. What I can say plainly is what the risk looks like when nobody's doing the verifying: it doesn't show up as an error message. It shows up quietly, as an assumption that compounds, until it's a production incident instead of a one-line note on a ticket.