AI Psychosis Is Real — MitchellH's Warning Every Developer Should Read

"I strongly believe there are entire companies right now under heavy AI psychosis and it's impossible to have rational conversations about it with them."

This isn't some random Twitter hot take. It's Mitchell Hashimoto — the creator of Vagrant, Packer, Terraform, and co-founder of HashiCorp — speaking from two decades of infrastructure engineering experience.

His post hit 658 points on Hacker News and 254K+ impressions in hours. And it's resonating because he's been here before.

The MTBF vs MTTR Lesson We Already Learned

Mitchell draws a direct parallel to the cloud infrastructure transition:

"I lived through the great MTBF vs MTTR reckoning of infrastructure during the transition to cloud and cloud automation. All those arguments are rearing their ugly heads again."

MTBF (Mean Time Between Failures) — build systems that rarely break. MTTR (Mean Time To Recovery) — build systems that recover fast when they do break.

During the cloud migration, the industry swung hard toward MTTR. "It's fine if things break — we can fix them fast with automation." And it worked — until it didn't. Companies automated themselves into systems that were resilient in local metrics but globally incomprehensible.

The AI Version of the Same Mistake

Today's "AI psychosis" takes the same form:

"It's fine to ship bugs because the agents will fix them so quickly and at a scale humans can't do!"

Sound familiar? It's the MTTR mentality applied to code quality. The arguments Mitchell hears when he tries to raise concerns:

• ❌ "No no, it has full test coverage"
• ❌ "Bug reports are going down"
• ❌ "Our velocity has never been higher"

These are local metrics that mask global decay.

What Actually Happens

Mitchell's warning is worth quoting in full:

"We already learned this lesson once in infrastructure: 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 is the real danger of AI in software development. Not that AI writes bad code — but that AI lets you write bad code faster, and the speed masks the decay.

How to Use AI Without Losing Your Engineering Discipline

The answer isn't "don't use AI." The answer is use AI with the same discipline you'd apply to any engineering tool.

✅ Do This

1. Review AI-generated code like you'd review a junior developer's work Tools like GitHub Copilot and Cursor are incredible accelerators. But treat their output as a first draft, not a final product. Every line needs human review.

2. Maintain semantic understanding Use Claude or ChatGPT to explain why code works, not just to generate it. If you can't explain the architecture, you don't understand it — and that's how decay starts.

3. Keep your monitoring and observability Tools like Sentry and SonarCloud catch what AI agents miss. Don't let "bug reports are going down" fool you — make sure you're measuring the right things.

4. Use AI for what it's good at

• Boilerplate code → ✅ AI
• Test generation → ✅ AI (with review)
• Architecture decisions → ❌ Human
• Production debugging → ❌ Human (with AI assistance)

❌ Don't Do This

• Ship AI-generated code without review
• Let AI agents auto-fix production bugs
• Measure success by velocity alone
• Assume test coverage = code quality

The Bottom Line

MitchellH's warning isn't anti-AI. It's pro-engineering discipline. The same lessons we learned in infrastructure apply to AI-assisted development:

Speed without understanding is not progress. It's just faster decay.

The companies that win with AI won't be the ones that use it most aggressively. They'll be the ones that use it most responsibly — with the same rigor, review, and architectural thinking that built great software before AI.

---

Browse our curated list of AI development tools — from code assistants to monitoring and testing tools.