Insight
Why AI writes the code and a check decides if it ships.
Most of the code behind the site you are reading was written by a model. That is not the interesting claim.
Open the diagram description
A diagram in three parts on a near black background with a single acid green accent. The top row shows a straight path of three panels reading left to right. The first panel, labelled written, says that a model is very good at producing something plausible. An arrow points right to the second panel, which is outlined in acid green and labelled the gate. It says the gate refuses to build on a claim it may not publish, and that it scans both the source and the emitted HTML. A second arrow points right to the third panel, labelled outcome, which says shipped or refused, and that what ships has been refused at least once, on purpose. Below that row runs a horizontal rule with one arrow rising from its middle up into the gate panel, captioned what makes it worth anything. Under the rule, a band headed before the rule is trusted shows four numbered steps reading left to right, joined by arrows. Step one, plant: put a violation into the source. Step two, run: run the build that scans source and the emitted HTML. Step three, watch: watch it fail, read the message, and check that it names the right rule. Step four, restore: restore the file with the hash compared, to prove the restore was exact. At the bottom left, a box drawn in a faint dashed grey outline stands for a signal that was never produced. It is labelled never observed failing, and reads, a rule nobody has tested. To its right, beside a vertical accent bar, two lines read: ask what would have to break for this check to notice, and, if the answer is nothing, the check is a comment.
On its own it is not a claim worth making: a lot of code is written that way now, and a fair amount of it should not have shipped. The interesting part is what happens between written and shipped.
What actually decides whether something ships?
A gate that has been watched going red.
This site refuses to build on a claim it may not publish. There is a table of forbidden strings and required strings, and the build scans both the source and the emitted HTML for them. That much is ordinary. What makes it worth anything is the discipline around it: before a rule is trusted, somebody plants a violation, runs the build, watches it fail, reads the message to check it names the right rule, and restores the file with a hash comparison to prove the restore was exact.
A rule that has only ever been observed passing is a rule nobody has tested. The same is true of every test in every suite, and it is the single most useful thing I have learned from doing this at speed.
What goes wrong when a machine writes quickly?
Not the code. The checks.
Every serious defect this project has shipped was an assertion that read as a check and enforced less than it appeared to. A subject that could be empty, so the loop ran zero times and reported clean. A check satisfied by a copy of the thing it was checking. A registration verified by grepping the entry point’s text. A word-boundary class that admitted a hyphen, so a phrase with a hyphen in it walked through a ban that caught the spaced form. A check that no runner invoked at all, which is worse than a red one: a red check is loud and gets ignored, an uninvoked one reports neither green nor red.
Every one of those passed review. Reading would not have found any of them. What found them was breaking the thing the assertion protected and watching what happened.
Is the model the problem?
No, and framing it that way is how people end up with the wrong process.
A model is very good at producing something plausible, and plausible is exactly what a reviewer’s eye accepts. That is a property of the reviewer as much as of the model, and the cure is the same in both cases: stop reviewing by reading and start reviewing by breaking. The model is a component. The system is the gate around it, and the gate is what a client is actually paying for.
I do not sell speed. The archive would not support it: I have two attempts at the same product sitting in a folder with twenty-six thousand lines of planning between them and no deployment at the end of either. What I sell is that the thing which ships has been refused at least once, on purpose, by something that is still capable of refusing it.
Ask what would have to break for this check to notice. If the answer is nothing, the check is a comment.
Gates that have been seen red
Which of your checks has ever actually failed?
Tell me what would have to break before one of your checks noticed. I will tell you what I would look at first.
Send Dan a message on WhatsApp (opens in a new tab)or email dan@burdetsky.xyz