How I trust code I didn't write

Someone posted a question on Hacker News this week that I have spent two years answering for myself without ever writing it down: do you still write code by yourself? The poster was not showing off about shipping fast. He sounded uneasy. He writes his requirements out longhand, hands them to an agent, takes the result back in blocks, and reads each block before letting the next one start, because he wants to know what he is building and why. He said he does not really like vibe coding, because it feels like you do not get full control over your own code.

I get the instinct, and I think he is closer to the answer than he realizes. The way I trust code I did not write is not to read it more carefully. I trust it because it cleared a gate that runs whether or not I read every line. Surface signals, the build is green, the grep is clean, the agent reports done, only propose that a change is right. A semantic check, whether the running system actually does what the spec said, is what disposes. Reading the diff is one input into that. It was never the verdict.

Doesn't trusting code you didn't write mean reading every line?

That is the trap, and it is worth naming because almost everyone falls into it first. When the agent writes faster than you can read, the honest-feeling response is to read harder. It does not scale. Past a certain speed your review degrades into skimming, and skimming degrades into rubber-stamping, and a rubber stamp that feels like diligence is worse than no review at all, because you trust it. The numbers say the same thing out loud: surveys keep finding that most developers do not fully trust AI-generated code, and that teams pour something like a quarter of the work week into checking and fixing it. That is the arithmetic of scaling review by staring, and it loses. The move is not more reading. It is a check that runs at machine speed against the one thing a human eyeball cannot verify by looking anyway: behavior.

What actually earned my trust: the gate, not the staring

The lesson that changed how I work cost me a scare. Early on I trusted green. A change built clean, the checks passed, the agent said it was done, and I shipped it. The structure was fine. The behavior was not. The gate I had was a structure-only gate, and a structure-only gate will certify broken behavior all day, because "it parses and the shape is right" and "it does the correct thing" are two different questions. Passing tests is not the same as a fixed app, and I had quietly confused the two.

So I changed what the gate measures. Now every change crosses something with legs: a structure leg that asks does this parse and hold its shape, a functional leg that asks does the running system do what the spec said, and where it matters a performance leg. The structure leg is the surface, and it proposes. The functional leg is the semantic measurement, and it disposes. That distinction is the whole game. It is what lets me accept a block of code I did not type, not because I understood every token in it, but because the block had to survive a behavior check I wrote before the agent ever ran. That is the spec-first move: the spec is the source of truth, and the gate measures the vibe coded result against it instead of against my mood that afternoon.

How do you review code you don't fully understand?

You review the intent, not the syntax, and you make a machine carry the part your eyes cannot. The Hacker News poster is already doing two-thirds of this without naming it. Writing requirements out longhand is a spec. Reading the result in blocks against those requirements is reviewing against declared intent instead of reading it cold. The missing third is the gate: an acceptance check that runs on behavior, so the block has to pass whether or not your read of it that day was sharp.

Concretely, that means writing down what the change is supposed to do before you ask for it, in enough detail that "done" has a definition. Then you read the diff in blocks, not to certify it, but to sanity-check it against the spec. Then you let the acceptance gate deliver the verdict. If you want the longer version of the operator-level checks that do not require reading code like an engineer, I wrote that up separately in how to audit AI-generated code before you ship. The short version is that the review you can trust on a vibe coded project is the one that does not depend on your attention span.

What about having another agent review it?

Tempting, and it half-works, so it is worth being precise about where it stops. A second agent will catch typos, obvious omissions, style drift. What it cannot reliably do is catch the semantic mistake, because a model reviewing another model's code tends to reason about that code the same way the author did, recognize the mistake as normal, and bless it. You get a clean green review that says nothing about whether the change is right in the running system. I wrote about that failure mode in when one AI reviews another AI's code. A second opinion that inherits the first one's blind spot is not a second opinion. It is the same guess with more confidence. The check that disposes has to be a measurement of behavior, not another opinion about the code.

This is also why I do not tie my trust to any one tool. In a single week an open-weight model gets good enough to run on your own machine and a widely used coding tool changes hands. The layer underneath you keeps reshuffling. If your confidence lives in a specific model or editor, it evaporates on the next release. If it lives in your spec and your gate, it survives every swap, because the gate does not care which agent wrote the code. It only cares whether the behavior matches the spec.

If you are formalizing how you trust AI output after the messy first phase and want to compare notes on what holds up at production scale, /work-with-us. Mostly, though, this is a thing you can build for yourself.

Questions that keep coming up

Do I have to read every line? No. Read the blocks against the spec so you understand the shape of what you are getting, then let the gate carry the verdict on behavior. Hand-reading every line is the bottleneck you are trying to avoid in the first place.

Is skimming the diff still review? Skimming is a surface check, so it proposes. It can tell you the change looks reasonable. It cannot tell you the running system does the right thing. Only a behavior check disposes.

The agent says the tests pass, so is that enough? Tests passing is a surface signal, and a real one, but it proposes. Whether those tests actually cover the behavior the spec asked for is the question that decides it. A green suite that checks the wrong thing is exactly the trap.

The vibe coder on Hacker News was reaching for control and worried he had to choose between reading everything and trusting blindly. He does not. The spec is the control. The gate is the trust. The reading is just how you stay oriented in between.