Three things worth knowing
- A consultant at Ludicity published an essay on July 18, 2026, arguing that AI mandates have made honest reporting about project outcomes functionally impossible inside large organizations.
- The central claim: across 18 months of client work and roughly 300 professional conversations, the author's team has observed a 0% success rate on AI projects. The claim is one consultancy's vantage point, but the mechanisms described are specific and documented.
- Named figures including Mitchell Hashimoto and Thomas Ptacek, who hold opposite views on LLM capability, agree on the organizational point.
The AI productivity debate usually focuses on the models. This essay focuses on the org chart, and that's what's made it stick on Hacker News.
The argument is not that LLMs don't work. It's that the incentive structures inside large organizations now make it nearly impossible to find out whether they work on any given project, because every actor with information has a reason to misrepresent it. The essay opens with a quote from Mitchell Hashimoto: "I strongly believe there are entire companies right now under heavy AI psychosis and it's impossible to have rational conversations with them about it."
What Happened
The author runs sales and technical delivery at a consultancy and draws on roughly 300 conversations with professionals ranging from niche service workers to Fortune 500 executives. The essay was published July 18, 2026, and surfaced on Hacker News shortly after.
The core argument runs in stages. AI investments are failing at a near-total rate. But every actor in the chain- boards, executives, employees, vendors, consultants- has an incentive to misrepresent that. Raising doubt is career-threatening: the author says the only people they know of fired over AI strategy are those who questioned it. Executives face a prisoner's dilemma: contradicting a customer's 100x-productivity claims risks losing the contract, so nobody defects from the consensus even when everyone in the room privately disagrees.
Key Features
- 0% observed success rate: Every AI project the author's team observed over 18 months has failed, including ones they encountered during unrelated engagements. This is one consultancy's observation, not a statistically representative sample, and the essay presents it as such.
- AI-washing is systematic: Engineers complete work the normal way and attribute it to Claude afterward because managers penalize non-AI approaches. The incentive flows downward from mandate to measurement to behavior.
- Token leaderboards get gamed: Companies measuring engineers on AI spend prompted people to set LLMs running in loops, generating plausible-looking output while watching Netflix. Per the author, not one engineer has been caught doing this.
- Demos override judgment: The author demoed Snowflake Cortex with explicit warnings it wouldn't meet client goals, citing the Snowflake staff's own estimate of roughly 92% accuracy in ideal configuration. Every lukewarm client tried to buy it immediately after seeing the demo.
- Metrics go unmeasured: Project leaders avoid tracking basic usage, or measure things that are easy to game. A voice bot the author describes failed to follow up on a request for six months; that miss likely logged as a resolved incident in the system.
- Headcount now requires AI penance: Some organizations require staff to demonstrate they tried AI before requesting additional hires. Admitting AI didn't suffice risks a "bad at AI" label, with layoff risk attached.
Why It Matters
The part worth sitting with for engineers is the incentive structure description, not the 0% figure. If the essay is directionally right, developers are operating inside systems that actively punish accurate reporting. One example the author quotes: an engineer checking out a parallel copy of a Go repository and asking an AI to rewrite it in Zig, purely to satisfy a usage quota, then discarding the output. The work had no effect on the actual codebase.
The author's argument about why AI projects fail at the same rate as ordinary software projects also deserves attention: AI projects carry every failure mode of normal software projects plus novelty risk, and few companies ship ordinary software well enough to absorb the extra risk. Internal chatbots fail for a mundane reason the essay makes explicit: "an LLM is not psychic," and documentation quality in most organizations is low enough that no model can compensate for it.
The survival advice in the essay is blunt enough to be useful. Raise project concerns one-on-one, never in groups. Anonymous polls work: the author has seen teams split bimodally, half rating a project 3/10 and half 8/10, on work already years late. If you're reviewing large volumes of bad AI-generated code, assume burnout is coming and start the job search before it arrives.
Example Use Case
The Oracle-to-Snowflake migration example is the clearest illustration. A vendor added a preliminary phase using an LLM to translate Oracle-flavored SQL to Snowflake-flavored SQL. The automation failed on permissions, not model capability, so the team translated by hand. The company reported it as an AI-driven success because a small fraction of the SQL had passed through the model at some point.
The author's read: most "AI projects" are ordinary projects with an AI element attached to satisfy an internal purity test. Projects driven primarily by a model with falsifiable success metrics are rare outside startups. That framing is useful for anyone trying to evaluate whether a project in their own organization is actually AI-enabled or AI-labeled after the fact.
Competitive Context
The essay's closest counterpart is Thomas Ptacek's "My AI Skeptic Friends Are All Nuts" on the Fly.io blog, which takes the opposite position on LLM capability. Ludicity previously rebutted it directly. What's notable is that despite disagreeing on what models can do, both authors agree on the organizational point. Ptacek's own words: "Tech execs are mandating LLM adoption. That's bad strategy."
Most AI commentary argues about model capability. This essay documents how mandates, gamed metrics, and executive coordination failures distort decisions regardless of what the models can actually do. That's a different argument, and it's the one that's harder to dismiss by pointing at a benchmark.
An anonymous career CISO quoted in the piece says most peers are "quietly skeptical but afraid to speak up." That's consistent with the prisoner's dilemma framing: nobody defects from the consensus because defecting first carries real personal cost.
My Take
The 0% figure will attract most of the attention, and it should be read carefully. It is one consultancy's observation over 18 months, not a controlled study, and the author is clear about that scope. What's harder to dismiss is the mechanism: the description of how incentives flow from mandate to measurement to behavior, and how that flow makes accurate reporting structurally unlikely, is specific enough to recognize if you've worked inside a large organization recently.
The thing I keep thinking about is the prisoner's dilemma framing. It does not require anyone to be acting in bad faith. Every actor is responding rationally to their own incentives. That's what makes it hard to fix from inside: you cannot solve a coordination problem unilaterally, and the essay is honest that the survival advice it offers is mostly about protecting yourself rather than changing the dynamic.
Run your software agents at scale
Cosmos gives your agents the context, tools, and feedback loops they need to get better with every workflow.
Written by
Paula Hingel
Technical Writer
Paula writes about the patterns that make AI coding agents actually work — spec-driven development, multi-agent orchestration, and the context engineering layer most teams skip. Her guides draw on real build examples and focus on what changes when you move from a single AI assistant to a full agentic codebase.