a16z Podcast - The Future of Software Development - Vibe Coding, Prompt Engineering & AI Assistants

Episode Date: July 21, 2025

Is AI the Fourth Pillar of Infrastructure?Infrastructure doesn’t go away — it layers. And today, AI is emerging as a new foundational layer alongside compute, storage, and networking.Erik Torenberg interviews a16z’s Martin Casado, Jennifer Li, and Matt Bornstein breaking down how infrastructure is evolving in the age of AI — from models and agents to developer tools and shifting user behavior.We dive into what infra actually means today, how it differs from enterprise, and why software itself is being disrupted. Plus, we explore the rise of technical users as buyers, what makes infra companies defensible, and how past waves — from the cloud to COVID to AI — are reshaping how we build and invest. Timestamps: (00:00) Introduction (01:49) Defining Infrastructure in the AI Era(03:15) The Fourth Pillar: AI's Role in Infrastructure(06:01) Historical Context and Evolution of Infrastructure(08:20) The Impact of AI on Software Development(10:18) Investment Strategies and Market Dynamics(17:02) Developer Tools and AI Integration(20:57) Defensibility in the AI Landscape(22:16) Founders' Intuition and Industry Progress(22:26) Defensibility in AI Infrastructure(24:00) Expansion and Contraction Phases in the Industry(24:35) The Role of Layers in Market Consolidation(27:43) The Future of AI Models and Specialization(29:27) The Decade of AI Agents(29:54) Context Engineering and New Infrastructure(34:23) The Evolution of Software Development(42:13) Horizontal vs. Vertical Integration in AI(43:54) Conclusion and Final Thoughts Resources: Find Martin on X: https://x.com/martin_casadoFind Jennifer on X: https://x.com/JenniferHliFind Matt on X: https://x.com/BornsteinMatt Stay Updated: Let us know what you think: https://ratethispodcast.com/a16zFind a16z on Twitter: https://twitter.com/a16zFind a16z on LinkedIn: https://www.linkedin.com/company/a16zSubscribe on your favorite podcast app: https://a16z.simplecast.com/Follow our host: https://x.com/eriktorenbergPlease note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures.

It's like faster than light speed travel has just been invented. For many of the developers and programmers I talk to today, they're like going to Disneyland just because of how many great tools there are to help them move faster. We do spend a lot of time just trying to be very honest with ourselves, like what is the new behavior being created, where is this stuff getting used? Infrastructure never goes away, it just gets layered. In this case, it's definitely all the infrastructure that we've been using and leveraging in the past are still very relevant, but it's definitely getting layered by having

this fourth pillar. Software was always the disruptor. One of the most exciting things about the AI wave is like software is being disrupted, like we're being disrupted. This is a pretty big deal. It's by far the biggest thing that I've seen happen sort of in my life. Is AI the fourth pillar of infrastructure? Today on the podcast, we're joined by Martin Casado, Jennifer Lee, and Matt Bornstein from A16Z's infra team to unpack how infrastructure is evolving in the age of AI, from compute, storage, and networking to models, developer tools, and agents.

We get into what infra actually means today, how it differs from enterprise, and why software itself is being disrupted. We also talk through the rise of technical users as buyers, what makes an infra company defensible, and how past infra waves from cloud to COVID to the current AI boom have shaped how we invest and build. Let's get into it. As a reminder, the content here is for informational purposes only, should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security, and is not directed at any investors

or potential investors in any A16Z fund. Please note that A16Z and its affiliates may also maintain investments in the companies discussed in this podcast. For more details, including a link to our investments, please see a16z.com forward slash disclosures. We're here today to discuss the state of infra. First, can we get a definition of infra? Where does infra differ from enterprise? How do we think about it internally? I would say infra is basically what makes software work. We'll probably get pretty deep into a set of technical definitions.

You mentioned sort of networking, storage, compute. Where does AI fit into that? But I think at the simplest possible level, if you want software, We'll probably get pretty deep into a set of technical definitions. You mentioned sort of networking storage compute. Where does AI fit into that? But I think at the simplest possible level, if you want software, infra is what engineers are using behind the scenes to make all this possible. And our formal definition internally is technical buyer. So it's the stuff you use to build the stuff,

the stuff you use to build apps. And if it's used by a technical user, we consider an infrastructure, whereas something like, let's say, vertical SaaS could be used by a flooring company or by a marketer or by sales, that would not be considered infrastructure. And technical user, for the record, is developer, data scientist, analyst, cybersecurity

professional. Yeah, right. There's a DevOps, right. There's a wide range of sort of like people. These are our people, right's a wide range of people. These are our people, the kind of nerds behind the scenes. And in the system terms, think about it as compute, networking, and storage, but also all the tooling that goes around the developer's day of what you're using

to build software and what are the tools and products that are operating. growing more complex software as well, all the way to semi-technical users that may want to either prototype or tinker with building applications. We're very interested in anything in the technical domain and used by technical people. So you mentioned compute, networking, storage. How should we think about models? Is this the fourth layer of info? How do they interface?

How should we think about that? I certainly think of it as a fourth layer of infrastructure. It's certainly leveraged and built on top of all the three pillars we're talking about. It has a lot of demand of compute. And of course, it's trained and also producing a large amount of data. And to leverage and use these models for our purposes, latency and networking capabilities

is also very important. But it's going to be as prevalent as any piece of infrastructure software. I don't know, like the analogy these days anymore. Is it a database? Is it sort of like a new form of compute? So really, to me, it's like a fourth pillar that incorporates everything, but also provides intelligence for the software we're using and building today. Yeah. So I think this is exactly right.

I think it's probably worth asking why a piece of infrastructure is a piece of infrastructure. And generally, a new piece of infrastructure changes the way that you program computers and then changes the stack that's around it. Like it's got different memory requirements. It's got different latency requirements. And so it just requires rethinking how we build software and how we build infrastructure. You know, I would say in addition to compute networking storage, I'd say distributed systems would also be included just because things like state consistency

require you to think about proximity and guarantees. I would say databases probably did too, because it changed our programming model. You have different guarantees. And these models very much fit in that for a couple of reasons. I think Jennifer is exactly right. You just build different data centers and different chips if you want to build these models so it has that impact.

But programming them is like non-obvious. We're just still trying to grapple like how you program with them. Like, they don't really listen to you. Sometimes they do the coding themselves. And if I were to try and distill like, what is the one biggest difference that these models provide to infrastructure? It's the following. I don't remember ever in the history of computer science

where we've, from an application standpoint, we've abdicated logic. Like in the past, we've abdicated resources, like you're like, give me compute, give me swords, like these abstracted resources, but the logic, the yes or no, like the what it's doing, always came from the programmer. But in these ones, we're like, come up with the answer for me. And so it's requiring us to rethink what does it mean to be a programmer, what does it mean to be software, et cetera? So it's clearly very fundamental to computer science.

And I would say, again, to Jennifer's point, it's very, very much a new piece of infrastructure. And I think a lot of people are trying to reason by analogy. You sort of alluded to this, Jennifer, as like, oh, is it like a database because it can answer queries? Or is it like a network because it's sort of non-deterministic and we need to handle retries and weird edge cases. But like I think people are really just trying to figure out how to program these things, which you sort of said, Martin, but like we've got to start from a blank sheet of paper,

which is what makes our jobs like really exciting right now because there's a lot of people trying to figure it out and coming up with ideas. Many of us have been in computer science for a long time, right? We've been in our schools and in our operating lives and in our with ideas. Many of us have been in computer science for a long time. We've been in our schools and in our operating lives and in our investing lives. And like software was always the disruptor, right? Like we disrupt the taxis or we disrupt like sales, we disrupt the back office or we disrupt everything.

Like one of the most exciting thing about the AI wave is like software is being disrupted. Like we're being disrupted, right? And so like- Yes, it's disrupting software. It's eating software. I know, I know, we're like, oh. So we have to think about- Software is the self, eating is being disrupted. Like we're being disrupted, right? And so like. Yes, it's disrupting software. It's eating software. I know, I know. We're like, oh.

So we have to think about. Software is the self eating. Yeah, that's right. It's like honestly, I think this is the first time I could honestly say that like the profession that I've dedicated my entire life to is being disruptive. And it's very exciting because it's eating itself in a way. Yeah.

And it's tempting to be a curmudgeon, right? Because we've all been doing this our whole lives. So it's like really being open to it, embracing the new stuff is like the key thing. What still applies is infrastructure never goes away, it just gets layered. In this case, it's definitely all the infrastructure that we've been using and leveraging in the past are still very relevant,

but it's definitely getting layered by having this fourth pillar, which is AI and models. What's different from past super cycles, first, what can we learn as we enter this new one? So there's two things that happen. So one of them is often when you bring the marginal cost of something down, like with compute, we did it for computation, and for the internet,

we did it with distribution. It increases the TAM a whole bunch. So for one, you almost always see this massive TAM expansion. And part of that tends to be because the TAM is bigger, you've got new users. And because you have new users, there's normally a new behavior that happens. This is very much the case with the internet, which is people weren't used to going to a computer and talking to everybody around the world on top of the internet. And existing companies don't know really how to think about new behaviors.

They've built these sales motions and operating things around the old behavior. And so you see TAM expansion, you see new behaviors. Those new behaviors provide white space for challengers, new startup companies to come and to go ahead and fill those models. And I think we're seeing exactly that happen with this one as well.

Clearly, this market is massive if you look at how successful these model companies are. But also, you're seeing exactly that happen with this one as well. Clearly, this market is massive if you look at how successful these model companies are. But also, you're seeing use cases that computers just never really have done before, and you're seeing that too. And so in that way, I think it rhymes very much with, say, the internet, and it rhymes very much with probably even the microchip. Maybe I'll answer that question just from my personal experience. I'm always sort of a tools person and also wanting to like having tools fulfilling certain creativity because I came to coding and computer science as a

late bloomer after my 20s and really enjoyed all the tools available for me at that point of just building software and like learning computer science as well. Now we just have massive and massive leverage in trying to create anything as long as you have a good idea. I was a bigger local champion for the last five, ten years. Because again, these are tools for people who have good ideas but may not be educated in the computer science term. The real tools of the world, the next level of thought partners, tools,

to really, as any role in the company, prototype software interfaces for your end customer, for your end user, as long as you know what they need, what they want to see. You can really realize these ideas really quickly at your fingertips. So low code's finally happening. It just takes a lot of code. It just turns out the code is natural language. I know, it's so funny because when Jennifer joined the team, she was very excited about low code.

But from my view, low code is like Python. It's like a scripting language. Interpreted languages. And PM is low coding. So we kind of had to bridge that gap. And it was in a way like a bit irreconcilable until AI came out. And it's very, very clearly like what the promise of low code was. And so you're right, it really is disrupting software.

So when I was a kid, the internet was sort of a new thing. I just remember really vividly there was this movie with Sandra Bullock called The Net, and she orders a pizza from her computer. And this was like completely mind-blowing. And now actually this is a common user behavior, but what we're dealing with now is just so much bigger than that, right? I just think it's really hard to,

like I think some of these points about how will the infrastructure evolve, like how will the companies adapt and things like that are probably transferable, but this is a pretty big deal. It's by far the biggest thing that I've seen happen sort of in my life. Let's zoom out and take this long view.

And Martina, you're actually the perfect full circle because weren't you the first Infra Investment ever as a portfolio founder? I think it was either me or Okta, but I will say me and Todd were like the infrared portfolio One one LP days when they would trot us out in front of the LPs It was like me and Todd from Okta So for sure I was one of the first two but what point did we develop clear and for practice at Azenzia? So we always had strong infra people, right?

So like Ben Horowitz is an infra guy. And honestly, I would say Mark is, like he masquerades as a consumer guy, but he's actually revolutionized the way we use computers in this deep infrastructure way. And by the way, many things came from that JavaScript, et cetera. We had Peter Levine, Zensource, we had Scott Weiss.

And so like there's always been deep infra. But when I joined the firm, we didn't think of it as infra. We thought of it as enterprise. And so you're either in the consumer team, you're in the fintech team, or you're in the enterprise team. And the thing about just classifying this stuff as enterprise, the go-to-market motions for something that touches technology and being able to reason about that is so different than reasoning to the go-to-market motion that's purely

through like sales, right? And we've just learned over time that like we do deep market diligence as a firm and we do deep diligence on companies before we invest in them. And that the type of diligence we do if it was deep infrastructure just required a different type of junior partner and type of analysis. Over time, we realized that companies where you can evaluate more by like the business model, the market buyer, the unit economics, you know, those kind of class of companies are just sufficiently distinct.

So we decided to just pull them apart. And then that's why we have the apps fund. And then of course, the infra fund. If you think about enterprise, there is of course the horizontal piece of it, but also a lot of vertical enterprise, whether applications, buyers, sectors, where infrastructure is almost always horizontal. And that's another thing we realized along the way of we still want to like appeal to these like technical audience and technical buyers, but we want to

think about sort of the space in a horizontal fashion where these technologies can be distributed to all these different sectors and verticals as well. And it impacts how we think about the stack, it impacts how we think about what is going to drive the form of how the stacks integrate with each other, just like different from enterprise generally. Yeah, so it's actually a very, very important distinction. I'm glad you brought it up. So like, technical buyers tend to be centralized buyers in a way, right?

Like IT will buy compute network and storage. And yes, you've got the compute person, the networking person, but it kind of rolls up to IT and developers are kind of a centralized buyer. So like you can understand IT and you can understand the developers. But when I was looking at vertical SaaS apps early in my investing career, to understand how to sell into a flooring company, you have to understand the flooring market. And that's entirely different than like the pet food market, and that's entirely different than the construction market.

So I felt like there was no real central software buyer for these kinds of verticals. So as you get further away from core infrastructure, you get away from this notion of a centralized, educated buyer, and just the level of analysis becomes very different. I think that's exactly right. And there's even sort of like the horseshoe theory of software buyers happening now, educated buyer.

to developers looks more like consumer these days than it used to. That's an incredibly important point. When I first joined Venture or maybe even just started thinking about infrastructure, developers deal in the low tens of millions and they're becoming the next generation of consumers. Now they're definitely the language being the programming language for everybody. They're making decisions just as a consumer. So we're, of course, training ourselves to also understand how developers as individuals adopt tools, but also IT buying centers as customers and enterprise organizations are evaluating tools. So there's just a lot to learn and figure out, given these are the technical audience we really care about. Yeah. I want to get to how we think about our investable universe and what sort of subcategories are mature versus newer or sort of ripe. But before that I want to

better trace the evolution a little bit. So maybe, Martin, we can start with you. If you had to categorize like since you've been investing like the different waves of infrared or like maybe the different inflection points at which it changed how we even thought about it. How would you characterize it? Let's just say for like the different waves of infrared, or like maybe the different inflection points at which it changed how we even thought about it. How would you characterize it? Let's just say for like the life cycle of the firm, so, what, 2009, and that was actually pre-cloud. And so a lot of the early investments

were right in the cusp of cloud. And like, for example, my company, like the cloud was out there, but it wasn't sufficiently deployed, you could use it as a core thesis. And a lot of the early investments were like this. And we talk about it in terms of tech, but it rips through the entire business model.

Like early software was on-prem with a perpetual license. That's just different economics and different analysis, right? And so like the pre-cloud installable software area was one. And then we saw the cloud transition, right? So we went to recurring revenue, totally different deploying model, totally different operating model. And during that time, we'd see things like net dollar retention being more important, expansion being more important, gross turn being more important.

It's margin. Gross margin being more important. Everything changed to that. By the way, meanwhile, of course, we saw consumer being disrupted by mobile, right? With the rise of the Ubers and the lifts and the RB and Bs. And then again, we're seeing it happen again during this AI, which I would say the AI transformation of the last three years has been the most dramatic I've seen in the last 30 years of being in this industry. And there's one interesting blip along that path, which is COVID. We come from the realm of enterprise sales and being on the ground and deploying things and like that totally evaporated.

So like actually that was a dramatic shift as well, but it was driven by this kind of force majeure as opposed to a secular technical wave like the other two did. I would say one of the benefits COVID brought is there was already the trend going of like developers buying and adopting tools, DevTool companies that are giving birth to, Let's go deeper into the present a little bit. Can you guys share how we think about the different subcategories or landscape that kind of makes up in from? We could also plug some examples of portfolio companies, spaces where we made some bets. Here's a few important categories. Developer tools, meaning anything developers use to make their lives better,

easier, faster, more efficient. Cursor is probably our top developer tool company right now. And before that, GitHub, right? Yeah, GitHub. We were in GitHub. So we've seen very popular. And Jennifer, you've actually backed a bunch of interesting DevTools companies in the last few years too. Yeah, from LumiFi, Stylos. And there was a long time where the DevTools

was written off by BC. Oh yeah, the TAM was too small. Yeah, exactly. I mean, at the time of GitHub, would you ever have imagined a repository would be a huge company? Like, it was like almost a joke. Right, and people were unsure about the business model and all these things. Small TAM is the classic like red flag I never have imagined a repository would be a huge company. It was almost a joke.

Right, and people were out chatting about the business model, all these things. SmallTAM is the classic red flag for infra investing. If you're at home listening to this and someone tells you SmallTAM runs your... They're not an infra investor. Infra creates TAM. There's one takeaway from this thing is TAM creative. So yeah, I think DevTools, you've got core infra, which is compute network and storage. This is like to IT. And then you tend to actually be quite a you've got core infra, which is compute network and storage, right? This is like to IT. And then you tend to actually be quite a bit above the core

infra stack. So maybe you talk through the areas you focus on. I think about both how developers are using tools to improve their efficiency, but also how customers are getting value out of that as well. So a lot of packaging, maybe DevTools into SaaS forms. I mean, investing in this company called Pylon, it is a SaaS company that does customer support, but fundamentally, investing in this company called Pylon.

It is a SaaS company that does customer support, but fundamentally it's like doing a data pipeline. So that's like core infrastructure that's very good at connecting with systems and providing context to a lot of agents and AI models. So to me that's infrastructure. And we're spending a lot of foundation model investing. And we can probably numerate for the next 10 minutes. I will say the reason that we're a little bit skittish on this question is early in super cycles,

it's very hard to distinguish between an infrared company and the application companies. And the reason is because the TAM is so small and so new, the new technology becomes the app, right? So let me refer to like the original super cycle that started the firm, which is the internet. Like Netscape, I remember when it came out, like it was a consumer thing, or at least a student in school thing, right? And so this is one company which everybody was downloading from an FTP server, Netscape, and using it as individuals.

The enterprise didn't know what to think about it and banned it or whatever. And the same company that built JavaScript, that's building this core technology, is also doing the browser. And over time it matures, and then of course you have all of these internet companies and all the applications show up. We're seeing the same thing in the AI wave. Is Mid Journey, is that an infra company?

They built a model, or is that an app company? Well, it's both in this sense. And so I do think that at this stage it's very hard to distinguish. It's exactly right. It's very hard to answer if OpenAI is an app company or it's an infra company. It already is building infrastructure that's like a cloud running these models

for different sector and different use cases, but at the same time, building a consumer app that's high GPT. We think of foundation model companies are similar. Like 11 Labs, they're a voice AI provider, and they have the creator application that can use the studio to create voices. But at the same time, they're a voice AI provider, and they have the creator application that can use the studio to create voices. But at the same time, they're also supplying the voices to these large scale enterprise use case

that are like fine tuning, cloning your own voice, and distributing that through API. So it's sort of both. Yeah. Another area we've done a lot of work is data systems. And this goes all the way back to Databricks. And there's sort of been these two branches. One is this like kind of back-end data-enged driven big data systems spark-a-doop

sort of thing. And the other is this sort of data analyst, more tabular snowflake kind of thing. And I think as a firm, we've been super, super active and super aggressive, you know, investing in companies like Databricks. I mentioned 5TrandDBT, which you guys invested in together, Hex, which is doing really, really well, Tabular, which was acquired by Databricks. So we're still, I think, really, really bullish on this. Unfortunately, AI has sucked the air out of the room for a lot of data companies from a bunch of different angles, but I think we'll continue to do more of this as well. How do we think about defensibility for AI companies, whether it's the app layer or the

model layer, do they all have their respective sort of areas of defensibility or how is sort of a notion of defensibility evolved? So we once wrote a blog post that there was no defensibility anywhere in the stack. For anything. For anything. And yet people make lots of money. Yeah, and yet.

You know, the argument at the time was like, OK, like Nvidia has sort of a moat because chip designs are hard to copy. But if you go sort of up or down, it's kind of like, okay, like Nvidia has sort of a moat because chip designs are hard to copy. But if you go sort of up or down, it's kind of like, okay, they're all sort of manufactured at the same place, right, at TSMC. If you go down, if you go up, the cloud providers provide effectively the same product.

Like the models are training on the same data and have similar capabilities. The apps are all kind of like all using the same model. So that was sort of the naive theory, I think, when we were just trying to understand this at the beginning. I think maybe like all using the same model. So that was sort of the naive theory, I think, when we were just trying to understand this at the beginning. And I think maybe it was true at the time. What Martina was sort of alluding to a second ago is,

meanwhile, every company at every layer of the stack is doing like fantastically well right now. And during this kind of initial phase of industry development, which we sometimes call the Brownian motion phase, like I actually think it's really hard to make sort of pronouncements like this about what's gonna work, what's not gonna work, where's value gonna accrue, et cetera, et cetera.

App companies are doing really, really well and like we're pretty clear past the sort of wrapper phase. Like I don't think there are any wrappers anymore. Like building good products with AI is really hard and the founders doing it now have like really good kind of intuition for how to do it. The models are clearly like pushing the whole industry forward

and like they've built huge companies, you know, so it's kind of all working right now and I think you could actually make a case for how defensibility will work. It's quite different from the way defensibility has worked before and maybe you guys want to add on to that. Yeah, on how defensibility worked for companies before, largely it's really hard to let's say if you're building like a new database, like a new framework, it just takes a lot of expertise in the domain of understanding what has happened in the past, where did the field come through, and what are the innovations that need to happen to polish, let's say, like a software into this new abstraction to provide to developers. Maybe one example I'm thinking of is like DocDB. It's like such a high-performance, small, but really nimble database. It took four years for the team to write it. To replicate that is really hard.

And that's generally what happened in the past infrastructure space. It's like it takes these experts a lot of time to build like a new piece of security software, if it's the UB keys or if it's again like data breaks on Spark. But now as the AI infrastructure comes through, like I think a lot of those defencibility still stays and they are true. Because these are earned secrets of what are the downfalls and guarantees other software run into where these founders know sort of the past and also looking into the future. But I do feel like the adoption phase is just like really massive.

Who is going to earn the distribution and earn the developer attention is going to be a different game. Can I just do a quick mental model of what has suited me very well in thinking about this? I think the sloppiest thinking in our industry is around defensibility. And it's just we're just so sloppy about it.

And so maybe this is worth the price of listening to this podcast, this mental model. So the industry tends to go through these expansion and contraction phases. Think of like the Big Bang or something like it expands and then it contracts. So what happens when it expands? When it expands, zero-sum thinking is deadly because you're just getting more market. We're clearly in an expanse phase, right?

Everybody is, oh, Nvidia can't like sell more chips, but they keep selling more chips. Oh, like the hosting platforms can't continue to get margins, yet they keep continuing to get margins. I mean, Matt said it perfectly. I totally agree. So if you're in the expansion phase, then there's just more to sell. You should be aggressive in investing. So what happens in the collapse phase? So look at any layer of the stack.

So in the collapse phase, which things start to consolidate again, you have consolidation. But what is the end state of consolidation? The end state of consolidation will always be an oligopoly or a monopoly. It's not like layers ever go away. If you have an oligopoly, say the clouds, then you have what is effectively price fixing, but it's tacit, right? Which is everybody is like, we're going to price it this and we're going to maintain our 30% margins.

So you still have value there, you have margins. Or in the case of like a monopoly, you'll end up with say like an Intel at the time, then you can also maintain margins. So in none of this do you lose margins, right? And I just think this is why people think so sloppy about this. People use the words like commoditization and no defensibility. That tends to be a battle between layers of the stack. But the only way you can do that is actually move down the stack

and enter somebody else's layer, which is incredibly hard to do. And you do see it. So of course, Google is going to build their own chips, and they start moving down the stack. But that's a very, very different layer than somehow Google playing the different layers off against each other. And so I would encourage anybody that

does invest at least in infrastructure to not think zero-sum and to realize that historically, every layer of the stack has maintained some level of value and margin. And if not, it was because a layer above them managed to verticalize themselves. But then it's that one player against the rest of the world. Yeah, I mean, it's like faster than light speed travel has just been invented, right? And we're sending all the spaceships out in all directions. And there's plenty of planets like and stars to claim for everybody.

We're not even close enough to each other to fight for them. For sure, this is extreme. But it will slow down and then the consolidation will happen. But I guarantee you'll just end up with these great companies that maintain margin. AWS still has great margins. Google still has great margins. And still growing at an insane speed.

Databricks, too, still growing at an insane speed. Databricks too is growing at an incredible speed. I think people underestimate how hard these problems are in many cases. You're sort of applying consumer thinking because this is how we live most of our lives. It's like, oh, wouldn't it be relatively easy to move to a different part of the stack or take out your competitor or someone, a customer could just switch back and forth. And it's just different laws of physics, I think, in inference. It just turns out in general, the switching costs of the infrastructure piece is so much higher.

Even with API business, people tend to think you can just switch over to another API. There's so much logic embedded in calling the API in the software itself. There's a lot more switching costs compared to your regular SaaS software consumer software. Yeah, totally, because you're actually integrating systems, right? It's not necessarily a person who can just have a preference for one thing or another. You're sort of integrating. For sure. Sam Altman once had the advice to startups last year.

He was like, if you're worried about us improving our models, you're in a tough spot. But if you get more excited about your business by us sort of improving our models, then you're in a good spot. Do you think that's a helpful framework? I think it's helpful for OpenAI for me. No comments. I'm serving. I want to say that too.

If you know, A16Z, if you think us investing in this company isn't good for you, then if you want to buy from our customers, our companies, that's great. There's a very open question that's actually a technical question. It isn't a business question, which is how much does general training generalize, right? So we know in the pre-training world, it generalized really well. So you'd create one model and that model is just as good at code as it was at like writing a poem or right.

So we know that it was very general. And in that world, sure, as the models get more powerful, then they can do all of the things so they compete with all of the things, right? But it seems clear to me, and again, this is an observation, and it may not be correct, that as we get more into the RL world, that you make some trade-offs. And then let's say I RL something for code, it's not going to be as good as something else,

and like you're making these trade-offs. And in that world, then it's not the case that the model is going to generally be good. So I think it's great to compete at the model layer. And so again, I think this is maybe a reasonable rubric, certainly for OpenAI to have people believe, maybe a reasonable rubric if you believe that these models are going to be generally great, but I just don't think it holds up to how things are going to play out.

This was a debate we had two years ago. I think whether the general model and the most capable model will rule or a lot of small medium sized models that are very good at specific tasks, that's going to be the future. It turns out both are true. Both, yeah. When we talk about complex systems, you cannot just use one model that drives everything, at least not today, but you can compose very capable and powerful models to take certain

tasks and also chain together processes from processing document to feeding in a model to have some reasoning and give you back really clean instructor data to make decisions and put into your application and to serve end users. Like that's a complex system that invokes many model calls instead of just like one big models task. Did you guys have any reactions or is it worth talking at all about Karpathy's talk?

Did that framing resonate with you? Did you have any sort of differences of how you would frame certain things? One thing he mentioned is that he thinks it's not the year of agents, but the decade of agents. Perhaps it's not as immediately upcoming as we might have thought. Probably should have talked about it more. There's something he said recently that I thought, and he's actually responding to somebody else that I thought is actually very insightful.

I actually thought his talk was great, but I thought his talk was kind of an overview of what a lot of people know. I thought it was a pretty good general overview. I saw the tweet today about who knows how old it was. So this idea of prompt engineering that people have talked about, and somebody, it wasn't Karpathy, but Karpathy piled on top is this, it's really not about prompt engineering, it's context engineering. And prompt engineering is context engineering. And so what is context engineering?

So if you're going to call a model, you have to know what to put in the context in that prompt. And what tools do you have to do that? Well, you could use other models, but at some point, you're probably going to use traditional computer science. You can use like things like indexes, you're going to do prioritization, etc. And to really drive the best performance out of those models, you do want the context to be correct.

And I do think it's probably the right framing of this problem. And the next step is, inasmuch as we're going to provide formalism to how to use these models, to how to use existing tools, to how do you improve the performance, you should be thinking about what's the right way to get the right context into those models. And I bring this up because, like we said before,

new infrastructure pieces create new patterns and new methods of software and building systems. And this is a great example of that kind of emerging before our eyes and people reasoning about it. And I truly believe in five years we'll look back, we'll come up with a whole new set of formal ways to build software and they will have strong guarantees and we'll understand them and there'll be all the tools for it etc.

The way I think that relates to our world is if you think about what is the new form factor of infrastructure that needs to become part of this context in engineering it goes back to a lot of what we're obsessed about with data pipeline how do you feed the right data and context into the models or into the context and how do you have agencies tools or infrastructure that will provide a discovery and guarantees how do you feed the right data and context into the models or into the context, and how do you have agencies' tools or infrastructure that will provide a discovery and guarantees the observability of these tools as well. Like it's the classic infrastructure problem

that's still unsolved, so it's a very exciting time. There's a few different types of infra founders, right? There's the sort of infra founder who loves solving really messy, long-tail, like nasty problems, right? There's a type that kind of just gets fed up with a problem and they're like, I'm going to solve this finally. I'm sick of this. Then there's the type that just sees the world in a new way.

And it's like, this is actually how we should marshal these resources. And React is a great example of this. We had all these progression of front-end development frameworks. And finally, React was the way that stuck. And for years now, it's been the default front-end development frameworks and finally React was like the way that stuck. And for years now, it's been sort of default front-end. So like, I think what Karpathy's talking about is trying to figure that out, right? And I think his software 2.0 thing was really interesting.

We were investing in a bunch of like traditional ML companies at the time. And I think software 3.0, I think he's sort of right about that too, and sort of directionally. And my hope is it'll inspire a lot of new infra founders to do this work, see the world in a new way, and figure out how these primitives should really be arranged. One of the difficulties of having any conversation around AI is it just exploits this weakness in the human imagination to dump all of our fears and hopes and dreams into this anthropomorphic fallacy, right?

And this goes all the way back to the Promethean legend. And so let's talk about even this context, right? And this goes all the way back to the Promethean legend. And so let's talk about even this context, right? We're building systems to build other systems. Those systems have constraints, right? And so you can fail on either side of this when it comes to this anthropomorphic fallacy. On one side, you could be like, this stuff doesn't work. You shouldn't use it. You should only use traditional things, which, okay, that's clearly not the case. It seems very useful. But on the other side, you can believe they'll solve all of our problems and you don't need formalism and you just kind of like go to the beach and you come back when AGI is done and it'll do it for you type thing.

And so part of our job and what we spend a lot of time talking about is trying to find that pragmatic, non-blinkered, non-pessimistic middle despite all of the rhetoric. And you hear all the rhetoric, right? The stuff is going to like, no, we're not going to have to work and we're all going to be on the beach. Right? Or, you know, it'll kill us. The whole thing.

And I think where we've landed is this is a real disruption. It's just changing all of software. It'll look something place different, but it is still going to require professionals. And I do think that the statement it'll require professionals is a very meaningful one. It means that you actually still need people that understand the specifications of the systems.

And not everybody agrees that. Some people are out there like, listen, you will never need a programmer again because people are going to just say some high level thing and it'll show up. And the only one statement I'll say to that is formal systems came out of natural languages for a reason. And like either you care about specifying what you're designing or you don't.

And if you do, you need to be a professional. And that's why every professional discipline, even though they started with a natural language, has ended up with a formal system. What is your mental model on coding specifically? Will there be fewer engineers who are just higher powered? I think the best way to think about this is simply that we're going to have more developers. I think it's very unlikely that we're going to shrink development teams because we have amazing new tools.

That's just not how these markets have worked in the past. I think exactly the opposite is going to happen. It's like we're going to be creating so much great software and it's going to be so accessible to so many people who may work at a big company or may just be sort of hacking on the weekend. I think that's by far the simplest way to think about it. And it gets back to Martin's point of you can't

anthropomorphize these models. A model is a file on a hard drive in a computer somewhere. And when you run a Python script, you can transform one piece of data into another piece of data. Like, that's what this is. And programming is a fundamentally creative job, right? You are literally creating things

in the most strict sense of the word, which is you're creating software that doesn't exist before. And that's something only a person can actually do at some level of abstraction. So I personally think this is a huge boon for programmers and you have to change the way that you're working. And it's like a huge productivity boost. some level of abstraction. faster, like, build things they have always wanted to do on both side projects and also their main job.

I do think it also changes the dynamic of how people are picking up new languages, picking up new frameworks. And it is, again, a next level of iteration speed, given what we're seeing with AI agents and also AI coding tools. Here's another, I think, useful mental model on this stuff. I think it's worth asking the question, why do people buy software?

Why does someone buy some random SAS tool? Is it because it's so hard to build it? No. Most SAS tools are like CRUD. They're just these basic kind of read-write databases. They're all the same. So why do people buy them? And Aaron Levy, who's the CEO of Box, I think,

said this so beautifully. The reason people buy software is because somebody else made the decisions of what the workflow should be and what the operational logic should be and what data is important, how you use that data is important. Creating a product is a lot of understanding what is being used and guiding the user along that direction.

So if not, I just give you a compiler. You do whatever you want, or I'll just give you a database and you do whatever you want. There's a reason that we have a proliferation of vertical SAS, and it is this kind of articulation or this transfer of domain understanding. And that just doesn't go away independent of how you create the software.

And so we will still need to design products based on whatever problem is being solved, guide people so that they're the most effective with them and they can understand the best. And we did this with assembly before, and then we did it with high-level languages, and then we did it with high-level frameworks, and then we're going to do it with AI.

But like the fundamental process of that articulation will not go away. And it's totally orthogonal to creating the software itself, right? It turns out to be a much harder problem to go out and collect requirements from an unknown set of users with an unknown set of needs. And figuring out what to build, that turns out to be much harder than actually building it. So what do you think is the average number of lines changed in the PR in the industry?

Two. Yeah. But it shows you to the point. It literally is understanding the need from the business and the need from the business and the need from the user and making some minor tweak. That is the long tail that goes into software. Just for the record, by the way, Martin said crud.

Crud is a technical term. delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete,

delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, delete, to reveal themselves in the next few months or next year that are going to impact our business. Oh gosh, every week is different. What are some of the recent ones? Definitely like how realistic are agents today like really producing production level software?

That's more on the coding agent side, but also in general, like the agent evolution. Where are we in going from demo ware to producing real value, tangible value? What are some other ones? Synthetic data is when we talk about a lot. We've been talking about them for 10 years. This is so great about infrared.

You can have the same debates for 10 years, and they never quite go away. It's like changing the background. It's like everything else is the same. Consistency versus availability. Literally every system has this trade-off. So the synthetic data thing, right, it's almost an information theory question.

It's like, can you make models meaningfully better without introducing new information to the system? And I think it's now pretty clear you can do a little bit, but the question is, does this lead to sort of like a self-improving utopia of models or not? And I think we have some pretty strong opinions on the not side of that. Generalization, Martin mentioned, is a pretty interesting one. If you train a model to be really good at math, does that mean it's going to be really good at other things or is it just like really good at math, which I get excited about. Not everybody gets excited about this. Another one that we talk a lot about is like what these things are actually good for, just

because the path we came from used a lot of AI, pre-gen AI used a lot of AI. So there's a lot of AI shaped holes in the enterprise, like chat bots and this and that. And that's very much on the brain. And it seems to sometimes confuse the discussions from the new use cases we're seeing. Like if you look at the most common use cases of something like ChatGPT, I think the top one is like companionship and therapy, and then it's like managing my schedule.

It's like the top of the pyramid of need stuff. And then number five is professional development, not like low code development or whatever. And so I think what is happening is we have this idea of what we thought AI was going to do and like just kind of the stilted attempts previously. And like, Jennifer actually ran product for a chat company prior. And then what it really is good for,

and clearly there's some overlap and convergence, but it's not nearly as big as people say. And so we do spend a lot of time just trying to be very honest with ourselves or what is the new behavior being created? Where is this stuff getting used? What is it just being trying to cram into places it's not actually quite good at? To that point, how do we think about agents right now?

What are they good for going to be good for soon enough? What is the state of them? How do we think about the broader conversation? Coding agents are awesome. Like they're amazing. It's really amazing. So I have a very simple way to think about this. And I'm like the anti-agent guy, by the way.

I think it's kind of a marketing thing. This is the other thing about infrared people. We are like allergic to marketing, which is not always a good thing. Which is a good thing. You're here, Eric. I was asked, what do you mean? Yeah, yeah, exactly. Can you explain?

If you take the simplest definition that basically an agent is an LLM running in a loop, a very simple way to think about this is errors propagate throughout the loop, right? So if you have a small error, it gets worse and worse. And this is why a lot of agents doing, say, general web browsing don't perform very well yet. On the flip side, if you have a way to correct those errors in the loop, which is one thing

that you have in code, right? You can land to you can interpret, you can try to compile and things like that. You actually do see good performance over time. So that's a very simplistic and maybe not quite the right way to look at it. But if you can do this kind of error correction, I think you're seeing a lot of improvement

from this iterative approach. I mean, it's incredible. I'm actually on the GitHub mailing list of a lot of the companies that I work with, just mostly for interest. And I have, even in the last week, seen a bunch of kind of cursor, like agent commits and like even in the last 24 hours, the slack integration seeing it come from slack.

And so I do think for kind of bite size tasks, you can articulate very well, we're starting to see them really work. So in the coding space, I would say I'm a convert. But to Matt's point, like the, you know, go wander out in the woods and bring back a bear. Will we see more vertical integration or more horizontal specialization? You know, historically we've seen both. And what's interesting is we're already seeing both now, right? Apple, of course, has just been historically vertically integrated.

Microsoft and Intel, historically horizontally. And often, companies will start horizontal and then go vertical. So Google is horizontal. It was built on top of normal servers, but then they built their servers, and then they built their own chips, they built their own networking gear. So I think you always get a mix of the two. What's interesting about now is we're actually really seeing both.

I would say that OpenAI is very much a vertically integrated company now with chat GPT driving a lot of it. I would say Anthropic, a lot of the usage really is more horizontal. And they're doing a great job of that. I think we're seeing this on the model layer too. A very interesting discussion we haven't had, but it's a very interesting one is like open source,

quote unquote, really seems to work with these models just because you can't as a user recreate it. So we look at BFL. They've done a great job building like a horizontal layer for these models, but then you've got companies like ideogram, which have built a great kind of vertical experience as well. And so I'll say for AI, we've got already this early on great examples of both. And I don't see any reason that that will change.

Yeah. I think from the business front, it just poses new interesting questions and challenges too, of how do you capture the value? Of course, horizontally you can capture the value through being able to address every single use case by providing that to developers or enterprises. But if you're going to integrate, you kind of have to pick the lane of do I want to focus on image models? Do I want to focus on graphic designers?

Do I want to focus on people who are generating photography? You have to understand the market and the user personas use cases pretty well to capture the maximum value where you probably can take a easier path to just provide API so everybody can use it. I think it's a great place to wrap. Guys, thanks so much for coming on the podcast. Thank you for having us. Thank you. This is fun. Thanks for listening to the A16Z Podcast. If you enjoyed the episode, let us know by leaving a review at rate this podcast dot

com slash A16Z. We've got more great conversations coming your way. See you next time.