In the 1980s, a Munich taxi company ran an experiment that belongs taped to every engineering manager's monitor. Half its fleet got a brand-new safety device—anti-lock brakes, then cutting-edge. The other half kept ordinary brakes. The obvious prediction: the cars that couldn't skid would crash less.

They didn't. The cabs with anti-lock brakes crashed at the same rate as the ones without. Researchers riding along found out why. The drivers who knew they had better brakes followed closer, drove faster, and left their braking later. They spent the new safety margin on speed.

That swap has a name—the Peltzman effect—and it is the most important idea your team has never been taught. Because right now you are installing the biggest safety device in the history of knowledge work: AI that reviews your code, drafts your follow-ups, and promises to catch what you miss. The Peltzman effect predicts exactly how your team will respond to that net. This piece explains what the effect really is, why your safety tools quietly lower everyone's guard, how AI supercharges the problem, and what to do that doesn't involve ripping the guardrails out.

What the Peltzman effect actually is (and isn't)

The Peltzman effect is the tendency of people to respond to a safety improvement by taking more risk—spending the safety gain instead of banking it. It is the clearest workplace example of a broader idea called risk compensation: people, as one standard definition puts it, "adjust their behavior in response to perceived levels of risk, becoming more careful where they sense greater risk and less careful if they feel more protected."

The effect is named for economist Sam Peltzman, who in 1975 studied what happened after the U.S. mandated seat belts and other auto-safety features. Deaths per accident fell, exactly as designed. But total highway deaths barely moved, and fatalities among pedestrians and motorcyclists—people with no seat belt to protect them—rose. Peltzman's explanation was blunt: "Because seat belts reduce the likelihood that drivers are harmed if they crash, they encourage more reckless driving." The protected drove harder; the unprotected paid the bill.

Here is where almost everyone gets the Peltzman effect wrong. They hear "seat belts don't work" and dismiss the whole thing—and Peltzman himself spent fifty years correcting that caricature: "I never say you shouldn't wear a seat belt. People have taken me to be anti–seat belt. That's ridiculous." The honest version is narrower and far more useful. A safety device triggers some offsetting behavior. Sometimes that offset is small, sometimes large, rarely total. Later research found the behavioral adaptation "generally offsets less than half of the direct effect"—meaning the nets usually still win, just by less than the brochure promised. Seat-belt laws really did cut occupant deaths. The point isn't that protection fails; it's that you cannot model the protection without modeling the behavior it changes.

The safety thermostat: risk homeostasis and automation complacency

Why does the offset happen at all? Psychologist Gerald Wilde proposed that each of us runs a kind of internal thermostat for danger. We "accept a particular level of subjectively evaluated risk to our health and safety in order to gain from a range of benefits," and when something makes one part of life feel safer, we unconsciously turn the dial up somewhere else to hold that comfort level steady. He called the strong version risk homeostasis. You don't decide to do it. The thermostat moves on its own.

Don't oversell it, though. The thermostat isn't iron. When researchers put radar guns on skiers, helmet wearers did not ski faster or take bigger lines—if anything, they were a touch more cautious. Risk homeostasis is a tendency, not a law, which is exactly why some safety gear pays off in full and some gets partly eaten. The manager's job is to know which kind of net you just handed your team.

The most dangerous nets are the ones that also remove your attention. That mechanism has its own name in human-factors research: automation complacency. In a foundational 2010 review, Raja Parasuraman and Dietrich Manzey showed that when people supervise an automated system they trust, they stop watching it closely—"automation complacency occurs under conditions of multiple-task load, when manual tasks compete with the automated task for the operator's attention." The unsettling part for any team lead: it "is found in both naive and expert participants and cannot be overcome with simple practice." Seniority does not save you. As one engineer put it on Hacker News, "Automation doesn't make operators more careful. It makes them forget how to be. The more reliable the system, the less ready the human."

This is close to two ideas you may already know, but distinct from both. It is not the moral hazard of someone taking risks because another party will eat the cost—here your team still owns the outcome; they just feel safer than they are. And it is not iatrogenic harm, where the fix itself directly does damage—the guardrail works fine; it's the behavior around it that erodes the benefit. The Peltzman effect is its own animal: the net does its job, and the team quietly spends the savings.

AI is the biggest safety net you ever installed

Now point all of that at the tool you deployed last quarter.

An AI coding assistant, an automated test suite, an AI meeting notetaker, an auto-rollback pipeline—each one is sold as a safety net. Ship faster; the AI will catch it. And by the logic of the Peltzman effect, "the AI will catch it" is the most expensive sentence in your codebase, because it is precisely the belief that makes people stop catching things themselves.

We don't have to guess about this. Stanford researchers ran a controlled study, Do Users Write More Insecure Code with AI Assistants?, and found two things at once. Participants with an AI assistant "wrote significantly less secure code than those without access." And—this is the Peltzman effect in a single sentence—those same participants "were more likely to believe they wrote secure code." Worse output, higher confidence. That is not a productivity story; it is a risk-compensation story.

The confidence gap shows up in the wild, too. In mid-2025 the research group METR ran a clean randomized trial with 16 experienced open-source developers across 246 real tasks. The developers expected AI to speed them up by 24%. Instead, the work took 19% longer with AI. The kicker: even after living through the slowdown, they still believed AI had made them 20% faster. The felt safety—"I've got an AI copilot"—stayed high while the real margin went negative. This is the same AI over-reliance trap behind trusting the instrument instead of looking out the window; the Peltzman effect just explains why the gauge feels so trustworthy.

The receipts: when the net makes the work worse

If risk compensation were only a feeling, you could ignore it. It isn't. It shows up in the artifacts.

Google's 2024 DORA report, the largest annual study of software delivery, found that as AI adoption rose, teams saw "an estimated decrease in delivery throughput by 1.5%, and an estimated reduction in delivery stability by 7.2%." More AI, less stable delivery—even as more than 75% of respondents said they rely on AI for at least one daily task, and 39% reported "little to no trust" in AI-generated code. (DORA is correlational, so read it as a pattern, not a proof.) Veracode's 2025 security analysis is starker: across tens of thousands of tests, AI models introduced vulnerabilities from the OWASP Top 10 in 45% of cases, and when handed a choice between a secure and an insecure approach, "chose the insecure option 45 percent of the time." The net you're trusting to catch security bugs is, much of the time, the thing planting them.

The behavior leaves fingerprints in the code itself. An analysis by GitClear of 211 million changed lines found that copy-pasted code climbed from 8.3% to 12.3% as AI tools spread, while refactoring—the careful act of finding a cleaner solution—fell from 25% of changes to under 10%. Less searching for the better answer, more accepting the first one the net waved through (the same pull toward the first familiar option we covered in the Einstellung effect). None of this is fringe: 84% of developers now use or plan to use AI in their work. The safety net is everywhere, and so is the compensation. One engineer described the loop exactly: "engineers will rubber stamp AI suggestions to hit their metrics instead of actually reviewing the code. You can't optimize for quantity of AI usage and quality of output at the same time."

How to keep guardrails without going reckless

The wrong lesson from the Peltzman effect is "rip out the safety nets." That's the seat-belt overreaction Peltzman spent his career disowning. Good guardrails—tests, reviews, rollbacks, AI assistance—genuinely catch real failures. The goal is to keep the net and keep the vigilance it tempts you to drop. A few plays that work:

That last point is why we built Coommit around a shared canvas instead of a black box. When the contextual AI works alongside the conversation—its suggestions, its sources, and the paths it discarded all visible on the board—the team stays in the loop instead of rubber-stamping a tidy output. It doesn't disable the Peltzman effect; nothing does. But it keeps the net from also taking your eyes off the road.

Conclusion

The Peltzman effect has been redistributing risk for half a century, from Munich taxicabs to the modern sprint board. The mechanism never changed: make people feel safer, and they spend the safety on speed. What changed is the size of the net. AI is the most powerful "I've got you covered" tool ever shipped to knowledge workers, and it has arrived in nearly every workflow at once—pointed, by default, at the exact moments where one unchecked answer does the most damage.

The teams that win the next few years won't be the ones with the most guardrails. Everyone will have those. They'll be the ones who installed the net and kept their hands on the wheel—who treat "the tool will catch it" as the start of a conversation, not the end of one. Ask your team one question this week: where have we quietly stopped looking, because something else is supposed to be watching?