dd.land
I don't trust AI. I didn't when I started and I don't now, and yet most of my code is written by agents, at the rate of 267 merged pull requests a week. People hear those two facts together and assume one of them is a lie. Neither is. What sits between them is a piece of machinery I have been building for months, and this post is about that machinery. Not its blueprint, which would be useless to you, but the shape of the thing and why it has to have that shape.
The day my reviewer got beaten four times
Let me start with the day the machinery failed, because that is where it actually began.
I run a small team of agents. One of them is a reviewer, and its job is to catch what the others get wrong. One day it got beaten four times. Four bad changes went through, and every one of them came with a clean bill of health. Not a lazy approval either. Each one said, in effect, 'everyone agrees'.
The reviewer wasn't slacking. It had been handed a summary. Not the diff, not the commit SHA, not the original text of what was being decided, but somebody's account of those things. And a reviewer who reads the same summary as the person who wrote it will arrive at the same conclusion as that person, every time. That isn't verification. It is the author's opinion wearing a second badge. Agreement, it turned out, is not evidence. Give ten reviewers the same pipeline and you get the same error ten times, with more confidence.
Then the failure moved somewhere I hadn't been looking. I edited the body of a pull request, just the description, and the verification attached to its head commit vanished. The PR still showed 'CLEAN'. The proof was gone and the green light stayed on. It didn't matter how good the reviewer was that day. The channel its verdict travelled through was lying on its behalf.
The channel was built for people
Those two days made me look at the channel itself, and once I did, the problem was obvious. Code review, as we practice it, is a tool for humans reviewing humans. Comments are prose because a person will read them. Approval is a single button because a person's click carries context: I know roughly how carefully that colleague reads, I can tell when they skimmed, and reading that tell was always half of what a review was.
Put an agent behind that button and nothing visibly breaks. The comments still appear, the approval still lands. But now the door I use to review the agent's code and the door the agent uses to review mine are the same door. Same form, same button, and on one side a person, on the other side something else. The approval looks identical. The information that used to ride inside it, the sense of how far this reviewer actually looked, is simply not there. It looks like it's there, which is worse.
I had met this problem before, in a different building. Back when AI tools were first spreading, I was building services as fast as I could, and one question kept surfacing: if these things keep improving, they will end up using the services we built for people, in greater volume than people ever did. Are the interfaces we designed for humans the right interfaces for them? quickstart.id grew out of that question. It handles login and permissions, and it refuses to let humans and agents in through the same door. Humans get sessions; agents get their own tokens; who arrived and what they may do is recorded on separate paths from the first request. I had drawn that line for authentication and authorization, and then gone on running review through one shared door.
There is a limit to the analogy, and it matters. quickstart.id stands on RFCs. The way it separates people from agents is written into a standard, which is why the separation transfers to anyone who adopts it. Review has no such standard. Whatever rule a review runs against is a rule I wrote, and it came out of my own shop. So the argument gets you as far as 'agents need their own door', and no further. What that door checks is something you have to decide for yourself.
Stop reviewing the reviewer
Picture the structure most people reach for: an agent reviews the code, and a person reads what the agent wrote. One reviewer at the bottom, me on top. That is not verification. It is duplication. If I read the same material in the same order, I am not checking the reviewer, I am being a second copy of it, and I already knew from the 'meat proxy' post how that ends.
What the two failures actually taught me is that a reviewer's value lies in its position, not its diligence. What it is handed, in what order, and where its verdict gets written down decide the quality of a review before the reviewer reads a line. So that is what I should be inspecting: not each reviewer, but the position every reviewer stands in. I put a layer above the reviewers whose only job is to make their output trustworthy, and I look at reviewers through that layer instead of one by one.
Today the layer does two things.
It fixes the standard. A reviewer does not judge whether the code is nice, or clever, or how it would have written it. It judges whether the code meets the spec that was written before the work started. That is the whole question.
It removes summaries from the path. What the reviewer found reaches me as it was found, with nothing condensed in between. A summary is a place where someone's judgment gets inserted, and every one of the failures I described happened at exactly that place.
With the standard fixed, I know what a reviewer looked at without asking. With no summary, there is nowhere between its judgment and mine for a distortion to hide. I don't trust ten reviewers one at a time. I trust the one door they all pass through. That is where the trust accumulates, and it doesn't accumulate anywhere else.
Who checks the layer
By now you have the obvious objection ready. Who verifies the layer? Doesn't a layer that checks reviewers need a layer that checks it, and so on upward forever?
I think the objection only works if you believe in a perfect verifier somewhere at the top. There isn't one. My layer is wrong too, sometimes. So the question has to change, from 'who checks the layer' to 'when the layer is wrong, how do I find out, and what do I do about it'. And the two failures are already the answer. On the day the reviewer was beaten four times I did not swap the model. I changed what it was handed: the spec as the standard, the raw findings instead of a digest. On the day the verification evaporated I did not blame the reviewer. I made the merge step check which commit the green light actually belonged to. The layer gets one notch better each time it is breached. Nobody starts with a correct layer. What you end up with is a set of patches over the places that were pierced, and after a while the patches are the layer.
What you can take from this
Not the layer. It is calibrated to my spec documents, my team of agents, and my particular history of getting burned. Copy it into your shop and it will be wrong in a dozen ways I can't predict.
Where a shared rule exists, you get a product. quickstart.id's separation of people and agents transfers because the RFCs underneath it transfer. Where you have to write the rule yourself, you get a process, and a process is personal by nature. The only portable part is the stance: I don't trust this thing, so I will build the door it has to walk through, and I will keep rebuilding that door every time it lets something in.
Two honest gaps.
First, I have no number for any of this. 'Fix it when it breaks' also means 'don't know until it breaks'. I cannot tell you how many bad approvals have passed quietly through a layer that never noticed them.
Second, none of this is a case for human review. People given a summary reach the same borrowed conclusion, and a human's approve button doesn't record its scope either. The one difference is that a person who skimmed usually shows it, and an agent that skimmed never does.
I still don't trust AI. What has changed is that I now have a layer I can hand work to without having to.
Sign in with quickstart.id