Y Combinator Startup Podcast - Andrew Ng: Building Faster with AI

Episode Date: July 10, 2025

Andrew Ng on June 16, 2025 at AI Startup School in San Francisco.Andrew Ng has helped shape some of the most influential movements in modern AI—from online education to deep learning to AI entrepreneurship. In this talk, he shares what he’s learning now: why execution speed matters more than ever, how agentic workflows are changing what startups can build, and why concreteness beats vagueness when turning ideas into products. He reflects on the rise of AI coding assistants, the shifting bottlenecks in product development, and why, despite faster software, it’s still human judgment and responsibility that will shape what comes next.

It's really great to see all of you. What I want to do today, since this is build as startup school, is share of you some lessons I've learned about building startups at AI Fund. AI Fund's a venture studio, and we build an average of about one startup per month. And because we co-found the startups, we're in there, writing code, talking to customers, design our features, deterring pricing. And so we've done a lot of reps of not just watching others build startups, but actually being in the weeds, building startups with entrepreneurs.

And what I want to do today is give you some of the lessons I've learned building startups, especially around this changing AI technology and what it enables. And it will be focused on the theme of speed. So it turns out that, for those who that want to build a startup, I think a strong predictor for startups' odds of success is an execution speed. And I have a lot of respect for the entrepreneurs and executives that can just do things really quickly. And new AI technology is enabling startups to go much faster. So what I hope to do is share of you some of those best practices,

which are frankly changing every two to three months still to let you get that speed that hopefully lets you have a higher odds of success. Before diving to speed, you know, a lot of people ask me, hey, Andrew, where are the opportunities for startup? So this is what I think of as an AI stack, where at the lowest level are the semiconductor companies, then the clouds are hyper-scalers. built on top of that, a lot of the AI Foundation model companies build on top of that.

And even though a lot of the PR excitement and hype has been on these technology layers, it turns out that almost by definition, the biggest opportunities have to be at the application layer because we actually need the applications to generate even more revenue so that they can afford to pay the foundation, cloud, and semiconductor technology layers. So for whatever reason, media and social media tends not to talk about the application layer as much, but for those of you think you're building startups, almost by definition, the biggest opportunities have to be there, although of course the opportunities at all layers of the stack.

One of the things that's changed a lot over the last year, in terms of AI tech trends, if you ask me, what's the most important tech trend in AI? I would say is the rise of agentic AI. And about a year and a half ago, when I started to go around and give talks to try to convince people that AI agents might be a thing, I did not realize that around last summer, a bunch of marketers would get a hold of this term and use it as a sticker and slap it on everything in sight, which made it almost lose some of this meaning. But I'll share of you from a technical perspective why I think agentic AI is exciting

and important and also opens up a lot more startup opportunities. So it turns out that the way a lot of us use LOMs is to prompt it, to have it during output. And the way we have an LLM output something is as if you're going to a human or in this case an AI and asking it to please type on an essay for you by writing from the first word to the last word all in one go without ever using Backspace. And humans, we don't do our best writing being forced to type in this linear order. And it turns out neither does AI, but despite the difficulty of being forced to write in this linear way, our LMs do surprisingly well. With agentic workflows, we can go to AI system and ask it to please first write an essay outline,

then do some web research if it needs to and patch some web pages to put in the own context, then write the first draft, then read it first draft and critique it and revise it and so on. And so we end up with this iterative workflow where your model does some thinking and some research, does some revision, goes back to do more thinking, and by going around this loop many times, it is slower, but it delivers a much better work product. So for a lot of the projects, the AI Fund has worked on, everything from pulling out complex compliance documents to medical diagnosis, to reasoning about complex legal documents,

we found that these agentic workflows are really a huge difference between working versus not working. But a lot of the work that needs to be done, a lot of valuable businesses to be built still, will be taking workflows, existing or new workflows, and figuring out how to implement them into these types of agentic workflows. So just to update the picture for the AI stack, what has emerged over the last year is a new agentic orchestration layer that helps application builders orchestrate or coordinate a lot of calls to the technology layers underneath. And the good news is the orchestration layer has made it

even easier to build applications. But I think the basic conclusion, the application layer has to be the most valuable layer of the stack still holds true. With a bias or focus on the application layer, let me now dive into some of the best practices I've learned for how startups can move faster. It turns out that at AI Fund, we only focus on working on concrete ideas. So to me, a concrete idea, a concrete product idea, is one to specify the enough detail that an engineer can go and build it. So for example, if you say, let's use AI to optimize health care assets, you know, that's actually not a concrete idea. It's too vague. If you tell me to write software to use AI to optimize healthcare assets, different engineers would

do totally different things. And because it's not concrete, you can't build it quickly and you don't have speed. In contrast, if you had a concrete idea, like, let's write software to let hospitals, let patients book, my machine slots online to optimize usage. I don't know if this is a good or bad concrete idea. It's actually business is already doing this, but it is concrete and that means engineers can build it quickly. It's a good idea you find out there's not a good idea, you will find out.

having concrete ideas buys you speed. Or someone to say, let's use AI for email personal productivity. Too many interpretations of that, that's not concrete. But if someone says, can you build an app, Gmail integrate the automation that's use the right problem source, but filter and tag emails, that is concrete. I could go build that this afternoon. So concreteness buys you speed.

And the deceptive thing for a lot of entrepreneurs is the vague ideas tend to get a lot of kudos. If you go and tell your friends, we should use AI to optimize the use of healthcare assets. Everyone will say that's a great idea. But it's actually not a great idea, at least in a sense of being something you can build. It turns out when you're vague, you're almost always right.

But when you're concrete, you may be right or wrong. Either way it's fine. We can discover that much more fast, which is what's important for Sonsa. In terms of executing concrete ideas, I find that in AI Fund, I asked my team to focus on concrete ideas because a concrete idea gives clear direction, and the team can run really fast to build it

and either validate it, prove it out, or falsify it and conclude it doesn't work. Either way it's fine, so that we can do that quickly. And it turns out that finding good concrete ideas usually requires someone, could be you, could be a subject matter expert, thinking about a problem for a long time. So for example, actually before, you know, starting Coursera, I spent years, right, thinking about online education, talking to users, holding my own intuitions about what would make a good at-tech platform. And then after that long process, I think Ys C sometimes calls it, wondering the idea maze.

But after thinking about it for a long time, you find that the guts of people that have thought about this for a long time can be very good about rapidly making decisions. As in, after you've thought about this, talk to customers and so on for a long time, if you're also six-spirit, should I build this feature or that feature? You know, their gut, which is an instantaneous decision, can be actually a surprisingly good proxy. It can be surprisingly good mechanism for making decisions. And I know I work on AI, you might think I'll say, oh, we need data. And of course I love data. It turns out getting data for a lot of startups is a slow mechanism for making decisions. And a subject matter expert with a good gut is often a much better mechanism for making a speedy decision.

And then one other thing, but many successful startups at any moment in time, you're pursuing one very clear hypothesis. They're building out and trying to sell, trying to validate a false buy. And a startup doesn't have resources to hedge and try 10 things at the same time. So pick one, go for it. And if data tells you to lose faith in that idea, that's it totally fine. Just pivot on a dime to pursue a totally different concrete idea. So that's what often feels like an AI fund. We're pursuing one thing doggedly with determination until the world tells us we were wrong,

then change and pursue a totally different thing with equal determination and equal doggedness. And one of the patterns I've seen, if every piece of new data calls you to the pivot, it probably means you're starting off from two weeks of base of knowledge. If every time you talk to a customer, you totally change your mind, probably means you don't know enough about that sector yet, it's a really high-quality concrete idea, and finding someone to start about a subject for longer, may get drawn to better power.

In order to go faster, the other thing I often think about is the built feedback loop, which is rapidly changing when it comes to how we build with AI coding a system. So when you're building a lot of applications, one of the biggest risks is custom acceptance. A lot of startups struggle, not because we can't build whatever we want to build, but because we build something and it turns out nobody cares. And so for a lot of the way of, you know, I build startups, especially applications, less so deep tech, less so technology startups, but definitely application startups is we often build software, so this is an injuring task, and then we will get feedback from users,

and this is a product management task, and then we'll go back, you know, to the software, and basically user feedback, we'll tweak our views on what to build, go back to write more software, and we go around this loop many, many times, iterate toward product market fit. And it turns out that with AI coding assistants, which Andre talked about as well, rapid engineering is becoming possible in a way that just was not possible.

It's becoming much more feasible. So the speed of engineering is going up rapidly, and the cost of engineering is also going down rapidly. This changes the mechanisms by which we're going to be able to be able. we drive start-ups around this loop. When I think about the software that I do, I maybe put it into two major buckets. Sometimes I've built quick and dirty prototypes

to test an idea. You'll say build a new customer service chat ball, let's build an AI to process legal documents, whatever. But a quick and dirty prototype to see if we think it works. The other type of software where I do is, right, maintain production software, maintain legacy software, but these massive production ready goal bases.

Depending on which analysts report you trust, it's been hard to find very rigorous data on this. You know, when writing production quality code, maybe we're 30 to 50% faster with AI assistance. Hard to find a rigorous number, maybe. Be as possible to me. But in terms of building quick and dirty prototypes, we're not 50% faster.

I think we're easily 10 times faster, maybe much more than 10 times faster. And there are few reasons for this. When you're building standalone prototypes, there's less integration with legacy software infrastructure, legacy data needed. Also, the requirements for reliability, even scalable,

even security are much lower. And I know I'm not supposed to tell people to write insecure code, right? Feels like the wrong thing to say. But I routinely go to my team, so they go ahead and write insecure code because if this software is only going to run on your laptop,

and if you don't plan to maliciously hack your own laptop, it's fine to have insecure code. But of course, after it seems to be working, please do make it secure before you ship it to someone else and, you know, like a leaking PII, a leaking sensor data that is very damaging. So before you ship it, make it secure and scalable. but they were just testing it, it's fine.

And so I find increasingly startups will systematically pursue innovations by building 20 prototypes to see what works, right? Because I know that there's some acts in AI, a lot of proof of concepts don't make into production, but I think by driving the cost of a proof of concept low enough, it's actually fine if lots of proof of concepts don't see the light of day. And I know that the mantra, move fast and break things, got a bad rep because, you know, it broke things.

And some teams took away from this that you should not move fast, but I think that's a mistake. I tend to tell my teams to move fast and be responsible. And I think there actually lots of ways to move really quickly while still being responsible. And in terms of the AI assistance coding landscape, I think was it? Three, four years ago, Code Auto-Complete, popularized by GitHub co-pilot. And then there was a cursor, wind-serve generation of AI-enabled IDs. Great, use wind-serve cursor quite a lot.

And then starting, I don't know, six, seven months ago, this started to be this new generation of highly agentic coding assistance, including using O-3 a lot for coding. Cloud code is fantastic. Since Quad-4 release, it's become, and I'll begin in three months, that may use something different. But the tools are evolving really rapidly.

But I think Cloud Code Code, is a new generation of highly agented coding assistance that is making developer productivity. keep on growing. And the interesting thing is if you're even half a generation or one generation behind, it actually makes a big difference compared to if you're on top of the latest tools. And I find my team is thinking really different approaches, the software engine now compared to even three or six months ago. One surprising thing is, we're used to thinking of code as this really valuable artifact because it's so hard to create. But because the cost of software engine is going down,

code is much less of a valuable artifact as it used to. So I'm on teams where, you know, we've completely rebuilt a code base three times the the last month, right? Because it's not that hard anymore to just completely rebuild the code base, pick a new data schemer, it's fine, because the cost of doing that has plummeted. Some of you may have heard of Jeff Bezos's terminology of a two-way door versus a one-way door. A two-way door is decision they can make, if you change your mind, come back out, you know, reverse it relatively cheap. Whereas the one-way door is you make a decision and you change your mind is very costly, very difficult to reverse.

So choosing the software architecture of your tech stack used to be a one-way door. Once you're built on top of the top, certain tech stack, you know, set a database schema, really hard to change it. So that used to be a one-way door. I don't want to say it's totally a two-way door, but I find that my team will more often build on a certain tech stack, a week later, change your mind. Let's throw the code beta way and redo it from scratch on the new tech stack. I don't want to overhype it. We don't do that all the time. There are still costs to redoing that. But I find my team is often rethinking what is a one-way door and

what's now a two-way door because the cost of software engineering is so much lower now. And maybe going a little bit beyond software engineering, I feel like it's actually a good time to empower everyone to build AI. Over the last year, a bunch of people have advised others not to learn to code on the Brownsville AI will automate it. I think we'll look back on this as some of the worst career advice ever given. Because as better tools make software engineering easier, more people should do it, not fewer.

So when many decades ago, the world moved from PunchCost to keyboard and terminal, that made coding easier. We moved from assemblies, high-level languages like COBOL. There are actually people arguing back then that now we have COBOL, we don't need programmers anymore. Like people actually wrote papers to that effect. But of course that was wrong, and program languages made it easier to code and more people learn to code.

Texas is the IDEs, the AI coding assistants, and as coding becomes easier, more people should learn to code. I have a controversial opinion, which is, I think it's time for every one of every job, to learn to code. And in fact, on my team, you know, my CFO, my head of talent, my recruiters, my front desk person, all of them know how to code. And I should see all of them performing better at all of their job functions because they can code. And I think I'm pretty a little bit ahead to curve. For most businesses are not there yet. But in the future, I think we'll empower everyone

to code a lot of people can be more productive. I want to share with you one lesson I learned as well on why we should have people learn to do this, which is When I was teaching Genocide for Everyone on Coursera, we needed to generate background art like this using Mid Journey. And, you know, one of my team members knew art history. And so he could prompt Mid Journey with the genre, the palette, the artistic inspiration, had a very good control over the images he generated.

So we ended up using all of Tommy's generated images. Whereas in contrast, I don't know art history. And so when I prompt, you know, image generation, I could write, please make pretty pictures of robots for me. And I could never have the control that my collaborator good, and so I couldn't generate as good images as he could. And I think with computers, one of the most important skills of the future

is the ability to tell a computer exactly what you want, so they'll do it for you, and it will be people that have that deeper understanding of computers that will be able to command the computer to get the outcome you want and learning to code, not that you need to write the code yourself, steer AI decode for you, it seems like it would remain the best way to do that for a long time. With software engineering becoming much faster,

the other interesting dynamic I'm seeing is that the product management work, getting user feedback, deciding what features are the build. That is increasingly the bottleneck. And so I'm seeing very interesting dynamics in multiple teams. Over the last year, a lot more of my teams have started to complain that their bottlenecks on product engineering and design because the engineers have gotten so much faster. Some interesting trends I'm seeing, three or five years ago, Silicon Valley used to have these slightly suspicious rules of thumb, but nonetheless rules of thumb, we'll have 1 PM to 4 engineers

or 1 PM to 7 engineers. It was this like PM product manager at the engineering ratio, right? We should think we're great enough of those typical as ever, 1 PM to 6, 7 engineers. And with engineers become much faster, I don't see product management work, designing what to build, becoming faster at the same speed of engineering is, I'm seeing this racial shift. So literally yesterday, one of my teams came to me, and for the first time, when we're planning a hit Comfort project,

this team proposed to me not to have 1 PM to 4 engineers, but to have 1 PM to 0.5 engineers. So the team I should propose to me, I still know that this is a good idea. For the first time in my life that I saw managers proposed to me, having twice as many PMs as engineers, it was a very interesting dynamic. I still don't know if this proposal I heard yesterday

is a good idea, but I think it's a sign of where the world is going. And I find there's a PMC can code or engineers with some product instincts often end up doing better. The other thing that found important for startup founders is because engineering is going so fast, if you have good tactics, we're getting rapid feedback to shape your perspective and want to build faster, that helps you get faster as well. So I'm going to go through a portfolio of tactics for, you know, getting product feedback to keep shaping what you will decide to build. And we're going to go through a list of the faster, maybe less accurate, the slower, more accurate tactics.

So the fastest tactic for getting feedback is, look at the product yourself and just go by your gut. And if you're a subject matter expert, this is actually surprisingly good, if you know what you're doing. A little bit slower is go ask three friends or teammates to get feedback to play your product and get feedback. A little bit slower is ask three to 10 strangers,

you know, for feedback. It turns out, when I built products. One of the most important skills I think I learned was how to sit in the coffee shop, how to sit in the hotel lobby. When I travel, I often sit in the hotel lobby. It turns out learn to spot places of high foot traffic and very respectfully, you know, grab strangers and ask them for feedback on whether I'm building. This used to be easier, was less known when people recognize you. It's a little bit more awkward. But I found that I've actually sat with teams at the hotel lobby, very high foot traffic. And, you know, very respectfully ask

strangers, hey, we're building this thing. Do you mind taking a look? Oh, and I actually learned in a coffee shop that a lot of people working, a lot of people don't want to be working, so we give them excuse me distracted. They're very happy to do that too. But I've actually kind of made tons of product decisions in a hotel lobby or the coffee shop with collaborators, just like that. Send prototypes to 100 testers. If you have access to logic, there's users, send prototypes to more users. And these get to be slow and slower tactics. And I know Silicon Valley, you know, like to talk about AB testing. Of course I do a ton of AB testing, but contrary to what many people think, AB testing is now one of the slowest tactics in my menu because it's just

slow to ship it, it depends on how many users you have. And then the other thing is as you use anything but the first tactic, some teams will look at the data to make a decision, but the missing piece is when I A, B, test something, I don't just use the result of the A or product B. My team will often sit down and look carefully to the data to hold our instincts to speed up to improve the rate, which we're able to use the first tactic to make high quality decision. Often sit down and think, gee, I thought, you know, this product name will work better than their product name. Clearly, my mental model that uses wrong. So really sit down and think to update our mental model using all of that data to improve the quality of our guts on how to make

product decisions faster. That turns out to be really important. All right. So talk to about concrete ideas, speed up engineering, speed up product feedback. This is one last thing I'll touch on, which is I've seen that understanding AI actually makes you go faster. And here's why. As an AI person, maybe I'm biased to be pro AI, but I want to share you why. So it turns out that when it comes to mature technology, like mobile, you know, many people have had smartphones for a long time, we kind of know what a mobile app can do, right? So many people, including non-technical people, have good insights about what a mobile app can do. If you look at mature job roles, sales, marketing, HR, legal, they're all

really important and are really difficult, but you know, there are enough marketers that they've done marketing for long enough and the marketing tactics haven't changed that much in the last year. So there are a lot of people that are really good in marketing. And it's really important, really hard, but that knowledge is relatively diffused because, you know, the knowledge of how to do HR, like it hasn't changed dramatically, you know, in the last six months. But AI is emerging technology. And so the knowledge of how to do AI really well is not widespread. And And so teams that actually get it, to understand AI, do have an advantage over teams that don't.

Whereas if you need, if you have an HR problem, you can find someone, you know, that knows how to do it well, probably. But if an AI problem, knowing how to actually do that, could put you ahead of other companies. So things like, what accuracy can you get for customer service chatbot? You know, should you problem,

or fine-tune using your gender workflow? How do you get a voice out to low latency? There are a lot of these decisions that if you make the right technical decision, you can like solve the problem in a couple days, they make the wrong technical decision, you could chase a blind alley for three months, right? And one thing I've been surprised by, it turns out if you have, you know,

two possible architecture decisions, it's one bit of information. It feels like if you don't know the right answer, at most you're twice as slow, right? One bit. You know, try both. It feels like one bit of information that at most by you at two-x speed up. And I think in some theoretical sense,

that is true. But what I see in practice, if you flip the wrong bit, you're not twice as slow. You spend like 10 times longer, chasing a blind alley, which is why I think going into this right technical judgment, it really makes startups go so much faster. The other reason why I find staying on top of AI really hopeful for startups is over the last

two years, we have just had a ton of wonderful Gen. AI tools or Gen.A.I. Building blocks, right? Partial list, but prompting, genetic workflows, e-vals, God Rails, Rack, VoicSat, Async programming, lots of ETL, embeddings, fine-tuning, GraphDB, how to integrate a computer use, MCB, Rezing models. There's a long and wonderful list of building blocks that you can quickly combine to build software that no one on the planet could have built even a year ago. And this creates a lot of new opportunities for startups to build new things. So when I learned about these building blocks, this is actually a picture that I have in mind.

If you own one building block, like you have a basic white building block, You know, you can build some cool stuff. Maybe you know how to prompt. So you have one building block. You can build some amazing stuff. But if you get a second building block, like you also know how to build chat box. So you have a white Lego break and a black Lego break.

You can build something more interesting. If you acquire a blue building break as well, you can build something even more interesting. Get a few red building breaks, maybe a little yellow one, more interesting. Get more building breaks, get more building breaks, and very rapidly,

the number of things you can combine them into grows kind of combinatorily or grows exponentially. And so knowing all these wonderful building blocks, let's you combine them in a much richer combination. One thing is that deep learning die does. So I actually take a lot of deep learning die short courses myself, you know, to work with, I think, pretty much all the leading AI companies in the world and certainly,

and try to hand out building blocks. But when I look at the deep learning. the AI course catalog, this is actually what I see. And whenever I take these courses and learn these building blocks, I feel like I'm getting new things that can combine to form kind of combinatorily or exponentially more software applications that were not possible just one or two years ago. So just to wrap up, this is my last slide.

Then you want to take questions if y'all have any. I find that there are many things that matter for startup, not just speed. But when I look at the startups that AI fund is building, I find that the management team's ability to execute at speed is highly correlated with its odds of success. And some things we've learned to get your speed is, you know, work on concrete ideas. It's going to be good concrete ideas. I find that as an executive, I'm judged on the speed and quality of my decisions, both

do matter, but speed absolutely matters. Rapid entering with AI coding assistance makes you go much faster, but that shifts the bottleneck to getting user feedback into product decisions. And so having a portfolio of tactics to go get rapid feedback. And if you haven't learned to go to coffee shop and talk to strangers, it's not easy. But then just be respectful, right? Just be respectful of people. That's actually a very valuable skill for entrepreneurs to have, I think.

And I think also seeing on top of AI technology as you speak. All right. With that, let me thank you very much. Have the quick questions. As AI advances, do you think it's more important for humans to develop the tools or learn how to use the tools better? How can we position ourselves to remain essential in a world where, you know, intelligence is becoming democratized?

I feel like AGI has been overheight. And so for a long time, there'll be a lot of things that humans can do that AI cannot. And I think in the future, the people that are most powerful are the people that can make computers do exactly what you wanted to do. And so I think staying on top of the tools, some of us will build tools sometimes, but there are a lot of other tools that others will build that we can just use.

But so people that know how to use AI to get computers to do what you wanted to do will be much more powerful. Not worry about people running out of things to do, but people that can use AI will be much more powerful than people that don't. Hey, so well, first of all, thank you so much. I have a huge respect for you,

and I think that you are true inspiration for a lot of us. My question is about the future of compute. as we move towards more powerful, more powerful AI, where do you think that computer setting? I mean, we see people saying, let's ship GPUs the space, some people talking about nuclear power data centers. What do you think about it?

There's something that's debating RELA to say in response to the last question about kind of AGI, about maybe I answered this end, a little bit of the last question. So it turns out there's one framework you can use for deciding what's hype and what's not hype. I think over the last two years, there's been a handful of companies

that hyped up certain things for promotional, PR, fundraising, influence purposes. And because AI was so new, a handful of companies got away with saying almost anything without anyone fact-checking them because the technology was not understood. So one of my mental filters is

there's certain hype narratives that make these businesses look more powerful that's been amplified. And so, for example, this idea that, AI is so powerful, we might accidentally lead to human extinction. That's just ridiculous, but it is a hype narrative that made certain businesses look more powerful, and it got

ramped up and actually helped certain businesses fundraising goals. AI is so powerful, soon no one will even have a job anymore. Just not true, right? But again, that made these businesses a little more powerful, got hyped up. Or we are so powerful, so when the hype narrative, we're so powerful that by training a new model, we will casually wipe out thousands of startups. That's just not true. Yes, Jasper ran into trouble.

Small number of companies got white out, but it's not that easy to casually wipe out thousands of startups. AI needs so much electricity, only nuclear power is good enough for that. That wind, solar stuff, that's just not true. So I think a lot of these GPUs in space, you know, I don't know, it's like go for it. I think we have a lot of room to run stuff

terrestrial GPUs. Yeah, but I think some of these hype narratives have been amplified that I think are a distortion of what actually will be done. There's a lot of hype in AI and how, and nobody's really certain about how we're going to be building the future with it. But what are some of the most dangerous biases or overhyped narratives that you've seen people talk about or get poisoned by that they end up wrong? running with that we should try to avoid or be more aware of and allow us to have a more

realistic view as we are building this future. So I think the dangerous AI narrative has been over height. AI is a fantastic tool, but like any other powerful tool, like electricity, lots of ways to use it for beneficial purposes. Also, some ways to use it in harmful ways. I find myself not using the term AI safety that much, not because I think we should build dangerous things, but because I think safety is not a function of technology, it's a function of how we apply it. So like electric motor, you know, you can't, the maker of electric

motor can't guarantee that no one will ever use it from an unsafe downstream task. Like using electric motor, we use to build a dialysis machine, electric vehicle, can be used to build a smart bomb, but the electric motor manufacturer can't control how we use downstream. So safety is not a function of the electric motor as the function of how you apply it. And I think the same thing for AI. AI is neither safe nor unsafe. It is how you apply it that makes it save or unsafe. So instead of thinking about AI safety, I often think about responsible AI because it is how we use it responsibly, hopefully, or irresponsibly, the determines what are not what we build with AI technology ends up being harmful or beneficial.

And I feel like sometimes that the really weird corner cases, they get high-top of the news, I think just. One or two days ago, there was a Wall Street Journal article about AI losing control of AI or something. And I feel like that article took, quote-in-case experiments run in a lab and, you know, sensationalize it in a way that I think was really disproportionate relative to the lab experiment that was being run. And unfortunately, technology is hard enough to understand that many people don't know better. And so these hype narratives do keep on getting amplified. And I feel like this has been used as a weapon against open source software as well, which is really unfortunate. Thank you for work. I think your impact is remarkable. My question is, as aspiring founders, how should we be thinking about business in the world where anything can be disrupted in a day?

Whatever great mode, product or feature you have can be replicated with vibe code and competitors in basically ours. It turns out when you start a business, there are a lot of things to worry about. The number of thing I worry about is, are you building a product that users love? It turns out that when you build a business, there are lots of things to think about. There are goes to market, channel, competitors, technology, mode, all that is important. But if I were to have a singular focus on one thing, it is, are you building a product that users really want? Until you solve that, you know, is very difficult to build a valuable business. After you solve that, the other questions do come to play.

Do you have a channel to get the customers? What is pricing long-term? What is your moat? I find that most tend to be overhyped, actually. I find that more businesses tend to start up of a product and then evolve eventually into a moat. But consumer products brand is somewhat more defensible. And if you have a lot of momentum, it becomes harder to catch you.

But enterprise products, sometimes if you have maybe more, is more of a consideration of their channels that are hard to get into enterprises. So I think, sorry, when AIFund looks at businesses, we actually wind up doing a fairly complex analysis of these factors and writing a, you know, to the six-page narrative memo to analyze it before we decide whether or not to proceed or not. And I think all of these things are important, but I feel like at this moment in time,

the number of opportunities, meaning the amount of stuff that is possible that no one's built yet in the world seems much greater than the number of people with the skill to build them. So definitely the application layer, it feels like there's a lot of white space for new things you can build that no one else seems to be working on. And I would say, you know, focus on building a product that people want that people love and then figure out the rest of it along the way, although that's important to figure along the way. Hi, Professor. Thank for your wonderful speech. I'm an, an, uh, an, uh, an, uh, I'm a researcher from Stanford, and I think your metaphor in your speech is very interesting.

The current AI tools are like bricks and can be built upon accumulation. However, so far, it is difficult to see the accumulative functional expansion of the integration of AI tools, because they often align on the stacking of functions based on intent distribution, and are accompanied by dynamic problems of tokens and time overhead. and time overhead. So which is different from static engineering? So what do you think will be the perspective of a possible agent two accumulation effect in the future?

But hey, just some quick remarks to that, right? You mentioned agent, LM token costs. My most common advice to developers is to first approximation, just don't worry about how much tokens cost. Only a small number of startups are lucky enough to have users use so much of your product that the cost of tokens becomes a problem. It can become a problem.

I've definitely been on a bunch of teams where the cost users like our product and we started to look at our Gen EI bills and it was definitely climbing in a way that really became a problem. But it's actually really difficult to get to a point where your token usage costs are a problem. And for the teams I'm on,

where we were lucky enough that users made our token cost a problem, we often had entering solutions to then bend the curves and bring it back down. for prompting, fine-tuning, use DSPI to optimize or whatever. And then what I'm seeing is that I'm seeing a lot of agentic workflows that actually integrate a lot of different steps.

So, for example, if you build a customer service chatbot, we'll often have to use prompting, maybe optimize some of the results in DSPI, build e-vails, build guardrails. Maybe the customer service chatbot needs rag apart the way to get information to feedback to the user. So I actually do see these things

grow. But one tip for many of you as well is, I will often architect my software to make switching between different building block providers relatively easy. So for example, have a lot of products that build on top of OLMs, but sometimes you point to a specific product

and ask me, which OM are we using? I honestly don't know because we'll build up eVALs and where does the new model that's released, we'll quickly run eVALs to see if the new model's better than the old one. And then, you know, just switch to the new model if the new model does better on eVALs, And so the model we use week by week, you know, sometimes our engines will change it

without even bothering it to tell me because the e-vow showed the new model works better. So it turns out that switching costs for foundation models is relatively low, and we often architect our software. Oh, AI suite, there's an open-sourcing that my friends that I worked on to make switching easier. Switching costs for the orchestration platforms is a little bit harder.

But I find that preserving that flexibility in your choice of building blocks, often as you go faster, even as you're building more and more things on top of each other. So hope that helps. Thank you so much. In the world of education in AI, there are two paradigms mostly. So one is AI can make teachers more productive, automating grading and automating homeworks. But another school of thought is that there will be personal tutors for every student. So every student have one tutor that gets feedback from an AI and gets personal questions from them. So how do you see these two paradigms converge and how would education look like in the next five years?

I think everyone feels like a change that's coming in at tech. I don't think the disruption is here yet. I think a lot of people are experimenting at different things. So, you know, Coursera has Coursera coach, which actually wears really well. Deep LearnedDi is more focused on teaching AI also has some built-in chat bars. A lot of teams experience of alter grading. Oh, there's an avatar with me on the Deep Learned Eye website they can talk to if you want. Deep Learned.E.L.L.A.S.A.

And then I think for some things like language learning with, you know, speak, duolingo. that has become clearer some of the ways I would transform it. For the broader educational landscape, the exact ways that AI would transform it, I see a lot of experimentation. I think what Keyer Learning, which I've been doing some work with,

is doing, is very promising for K-12 education. But I think what I'm seeing is, frankly, tons of experimentation, but the final end state is still not clear. I do think education will be hyper-personalized, but that workflow is an avatar, is a text chat bot. What's the workflow?

I feel like the hype from a couple years ago that with AI soon and it will be all so easy, that was hype. The reality is work is complex, right? Teachers, students, people do really complex workflows. And for the next decade, we'll be looking at the work that needs to be done and figuring out how to map it to agentic workflows. And education is one of the sectors where this mapping is still underway, but it's not yet mature enough to the point, where the end state is clear. So I think we should all, yeah, just keep working on it. All right.

All right. Thank you so much, Andrew. Thank you. Hey, my question is, I think AI, it has a lot of great potential for good, but there's also a lot of potential for bad consequences as well, such as exacerbating economic inequality and things like that. And I think a lot of our startups here, while they'll be doing a lot of great things, will also be, you know, just by virtue of their product, be contributing to some of those

negative consequences. So I was curious, how do you think, you know, us as, AI builders should kind of balance our product building with also the potential societal downsides of some AI products? And essentially, how can we both move fast and be responsible, as you mentioned in your talk? Look in your heart. And if fundamentally what you're building, if you don't think it'll make people writ launch better off, don't do it. Right. I know it sounds simple, but actually really hard to do in the moment. But AI fund, we've killed multiple projects, not on financial grounds, but on ethical grounds where there are multiple projects.

We looked at the economic case is very solid, but we said, you know what? We don't want this to exist in the world, and we just killed it on that basis. So I hope more people will do that. And then I worry about bringing everyone with us. One interesting thing I'm seeing is people in all sorts of job roles that are not engineering are much more productive

if they know AI than if they don't. And so, for example, on my marketing team, my marketers, they know how to code. frankly, they were running circles around the ones that don't. So then everyone learned to code, and then they got better. But I feel like trying to bring everyone with us, they make sure everyone is empowered to build with AI. That'll be an important part of what all of us do, I think.

I'm one of your big fans, and thank you for your online courses. Your courses make the deep learning much more accessible to the world. And my question is also about education. As AI becomes more powerful and widespread, there seems to be a green gap between what can actually do and what people perceive it. So what do you think about, like, is it important to educate the general public about deep learning stuff and not only educate those technical people and make people understand more what AI really do and how it works? I think the knowledge will diffuse.

We want to empower everyone to build with AI. So we're working on it. Many others are working on it. I'll just tell you what I think is the main thing. I think there are maybe two dangers. One is if you don't bring people with us fast enough, I hope we'll solve that. There's one other danger, which is,

it turns out that if you look at the mobile ecosystem, mobile phones, is actually not that interesting. And one of the reasons is there are two gatekeepers, Android and iOS, and unless they let you do certain things, you're not allowed to try certain things on mobile. And I think there's, you know, hampers innovators. These dangers of AI have been used by certain business. that are trying to shut down open source because a number of businesses

that would love to be a gatekeeper to large-scale foundation models. So I think piping up dangers, suppose it false dangers of AI, in order to get regulators to pass laws, like the proposed SB 1047 in California, which, thank goodness, we shut down, where they put in place really burdensome registry requirements that don't make anyone safer, but would make it really difficult for T's release open source and open weight software. So one of the dangers

dangerous to inequality as well is if these regulatory, you know, awful regulatory approaches. And I've been in the room where some of these businesses said stuff to regulators that was just not true. So I think that some of these arguments, the danger is if these regulatory proposals succeed and end up siphling regulations, leaving us of a small number of gatekeepers, where everyone needs the permission of a small number of companies to fine-tune model, prompt a certain way. That's what was sifle innovation and prevent the diffusion. of this information to let lots of startups

build whatever they want responsibly, but the freedom to innovate. So I think so long as we prevent this line of attack on open source, open weight models from succeeding, and we've made good progress, but the threat is still there.

Then I think eventually we'll get to the diffusion of knowledge and we can hopefully then bring everyone with us. But this fight to protect open source, we've been winning, but the fight is still on and we still have to keep up that work

to protect open source. Thank you all very much. It's a wonderful, Slema, yeah. Thank you, so. Thank you.