I saw a thread by Mitchell Hashimoto, co-founder of HashiCorp. He says there are entire companies right now under what he calls AI psychosis. He cannot name them because they include personal friends he deeply respects. He is worried about how it plays out.
Source: Mitchell Hashimoto on X/Twitter · Screenshot of the thread below.
The old lesson coming back
Hashimoto lived through the MTBF vs MTTR reckoning in infrastructure during the move to cloud and cloud automation. That whole argument is coming back, but this time it is not just ops teams. It is the whole software development industry, maybe the whole world.
- MTBF means Mean Time Between Failures. It measures how rarely things break.
- MTTR means Mean Time To Recovery. It measures how fast you recover when things break.
Both matter. The problem is when people decide MTTR is all you need.
The "MTTR is all you need" mindset
Hashimoto describes the psychosis as an almost absolute belief that fast recovery is enough. The line he keeps hearing is something like this: "It's fine to ship bugs because the agents will fix them so quickly, at a scale humans can't do."
Infrastructure already learned that MTTR is great, but you cannot yeet resilient systems entirely. Fast recovery does not remove the cost of breaking in the first place.
Why it is hard to talk about
He says the hardest part is raising the topic with people he knows personally. The response is usually dismissal:
- "No no, it has full test coverage."
- "Bug reports are going down."
These are local metrics. They do not paint the whole picture.
The real risk
Hashimoto's core warning is this: you can automate yourself into a very resilient catastrophe machine. A system can look healthy on dashboards while globally becoming incomprehensible.
He lists the pattern:
- Bug reports go down while latent risk explodes.
- Test coverage rises while semantic understanding falls.
- Changes happen so fast that nobody notices the underlying architecture decaying.
In other words, the machine keeps running and the dashboards stay green, but the people running it understand less and less of what is actually going on.
What I would tell fresh grads and juniors
I use AI to write and to code. I am not anti-AI. But reading Hashimoto's thread, I kept thinking about what it means for people just starting their careers.
I have been in the industry for about seven years now. I lived through parts of the infrastructure shift Hashimoto talks about. But fresh grads and juniors today? They did not. They are entering an industry that is about to re-learn the MTBF vs MTTR lesson — except this time with AI agents in the picture.
Here is what I want them to understand.
If agents patch every bug the moment you ship it, you never get to see what the bug looks like. You miss the debugging reps that build real intuition about how systems work. As a junior, those reps are how you grow. A bug that gets silently fixed by an agent is a learning opportunity you just lost. Do not let that happen.
Hashimoto also warns about local metrics hiding global decay. Bug reports go down, but latent risk goes up. Test coverage rises, but semantic understanding falls. For a junior, the practical lesson is this: do not measure yourself by how fast you ship. Measure by how well you understand the system you are building. Speed is only useful if you know what you are actually doing.
There is another thing. Teams that move fast with AI agents are accumulating tech debt in ways they might not notice. The architecture decays because changes happen so fast. Someone will inherit those systems. If you are early in your career, you might be that someone. Knowing the warning signs early helps you spot them before they become your problem.
My advice is this: keep doing the slow parts. Read the code. Think about the design. Ask what the system actually does at 3am when something weird happens. Debug without asking an agent to do it for you first. These habits separate engineers who grow from engineers who just move tickets.
I worry too.