Almost Right

In 2009 a group at Cambridge put volunteers into an fMRI scanner and had them play a simplified slot machine, and the outcome that held their attention was not the win but the near-miss, the reel that stops one position short of the payline. Players rated those spins as less pleasant than an outright loss while simultaneously reporting an increased desire to keep playing, and the scanner showed the ventral striatum and the anterior insula active throughout them, which is the same circuitry that responded when the money was real. Clark and his co-authors described this as the anomalous recruitment of reward circuitry, which is a careful phrase for a brain booking a payout that never reached the ledger.

Sixteen years later Stack Overflow put a survey in front of more than thirty thousand working developers and asked what they found most frustrating about AI coding tools, and the answer that came back at the top of the list, at 66%, was "AI solutions that are almost right, but not quite". The same survey found trust in the accuracy of those tools sitting at 33% against 46% who actively distrust them, with adoption climbing to 84% regardless.

Rising frustration alongside falling trust alongside rising use reads as a contradiction, and treating it as one tends to lead people toward explanations involving hype or peer pressure that do not survive much contact with the developers in question. There is no contradiction in it; what the pattern shows is the ordinary behavioral signature of a particular reinforcement schedule, of which the near-miss is the most efficient unit available.

Because the comparison that follows tends to get heard as an accusation, it is worth being explicit about what does and does not come with it. This is not an argument that AI tools are bad, or that using them indicates some deficiency of character; I use them daily, and the evidence that they pay is at present stronger than the evidence that they do not. It is an argument about a second question that keeps getting folded into the first one — whether you are in any position to know how well they are working for you, specifically, this week — and those two questions have wildly different amounts of evidence standing behind them.

Casinos enter this as a control group rather than as a villain, being the one industry that has studied the mechanism for fifty years with its own revenue riding on the answer, which is why it is documented there more thoroughly than anywhere else. The underlying result goes back to Ferster and Skinner in 1957: rewards delivered after an unpredictable number of attempts produce the steadiest behavior of any schedule and are the hardest to extinguish, so that an action rewarded every single time falls apart quickly once the rewards stop, while an action rewarded unpredictably outlasts them by a considerable margin. Slot design has spent the decades since building upward from that floor, and multi-line machines in particular will return fifteen cents on a twenty-cent wager and run the winning animation and the winning sound anyway, an outcome the industry itself calls a loss disguised as a win and one that players' skin conductance responds to as though they had won rather than lost.

None of this is aimed at the jackpot. Natasha Dow Schüll spent fifteen years among machine gamblers and the people who design for them, and the metric she found the industry organized itself around, from the algorithms through the ergonomics to where the cash machines sit, was never winnings but time on device, meaning the sheer duration of play. It works well enough to show up in the receipts: in the second quarter of 2026 slot machines took $9.77 billion off American commercial casino floors while every table game in the country combined took $2.60 billion, which makes the most heavily engineered game in the building the most profitable one by a factor of close to four.

Nothing about a language model was designed with any of this in view, which is the part that makes the resemblance worth raising at all. These models sample, so identical prompts produce different outputs and whether the next one solves your problem is unpredictable in an architectural sense rather than an adversarial one, and a variable-ratio schedule requires no author, only genuine uncertainty about the next outcome and a button that is cheap to press. The near-miss comes free with that arrangement, and by developers' own accounting it is the single most common thing these systems produce. The Cambridge study carries one detail that transfers with unpleasant precision, which is that the effect appeared only on trials where the player had personally arranged their own gamble; and given that you wrote the prompt, selected the model and decided what went into the context, authorship is operating here as an amplifier rather than as any sort of protection.

The analogy ends at the arithmetic, and it ends there decisively. A slot machine's return is fixed in firmware, so that losing across a long enough run is not misfortune but the machine working exactly as specified, and generative AI has no equivalent number anywhere inside it. DORA's 2025 report found 90% of developers using AI at work at a median of two hours a day and, for the first time in that report's history, a positive association between adoption and software delivery throughput. The payouts are real, which is the whole reason this is worth writing about rather than a reason to stop: a rigged game can simply be walked away from, whereas a game that genuinely pays while running on a schedule that corrupts your reading of it is one you are obliged to measure properly.

What the schedule does, though, has nothing to do with whether you are winning. In 2025 METR ran a randomized trial in which sixteen experienced open-source developers worked 246 real issues in repositories they had contributed to for years, having forecast beforehand that AI would make them 24% faster and reporting afterward that it had made them 20% faster, against a measured result of 19% slower. METR then ran the study again the following year across 57 developers and more than 800 tasks and the sign reversed: the returning developers came out 18% faster, with a confidence interval wide enough to hold both answers without strain. They now describe their own data as "only very weak evidence" and are rebuilding the experiment.

A research organization with randomized assignment, a year of funding and developers timing their own work has produced two results pointing in opposite directions and cannot tell you the magnitude of either, while the developers sitting in the chair required roughly an afternoon to reach certainty and were, in the first study, certain and wrong by about forty points. Whatever the real effect turns out to be, the confidence anyone currently holds about it, mine included, is not arriving from the evidence, because there is not yet enough evidence for it to arrive from; it is arriving from the schedule.

What the schedule takes is not your money but your ability to tell how the session went.

The disagreement between the two instruments can be watched in the open. Developers who adopt AI most heavily report higher code quality, while the repositories those same developers work in show duplicated code blocks up 81% and refactoring line moves down 70% against 2022. Both measurements can be honest at once, given that one of them is taken at the moment of reinforcement, when the diff looks right and the tests have gone green, and the other is taken some months later, from outside, by something that is only counting.

This is where the casino half of the essay becomes the less interesting half, because a slot machine only takes money, whereas what these tools do is stranger and has a much older literature standing behind it. Generation has scaled enormously across three years and verification has not moved at all: a model writes four hundred lines in twenty seconds, and the human capacity to read four hundred lines and know whether they are right is roughly where it stood in 1983, which happens to be the year Lisanne Bainbridge published five pages in Automatica about industrial process control and what goes wrong when you automate most of a job and hand the operator the remainder.

Her central irony was that the more advanced a control system becomes the more crucial the human contribution to it is, and the less capable the human is of supplying that contribution, because automating everything easy to automate leaves the person holding the monitoring — a task humans are measurably poor at — while removing from their day the ordinary practice that kept them competent to intervene. Operators working under automation need more training rather than less, she argued, precisely for the rare moments that matter. The paper has been cited into the thousands, largely by aviation and process safety, fields that took an interest because their failures killed people, and it describes the position of a developer supervising a coding agent about forty years early and without any AI in it.

At this point the two halves of the essay turn out to be a single fact. Output that is almost right is the most reinforcing thing a variable-ratio schedule can produce, which is the Cambridge result, and it is simultaneously the worst available failure rate for anything a human being is supposed to supervise, being good enough that checking starts to feel wasteful and wrong often enough that not checking is how you get hurt. A system that failed loudly half the time would train you to read every line it handed you, whereas a system that fails quietly one time in twenty trains you out of reading altogether, and those are not two problems but one property performing both functions at once.

The evidence thins quickly beyond this, and it is worth being careful about how far the argument can actually be pushed. The best-designed study on the question is Echoes of AI, which ran 151 participants, 95% of them professional developers, under randomization and reached its final form this February; its first phase found AI users completing work with a 30.7% median reduction in time and habitual users nearer 56%, and its second phase handed the resulting code to different developers and found no significant difference in completion time or quality when those developers went on to change it. On the specific fear that AI-written code poisons the well downstream, the strongest evidence currently available finds no detectable effect.

The cognitive claims are a good deal weaker than their circulation suggests. A 2025 survey of 666 people found AI use negatively correlated with critical thinking and mediated by cognitive offloading, which is correlational and self-reported from end to end. The MIT Media Lab EEG study that gave us the phrase cognitive debt ran 54 students, 18 of them through the crossover condition, on a single model, and has since drawn a published rebuttal, with its own authors discouraging the reading that it demonstrates AI making people stupid. Both are better understood as hypotheses with instrumentation attached than as findings. And on whether any of this is addictive in the clinical sense, among developers specifically, nobody has yet looked: the single review of problematic generative-AI use published this year gathers what exists and characterizes it as limited, cross-sectional, culturally constrained and without clinical correlates, and its prevalence figures come from adolescents and students rather than from people doing this forty hours a week for a living.

That absence is the thing I would actually argue about, and it is the one place in this essay where I am handing over an opinion instead of a citation. We have fifty years of gambling research because gambling took money from people who could name the amount and sue over it, and forty years of automation research because aircraft came down, and both literatures exist because the failure in each case was loud, dated and attributable to something specific. Nothing here is going to be loud. What deskilling produces is a profession that is slightly less able every year and in which every individual feels fine, and feeling fine has quietly stopped being evidence of anything, because the feeling is the first thing the schedule takes.

The machine has been almost right all afternoon, which is not the same as the afternoon having gone well, and you are the last person in the building equipped to tell the difference.