Chamath is wrong: AI won’t kill enterprise software

On recent episodes of The All-in Podcast, Chamath Palihapatiya, aka “The Dictator,” speculated that the enterprise software industry is dead. He argues that homegrown software will replace “steak dinners and basketball game tickets,” eventually causing the enterprise software industry to shrink:

“I’m pretty sure that the market here shrinks by an order of magnitude. Instead of fighting over $5 trillion, I think we’ll be fighting over $500 billion.”

— Chamath on The All-in Podcast, Episode 208

Chamath’s argument relies on a belief that AI lowers the barriers to software development, making it more attractive for companies to trade for best-of-breed software for DIY software tools.

Perhaps Chamath’s dictatorial rule should be restricted to SPACs, fine sweaters (he’s not wrong), and macroeconomics — because calling for the demise of enterprise software is analogous to me speculating on the play calling of an NFL football game. Being an NFL spectator doesn’t make me qualified to speculate on a sport I’ve never played. While I’ve never played football, I have “played” enterprise sales. I’ll deconstruct Chamath’s argument and make the point that he got this one wrong.

What is enterprise sales, actually?

Anyone who thinks that steak dinners and recreational golf games are what cause enterprises to spend thousands or even millions of dollars on software to solve pressing business needs has never spent time in the arena. The truth is companies are like Rube Goldberg machines — a collection of parts working together, but often in convoluted and inefficient ways. Change isn’t just hard; it’s actively resisted. Even when cogs in the machine acknowledge the need for change, their hands are often tied by a system that rewards keeping things the same. This is what James Burnham called ‘managerial economics’: a system where decisions are driven by self-preservation rather than innovation. It’s not that managers are lazy or incompetent; it’s that the system they operate within prioritizes stability over transformation.

Enterprise sales resolve this tension by helping prospective buyers realize that a problem worth solving is available and quantifying the business impact of solving it.

But this is half of the battle: salespeople must also reveal the buying process and shepherd this process to a close. Never is this process uniform or clearly outlined. Instead, salespeople must navigate a maze of budget holders, executive decision-makers, technical evaluators, end users, procurement teams, security reviewers, and naysayers resistant to change, despite the acknowledged positive impact of whatever you’re selling. Sales is a messy, human-involved art.

While I acknowledge self-service software and freemium business models allow for adoption without a salesperson, seldom are these models more than a starting point for a sales-led engagement, nor do they survive multi-stakeholder evaluations. In reality, only 12% of B2B SaaS companies use a purely product-led sales model. The majority (56%) take a hybrid approach, combining product-led and sales-led growth, while 33% rely entirely on a sales-led model. I have yet to see evidence that machines outperform humans for enterprise sales, so the durability of these jobs seems likely.

But won’t internally built software by AI replace independent software vendors (ISVs)?

Let me first acknowledge that the current generation of CodeGen tools is remarkable, and I assume that these tools will improve by many orders of magnitude in the coming decade.

So, why won’t AI-generated software become so good that companies opt for homegrown solutions vs. purchasing external vendors? To answer that, let’s first look at the history of independent software vendors (ISVs). Historically, most software was built internally, and the growth of networking saw companies migrate toward external solutions, opting to replace the tools they’ve built themselves. This wonderful historical analysis describes this shift in more detail.

Look no further than General Electric (GE), which boasts tens of thousands of software developers. Note that the company has more software developers than the total headcounts of many of the software tools they purchase. GE was a poster child for “not built here,” opting to build instead of buy. But that philosophy shifted as the company’s leadership realized their customers don’t pay them to build file sharing, HRIS, and CRM tools — they pay them to solve industrial, aerospace, and healthcare problems through hardware and software. Resources that don’t directly contribute to that mission deteriorate margins and produce an opportunity cost of dollars spent elsewhere.

Great software requires savvy product leadership and thousands of iteration cycles. Taking a DIY approach means re-discovering the insights that emerge from software vendors focused on the problems their tools are meant to solve. These insights are the product of iteration across multitudes of customers and experiments. Software vendors also have more at stake. Market incentives raise the costs of failures — build bad software, and you won’t survive — whereas product managers building and maintaining internally built tools can thrive in mediocrity.

Bad software devolves from bad product management, and we shouldn’t expect companies to suddenly develop visionary product abilities for their various software requirements. My company has exceptional software developers and product leadership, but we’re no more likely to build our own tools than our peers — even with the most talented prompt engineers coupled with powerful AI models.

We’ve seen this play out time and again at Northflank. Many of our customers — including some of the large enterprises Chamath refers to — initially take the DIY route. They task their internal teams with building custom solutions to manage deployments, orchestrate CI/CD pipelines, or create pre-production environments. The initial build often seems achievable — and in many cases, it does get shipped — but the real challenge, and the reason they came to us, is maintaining these tools over time. The term “re-platforming” echoes among so many engineering teams.

The feedback I hear on sales calls is consistent: companies underestimate the ongoing effort required to maintain and improve software. This gets compounded by turnover — people who originally built the tools often leave the company, taking their understanding of the systems with them (unless you spend even more time writing docs on top of docs, which diverts additional resources away from the actual product you’re selling).

This leaves remaining teams scrambling to support tools they didn’t design. Updates are deferred, features stagnate, and eventually, the tools themselves become relics.

Companies aren’t their software vendors, and diverting resources to maintain custom-built solutions comes at a steep cost — a decision that is, frankly, short-sighted.

Chamath founded 8090 on the basis that AI “can increase efficiency by 80%+ and cut costs by upwards of 90%.” Software vendors can also benefit from these gains and are more likely to translate these efficiencies into better products.

Software markets aren’t zero-sum

As has been the case with all enabling technologies, we’ll get more software, not less. It’s more likely that businesses will deploy CodeGen tools toward developing software for which there haven’t historically been vendor-led solutions.

Market forces will set in, best-of-breed vendors will emerge, and buyers will re-encounter the decision to continue building and maintaining an internal tool vs. buying an off-the-shelf solution. With history as a precedent, we should expect that vendor-led solutions will thrive, and these tools will require salespeople to navigate complicated buying processes.