Hashimoto coined the term 'AI psychosis' to describe entire companies operating under a collective delusion about what AI can do today. As a respected infrastructure engineer and HashiCorp co-founder who actively uses AI tools himself, his critique carries weight precisely because it comes from a practitioner, not a skeptic.
Posted Hashimoto's take to Hacker News where it scored 1,032 points and 448 comments, indicating massive resonance. The community engagement suggests the phrase 'AI psychosis' named something thousands of developers have been feeling but struggling to articulate.
The editorial synthesis highlights a specific pattern: companies are cutting senior engineering headcount claiming AI will replace those roles, while the AI-generated code still requires senior-level review to catch subtle bugs, security flaws, and architectural debt. The result is firing the exact people needed to supervise the AI's output.
The editorial identifies 'demo-ware' as a core symptom of AI psychosis — teams shipping features where the AI component works impressively in controlled demos but fails unpredictably in production. Product roadmaps are being built on the gap between 'works in a Jupyter notebook' and 'works at scale with real user data,' and organizations are not accounting for this difference.
The editorial emphasizes that Hashimoto is currently deep in systems-level work on Ghostty and contributes to the Zig ecosystem, actively using AI tools. This framing positions the critique as a 'diagnostic from someone who builds developer infrastructure for a living' rather than a Luddite rejection, which is precisely why it resonated so strongly with the technical community.
Mitchell Hashimoto — co-founder of HashiCorp, creator of Terraform and Vagrant, and one of the most respected infrastructure engineers of the last decade — posted a blunt assessment on X: he "strongly believes there are entire companies now under AI psychosis."
The post didn't include a long thread or detailed argument. It didn't need one. The phrase 'AI psychosis' landed with a 1,032-point score on Hacker News, one of the highest-engagement posts of the week, because it named something thousands of developers have been feeling but struggling to articulate.
Hashimoto isn't an AI skeptic. He's currently deep in systems-level work on Ghostty (a GPU-accelerated terminal emulator) and contributes to the Zig ecosystem. He uses AI tools. This isn't a Luddite take — it's a diagnostic from someone who builds developer infrastructure for a living.
The term is provocative by design, but it maps to a recognizable pattern. AI psychosis, as the developer community is interpreting it, describes organizations making structurally irrational decisions — layoffs, reorgs, product pivots, shipping pipelines — based on a distorted perception of what AI can reliably do today.
Here's what practitioners are reporting across HN threads, Reddit, and engineering blogs:
Staffing decisions based on vibes, not benchmarks. Companies are cutting senior engineering headcount with the stated logic that AI will "replace" those roles. The problem: the AI-generated code that supposedly justifies these cuts still requires senior-level review to catch the subtle bugs, security flaws, and architectural debt it introduces. You fired the people who catch the mistakes the AI makes.
Product roadmaps built on demo-ware. Teams are shipping features where the AI component works impressively in a controlled demo but fails unpredictably in production. The gap between "works in a Jupyter notebook" and "works at scale with real user input" hasn't closed as fast as the pitch decks suggested. Leadership saw the demo, approved the roadmap, and now engineering is stuck maintaining a system that hallucinates 4% of the time — which, for some domains, is 4% too many.
Architecture astronautics, AI edition. Organizations are rearchitecting entire systems around AI-first paradigms before validating that the AI component delivers measurable value. The classic engineering mistake of optimizing for a future that may not arrive is being repeated at unprecedented speed and budget, because 'AI-first' has become an unfalsifiable strategic directive.
Metric gaming with AI outputs. Lines of code generated, PRs merged, features shipped — all the vanity metrics look fantastic when an AI assistant is inflating output. But defect rates, time-to-resolution, and customer-facing reliability tell a different story. Some teams are shipping more code and building worse products.
A 1,032-point HN post from a single sentence tells you the nerve that was hit. The developer community is not anti-AI — most senior engineers use Copilot, Claude, or similar tools daily and find genuine value in them. The frustration isn't with the tools. It's with the organizational layer above the tools.
The gap that Hashimoto identified is between what AI tools actually do well (autocomplete, boilerplate, exploration, rubber-ducking) and what companies are pretending they do (replace judgment, eliminate expertise, compress timelines without compressing quality).
This mirrors a pattern that's old enough to have a name: technology-driven organizational mania. The dot-com era had it. The blockchain era had it. The pattern is always the same: a genuinely useful technology arrives, the market overestimates the timeline to maturity, companies restructure around the optimistic timeline, and practitioners are left holding the bag when reality reasserts itself.
What makes the AI version particularly acute is the confidence problem. When a blockchain project failed, it failed visibly — the smart contract didn't execute, the transaction didn't clear. When AI-generated code fails, it often fails silently. The function returns a plausible-looking result. The test passes because the test was also AI-generated and shares the same blind spots. The failure mode of AI psychosis isn't a dramatic crash — it's a slow accumulation of technical debt that nobody fully understands because nobody fully wrote it.
If you're a senior engineer or tech lead inside an organization that's making aggressive AI bets, here's the practical framework:
Audit your AI-generated code coverage. Not how much code was AI-assisted (that number is vanity), but how much of your production codebase was generated by AI and has never been deeply reviewed by a human who understands the domain. That's your real risk surface. If that number is growing faster than your review capacity, you're accumulating invisible debt.
Push back on headcount cuts justified by AI productivity. The data doesn't support it yet. Studies from Microsoft Research, Google's internal productivity team, and multiple independent analyses show AI coding tools improve velocity on well-defined tasks by 20-40%, but have negligible or negative impact on complex architectural work, debugging novel issues, and cross-system integration. Those are the tasks that senior engineers do. Cutting seniors to pay for AI tooling is trading your immune system for a faster heartbeat.
Demand failure-mode documentation for AI components. Every AI-dependent feature in your system should have documented answers to: What happens when the model hallucinates? What's the fallback? Who reviews the output before it reaches users? How do we detect silent failures? If these answers don't exist, the feature isn't production-ready — it's a demo that got promoted.
Hashimoto's post will age well or poorly depending on which timeline plays out. If AI capabilities continue their current trajectory of genuine but incremental improvement, the companies that restructured aggressively around 2025-2026 AI capabilities will face a painful correction — not because AI failed, but because they built organizational structures around a version of AI that doesn't exist yet. The companies that treated AI as a powerful tool rather than a replacement for engineering judgment will have kept their senior talent, maintained their code quality, and adopted AI improvements as they actually materialized. The difference between those two outcomes isn't the technology — it's whether leadership could distinguish between what AI demos can do and what AI systems can sustain.
I feel in a really weird position where I both really dislike what AI is doing to the experience and practice of writing code, to the point where I want a job doing literally anything else besides using the computer, but also think that these tools are extremely powerful and only getting better.I th
Maybe this is what will turn software engineering into an Engineering field.Right know, prompters are setting up whole company infrastructure. I personally know one. He migrated the companies database to a newer Postgres version. He was successful in the end, but I was gnawing my teeth when he descr
Recently I had a request come through to allow finance analysts to vibe code their apps. During a discussion one of the finance managers let the cat out of the bag. Turns out our CFO had met fellow CFOs at a get together. They talked about how each of them were using AI. Our CFO was lagging behind a
I think AI rescue consulting is going to be come a significant mode of high value consulting, similar to specialists who come in to try and deal with a security breach or do data recovery.Purely AI written systems will scale to a point of complexity that no human can ever understand and the defect c
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I’m at a FAANG and we have $300/day token quota. Personally I don’t use that much of it but management is pushing really hard for it. “the quota has been raised for a reason, use it”. Any task: “have you tried working on it with Claude?”. Every meeting “now engineer x and y will show you what h