The AI Bubble Is Really a Shipping Problem

There is a particular kind of frustration that comes from watching an entire industry repeat the same mistakes with a newer, shinier vocabulary. Nikhil Suresh, founder of Hermit Tech in Melbourne, captured this feeling in a blog post titled "I will fucking pile drive you if you mention AI again". The post went viral, but what makes Suresh worth listening to is not the profanity. It is the pattern he has observed across years of corporate consulting: companies that could not ship software before AI are now blaming AI for their failures, or worse, believing AI will fix problems they have never honestly examined.

Suresh studied psychology at Monash University before pivoting to data science, finishing his master's degree in 2019, just before the current wave of AI hype crested. His timing gave him a particular vantage point. He watched the data science market contract as infrastructure realities set in, saw colleagues migrate to data engineering, and then watched the entire landscape reinflate when ChatGPT arrived. "The amount of bullshit has not changed since then," he told Murray Robinson and Donna Spencer on the No-nonsense Agile Leadership podcast. "It has just picked up."

The core argument Suresh makes is not that AI is useless. It is that AI has become a label applied to the same organizational dysfunction that existed before, concentrating previously distributed waste into a single, expensive line item. Companies that bought data governance software that did not work, firewalls that did not quite function, and consulting engagements that delivered nothing now pour the same money into AI initiatives that face identical structural barriers. "They would buy data governance software that doesn't work, and then they would buy a firewall that isn't quite working," Suresh explained. "And the spend was distributed across various bad ideas and now it's all just one bad idea. And that makes it a single target."

The Proof-of-Concept Trap

One of the more striking observations Suresh makes concerns why LLMs have been so seductive to managers who never shipped software. Before large language models, machine learning projects required genuine technical complexity: data preprocessing, algorithm selection, hyperparameter tuning, test-train splits, monitoring for distribution shift. These projects failed quietly, and the failure was spread across months or years of technical work that non-technical managers could not evaluate.

LLMs changed the feedback loop, but not in the way that matters. A manager can now type a plain English prompt and receive something that looks like a working system. "Instead of going, we need to train XGBoost to do sentiment analysis on Twitter, you just put the tweet in and then say, is this positive or negative?" Suresh said. "That's not actually a product, but it is a proof of concept. And for people who've never shipped their whole careers, I think the exhilaration of being able to churn out presentations week after week hooked the dopamine machine straight up to their brains."

This is a diagnosis that goes beyond technology selection. It describes a class of professionals whose careers have been built on the absence of delivery. Suresh argues that many IT managers have cycled through jobs for years without ever shipping a successful project, and they have normalized this failure because everyone around them has done the same. The LLM does not fix this. It accelerates the production of artifacts that look like progress while moving no closer to something a customer can actually use.

The anecdote he shares about a government contractor is instructive. The contractor asked an LLM for considerations about AWS account architecture. The model suggested that multiple accounts would allow sharing S3 bucket names across environments, a suggestion that sounds reasonable until you know that S3 bucket names must be globally unique. "Unless you're already an expert, that looks entirely reasonable because every other AWS service does work that way," Suresh said. "What am I meant to use it for? I don't understand. It's wrong on so many things."

The Hallucination Problem as Existential Risk

Suresh is clear-eyed about the technical limitations of current LLM architectures. The hallucination problem, the tendency of models to generate plausible-sounding but incorrect information, is not a bug to be patched. It is a fundamental characteristic of how these systems work. "If there was some way to consistently align an LLM so that it would say, 'I don't know,' something that would immediately make them hyper valuable," he said. "One of the reasons AI wasn't doing so well in 2019 is you couldn't get 100% accuracy on almost any system."

The legal and medical domains illustrate why this matters. A lawyer who makes a mistake is accountable. A doctor who misdiagnoses faces malpractice liability. An AI system that provides incorrect legal advice or misses a cancer diagnosis exists in a vacuum of accountability. "If the company won't accept the consequences, are you okay with having no legal recourse if it misses your cancer?" Suresh asked.

He sees the current enthusiasm for AI agents, systems where one LLM pipes output into another, as a crude workaround for this problem. "It's a crude way of going, can we get a human check on this? And the answer is no. It's still a thing that gives you answers based on whatever it thinks the most likely next token is." His own experiment illustrated the problem: he asked an LLM to explain why a particular piece of software was problematic, using careful language expressing doubt. His co-founder asked the same question without the qualifying language. They received diametrically opposite answers. "That's definitely an issue with just using LLMs to verify LLMs."

If the hallucination problem is not substantially resolved, Suresh believes the current investment cycle ends badly. "If they don't solve the hallucination problem or make immense progress, this was a gigantic bubble and most of this money's wasted. That is probably the most likely outcome."

The Shipping Problem

{{IMAGE:3}}

The deeper issue Suresh identifies is organizational, not technological. Most companies do not ship software because they lack the feedback mechanisms that make shipping possible. His consultancy includes a contract clause allowing clients to terminate on one week's notice with a full refund, because he knows that any week where nothing ships signals a problem. "Most stuff doesn't seem to be built that way. It's just a series of complete horizontal slices. How do we spec out the whole database and then the whole application layer and then the whole DevOps pipeline, and there aren't clear feedback mechanisms on when that stuff is done."

He describes displacing a consultancy that spent two years on a project without shipping, on what Suresh estimated was three weeks of actual work writing SQL and purchasing Snowflake. The competing firm did not use version control. "They're not just five guys in a basement screwing around. They've got 300 people here in Melbourne on staff."

Donna Spencer, co-host of the podcast, added a design perspective. In her experience, projects that failed to ship usually could not converge on a shared understanding of the problem. Thin vertical slices help because they reduce the scope of agreement needed. "You could just go, would this button help anyone anywhere? Can we just agree the button existing is better than the button not existing? And at least you can do something."

Suresh connects this to a broader cultural problem. Engineers who have been ground down by corporate dysfunction learn not to raise problems. He describes potential clients who would reach out about failing projects but always with the caveat: "Can you do this in a way that doesn't suggest I see any problems with the company or that I approached you?" The circularity is precise. "The reason there is a problem is the organization is full of people that won't admit there's a problem."

What AI Could Actually Help With

Suresh is not anti-AI. His consultancy employs people with postgraduate degrees in data science adjacent fields. His argument is more nuanced: AI is only valuable when the underlying systems and processes are sound, and for most companies, they are not. "The moment you've put away AI stuff, the problem space is no longer how do we solve some subclass of problems susceptible to AI? We're now talking about how do you solve problems because computers can solve all sorts of problems."

His firm specializes in data engineering, the less glamorous work of integrating systems, cleaning data, and building the infrastructure that makes analytics possible. This work is prerequisite to any meaningful AI deployment. "Any algorithm you run needs to have an accurate idea of what is happening in the business, what the state of things is at a given moment. Even the state of your documentation, I would consider to be in the scope of data engineering."

The one AI product company Suresh worked with that knew what it was doing did not even use the word AI on its website. They had computer vision experts doing clever work without the marketing veneer. "Everyone else that has asked us for AI has had no idea what the fuck they were talking about."

The Social Dynamics of Hype

What makes Suresh's analysis valuable is his attention to the social mechanics that sustain the AI bubble. Journalists he has spoken with agree with him privately but will not say so publicly because they are not technical experts and fear contradicting the prevailing narrative. Executives who have committed to AI strategies face ego costs in reversing course. "If someone comes in and says, 'Hey, you're misled on all this AI stuff,' at that point, they've probably said a lot of things to a lot of people about how they're about to get invested in AI. So you need a huge amount of humility to dial it back and admit, 'Hey, I was wrong on this one.' And I think that humility is very anti-correlated with what gets you into an executive position in the first place."

The humanitarian cost is real. Suresh describes hospitals and universities that cannot fund genuine initiatives because budgets have been consumed by AI projects. Nonprofits seeking to deliver medical care have asked him to help them figure out "the smallest amount of AI we can do so that we can actually get this money to do the thing." Artists and translators have been terrorized by predictions of imminent replacement that have not materialized at the scale promised.

He frames this as a moral failure. "If it is a bubble, then they're all accountable for a huge amount of human suffering, and I will not let them forget it."

A Realistic Trajectory

Suresh sees two plausible paths forward. In the optimistic scenario, incremental improvements resolve enough of the hallucination problem that LLMs become reliably useful for specific, well-constrained tasks. In the more likely scenario, as he sees it, the fundamental architecture does not lend itself to truth-telling, the bubble deflates, and the money invested yields little lasting value.

Either way, the underlying problem remains. Companies that could not ship software before AI will not ship it with AI. The technology does not address the organizational dysfunction, the career incentives that reward presentations over products, or the cultural fear of admitting problems. "We don't systematically produce people who can ship. So it shouldn't be surprising that mostly can't ship."

The advice Suresh offers is modest and practical. Start with thin vertical slices. Create feedback loops measured in weeks, not years. Hire people who will tell you uncomfortable truths. Invest in data engineering before AI. And perhaps most difficult, accept that the magic promised by AI vendors is not coming, not because the technology is worthless, but because the problems were never technological in the first place.

You can find Nikhil Suresh's writing at the Ludic Blog and learn about his consultancy at Hermit Tech. The full conversation with Murray Robinson and Donna Spencer is available on the No-nonsense Agile Leadership podcast.