Hanlon's Razor: Assume Error Before You Assume Malice
Table of contents
The deploy goes out, and ninety seconds later your service is throwing errors it was not throwing before. You check the commit log and the only change is a merge from the one teammate you have been quietly annoyed with all week. The thought arrives before you can stop it: they knew this would land on me. You are already half-composing the message, the one with the cold, careful politeness that means you are furious. Then you actually read the diff. They renamed a field three layers down, the kind of rename nobody traces by hand, and the break is honest. There was never a plan. There was a person moving fast who could not see your corner of the system from where they stood.
There is a rule for the gap between the explanation you reached for and the one that was true, and it is more useful than its blunt wording suggests. It is Hanlon's razor, and most write-ups give you the slogan and a traffic anecdote and stop. What is worth more is seeing what it actually decides (how to read the cause of a bad outcome, not whether someone is a good person), how it differs from the razors it gets shelved next to, why generated text and automated systems have made it a daily working tool rather than a cynic's comfort, and what it means for the terse, half-finished claims sitting in your own notes. Here is Hanlon's razor in full, with a comparison table, worked examples, and the version running quietly against your past self.
What is Hanlon's razor?
Hanlon's razor is an adage stating that you should never attribute to malice that which is adequately explained by stupidity, or, in its less insulting and more usable forms, by incompetence, ignorance, haste, or a broken system. The specific phrasing was popularized by Robert J. Hanlon, who submitted it to a 1980 collection of Murphy's Law jokes, though the thought is old: Goethe and others reached for versions of it long before it had a name. A razor, in philosophy, is a rule of thumb that lets you shave off an unpromising line of reasoning without chasing it down. This one shaves off the reflex to read hostile intent into outcomes that a plain mistake already covers.
The core of it is a rule about which explanation to reach for first. When something goes wrong in a way that affects you, two accounts are usually available: someone did it on purpose, or someone (or something) erred. Hanlon's razor says the error explanation is the better default, not because people are never malicious, but because mistakes, oversights, miscommunication, and bad incentives are vastly more common than coordinated ill will, and they cost far less to produce. The razor does not claim malice never happens. It says you should not assume it until the evidence for intent is actually there, and that treating "this hurt me" as proof of "this was aimed at me" is a predictable error in its own right.
Why error is the better default
The razor looks naive until you count the two explanations honestly. Malice requires a lot: someone has to notice you, model how an action would affect you, decide to cause that effect, and then act on it, all while the ordinary friction of work gives them a hundred easier things to think about. Error requires almost nothing. A rename nobody traced, a Slack message read in the wrong tone, a config copied from a stale example, a deadline that squeezed out the double-check. The base rates are not close. In any system with more than a few people in it, the overwhelming majority of the outcomes that feel personal were produced by someone who was not thinking about you at all.
Assuming malice is also expensive in a way that compounds. It poisons the next interaction before it happens, it spends your attention on a conflict that does not exist, and it makes you worse at finding the real cause, because "they did this on purpose" closes the investigation while "something broke" keeps it open. Many of the outcomes that look like somebody's bad intent are better explained one level up, as the product of a structure or an incentive rather than a villain: the system rewarded the behavior that hurt you, and the person was just standing where the system put them. Reaching for malice skips past all of that. It is the costliest explanation masquerading as the obvious one.
Hanlon's razor versus the other razors
The razors get stacked in the same mental drawer and pulled out interchangeably, which is how people misuse all of them. Each shaves off a different unpromising move and answers a different question. The table sorts the ones that come up most, plus Grey's law, which is the honest limit on Hanlon's.
| Principle | One-line form | What it decides | Use it when |
|---|---|---|---|
| Hanlon's razor | Never attribute to malice what is adequately explained by error | How to read the cause of a bad outcome | An outcome looks hostile and you are about to assume intent |
| Occam's razor | Prefer the explanation with the fewest assumptions | Which of several explanations to favor first | You are choosing between competing accounts and want the simplest |
| Hitchens's razor | What is asserted without evidence can be dismissed without evidence | Who carries the burden of proof | A claim arrives with nothing behind it |
| Grey's law | Sufficiently advanced incompetence is indistinguishable from malice | When the error framing stops mattering | The harm repeats after it has been flagged, regardless of intent |
Hanlon's razor is really Occam's razor pointed at human behavior: malice is the explanation with more moving parts, so it needs more evidence before you prefer it. The row that keeps Hanlon honest is the last one. Grey's law notes that past a certain point the distinction between malice and incompetence stops paying rent. If a person or a team keeps producing the same harm after being told, the question of what is in their heart becomes academic; the outcome is the same and so is your response. Hanlon's razor is a default for the first occurrence, not a permanent excuse, and a sharper, evidence-based cousin governs the moment someone actually offers proof of intent: once evidence is on the table, you weigh it rather than wave it away.
Hanlon's razor in the age of AI
Hanlon's razor earned its first fame in software. It spread through the Jargon File in the 1990s as a reminder that weird bugs and server glitches are honest coding mistakes, not sabotage, and the reflex it corrects is the same one every on-call engineer knows: the outage looks deliberate because it is so perfectly timed, and it never is. The place the razor earns fresh keep now is one step past that, in how people read the output of AI systems.
When a model gives you a confidently wrong answer, invents a citation, or ignores an instruction you gave it clearly, the language that comes to mind is the language of intent. It lied to me. It is being lazy. It is hiding the real answer. That framing feels natural because the output arrives in fluent, human-sounding sentences, and we read intent into anything that talks. But there is no one in there to have an intent. A model has no plan for you, no agenda, no capacity for malice; it produced a wrong token sequence the same mechanical way it produces a right one. Attributing the error to deception is Hanlon's razor failed in a new setting, and it leads you to exactly the wrong response: arguing with the system, or distrusting it theatrically, instead of treating the failure as what it is.
Reframing the wrong answer as error rather than malice changes what you do next. You stop demanding the model confess and start building the guardrail: narrow the prompt, supply the missing context, and above all check the claim against something real before you let it into your work, because a mistake you can catch is more useful to plan around than a betrayal you can only resent. It also keeps your trust calibrated correctly. A model that was confidently wrong once is not out to get you, but it has shown you something about its reliability on that kind of question, and the right lesson is the measured distrust you would apply to any source you have caught being wrong, not a story about bad faith. Error is a property you can engineer around. Malice is a story that leaves you helpless.
Examples: applying the razor
The razor is easy to nod along to and easy to abandon the moment something stings, so it helps to see it run against the outcomes that actually cross a working day. In each case the first move is the same: before you assume intent, ask whether a plain error already covers it.
| The outcome | The malice reading | What the razor says |
|---|---|---|
| A teammate's merge breaks your service | They knew this would land on me | A rename they could not trace to your code. Assume error, read the diff. |
| A reviewer leaves a terse, blunt comment | They are being hostile | Terse usually means busy, not cruel. Read it as haste before contempt. |
| An AI tool ignores an explicit instruction | It is being deliberately unhelpful | No intent exists to be unhelpful. Treat it as a limit, fix the prompt. |
| A vendor ships a change that breaks your integration | They are trying to lock us in | More likely nobody modeled your use case. Assume oversight, then confirm. |
| A colleague omits context you needed | They are withholding to look smart | Missing context is the default state of handoffs, not a power play. |
| The same bug ships for the third time after you flagged it | They do not care | Grey's law. Intent stops mattering; treat the pattern as the problem. |
The pattern across the rows is that the razor almost never asks you to decide someone is good. It asks you to spend the first explanation on error, because that is where the odds and the cheap fix both are. Five of the rows resolve to a mistake and a concrete next step. The last one is the exception that proves the edge: once the harm repeats after a warning, Hanlon's razor has done its job and hands off to the pattern, which you treat on its outcome regardless of what anyone intended.
How to apply Hanlon's razor well
The razor is a reflex worth building, and a few habits do most of the work.
Reach for the boring explanation first. Before you draft the pointed message, list the ways this could have happened with nobody meaning it. There are almost always several, and one of them is usually right. The habit is not to deny that malice exists; it is to make error your first hypothesis and malice the one that has to earn its place, which is the reverse of what stress does to you.
Let intent back in when evidence actually appears. Hanlon's razor is a default, not a blindfold. If someone shows a clear pattern, a motive, and an action that fits only the hostile reading, the default has been overcome and you should act on what the evidence says. Using the razor honestly means applying it to the ambiguous first case and dropping it the moment real signs of intent are on the table.
Separate "not malicious" from "not a problem." A mistake can be as damaging as an attack, and reading it charitably does not mean ignoring it. The point of the error framing is to route you toward the fix (the broken process, the missing context, the unclear spec) instead of toward a fight. Deciding which bad outcomes are even worth a full investigation is its own call, made deliberately rather than by the heat of the moment.
Point it at systems, not just people. The most useful version of Hanlon's razor widens from "this person erred" to "this system let the error through." A bad outcome is often nobody's mistake in particular and the predictable shape of how the work is organized: the handoff with no owner, the deploy with no check, the incentive that rewarded speed over care. That reframe turns blame into a design problem you can actually solve.
The version hiding in your own notes
The sharpest place to turn the razor is inward, on the notes your past self left you. You open a note from six months ago and it says, flatly, "don't use the batch endpoint." No reason, no context, no link. The reflex is a small, familiar irritation at past you: why would you write that and not say why, what were you thinking. That irritation is a tiny malice reading aimed backward in time, and it is wrong for exactly the reason the razor describes. Past you was not withholding. Past you was moving fast, the reason was obvious in the moment, and the context was the first thing to evaporate.
The fix is structural, not a matter of being kinder to yourself. A note that carries its own reason survives the gap; a bare instruction becomes a claim you have to re-litigate or nervously ignore every time you meet it again. This is the same failure that lets a line that was once well-grounded harden into a stale rule you follow without knowing why, and it is the private version of the terse teammate: the information was never hostile, it was just incomplete, and the cost landed later. The same charity you extend to a colleague's blunt review, you owe your own records, and the way to pay it is to capture the reason with the instruction while the reason is still in front of you. A stale internal doc is the team-scale version of the same thing, which is why an out-of-date page is better read as neglect than as a trap.
When Hanlon's razor does not apply
The razor gets overextended, so the guard matters. It is narrow on purpose, and it has two failure modes at opposite ends.
The first is using it to excuse the inexcusable. Real malice exists; fraud, harassment, and deliberate sabotage are not hallucinations, and someone who keeps "accidentally" doing the same harmful thing is described by Grey's law, not protected by Hanlon's. The razor applies to the first ambiguous case, not to a pattern that has already announced itself. When evidence of intent is genuinely present, invoking the razor is no longer charity; it is looking away. The second failure is subtler: treating "not malicious" as "not serious." An error can do real damage, and reading it charitably is only the first step, the one that gets you to the actual cause instead of a grievance. Hanlon's razor is a tool for finding the problem faster, not a reason to let it stand. Point it at the ambiguous outcome in front of you, extend the error assumption exactly once, and let both the evidence and the pattern take it back from you when they have earned it.
Getting started
Hanlon's razor is not a way to think the best of everyone. It is a way to stop spending your attention on conflicts that were never there, and to get to the real cause of a bad outcome faster than resentment ever will. The test is small and mechanical: when something goes wrong and feels personal, reach for the boring explanation first, hold the malice reading until the evidence for intent actually shows up, and when a harm repeats after a warning, stop asking what anyone intended and treat the pattern itself. It is most valuable exactly where intent is easiest to imagine and hardest to confirm, which today means the confidently wrong output of a system that has no intent at all.
Start with your own knowledge base, where the terse, context-free notes are quietly the ones you are hardest on. Capture each claim with its reason, a line on why you believed it and what it depends on, so a note does not come back months later as a bare instruction you resent or ignore. Read a confusing past note as a mistake to recover from, not a failure to judge. And treat a wrong AI answer as an error to engineer around rather than a betrayal to argue with. Try Scribelet free and let it keep your notes with their reasons attached, and check them against the world, so the context you had today is still there the day the note is all you have left.
Share this article