The term “AI psychosis” started bouncing around at the end of May. By the 31st there was a real debate about it. Two days earlier, Box CEO Aaron Levie had quipped that most CEOs have AI psychosis, and TechCrunch ran a piece titled “What happens when companies become too AI-pilled?” The framing was mostly about consumers and chatbots, people forming unhealthy attachments to a model that tells them what they want to hear.
Levie’s joke landed because it pointed somewhere more uncomfortable. The version of this I worry about shows up in the corner office, among executives who have stopped touching the work and started believing the dashboard.
I’m an executive writing to executives here, so I’ll include myself in the diagnosis. The failure mode isn’t engineers over-trusting their tools, because reality corrects engineers constantly. Their code either compiles or it doesn’t, the test either passes or it doesn’t, the customer either renews or churns. The people most insulated from that corrective feedback are the ones at the top, and they’re the ones currently mandating AI into every corner of the org.
The Detachment Problem
When you run a 400-person organization, your entire job is consuming summaries. You read the deck; the data sits in a warehouse somewhere and you trust that someone looked at it. You hear the readout, not the customer call. That isn’t laziness; the role only scales that way. But it means leadership has always operated a few layers removed from ground truth, and AI makes those layers thicker and more convincing.
A model will produce a confident, well-formatted answer to any question you ask it about your business. It will draft the strategy memo and project the savings down to the decimal. None of that output knows whether it’s right. It reads as authoritative because it’s fluent, and fluency is exactly the signal executives have been trained to trust in a sharp lieutenant.
That’s the psychosis. Not a hallucinating chatbot, but a leader who has replaced contact with their own business with a stream of plausible artifacts and stopped being able to tell the difference.
Magical Thinking Scales Faster Than Code
I’ve made the argument before that 95% of AI projects fail because they start with the technology instead of the problem. The mandate from the top is almost always “we need to be using AI” rather than “we have a problem AI might solve.” That’s the technology-first mistake, and it comes from detachment. A leader close to the work knows where the expensive, painful processes are. A leader who only sees the AI headlines knows only that competitors are announcing things.
The detached version compounds. “Use AI everywhere” becomes a measured KPI. Adoption percentage goes on a slide. Teams start instrumenting AI into workflows that were fine, because their bonus now depends on the adoption number rather than on whether anything got better. You end up optimizing for the appearance of transformation, which is precisely the trap the boring, problem-first approach avoids.
I’ve also written that AI layoffs are a strategy tax, and the throughline is the same. When you cut the people who understood the legacy system or the compliance framework, you removed cost on paper but eliminated the judgment layer. The judgment layer is what tells you the AI’s confident answer is wrong. Detached leadership is a softer version of the same self-harm: you keep the people but stop listening to them, because the model’s summary is faster and more pleasant than the engineer who keeps saying “it’s more complicated than that.”
The Judgment Layer Has to Reach the Top
My standing rule for building AI products at Vestmark is augment the expert, don’t replace the expertise. When we built Vestmark Pulse, the point was never to hand an advisor an answer and walk away. It was to surface the relevant signal, flag the anomaly, draft the first version, and leave the human in the seat where judgment lives. We move something like two trillion dollars in assets through systems where a confident-but-wrong output can turn into a regulatory event, not just an embarrassing one. The error budget enforces humility.
That same discipline has to apply upward, and it usually doesn’t. We’re careful to keep AI as a draft for the analyst and the advisor, then we let a CEO read an AI-generated market summary as gospel. The expert we most need to augment without replacing is the decision-maker, and they’re the one with the least friction stopping them from skipping the review step.
The judgment layer is a posture more than a tier of the org chart: treating any output, from a model or a person, as a claim to be checked against reality rather than a fact to be acted on. When leadership abandons that posture, the whole organization downstream loses permission to question the AI too.
Staying Sane
If you run a team and you don’t want to end up AI-pilled, the corrective is unglamorous and it’s mostly about staying close to the work.
Get into the actual artifacts on a regular cadence. Read raw customer transcripts, not the sentiment summary. Sit with an engineer while they use the internal tool you mandated and watch where it wastes their time. The detachment is the real problem here, and the only thing I’ve found that fixes it is staying close enough to the work to get surprised by it.
Treat every AI output as a draft, including the ones that flatter your strategy. The summary that confirms your priors deserves more scrutiny than the one that challenges them, because the model is very good at telling you that you’re right.
Then change what you measure. Kill the AI adoption KPI. Nobody outside the building cares what percentage of your workflows touch a model. Measure the business outcome the AI was supposed to move, cycle time, cost per case, advisor capacity, retention, and let adoption be whatever it needs to be to hit that number. If a team gets the outcome without the AI, that’s a win even if the dashboard reads it as a gap.
Pick one number on your AI scorecard this quarter that measures activity rather than outcome, and delete it. Then go find the team it was pressuring and ask them what problem they were actually trying to solve. That conversation is where you start.