It's good to see everyone here on the weekend. What I want to do is share with you a few thoughts on what I'm seeing with AI-assisted software engineering and also why we wanted to organize this buildathon rapid engineering competition for zero to product in a day.
So I find that when you're trying to do something innovative, be it build a startup which AI Fund does every day, or in a bigger corporate environment innovating and creating something new, I find that one of the biggest predictors for whether or not the project is likely to succeed is speed. There are teams that can just execute ferociously and at speed that allows them to get more reps in, try more things, and the odds of success are just materially higher. So frankly, when I work with engineers or CEOs for portfolio companies, one of the things that I really respect is people that can execute decisively and really, really fast.
And by the way, I know that when I talk about speed, sometimes people think, oh, you know, it's just talk about working harder, and it's actually not right. Like working hard definitely helps. I know in some parts of the world it's not politically correct to talk about working hard, but frankly, I work hard. I respect people that work hard. That's just it. But beyond working hard, which is important, there's a certain decisiveness and skill set that lets you execute like crazy and try more things and get more done. And one of the reasons why I'm excited about AI-assisted coding is it takes a core part of what we do and it lets us do it way faster.
So, you know, when I look at the software work that I get up to, some of what I do is build prototypes or small standalone products, and some of what I do, and so what a lot of you do, is work on production software or large code bases. And if we look at the impact of AI-assisted coding, it's very hard to get rigorous studies, like I've tried, you know, but maybe for working on large legacy production-scale code bases, maybe AI makes us 50% faster, maybe even higher now.
But for building prototypes or small standalone products, it's not a 50% speed up, it's like a 10x speed up. I think many of you have experienced so many projects that two years ago would have taken, you know, three engineers like six months to do. Now we or our friends can throw together in a weekend. And what this means is for us all to try new things. We can build 20 prototypes and see what works.
So actually, on a lot of my weekends, it turns out I actually tend to do a lot more coding on Saturdays just given my schedule. On my Saturdays, I build tons of software that I look at and go, you know, gee, that didn't work, and I never tell anyone about it. It never sees the light of day. It turns out that there's some people that have angst that in AI a lot of proof of concepts never make it to production. And this is viewed as a problem, but I actually don't. To me, the solution is not to make more proof of concepts, make an MVP. The solution is to drive the cost of doing a proof of concept so low they just don't care. If you build 20 prototypes, 18 fail and never see the light of day. But that's the price of discovering the two that are really valuable that you do spend more time to make it robust, reliable, and take it to scale.
And it turns out that building prototypes, small standalone products, I think, you know, there are reasons why we can do that especially fast, right? The requirements for scalability, for frankly even security, are much lower. If I'm writing software that only runs on my laptop, then since I do not intend to maliciously hack my own laptop, you know, it's fine if I don't have as many firewalls so long as I don't, you know, leak sensitive information or do other bad things. So the level of effort needed to build prototypes is much lower, and AI is continuing to drive it lower while also making it safer.
And so years back, Silicon Valley, this mantra, move fast and break things, got a bad rep because, you know, it broke things. Some people took... don't take a picture of this slide yet. Wait, this will get me in trouble. I'm going to change this. I think some people took away from this that Silicon Valley is moving too fast. They'll move fast. And that's wrong. I think the mantra I tell my teams is move fast and be responsible.
And I find that many smart teams will have ways to create a sandbox environment where you're not shipping software to millions of people that harms them in some way. But you're building a prototype, you're trying it out yourself, assuming you won't traumatize yourself overly much. You know, if an LLM gives a wrong response once, like it's fine to move really fast, but do it in a safe sandbox so you can prototype and then decide what to put the security and safety on to then take to scale.
And one of the things with coding of AI systems is there's been, over the last couple years, there's been multiple waves of innovation, multiple generations. I think GitHub code autocomplete was a huge innovation two years ago, but we've moved well beyond that now. And then there's a wave of AI-enabled IDEs, right, using Windsurf, Cursor a lot. And then also around the same time, there's a wave of businesses like Replit, v0, maybe Lovable. And then just earlier this year, last several months, the wave of another wave of highly agentic coding assistants like Claude Code, Gemini, Codex. Some of you know I personally use Claude Code a lot, right? But again, I'll speak again in two months, we'll see what we're using in two months.
And one thing I find is the tools evolve so quickly that it actually makes a material difference if you're on the latest generation of tools versus not. Maybe LLMs have matured enough that, you know, heck, if you're using GPT-4 instead of GPT-5, or if you're using, you know, whatever, it's fine. If you're using Gemini, there are multiple models that are just good enough for a lot of business applications. But coding assistants is one of the sectors that's evolving so fast that being half a generation behind or one generation behind, it actually makes a very material difference right now. Whereas if you use an LLM that's six months old, you know, it's probably okay for a lot of applications.
And the other exciting thing I see is this is leading to new philosophies on software engineering. So code used to be such a valuable artifact, was so difficult to build with this legacy software, is so valuable, going to maintain it, update it. But code is becoming less valuable as an artifact because AI can write it for you. And even choosing an architecture is closer to a two-way door, meaning this Jeff Bezos term where you can make a decision, if you don't like it, change it. So previously, if you set up a database schema, you frankly don't ever want to change that. But now, if I have the wrong database schema, it's fine, you know, get AI to maybe do the migration for you, it's not nearly as painful. So when I'm building, sometimes I'll, you know, in a day explore three completely different architectures, right? And it's fine. And then maybe next week I'll say, you know what, let's ditch my code base, let's rebuild everything from scratch. So this is leading to very new ways of thinking about software.
And one of the exciting things, I'll come back to this later, is Silicon Valley, and I suspect all of you in this room and many of you watching the live stream, are actually at the forefront of this. I'll come back to that later. But one of the biggest changes I'm seeing in software is when building becomes easier, which is important, let's keep making that even easier, then deciding what to build becomes a bigger bottleneck. I've been calling this the product management bottleneck.
So at AI Fund, also at DeepLearning.AI, when we're building products, I think of us as trying to drive a very rapid iteration loop where we write some software to build a prototype, maybe a quick and dirty prototype, and then we do some product management work, PM work, go and get user feedback that shapes our views on the product, that causes us to update what we want to build, and we iterate around this loop really quickly to try to build user intuition and get to better product. Right, so this to me, this is a core loop that, you know, AI Fund, DeepLearning.AI, many of my teams use to drive software development. Because of AI coding assistance, rapid engineering, we can now build software much faster than ever before, and this means that getting the feedback or honing our intuition of what users actually want, this is a bigger and bigger bottleneck.
So previously, if it took me three weeks to build a prototype, then, you know, it's fine if we spend a week to do a design study or whatever. So three weeks to write code, a week to get feedback, that's fine. But now if we can write the software in a day, then needing to spend a whole week to get user feedback, that feels like an eternity. So one interesting trend I'm seeing is a lot of my teams, we make more and more decisions by gut because it's a very fast decision-making process. And, you know, I'm a data person, right? I love data, work on AI data, I talk about data-centric AI, so clearly I value and respect data. And in fact, we're at Snowflake, but, you know, data company, data is important. But let me share with you one example of a decision that I made.
So as I work on a product, we had... this is not yet shipped, so I don't want to talk about the details, but long story short, we had four product ideas. I liked one of them, and my team disagreed with me. And so they ran a user survey to, you know, find out what users liked. And it turned out the data came back and I was wrong, right? My gut said I like version one, users like version three. So to me, the bad way to use that data would be to say, oh, users like version three, let's ship, let's build feature three instead of feature one. That's fine, many teams do that, your decision is data-driven, so that's fine. But to me, that's a very simple way to use data.
What I actually did was not just say the data says feature three, let's make a decision to do that. What I did was I spent a long time scrutinizing the user data. We asked multiple questions, of which this is one, and really sat and reflected, all right, how did I mess this up? Why did I think users want feature one when clearly the data came back to say users want feature three? Because instead of going from data to decision, which is data shows us feature three, let's build that, this data to decision, what I wanted to do was data to hone my intuition, and my gut then makes a decision on what to build. And this is a big difference because what this means is I really spent like a couple hours, all right, how did I, you know, how did I mess this one up? Because I think by spending that time to hone my gut, it then lets me make not just this one decision a superior way, but a lot of other decisions in a superior way to how we serve users.
And in light of that, we actually spend a lot of time thinking about a portfolio of tactics to hone our intuition about users. And maybe there's a long list, right? But yeah, we do everything from play with the product yourself, and if you know users well, your gut could be pretty good, right? And I know there are, you know, I don't know, official UI studies people that hate it when I say that, right? Because of course we're not the user, but when your gut about the user is pretty good, it's a very fast decision-making process. To ask friends, teammates, hallway usability testing, hallway testing, ask strangers. It turns out in my career, I've learned where there's high foot traffic. So I've learned that I'll often, like, sit in a coffee shop or hotel lobby and very respectfully, you know, grab strangers and also look at my products. I still do a bit to this days with prototype testers, you know, all the way up to launching A/B testing. And I know Silicon Valley likes A/B testing, and of course we do A/B testing. We want rigorous results. But to me, this is actually one of the slowest tactics in our portfolio that we use very rarely. But so this is an example of the types of workflows that we see when accelerations in engineering are driving bottlenecks elsewhere that we now have to work to alleviate.
One of the things I think many of you will be asked, because of who a lot of you are, is your software engineering friends, your non-software engineering friends may be asking, should I learn to code? And I want to just take a minute to address that, then before I come back to wrap up, which is over the last year, a bunch of people have advised others not to learn to code, saying AI will automate it. And I think we'll look back on this as some of the worst career advice like ever given.
When software engineering went from punch card to keyboard and terminal, there were actually people saying back then, look, we now have COBOL, coding is so easy, like you don't need software engineers. People actually thought that, right? But that was wrong. I mean, COBOL, keyboard, and terminal made coding much easier, and more people did it. When we went from assembly to higher-level languages, text editors, IDEs, and now AI coding assistants, every step is making coding easier. And what this means is a lot more people should be learning to code. So at both AI Fund and DeepLearning.AI, I think everyone learns to code. And I actually posted, you know, an example on YouTube how when our CFO knows how to code, she could do work that makes her and her team more efficient. Or when our, you know, assistant general counsel as a lawyer knows how to code, well, he speeds up how he processes NDAs. Or when a front desk person, you know, knows how to code, she could do work that she could not previously. So I find that I just ask you to just encourage all your friends to learn to code.
And one of the ways I think about it is one thing that really clicked for me was when I was teaching Generative AI for Everyone. It was the fastest growing course on Coursera. The year it was launched was for non-technical people to get a business sense of GenAI. But we needed to generate artwork like this right in the background. And I was working with a collaborator, Tommy Nelson, that understood art history, and so he could prompt AI image generation, Midjourney. He could prompt Midjourney with the language of art, with the artistic inspiration, the palette, the genre inspiration. And so he could generate beautiful pictures like these. I, on the other hand, you know, I don't know art history. I wish I did, but all I could do was prompt, please make pretty pictures of robots for me. And I could never get the control that Tommy did, which is why we ended up using all of his pictures and none of mine.
And I think, look, into the future, not just for all of us developers, but really for everyone, one of the most important skills of the future is the ability to tell a computer exactly what you want it to do so the computer would do it for you. And for the foreseeable future, knowing the language of computers, knowing coding, will allow you to have that deeper understanding of computers to control it much more finely. It's not that people need to write code with their ten fingers that much, you get AI to do it for you, but that deeper understanding will be critical for telling computers what to do for you. So I hope that we can go out and spread the word because what I'm seeing is not just for software engineers, but also for almost pretty much all knowledge workers, the ones that know how to do this with AI assistants are just much more effective and much more powerful. And so I think it's important that we bring them along with us as well, even as these tools make it so much easier for all of us in this room.
And one other piece of hype that I'm seeing is with AI-assisted coding or whatever's going on in the world. So people are wondering, do we need CS majors, right? And so unemployment for recent CS grads has ticked up to, I think, like 7% or something, which is concerning. But what I'm seeing is there's an AI engineer shortage. I wrote about this in The Batch, calling it generative AI application engineers, but I think that's too much of a mouthful. But what I'm seeing is, unfortunately, there's still many universities that have not yet upgraded the curricula to teach students for what the job roles are today. But frankly, AI engineers, I can't find enough of them. Businesses can't find enough of them. And unfortunately, there are people getting degrees that, you know, they graduate without having made even a single LLM call, right? And that's just like... and actually I have met recent students that, you know, have not yet tried any of the AI coding assistants. I think that's really unfortunate. But I find that when I talk to many businesses, we just can't find enough AI engineers.
So to me, these are some of the key skills from what I'm seeing for this emerging AI engineer role. One is familiarity with AI-assisted coding. I mean, frankly, just so much more productive if you know how to use these tools. And the good news is it's not like it takes two years to learn these tools because the tools have not really been around for that long, right? But it is a critical skill. And second skill set I find really important is familiarity with AI building blocks. So because of LLMs, businesses or open source, you know, closed source, whatever, there are now techniques for prompting, for implementing RAG, agent workflows, how to do eval. And I find that one of the most important skills to building agentic workflows is the ability to drive a disciplined error analysis process, which is surprisingly hard. But to kind of go learn that, how to use tools, things like MCP, voice stack, and so on. But I find that this new set of AI building blocks, it lets you write software that just does a lot more than what was possible two years ago. And so if you know this, your software, you just have a lot more options of building blocks to put together combinatorially to build new types of software.
Another last skill set is this kind of rapid prototyping skill set, right? Including basic full-stack, basic full-stack knowledge. And it's been really interesting. You know, I find that, I don't know, I was a pretty sucky front-end developer. I still am if I'm being honest. My background is much more backend machine learning. But with AI assistance, I'm a fantastic front-end... no, not really. That's not really true. But I find that coding assistants, you can kind of see the front-end bugs more easily, whereas they trick you, backend bugs that can take you weeks to debug still. So, but I find that basic full-stack knowledge, you know, so you can prompt AI, right, to write full-stack for you, front-end, back-end, is helpful. Understanding of architecture decisions, right? And then also to the extent that because of the product management bottleneck, I find that developers with very basic product management skills... So I find if an engineer needs a pixel-perfect Figma design, you know, then they just build the pixel-perfect Figma design, that's less valuable. Whereas if product management can give looser guidelines and if engineers can have more user sense and user judgment to make some of the basic product decisions, have some user intuition, basic design decisions, it actually lets the team go much faster.
So despite the doom and gloom about recent grads taking on employment, which is a problem we need to solve, I see many businesses all around Silicon Valley like we just couldn't find enough people with the skill set. And the job opportunities are actually, if you have the skill set, like come and you're looking for a job, talk to me. There are many businesses I can introduce you to. There's a real, real shortage, real opportunity for a lot of people.
So just to wrap up, I know I touched a lot of points, but just to close, a few points. I feel fortunate that many of us here in Silicon Valley, or those of you watching the live stream, probably means you're connected enough, right, to find out about this video and get a hold of this. I feel like there is a... I think many of us here, candidly, are at the forefront of rapid engineering. Oh, and maybe there's the other term, vibe coding, which is fine. A lot of people vibe code. I tend not to use that term as much because I think it misleads people into thinking just go to vibes, you know, accept all the changes Claude suggests. And yeah, you could do that, but I wish it was that easy, right? When I'm coding for a day or an afternoon with a coding assistant, I'm exhausted, a deeply intellectual exercise. So I find the term vibe coding, a lot of non-technical people use it, but I would not write on my resume I'm a vibe coder. So, but anyway, whereas I think rapid engineering is a term that actually Eli from AI Fund suggested to me that I think kind of shows frankly how important but also how tough it is, right? And this is leading to a lot of changes in workflows in software, like the product management bottleneck, but a lot of other things as well that I find really exciting to be discovering alongside you.
One of the things I hope you'll do today is if you are seeing best practices or weird changes in workflow, actually, like, grab me. I'd love to hear what all of you are seeing as well as you're innovating and seeing new problems, running into new problems that did not exist and then finding new solutions. I find that fascinating. I hope the conversation is here, we can all learn from each other in addition to building some cool things today.
And one of the reasons why we wanted to organize the buildathon is because I saw very clearly that there are people in Silicon Valley and other major tech hubs, and maybe elsewhere as well, that can build so much faster than was possible a year before. And a lot of people in the world have just not figured this out. And frankly, we'll still run into people to say, oh, I'm using AI for coding, you know, it's like doing code autocomplete for me, right? And it's so wonderful, and it is wonderful, but we've moved so far beyond that now. So one of the things I hope we'll do is share best practices with each other, learn from each other, but also go spread the word to a lot of the world that is still far from the cutting edge about what is now possible. And maybe going even beyond what I hope all of you will do, which is, you know, help lead the world forward in software.
I think that software is also a harbinger of things to come in other disciplines. So in the LLM world, I think there are two clear buckets of value already. One is answering questions, which, you know, ChatGPT is a market leader for that, just answering people's questions. And then there's also writing code, right? These are the two big buckets of value. And because of that, so much investment has gone into AI for writing code that is very advanced compared to tools for lots of other job disciplines. But I think a lot of the things we're seeing in software, eventually the tools would get better for a lot of other job disciplines as well. And so these really exciting accelerations we're seeing in software will come to other disciplines as well. And so in addition to rapid engineering, everything what we do with software, I feel like it's giving us early lessons even to non-software engineers about what may come soon for their disciplines. And figuring this out for ourselves and really for all knowledge workers in the world, maybe people are knowledge workers too. I find that an exciting set of tasks that I hope all of us can engage in, both for our own work but also to help bring a lot of others with us. So looking forward to a fun day with all of you. Thank you very much.
