TL;DR Yes, I trust the frontier models: I put them through their paces daily, across very different scenarios. That trust is calibrated, which is the opposite of blind — and it proves nothing, because it says something about me and nothing about the software. On regulated healthcare software, quality is a set of properties that must hold on every single change: an audit trail that stands up in court, an identity nobody can forge, accessibility as a legal obligation, interoperability contracts that do not lie. Not one of them depends on who wrote the line. So I stopped defending them by reading diffs and started compiling them. 67 recorded decisions, 39 checks that fail the build, one pre-merge verdict, and exactly one perimeter where the answer is deliberately a human. We measure one thing: which stage each defect is caught at. Two of those stages are still empty — we are not live, and the first on-site tests are weeks away. Review itself is mostly agents reviewing agents; what is left to people is what a machine cannot carry — the legally binding calls and the security ones. The point was never to slow down. It is to go faster and better at once.
Yes, I trust the frontier models. I put them through their paces every day, across very different scenarios, and I know fairly precisely what they produce: where they are excellent, where they drift, what comes back when the brief is bad. There is nothing blind about that trust. It is the product of daily calibration.
And it proves nothing.
My confidence is a fact about me, not a property of the software. It does not transfer, it cannot be audited, and it is worth nothing to someone asking how we guarantee that an audit record gets written. That is why I no longer read diffs line by line, and why I built something else instead.
What quality means here
The software we write — Solstice*, an ERP for a group of French public hospitals — manages patient records. That context sets the whole definition.
Quality here is not a score and not a defect count. It is a short list of properties that have to be true after every change, without exception:
- Writes that can be held against us later carry a legal audit trail, and the write is refused if the trail cannot be written.
- A user's identity is never inferred from something the caller can type.
- Regulated fields are never returned in the clear.
- Accessibility is not a nice-to-have. In French public procurement it is a legal obligation with a named standard.
- The interoperability contract we publish describes what the deployment actually serves.
Not one of those is verified by asking "does the feature work". Each is a property of the system that a perfectly working feature can silently violate. That is the whole problem, and it existed long before agents.
Quality is not the absence of bugs. It is the set of properties that survive the next change.
Why reading stopped being the instrument
Two reasons, and only one is about volume. Volume is real and everyone has said it: more code arrives each week than any team reads with genuine attention.
The second survives even with infinite reading time. Reading a diff is an instrument for finding a wrong line. The defects that get through are usually a missing line, in a file the diff never opened.
You cannot notice an absence in a document that does not contain it.
Almost half our checks exist because the obligation spans files. A resource class announced in the public contract means a service address must be provisioned in the deployment file. A port published next to the gateway silently removes the authentication the gateway performs. The change under review is locally correct; the obligation lives where the reviewer is not looking. That is exactly where human review is weakest and a script strongest.
One finding changed how I read a proposal. A study accepted at MSR 2026 measured that agent-written pull requests carry noticeably more redundant code — and that reviewers rated them more favourably than human ones. Idiomatic, well-commented code buys less suspicion than it has earned. It is plausible before it is correct, and plausibility is what a reviewer stops on.
None of which makes it a new species of defect: a tired engineer forgets the same call on a Friday afternoon. What changed is the rate of the omission and the cost of catching it by reading.
The 4 layers
None of this is a verdict on the models. Those properties have to hold whoever wrote the line — an agent, a senior engineer, or me on a Friday evening. So they no longer rest on anyone's attention. They rest on code that runs.
67 recorded decisions. Dated, versioned, read by every agent before anything structural. They carry the reason — the part an agent otherwise refactors away because it looks like an accident. No human on the team reads all 67. Nor do I.
39 blocking checks, inside 44 continuous-integration jobs. One per property, each born of a real mistake. A single design rule governs them, and it is the only transferable thing in this post: derive the perimeter from the code, never recopy it. A hand-maintained list is wrong one rename later, and it fails silently.
1 verdict before the merge. One command, scoped to the diff, running exactly what the pipeline runs, printing PASS or FAIL. It does not prove the change is good; it converts "please have a look" into a claim someone can check.
1 human perimeter, on purpose. The surface reachable from outside the hospital information system: static entry secret, destructive delete. Review by a non-author, mandatory. We could have written a script; we decided that kind of mistake should cost a conversation.
A word on review, because the word misleads. On my team it is overwhelmingly automated: agents review agents and file a report. The human does not read the lines. The human reads what happened, and owns what a machine cannot own — the legally binding decisions and the security trade-offs.
Responsibility does not delegate to a model.
None of this exists to slow anyone down, and I would drop all of it tomorrow if it did. An executable rule is what lets us merge without a meeting. Speed and quality are not traded against each other here: they move together.
How we prove it
"We have guardrails" is a claim, not evidence. A system that enforces properties has to be measured, or it is just architecture with good intentions.
We measure on one ladder: how many stages a defect clears before something catches it. 6 stages, in order — the build, code review, manual testing, QA, the pilot site, production. Every defect is labelled with the stage that caught it. Everything else we track hangs off that: defect density against merged proposals, time to fix by severity, the reopen rate, the standing backlog.
The last two stages get their own name, and it is the only number I would defend in a steering committee: escaped defects. Anything found at the pilot site or in production escaped every net we own.
This reframes what a guardrail is for. A check is not there to reduce a defect count. It is there to move one class of defect permanently leftward — from "a tester finds it" to "the build refuses it" — and it never moves back. That is why the count of executable rules matters more than the count of bugs. A fixed bug can come back. A written rule cannot.
The question is not how many defects we found. It is how far each one got before something stopped it.
What none of this proves
My confidence does not transfer. It does not exist for the person who joins on Monday, nor for a model I have not put through its paces, nor for me on a subject I know badly. The checks are what remains when my calibration is absent.
It is a ratchet, not a net. 39 checks encode 39 defects already paid for. Each was written after something got through. We cannot repeat 39 specific mistakes — which says nothing about the ones nobody has noticed yet.
The verdict is narrow. PASS means no known rule is violated. The end-to-end phase runs against mocks, never a real database. Several of the defects that taught us most would have sailed through it.
The last two stages are empty because we have not reached them yet. Nothing escaped to a pilot site or to production because there is neither, yet. The first on-site tests are a few weeks away. That is when those two columns start filling, and when I find out what everything above is actually worth. The hardest evidence — what survives real users on real hospital data — is evidence we do not have. Anyone showing a leakage chart with the last two columns empty is showing a calendar, not a result. Including me.
Checks catch the disease they treat. One of ours came from a schema change that only applied to freshly created databases: green in the pipeline, green locally, broken everywhere else. Its first version had a blind spot of exactly the same shape.
Derogations are not counted. About 12 are in use, each with a written reason beside it. Exactly one check counts them over time. Nothing prevents an agent from writing its own exemption to turn itself green. That is the open flaw in everything above, and I have no fix for it.
What still belongs to humans
Being surprised first. Every one of these checks exists because a person felt something was off and went looking. No rule has ever written the first rule.
Deciding what a defect means. That a control cannot be reached with a keyboard is a technical fact. That it puts us in breach of a legal accessibility obligation, and therefore blocks a release instead of joining a backlog, is a judgement.
Judging a derogation. An exemption marked in the code is auditable only if somebody goes and reads it — the marker does not audit itself.
Signing. A legally binding decision commits somebody, and a model cannot be that somebody. That is not a limit of the current generation. It is what binding means.
And the question no check asks: whether the thing should exist at all.
None of this is an argument for fewer people. People are the ones who get surprised first, and being surprised is the only part of this that does not scale by writing more scripts.
What to do Monday morning
- Write down the properties, not the process. Five sentences that must stay true after every change. If you cannot name them, no amount of tooling will protect them.
- Label every defect with the stage that caught it. One field, and the highest-value measurement in this post. Without it you count bugs instead of measuring reach.
- Take one incident you already paid for and make it fail the build this week. Not a policy. One incident, one script.
- Prefer the obligations that cross files, and derive every perimeter from the code. Anything you maintain by hand drifts, and it drifts quietly.
- Count your derogations against a baseline that can only go down. I have one of those. I should have 40.
Read the rest of the series: Doctrine Compounds. Models Don't. — why the rules outlive the models that read them. The Backlog Was Never the Job — who signs when the rule and the judgement disagree. 100% Agent-Written — the verification tax, counted. One More Prompt — why my own sense of speed is not evidence. The LAN Is Dead — the checkbox nobody read. The Skill Was Real. The Seat Wasn't. — testing is not the only skill that stopped needing its own seat.
Sources
- More Code, Less Reuse (MSR 2026): agent-written proposals carry measurably more redundant code, and reviewers rated them more favourably than human ones. Peer-reviewed, no vendor funding. Sentiment is not review rigour — take the direction, not a rate.
- Perry et al., Do Users Write More Insecure Code with AI Assistants? (ACM CCS 2023): assisted participants wrote less secure code and were more confident it was secure. 47 participants, lab setting, a model three generations old. Cite it for the mechanism, never as a current rate.
- Debt Behind the AI Boom (2026): 304,362 metadata-verified agent-authored commits; of the issues found, 89.1% maintainability, 5.8% runtime bugs, 5.1% security. The authors state they ran no human baseline, so it describes the shape of the debt, not a gap against people.
- GitClear — The AI Code Quality Maintainability Gap (2026): duplication up, refactoring down across 623 million changed lines. Calendar-year correlation with no authorship attribution, published by a vendor selling code-quality analytics. Corroboration, not proof.
- Veracode GenAI Code Security (2025, re-tested 2026): 45% of generated samples failed a security check, flat across model generations. Vendor-funded, synthetic prompts, no review and no pipeline in the loop — raw model output, not shipped code. The flat line is the only durable point.
- On the most-quoted number in this debate — the 19% slowdown measured on experienced developers in mature repositories — I wrote what happened when its own authors withdrew the framing, in the post on measuring your own perception. It is not re-argued here.
- Solstice* — the layers, the counts and the measurement ladder come from the repository and its issue tracker. Internal, no links: the codename is fictitious and the real project, its products and its vendor are anonymized. Figures verified on 29 August 2026.