Andrew Ng on building AI-native teams | AI Fund Frontier ‘26

Mid sip.

So, really nice to see everyone and thanks especially for those of you that have flown in for this co-founder and CEO summit. Okay, good. Thanks. So, I feel like across a portfolio and when can people hear me okay? Okay, great. So, I feel across the AI fund portfolio as well as when I work with other businesses outside this specific ecosystem, I see a huge range. I see some range of how AI-native different teams are. And what I thought I'd do is share some of my observations and tips on how to shift your teams toward the more AI-native end of the spectrum. And I don't love the AI-native term because it implies you're either born with it or you're not. But, you know, that's not true. But just that caveat, here are some of the things I see.

So, when I think about AI-native teams, the principal thing I think about is the speed advantage it buys you. At AI Fund we have a strong view that one of the best predictors of startup success is where you can execute at an insane velocity. And I think of AI as very much not a cost-savings thing, not a productivity thing, but a massive speed advantage. And I want to touch on three things, which is the new product management loop or the new product development loops, data of agents, and then tone from the top. Now, I don't have a lot of slides, but I'll hit through these theories of it quickly. So, you may have heard me talk before about the product management bottleneck, which is the observation that because coding is now so fast, the bottleneck is not building, it is deciding what to build. And more generally, as AI accelerates software engineering and other functions and other tasks in many different functions, AI-native teams are not just old-style orgs that use a bunch of AI tools. AI-native teams are teams that are rebuilt from scratch around where the new bottlenecks are, right? And this is a fundamental shift in thinking because with this shift in thinking, that we're going to build a team to solve the new bottlenecks while the old bottlenecks are just, you know, taken care by AI. This is a very different way of organizing teams than take an old-school organization, sprinkle AI into it. And so, in particular, focusing on just the product development loops for now, I published this in the batch a few months ago, I think, but this still feels to me a very good way to approach product development, and I'll touch on other functions later as well. But, you know, with the agentic coding loop, where a coding agent run for, I don't know, maybe minutes, maybe hours, not days in my case. There's hype on that. I personally never let the coding agent run for days without supervision. Definitely hours. But because at least today I can't get my AI to make good product decisions. If you figure out how to do that, let me know, right? I seems to So, I feel like having a developer vision, having a human judgment of what to build, what not to build seems really important. And one important piece of this as well is to match the speed of how fast AI can build all the time, you've got to look at it and make a decision, right? There is no time to go and user test it, run AB test, get back in a week. You should just build a product, look at it, and have good enough gut to make a decision on where to go next. But then at the same time beyond a certain point the well of knowledge in your gut does get exhausted, and you have to pull in external data, be it AB testing, surveys, user testing in order to pull in that external feedback loop in order to hone your gut in order for you to drive your AI agent.

One of the hardest things about executing this is that the best tactics are stage dependent. So, let me take the external feedback loop as an example. In the very early stages of a startup, I think all of us are used to, you know, grabbing our two best friends or actually in AI Fund, we go downstairs sometimes to Peace Coffee Shop down here, and grabbing two three people and asking them for feedback. So, it's a very fast development loop, right? And I actually tend to obsess, you know, I feel like my usual obsession with speed, I've had team members say, "Oh, let me wait for lunch to get feedback from everyone at lunch." I'll say, "No. It's now 9:00 a.m. I'm going to grab this person, and we get feedback by 9:20 a.m. Because to me, the difference is not you save 3 hours. The difference is if it's 9:00 a.m., I want feedback by 9:20 a.m., not by 1:00 p.m. because that's like a what? Let's see. 3 4 4 Am I math is right? That's like a 12x speed advantage, right? No, it's not about saving 3 hours. It's about being two times faster if I got my math right. Is that right? But one of the hardest things about executing this is the best tactics are very stage dependent. In the early stages, there's this grab someone, 20 minutes to get your feedback, then drive the next loop. But then beyond a certain point, you know, I find it if startups keep on using these fast tactics, your product improves rapidly, but then hits a plateau and you're kind of bouncing up and down with random moves rather than systematic improving it. And so as that part of your business matures, you then have to switch to slower tactics. Like maybe you now take two days to run a survey on 100 users, or maybe you can take a week and run AB testing on 1,000 users. And then I find that when it's already pretty good, you have these slower but higher accuracy tactics that let you then grind out that 1% 1% 1% improvement in performance. And sometimes, you know, if you go from 0 to 80% quickly, that's fine, but you've got to then spend the next month grinding out that 1% 1% until you're 95 98% and that actually makes for a vastly more valuable product than something that only works 80% of the time. So I find among leaders, large company leaders tend to always use the slow tactics, which is a mistake. Sometimes startup leaders only use the fast tactics, which is also a mistake, but they calibrate to shift. Both in terms of how you get product feedback as well as how you tune your agentic workflows. When do you do evals by glancing at it and make a decision versus spend more time to collect a golden data set and do more rigorous metric-based evals. That again is another I see that to be a very hard shift.

All right. So I think these product development loops, and there are also other tactics. I know some of you record all the conversations you have with customers with consent, hopefully, and then use that as part of your data set. And I find that there are lots of tactics to speed this up. All right. The second thing I want to touch on is data for agents. It was interesting when, I should say sorry, when, All right, fine. All right, fine. Oh, well, all right, fine. All right, no, all right, fine. All right, fine. But maybe one thing I've seen for a lot of teams, in across multiple companies is if you want to do innovative work, data is still the bottleneck and you spend half your time doing data cleaning before you can build whatever you want to build on top of it. So, the other kind of upfront architecture decision worth CEOs taking through is, what's your company-wide data architecture to unblock as many people as possible, either humans or agents under the control of humans, a lot of the latter, to go and figure out what's going on and get value. So, maybe some quick examples, so you know, Eli's built a data layer that has made a lot of AI funds and DeepMind AI's data agent queryable. And maybe as one example, when, you know, DeepMind AI, right? Large user base, you know, revenue, my data science tasks used to be done by humans where if I want to know what's the revenue, what's the churn, I had to go and get a human to go and look at the data in our Amazon Redshift database and then tell me what like a week later or something. But by making all that data available to AI agents, now, I ask, you know, my coding agent to do the analysis for me and this drives And not just me, importantly, is a lot of my leaders will just go and ask how code a code X to go into Redshift and do the analysis, and then just give us conclusion. About a quarter of the time it gives bizarrely wrong conclusions, so still needs steering, but it just drives much faster business decision-making. But so this data layer, for agents, sometimes fully autonomous agents, sometimes coding agents or chat agents, is another important architectural decision. And lastly, you have time for the talk. Let me just give you some things to consider. I know that some of the CEOs here has started your businesses before, you know, earlier or before the January Revolution, so on and so forth. So I just put forth some things for consideration to shift your teams toward the AI-native end of the spectrum. First, I wish everyone knew how to code, but not all of my wishes come true. But I find that in large organizations, one metric I look at is of your executive team, what percentage of them are AI-native, right? So it turns out that you don't need everyone on your executive team to be completely It'd be nice if that's true, but you know, you may have a really good sales person, a really good head of marketing, a really good whatever, and you know, they're not yet very AI-native. But it turns out that if 90% of the executive team is not AI-native, you're going to have a really hard time implementing certain projects. If it's just you and one lonely CTO, you know, that's better, but it's kind of like I don't know. But I think if I'm going to say like a third of your executive team felt AI-native, or some meaningful fraction, that gives you more energy and momentum to bring others along with you and change the company culture and change the company operating model. So what I put forth to you, for those of you that have kind of executives already, is take a look at your executive team, and you know, not not everyone needs to be a AI engineer, right? But do you have enough highly AI-native executives around you? And I think like a third is a good baseline to shoot for. Maybe half you can get there, and then clearly 100% would be wonderful as well. But that helps you drive more changes throughout the organization.

And among the teams I work with, I think I'm fortunate that for many individual functions, you know, I have leaders that are at the extreme AI-native end of that type of function. So, for example, I think, you know, Ellen, our head of finance, is very AI-native for a finance person, but she's not a software engineer, right? Or Dan, as well as Ariana in deep learning, are very AI-native for marketers. Dan is pretty much a halfway to software engineer at this point, I think. But again, Dan is not a software engineer. I don't think he wants to be. Although, you're welcome to be one if you want to, right? So, but I find that is important I feel like the goal is not to take an engineer and make them a head of finance, right? That'd be kind of weird. You could try that. I don't know, that could have funny things happen. But I think that if you have a head of whatever function that relative to all the other people in Silicon Valley that do that function on the AI-native end of the spectrum, then you're in pretty good shape. And I wouldn't buy into this hype of, you know, the startups in their dorm room, where, yeah, the head of finance is a 21-year-old college grad that is using code as all the time, but I'm not sure what that person to be my head of finance. And then small high-context team. I know ever since the famous, you know, Netflix culture deck, this context not control concept has been popular in Silicon Valley, but because building is so fast, individuals can now move so fast, the communication between individuals is one of the massive bottlenecks. And so, I think there's much greater need than before to set up small, highly empowered, high-context teams that don't have any bottlenecks, including you, right? And yeah, it's been wonderful to see, you know, I think So, I think a lot about how to get for if you've got to hire great people. If you don't have great people, you're sunk. But if you have great people, how do you give them high context and high empowerment, but with guardrails, and also enough of a understanding of where the company is going, so you don't get a thousand crazy experiments that disconnected. So, I find that high context, but also the guardrails and the with the overall company alignment. That's a very tricky balance. And then one last thing, maybe controversial is in person when possible. AI Fund is hybrid, so not everything needs to be in person, but because of that communication bottleneck, I find myself searching for very early stage startups, you know, just having a stronger bias than I used to be for building in person teams. Right? So, let's see. These are some of the things I saw and I didn't want to be the only one talking. I know that I feel like, you know, in this room, there are many people that are very highly AI-native. So, I was thinking of asking Ashwin and Mishkin to say a couple things and then if after that, you maybe just say a minute for your top tip for how to be highly AI-native. And then if there's anyone else that wants to jump in with like a, you know, quick 1-minute contribution, feel free to do so as well. But, Ashwin.