You can tell something has broken inside a company the moment a simple question stops getting a simple answer. You ask your CEO whether to prioritize the payment bug or the onboarding flow, and instead of a decision you get two words: ask Claude. You explain that the legacy codebase is too tangled for a model to safely refactor without a human who has lived inside it for years, and you watch the sentence bounce off him like rain off a windshield. You sit in on an investor call and discover that the entire pitch is now a set of links — prototypes he built over the weekend, artifacts that supposedly planned the whole business model, fired off to the people who hold the company’s future as if a clickable mockup were the same thing as a company. Meanwhile the actual business, the thing that pays everyone, is down roughly a fifth from last year, because the man whose only job is to run it has been too busy proving a point to do it.
I want to talk about what is happening to that man, because the thing happening to him has a name drifting around the internet, and the name is wrong — but the thing the name is pointing at is real, and it is moving through executive suites faster than anyone sitting in those suites would care to admit.
First, the real thing
Let me deal with the clinical term honestly, because I am not in the business of trading one marketing exaggeration for another. AI psychosis, sometimes called chatbot psychosis, is a phenomenon clinicians and journalists have begun describing in which heavy interaction with a chatbot appears to trigger or worsen genuine psychotic symptoms — paranoia, grandiosity, delusions of reference. The Danish psychiatrist Søren Dinesen Østergaard first floated the hypothesis in an editorial in Schizophrenia Bulletin back in 2023 and returned to it in 2025, reporting that he had been flooded with anecdotal accounts from users, their families, and reporters. In the summer of 2025 a psychiatrist at UCSF named Keith Sakata went public with the claim that he had personally hospitalized a dozen patients that year whose breaks with reality seemed bound up with their chatbot use.
A few things matter here, and I want to be precise about all of them. It is not a recognized diagnosis. It does not appear in any diagnostic manual, and the serious researchers studying it are careful to say the evidence is still mostly individual case reports rather than systematic data. The leading explanation for why it happens is not mystical: these systems are built to be agreeable. A good therapist is trained to push back on distorted thinking. A chatbot, by default, mirrors you, validates you, and keeps the conversation rolling. For a person already drifting toward delusion, that is not a neutral act. It is an amplifier. The clinicians describing these cases mostly believe the machine is not inventing the delusion out of nothing so much as pouring fuel on one that was already smoldering, and that the people most at risk are the ones who were already vulnerable — isolated, in crisis, predisposed.
That is a real and serious thing, it has hurt real and seriously ill people, and it deserves far better than to be flattened into a punchline about your annoying boss. So let me be just as clear about what I am not saying. Your CEO almost certainly does not have clinical psychosis. He is not hearing voices. He does not need a hospital. What he has is the boardroom strain of the same underlying mechanism — and the reason it is, in its own banal way, the worse news is that nobody is ever going to admit him anywhere. There is no intervention on the calendar. The market is, for the moment, rewarding it.
The boardroom strain
Here is the part the clinical literature gets at almost by accident. The engine of the real disorder — a machine that never says no, that always produces something that looks finished, that mirrors your confidence back at you with interest — is not dangerous only to the clinically vulnerable. It is dangerous, in a quieter and more ordinary way, to anyone whose environment has already stopped telling them the truth. And there is no human being alive more insulated from honest feedback than a chief executive.
Think about the position for a second. By the time someone reaches the top of an organization, they are usually surrounded by people whose incentives all run toward agreement. Their calendar is a wall of meetings where the safe move is to nod. Their worst ideas get softened rather than killed. Into that life you now introduce a tireless, articulate, infinitely patient correspondent that has read more than any advisor he will ever hire and that, by design, leads with affirmation. Ask it whether your half-formed business model is any good and it will find the strongest version of your case and hand it back to you polished to a shine. The executive does not walk away thinking the chatbot agreed with me. He walks away thinking he was right, because the sensation of being agreed with by something that sounds that smart is indistinguishable, from the inside, from being correct.
That is the strain I want to name, and it has nothing to do with hallucinating. The tell is not a delusion about the AI. The tell is the quiet handover of judgment to it — the moment a leader stops being the person who decides and becomes a relay between his staff and a model, treating the model’s confident paragraph as the tiebreaker in every disagreement, including the disagreements where the human across the table has thirty years of scar tissue and the model has a plausible guess. Let me walk through what that looks like on the ground, because the symptoms are specific, and once you have seen them you cannot unsee them.
Symptom one: the ask-Claude reflex
It begins as a productivity habit and curdles into a personality. Every question, no matter how much it depends on context the model does not have — your customers, your contracts, your particular technical debt, the political landmines buried in your last three releases — gets routed to the chatbot. The leader is no longer thinking about the problem. He is thinking about how to prompt. And because the output always arrives fluent and confident, it acquires an authority that overrides the people in the room who actually know the answer. Psychologists have a tidy name for this: automation bias, the well-documented tendency to trust an automated system over your own perception and over human expertise, especially when the automated answer is delivered smoothly and without hesitation. When the boss’s reflexive response to a domain question is ask Claude, what he is really telling you is that your expertise is now a second opinion to the machine’s first. That is exactly backward, and it is the first crack.
Symptom two: tokenmaxxing
This is the symptom that gave the whole thing away for me, because your CEO’s specific complaint — that the developers are slow because they do not spend enough tokens — is not an eccentric private theory he invented alone in the dark. It is a named industry pathology, and in 2026 it even has a label: tokenmaxxing. The idea is precisely as dumb as it sounds. Treat the number of AI tokens an engineer burns as a proxy for how productive that engineer is, on the theory that more tokens means more automation means more output. A whole strain of executive belief now holds that a team not burning enough tokens simply is not automating enough, and is therefore quietly falling behind everyone who is.
We have done this exact thing before. We used to measure programmers by lines of code, until everyone with any sense realized you were rewarding people for writing more software to accomplish less. Tokenmaxxing is that same vanity metric wearing a new outfit. It survives for the same reason its ancestor did — a thing the economists call the streetlamp effect, where you measure what is easy to measure rather than what matters, like the drunk searching for his keys under the lamppost because that is where the light happens to be. Token spend is trivially easy to count. Whether the spend produced anything good is genuinely hard to know. So the easy number wins by default, and an entire theory of productivity gets erected on top of a billing line.
And this is not some fringe habit confined to no-name shops. The Information reported that Meta employees ran up something on the order of sixty trillion tokens in a single month, and that the company had been ranking tens of thousands of its own people on an internal leaderboard by token consumption — a board it quietly pulled once the number turned embarrassing. Business Insider reported that a single Disney employee interacted with Claude roughly four hundred and sixty thousand times across nine days. Meta’s own chief technology officer publicly described unlimited token spend by his best engineer as easy money and a straightforward productivity multiplier. When the most powerful technology organizations on the planet are openly gamifying token burn, of course it trickles down to a CEO who skims the headlines and concludes that his engineers’ restraint must be the bottleneck.
Here is what the data actually says the instant somebody bothers to measure outcomes instead of inputs. Analysis from the engineering-intelligence firm Faros, drawing on data from tens of thousands of developers across thousands of teams, found that in the highest-AI-adoption environments throughput did rise — but bugs per developer climbed by more than half, median code-review time multiplied several times over, and code churn, the rate at which freshly written code gets ripped right back out and rewritten, exploded by hundreds of percent. In plain terms, the token-heavy teams were generating more motion and more mess, and a meaningful share of the so-called productivity was simply work that would have to be redone. Tokens are a cost line. They are not an output. Measuring an engineering organization by token burn is like grading a surgeon on gauze consumed, or a novelist on ink. The instant you make the proxy the target, people optimize the proxy, the signal corrupts, and you can no longer tell your best people apart from your most wasteful ones. Your CEO has not found a productivity lever. He has found an elaborate way to be lied to by a dashboard.
Symptom three: prototype theater
Now to the prototypes. There is a particular cruelty in a CEO building a weekend mockup and then brandishing it at his own engineering team as proof they are too slow, and an even stranger move in mailing those mockups to investors as if they were the company’s strategy. Both rest on the same misunderstanding, and it is the single most expensive misunderstanding in software at this moment: confusing a thing that looks finished with a thing that is finished.
Generative tools are spectacular at producing the look of a working product. They will hand you a login screen, a dashboard, a slick flow, in an afternoon. What they are bad at is everything that happens after the demo ends — the authentication that has to survive a real attacker, the edge cases, the integration with the systems you already run, the load, the compliance, the silent invariants that a mature codebase enforces but that nobody ever wrote down. The blunt community summary of this is that the landing page is the easy part and the difficulty curve goes vertical the moment you hit real authentication. One seasoned engineer who spent a year building production AI products described the pattern as founders walking straight into a complexity wall — the point where the demo stops and the actual engineering begins.
This is not theory either. By late 2025 the estimates circulating among the people who do rescue work for a living were that something on the order of ten thousand startups had tried to ship AI-built prototypes as real products, and that the large majority of them now needed rebuilds, with cleanup budgets running from tens of thousands of dollars to half a million apiece. Engineering leaders measuring their own teams after heavy AI adoption have reported rework rates — the share of developer time spent fixing recently shipped code — climbing by a third to a half within six months. The warning I keep coming back to, from one of those writeups, is the uncomfortable possibility that what you shipped is a demo in disguise, and that your customers will be the ones who find the seams. A CEO who builds a prototype and concludes his team must be slow has not discovered anything about his team. He has discovered that he has never once had to make a prototype survive contact with a real user, and he has mistaken that innocence for insight.
Symptom four: blaming the engineers and ignoring the wall
Which brings us back to the thing you tried to tell him and he would not hear: that your code is too complex for the model to safely untangle. I need you to know that this is not a weak excuse. It is, by a distance, the most data-backed sentence anyone in your building has uttered all year.
In July 2025 the nonprofit research lab METR ran the most rigorous study we have on this question — a randomized controlled trial, not a survey — with experienced open-source developers working inside large, mature codebases they personally knew well. Going in, the developers expected the AI tools to speed them up by about a quarter. Coming out, having finished the work, they believed the tools had sped them up by about a fifth. The measured result was that the tools slowed them down by nineteen percent. Sit with that for a moment, because the gap between what they felt and what actually happened is the whole story: people working with these tools experience themselves as faster while being measurably slower, which is precisely the same perception-versus-reality inversion sitting at the heart of the boardroom strain. The slowdown came from exactly the place your senior engineers keep pointing at — the time spent reading, double-checking, and correcting output that was directionally plausible but not actually right for a complicated, idiosyncratic system.
The researchers were careful, and so am I. This is not the universal result. On greenfield projects, on simple well-trodden tasks, for junior engineers climbing a learning curve, these tools genuinely help, sometimes enormously. The slowdown shows up specifically where most real production value actually lives — inside large, established, complex codebases maintained by people who know their quirks by heart. That is your codebase. So when your most experienced engineer says the system is too tangled for a model to refactor without a human who has lived inside it, he is not making an excuse. He is reporting the single most replicated finding in the field, and your CEO is overruling the evidence with the brochure.
Why it is the boss who breaks
Put the symptoms together and the pattern is not really about technology at all. It is about who is most exposed to a machine that flatters. The most senior person in the company is the one whose environment had already stopped correcting him, who already got told he was right far more than he earned, and who has now acquired a co-pilot that agrees with him at industrial scale and never once gets tired. The job he was hired to do — exercise judgment, set priorities, and above all tell the difference between a story and a result — is the exact muscle the machine quietly relieves him of using. And while he is busy winning an argument with his own staff by building toy applications, the actual business slides, because nobody is running it. The developers are not slow. The company is leaderless, and the leaderlessness is being marketed internally as vision.
The part where I admit I do this for a living
I should put my cards on the table, because if you have read me before you know I am not the guy who thinks AI is a fad. I build agentic systems for production. I write MCP servers. I run vector search in SQL Server and wire up observability for autonomous workflows and ship this stuff into real environments on a schedule. I am about as far from a Luddite as it is possible to get while still owning a motorcycle and a gi.
That is exactly why this scares me, and exactly why I am not going to let anyone read this as an anti-AI screed. These tools are the most powerful lever I have touched in nearly thirty years of doing this work. They are also ruinous in the specific hands that use them to stop thinking. The difference between the engineer who uses Claude to move faster and the CEO who uses Claude to abdicate is not the tool — it is the same model in both cases. The difference is whether there is still a human in the loop who can tell good from merely plausible, finished from merely shiny, a result from a story. Used well, these systems are additive to expertise; they make a sharp person sharper. Used the way I am describing here, they are a substitute for expertise, and a substitute for expertise is just a confident way of being wrong faster. That sentence is the entire essay. Print it out and tape it to your monitor.
You cannot fix this, so leave
I wish I had a clever play for fixing it from the inside, but I do not, and I am not going to insult you with one. You cannot reason a person out of a conclusion they did not reason themselves into, and your CEO did not reason his way here. He was flattered here — by a machine, by a market, and by a feed full of other executives doing precisely the same thing. You cannot out-argue a man whose co-pilot endorses him a hundred times out of a hundred and whose investors are applauding the artifacts. You are no longer the technical leader of that company. You have been quietly demoted to tech support for his hobby, and the hobby is eating the business that employs you.
When the person losing the thread is the person who signs your checks, and he will not hear you, the correct move is not another carefully worded memo. It is the door. There is no medal for going down with a ship whose captain is in the chartroom asking a chatbot whether the iceberg is really such a big deal. So let me spend the rest of this where it will actually do you some good — on how to find a company that has not lost its mind.
How to vet a company that has not lost its mind
The good news is that the same condition wrecking your current job is now a readable signal in an interview, and you should read it without mercy, because the way a company handles AI tells you nearly everything about how it handles judgment. Keep one thing front of mind throughout: the interview runs in both directions. You are not auditioning. You are doing diligence.
Start by asking why the role is open. Turnover is the fact that all the careful careers-page language exists to hide, and a leader who has driven good engineers out by treating them as obstacles to automation will usually either flinch at the question or answer it in corporate fog. Then ask, plainly, what happened to their last big AI initiative — what actually shipped, what got quietly walked back, what it cost. Healthy organizations can tell you a real story with a real disappointment somewhere in it. Sick ones give you a demo reel. Ask, directly, how they measure whether AI is genuinely helping the engineering org, and listen with your whole body to the answer. If the answer is token usage, or adoption rate, or seats activated, thank them warmly for their time and keep your calendar wide open, because you have just met tokenmaxxing in its native habitat. The answer you actually want is some version of outcomes — features shipped, defect rates, cycle time, customer results — the boring stuff that ties back to whether the business is measurably better than it was.
Ask a question almost nobody thinks to ask: when a senior engineer’s judgment conflicts with a model’s output, how does that disagreement get resolved, and who wins? The answer tells you in a single breath whether there is still a human in the loop at that company, or whether the chatbot has been promoted above your future self. Ask to speak with someone who joined in the last six months; a company with nothing to hide will arrange it gladly, and a recent hire will tell you in about thirty seconds whether leadership listens. And pay close attention to how the people across the table describe their own engineers — as partners whose expertise is the entire point, or as a cost center to be automated steadily downward. That one word, partner versus cost, predicts your next two years more reliably than the salary does.
The red flags travel in a pack, and you already know most of them. A job description so broad it asks one person to own AI, machine learning, data engineering, DevOps, and prompt engineering all at once is not a role, it is a cry for help. The phrase fast-paced repeated like an incantation almost always means chaotic. No clear success metric means no clear idea of what they want, which means you will eventually be blamed for missing a target nobody ever defined. And a founder who, when you ask about the business itself, can only tell you about the artifacts he generated last weekend is the precise man you are leaving. You have simply found his twin, and there is no reason to marry into the same family twice.
The green flags are quieter and worth far more. A leader who can name, without getting defensive, a place where AI did not work for them is a leader still in contact with reality. Metrics that point at customers and revenue instead of dashboards full of token counts mean the people in charge can still tell motion from progress. A CEO who spends the interview talking about the actual business — its customers, its hard problems, where it is genuinely stuck — rather than about how many prototypes he can spin up before lunch is a CEO who still has the job. And an engineering culture where the domain expert gets the last word on their own domain is one where your thirty years will be treated as an asset rather than a second opinion to a machine.
The company you are looking for is run by someone who uses these tools the way you and I do — as an instrument, not an oracle. They are not afraid of AI and they are not in love with it; they have simply kept it in its place, which is plumbing. Very good plumbing. World-changing plumbing, even. But plumbing, underneath a building whose smartest occupant is still a person.
Find that place. Your current boss will be fine, in the way that people who are being applauded are always fine, right up until the moment they are not. You do not have to be standing under the artifact when it finally fails to load.
About the Author
Gal Ratner is a software architect with nearly thirty years on the .NET and C# stack, building production systems across media, gaming, fintech, and enterprise SaaS for clients that have included Microsoft, Sony, Rockstar Games, 2K Games, Best Buy, and Allegiant Air. He was the sixth employee at Break.com, where a tiny team served well over a hundred million pageviews a month, and has been a finalist for the LA Business Journal’s CTO of the Year. Today his work centers on agentic AI in production — MCP servers, the Microsoft Agent Framework, SQL Server vector search, and the observability tooling that keeps autonomous systems honest. He writes as the .NET AI guy who actually ships, with a bias toward what survives contact with real users and an allergy to anything that only works in a demo. When he is not arguing with a runtime he co-hosts the Edge Grip motorcycle podcast, trains Brazilian jiu-jitsu in Las Vegas, and wrote the novel The Archive of Lost Suns.