Software Failure Wears the Clothes of Success
Updated
Knowledge on this page was mainly distilled from A Stranger Explained the Future of Programming to Me in 1981.
Software introduced something genuinely new into the world: the thing that runs and is wrong. A program can execute without a single error, render beautifully, return a number, and be false in a way nothing on your screen will indicate. That option was not available with a soldering iron.
Why Physical Systems Are Blunt Reviewers
In electronics, a circuit works, or nothing happens, or something gets warm and you learn a permanent lesson about polarity. The physical world cannot produce a convincing imitation of what you asked for. It has no idea what you were going for, is not impressed by your intentions, and takes no account of how long you spent. It just answers. For most of engineering history, that blunt reviewer was the only one anyone had.
Hardware is not honest all the way down. A board can pass on the bench and fail at temperature. A meter calibrated wrong reads confidently wrong all day. Intermittent faults are real. But the narrower claim survives: physical failure mostly announces itself as failure. Software failure learned to show up wearing the clothes of success.
AI as the Extreme Case
A language model is optimized to produce output that looks like what was asked for. That is a literal description of the training objective. The technology is therefore aimed with unusual precision at producing plausible-looking results, and only secondarily at producing correct ones.
Veracode tested more than a hundred models across eighty coding tasks and found security flaws in 45% of the generated code, while the security pass rate stayed flat through mid-2025 even as the models got functionally better at writing code that works. The models improved at looking right without improving at being right on the dimension that matters most for production safety.
The Perception Gap
The subtler danger is what plausible output does to the person using it. METR ran a randomized trial with experienced open-source developers working on real tasks in repositories they already knew well. They finished 19% slower with AI assistance than without it, but estimated afterward that they had been about 20% faster. The people inside the loop could not feel which direction the effect was pointing, and these were not beginners.
When the output always looks like success, the human ability to detect failure degrades. This is not a tooling problem that better models will solve on their own. It is a structural feature of any system optimized to produce output that matches the shape of what was requested.
Q&A
Does this mean AI-generated code is always unreliable?
No. The claim is narrower: AI-generated code can be wrong in ways that are harder to detect because the output is optimized to look correct. Functional quality has been improving steadily. Security quality and edge-case handling have not kept pace, which is the gap that matters.
How is this different from bugs in human-written code?
Human-written bugs also hide, but the developer usually has a mental model of the code's structure and can reason about where failures might occur. With AI-generated code, the developer often lacks that mental model entirely because they did not write the logic. The code arrived plausible and complete, reducing the instinct to interrogate it.
What was the METR study design?
METR conducted a randomized controlled trial with 16 experienced open-source developers working on real tasks in repositories they already maintained. Half the tasks were done with AI assistance and half without. Measured completion time was 19% slower with AI, while self-reported estimates said 20% faster. The gap between perception and reality is the key finding.
Can better prompting or review processes close this gap?
Review processes help, but the structural challenge remains. LinearB analyzed 8.1 million pull requests and found AI-generated ones waited 4.6 times longer before a reviewer picked them up and merged at 32.7% compared to 84.4% for human-written code. The downstream cost of review is real and does not vanish with better prompts.
Is the plausible-output problem unique to coding?
No. Any domain where a language model produces output, whether legal drafts, medical summaries, or financial analysis, inherits the same structural property: the output is optimized to look like a correct answer. The coding domain simply has the clearest measurements because software either works in production or fails there observably.