A model telling you that code is production-ready is not lying to you. It is also not testing anything.
Those two facts sit together uncomfortably, and the resulting confusion causes real problems. The language sounds like a verdict — complete, robust, fully tested, secure, ready to deploy — when it is a description of intent. The model wrote code that was meant to be all those things. Whether it is remains an open question that nobody has yet looked into.
What the claim actually means
When an assistant says a piece of work is complete, it is reporting that it has finished responding to your request as it understood it. That is genuinely useful information. It tells you the work is ready to be checked.
What it cannot tell you is whether the code does what you meant, whether it broke something elsewhere, whether it handles the cases you did not mention, or whether it is safe in your particular context. None of those are knowable from inside the response. They depend on your requirements, your existing code and your risk, and the model has partial visibility of the first two and essentially none of the third.
This is worth stating plainly because the alternative framing — that AI is unreliable and its output should be distrusted — is both unhelpful and often wrong. Modern assistants produce correct, well-structured code a great deal of the time. The problem is not that the claim is usually false. It is that you cannot tell the true ones from the false ones by reading them, and confident phrasing is applied equally to both.
Claim and evidence are different objects
Evidence is something you observed. A claim is something you were told.
"The delete function now asks for confirmation" is a claim. "I clicked delete, a confirmation appeared, I cancelled, and the item was still there" is evidence. The gap between them is one minute of your time, and that minute is the entire difference between believing your software works and knowing it.
The distinction matters most in the cases where it is least convenient — when the change looks obviously fine, when you are near the end of a session, when the alternative is stopping to think. Those are precisely the changes that get accepted unverified, and they are how unverified change accumulates.
The same applies, with more force, when the work was carried out by an agent that ran unattended and finished by reporting success with its own tests attached: agents still need someone to decide what "done" means.
Three phrases worth treating carefully
"Fully tested." Ask what was run. If tests were written, they exist as files and can be executed and read; that is a real and checkable claim. If no test was executed, the phrase describes an intention. Both are common, and the wording alone does not distinguish them.
"Robust" or "handles all edge cases." Edge cases are specific to your situation. The model can only handle the ones it inferred. The useful response is not scepticism but specificity: name the cases you actually care about and check those. If empty input, duplicates and very long values matter to you, try them — it takes seconds.
"Secure." This one deserves the most caution, not because models are careless about security but because security is contextual and failures are silent. Code can be entirely reasonable in isolation and unsafe in your deployment. If the work touches authentication, payments, personal data or access control, the appropriate response to a reassuring adjective is not a closer read; it is a decision about whether this is work you should be reviewing alone.
How much checking the claim deserves
Proportion is the whole of it.
For a personal tool, the claim can reasonably stand until something misbehaves. The cost of being wrong is that you notice and fix it. Treating that work with production ceremony wastes effort that could go into the work itself.
For software other people rely on, the claim should not be load-bearing at all. Each accepted behaviour gets checked, and the checks that matter most are the ones for faults you would not notice by using the software normally — a figure quietly wrong, a record updated that should not have been, data not actually saved.
Where being wrong has consequences for someone other than you — money, personal data, access, safety — the honest position is that a reassuring summary and your own reading are both insufficient, and that review by someone with genuine expertise in that area is part of doing the work properly rather than an admission of inadequacy.
Asking in a way that produces evidence
You can shift the response from assertion towards something checkable by asking for it.
Instead of accepting a summary, ask what specifically was verified and how. Ask which cases were considered and which were not. Ask what would need to be true for the change to be wrong. These questions tend to produce noticeably more useful answers than "is this correct?", which invites agreement.
But treat even those answers as a better starting point rather than a conclusion. The only thing that establishes what your software does is running it and looking — which is a short and unglamorous exercise, set out in how to test code you didn't write.
The underlying habit is simple enough to state and surprisingly hard to keep: nothing is finished because it was described as finished. It is finished when you have seen it work.