The Rise of AI Psychosis: When Speed Outpaces Software Engineering
In a recent and provocative post, Mitchell Hashimoto raised a concern that is resonating deeply across the technical community: the existence of "AI psychosis" within entire companies. This isn't a clinical diagnosis, but rather a systemic delusion where the drive to integrate AI agents into the development lifecycle has decoupled software production from the fundamental principles of software engineering.
At the heart of this issue is a dangerous shift in priority. As Hashimoto notes, many organizations are operating under an absolute "MTTR (Mean Time To Recovery) is all you need" mentality. The logic is seductive: why worry about shipping bugs if AI agents can identify and fix them at a scale and speed far beyond human capability?
The "Resilient Catastrophe Machine"
Hashimoto draws a parallel to the early days of cloud automation and the debate between MTBF (Mean Time Between Failure) and MTTR. While the ability to recover quickly is vital, the belief that it replaces the need for resilient system design is a fallacy. When applied to the entire software development industry, this mindset risks creating what Hashimoto calls a "very resilient catastrophe machine."
The danger lies in the gap between local metrics and global health. A company might see its bug reports go down or its test coverage rise, but these are often lagging or misleading indicators. As the community pointed out in the subsequent discussion, bug reports may decrease not because the software is better, but because users have lost faith that reports will be fixed, or because the system has become so complex that users can no longer identify where the failure lies.
"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."
The Corporate Engine of Delusion
The discussion surrounding Hashimoto's post reveals that this "psychosis" is often driven from the top down. Many engineers report a disconnect between the people writing the code and the executives steering the ship.
Several recurring themes emerged from the community discourse:
1. The KPI-ification of AI
There are reports of companies making "AI use" a mandatory performance goal or setting token quotas that engineers are pressured to meet. When "doing AI" becomes a KPI, the metric shifts from value delivered to tokens burned. This encourages "vibe coding"—the practice of prompting AI to generate large swaths of code without a deep understanding of the underlying architecture.
2. The "Bragging Contest" Leadership
Some contributors noted that the push for AI is often driven by FOMO (Fear Of Missing Out) among executives. One anecdote described a CFO pushing for AI acceleration simply because they lost a "bragging contest" with other CFOs. This transforms a technical tool into a status symbol, leading to the adoption of immature workflows in regulated or high-stakes environments.
3. The Erosion of Cognitive Ownership
Perhaps the most insidious effect is the loss of deep codebase knowledge. When AI writes the code, reviews the code, and writes the tests, the human "in the loop" becomes a mere spectator. This creates a massive accumulation of "cognitive debt," where the system functions, but no living person understands why or how to maintain it when the AI fails to one-shot a solution.
Counterpoints: The Pragmatic View
Not everyone agrees that this constitutes a crisis. Some argue that this is simply the latest iteration of the "move fast and break things" era. They suggest that the market will naturally weed out companies that sacrifice too much reliability for speed.
Others point out that LLMs are genuinely powerful tools that can handle tedious refactors, catch edge cases, and accelerate prototyping. The problem, they argue, is not the tool, but the lack of discipline in its application. As one contributor noted, the industry has always produced mediocre code; AI simply produces it faster. The solution is not to reject AI, but to return to rigorous engineering standards—such as those used by NASA—and use AI to follow those rules more strictly.
The Path Forward: From Vibe Coding to Engineering
If the industry is indeed sliding into a state of AI-driven instability, the remedy is a return to the basics of software engineering: specification, validation, and responsibility.
True productivity is not measured by lines of code generated per hour, but by the long-term maintainability and security of the system. The risk of "AI poisoning"—where AI-generated vulnerabilities are introduced at scale—is a looming threat that cannot be solved by more AI agents.
As the dust settles on the generative euphoria, the industry may find that the most valuable engineers are not the best "prompters," but those who can distill core design principles from the noise and rebuild stable foundations upon which AI can safely operate.