What does production-ready mean when AI writes the code?

A vendor tells you the build is production-ready. Ask what you’d have to take on faith to believe it, and the honest answer is usually all of it. The word arrives as an adjective the seller has applied to their own work: there’s a running deployment, it looked right in the demo, the team is confident. None of that is something you can check from where you sit. You can check it after the first incident, which is the wrong time, or you can trust the person who built it, which is not checking. Every shop in the category says production-ready, and they can all say it with equal conviction because the word, the way it’s used, costs nothing to say.

That equal conviction is the tell. A term that every competitor can apply to themselves with a straight face isn’t describing the software; it’s reporting the seller’s mood. Defined so it actually means something, production-ready is not a property of the code at all. It’s a property of the evidence that ships next to the code. A system is production-ready to exactly the degree that someone who doesn’t trust you can confirm what it does without you in the room. That standard is falsifiable, and that’s the entire point of it: a claim you have no way to fail is a claim that was never holding any weight.

The word used to carry quiet collateral, which is why it took this long to notice it was hollow. When a person wrote every line, “production-ready” leaned on a fact nobody bothered to state: someone had held the system in their head while building it, and that person’s understanding was the evidence. Thin and unrepeatable, but real. Machine-generated code removes exactly that backing. Nobody held it. New Relic’s June 2026 State of AI Coding report caught the gap in two numbers: 94% of technology leaders rate AI-generated code as higher quality than human-written code at review, and 78% report more production incidents once it ships. New Relic calls the pattern unverified trust. Read against the word, it says something narrower: the claim survived the shift to generated code, and its collateral didn’t. So “production-ready” now points at nothing unless explicit artifacts stand in for the understanding that used to be implied.

Four artifacts do that standing-in, and the useful way to see them is as answers to four questions the adjective leaves open. Each one converts a thing you’d otherwise have to take on faith into a thing you can re-run.

The first question is the one the word skips entirely: which behaviors the system is actually ready for. “Production-ready” with no inventory behind it means ready for the behaviors the team happened to remember. The artifact that answers it is the behavior catalog: a typed, machine-checkable list of every observable behavior in the system, each entry citing the source it was read from and a note on why. The Bugzilla port we publish runs to 419 catalog entries across five services, and the provenance is enforced rather than asserted: a gate greps the cited excerpt out of the named file instead of trusting that the citation is honest. The cheap imitation is a feature list, which tells you what someone meant to build and nothing about what’s actually there to verify. A catalog excerpt is public, down to entries like attachment.create-attachment.empty-description rejecting with MISSING_ATTACHMENT_DESCRIPTION, traced to Bugzilla/Attachment.pm.

The second question is whether the checking happened, on this build, with what result. Most teams answer it with a green badge, and a green badge proves only that the suite the team chose to write passed; it’s silent on everything the suite never reached. The artifact that answers it properly is the gate transcript: the logged record of every automated check a piece of work passed or failed on its way through the line. A full service in the port moves through roughly 40 gates across about 30 stations, and the transcript keeps the red entries. One of those gates, the assertion floor, rejects a test whose body compiles but asserts nothing, which is the most expensive kind of green there is. A transcript with no failures in it reads as theater; the failures and their reruns are what make the green ones mean something. Green here never claims no human looked. It claims no human had to vouch, which is the property you can actually hand to a stranger.

The third question is whether any of this survives the next change, because production-ready isn’t a state a system occupies once. It’s a property that has to hold through the edit you make tomorrow. The artifact is a regression suite with a baseline to run against, and our name for the strong form is dual-green: the same behavioral suite, projected from a catalog a human approved, running green against two systems at once, the original and its replacement or the system before a change and after it. Dual-green turns “it still behaves the same” from a reassurance into a test result, and a test result is something the buyer re-runs without asking us anything. A suite that’s only ever been green against one system is weaker by exactly the amount of the comparison it skips.

The fourth question is the one almost nobody volunteers: what sits outside the line. Any real coverage is partial, so a coverage claim with no stated edge is a lie of omission dressed as confidence. The artifact is the boundary, stated on purpose. The discovery pass on that same Bugzilla system enumerated seven bounded contexts; five were rebuilt and two, search-and-reporting and administration, were found and deliberately left out of scope. Saying so is not a weakness in the proof. It’s the part that makes the rest of the proof trustworthy, because a vendor who tells you precisely where their coverage stops is a vendor whose “covered” you can believe. The matching internal artifact is the coverage-debt report: the enumerated, classified list of behaviors a system has that its suite doesn’t yet cover, tiered by the level of test each one actually needs. A coverage percentage with no boundary under it is a number doing public relations.

None of the four means anything without a fifth condition holding underneath all of them, and it’s the one most quietly violated: whatever built the system cannot also be what grades it. A builder scoring its own work is back to trust with extra steps. In the production system the machinery that verifies is read-only by construction; it can inspect what was built and it is structurally unable to edit it, so a passing grade is never the grader marking its own homework. Take that separation away and the catalog, the transcript, the suite, and the boundary all collapse back into the same self-applied adjective you started with, just with more pages.

So the standard, stated plainly, is narrow and it doesn’t flatter anyone, including us. Production-ready is reached at the moment you can hand over the artifacts, leave the room, and have the claim survive your absence: the catalog someone can check against the source, the transcript someone can read for the failures it kept, the suite someone can re-run against both systems, the boundary that says where the evidence stops. Everything short of that is a word. The receipts are public, and the test of any vendor who uses the word is the same one you’d apply to us: ask for the gate logs, and watch whether the answer is an artifact or an assurance.