The Bug That Passed Every Review
Every check was green. Every task had been reviewed and passed. By all the local evidence, the work was done. Then we ran one more pass — adversarial, aimed at the whole branch instead of any single task — and it found a HIGH-severity data-loss bug in the stretch of the pipeline that ingests hospital price files.
It was not a subtle smell. A refresh path, under a specific sequence, would quietly gut the consumer-facing dataset down to a subset of what it should contain. Real rows, silently gone, in a system whose entire job is to not lose rows. And it had sailed through every per-task review — including AI-assisted review — because, examined one task at a time, every task was correct.
I have been building this pipeline with AI as a genuine collaborator. The bug sits exactly on the line between what AI is good at here and where it structurally cannot help, no matter how good the model gets.
What AI Actually Built
Full credit first — it is real and large.
AI did Layer 1 — the unglamorous floor of the building, the part nobody claps for and the part that is almost all of the work. Three incompatible machine-readable file formats, reconciled into one schema. Schema-drift detection, so that when a hospital silently changes its file format between regulatory revisions, a median does not get quietly poisoned. The streaming machinery to handle a file that decompresses to many gigabytes without running the process out of memory. The verification scaffolding under all of it. This is the compounding that is real in "AI for X," and it is not at the dashboard — it is here, in the data plumbing. AI did it fast enough that a small founding team shipped one state and then a second one five times larger, on a timeline that used to cost a dedicated team a quarter each.
So when I say the seam needed a human adversary, I am not saying AI did not pull its weight. It did the heaviest lifting. I am saying there is one specific thing it could not do, and the data-loss bug is what skipping that thing looks like.
Where the Bugs Actually Lived
Once I started counting, the pattern was unmistakable. The bugs that mattered — the ones that would have lost data in production — did not live inside the pieces. They lived in the seams between them.
The adversarial pass kept finding them after every per-task review had passed. In the streaming work, four real bugs, including a worker process that could die during the submission loop and take the entire run down with it — a failure that exists only in the interaction between the worker lifecycle and the submission loop, not in either alone. In the discovery feeds that find the files to ingest, a server-side-request-forgery hole where a redirect could bypass a safety check, plus a bug that silently dropped URLs — again, failures in the handoff between "validate this URL" and "follow this URL," not inside either step. In the ingest seam itself, two more high-severity data-loss bugs, each a property of how two correct components combined.
Every one of these was invisible to any review that looked at a single component. Not because the reviews were lazy or the reviewer — human or AI — was weak. Because the bug was not in a component. It was in the relationship between components, and a review scoped to one component cannot, even in principle, see a relationship it is not looking at.
Why Unit Review Cannot See the Seam
When you review a unit of work — a function, a module, a single task — you check it against its specification. Does this piece do what this piece is supposed to do? That is the right question for that scope, and a good reviewer, human or model, answers it well. But an integration bug is not a violation of any single piece's specification. Each piece can be doing exactly what it was told to do, correctly, in isolation. The bug is in the gap between the specifications — an assumption one piece makes about another that nobody wrote down, an ordering that only matters when two pieces run together, an error path one component handles in a way the next does not expect.
The per-task review's strength — its tight focus on one unit — is exactly what blinds it to the seam. You cannot find a boundary bug by checking either piece against its own spec; neither piece is wrong against its own spec.
This is why a smarter reviewer does not solve it. A better model reviewing each task one at a time is a better answer to the wrong question — more within-unit bugs caught, the between-unit bug still invisible. The seam needs its own review, with the boundary explicitly in scope, or it does not get reviewed at all.
The Adversary at the Seam
So the merge boundary got its own pass, built to be adversarial on purpose.
The shape was a funnel of fresh eyes, each stage scoped wider than the last. Spec, then a fresh-eyes review of the spec. Plan, then a fresh-eyes review of the plan. Each task implemented and put through a two-stage review — does it meet the spec, and separately, is the code sound. Then, at the end, a whole-branch merge-gate with several adversarial finders running in parallel, each pointed at a different way the seam fails. One reading line-by-line across the diff. One hunting specifically for behavior that was silently removed. One reading across files for contracts that had drifted apart. Their entire job was the integration — the place the per-task reviews structurally could not reach.
Two things kept this from becoming theater.
The first is what "review and merge if no issues" was allowed to mean. Not "glance, find nothing obvious, merge." It meant: find the issues, fix them properly, then merge. The default outcome of an adversarial pass doing its job is that it finds something — and the discipline is that finding something blocks the merge until it is genuinely fixed, never waved through with a note. A merge-gate allowed to pass things "with minor concerns" is not a gate.
The second is how the fixes were verified. Every fix got a test, and every test was mutation-checked: break the fix on purpose, confirm the test goes red. A test that stays green when you break the code it supposedly covers is a green light wired to nothing. Watching it fail for the right reason is the only proof the guard is real. Same discipline the data validators live under, applied to the seam.
What This Means for Building With AI
Here is the durable lesson under all of it.
AI collapses the cost of building the pieces. It does not collapse the cost of integrating them honestly. Those are different costs, and the second does not fall because the first did — if anything it grows relatively larger, because AI lets a small team build more pieces, faster, which means more seams, sooner, than that team would otherwise have to integrate.
The failure I see coming in a lot of AI-accelerated work is the one I almost shipped: a system whose every component is individually excellent and individually reviewed, with an integration seam that only ever got looked at one piece at a time. Each piece passes. The demo works. And a data-loss bug sits in the boundary, invisible to every review performed, waiting for a production sequence to trigger it.
The model will not save you from that, because the seam is not in the unit it reviews. What saves you is an explicit, adversarial pass whose only job is the boundary — the integration, the handoffs, the assumptions that live between specs — with the authority to block the merge until what it finds is fixed. AI did Layer 1. The seam is the part you still have to staff an adversary against, on purpose.
What I Do Not Yet Know
The adversarial merge-gate works, but I cannot yet call it complete, and that honesty matters more than the tidy version.
I do not know whether the finders I run cover the space of seam failures, or just the space of seam failures that have already bitten me. Line-by-line, removed-behavior, cross-file contract drift — I have those finders because those are the bugs that hurt. A genuinely novel integration failure, of a kind none of my finders is shaped to look for, would pass the merge-gate exactly the way the data-loss bug passed the per-task reviews: silently, because nobody was looking at that boundary. The gate is adversarial, but its adversariality is bounded by my imagination of how seams break — and the whole lesson here is that the dangerous bug is the one your current scope leaves out.
The other thing I do not know is how much of the adversarial pass can itself be handed to AI. Some clearly can — a model told to look across files for drifted contracts is useful. But there is something about the adversarial posture, a reviewer whose incentive is to break the thing rather than approve it, that I have not figured out how to specify reliably to a model that will, by default, try to be agreeable and find the work acceptable. Refutation seems to want a different stance than the one a helpful assistant defaults to.
So the open question I would put to anyone building seriously with AI: how do you get an adversarial pass — the one whose job is to refute the work, not bless it — out of tools trained to be helpful? I can get the building, and much of the within-unit checking. The part I am still doing mostly by hand is the part that assumes the system is wrong until it survives an honest attempt to prove it.
→ See how the same review discipline shows up on the data side: When You're More Correct Than the Source of Truth.
→ See the full framework: The Decision Effectiveness Framework.