Suresh argues that the largest capital allocation decision in modern corporate history is being made without evidence, citing the MIT NANDA 95% failure rate and IBM's 25% CEO-reported success figure. He points to Klarna's rehiring of human agents, Air Canada's hallucinating chatbot, and McDonald's failed IBM drive-thru pilot as public evidence that the mandates continue regardless of outcomes.
Suresh's most cited passage describes a broken feedback loop: when engineers report that copilot rollouts produced no measurable throughput gain, leadership responds with reorgs, replacements, or demands for different metrics. He contends that the organizational answer is decided before the question is asked, reducing engineering to a rubber stamp for a foregone conclusion.
By submitting the essay and driving it to 309 points with 154 comments, the HN community amplified the diagnosis that senior engineers are being sidelined for delivering unwelcome findings. The thread's traction — described as reading like group therapy for senior engineers — signals broad resonance with the punish-the-messenger dynamic.
Suresh points out that executives publicly commit to layoffs on the basis of AI-driven productivity that no internal team has actually quantified. He treats this as a diagnostic of the mania: the strategic conclusion (fewer humans needed) precedes and survives any evidence to the contrary, including well-known reversals like Klarna's.
A long-form essay by Nikhil Suresh (writing as Ludic) titled *AI Mania Is Eviscerating Global Decision-Making* hit the Hacker News front page and stuck at 309 points with a comment thread that read like a group therapy session for senior engineers. The piece is not a technical critique of transformers or a benchmark takedown of GPT-5. It is a diagnosis of an organizational disease: executives across finance, consulting, government and industrials have made AI adoption a mandatory KPI, and are systematically ignoring, punishing, or firing the people whose job it is to tell them whether it's actually working.
Suresh's core claim is that we are watching the largest capital allocation decision in modern corporate history be made almost entirely on vibes. He cites the well-documented pattern of internal AI pilots posting single-digit success rates — the MIT NANDA report put project failure at roughly 95%, IBM's own survey pegged CEO-declared "successful" AI initiatives at 25% — while the same executives publicly commit to headcount reductions justified by productivity gains no one has measured. Klarna publicly rehired human agents after its AI-first customer service push. Air Canada's chatbot invented a bereavement policy and cost the airline in court. McDonald's pulled its IBM drive-thru pilot after three years of TikTok-viral order failures. None of these caused a strategic rethink; the mandates kept coming.
The essay's most cited passage is about the feedback loop. When a technical lead reports that the copilot rollout produced no measurable throughput gain, the response is not "interesting, let's investigate" — it's a reorg, a replacement, or a demand for a different metric. The organization has decided the answer before the question is asked, and the role of engineering is reduced to producing evidence for a foregone conclusion.
The interesting thing about Suresh's piece isn't that it's angry — plenty of essays are angry. It's that it names a specific mechanism that most of us have felt but haven't articulated. Call it *mandate laundering*: a board demands AI adoption, the CEO commits to a number in an earnings call, the CTO turns that number into a project count, and by the time it reaches a staff engineer it's a hard requirement to ship something with an LLM in it, regardless of whether the problem in front of them is well-suited to one. The metric that matters — "does this actually work" — never travels back up the chain, because every layer has a career incentive to filter it out.
This isn't unique to AI. Six Sigma consumed the same class of executive in the 2000s, blockchain in 2017, "digital transformation" perpetually. But three things make this cycle different. First, the vendor push is unusually coordinated: every major cloud, every SaaS incumbent, and every consultancy is selling the same story with the same slide deck. Second, the sunk cost is larger and faster — hyperscalers are on track to spend roughly $400 billion on AI capex in 2025 alone, which creates enormous downstream pressure to demonstrate ROI whether or not it exists. Third, and most corrosive, the technology is *just good enough* at demos to keep the fantasy alive. A working prototype that fails at scale is far more dangerous to organizational judgment than a technology that clearly doesn't work.
The HN comment thread was notable for how many senior engineers reported the same specific experience: being told to ship an LLM feature, shipping it, watching it degrade a working system, reporting the degradation, and being told the report was the problem. One commenter, a data platform lead at a Fortune 100, described building three separate dashboards for the same AI initiative because leadership kept rejecting the one showing flat productivity numbers. Another described being explicitly instructed not to A/B test a copilot rollout because "we already know it works." This is not a technology story. It is a governance story wearing a technology costume.
The counter-argument deserves a fair hearing. Transformative technologies frequently look like failures during adoption — ERP rollouts in the 90s had similar failure rates and eventually reshaped how companies operate. AI coding assistants do have measurable effects on some tasks for some developers, and dismissing the whole category because the enterprise rollout is being run badly is its own kind of vibes-based reasoning. Suresh doesn't fully engage with this, and the essay is stronger as diagnosis than prescription.
If you're a senior engineer or tech lead inside one of these companies, the practical implications are ugly but concrete. Assume the mandate is not going to be rescinded on the merits; plan for how to comply while minimizing blast radius. That means: pick the smallest possible surface area for the required AI feature, put it behind a feature flag from day one, instrument it with the metrics leadership *thinks* they want (adoption, latency, cost) alongside the ones that actually matter (task success rate, downstream error rate, human override frequency), and keep the non-AI path warm. Klarna's rehire was possible because they hadn't actually eliminated the underlying capability; the companies that will be genuinely damaged are the ones that dismantled the fallback.
Second, be careful about which metrics you volunteer. Once "AI-assisted PR merge rate" becomes a KPI, it will be gamed within a quarter and it will replace the metric you actually cared about. The most defensive move a technical leader can make right now is to preserve at least one honest measurement channel — usually a small manual sample — that leadership cannot restructure away. If the pilot is genuinely working, you'll have the receipts. If it isn't, you'll have the evidence you'll need when the reorg comes.
Third, for anyone hiring: the market is about to be flooded with people who spent three years shipping AI features that didn't ship value. Distinguishing them from the people who shipped AI features that *did* is going to be one of the harder interview design problems of the next couple of years, and the usual signals (title, company, comp) will be actively misleading.
The essay will not change any executive's mind — the audience for a 9,000-word Mataroa post is not the audience making these decisions. But it is a useful marker: we are now at the point in the hype cycle where the practitioner class has, quietly and in large numbers, stopped believing the story their leadership is telling. Historically that gap closes in one of two ways — either the technology matures into the promise, or the failures accumulate until someone gets fired for the pilot rather than for reporting on it. Bet on which one, and you're betting on your career for the next five years.
This part toward the end of the article resonated with me:> If you’re being asked to review huge volumes of terrible AI code, just assume that the organisation is going to burn you out and fire you. You will not convince the person drowning you in 2000 line PRs to stop. Start looking for a new jo
> All of the AI projects we have observed as a team are failing. Every single one – we have seen 0% success in a year and a half, not only amongst projects we have been asked to participate in, but even within projects that we have observed in passing while doing totally unrelated work.That'
> Checking out a parallel copy of our Go repository and telling the AI to rewrite the whole thing in Zig while I work on something else just so I can keep my job.> Was it just sales fluff? The answer was a lot more interesting.... Executives at their customers were saying absurd things about a
> All of the AI projects we have observed as a team are failing. Every single one – we have seen 0% success in a year and a half,What is an "AI project"? The post doesn't define it.Is it writing some software from scratch? Using an LLM chatbot by non-coders, either internally or ex
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Most of us on some level felt confident that AI would completely revolutionise our society. The singularity made sense to me, at least. It hasn't worked out like that, but rather than accept the crushing reality of our mistake and take a second to re-evaluate, we've decided to LARP out the