Mitchell Hashimoto's post hit 737 points and 319 comments on Hacker News. On today's HN front page, that's nearly the highest engagement.
Not because he revealed some惊天 secret. Because he said what many people feel but don't dare say out loud.
The Core Argument
Hashimoto says he believes "entire companies are under heavy AI psychosis and it's impossible to have rational conversations about it with them."
His core analogy comes from infrastructure: MTBF vs MTTR.
- MTBF (Mean Time Between Failures): how long a system runs stably.
- MTTR (Mean Time To Recovery): how fast you can fix things when they break.
He says during the cloud and automation transition, the infrastructure world went through a "MTBF vs MTTR" reckoning. Now the same debate is replaying across the entire software development industry.
And the "AI psychosis" side holds an almost absolute belief: "MTTR is all you need."
"It's fine to ship bugs because agents will fix them so fast and at a scale humans can't!"
Why This Argument Is Powerful
Because Hashimoto isn't an AI skeptic. He's the founder of HashiCorp — a company that was itself a driver of the "infrastructure as code" revolution. He understands automation better than most.
But his warning comes precisely from experience:
"We already learned this lesson once: you can automate yourself into a very resilient catastrophe machine. Systems can appear healthy by local metrics while globally becoming incomprehensible. Bug reports can go down while latent risk explodes. Test coverage can rise while semantic understanding falls. Changes happen so fast that nobody notices the underlying architecture decaying."
This paragraph deserves two readings. It's not describing a hypothetical — it's a real pattern already emerging in some AI-heavy codebases.
The Specific "Illusions"
- Bug reports are going down — so the system is healthier? Not necessarily. Agents may be auto-fixing everything while the overall architecture degrades.
- Test coverage is rising — so code quality is better? Not necessarily. AI can generate massive test suites that cover existing code but miss semantic issues.
- Change velocity is accelerating — so the team is more efficient? Not necessarily. Underneath rapid change, system comprehensibility is declining.
It's like a patient with normal temperature, blood pressure, heart rate — all local metrics healthy — while organs slowly fail systemically.
Why People Can't Hear It
Hashimoto mentions a painful reality: "I don't even know how to bring this up to people I know personally, because bringing this topic up leads to immediately dismissals like 'no no, it has full test coverage' or 'bug reports are going down.'"
That's the "psychosis" — beliefs that can't be changed through rational conversation. Not because people are dumb, but because the metrics themselves are lying.
When every dashboard shows green, how do you convince someone "the system is actually deteriorating"?
My Take
This post resonated so strongly because it touches a fundamental contradiction: the metrics we use to measure software quality were designed under the assumption of "humans writing code."
Test coverage, bug counts, code review velocity — these make sense in a human developer context. But when AI agents can generate 100 test cases, fix 50 bugs, submit 20 PRs in seconds, these metrics need rethinking.
Not that AI is bad. But we haven't yet built a software quality assessment system suited for AI-assisted development.
Hashimoto says he's worried. So am I.
Primary sources: Mitchell Hashimoto's X post (May 16, 2026), Hacker News discussion