From SaaS to AI-First: How Companies Are Reshaping Innovation

Elad: I feel like there's some meta trends that people are getting right and then a lot of specific companies that people are getting wrong. And so I guess the basic premise is that SaaS software and Per-seed software will no longer exist and everything's going to be replaced by AI and everything's just going to get vibe coded. So why would you pay X dollars for a Salesforce instance when you can just vibe coded internally? And all that stuff strikes me as incredibly shortsighted in the near term. Over the long run, who knows what happens in 20 years or whatever, but there's lots and lots of companies that are quite durable. I think an interesting example of that where I'm still a shareholder is Samsara where, you know, nobody's gonna Vibe code a fleet management app that will then be distributed through like what, Vibe sales? Vibe, you know, enterprise sales or something. And you're gonna build a Vibe like in-cab camera sensor that everybody will install in these fleets. and then you're going to support them using Vibe agents or something. It's just very overstated.

Sarah: I think a lot of it is actually driven by some assumptions that, you know, persona close to my heart, but engineers and builders are making about like the rest of the world, right? Because there's this, there's this implied belief that like everyone will want to make their own software. And I think it's like software is eating the world. Is that what you're trying to say? I am not. I think like we're we're still. Time to build, Sarah. Time to build. I don't think that everybody wants to make their own software. I think some set of people want to make it and others will want other people to do it for them. And like sometimes like what's a what's a like if you think about a good example of this, engineers sometimes have a like my personal labor focused picture of the world. So if you like, should you build JIRA in most engineering organizations? Like, is that a... Yeah, it's not the best use of your time if you're focused on product. I mean, the other piece of it is the examples that people use. Oh, my five-person startup built our own CRM, vibe coded it, blah, blah, blah. Yeah, of course. I mean, before that, you just did it all in a spreadsheet, and that was fine too. You'd have to vibe code anything. And so for very limited niche applications where it's a technical team doing something really quick because it's useful and custom and bespoke, amazing. Of course, that's going to happen. Does that mean that a Fortune 100 company is going to displace their CRM with some internal thing that got bipoded over the weekend? Probably not. And so I think it's also extrapolating or projecting behavior of very small technical startups onto the world's biggest enterprises.

Sarah: I think a lot of it is actually driven by some assumptions that, you know, persona close to my heart, but engineers and builders are making about like the rest of the world, right? Because there's this, there's this implied belief that like everyone will want to make their own software. I don't think that everybody wants to make their own software. I think some set of people want to make it and others will want other people to do it for them. The other piece of it is the examples that people use. Oh, my five-person startup built our own CRM, vibe coded it, blah, blah, blah. Yeah, of course. I mean, before that, you just did it all in a spreadsheet, and that was fine too. You'd have to vibe code anything. And so for very limited niche applications where it's a technical team doing something really quick because it's useful and custom and bespoke, amazing. Of course, that's going to happen. Does that mean that a Fortune 100 company is going to displace their CRM with some internal thing that got bipoded over the weekend? Probably not. And so I think it's also extrapolating or projecting behavior of very small technical startups onto the world's biggest enterprises. I think to your point of the five-person company versus the very large enterprise, if you ask that same engineer who's pissed about paying $10 a seat for Jira, if you asked him or her, do you want to do the change management in Bank of America of getting everybody to do this the way you think is right? And then dealing with all the security considerations and managing other people's opinions about potential changes to the story management workflow and then maintaining the system. The answer is like, probably not, you know?

Sarah: I think people also misunderstand how much demand exists for software products. And by software products, I mean everything. I mean AI, I mean... Is software eating the world? Is AI eating the world? AI is eating the world. So I think that is actually true. And I think Mark's post on that was really thoughtful and poor thinking on it all. I think that fundamentally, you know, there's so much demand for software, and there's so little supply of engineering in reality, relevant to that demand, that as you add this enormous boost of productivity to software engineers, it just gets soaked up, right? Because there's so much more stuff to build and to do. And I don't see teams, you know, startup teams continue to hire engineers for a reason, you know.

Sarah: Yeah, I think related to that, the one thing I've seen is that if you have an engineering identity that's based on like a value-based ranking of difficulty or skill, like the specific types of engineering that are considered, you know, impressive or high status can actually be like less hard for agents, right? So I think there's an enjoyability like element and then an identity element. And actually, one of your founders from Applied Intuition wrote a good blog post where there is an essay where he says, like, keep your identity small. I think that's like wonderful overall advice for this period of time, right? You're like more adaptable if it's true.

Elad: Well, the anxiety that I see is like if you can generate an enormous amount of code and no one is reading it, you don't know the quality of the code. Nobody deeply understands the code base and there's more fragility, right? It's like the slop problem, but instead of it being like vibe coding slop for random websites for non-technical people, it's vibe coding slop in my actual production code base for every lazy engineer, which is every engineer. I think people are like looking at some problems of actually do you think ticketing, ticketing systems are like at risk, but I think the broader problem that Jira could go solve or new company could go solve is like nobody knows how to manage that issue of human attention to engineering. And there's a bunch of ideas like testing and smart review, just let agents do it, formal verification. I think it's like open season around this really, really big problem.

Elad: We basically asked what proportion of GDP is tech, right? And just the US economy at least. And how has that grown over time? And also, what does that meant in terms of market caps, right? And so if you look back to 2005, Google was worth $100 billion and Exxon was the world's most valuable company, $400 billion in market cap. And then it took until 2018, Apple was the first company with a trillion dollar market cap ever. Everybody was shocked that anything could get to a trillion. And at the time, tech represented about 30% of the S&P. Before that, it was, say, 10%-ish back in 2005. And now the top eight tech companies are about 23 trillion of market cap, and they make up well over 50% of the S&P in terms of value. At the same time, they went from basically 4% of GDP in 2005 to about 12% of GDP today. And so then the question is, what proportion of GDP eventually just becomes tech? And AI is a driver of this, right? Because you're taking services and you're taking certain types of jobs and you're augmenting them with AI and you're converting them into effectively software spend or tech spend. And you can make different assumptions about growth rates. And then based on that, you can end up with anywhere between 15, 20% of GDP to 30% of GDP in 2035.