Today, more than 3% of the world’s lawyers use Legora, and the company has grown from $1 million to $100 million in ARR since launching in October 2024.

At Startup School 2026, Legora co-founder and CEO Max Junestrand shares how they built one of the fastest-growing enterprise software companies in the world, from cold emailing lawyers and moving into a customer’s office to freezing sales for six months to rebuild the product. He explains why building a company is ultimately about people, how to create a culture that wants to win, and why founders have to learn to love the hustle.

Watch on YouTube

Timestamps

00:07 — From 3 Engineers to $100M ARR
03:15 — How Legora Got Started
05:09 — Learning the Legal Industry From Scratch
07:22 — Getting Rejected by YC
09:36 — Moving Into a Customer’s Office
11:11 — Going From Zero to $1M ARR During YC
13:26 — Why We Froze Sales for Six Months
15:18 — Rebuilding the Product From Scratch
17:26 — Building a Company Is About People
21:51 — Creating a Culture That Wants to Win
25:26 — You Have to Love the Hustle
27:55 — Do Founders Need Domain Expertise?
29:14 — Betting on Models Getting Better
36:29 — When Should You Start a Company?
45:04 — How to Become More Ambitious
48:18 — The Skills Founders Need Today

Transcript

Max: This is a much warmer welcome than what we had coming into Y Combinator the first time. Legora’s YC journey started with a rejection, but more on that story later. In YC, they teach you something called the two sentence description. It is: describe your company in two sentences. Legora is the agentic operating system for lawyers, and it handles complex legal work from start to finish so lawyers can achieve more than ever before. Over 3% of all the world’s lawyers are now active users of Legora. You will learn more about this when you get accepted into YC. When we started looking at the legal industry, it felt like one of the biggest opportunities to apply large language models to solve real problems. The software that we were up against looked like it had been built in the ‘90s. As software engineers, we have been incredibly spoiled with great software because we love to build for each other and for ourselves.

But in the legal industry, this is what the software used to look like and what we were up against when we started out. Now, Legora has grown into a global brand, putting celebrities like Jude Law at the New York Wall Street. And still, I feel like we are only getting started. My favorite Slack channel in Legora is customer love. It is where our customers post things that they truly feel they couldn’t have achieved without our system. We mine many of our sales calls for quotes like this. I wanted to share just a couple with you because I think at the end of the day, this is what it’s all about. A parent asked me at one of the tournaments how I juggle work and all of the golf travel. One word: Legora. Never has the path between an idea and execution been so short.

Never, man. If Legora went away tomorrow, I’d just go back to coaching high school basketball. When Legora went into YC, we were questioned about the idea of even selling and working in the legal industry. It is such a conservative business that had never been lenient to software before. But from the time that we went into GA in October 2024 until the last end of quarter, we’ve grown from one to a hundred million in ARR. Starting from just three engineers in Sweden to a company of over 750 people all over the world, this is awesome. The fact that we’ve gone in to do this starting from Europe, I think just adds another feather in that hat.

But the Legora story almost didn’t happen. And it actually didn’t start with me. In fact, it started almost like the great beginning of a joke. A lawyer, a physicist, an engineer, and a psychologist back in 2020—before GPT, before AI was cool—started a company called Judilica. What they observed was that law school students were going into their internships basically to summarize court cases. With the early models from Google called BERT, they started to explore what this space could be and what was possible to build. My story started in the Swedish archipelago at an island which looks something like this. I met my two co-founders at a volleyball game.

I think startup founder stories can come from many different places. This definitely wasn’t a high-odds place to start. But when I met August and Siga, they showed me a demo of the product they had built. Our group chat actually looked exactly like this. They gave me a demo of the project. With GPT-3.5, they had built a very simple product that could explain what a stock option agreement really meant. We started with that and I said, “This is a super cool demo, a super cool project.” My co-founder Siga said, “I’m glad you want to help out.” I ended up helping out a little bit more than just that.

When GPT-3.5 came, that was the internet moment of our generation. I dropped out of college. I never finished my master’s thesis because the opportunity cost of not building had become too large. But when we started out, it wasn’t obvious that we were going to be a success. To learn about what the legal industry was, what it meant, how lawyers actually worked, we came up with the ingenious plan of cold emailing lawyers on the emails we could find on their websites and writing to them on LinkedIn asking for a lunch where we could learn more about their different practice areas. We offered to pay their hourly fee to have lunch with us. Many of them took us up on that offer, but fortunately for us, many of them didn’t make us pay for the hour. Many of them even paid for the lunch.

Once we had gotten our feet under ourselves, we approached one of the largest law firms in the Nordics named Mannheimer Swartling. But just two years before that, their managing partner had gone on TV and said that AI, back when they were starting to use it, was really more artificial than intelligence. We had to work really hard to change the perception of what both technology and AI could be in the area of law. In law, you are not paid when things go right. You are punished when things go wrong. Many of the initial AI solutions in the space had required an immense amount of training. You had to bring a lot of use cases and examples just to get very, very little results. When GPT-3.5 came, that really changed the story. With Mannheimer Swartling, we ended up moving into their offices and working really closely with them.

And as I said in the beginning, the warm welcome here was quite different from the first time we interacted with YC. We applied in May of 2023 with a promise of being able to query all legal documents using large language models. When we came to our interview, one of the first questions we got asked was, “What type of lawyers are you serving?” Not very knowledgeable about the legal space yet, our response was, “What do you mean? Are there different types of lawyers?” That did not land very well with the YC partners at the time. I actually remember very painfully that Tom Bloomfield started laughing in the interview when we gave that response, and we knew that we were cooked.

But that also gave us the perseverance and the drive to continue. With a lot of letdown, the day after we did not work, but the day after that, we got back to building. Two months later, we got accepted under a new name and with a different platform. We had done our homework. We had done the work. From Sweden, the idea of getting accepted into Y Combinator felt like we were going to Mount Olympus. We were going to dine with the gods and get to work with other startup founders who came from all of the great tech companies that we knew of. Once we got to Y Combinator, we realized that we actually knew a lot more than we thought we did. This is one of my favorite pictures. It is the screenshot I took after we did the video call after our second YC interview when we knew that things had gone a lot better than the first time.

After we got accepted into Y Combinator, we moved into this law firm I mentioned earlier, Mannheimer Swartling. It was the biggest law firm in the Nordics, but they had no real clue about how to work with software and how to work with technology. We ended up getting a conference room with no real windows where the AC would turn off at about 5:00 PM, but it was really close to the Coke fridge. At about 6:00 PM every day, one of the engineers would go up, grab the door, and start waving it back and forth to get more oxygen into the room. Those conference chairs still made an imprint on all of our backs, I think, three years later. Me in the car there with two more screens is when we made the move from the conference room of a law firm to our first real office.

I think one of the key takeaways from this entire experience is that, first off, we quickly learned not to take no for an answer, but also the power of simply reaching out and asking for help. One big lesson from these first three years of building Legora has been that it is very powerful to be a person and to be a company that others want to see succeed and that others want to help.

We came to San Francisco. We got a room at an Airbnb up in Bernal Heights and started building. During YC, we grew from zero to a million dollars in ARR. We also learned the hard way that working across San Francisco and Europe took a big toll on the team. I couldn’t find a picture of this, but I bought an influencer ring light that I put on my laptop. The reason I had that ring light was because I was doing sales calls between 1:00 AM and 10:00 AM every single day in San Francisco to Europe because that was where our initial customer base was. After a rocket trajectory during YC, which now two years later is slow compared to what some of the companies are doing, we set off to fundraise. This was my first time fundraising.

I had no idea what to expect, but we had lined up 80 investor meetings in a week and a half. We had European investors, American investors. The main takeaway from that experience for me was that you need to become a really good storyteller in order to drive interest and to get people on your team. It was also a very different experience talking to some of the European investors versus some of the American investors. I feel like in the US, we think more about what can go right rather than what could possibly go wrong. We ended up working with a venture firm called Benchmark. This is a picture of Chethan, our partner, when we had signed the term sheet. I remember negotiating that term sheet on his desk with a computer open, going on decimals in Excel to determine the exact number of shares.

They ended up investing $9.51 million. Following that investment, Redpoint pre-led our Series A just three weeks later, and we started to run into a challenge. We had about $35 million in the bank. We were 10 people in the team. There was actually a month following that when we made more money from interest rates on those $35 million than we did from customers. That is not a very good sign when you have become a bank. Going into our first board meeting, we had Chethan and we had Redpoint, and it was me and my co-founders. We made a very hard decision, which was to freeze our sales motion. When you work with lawyers, you only really get one chance to get it right. If you show up and the product doesn’t work, or if the lag in the system is too high, or if a system goes down when there’s too much traffic on your Azure instance, you are toast.

After that six-month sales freeze was when we really started ripping. That’s where you see that curve from one million to a hundred million really starting. What happened at the start of that was turning from a small startup looking for PMF to really establishing what our business and what our product was going to be.

In the very, very early days at Leia, even pre-Legora, the way we would decide what to build was by voting. We would make democratic votes in the entire team. For anyone who has built software before, you know that if you have too many chefs in the kitchen, that typically does not make a very good dish. That was exactly what was going on. We were working on too many features. We had to rebuild everything for the product launch that we were going to have after the summer, after the sales freeze. We had to build a platform that was adaptable to foundations that were constantly changing, both with the underlying models and with the frameworks we were using to build agentic workflows like LangChain, et cetera. So in October of 2024, we wrote down what we called the layout product manifesto.

This was basically gathering everything we had learned, putting it into one very simple document that we shared with the entire 25-person team back then, and that we would rally the troops around. At the time, we were doing about $1.3 million in annual recurring revenue. Many of our competitors were doing 10 times that with products that only had one of these features. I also think that’s a function of having started in Sweden. The market is not big enough to house a real unicorn or a decacorn or something even bigger than that. One of the earliest questions we got from YC was, when will you move to the United States? When will you make the jump? It was off the back of this product refocus that we were able to not only compete with the competition on product, but build enough momentum to make the jump over to the US and start to compete for the biggest logos in our markets.

As engineers and as tech people, we often overemphasize the reliance on product and on the tech. But if there’s anything I’ve learned in these past three years, it’s that it’s all about the people. Building product is one thing, but building a company is a very different thing. We made many early mistakes around this.

One of the hiring patterns that we had to unlearn was looking for fancy logos on resumes or what we like to call y-intercept. If you think about somebody’s skill curve, it might start out really high, but if they don’t have a good trajectory upwards, they’re going to have a really hard time working in a company that is scaling exponentially. So instead, we started to look for people like us who wanted to work insanely hard with very high growth potential, and we doubled down on that talent over and over again. Our top seller today is 23 years old and he has sold more than $10 million worth of Legora. He had no sales background. He jumped out of university. By continuously doubling down on that type of talent, I think we have built a very unique culture at Legora. One of those things has been about bringing and building cultural fit.

Up until the point where we were around 500 people, I interviewed every single candidate outside of engineering. Now I interview every director and upwards. But what we have done is set the cultural foundation in the business where it self-selects. We have three values at Legora: lean in, fight for excellence, and grow together. Together they make LFG—let’s fucking go.

That also sends a signal to leaders and others who join the company from perhaps more established backgrounds, where joining a company whose values include profanity quickly tells them what this is about. Another very complex cultural thing, starting a company in Scandinavia, is something called Jantelagen or the law of Jante. This is very foreign to our American friends, but in Swedish culture, this basically means that you should not think that you are somebody or that you are more important than anybody else. Your ideas are not better than anybody else’s. I think a part of this humility is good and it supports a culture where the best ideas win and where people earlier in their careers feel empowered to speak up.

But it’s very hard to build one of the fastest growing enterprise companies in the world if you don’t think that you are somebody or if you don’t think that you are better than anybody else. So we have had to really create a nice cocktail of US, European, and Asian culture all in one to create a global company that is Legora today. I really think that building a strong company culture is the best guarantee to attract and keep the best people. Another way that company culture gets expressed at Legora is through articles like this one that ended up in Sifted.

For us, there is only winning. Everything else is losing in a winner-takes-all market or winner-takes-most market. The company has to run like there’s no place for number two. I think it actually would be fair to say that when Legora was founded, it really had no reason to exist. We were one of many legal AI companies. But because of this mentality and because of not feeling like we’re safe, even though we have achieved extraordinary numbers by any normal measures, we continue acting like professional swimmers who are looking down in our lane while the competition is looking sideways at what we are doing. At Legora, we have had to build a culture to really support that ambition. So starting years behind some of our biggest competition and having to build this intensity in a country where most people want to go for fika at 3:00 PM, which means having a cinnamon bun and a coffee, or go home at five.

One of the ways that has been done is to create cultural values and cultural moments that really distinguish us from many others. In Swedish, there is a saying: you can wake up with a taste of blood because you’re so excited about something. I was doing an article in Swedish and I used that saying, and I didn’t know that the interviewer was going to release that article in English. When this came out, it got lots of fun reactions. One of them was, is Legora made up of vampires? The second one was, you guys need to floss better. Many good ideas, but this has now turned into the word “blood smoke” internally, which means that. And we just keep going at it. I think part of having our HQ in Stockholm has helped us keep this.

Everybody globally from the company does their onboarding in Stockholm, which is a lot nicer in summer than in the winter. But that has created the same vibe in any Legora office, regardless of where you walk in all over the world. I think one great example of this was we had a very big law firm in the US that our competition was working with, but that law firm had a specific problem around being able to draft certain types of documents based on incoming term sheets. Our competition had promised that they were going to solve that problem for them and they hadn’t. So one of our US-based legal engineers, lawyers, learned about this use case, got on a flight to Stockholm, spent a week with our engineers, solved the problem in Sweden, and then went back to the US and delivered it to the customer.

I think that Swedish base has become one of Legora’s real superpowers.

So to round things off before we jump into the Q&A, I’m sharing this stage this weekend with people who have built things at a scale that I haven’t yet gotten close to. I will leave many of the big lessons for them. But what I can tell you is that three years in, it’s a little bit smaller than that. Most of what actually mattered in the company and in Legora so far did not revolve around signing a big client or closing a new round of financing or opening a new big office in Manhattan. It happened in a windowless room without much oxygen or on a call on our way to the airport, a Slack channel at 2:00 AM trying to fix a bug before a big presentation on Monday. Nobody puts that in a pitch deck, but that is what makes the company.

You shouldn’t wait around for those big moments. You have to love the hustle. If I can leave you with anything, it’s that even though we started in a small law firm in Sweden, I was born in the Swedish Archipelago with a class of 10 other people. I thought I had a big plan for my life and I was going to go to McKinsey after school. But when GPT-3.5 dropped in our laps, we truly made that into our thing and we captured what I believe to be our generation’s internet moment. So you can just do things. Legora and myself are living proof of that. So with that, we’re going to jump to Q&A and I want to invite a very good friend, our partner from Y Combinator, Gustaf Alströmer. Gustaf, we’re really becoming professionals at this now.

Gustaf: This is not the first time we’re

Max: Doing this. No. It’s great. It’s good to see you.

Gustaf: You too. Good to see you. Thanks for the talk. That was awesome. Real good.

Max: Thank you.

Gustaf: And always thank you for coming back and speaking to YC and to founders here at Startup School.

Max: Of course.

Gustaf: Ready

Max: To be back.

Gustaf: I wanted to ask the first question, which is one that I’ve gotten from a lot of founders who ask about you, which is you guys are three founders or were three founders who were not lawyers. Yeah. And you started the best legal AI company in the world. Does domain expertise not matter that much anymore?

Max: So there’s actually a story of a Swedish VC who was very bullish on doing the pre-seed of Leia, but they ended up not doing it because we did not have any lawyers in the team. I met one of the partners from there at the airport quite recently, and they were very, very bitter. Leia or Legora turned out to be the lesson for them that perhaps domain expertise is not what you need to succeed. I think that you need a willingness to learn about the market, which we did very, very early by exposing ourselves and spending lots of time with lawyers as much as we possibly could. But I don’t think you need domain expertise. Probably dependent on the market that you’re going after. Maybe if you’re building in quantum computing or in fusion, that’s a good idea.

But legal was easy enough for us to pick up as we went along.

Gustaf: I spoke to some founders yesterday and we spoke about the next categories where the LLMs are not sufficiently good yet, but they will be. It made me think of what you just said when you were toying around with Bard in the early days. What gave you the confidence to build a legal AI product on a model that wasn’t good enough? It was good, but not good enough. There are many other founders probably in this audience who are thinking about the same problem, but in a different domain, maybe mechanical design or some other part where the models are just not good enough.

Max: I think the sort of tribal knowledge when we got started was that you have to fine-tune a model. In 2023, 2022, that was really

Gustaf: The name of the

Max: Game. I even remember, I think it was Bloomberg who spent millions and millions and millions of dollars building a Bloomberg law model. Our view was partly because we didn’t have enough money and partly because we truly believed that to be right. The models will keep improving. I’m sure Sam is going to come up on stage and say that later today.

Gustaf: Yes.

Max: And so by just betting that the models will keep improving, what you should be focused on is how you can deliver the value that the models generate to your market. That was the crux for us. Even with the first generation of ChatGPT, that was unusable in law, partly because the model wasn’t good enough, but partly because it actually didn’t support private conversations or European data hosting. I remember the first sales I ever did, we basically said, “We are like ChatGPT, but we are compliant in Europe.” That was the pitch. That was not a very strong pitch. And clearly ChatGPT would figure out how to do that later on. But at the time it was good enough. And so I think we recognized that you don’t have to build for the world over here. You need to build for the world today and maybe one step ahead. It’s kind of like this ladder where you should maximize the opportunity now, make sure that you get really good relationships with your customers, so that you can also have that conversation with them.

Because if everybody’s betting on this exponential uplift in model capability, the Legora platform will continue delivering more and more value. I think that we have built 1% of all the software that we will build over the company’s history. And probably the product will look very different from what it does today a few years down the line.

Gustaf: Yeah. A lot of news on models this week or last two weeks.

Max: It’s going to be a great episode for whoever makes the documentary.

Gustaf: I’m hoping in some ways we’re making a documentary right now about everything that’s going on. I’m not sure if someone is, but I hope they are. Open weight model is very much the topic right now. And when we spoke on stage a couple of months ago, you talked about that you’re not attached to one specific model. You can work with many different models. Have you updated your view based on this week? How do you think about it? I’m sure there was a moment a year and a half ago when it seemed like there was just one or two models that were really sufficient to power Legora and now there seems like a lot more.

Max: Yes, which I think will be great. Clearly there will be applications of different models in different use cases. If you take customer support, you’re optimizing for speed of turnaround, latency to the customer, and cost on solving a particular ticket. I think Finn used to charge $1 per solved customer ticket.

In law, you actually want the most amount of intelligence quite often because the fraction of a token spend or software spend compared to human expertise applied to the problem is really tiny. If you’re solving complex litigation, you’re going to want to throw the most brain that you can on that problem. So we have really two different camps. One group of our users are asking for the ability to loop really complex models just to work on problems for a long period of time, racking up big LLM costs. Another group of our users are saying, “Can we get access to open source? That is going to be cheaper on our consumption.” I think the answer is somewhere in between.

I think ultimately one of the core IPs and muscles that I encourage as many of you as possible to build is the ability to eval new models and to eval new use cases because that is the superpower that then allows you to route things effectively. We did a lot of that early on because we hired a lot of lawyers into Legora and we made part of their job customer-facing, but part of their job was also to build out use cases that we would throw our evals on. The frontier of cost intelligence and where that frontier lies is yet to be seen. I think there’s also a compute problem where when we lock in big contracts with the labs and with our compute providers, that is actually a huge thing. We cannot have our system go down when a percentage of all the lawyers in the world are working with it and their clients rely on it.

Gustaf: And are there specific benchmarks you look at for how—I’m sure you are.

Max: Well, we look at the Legora bench. We actually announced and released that on Friday last week. That has been work for the past three years and we’ve kept that internal up until Friday. The reason for that was it was basically OpenAI or the Anthropic models, so it wasn’t that interesting to publish benchmarks on. We would only make those two models available in our system and the user could pick. Now the smorgasbord of available options is a lot larger. Actually, we found to our surprise that SpaceX and Grok was one of the best performing models, especially given the costs on our benchmarks. We don’t even have them on our data processing agreement, so we actually can’t yet offer them to our customers, but now we will start to.

Gustaf: And do you see your customers having strong opinions about which models they want to use or is it just that they want whatever is the best?

Max: Some of them have a strong opinion, especially banks and big law firms. They don’t want Chinese models.

Gustaf: Yeah, makes sense.

So I want to go back to just a little bit earlier when you decided you want to build a startup. A lot of people in the audience here—I’ve had two dinners in the last few days with attendees at Startup School. We talked about when should you start a startup. People are working at DeepMind, people working at internships or jobs right now. Often you’re one or two years into it. What would you say was the trigger for you to say, “I’m just going to do this and not do McKinsey,” or the other options that you had?

Max: So my dad had two companies during the dot-com boom, both of which went to zero after raising too much venture capital. So maybe—

Gustaf: Has he been a good mentor for you?

Max: Yes, absolutely. And—

Gustaf: How often do you speak about—

Max: Agora? Oh—

Gustaf: He speak

Max: Probably every day or every other day.

Gustaf: About

Max: Gora? That’s great. Yeah, about lots of stuff. Now I’m too tired to walk home often, so I have to take the train or take a cab. But I used to walk home and I would call him and that would be a lot of fun. Sometimes we call him senior advisor. Actually, for one of our biggest customer pitches, we were stretched for resources, so he came in and did the PowerPoint for that client.

Gustaf: He knew

Max: Everything at this point. Yeah. He knows most of it. He had two companies in the dotcom era, both went to Xero, and then he had a boat business in Archipelago when I grew up. So I’ve always been surrounded by entrepreneurship. I always felt like I wanted to prove myself in that arena. I’m very competitive. I used to play video games. I used to play Dota 2 more than I went to school. And then I think building a company is the optimum. It’s the biggest arena that

Gustaf: You

Max: Can enter. And you’ll either leave victorious or you’ll leave defeated or you’ll be okay. I was very decided that I should probably learn more about the world, which I thought McKinsey was going to be a great place to start, which I still think it is. I think it really teaches you how to work. You learn work ethic there. But I did an internship, and so I think I got a bit of that even during my studies. Then we had this pivotal moment with GPT. We were talking about this. You weren’t as excited about investing a few years back pre-LLMs because there wasn’t a lot of—

Gustaf: There wasn’t a lot going on. I think the last year or two before COVID, there were not a lot of new ideas.

Max: Right. And I remember sitting down pre-GPT, here are all the startup ideas I can think of. Most of them were pretty boring. I don’t think most of them would’ve worked out. And then small companies got a really big advantage versus big companies. I think you saw this in just the way that Microsoft would build Copilots. It didn’t work for a really long time. I remember when that came out and we were like, “Oh my God, we’re so screwed. Every lawyer already works in Word and Outlook, and now they’re just going to use Copilot.” But it turns out it didn’t work. The ability for us then to still build a lot of value was huge. Reflecting back on that, you learn so much by having to figure it out. I really think that the amount of things you learn is a function of the amount of discomfort that you are willing to endure.

When we started Legora, I was super introverted. I really didn’t feel comfortable talking to customers. I wanted to code as much as possible. When you have to go separate ways with an employee for the first time, all of this is just so hard, but you realize that startups are one of the places where you can learn the most in a short amount of time. If I were to build a company again or join a company, I still feel like I learned a lot working at other startups. I actually worked

Gustaf: At

Max: YC startups before starting my own. I would say you should think really deeply about who you start with and the problem space. I think we picked a space more than we picked a problem, which I think is two different ways of going about it. It was completely obvious that legal and AI was going to be a thing. How it was going to be a thing was very uncertain. So we just said, let’s march in this general direction and then we’ll figure it out. That’s one way of doing it. I guess the other way of doing it is you find a specific problem, you solve over that very clearly,

Gustaf: You

Max: Generate ROI, and then you expand from that.

Gustaf: Yeah. You mentioned earlier, well, I know that you are extremely competitive. How is that expressed inside Legora? How does a Legora employee know that Max is a very competitive CEO and loves to win?

Max: Everybody at Legora is like that.

Gustaf: I think it’s self-select. How’s it expressed? Is it like a Friday meeting, here’s our goals?

Max: Well, yes. Everybody knows every monthly goal. I think setting quarterly goals is a little bit tricky.

Gustaf: Is that how it was from the very beginning, was it the three of you guys?

Max: No, then it was no goals. Then it was just every day you try to maximize the outcome.

Gustaf: And

Max: Then when you’re 750 people, you need to plan a little bit better and have some better internal communication. Actually, communication is the thing that really breaks when you scale. I think a lot of people have talked about that already. But you really feel this drive from engineering that they want to build the best product and the best feature. If you compare our tabular review versus the other alternatives in the market, you stack rank it. We have lots of people on vacation now in Stockholm because it’s July. Most of the engineers who are on vacation are more productive than they have ever been because they’re taking a bit of time off, but then they also get to code now on problems that they want to beat and they want to win. It’s a team sport.

Gustaf: And

Max: I think you can be competitive, but be it in a team way. You really need to solidify this winning or losing together strategy. When we get a big win, that is really celebrated. When we have a loss, we really mourn it together. Then we immediately make a plan of how can we flip it, or how can we make a land and turn it around? I feel like people are in solution mode rather than blame mode. I think that has been a big momentum driver for us, but also we’ve been chasing. There were other legal AI companies that were bigger than us when we started. So we always felt, at least in the beginning, like we were chasing. Now we are much bigger.

Gustaf: Let’s say you are the biggest one at some point very soon.

Max: Yes.

Gustaf: Is that going to impact your motivation or your competitiveness? I think

Max: At that time. So that’s interesting. I thought a lot about what happens at that moment. I think we need to either pick out another enemy and go, okay, we have to be bigger than them now, or we have to really find this way of being better than ourselves yesterday. I think that having competitors is a good thing. You should not be overly focused on what they’re doing, but it’s definitely a carrot. And it’s an easy thing to rally around because what you don’t want is a lot of side questions. You want everybody focused on the same thing.

Gustaf: So one question I got from the audience is how do you become more ambitious? And when I ask this question, I’m thinking of a company I’m working with right now who’s like, oh, we want to do this country in Europe and then we’re going to do this other country in Europe. And then maybe next year we’ll do US. You guys did a lot of countries in Europe just during the batch and then -

Max: And now we’re in 50 countries.

Gustaf: And now you’re everywhere and you scale up really quickly. Is that ambition or is that the product was working or did you know that -

Max: Definitely ambition. I think it’s -

Gustaf: How does someone learn that? Or how does someone become more ambitious? Is that possible?

Max: Yeah, I think it’s possible. I actually think the best way to become more ambitious is to have a peer group of other very ambitious people. In my final years of high school, I was pretty lazy. I was playing a lot of video games. I had a pretty easy time in school and I didn’t work that hard. I didn’t know how big the world was outside of my sphere. The first two years in college were the same. Then I made a new friend group of very ambitious people. That made it click for me. I went from doing zero internships to doing eight jobs in one year. I actually think that’s one of the best parts about YC. PJ talked about that in one of the essays, which is you come here and then you just realize that, wow, every peer, everybody’s really ambitious, and so you become more ambitious together.

And I think now we are like that inside of Legora. I don’t feel like I’m the boss. I feel like I’m a peer in the team that is running the company. Our CFO sometimes challenges our marketing team to be more ambitious. A CFO maybe typically wouldn’t care about that,

But we’re all just so forward-leaning and it’s just so fun. Then you really get to assemble this group across the entire company. It’s not just at the top. It’s everywhere.

Gustaf: And

Max: Then you get to watch your creation spiral and become more and more and more ambitious. That is really fun. I also think you need to have big idols and big companies ahead of you. In the beginning -

Gustaf: Who was your idol?

Max: So we would look at Spotify and Klarna as the biggest success tech stories from Stockholm that have ever happened. Then we realized, wow, we have a bigger market cap than Klarna. That was kind of a weird moment. Because we feel like we have done zero to one. And one to 10 and then 10 to 100 still remains. It’s in front of us. So yeah.

Gustaf: Would you say, so people in the audience here are wondering what skills are either more valuable to have now as you’re in school or you’re graduating from school versus not that more valuable? Basically, are the skills that you need to start a company or skills that you need to get into your career changing in a very short amount of time now?

Max: I think storytelling is, at least for the CEO, I had completely underappreciated how important and how good of a skill that would be because what ends up happening is you need to sell the company to yourself.

Working this hard if you don’t believe in your own story is really hard. You need to sell employees. Now we are hiring people. We are competing with the labs for talent. We need to sell the story of how working at Legora is going to be better than working at Anthropic. You need to sell the story to investors. You need to sell the story to customers. I think that in college or in high school or wherever that is, spending time to learn that is useful. I don’t know how to learn it. I actually don’t know how I learned it unless I just had a lot of exposure. I always liked stories. I like video games. I enjoy a good story, but I think that is the most important skill. And then maybe the other really

Gustaf: Important skill - What about technical skills?

Max: Okay. I’ll say one more before we go to technical skills. I used to be a really bad teammate and a really bad collaborator. I played volleyball for a long time growing up. I would be the type of person on the team who, when my teammate missed the serve, I would yell at them and go, “You fucking suck. How could you miss that serve?” That doesn’t get you invited to play the next game.

Gustaf: Yeah. Makes sense.

Max: It doesn’t invite a followership and it doesn’t invite a good vibe. In high school, I really understood that and had to pivot that way of working. I think technical skills, I think that the velocity and your ability to iterate on customer feedback still is probably the most important skill to get started. Even now when we’re bigger, very often we will hear about a particular type of problem a customer’s having in a customer call. I will dump that in the product channel and I’ll go, “How quickly can we turn this around and delight the customer?” That’s a bit strange to do at a thousand person company scale, but still how we do it. You need to make sure that you don’t overly zig-zag and that you continue building towards the right vision. But I still think that your ability as a smaller company to be fast versus your incumbent competition is the superpower.

And when you have a superpower, you need to lean into that. And that’s still true for me. I should be doing the things that I’m uniquely good at and other people in the company do the things that they’re uniquely good at.

I think also technical skills.

Gustaf: Maybe they’re different these days. Technical means something else.

Max: Yes, but it still means being able to build systems at scale. Just because you can produce a lot of code with AI, it’s not an excuse for not being a very good software engineer. And I still think we need many good software engineers. We are hiring a hundred of them at Legora.

Gustaf: What’s the most interesting problems that people get to work on when they join Legora?

Max: Oh, one of the most interesting problems right now is this transition from reactive agents to proactive agents.

Gustaf: What’s an example?

Max: So for the last three years of working with the product, you would give Legora a prompt or a set of instructions and it’s going to go off and do that thing. Now we are basically connecting Legora to different pieces of context and when it gets a trigger, it will start to do something. That means that if the sales team gets a contract, it will get routed to a Legora agent. The Legora agent will start working on it in parallel. If it needs to escalate to a lawyer, it will. Otherwise, it might just execute the contract. Or you connect the entire data room to a Legora agent and the agent automatically starts organizing that data room and produces the due diligence report. It’s having the agent do things without you telling it what it should do. And that for us is the unlock of how does one lawyer produce the outcomes of a team of 10 lawyers with the help of Legora?

I think that’s very interesting. We also have some very interesting problems just from a scale perspective. We’re spending millions and millions and millions of dollars on OCR and document parsing. And these are real engineering problems to go solve at a bigger scale.

Gustaf: Got it. And you grew from zero to 100 million ARR in 18 months in April. Keep growing at a crazy rate.

Max: Yes.

Gustaf: Your job has changed quite a lot in 18 months.

Max: Yes.

Gustaf: We talked earlier about you now interviewing exec teams. We had this talk from the founder of Dropbox at YC a couple years ago. We talked about the mini games that you play. You’ve done a lot of mini games in 18 months, and now you’re at the mini game of building out or hiring people to run your team. That sounds hard. And does it sound like something you’ve done before?

Max: Well, it’s definitely not something I’ve done before.

Gustaf: How do you learn something like that? It seems extremely important to hire the right executive.

Max: In a way, I think most of the work up until that point makes you qualified for that thing. If you’ve—

Gustaf: You get the next mini game by basically having seen the last one.

Max: Yes. But you need to make sure that you learn at part of every mini game. And I think you really need to put the company first, way ahead of your own ego in a way. And I tell this to the executive team, I need to re-qualify for the job as CEO of Legora every quarter. It’s a new company, new challenges, as do they. Running a sales team when you are one million ARR is very different from 150 million ARR. And I think for myself, if you enjoy that, if you enjoy learning new things, if you enjoy being challenged, if you accept the fact that now my most important job is building out the executive team and I’m going to go do that, you will succeed at it. And then I think as always, you try to build a good network of people who have done it before. The tough thing is there’s very few people who have done the company this quickly as we are. And even a lot of the executives that we are now bringing on, they come from SaaS and they come from this world of triple, triple, double, double.

If you grow 40% year-on-year, you are doing fantastic. You’re sort of on track. And—

Gustaf: That’s not enough anymore.

Max: It’s not enough. David, our CFO, joined from Vanta, another YC company. They’ve been very successful, but they’ve grown from 30 million to 300 million in something like four years. And now we’re doing it in one year. And so from 200 people to 1300 people over four years and we’re doing it in one year. And so you need to just compress timelines. I think you need to be brutal at saying no to things. And you need to understand yourself where you have the most competitive edge, where you can do the most.

Gustaf: When I landed in Stockholm at the end of April, all of the ads were basically Legora ads with Jude Law. And I’m curious how you get Jude Law to be the face of the company. And he was like, “If you haven’t seen the ads, I’d recommend you go onto YouTube and watch the Legora Jude Law ads.”

Max: Did you fall in love with Law again?

Gustaf: Yeah, I did.

Max: Yeah, you did? Good. And

Gustaf: What happened? How did you

Max: Score

Gustaf: That?

Max: Okay. So the inside baseball is we had a meeting with one of our marketing agencies and one of their pitches was, “Why don’t we redo very famous legal scenes? You can’t handle the truth. Why don’t we redo famous legal scenes with lawyers, but with Legora?”

Or no, the pitch was this. It was actually pretty funny. All of these movies about lawyers—what if they just had Legora and the movie would be over in a minute? So we got to this idea of working with actors. Then somebody said, “Well, Legora is like AI-powered law. What if we got Jude Law to be AI powered?” That got us down the track of, “Huh, maybe we could get Jude Law.” What’s funny in Hollywood right now is it’s pretty anti-AI with writing scripts, using AI in movies, etc. He thought we were completely unserious when we reached out the first time. Some Swedish AI company wants to work with Jude Law to make billboards and a campaign. But we were so persistent. I think one underappreciated form of negotiation is nagging. It’s one of the things my dad taught me.

And we nagged and nagged and nagged, and he said yes. On one condition: he got to pick his own scriptwriter and cinematographer. Who would’ve known? He brings an SNL script director and the cinematographer from Oppenheimer to light the scene and do the whole cinematography. They basically go into the set and nobody from Legora is allowed in. A few hours later, these magical productions come out.

Gustaf: It’s really good.

Max: It’s so funny. What I think it did for us was it put us in another light where even people outside of law now know about Legora. That has been really exciting.

Gustaf: Awesome. Thank you so much for coming to Startup School. This is awesome.

Max: Thank you, Gustaf. Appreciate having me.

Gustaf: Thanks everyone.

This week's Paper Club is focused on data. As models have scaled across tasks and languages, old assumptions about training and evaluation are starting to break. So we gathered three domain experts to break down the challenges and frontiers of training data, benchmarks, and multilingual pre-training.

Watch on Youtube

Timestamps

00:00 - Francois Chaubard (YC): Why a whole night about data?
9:51 - Vincent Sunn Chen (Snorkel AI): The Art & Science of Benchmarking Agents
28:44 - Volodymyr Kuleshov (Inception AI): Inception: Diffusion Language Models for Production
40:26 - Shayne Redford (Anthropic): ATLAS: Practical Scaling Laws for Multilingual Models

Transcript

Francois: Welcome to YC Data Club this time. I hope you guys like the little picture that we have this time. Paul Graham didn’t like that I was slacking off in my little crown over there, but he does know my name now, so that’s good.

All right, so why data? Why does data warrant its own night to talk about? In 2016, I left my PhD program and I started Focal Systems. And back then the notion was that data is a commodity. I already have downloaded ImageNet. How much more data do I possibly need? And there was lots of chatter about Scale AI being worth a billion dollars. There’s no chance. And there was a lot of VCs — except who was the guy that did Scale AI’s Series A? I think it was Levy at Accel. Besides him, everyone said the terminal value of data businesses was zero. And since then, it’s like $100 billion in market cap creation. So rest assured, the entire VC community has changed their tune on that.

And why? Well, the interview question I would typically ask at Focal — I still ran the deep learning team even until I left nine years later — was, let’s say I had to interview these PhDs from Stanford or MIT, super smart people. And I would say, okay, you train your model, you’re at 85% F1 score on hotdog, not hotdog. What do you do next? And if your answer was, oh, I would go read some papers, I would try ReLU versus GELU, I would add more layers, I’d do that — nope, next. Literally, no, no, no, no, no.

And the reason why is because you have to look at the data. The correct answer is you look at the data, you classify, you look at all the false positives, you look at all the false negatives, you put them in Pareto buckets, you say, what’s the biggest issue? And for us, for in-stock, out-of-stock, it’s like, okay, it’s when the fridge has some fog on it. We can’t see through the fog, or when there’s a person in the way, or when something else is happening. The number of layers was not going to change if there’s a person in the way and you can’t possibly tell if there’s an in-stock or out-of-stock. And so it’s just looking at data.

Andrej, I would say, was the most on this. And he famously did the first measurement of what human level is on ImageNet, where he actually looked through and tried to see how good he could be. And we’re not that good. I can’t tell the difference between an Eskimo sheepdog and a Siberian husky. I’m not good at that. And 30, 40% of ImageNet is dogs, are types of dogs. And people kind of don’t know that stuff.

And so the data that you’re training on ends up being much more important than the architecture itself, especially when the architecture is very expressive. In your PhD, he says, he spent maybe 5% of his time thinking about data and 95% of his time focused on the architecture. And then when you go into production, that flips. He was saying 25, 75%. I think nowadays it’s like 3%, 97%. And it’s really about the data now that we have the transformer and it works really well.

And why is this? Why does the data matter so much? It’s because in your nice little ImageNet train set, everything is really nice. The train distribution is beautiful. It’s amazing. And then when you launch it into production — raise your hand if you’ve ever had this experience — that happens. And then you start getting a bunch of points in the test distribution that you didn’t have in the train. And the model pukes itself and it doesn’t work.

So to automate the economy, if this is GDPval, we need both expert data and expert RL environments. RL environments for the verifiable rewards. And then for the preference-style data, very subjective: do you like this design? Do you not like this design? Is this more usable or less usable? The code may work, but the coding style is awful and it’s unmaintainable code. For things like medical, two doctors don’t agree on the same answer for a given patient, and same thing with judges. And so these are preference-style answers, and that runs a lot of the economy.

And the right way to think about data sets and RL environments, for sure, is these are products. If you talk to Greg at ARC-AGI, the amount of craftsmanship that goes into each game — that Prime Intellect just crushed, to be fair — is incredible. It’s very, very difficult to make these data sets really, really good, fully comprehensive.

And even for Focal, such a simple thing as in-stock and out-of-stock, the amount of time that was spent on how do we handle product pushers? It looks like a product, but it’s just pushing product to the front. And so should we have that be a separate class in the ontology, or should we classify that as an out-of-stock? Because it technically is an out-of-stock, but it’s going to confuse the model, because an out-of-stock and a product pusher look very different. So how do you handle all this stuff? It’s very, very difficult. And a lot of people think that they’re just zip files, and it’s really not.

And then the other thing too that I deal with a lot in the batch is, let’s say you are automating Salesforce and you have a bunch of traces and you have screen captures of people using Salesforce. So you have a hundred billion hours, you have all the data that you could possibly capture. Then Salesforce changes the UI. Then what? You better get some more data, right? Because it’s not going to work. And so you can have all the data, you still need more data. And so this idea that the terminal value is going to be zero is just so, so wrong.

Brendan just put in this slide at Sequoia and I really agree with it. It is the bottleneck right now. It is not the architecture. It is not GPUs. It is not watts. It’s largely why ChatGPT still — I just did this analysis, I posted it on my Twitter — there’s no model that beats random on predicting next-seven-day returns on the S&P. Literally, if you just roll a coin, it’s better than every single AI model that you can use in production right now. And so if we had a bunch of traces from Goldman Sachs traders that are definitely better than random, I would think that they would do better, but they don’t have that. And same thing with accountants, doctors, lawyers. You need experts in each one of these domains for us to match or exceed human capabilities on it.

And like I said, in the last 10 years, despite most venture capitalists turning a blind eye to this, it’s produced over a hundred billion dollars of market cap. It’s probably been one of YC’s best categories that we’ve invested in.

And so, what is the right mental model to think about this? I don’t know, but I propose something here. If I were Apple and I manufactured these things and I wanted them to be able to deliver groceries to your door, or to bring a burrito to your house, or bring a car and pick you up, or turn on a flashlight, or give you directions — you need these things called apps. And if you want the LLM to be a good doctor, accountant, lawyer, carpenter, trader, or therapist — a lot of people are using it for that as well — you’re going to need data and RL environments. And if you don’t have up-to-date, very good curated data, then your LLM can’t do those things.

And so a lot of people say, how many possible data companies can we have in this space? And the answer is, how many apps do you have on your phone? That’s probably the answer. I really do think about it like that.

And then even better on this analogy is, does it make sense for there to be an Instacart only for Apple and an Instacart only for Android? Or should it probably just be one company? Or should Apple get into the Instacart business and start delivering groceries? It doesn’t make any sense. Some of these, it makes sense. Apple should and Android should have a flashlight functionality, because that’s kind of easy to do. But for a lot of things, it’s really, really difficult to stand up the entire Instacart network and then start competing with Instacart if you’re Apple. Why? That’s just not what you are great at.

And in the same way, going really deep into being a great doctor, dealing with HIPAA and all that stuff — should Anthropic, OpenAI, Google, Apple, all these companies all get really great at curating an AI doctor? Or should you just use one company that does a great job of creating an RL environment, has a network of doctors, curates all this preference data, parallel data for a given patient — here’s one trajectory, here’s another trajectory, and a doctor is preferring one or the other? Probably just do that. Have one company that just focuses on that. And that’s what we’re seeing.

All right. I’m very excited by the speakers that we have tonight. May couldn’t make it. She got sick, unfortunately. We’re going to try to squeeze her into the next one. But we have Vincent Chen, who is a Hazy Research alumni, one of the founding team members of Snorkel, grew it to a billion dollar market cap now and well beyond, I think. Volo, founder of Inception Labs, Cornell professor, and expert surfer. And then Shane, MIT, PhD student, just defended, focused on pre-training, founded the Data Provenance Initiative, and then recently joined Anthropic. Please help me give a round of applause to our speakers.

Vincent: Thanks, Francois. Wonderful. Thank you, Francois, for the awesome introduction, and thank you for giving data its flowers. I feel like we’ve been trying to shout from the roofs about this, and it’s awesome to see it come front and center these days.

My name is Vincent. I’m one of the founding team members at Snorkel. I started our frontier lab business at the company, and now I lead research on benchmarks and evaluation. I’m going to talk about scaling expert supervision. I’m cheating a little bit, but I’ll talk about a few research themes and how they’ve evolved over the years.

We’ve been working on data for over a decade now at Snorkel, dating back to our roots at the Stanford AI Lab. And our key thesis is that scaling expertise — actually giving leverage to experts in the field, doctors, clinicians, journalists, people who actually have the spec in their head for what good looks like — is the real bottleneck for building really effective data sets. And effectively, that’s what all of our research is about at the company.

As I mentioned, we’re a frontier lab focused on data in particular. We’re super excited to be partnered with effectively every global frontier lab and Fortune 10 enterprises on the data problem. And each one of these engagements is anchored on this key bottleneck of scaling expertise. How do we actually get the judgment and knowledge out of these people’s heads and into the data sets that they’re working on?

So I first want to start by framing the problem and how it’s evolved over time. Expert supervision — the process of taking what is in experts’ heads, what is in messy documents or knowledge corpuses, and putting it into really effective data — is a real bottleneck. There’s a real process that goes from, okay, this is raw data, to something that can be used for evaluation and training.

Data 1.0, as I’ll call it, was basic labeling for question answering, for example. These might have been thumbs up, thumbs down preference labels, basic prompt and response pairs. And let’s say it’s 30 seconds of human judgment to produce one of these labels.

As Francois alluded to, the shape of data today is evolving significantly. Now we have entire worlds that we’re building against that represent tasks and rubrics and verifiers and really nuanced grading mechanisms, all packaged in Docker environments that actually need to represent the types of spaces that these agents are going to operate in. And these could take single digit to triple digit hours for humans to develop on their own. And so the key bottleneck here is really, how do we scale expertise so that we can effectively build these types of data sets, when there are only so many of these experts in the world with increasing complexity, and they only have so much time in a day?

So let’s start with Data 1.0. This is a problem that I believe still exists today, but when we started Snorkel, I want to share a little bit about how we thought about this problem. The problem of manual labeling, with the ImageNet example that Francois gave — there are a bunch of problems. One, it’s not a scalable approach. Think of the cost of manual labeling as an O(N) problem. For every single data point, you need a manual label, you need new cognitive effort to actually develop that. Two, these types of approaches aren’t robust to noise. You can imagine that the only way to actually reduce noise in these settings is to introduce redundancy. So you need a K-by-N relabeling effort to actually reduce noise. With changes in spec, schema, task definition, you need to start from zero. And critically, there’s no provenance. There’s no notion of what is my rationale, how did I actually think about this problem?

And so this was the key challenge that we faced up to a decade ago and still face today in many ways, where the problem of manual labeling only compounds in expert domains. Think of an MD-PhD or a cardiologist in a very niche subdomain. How do you actually get them to produce these large corpuses of MRI data sets or EHR data? It’s actually fundamentally intractable in a lot of these settings.

And so the line of work that we worked on here, we call it data programming. Our CEO Alex was a grad student at the time, and we all kind of contributed to this work. The key intuition here was we want to encode expert supervision in software. And there’s a few benefits when you do that. You get the scale of software — you now get to label data programmatically. You get the adaptability of software. You can refactor it and adjust it over time as your spec changes. And critically, you can actually audit it and have conversations about it and collaborate on it.

And so in a nutshell, a bunch of our key grad school work was this. One, on the left-hand side, the main idea was to first model expertise as labeling functions. This could be a number of different forms — it’s a pretty general abstraction — but the main idea is, if you express the rationales or reasons why people are labeling spam versus not spam into specific heuristics, this helps get that knowledge out of people’s heads and into a form factor that’s actually way more reproducible and scalable. Number two, in the middle, the challenge with this is obviously that these signals, these sources of supervision, overlap. They’re inaccurate. And so we introduced a bunch of theory and work to actually work through this notion of weak supervision. How do you actually understand quality in these settings where signals are overlapping and your sources are weak or aren’t fully ground truth? And at the end of this, taking these denoised signals and using them in end models that are noise-aware helps generalize this beyond the coverage of the initial labeling functions.

So one click down, the intuition behind the label model, without getting into too much of the gory details. Number one, the goal here is to model each voter’s accuracy in a fully unsupervised way. So the analogy I like to share is, hey, you have a number of students in your class with different levels of skill or quality. You don’t have a grading key, you don’t have an answer key. How do you estimate the true ground truth answer when you only have the votes from each of these students? That’s the fundamental modeling problem you’re trying to solve. You want to learn this noise model and understand each source’s quality effectively, given that you don’t have any ground truth in the first place. So step one is to learn the voters’ accuracy. Step two, this is Bayes — you’re trying to compute the probability of the ground truth solution given each one of those voters’ actual votes. And then three, if you train a noise-aware model, you’re able to actually extend the coverage of this label model and minimize some of the noise in broader distributions and scale this a lot more effectively.

So I’ll zoom out for a sec. The main intuition here was that a lot of our work in the early days was about scaling expertise via introducing labels and expert judgment as software. And one of the key bottlenecks there was actually denoising the sources of signal that these came from, in a regime where you were missing ground truth. And some of these techniques we still use today in a lot of our production settings.

So I want to talk briefly about Data 2.0 now. As the surface area for data and frontier progress has expanded, it’s grown in complexity and importance as well. So let’s use coding as an example. I have plotted on the x-axis complexity. Input complexity — how complex are your prompts and the specs that you’re giving models? Output complexity, environment complexity — are you working in just Q&A settings now, or are they fundamentally new environments where you give it YOLO access to your desktop? And on the y-axis, we have sequence length. How long are these agents actually working in practice?

Now, you might think for a domain like software coding that the evals are actually saturated, the data is actually saturated. And I would contend that as the frontier advances, the data challenges actually continue to grow. We’ve seen basic evals like HumanEval saturate at this point, which is true, but we’re still seeing a big spectrum of terminal-based agents continue to grow. ProgramBench — I think the latest model just cracked 1%. We introduced a benchmark called Senior SWE-Bench, which I’ll talk about in a second. But as the complexity and responsibility of agents grows, the importance of the data that you’re producing to both train and evaluate these models also grows.

With this in mind, I want to anchor on some recent work, which was Senior SWE-Bench. We were very humbled and privileged to work with the original SWE-Bench team out of Princeton on this. The key idea here was, we’re already using coding agents like senior engineers. We’re vibe coding, we’re trusting them to make architectural decisions, to refactor entire swaths of code, but we don’t have good ways to evaluate them. We’re still evaluating them as junior engineers. And so the key challenge we wanted to solve was that we wanted to build a benchmark, we wanted to build data sets that were really representative of actual work that senior engineers would produce, scale the expertise needed to produce and build these types of data sets, and build a really high quality benchmark that represented all of these factors. So I’ll talk you through some of the methodology we used to get here. Obviously we won’t get through everything, but hopefully it builds some intuition for how some of the methods we’ve used have evolved over time.

A little bit about the tasks themselves. In Senior SWE-Bench, the task design specifically required many points of expert supervision or expert touchpoints. On the left-hand side, this is a Harbor task. We’re big fans of Harbor as an eval framework. These are natural language instructions. The key diff here was that, if you’re familiar with SWE-Bench or traditional coding benchmarks, if you actually look at the data, if you actually look at the tasks, a lot of the samples are very overspecified, very PRD-level guidance for what to do, what not to do. We wanted to represent more realistic and higher-level abstractions in terms of how we actually interact with these agents in practice. So more of a Slack message — “hey, here’s a dump of logs, figure out what to do with it,” or “here’s a few user stories about an idea that I have, can you help me implement this?” So actually injecting expertise and realism into the instructions was the super non-trivial part of building this.

On the right-hand side, you see a whole reward phase, which we spent a lot of time designing and specifically calibrating as well. The intuition here is we wanted to capture a number of different components of how you actually measure these agents in practice. So not just, is this correct or mergeable, but does this exhibit taste? Does this exhibit what you’d trust a staff or senior or principal level engineer to actually do in your code base completely unsupervised?

Let’s go a click deeper into the specific reward design. This was a bit nuanced, and again, an area where we wanted to get creative in scaling expertise. So we had Snorkel engineers and researchers — we have a really strong network of very senior principal, staff level engineers, but not unlimited time. And so we wanted to find ways to scale their intuition and effort rather than having them hand-grade every single one of these samples and agent trajectories.

The axis we tried to articulate here is that there’s a trade-off between reliability and flexibility when it comes to traditional verifiers and rewards, especially in the software domain. On the top, you have high reliability and low flexibility. These are pre-written verifiers — think of these as unit tests. These are tests that reliably execute against your code base. They’re actually running against the code, so you know that they’re doing the thing. But the challenge is they don’t actually adapt to any solution. If you have a POST /profile implementation versus another way to update a user’s information, you might actually have a false negative in the verifier. You might penalize behavior that is fully okay and fully valid if you’re too constrained in your verification approach.

And so on the other side of the spectrum, low reliability, high flexibility, you have LLM judges. This is a very common and effective way in many cases to actually adapt to different solution shapes. The code can be a little bit more flexible. You’re actually just asking an agent or LLM to look at the code and specifically grade it using its own calibrated or uncalibrated intuition. And obviously the challenge here is that this can be really unreliable, because you’re not really exercising any of the solutions. You’re not exercising the code path directly. You might be just asking the agent to take a glance at the code, and it’s hard to actually control for false positives, where you may over-reward plausible but incorrect solutions.

And so we found a middle ground for this, and introduced this notion of a validation agent, which specifically tried to capture and scale the expertise of a bunch of our senior researchers and engineers and experts in our community and network — one, to express the user stories or specification of what they thought good looked like, and two, use that specification to then write deterministic tests against the code surface that was actually relevant to the solution space. So a simple idea, but it did take a lot of calibration and effort to actually come up with this notion of, how do we actually capture the expertise of someone who’s defining user stories for a particular task, while actually exercising the real code path?

So in a little bit more detail, what does this actually look like in practice? The input to this validation agent — think, hey, I have Codex, I have Claude Code. It generates a patch against my instruction set. The expert produces what we call the validation spec. So this was just a few bullet points, a Slack message of, okay, here are my user stories, here are a few functional or non-functional requirements. Not so much that it was overspecified and overly prescriptive about a specific solution, but high level enough that it actually captured the space of what we wanted the model to do or not do. We then had a validation agent take the patch and the validation spec and specifically implement test scripts. These were deterministic scripts that would execute and run over the code itself. And at the end of this, we would score against both the execution and use a judge to ensure that the runs were sane, or resulted in collusion or reward hacking or some sort of behavior that we thought was not valid for the trial.

And so this idea of encoding expertise in a way that was still scalable was really the crux of how we tried to design this validation agent to map to dynamic implementations in a specific code base. We did a lot of work to calibrate this. We aligned these against specific test engineers internally in our network. We introduced LLM judges that measured things like fidelity, completeness, collusion. And ultimately each test was parameterized so that in the validation spec, you can think of it as a ramble of, hey, what is the shape of the type of use cases, edge cases that we want to capture, without having to write the full test at the end of the day, which could take days to weeks to months.

So this is live now. And one thing I want to point out before talking about the results, which are kind of fun — we introduced this notion of a tasteful pass. This is a new metric that we introduced in this benchmark to specifically measure not just correctness or mergeability, but a more nuanced definition of, is this actually code that aligns to your code base practices? Does this actually map to how a senior engineer would act in practice? Is bloat minimized in terms of patch size? We merged that with notions of correctness to actually rank a bunch of these models. And remarkably — and we double and triple checked this — Fable, Opus and Sol are all tied for first place as of last week. This is pretty exciting because it means that the Pareto frontier is definitely getting pushed in these cases. This is a live dashboard and a living benchmark that we’ve been keeping up to date, so definitely reach out and check it out if you’re curious about it.

This is some of our recent work on this topic, and so I want to give some flowers to the team here. Henry, our co-founder, was the lead. We were very humbled to work with Karthik’s group at Princeton, who led the original SWE-Bench, and our chief scientist Fred, who has a lab over at Wisconsin-Madison, and some of his students were also involved.

And so I’ll zoom out and wrap up here. As we enter Data 2.0 and see a lot more complexity, we need a lot more data research. It’s not just a problem of throwing humans at these tasks these days. We need a lot of thoughtful design to give these experts — software engineers, doctors, lawyers, people who actually understand the spec — leverage to exercise their own supervision and judgment in these data sets. And this slide at least shows a view of all the axes that complexity is going to continue to grow in. The environments are going to get more complex and dynamic. The outputs are going to get more and more unverifiable and nuanced and subjective. And the autonomy of these agents is also going to continue to extend. And you could imagine every one of these axes introduces compounding complexity. And so it’s really a research question, it’s really a research problem, to think through how do we scale and provide experts more judgment. And that’s really what we’re focused on and encourage the community to work on as well.

And so here’s a very concrete ask. We need more benchmarks, and we think this is actually a really high leverage way for folks to drive new data research. We’re super humbled to work with a number of the folks on the screen, from Agents Exam over at Berkeley, Continual Learning Bench, OSWorld, the Terminal-Bench folks. We’ve learned a lot working with these folks. And in general, we’re very excited to see a lot more benchmarks. So we like to put our money where our mouth is. We have this notion of open benchmark grants. Hopefully this is actually a resource to folks in the community. We’re very excited to accelerate and focus on more research that is out there and help you accelerate your data development and partner as a research team. But yeah, we’re really excited about the future of benchmarks and data for Data 2.0. Thanks so much.

Francois: All right, next up we have Volo.

Volo: Okay, great. Thank you for having me. Super excited to be here today to tell you about some of our work, some of the work that we’ve been doing at Inception on training real world large scale diffusion language models — with my co-founder Stefano and Aditya and a really, really talented team of engineers and researchers.

So in short, what we’re working on is a new generation of language models that is powered by diffusion. And what that means is that instead of generating tokens one at a time sequentially left to right, a diffusion model starts by generating tokens all at once, starting from an initial guess of the sequence. So starting from some kind of noisy initial version of the output, and then producing all the tokens in parallel over multiple steps of refinement. We’re very excited about this technology. We think it’s going to be the future of language models.

And in particular, a very important advantage these models have today is speed. Because these models can produce multiple tokens per step, they can produce many more tokens per second, and they can reach speeds of over a thousand tokens per second, which is way beyond what is achievable with traditional autoregressive modeling.

There are all kinds of applications for ultra-fast inference in real-time AI. One area that we’ve been working in a lot is real-time voice. So voice agents, for example, in customer support, but also in other domains like education. These are agents that synthesize voice and talk to you in real time. Usually the state-of-the-art voice pipelines are still built on a cascaded architecture, where you have a speech-to-text system, a text-to-speech system at the output, and in the middle you have an LLM. The overall latency of the system is highly bottlenecked by the LLM. This is a critical, critical piece of this workflow. And if you can make LLMs go much faster — if they can go at a thousand tokens per second, like our Mercury 2 models are able to achieve — then you can make real-time voice interactions feel more seamless, or you can deploy a bigger model, or you can get the model to reason for longer, which will then significantly improve your quality.

So this is a slide that shows the performance of Mercury 2 on voice benchmarks compared to other models. And what you see is Mercury 2 draws a new Pareto frontier of quality and latency — latency on the x-axis, quality on the y-axis. So we have a new Pareto frontier that’s achievable with diffusion. I also want to highlight some other models here that are baselines. So here, for example, we have a 120 billion parameter gpt-oss model running on Cerebras, and a diffusion Mercury model can achieve both higher quality, at least as measured here by Tau-bench — and I’m going to argue on real data as well — and it can also run faster.

So this is really exciting, because Cerebras are specialized chips designed and built to make autoregressive models run really fast. If you have diffusion, you can achieve similar speeds on GPUs by having more intelligent software. So you can build software to make models really fast instead of hardware. That’s really exciting. You can deploy these models on a lot more GPUs that are more easily available.

But to build really good voice models, algorithms and diffusion is one component. The other part that’s really, really, really important is the data. You need data both for training the model and for evals. Right now, perhaps the most widely used and representative benchmark for running evals is Tau-bench. Tau-bench has a few problems. First of all, Tau-bench doesn’t really capture all the range of complexity that you see in real world data. If you look at a Tau-bench environment, it probably has an order of magnitude fewer specifications than you would have in a real world setting where a business would be doing real world customer support. There are fewer tools in Tau-bench. It doesn’t have certain kinds of specifications that you would want to provide. And then another problem with Tau-bench is that it’s extremely benchmaxed. If you go to your favorite benchmarking website, you’re probably going to see most of the models achieving scores that are in the 90s. But then if you run these same models on real world production logs, you’re going to get much lower scores, and there’s also going to be much more variance across models of different sizes. So data is a key, key ingredient of building the kinds of performant models that we want to build, in addition to the algorithms.

Now, our approach for getting good data for our models involves a system that we call TauForge, which synthesizes a wide range of realistic RL environments similar to Tau-bench, based on real data, based on real user interactions — either based on data that we’re getting from our data providers, or we also have partnerships with companies that are using this model in production. And so we get a lot of real world data that then allows us to synthesize Tau-bench-like environments across different domains, which can then be used for evals as well as for training the model.

So this slide gives an overview of TauForge. TauForge is an agentic system. It’s a harness that orchestrates a large number of different agents, and it produces synthetic RL environments that are similar to Tau-bench. The input to TauForge is a description of the kind of environment that you would like to generate. So here, for example, you could ask it to generate a banking environment, as well as artifacts that represent real world usage of the model in that target domain.

The first step is to synthesize an initial environment that is based on that data. That involves, for example, a policy that specifies the kind of task or the kind of domain where you want the model to operate. So for example, if this is meant to simulate customer support in banking, then you could generate a policy that describes how the bank would operate, what the hours are, where the users are, different accounts, maybe synthesize a small database. And also it creates tools that the model can use to then interact with this environment. Again, crucially, this can be conditioned on real usage of the model, which ensures that this environment is representative of how the model is going to be used later in production. If this data is not available, we’ve also created what we call the business knowledge graph, which is data that has been crawled all across the internet and that describes various representative businesses. So we can also synthesize domains for which we don’t have real world data, but we have crawled the internet to gain real world knowledge about these businesses.

Now, given an environment, the most important next thing that we want to generate are tasks. So we’re going to have simulated users that will try to achieve certain goals in this environment, and the agent will assist them in these goals. And we need to synthesize what those goals are. In order to do this, we start with what is called a database of seeds. These are abstract scenarios — for example, I want to open an account, close an account, I want to change my phone number, I would like to get some information — as well as personas, which are certain types of humans that might be interacting with the model. Given that we have an environment, we can take our library of scenarios and other seeds and specialize it to this domain, again by invoking an agent. And then once we have a good database, we can start to generate tasks. These are real world interactions that a user would have with these models, and then we will simulate those users using other agents.

Now, getting a good set of tasks is also non-trivial. We need to strike a careful balance of tasks that are not too easy to solve. If a model consistently solves a task, it’s not useful for learning. And conversely, if the task is too hard, there’s also not enough learning signal. So there is an iterative procedure where we filter and reconstruct tasks based on the ability of the model to solve them. And to do this, we use what we call hardening traps, which means that we can modify the task to make it more difficult. So for example, you can take away certain information, or you can make the ask more complex. You can do all kinds of tricks to harden the task, or you can also filter out difficult tasks, until we get something that we feel strikes a good balance between being realistic and providing learning signal to the model.

So again, the output here are RL tasks. And then of course, this is continuously inspected by looking at real world data. These environments can still be verified. The harness can be updated. And also, for models that are coming out of this environment, we get real world feedback from users, and we can use that to further refine the harness and further refine this synthetic generation procedure.

So as an example of what this model can achieve — this is an experiment where we used our latest preview model, Mercury 2.5. Before it was trained on any sort of domain specific data, it achieved about 50% accuracy, and training it on an initial set of tasks synthesized from TauForge improved performance on another set of environments by over 23%, matching the performance of all kinds of state-of-the-art open source and closed source models. And here, just to clarify, the setup is that there’s a diverse set of environments and businesses. So for example, banking or booking airplane tickets and getting a doctor’s appointment. So you can have a whole range of businesses, and you can split that into a test set and a training set. You hill climb on one set of businesses and you test on a different set of businesses, which helps reduce overfitting. And again, these tasks — especially the test set — are closely derived from real world logs, which gives us confidence that this will correlate with real world performance once we deploy into production.

So this is just a bit of information on the kinds of techniques that we can use to make our models really high quality, not just fast, but also improve their intelligence in some very specific priority domains like voice.

And if you’d like to try these models, they’re available. They run at a thousand tokens per second. This is the pricing. And even though I mainly talked about voice in this talk, we also have customers across other domains, including search as well as code. And so these are all domains where Mercury 2 models are really good for latency sensitive tasks. And if you’re interested in feedback, we have YC companies and other companies that are using these, so happy to tell you more after the talk. And maybe I’ll just briefly add by saying that we have a program for YC startups. If you are in YC, we have $500,000 in credits that we’re very happy to give away. If you’re interested, please grab me and I would love to tell you more. Thank you.

Francois: All right, next up we have Shane.

Shane: Awesome. Thank you. Thank you so much for your attention. I think I’m the last talk. I’m Shane. I just graduated from my PhD at MIT. And I think this is my favorite project during my five-year PhD. It was work that I did while interning at Google — thank you for the TPUs to make this happen.

We basically looked at multilingual pre-training, and within that, transfer between the languages. So the synergies, interference, interactions between the different training sets, data set sources, that are different languages. While I walk you through this project for the next 10 minutes, you can imagine all of these experiments and all of these results and methods could be generalized to many different sources within your data. They don’t have to be languages. They could be different domains or different quality sources of data, different things, however you want to splice it up. And I think that’s important because increasingly, when we think about our model’s capabilities, its risks, its limitations, we think about how all of those different pieces interacted and came together.

So diving into this, I’m going to talk a little bit about why this is important, motivating it a little bit beyond English. Then I’m going to go through, really quickly, rapid fire, some of the research questions we asked and the answers we arrived at, before bringing it together. This was presented at ICLR earlier this year with these phenomenal folks at Google, UW, Stanford, and some other places.

If you look at scaling law and even mixing law papers in the literature right now, they are 99% about English training data and English evaluation. There’s very little about the rest of the world and the community, which is actually kind of shocking. And so this is thinking, what if the objective was a single language that wasn’t English, or multiple languages, a cluster of them, and exploring that domain? And why is that different than in English? The reason is because there are severe constraints when you go past the first few languages that are very abundant online. And we also provide tooling and methods both for scaling laws, mixing laws, fine-tuning versus pre-training, and other decisions that developers have to make. And this has implications for developing models for your own culture, society, language. And also trying to figure out, if you are Turkish, what are the constraints in pre-training for Turkish language models? How much will they lag behind language models for English, based off of just the availability of data that’s there, and what synergies and interference we can expect in pre-training?

So let me start with the problem setup. Very simply, let’s pick a language. We’re going to pick Thai, because there’s something like 80 million speakers in the world. It’s a very unique language, but we could be talking about Swahili, Polish — it doesn’t matter. The point is that in MADLAD-400, a popular Common Crawl-based pre-training corpus, there are 0.6% the number of tokens in Thai as compared to English. So less than a percent of the amount of English data that you have.

Some frontier model, ChatGPT, whatever it is — we don’t know, but it has some training mixture among the natural languages. And it’s probably going to roughly follow, like every other language model, the distribution. They’ll do different sampling techniques and things like that, but you’re going to roughly have more English than anything else, followed by the next languages you care about that are more abundant, more heterogeneous, all the way down that list. And by the time you get to Thai, it’s a tiny sliver of the overall mixture, much less than 0.6%. And so the performance on Thai is going to be pretty poor. It might be pretty good overall because it’s a massive model, but it’s not going to be great for Thai speakers. And this is shown in the literature and in evaluations.

So you might say, okay, let’s train a model just for Thai. We’re going to monolingually only train on all of our Thai data. But the problem is there’s so little of it that we end up repeating it again and again and again. Those are those dashed lines, epochs. And you’ve overfit to your Thai data. You need a much smaller model. And so actually you don’t do very well there either.

Ideally, what you want to do, if we skip ahead to the solution, is something like this. It’s actually a mix where you use a lot of your Thai data, but by the time you’re hitting severe diminishing returns, you’re also incorporating — and this isn’t a curriculum, this is all mixed together — high quality synergistic data that happens to be English, Indonesian, Malay, Lao, Croatian, it turns out. But you’re not going to know that, because this isn’t just about what language families are similar. It’s about what data empirically is not noisy in that other source, is actually helpful, covers similar topics. And that is very distributed and uncertain on the web. It doesn’t just mean that they’re from the same language family. So it’s something you have to empirically measure. You can’t just bring a linguist and have them theorize about linguistics for this particular case.

So how do we get to the fantastic Thai model, or Swahili model, or Turkish model, and figure out the right mix and the right model size? First, we want to measure language synergies, and this is where a lot of the contributions of the paper come in. There are many ways you can think about doing this. And the way that we landed on was, imagine this: you have a training curve. So over your training steps, the red line is where you’re training only on Thai data. So it’s monolingual. It does pretty well, but it flattens very early. Now imagine that compared to models that are trained fifty-fifty on Thai and English, Thai and Telugu, Thai and other languages. And you can see that those learning curves are much higher, meaning that they’re not as good. And so actually the distance between these curves tells you something about how good that language is at being helpful for Thai. And so we can say, okay, well, Indonesian’s better than English, it’s better than Telugu, because that distance is longer.

And this efficiency gap can be formalized into something that looks like this. And let me abstract all this away — you don’t have to go into too much detail. If these two lines are really close, the number is big and positive. If the lines are very far away, it’s going to be a negative transfer, meaning there’s interference. These languages are competing for tokens or neurons in order to represent one another and perform well on them.

And if you do this over and over again, with many tricks that I’m not going to get into, you get this big cross-lingual transfer matrix, where red means high synergy and blue means high interference. And so if you look at — you can’t see it, but imagine you could zoom in and look at Spanish, the row — the bright red spots empirically happen to be Portuguese, Italian, and French. And the most negative, harmful language is Japanese, meaning if you train with Japanese, it’s going to hurt your Spanish. And so this is all empirically borne out, and there are some surprises in here, some interesting things. Some languages are more helpful broadly than others, and it’s complicated.

The other really cool thing about this matrix is it’s at one fixed size of language model. If we increase the size of the language model and make it much bigger, then actually a lot of these blues start to turn red or deeper red. There’s more synergy, because the model’s bigger and can accommodate understanding multiple languages at once, or together, and seeing their common patterns. But if the model gets really small, all of these turn to blue and they all interfere, competing for space within the model.

All right, quick question for the audience. Who thinks that if Portuguese is helpful for Spanish, that means that Spanish is helpful for Portuguese — that that symmetry exists, from what we measured? Raise your hand if you think that is true. We have a few people. If you think it’s not true, raise your hand. Okay, it’s kind of fifty-fifty. Well, actually it’s kind of hidden on the screen. I know it’s late. It’s not symmetric, as you can see. And actually there’s this weird sort of branching factor that happened. And this is important, because if you’re a practitioner and you do experiments, you say, okay, Telugu is really helpful for Swahili — you can’t assume the opposite. You have to go measure it. And so that’s where this breaks down, and we actually show that.

Okay, second question. You can redeem yourselves. What is more helpful, do you think — if two languages share the same script, or if they share the same language family? Who wants to vote for family? We have some. Who wants to vote for script? All right, congratulations team script. They both matter, but script matters a little bit more, probably because of tokenization artifacts and how those are represented.

If you’re taking pictures, don’t worry, it’s all online. I will point you to it.

I’m going to go through, in the last three minutes, really quickly, a little bit of math. We have this great matrix. We have all these numbers and relationships between languages. But the last step is, how do we actually create a scaling law from this? How do we actually understand how to predict, to estimate loss, or figure out the best mixture of languages for a given target, which is our original goal? You have to fit scaling laws. Those of you that are familiar with Chinchilla probably remember this. You predict the loss based off of the model size and the amount of data you’ve trained on, and you fit it using these blue parameters here.

However, if you have a multilingual data source and you’re trying to figure out how good it was on French, the thing that matters most is how much French data you had. And if you have tons of other data, how’s that factored in? 1D is not helpful. You need to model all of it. And so that’s what we do. There are many ways to model this. We explored many options, but a simple solution that actually works really well is to break down Chinchilla’s D into a composite of the monolingual source, in this case Thai, the close transfer languages in the matrix, plus a bucket for everything else. And we account for diminishing returns when you do multiple epochs of certain data. There are a lot of details. Long story short, it looks something like this. And the tau is sort of a weighting factor that you can learn from the matrix. I’m going to rush along in the interest of time, but you get bold numbers in a table, state of the art. Yay. It works. It works really well, actually. Maybe because a lot of people can’t run 700 pre-training experiments, maybe because this is underserved and people aren’t looking at this enough. But either way, I think this is really useful machinery to use for mixing multiple sources and understanding how they interact to predict the final loss for your model and how to scale your model given what you have.

So it gets us back to this. I’m going to wrap up by saying we did some experiments to say — you have big pre-trained models available that are multilingual. Do you just fine-tune, or maybe should you pre-train from scratch for the language that you care about? We tell you which to do based on how much compute you have. We also look at the curse of multilinguality. So if you want to increase the size of a language model from four languages, and you want to retrain it for eight languages, how much more data do you need, and how much bigger does the model need to be in order to maintain the same performance as before? We do a bunch of math. It’s very cool. And we show you exactly what to do as a practitioner. And it actually holds really well over different target languages. So I’d recommend consulting this if you’re interested. Thank you so much. Appreciate your attention.

Michael Kratsios has seen the AI boom from both sides: as COO of Scale AI and inside the White House. Today, as the director of the White House Office of Science and Technology Policy, he helps shape America’s national strategy on AI, science, and emerging technology.

At Startup School 2026, he sat down with YC’s head of public policy, Luther Lowe, to talk about how Washington makes technology policy, why the White House supports open source AI, and why little tech needs a seat at the table.

Watch on YouTube

Timestamps

02:38 — From Tech to the White House
04:39 — How Technology Policy Actually Gets Made
05:51 — The White House on Open Source AI
08:28 — How Washington Sees AI Differently
09:53 — Regulating a Technology That Changes Every Six Months
11:37 — Which AI Risks Are Overblown?
13:03 — Giving Little Tech a Seat at the Table
17:31 — Regulation Without Creating Incumbent Moats
18:01 — Born Free vs. Born in Captivity Technologies
20:46 — What Working in the White House Is Actually Like
25:56 — A New Golden Age of American Science
31:32 — Quantum, Congress, IP, and What Comes Next
37:54 — Why Technologists Should Consider Public Service

Transcript

Luther: Michael, welcome to Y Combinator Startup School. We’ve got an amazing crowd here. It’s been an amazing day and I’m really excited to talk about AI policy and your role at the White House under President Trump. But I wanted to tell the audience a little bit about your background. First of all, Michael Kratsios is the director of the White House’s Office of Science and Technology Policy. He’s the president’s top advisor on science and technology and one of the key architects of America’s national AI strategy. He previously served as the country’s chief technology officer in the first term for President Trump, where he led the early federal AI initiatives. He was chief operating officer of Scale AI in between government tours. So he’s seen the frontier from both inside a hyper-growth startup and inside the White House. And so we’re going to talk about how Washington actually thinks about AI.

So I want to get in—you have gone from the government to the private sector and you went back into the government, which is actually not a common thing. And I think it speaks to your character, Michael, because public service is not easy and it is a sacrifice. You could be out making a lot more money doing God knows what, your choice of roles, given the level of connections you have, your background. Why do you choose to do this work?

Michael: To me, I fundamentally believe that American leadership in these emerging technologies is one of the most critical questions of our time. For the American people to have all these benefits that AI is going to offer, we have to make sure that we have a regulatory environment that allows that to succeed. And to me, even a little bit selfishly, I think there is no place where you can work on bigger problems than the US government. Even at the biggest tech companies in the world, you’re never going to be dealing with problems of this scale. So being able to work on that is something that I find very rewarding and very fulfilling. And I just deeply believe that we have to find a way to keep winning. And the government can either help or they can unfortunately screw things up. So being there to try to put it in the right direction is something that I enjoy doing every day.

Luther: Let’s rewind the clock. How did you even find yourself in this place? I’m really curious, at what point in your life did you know that you were going to be passionate about science, technology, this whole field? I don’t know, like 14-year-old or even earlier, Michael Kratsios, and up until the age of the audience, like early 20s, even late teens. Tell me about that part of your life and how you gravitated toward this type of work.

Michael: Yeah. I’d always been obsessed or interested in technology. I would follow all the Steve Jobs keynotes every year obsessively. I still remember in college when the first iPhone came out—I’m dating myself here—but it was this amazing moment. We’d run around and talk to our friends about it. I was not an engineer in college, so I always wasn’t quite sure how to manifest my extreme excitement for technology into something I could do as a career. But ultimately, I ended up in San Francisco and worked for Peter Thiel for almost seven years. Working with him and working with a lot of the companies that he invested in, that’s when it all came together. Over the course of my time there between 2010 and 2017, as we were looking at more and more companies in the portfolio, what kept coming up was this question about regulations.

So whether you were thinking about Lyft and the challenges that they were having at a state or local level, SpaceX with the challenges they were having for launch permits and things that the FAA and Department of Commerce were doing—no matter what kind of industry you were looking at, there was this government angle where the government’s policy actions could be ones that could actually unlock technology. So when the president won and I had the opportunity to join the administration, my first instinct was, how do we look across all the rules that we have and make it easier for innovators to build? How do we get drones flying for commercial drone operations? How do we get autonomous vehicles on the road? How do we get drone deliveries to happen? And those are things that the government can unlock.

Luther: What’s something surprising about how technology policy actually gets made that would surprise everybody in this arena?

Michael: Yeah. I think typically what people who haven’t really worked in this space don’t realize is that these decisions are extraordinarily federated. There isn’t just one or two people in the White House who decide something. Kind of a blessing, I think, of the US system is that there isn’t one agency that does technology. We have a health agency, we have a defense department, but there is no technology department. And what that means is a lot of these tech issues are spread out across multiple agencies. So you have equities from national security questions to commercial-oriented questions to core science and technology research questions. And to make good policy, what the White House has to do is bring all of these agencies together. So whenever—take for example, drones. If you want to make sure that the rule is right to allow for commercial drone operations, you have to make sure that the FAA has the right rules in place, but also that the people who oversee our nuclear weapons are happy so that drones aren’t flying over nuclear sites.

Luther: Take us into the last week or so. Really, this week felt like a noisy week in AI policy. You saw the letter that dropped Friday morning from a lot of the larger companies—Y Combinator had signed it, but also Y Combinator helped organize a letter that you were one of the recipients of on Wednesday evening, really advocating for the government to not clamp down on open weights models. The impetus for that, the energy behind it, was this buzz and rumored, speculative worry that the White House was on the verge of doing an EO that would have restricted or clamped down on open source. Can you talk a little bit about that? How connected to reality is some of the stuff that you’ve seen on Twitter in the last week or so?

And then what is the White House’s policy? I actually spoke with Secretary Lutnik last night at the Correspondents Center, and he said that the White House strongly supports open source. So this is a great audience to clarify: what is the White House’s position on open source, open weights? Can you talk a

Michael: little bit about that? Yeah. So Luther over here has turned into a little mini reporter. He’s got lots of people following his Twitter. But I will say, I think what the secretary said yesterday is the same policy that we had on page one of our AI action plan that was released last July. For those of you who aren’t necessarily tracking this, the US strategy for artificial intelligence was released in July of last year. It was something that I co-authored with David Sachs and Secretary Rubio. The number one thing, the first thing that we talk about in chapter one, is a commitment to open source. The idea is that if the US wants to lead in artificial intelligence, we have to have a vibrant closed and open source ecosystem. That’s the only way they can all work together. So to me, that’s number one.

But I think what this week really showed, and what excites me about the job that I’m doing, is we have to have these conversations. If DC is in a vacuum and isn’t hearing anything from the startup ecosystem, or even from the big tech ecosystem, or from financial services, or all these different industries, we can’t make the best decision. So to me, I find it inspiring and extraordinarily tactically, practically helpful for weeks like this to happen because it forces a lot of the community to come up and say, what do we as Americans believe in? And we as policymakers can internalize that and make sure that we’re saying the right policy going forward.

Luther: That’s the democratic process in action, I guess. So every founder here is building with AI. Where you sit in Washington, what do you think is the single biggest gap between how Washington sees AI and how this room sees it?

Michael: I think in Washington, when people think about AI, it is a sweeping technology that covers everything from the perception of middle America, their perception on things like data centers, to questions about AI in healthcare, to questions about job loss and how it’s going to impact the labor market. There’s also a conversation about how it’s going to impact new company growth and productivity improvements across our tech ecosystem. What typically is different in Washington is you can’t separate those conversations. It’s very hard to not think about the labor implications of the AI boom or not be worrying about how, generally, Americans don’t really love data centers. They poll horribly; people don’t want them in their backyard. But everyone in this room knows very well that we need as much compute as we possibly can spread across the country. So for us, we end up having to balance a lot of this stuff, which is our job.

But we need the input from the startup community to know at least that element of the conversation, to make sure that gets done right.

Luther: And governments are usually regulating industries that have settled. AI seems to be reinventing itself every six months. How do you write the rules for something that is moving so quickly?

Michael: Yeah. The answer to that really is you don’t want to set very firm red lines in the sand because they ultimately don’t work. The best example of that in the world right now is the EU AI Act. When we were in the first Trump administration, the EU went through a lot of fanfare and spent many years putting together this EU AI Act. This rule of essentially regulation through Europe was passed and finalized before ChatGPT was ever invented. So now, going forward, all of these large language models—everything that’s happened since November of 2021 when ChatGPT came out—have to abide by this rule that was written before LLMs were even a thing. That shows how challenging the situation is if you try to set the line too firm to begin with. I think our own administrators have had challenges with this.

The Biden administration set a specific hard cap compute threshold: if you do anything above a certain threshold, then you have to do a bunch of disclosures to the government. Over time, having these firm red line thresholds does not stand the test of time. A lot of what we do is to make sure that any type of action can move along with the frontier. What’s been proven very much so by the government is that once it sets a line, it’s very hard to reset it. So we are very cautious and try not to set these hard thresholds.

Luther: It seems like a lot of the policy conversation around AI has to do with safety and risk. What do you think is an AI risk that builders underwrite and that you think is probably overblown?

Michael: I think the risk of the day, at least today, there’s two main ones. I think the first one is obviously the cyber risk presented by the Methos moment. Ultimately, the analysis that the labs had to do when they were putting out Fable on what kind of guardrails are put in place to make sure that the more exquisite, powerful, quote unquote, dangerous capabilities of Methos were appropriately limited for the release. But again, the challenge with a lot of these cyber capability models is the same model that is able to do something nefarious is the same model that can be very valuable in hardening an existing system. So there are these inherent trade-offs that happen. I think the second risk that always comes up, that we think is coming over the horizon, is this biological risk question.

My sense is that at the moment, and it has been for many years, it’s a bit overblown. People were shouting about the bio problem back in ‘21, ‘22. It hasn’t been an issue for three years. But I think we definitely need to build the right infrastructure to run the right test and evaluation processes on models as they creep past the frontier.

Luther: Got it. A lot of tech policy conversations end up dominated by the five biggest tech companies. This is one of the reasons that Y Combinator, with a handful of other companies a couple of weeks ago, helped spin up a trade association called the Little Tech Association. Sometimes, I live in Washington DC, you do as well—obviously, we were actually on the flight this morning at eight o’clock together—it feels like kind of a Google, Apple, Facebook, Amazon Truman Show sometimes in Washington. Every position paper you read or speech you hear, you think, gosh, that has some big tech influence behind it. How does a two-person company even have a fighting chance if those large companies are writing the rules? How does the White House make sure that the kind of company that’s sitting in this room gets heard?

Well,

Michael: The most important thing that I do is talk to you as often as I possibly can. But the reality is there’s a great number of institutions that help support and stand up for little tech. Generally, government is quite cognizant of the influence of a lot of large players in every industry. This isn’t a problem or a situation that is only occurring in tech. It happens in everything from energy to healthcare to whatever it may be. What we try to do very hard is—there are lots of mechanisms where you can get input from a wide variety of folks. So the traditional request for proposals or request for information process, where you can get everyone to submit comments. For us, I think it’s actually working.

If you think about one of the major priorities that the president himself spoke about in the speech that he gave when our strategy was released in July of last year, it was this question about preemption of state laws around AI. The fundamental thesis there is that if you create or allow for the creation of a patchwork of regulations—meaning there’s one set of regulations for AI in California, another one in Maryland, another one in Texas—the big tech guys, they can deal with that. Google can hire an army of lawyers and they’ll figure it out and they’ll be fine. But for all of you out here, that’s just not going to work. The president stood up and said, no, we have to have one national standard for AI so we can make it easy for anyone who wants to build an AI company to know what the one set of rules is and build a company that way.

So I think that’s an example of us really taking that to heart.

Luther: Well, I will say, I commend the White House for continuing—and really it started with the first Trump term—the bipartisan antitrust project with respect to big tech. US v. Google was started under the first Trump administration. US v. Apple is being continued. Hopefully the reports that it might settle imminently are incorrect. And FTC versus Facebook, FTC versus Amazon. These are cases that the Trump DOJ and FTC have continued. I think it’s that, coupled with the president’s own usage of the phrase “little tech” and championing little tech companies. Probably when we met years ago, I said we just have to make sure that little tech has a seat at the table. So as you go back to Washington, making sure that we’re doing everything we can to make sure that little tech has a seat at the table.

Michael: It’s important to me. I spent most of my 20s here in San Francisco working at a venture firm. I understand how challenging it is to build these companies. What makes the US so special is that there is no place in the world that is better to do a startup than in America. It is easier here and the opportunities are just unbelievable. As a public servant, what I think about every day is how do we protect that ecosystem? How do we make it even easier? How do we create all the opportunities for all of you to create great companies and succeed? Everyone in the world is clamoring to come to America to build companies. There’s something very special about here that we must preserve.

Luther: Is there a version of AI regulation that protects consumers, but doesn’t hand the incumbents a moat? And what does that look like concretely?

Michael: I think back to what I was saying with this one national framework. I think it’s all about having regulatory clarity and ease for all sizes of companies. If we can work with Congress to do something like that, I think that would be the biggest boon for startups.

Luther: The United States’ advantage has always been that anybody can start something. To your point, we are unique in that respect. This is the greatest place in the world to build a company. What would you tell a founder here who is worrying about compliance costs and that locking them out before they even start?

Michael: I would tell them that there’s probably no administration in history more committed to reducing regulations than the current one. Our Office of Management and Budget, which runs our regulatory process—the guy who’s running it is Russ Vought, and his life’s mission has been to eliminate as many regulations as possible. That is what we think about every day. From a tech standpoint, when we talk about regulations, the biggest question to me is how do we remove barriers to innovation? I talked a little bit about this. To me, there are two ways to think about the world of regulations: they’re about technologies. A lot of people talk about this in Washington. There are technologies that are either born free or born in captivity. For each of those categories of technology, you have a different set of regulations to look at.

Born free technologies are ones where there aren’t regulations on the books—things like the internet when it just started. Those are the types of technologies you have to preserve. You have to be very thoughtful about whether or not you’re going to introduce new regulations into that domain because people can build anything and thrive in those areas. So those born free technologies you want to preserve. Then the born in captivity technologies are technologies where you’re building something, but you can’t commercialize it or take it to market unless you get some sort of government approval. Think about commercial drone operations. You could go build an amazing drone in your backyard. You could build the most amazing software to connect a vendor to a customer and set it all up. But to actually close that transaction legally and have the drone fly, you can’t do that unless you get a waiver from the FAA.

Those are the types of technologies that we relentlessly think about—how to remove those regulatory barriers or make it much easier to do so. I think earlier, some of you may have heard from the founder of Boom Supersonic. I’ve been obsessed with supersonic flight for years. I think it’s the most obvious, in-your-face example of technological stagnation. We had the Concorde flying years ago. We’re flying slower than we were back then today. Absolute tragedy. In that situation, he can’t get his supersonic plane to fly unless the rules are set such that there is a noise limit instead of a speed limit over the United States, for example. In those born in captivity technologies, that’s what we relentlessly try to figure out—how do you remove those barriers and make it easier for these technologies to work?

Luther: I want to go back to a question that I probably forgot to ask at the beginning, which is about your day-in, day-out role. You’re not only the director of the Office of Science and Technology Policy—and maybe you can talk a little bit about this when you answer—but also a special advisor to the president. There’s probably not a typical day, but if you had to average the days across, what does a typical day look like? What time are you showing up to work? A lot of people don’t realize in the White House, the White House is a sprawling complex. There’s the Oval Office, obviously, but then there’s something called the EEOB, the Eisenhower Executive Office Building. How big is your team? Just help us visualize what it’s like working at the White House and what your job is actually like day to day.

And is the role of director of the OSTP always a special advisor to the president? I think that’s an extra, additional role you take on. So talk about that a little bit.

Michael: So I think maybe the most abstract way to think about it is, and I mentioned this a little bit earlier, the federal government is made up of all of these agencies. You have HHS, which does healthcare. You have Department of Defense, which does defense. You have Department of Energy that runs energy and national labs. For any type of policy that you do, you essentially have to get concurrence or have some sort of conversation among all of these different agencies. There’s only one building in the whole world that can get all of these agencies to come together and have that conversation and bring some resolution, and that’s the White House. Generally, there are four categories of policy that get sorted out in the White House. There’s national security, and there’s a council that runs that process. There’s domestic policy—healthcare and immigration type stuff—and there’s another council that runs that. There’s economic policy that does tax and other economic policy. And then there’s us, that does science and technology. So essentially there are four policy councils and four policy leads, and each of us runs policy processes on the topics at hand. In our portfolio, we obviously have AI that we talked about a lot, but we do things like quantum, civil nuclear energy, biotech, space. For each of those portfolios on my team, I have one or two people that help run that portfolio. I have a space team of about three people, and they coordinate space policy across the government. They bring NASA in, they bring the Department of Defense that has a bunch of satellites for national security purposes, and they all sit together and sort out the policy.

So I would say on a typical day, the general things that you do are, one, stakeholder meetings. So Luther comes and says, “Oh, hey guys, you got to look out for little tech.” And I listen to him, and then Google shows up. Don’t settle the

Luther: Apple case.

Michael: So there’s the stakeholder stuff. And the second category of work is just the blocking and tackling of doing policy. The president has said, “We have to make sure that commercial drone flight is happening. So let’s figure out how to do it. Let’s push FAA to change this rule,” that kind of stuff. Bring the agencies together and do that kind of work. So those are the two big buckets of stuff. And then the third is doing things like this, sharing the president’s message and talking to people around the country, understanding what their challenges are and trying to see how we can be helpful. To your point on the director versus the assistant to the president, within the White House, there are folks called commissioned officers and they have three ranks. There’s an assistant to the president, which are the most senior advisors to the president.

There’s about 20 or so of those people. That’s a title that I have, but that’s one that the chief of staff has and others. Then there’s deputies and then there’s specials. So it’s this hierarchy where we all flow up to support the president. So

Luther: Practically, what does that mean? Can you just wander into the Oval Office whenever you want? How often are you interacting with the president? And how does it function? Because I think people don’t necessarily appreciate how many people work at the White

Michael: House. Yeah. So I won’t get too much in the weeds of the mechanics, but as I mentioned, there are these policy processes where you bring all the agencies together and start working on a problem. You can imagine that as the bottom of the pyramid. They try to sort out the problem. If they sort it out, then it’s great. Then policy’s over and it gets executed. If there is disagreement and someone’s like, “No, no, no, no.” Making this up—some guy at Department of War is like, “No, I don’t like this drone policy because I don’t want drones anywhere near military sites. It has to be way more stringent.” If they can’t agree, then it kicks up to the next level. Then you can imagine more senior people at all the agencies chat. If they can’t agree, then it gets up even higher.

And then if they can’t agree, then it ultimately goes up to the president for decisions. What you try to do is limit the decisions that get to the president because he has a limited amount of time and he should be focused on the things that are most important to the country and to the national priority. For us, when there are certain high-stakes AI or technology issues that the president needs to weigh in on, we bring them to him. We have a conversation and he weighs in and makes the ultimate decision.

Luther: Well, part of the reason I ask this, and I wanted to unpack that, I wanted people in this audience to appreciate how busy Michael is. Truly, we owe a debt of gratitude to just the amount of public service and the fact that we got some time with him today because sometime in managing all of that flurry of activity, you’ve just released a 150-page report. I want to talk about Science: A New Golden Age. This came out this week. Tell us about it.

Michael: Well, maybe we can start with just a little bit of history because I think that’s what inspired us to write this report. In 1945, FDR wrote a letter to his science advisor, the person who had my role, this guy called Vannevar Bush. In that letter, he essentially asked his science advisor, “What should we do? And how do we approach the science ecosystem after World War II?” If you can imagine, during World War II, a lot of the energy that the federal government put into the science and tech ecosystem was around getting the nation ready for the war. A lot of money was spent in launching the Manhattan Project and all this other stuff. And Vannevar Bush replied back to FDR with a famous report called Science: The Endless Frontier, where he essentially said the government has a very important role to play in funding science and technology in the national interest, and particularly in funding early-stage basic research.

He made the point that there is stuff that only the government is going to do because the private sector isn’t incentivized to do it. Essentially, that report laid out how we’ve been doing science as a country for the last 70 years. But the times have changed pretty dramatically. Back then, around 1950, almost 70% of all R&D was being funded by the federal government. So they kind of had a monopoly over where the money was going to go. Only about 30% or less was done by the private sector. Over time, that has inverted completely. The private sector plus philanthropy now do about 70% of R&D and the government only does about 30%. If you think of pure basic research, the kind of stuff that you see at universities, there’s almost parity between the federal government and the private sector now.

So the system has fundamentally changed and the actors within the system have changed dramatically. All of you exist. You are doing incredible work as startup founders. You have these organizations called FROs, which are focused research organizations that sit outside of universities and do their own research. And because that system has changed, we as an administration believe that we have to re-examine the way that science and technology is done in this country to get the most out of it. When I was confirmed by the Senate for my role, President Trump wrote me a letter, very similar to what FDR did, and asked me a couple of questions around how we can revitalize and re-energize the science ecosystem. We spent the last year writing a report back to him on what we can do. There are a couple of main themes that we can get into around that, but the core thesis about it that I think applies to you, one of the main pillars of it, is around this fundamental belief that artificial intelligence is going to transform the way that scientific discovery is done in this country.

If you are working on material science, if you are working on pharmaceuticals, if you are working on chemistry, you in two, three years, or even today, are doing your role as a scientist dramatically differently because of artificial intelligence. And we as a government that spends almost $200 billion a year on funding R&D need to be aware of that and prioritize that so we can make sure that our ecosystem is putting out the best possible research in the world.

Luther: So the last chapter of this report sketches this almost sci-fi picture. You’re talking about AI agents posting bounties for experiments, contracting robotic cloud labs, settling results on a ledger, and then the budget memo gets really concrete. Fast grants decided in under a month, prizes built for three to one private leverage, every major agency filing an action plan within 90 days. You write in this report that the government’s job is to shape the arena, not direct discovery. So for the thousands of people we have assembled here, what’s the piece of that vision you’re hoping a couple of 20-year-olds build because the government cannot or should not?

Michael: To me, I think the infrastructure that is going to support the scientific ecosystem in the United States is going to fundamentally change over the next few years. The idea that you can have autonomous cloud labs running experiments on a loop without human intervention, testing hypotheses, running the experiment, seeing the results, creating a new hypothesis, testing it and running it, and ultimately getting to a conclusion, that is in our sights. But for all of that to work, there are lots of things that still need to be done. We have to get robotics perfected so that you can create these labs. You have to create the right software ecosystem to be able to think through the next hypothesis and create the next hypothesis. So to me, I think there’s almost this infinite category of work that can be done to create this world of autonomous experimentation that all of our scientists across so many domains are going to be leveraging to make these discoveries.

Luther: You alluded to some of the things that I think you’re looking out toward into the future, but beyond AI, what technology do you think Washington will care enormously about in five years that it barely discusses today?

Michael: Well, we discuss it a lot, but I don’t think it gets as much airtime as it should. That would be quantum information science technology or quantum computing. Back in the first Trump administration, in the 2017, 2018 era, I was chief technology officer of the United States. In that role, I remember constantly running around the West Wing, trying to convince people that artificial intelligence was an important thing. Maybe once every couple of months, some journalist would be nice enough to write an article about AI and what the government was doing. This is

Luther: 2017, 2018.

Michael: 2017, 2018. And I give President Trump an incredible amount of credit. He stood up and said, “I’m going to sign the first executive order in the history of the United States prioritizing artificial intelligence in February of 2019.” That essentially set out the first national strategy in history on AI. Through that, we created the first kind of regulatory thinking around how our agencies should be contemplating AI-powered technologies. But times have really changed. I think the effort that we put in there to essentially double the amount of R&D that we’re putting into AI in our budgets then, and you fast forward three or four years and we have ChatGPT and everything’s exploded. Now, obviously what we did in the administration wasn’t necessarily the reason why ChatGPT happened or whatever, but I think we spent a lot of work trying to prioritize and prime the S&T ecosystem to be ready for the moment, and I think it was.

If we parallelize that to today, I think that same moment is happening with quantum. There are truly some basic fundamental scientific questions that still need to be answered on how quantum can be applied to things like computing and sensing. That work goes on. The president just signed an executive order on quantum information science, and we’re going to do a ton of work over the next few years to prioritize it. He set a pretty ambitious goal for the Department of Energy to build a scientifically relevant quantum computer by 2028. My sense is we’re going to wake up in three, four, five years and see the progress we’ve made.

Luther: We’ve talked a lot about the executive branch and its authority, executive orders being used to shape AI policy. What do you think Congress could be doing better on these issues? Because it seems like the mere fact that we read so often about executive orders in AI might imply that our legislative branch could be doing a better job.

Michael: Yeah. I think that the congressional stuff is a little bit tricky with AI. I think the challenges that we spoke about a little earlier are where you don’t necessarily want to set rules of the road too early that end up hurting the industry rather than supporting it. The thing about executive orders, which is a little secret, is when an administration changes, you can just revoke the executive order and start from scratch again. When something is a law, you can’t do that. It’s the law and that’s the law of the land. So we work very hard to try to find places where we can collaborate with Congress to set rules that are actually pro-innovation and help the country. And the White House put out a set of legislative proposals to Congress earlier this year that walked through a couple areas where we think a lot of benefit could happen if it was in statute.

I’ve said this a couple times, I’ll say it again, we would urge Congress to be able to pass some sort of law around preemption so we don’t have this crazy patchwork of all these different states doing all these different things on AI. I think another area that a lot of Americans want to see Congress step up on is how AI interacts with intellectual property and with name, image, and likeness of certain Americans. I think there’s a lot of creators out there that are worried about how AI is going to impact what they do. And I think all of us, we all have a craft of some kind. Some people are singers, some people are writers. All of you are unbelievable coders. All of you have skills and talents, and having some protections and knowing around that is important and something we’ve implied.

Luther: Yeah. What is the White House line on that? If you had a magic wand and you could solve the IP issue, how would it be described? Because I feel like I’ve spoken with people from the traditional media industry that are just filing lawsuits against AI companies left and right. And then on the other end of the spectrum, I’ve talked to pure maxis that say that you should not even be able to opt out of being crawled for the purposes of training. Could you talk a little bit about, maybe unpack that issue a little bit?

Michael: Yeah. I think the one area where I’ve been clear is the model outputs. If you create a model that is outputting Mickey Mouse, not cool. Can’t do that. That’s Walt Disney and they should be the only people to output that. So I think making that more clear in statute is very important. I think there’s also a lot of things that the industry can self-coordinate on, like finding interesting revenue sharing models for creators. There are a lot of creators out there that would love to license their own personal IP to companies that can do all sorts of stuff with it, whether they’re musicians or anything else.

Luther: I actually just read this morning, my old company, Yelp, did a deal with ChatGPT where I guess they’re outputting some of the reviews. So yeah, you’re starting to see a lot more of

Michael: That. Exactly. And look, it’s early, but I think over time that market is going to mature. And I think that’s maybe a category of places where you probably don’t want to legislate too fast. So you have to let the market sort itself out. But I do think it’s important because Americans generally do care.

Luther: Well, to close us out, I have one final question, which is that you were one of the youngest people ever in your role. To the 20 year olds in this room who care about technology and how it shapes the country, should some of them work in government someday? And what would they find there?

Michael: I would recommend to all of you, if there’s a moment in your career or a moment in your life where you can take a role in government, I guarantee you will never feel or have a moment where it’s more fulfilling and more rewarding. I think it can be a slog, it can be bureaucratic, it can be painful, but when the outcome actually happens and you deliver the result, there is no place where you can have a bigger impact on this country. And I think all of you are here. You’re here to build companies. You’re excited about building new things, about hiring more Americans, about building technologies and amazing things that will touch the lives of so many of our fellow citizens. And there’s some flavor of that in government and creating the environment that can allow startups to thrive, that can allow new companies to be built.

I believe there’s something very fulfilling and rewarding about that. And being able to do that in the service of your fellow Americans is something I encourage all of you to do. And if any of you want to work in the White House Science and Technology office, you just look us up because we’re always looking for good people.

Luther: Well, Director Kratsios, I just have to say as Y Combinator’s head of public policy based in Washington, I really appreciate the accessibility of your office and the administration and the thoughtfulness on these issues. And I also really appreciate you coming out and speaking to Y Combinator AI Startup School today. Let’s give it up for Director Kratsios. Thank you.

Michael: Thank you.

Susan Kare joined Apple as an art history PhD who barely knew anything about computers. She went on to design many of the icons, typefaces, and symbols that helped make the original Macintosh feel understandable and human, defining a visual language for personal computing that still influences software today.

At Startup School 2026, Susan shares the stories behind the Happy Mac, Command key, Chicago font, and more, along with the design lessons she learned from Steve Jobs, Paul Rand, and the original Mac team: make things meaningful and memorable, embrace constraints, iterate constantly, and use just enough detail to make an idea instantly clear.

Watch on YouTube

Timestamps

00:00 — Making Things Meaningful and Memorable
01:51 — How Susan Joined Apple
05:01 — Designing the Original Macintosh
06:35 — A Computer Anyone Could Use
08:26 — Creating Chicago and the Mac Typefaces
11:47 — MacPaint and the First Icons
14:45 — The Story Behind the Happy Mac
17:08 — Why Simple Icons Work Better
18:25 — The Icons That Didn’t Work
21:23 — Designing Symbols That Last
22:44 — How the Command Key Got Its Symbol
25:20 — What Ancient Symbols Can Teach Designers
30:18 — Designing After Apple
36:32 — Lessons From Steve Jobs, Paul Rand, and More

Transcript

Hello, I’m Susan Kare, and now for something completely different.

I’ve been an iconographer and designer. I’ve worked on a lot of tech projects, and I want to talk about a tech startup I worked for, even though the Macintosh group was part of Apple, but I think a lot of the experiences resonate with some of the topics that I’ve heard here today.

So I’ve been doing this for a while and love it. Here are a few things that I designed over the years.

It’s funny because this was really a north star for the Macintosh group, but when I reread it in the last couple of days, it reminded me of AI and so many things that are being developed now.

Paul Rand is a celebrated graphic designer, no longer with us. He did the UPS logo and IBM logo and so many images that have persisted. I was lucky to work with him. Something he told me was always focus on making things meaningful and memorable. I think the heart of that is to have a good idea and then the form will follow.

I was a total art major, didn’t know anything about computers, and was lucky enough to work at Apple on the Macintosh as the Macintosh artist. Before I went to Apple, I was welding a life-sized razorback hog for a museum in Arkansas. I thought I was living my dream, going out to my garage, welding all day. But in truth, it was a little bit lonely, and I was glad I had the experience, but it made me hungry for working with a team.

My high school friend, Andy Hertzfeld, was a system software programmer at Apple, and he knew I had worked on the yearbook and liked art. He said he needed some images to display on a new computer that was being worked on. He showed me the display, which didn’t have a case, and said, “Could I come in for an interview to work on some small symbols and some typefaces?” I said, “Sure.”

I thought it sounded great and really interesting and something I hadn’t done before. I had a little bit of typographical experience from working at the Franklin Institute Science Museum in Philadelphia. I used a machine like this to make labels for exhibits. I was pretty good at Letraset, rub-down type. I could do it really straight and get the kerning right.

I had a PhD in art history, so those were my credentials.

I went to the library in Palo Alto and took out some books about typography and some font sample books, and actually brought them to my interview under my arm so I would seem as if I knew what I was talking about.

Andy also suggested to me that it would be good if I could make some examples of essentially bitmap graphics, but using graph paper. He didn’t really specify what to make. So some things I made were like a pun with a boot and some pieces of paper. You can see on this slide there’s a little bit of an ABC, but I just tried to make some examples.

These are more of the examples. It’s sort of funny because some of these really random things slightly influenced what we ended up using in the software.

So I spoiled the surprise, but I got the job, and I don’t think anybody even asked me any questions about font design despite my prep.

In a funny twist of fate, as much as I had wanted to be an artist, now that notebook with those early icons that I took to my interview is in the permanent collection of MoMA. So definitely hang on to your stuff.

When I got to Apple, the first day, this screen was shown to me to say, “This is what it’s your job to improve.” Fonts and the round rects that are on the five-and-a-quarter-inch floppy drawing could become icons, but they were able with a cursor to click and drag those around.

So it already had a little, seemed kind of magical to me. We definitely changed Do It to Okay, because Do It was a little off-color and people read it as Dolt.

I wanted to make a new system font and make some icons.

It was told to me, very sincerely, that we were trying to make a computer that anyone could use. I felt good about that because I was in that group, even though I am happy to work on and have worked on many projects that weren’t for me, but I liked that about this project. We wanted it to be as understandable as possible so you wouldn’t necessarily need a manual, and that it should be friendly because there were so many people there in the Mac software group where I was, who were just passionate about computers and wanted to be evangelical about that.

There were a few constraints. Usually, I think you can be creative in any constraints. You can make some pretty fun art with beach trash while you’re walking around. You can be creative, but it’s good to understand what the constraints are and then be excited about that as opposed to being upset that you don’t have a thousand colors.

This is 16 by 16 black and white. I think the first images that I made using those constraints were things like this.

We thought maybe a lasso would be a good way to surround an irregular region and some other art tools.

It’s funny to me because I went to Paris for the first time fairly recently, and there’s a street artist known as Space Invader, and he does a lot of mosaic work. He has borrowed liberally from early Macintosh stuff, which made me really happy.

The first font I designed was Chicago. It’s nine pixels tall, cap height. I looked at the stuff that was on the screen, and it just seemed as if it was all jaggedy and it didn’t seem as if it would be that big a deal to make it look tidier by using horizontals and verticals and 45-degree angles. I still wince when I look at, especially, that lowercase x.

But the others, I could pretty much fit into the system. We were so lucky on the Macintosh to be able to do proportionally spaced fonts because I remembered seeing displays where the M was really squished and the I was really wide. I didn’t realize what a big deal this advancement was, but it seemed to make it look a lot better. We used Chicago, put it in the title bar, and experimented a lot until we came up with those lines. What we didn’t realize was that when we designed the calculator, we were designing the first iPod, which also used Chicago, which made me happy.

We shipped some other fonts with the Mac, including a Monospace font. I thought we should probably have a Times Roman kind of thing and a Helvetica kind of thing, so that’s where New York and Geneva came from. Then I made a font that I called Ransom because it was what kidnappers used to do by cutting letters out of the newspaper so they wouldn’t have to reveal their handwriting and get caught.

Like the other fonts, Andy and I gave them city names. Because we had gone to high school near Philadelphia, we gave them names of towns on the Paoli local through the suburbs into the city. Steve Jobs came by one afternoon—he usually came by at the end of the day and walked around the software group to see what was new—and he said, “Well, city names aren’t bad, but at least call them world-class cities.” So that’s how we ended up with New York and Geneva instead of Paoli and Wynwood and Rosemont, where our high school was.

Bill Atkinson was the programmer who wrote MacPaint, and that was my favorite program, of course. I was happy to collaborate on the icons and the patterns. He developed an early scanner, and that’s how we got this Geisha image from a woodcut that Steve Jobs owned.

We made a control panel that had animation for when you changed the settings, hoping to communicate what would happen and what your choices were. We tried not to use text so that it could be international without having to make a different version, though we could use sound and speed.

We didn’t have that many really great tools for art, but we forged ahead.

Andy wrote an icon editor, so I did not have to design on graph paper once I got to Apple. This is a picture of an ImageWriter print of what the screen looked like with the icon editor.

There were no tools; you could just toggle the bits and see a greatly enlarged image as well as what the icon looked like at 72 DPI. I thought this was just magical, even though it didn’t have 20 levels of undo and you couldn’t draw any shapes. You could iterate without an eraser.

It’s hard to overstate how great this was. It automatically generated the hex code for an icon, which I could then type in and see the image on the screen. It was a marvel. This icon isn’t crying—it was probably me counting pixels for some reason down the edge. You can see in the title bar, I tried a bunch of different types of things during the time we were experimenting.

Sometimes people came and sat, and I would do their portrait in 32 by 32. People seemed to enjoy that. There wasn’t really a way to get a photo in there at the time or even a drawing, so I just had to do it from life.

I still enjoy making those portraits. I think it’s kind of amazing that in a thousand dots, if you iterate a lot, you can get an image with some semblance of resemblance. You can see Pharrell Williams is at the top on the right and Ashton Kutcher under him. They did not sit for their portrait.

There are some people that aren’t super well-known, and John Maeda, who’s a design leader.

One of the first icons I was assigned was for when it took a while for the computer to boot when it got turned on. Everybody wanted an image on the screen, and it had to be 32 by 32 because it was only a 128K Macintosh.

Because the computer was sitting there grinding while it started up, we wanted something that showed that everything was okay. I thought a smile was good. I’m pretty sure it came from my memory of a button I got when I was about 14. I like smiling and happy things.

The Understanding Happy Mac is a play on the title of this excellent book by Scott McCloud, which is about comics but really has so many good insights about user interface too. It came out 10 years after the Mac originally did. I pulled two illustrations from that book by Scott McCloud that kind of explain some of the thinking behind our icons, which is that when a face in particular has a lot of detail, it looks like somebody else. But if you make it really simple, everyone can project themselves onto it. I love that idea.

He expressed a similar thing: the less detail you have, the more universal something is, which is why I think a simple drawing of a pencil can stand for writing in some ways better than a chrome pen with a reflection, which is very fancy, but it’s a very particular kind of pen that not everybody might write with. So my bias in icons is a salient detail or two, but don’t lard it with a lot of extra stuff. It’s similar to street signs, like the sign where there’s a silhouette of two kids holding hands at a school crossing. There’s not a technical reason that they couldn’t have plaid lunchboxes and shoelaces or be singing a song, but it would probably be more distracting and just take away from that instant recognition that you’re aiming for.

We made some mistakes too.

I was told that as an alternative to the Happy Mac, if in the extremely unlikely event something went wrong with the Mac, there should be an unhappy Macintosh.

So I thought maybe a sick Macintosh looks a little hungover. And again, I could be irreverent because no one was going to see this. At least that’s what I was told.

Same thing with this icon. They needed an image for total system failure, which of course, again, no one would ever see. So I thought maybe it would be funny to have a bomb, like a Bugs Bunny type of bomb. But unfortunately, people did see this.

One time I was working in the software group, which was a glass room—the fishbowl—and the receptionist from the front said a call had come through to Apple from a person who really needed to talk to someone in the software group, not me, about her Macintosh because the caller was worried that she was looking at a bomb and was her computer going to explode.

So I felt a little guilt.

But the moral of the story has lots of iteration.

We started with the handful of applications that we had. I did MacPaint first, I remember that. I liked the idea that since it was a process, it looked kind of active, and then it could be paired with a document that resembled it. Our system was kind of a verb and a noun. It seemed like this could hold up pretty well because we only had maybe half a dozen applications and didn’t really have the mindset that there would be thousands of applications.

Same with alerts. I tried to crop a person. It’s not a person with a little square head. The idea is it’s a crop, so you don’t know the gender or the age or the hairdo or really anything about this glimpse of a person.

I had only seen a sand timer as an egg timer.

It seemed like, “Hey, we’re in the 80s. Let’s update these things.” So we made a watch cursor instead of an hourglass.

This was the icon for print, and it’s kind of a trap. The ImageWriter did have paper with holes up the sides that would fit on the sprockets to attach when you turned the big knob on the side. But again, too much detail. It would’ve had a much longer lifespan if I had just stopped and made it simpler.

In general, I think it’s not good in icons to show pictures of a particular product design because the three-and-a-half-inch floppy for save, even though there are still a few of those kicking around, obviously didn’t age well. Better to use a metaphor. Just enough detail.

This is what our dropdown menus looked like. We had the Apple—we called it the Apple menu—and there was going to be an Apple key for these keyboard shortcuts. But Steve came in one day at the end of the day and said, “You cannot do this.” I think he called it an apple farm and said, “Our logo is precious and we have to respect it. So we just can’t have a bunch of apples.”

Then the idea was I was told that key was a command key or a feature key. So I began thinking about commanding, and it seemed kind of mean. The Ten Commandments seemed like a pun.

So back to the library, and I came across this image in a book that was called a feature. I thought, okay, it kind of looks like a four-leaf clover that’s sort of lucky. It kind of looks like a cloverleaf highway, which might be a way to get somewhere fast. We ended up—and it had the bonus of being really easy to draw in 16 by 16—so we used that, and it’s still on the keyboard. But I felt a little bit bad that it was abstract. Sometimes abstract things can be harder to remember than something that has a metaphor that reinforces the concept.

But I went to Sweden, and I was so excited to get off the plane in Gothenburg. There’s the feature key because it’s used there to indicate that you’re near sightseeing, a monument, or something else.

Someone from Sweden must have heard me comment on this and said, “Actually, that symbol that’s on the signs is taken from a 1200 AD castle called the Borgholm Castle. It’s a ruin. But when you see it from above, you see that it’s like a castle with four turrets. So that’s actually what that symbol represents.” I thought it was fun to find out even after the fact it did look like something after all.

When you study art history, there’s not much new under the sun. People have been making little symbols for a long time.

And no, I did not design this. Hieroglyphics had their day.

This is a cartoon kind of showing that hieroglyphics are back.

There are some really pretty nice bitmap fonts developed pretty long ago. This has only about a seven-pixel capital height. I thought I wish we had that person.

There are a lot of carvings with symbols and text and illustration that resemble some of the things that we were doing on the computer.

Again, another extremely nice bitmap font 200-plus years before we sat down to make our proportionally spaced fonts. Here’s a very nice example. This has about a character height of 10 pixels.

I realized that maybe I was destined or trained from a young age to want to make things on a grid because it used to be acceptable to get little kits so your kids could make the parents an ashtray. I loved making this type of thing.

I like to think that there were emojis in the 1984 Macintosh, that you could combine pictures with text before there was texting. There are a few things hidden in here. It obviously had a hieroglyphic antecedent, and I hid some hieroglyphic-type symbols in there. But I think the whole point of that project and the graphics was it isn’t really just about a grid of pixels.

It’s the metaphor and the idea and the meaning behind everything. This is just a super-quick run-through of some icon options that I did for Swatch.

They wanted an alarm, so of course I started with a clock and made it noisier, then made it look a little bit more literal, and then a little louder and simpler, maybe.

Or maybe it should look like, oh, it’s a travel alarm clock—that would be in your head if you saw this. And then I thought, way too self-referential. Why would you want a clock on a clock? So I was making other things that looked a little bit noisy as options, like the alpha alarm clock.

The point just being, this is so not an exact science. I always like to show either what a client asks for or what a programmer might have used as a placeholder because I’ve gotten so many good ideas that way, and then maybe refine them a little bit.

After I worked at Apple, I did a job for Microsoft on Windows 3.0 and color, even if it was just 16 colors, and some of them weren’t very good colors, but it was still so nice to be able to use red for alerts and to differentiate at a glance a little easier when you had color as another option.

I wanted to make something that didn’t look like a garish chessboard. There were a lot of illustrations like that. So this is all those 16 colors, but dithered so that they appear a little more subtle.

I also did something that, I guess, there’s always a way to get addicted to something on your screen. In the nineties, a lot of people played Solitaire. I had to take it off my computer so I didn’t play too much. Slate at the time thought that Solitaire made a dent.

I’m just going to show a few images that I made in the decades after Apple and before, some examples of good advice that I wanted to share with you. I’ve worked for a lot of clients, and we’re not going to talk about them all. I feel so grateful. Some things were fun, and some things were serious, and some things wanted self-consciously to seem like business.

I worked on a project for General Magic. I did the logo, and we had a different kind of desktop metaphor that was a little more literal—hallways with doors. I think the very worst thing we had was jars of text, because why? But the idea was that you could remember where things were by going and finding them in a logical way. I kind of laugh, wince—all these things are gone.

No Rolodexes, no phones that looked like that. But at the time, it—yeah, no file. I mean, there still are file cabinets, but at the time you could tap on those drawers and they would come out and you could put whatever you wanted in there. That was kind of a fun project that just didn’t—We could send postcards, but it didn’t quite anticipate email. I worked for Facebook on a project where you couldn’t just upload images, but you could buy images for a dollar, like a real dollar, and send them to people. I thought this was a wonderful project—having a gift shop and thinking about what you could draw that someone would want enough either to have or to share with someone that it was worth spending a dollar on.

We did this for not quite four years and had a new gift every day that launched at midnight on the East Coast. We could kind of tell by maybe a quarter after if it was going to be a successful bestseller by just how many sold in that first 15 minutes.

We had some limited editions and we had some—I thought maybe if you made something that cost thousands of dollars, like diamond earrings and a Rolex and did fancy things, that it would seem more worth a dollar because it was so expensive. But what I learned was that cute trumped everything. Teddy bears, anything heart-shaped. The Kiss Mark was the bestseller of all time. If my life depended on selling a drawing for a dollar, I now know I would draw a penguin because we had multiple limited editions of penguins, and they all sold out.

It was just interesting. We did some collabs with Britney Spears and other entertainers. Ultimately, Facebook ended this program because they didn’t want to compete with third parties, but it was good while it lasted.

Then I did some icons for Pinterest, where a terrific animator helped me with these. I thought just a little bit of motion so that it wouldn’t get really irritating over time. I made many icons there. This isn’t all for Pinterest, but some of them were.

I made a logo for astealthmill.com, which is a terrific company. Before they had their real logo, we did a trash panda because it dealt with trash in a similar way.

This is an illustration. The National, which is Amtrak’s magazine, invites artists—I think it’s a quarterly magazine—and they have artists interpret their route map. I thought it might be fun to go back and do pixelated icons for places where you could take the train.

I love doing logos. This is for Magic Puzzle, which really does make these great jigsaw puzzles that, after you finish, perform a magic trick—not levitating.

I was an artist doing studies for the logo, which is pretty close to this, for Pikmin Bloom game and Peridot, which is a game.

I love doing avatars. Avatars are so freeing because they can stand for anything. It kind of made me feel like gifts—you just want to have an array so someone can find something that speaks to them.

I just did these badges for a fairly new Ledger crypto wallet, and it has a little attachment opening in the front so that you can personalize it. And they really wanted to have something a little bit retro-looking.

This is a logo for a VC firm where the idea is to get out of the office and work in the mountains, work somewhere outdoors. Dave Morin, a friend, called and said, on a Friday, I think, and wanted to have an image and t-shirts and hats by Monday. So it was kind of a quick project, but it was fun to get a little bit of experience with something new.

Now I wanted to share some advice that I’ve been given by people that I met. It’s not a Google project, and I’m always looking to add to it. So I welcome any good advice that you want to send along.

By people that really influenced me. This is Paul Rand I mentioned earlier, just a terrific designer who started working, I think, for magazines when he was around 15.

He said that with all these new fonts, you don’t need that many. He was kind of brusque: you don’t need that many fonts. You just have to know how to use them well. This is some of his work.

I got to work with him at a company called NeXT, where Steve Jobs went after he had to leave Apple. I, of course, wanted to hire Paul Rand for the logo because he was my hero. Steve hadn’t really heard of him and thought we should have a contest, which I would never think is the best way to get good creative. But he said we could hire five people or firms and pay them each $15K, and then we would pick the best and continue to work with them. So I invited some people, and then I invited Paul Rand, and he said, “You will pay me $100,000. I will do one logo, and you will like it.” And that is actually what happened. We did like it, and we did pay him. It was such a great learning experience for everybody to work with him.

Among other advice he gave me, these are the fonts that he tended to use a lot.

I noticed in his work, he also tends to use the same colors. I kind of thought, okay, if PMS 354 Green is good enough for Paul Rand, it’s good enough for me. I still tend to look in his books and use some of the colors that he recommended for NeXT. He did, just as an offhand remark, say that.

When we were talking about logos, he really advocated trying hard to think of a way to do something to the name of the product, kind of the way he put NeXT in the Cube. He showed this as what not to do.

This is a couple AT&T logos ago, because he said, “If you can spend a ton of money to make some random symbol associated that doesn’t really mean anything much”—I mean, I guess it’s the world—”with your logo. You can do whatever you want, but most people don’t have unlimited money.”

So these are some logos that he did. You can kind of get the idea that Morningstar has a rising sun and IBM is pinstriped and businesslike. I love that UPS logo. He said when he was doing it, he showed it to his six-year-old daughter and said, “Katherine, what is this?” Reportedly she said, “It’s a present, daddy.” He thought that was such great justification that it was understandable, but really it had a shield and a package.

Sadly, they modernized it because I’m sure there were people sitting around a table who said, “Well, we’re not just about packages anymore,” but I keep hoping they’ll bring it back.

This is a futurist named Paul Saffo.

I just loved this quote that he mentioned one day. I kind of get this in a metaphorical way. I always think I can do this in an hour when really nothing takes an hour. So many projects I’ve worked on, you optimistically think you know exactly what you want to do, but still, allow extra time.

This is my dad, who was the director of the Monell Chemical Senses Center in Philadelphia, which studied taste and smell. I introduced my dad to Paul Rand, and he made that logo for Monell, which I felt pretty happy about, and they got along really well.

My dad always had good advice. It wasn’t the most cheerful advice, but it was realistic. He had to raise a lot of money for the Science Center, so he knew what he was talking about. I try to remember that because I get depressed when I hear no.

He also said this, which I think is a really realistic way to think about things and not be kidding yourself.

This is Daniel Nordh, who was born in Sweden, now lives in Portugal, and worked in London for the mayor. He’s an architect. He told me how they used to just sit around tables and have endless discussions about things.

This is how he said, “Make it visual.” I guess this is a metaphor too, but do the drawing. Really, show don’t tell, I think is what he meant.

This is a guy maybe well-known in some circles named Jean Pigozzi, who I met through Steve Jobs. He was kind of an Apple fan. He maybe invented the selfie, but had a lot of celebrity friends. His father was Italian and started the Simca Car Company so that he could spend his life doing whatever he wanted.

He collects African art. He said—and this amused me because it does seem like a long time ago and a lot of fun that we worked on the Macintosh.

He also said this, which I think I try to do. I think it’s good advice.

And this is Andy Hertzfeld on the left, Bill Atkinson, Bud Tribble, and Steve Jobs, and Alan Kay on the right, who’s in his 80s now, unbelievably accomplished computer scientist.

And this is Bud quoting Alan Kay as a kind of tenet about user interface and maybe not having everything at the same level and nesting things so that things can just appear—that ease of use seems possible. I always try and think about that.

Alan Kay said this to me, and I took great joy hearing that because he just said, yeah, who knew? Proportionally spaced fonts can actually look pretty good.

And this guy, pretty well known, he’s sitting in my cubicle at Apple, and he did say in the ‘80s, “Appreciate what you have right now.”

The first offsite I went to, he put up these three goals. Because of the second goal, a programmer named Steve Capps and I—Steve Capps sewed a black flag, and I painted a skull and crossbones on it and put a striped apple as the eye patch.

We went to work in the middle of the night and climbed up on the roof because obviously security was a lot more lax back then. We flew that flag and it was really just as a rejoinder to this, that we were the pirates.

I remember we used to show the Mac to lots of people. I still think of this now because obviously you say some people can figure out how to use this, but not everybody. There was great joy because they could feel smart or they wouldn’t feel dumb if you said it was easy and they still had trouble with it.

This is the only piece of really bad advice I got from Steve Jobs. He said, “If Apple stock was ever going to be worth anything, don’t you think I’d be holding onto mine?” I thought, “Well, I’m not going to buy my stock if he’s not buying his. He would know.”

He also said, “Susan, you can twiddle bits and never make more than $20,000. Or it’s better to be a creative director.” He was talking about NeXT, and I was a creative director and I got to work with Paul Rand. That was fantastic. But ultimately I was a bit twiddler at heart and I went back to it, and maybe not always bits.

I think this is debatable, but he took lots of visiting executives to see this movie. I liked it because it had a welder in it.

Jay Chiat started the ad agency that Apple used, Chiat\Day. It was not work-life balance at the time. Everybody I worked with in the software group had a sleeping bag in their cube.

I think this is really good to remember. I know a couple companies I’ve worked for, we decided that with 15 people, you could still have consensus hiring and everybody in a room and be on the same page. Then you start to get more people and there’s a plus and an upside and a downside.

Andy said this, he gave me this advice showing stuff to Steve. He’s like, “Don’t show him one thing because he’ll say he doesn’t like it. That maybe forces you to go try and do it again and be better.

But if you show a few things, then he can be involved and say that something is terrible, but still pick something.”

And this is advice from my mom, and I think it’s very good advice.

This is Evan Sharp and Ben Silbermann, who started Pinterest, and they had a lot of good ideas, but Evan used to say this.

And this is Dennis Hwang, who started working at Google when he was an undergrad at Stanford. He’s a terrific computer scientist and artist.

He told me this—that was the prevailing wisdom at Google. I would probably preach the same thing: don’t mess around with the logo and put it in a different color and put it on a crazy background until people know it so well that you can play with it.

But obviously Dennis made these. They did pretty well with this.

This is something that a friend’s dad told me.

This is not political. It’s just a fun picture I found with an accordion.

And you know this guy, he has a lot of truly good advice.

Including this, but I don’t think it means to be discouraged and quit trying. It just means, oh, maybe it’s time to go on to the next idea.

And thank you. But also really thank you to Y Combinator. I had an amazing day today and everything ran so smoothly and everyone was so gracious. It just seemed like I felt envious of everybody taking part in this event because it just seems so cool. Thank you.

Robots can already fold laundry, make espresso, clean kitchens, and assemble things. The harder problem is getting them to do those tasks reliably, for long periods of time, without a human babysitting them.

At Startup School 2026, Physical Intelligence cofounder Chelsea Finn explains what it takes to build general-purpose robots that work in the real world. She shares how reinforcement learning has doubled robot throughput, how their systems can run autonomously for hours, and why she believes robotics is entering its GPT era: moving from specialized models toward general-purpose systems that can work across tasks, robots, and environments.

Watch on YouTube

Timestamps

00:00 — The State of Physical Intelligence
01:23 — What It Takes to Make Robots Useful
05:11 — The Reliability Problem
07:43 — Reinforcement Learning for Robotics
09:35 — Learning From Failures
12:43 — Training Robots to Improve Themselves
14:21 — Can a Robot Work for 13 Hours Straight?
17:36 — Why Robots Need Memory
21:22 — Building a General-Purpose Robot
25:02 — From Fine-Tuning to Out-of-the-Box Models
27:35 — Training on All the Data
30:20 — One Model That Beats the Specialists
31:21 — Compositional Generalization
37:49 — The GPT Era of Robotics
39:49 — Q&A

Transcript

Hi everyone. Today I’m going to be talking about the state of the art of physical intelligence. In particular, two years ago, I founded a company called Physical Intelligence, and we’re really interested in how we can develop any robot or allow any robot to do any task in the real world. I spoke at this event last year, and at that event, I shared some of our progress at Physical Intelligence, where we could do really complicated tasks like unloading and folding laundry. I also talked about how, for the first time, we showed how robots can do useful tasks in environments and rooms they’ve never been in before. Since then, over the past year, we have gotten robots to do a lot of other really cool things. For example, we’ve gotten robots to be able to wash a greasy pan in the top right, peel a carrot in the video below that, make a grilled cheese sandwich in the video below that, slice zucchini, and so forth.

But what I’d really like to focus on today isn’t just cool videos of robots doing lots of different things, but what it actually takes to get robots to be useful in the real world. Specifically, how can we develop general-purpose robots that are useful in the real world? There are two aspects of this. The first is general purpose—how we can develop general-purpose models. The second is actually bringing those models into the real world so that they can have an impact and be useful to people. In the first part, I’ll talk about being useful in the real world. To actually bring a technology to the real world, I think we need to figure out—it’s helpful to look at what people have done in the past to bring AI into the real world. If we look at a timeline of major production launches that are leveraging technology like machine learning, we can see a timeline like this.

I think the first early examples of machine learning being used for real in the real world were for things like product recommendations and ad ranking. Then, five years later, we started to see not just machine learning being used, but deep learning being used for the same sorts of applications. This was a really exciting advance because deep learning is an algorithm that you can really apply out of the box to scenarios that involve complex inputs and outputs, and it makes it easier to translate to other applications. But from there, I think an even more exciting moment in time that we saw in terms of machine learning and AI in production was in 2022 with the launch of ChatGPT. This was the first time we saw a general-purpose model truly being used by many different people in the real world.

Within five days, ChatGPT had reached a million users. More recently, we’ve seen things like Claude Code also be incredibly useful, hopefully to many of us in the real world, and other coding agents. If we look at how AI has been used in the real world and look at this, I think there are a few different takeaways we could make. The first is that generalist models are increasingly being used for real-world problems. We’re actually seeing general-purpose, generalist AI models that can do many different things being used in the real world, and we see that transition from the left to the right. But I also think there’s a more nuanced observation we can make from looking at these applications. In particular, if we look at all of these different applications where machine learning has actually been useful in the real world and profitable and so forth, in all of these applications, the customer is making a decision based off of the recommendation of the AI model, more or less.

This means that if the customer is ultimately making the decision, if the system makes a mistake, that’s okay because usually the person can recognize that or decide what to do even despite that mistake. So even when these sorts of systems aren’t perfect, they’re still incredibly useful to different people, and there’s less pressure on them to be completely perfect. I think that physical AI and robotics is pretty different from this. If we think about physical AI that is actually operating in the physical world, they have to be directly making decisions that affect the physical world. This means they’re going to be far more useful when they’re operating fully autonomously. As a result, this requires us to develop physical AI systems that make far fewer mistakes than the machine learning systems that have been deployed thus far.

One really exciting thing to highlight that has happened recently is that a year ago, Waymo passed the quarter of a million weekly autonomous rides, suggesting that it is really possible to develop a machine learning-based system that can operate in a trustworthy and autonomous way directly in the physical world. I think that brings a lot of hope and optimism for actually doing the same with the rest of AI in the physical world. So if we want to develop general-purpose robots in the real world, I think we need to think about how we’re going to make them autonomous for long periods of time so that they’re actually useful, rather than something where a human is basing decisions on the predictions of the model. To think about long-term autonomy, I want to ground this in a specific example and say that we wanted a robot to make espresso.

And if we want it to be useful for us, we need it to make espresso reliably so that we don’t have to babysit the robot very frequently in order for it to help serve drinks. Even on its own, this task is really difficult. Actually operating the portafilter requires very precise and forceful control to insert it appropriately. It also needs to smoothly handle cups with liquid in them and not spill those cups. It also needs to have an accurate sense of timing, which often isn’t an issue in other areas of machine learning. Not only do we want to do this pretty challenging task, we want to do it with over 90% reliability. So how can we do this? The first step in machine learning is always to collect some dataset, train a model, and evaluate how good your model is.

Unfortunately, this rarely works reliably on the very first try. In practice, it’s better to iterate on the model that you’ve developed, where you try to collect more data or improve the quality of the labels in your dataset, or make the labels more detailed, collect more data of the edge cases—the scenarios where it’s not working well—adjust the balancing of the dataset, and so forth. While this generally improves the reliability of the model, people eventually get tired, and it’s hard to get really, really high reliability with a person manually tuning this. What would be even better is if the AI system itself can iterate on the scenario in which you want it to have higher reliability, where it automatically seeks out places where it needs more data, where it needs more supervision.

If we can do this for many more iterations because it’s automatic rather than a person doing it, then this might be the way to get really, really high—like 99 plus percent—reliability from physical AI systems. This is the approach that we’ll take. This looks a lot like a reinforcement learning algorithm that’s trying to attempt the task, learn from its failures, and get better and better on its own. So then how do we develop a scalable reinforcement learning recipe for robotics? In language models, we have algorithms like PPO and GRPO. These have scaled to large language models and have enabled really complex reasoning. But there’s a bit of a challenge in applying this to robotics, which is that these algorithms have been trained with millions of attempts or sometimes even tens of millions of attempts by scaling up the compute, because each attempt is simply running the language model in a data center just by using compute.

If we were to translate this very approximately to robotics—say we had maybe not millions or tens of millions, but just one million trajectories of a one-minute robot task (this is even shorter than the espresso task that I talked about)—this would correspond to 700 robot days to get high reliability for that task. Maybe this isn’t completely out of the question, but this would be quite challenging to do. That’s because the calculus is a little bit different. We’re not just running compute to optimize for a use case. We’re actually running the robot in the real world and using the hardware and attempting the task in the real world. So we’d like to have an algorithm that can iterate much more efficiently. There are actually ways that we can make these algorithms a lot more efficient. There are a couple of large inefficiencies in these reinforcement learning algorithms for language models.

The first is that they spend a lot of time on dead-end trajectories. Maybe this is okay if you’re just spending compute on it, but this would cost a lot in the physical world. We can look at a concrete example: say that we want a robot to construct cardboard boxes and stack them on the right. In this trajectory, the robot accidentally grabbed two boxes that are flush against each other. If we let it continue, it would just continue to try to fold that box rather than separate out the two boxes. Trying to fold two boxes together isn’t useful data that will teach the model how to get better at the task. That would be wasting a lot of time on the robot attempting to go down the wrong path for solving the problem. Instead of spending a lot of time trying to do that task, we’ll have a human intervene and show the robot what to do and how to recover from that situation.

What you can see here is a human teleoperating and intervening with the robot, showing it that to recover from this situation, it needs to essentially try to separate out the two boxes. It then puts its gripper in, sees if the robot could autonomously recover. It doesn’t autonomously recover, so the person intervenes again to help it get back on the right track so that we’re efficiently using the data on the robot.

This is the first thing that we can do: we can show the robot how to recover early or how to recover so that we’re not spending time on dead-end trajectories, or at the very least just terminate the episode early. The second thing that we can do is—PPO and GRPO and these kinds of algorithms—they make many attempts at a single prompt. Depending on the algorithm, they’re essentially trying to estimate for these different responses what is a good response and what’s a bad response. Even for an individual prompt, they’re going to roll out 10 or 50 times for that individual prompt. They’re doing this because they’re trying to estimate the value of these different attempts to then increase the likelihood of good things and decrease the likelihood of bad things.

But we can amortize this cost rather than trying to collect a lot of attempts for a single prompt. We can amortize this across different prompts and learn a much more general value estimate of what’s good and what’s bad, and use this to improve with our autonomous experience. What this looks like is we can train a general-purpose value function on lots of videos of the robot experience. This can learn things like, if it accidentally unfolds a shirt when it’s trying to fold, that’s bad, and that’s making negative progress—it’s shown in red. Or if it’s making forward progress, it recognizes that as well. The same value function can also estimate what’s good and bad for a completely different scenario, in this case for retrieving an item from a fridge. This sort of general-purpose value model that’s predicting the time to success can significantly reduce the number of attempts needed to learn how to improve from experience.

With these two improvements to a reinforcement learning system, we have a general improvement algorithm that trains a foundation model on diverse data, then collects experience from that with a human intervening as necessary to help prevent dead-end trajectories, and then trains a general-purpose estimate of what’s good and bad—the value function—and then uses that to improve the model. With this sort of improvement, we’re able to fine-tune a foundation model to higher degrees of performance. In the task of making a latte, in this case we’ll be making a latte in collaboration with a person where the robot is in charge of making the espresso and the person is in charge of steaming the milk. This is what the model looks like. The model is directly controlling the joints of the robot using the images from the robot’s cameras as input.

We can see that the model is able to do the pretty challenging task of inserting the portafilter, waiting the appropriate amount of time for the espresso to dispense, pouring the steamed milk into the cup. The last part of this task is actually the most challenging, where it needs to take a very full cup of latte and transfer that over to the coaster. Here’s the observation that the robot sees directly. You can see that the policy is super delicate and able to balance the cup appropriately and smoothly so that the latte doesn’t spill.

This gives you a sense of the difficulty of this task. Going back to this reliability question, we took this policy, and we ran it not just once, but we ran it for 13 hours straight. We wanted to evaluate: is this policy not only good at making a latte once, but can it do so reliably to the extent that it would be needed to be useful in the real world? Here’s a time-lapse of that process. We found that the robot was reliable enough to be useful for long stretches of time without making mistakes frequently. The same algorithm isn’t specific for making lattes, of course. We also applied this to other applications as well. Dandelion Chocolate Factory is a few blocks from our office, so we took a workflow that they typically have a person do, which is to construct these cardboard boxes, label them, and stack them.

We trained our robot to do exactly their real workflow and trained it with the reinforcement learning algorithm that I talked about to get a policy that is far more reliable at constructing, labeling, and stacking these boxes. We also applied this algorithm to folding clothes as well. In this case, we wanted to not just test how well the model could do one task in one environment, but to do it in many environments. These are clothing items that the robot has never seen before in a home it’s never seen before, and it’s able to do so. It acts autonomously for an extended period of time.

Videos don’t always show everything, so we also quantitatively measured the reliability of these models. We care both about the reliability as well as the speed—how many boxes can it build per hour? We’re going to measure throughput, which couples both success rate and speed. We find that over the phases of training from pre-training to an SFT-like stage to an RL post-training stage, we see a drastic increase in success rate and throughput. Specifically, around a 2X throughput just from the RL stage itself, showing how we can get much greater reliability from reinforcement learning. For the espresso task, if we look specifically at the success rate, we achieved over 90% success rate on making espresso. The takeaways for this part are that we can develop a scalable recipe for high reliability of complex robotic manipulation tasks.

We saw in this case a 2X higher throughput from using experience and interventions. Most importantly, we saw how we can achieve long-term autonomy in real workflows that people actually care about in the real world. This is what it’s going to take, I think, for robots to be useful in the real world. There’s also a lot more work and a lot more opportunities. We only ran a few iterations of improvement of this algorithm, and with more iterations, we should be able to see even greater improvement or even greater reliability. Even with this improvement, the robot still makes mistakes. It’s also still slower than people. There’s a ton of room for improvement for developing even more powerful recipes.

So we’ve seen long-term autonomy for these different workflows, but there’s actually one more ingredient that I’d like to talk about for enabling robots to be autonomous and useful for long periods of time. That ingredient is memory. You might be surprised to hear that most state-of-the-art foundation models for robotics have no memory or context. They’re just operating on the current sensor observations, the current camera readings, and predicting actions based off of that. You can do short motor skills and repetitive tasks without memory. The videos that I showed before didn’t have any context either. But if you want to do a long task that involves multiple different steps in sequence, then memory is critical for tracking progress of the steps that you’ve completed so far. If it’s critical for doing these kinds of long-horizon tasks, then why don’t these models have any context or memory?

There are a couple of technical reasons for this, and I’ll talk through one of them, which is that if you naively approach memory and try to feed in context like past video to a robot foundation model, say that you just pass in 10 seconds of video. Maybe this 10 seconds of video is sampled at 50 hertz, which is a common control frequency in robotics, and you feed in all four camera streams on the robot and use around 256 tokens per image. This corresponds to passing in half a million tokens into your model, which is a lot of tokens. Trying to do that in real time into your model right now is quite challenging. Even if you sub-sample to one frame per second, you’re still going to be passing in 10,000 tokens into your model, which at least right now is prohibitively expensive for these models.

And that’s still only 10 seconds of memory. I don’t have time to go into the technical details of exactly what we did here, but we also developed a solution for this context problem. Specifically, we developed a system that has memory at multiple timescales. The first is a short-term video memory that has about 10 seconds of video memory, but is computed much more efficiently than naively passing it into the model. Then, for longer memory, for memory that spans multiple minutes or multiple hours, we don’t necessarily need video of exactly what happened in that past history. Instead, we represent memory for those parts in text, where we summarize what happened in text space and then incorporate that much more compressed textual summary of what happened over the past 10 or 15 minutes into the model as well. With this memory at multiple different timescales, we’re able to enable robots to do tasks that can operate for 10 or 15 minutes at a time completely autonomously.

What’s different from the previous slide or what I showed previously is that this task isn’t repetitive. This is going to be a 10 to 15-minute task that involves cleaning a kitchen. The robot isn’t just repeatedly making espresso over and over again. What it involves is wiping the counter with a sponge, then drying the counter with a paper towel, throwing away the paper towel. Next, it’s going to put away the mustard into the fridge. Then it will put the dishes away into the cabinet, wash some of the dirty dishes in the sink, and so on. By incorporating memory, it’s able to do a task that requires keeping track of all of these different steps that are done to clean the kitchen and successfully operate for 10 to 15 minutes completely autonomously.

Great. So those were a couple ingredients for long-term autonomy. Now I’d like to build on that and actually take those ingredients and put them into a general-purpose model that can do everything that I showed before, but also can do that in a single model and can do some other things as well. To think about developing such a general-purpose model, I think it’s really helpful to contextualize where robotics is at within the timeline of other developments in generalist AI. If we think about how generalist AI systems have evolved over the past 15 years, I think the first major milestone was in 2012 when we saw that a deep learning system trained from scratch was the first time that it topped an external benchmark, and all of the previous methods for that benchmark were specifically designed for that application.

All of the previous methods—specifically, this was the ImageNet benchmark—were designed specifically for image classification. This was the first time that a deep learning-based system outperformed those more specialist systems. This is a much more general algorithm that wasn’t specifically designed for image recognition. Then just a couple years later, we found that we weren’t just training algorithms from scratch, but we were able to get models like pre-trained models that are useful for fine-tuning to downstream tasks. It became the norm to take a model that was pre-trained on ImageNet and then fine-tune it on a downstream task. We saw better performance from using that pre-trained model, like BERT or an ImageNet pre-trained model. From there, I think the next big phase and the next big transition in generalist AI models wasn’t using pre-trained models, but moving from a pre-training/fine-tuning regime to a regime where we’re just using generalist models out of the box.

And this was with models like the start of GPT-2. And of course, almost all the models that we interact with today worked out of the box without fine-tuning, at least most of the consumer models. There are actually other models that still use a lot of fine-tuning. One other milestone that I want to highlight was in 2021, where I think I saw the first signs of compositional generalization in these models. One specific instance of that was with DALL-E, and I’ll talk a little bit more about that in a later slide. This is how generalist AI has advanced over the past 15 years. Meanwhile, if we think about physical AI, even just three years ago in 2023, it was extremely common for people working on robotics to collect a bespoke dataset from scratch for an individual project and train from scratch on that dataset.

This is analogous to collecting ImageNet from scratch and training on ImageNet, or training on the dataset that you just collected from scratch. If you want to develop a general-purpose model, and you have to collect the dataset from scratch for every single project, you’re probably not going to make a lot of progress. Until just a few years ago, I think we were pretty far on the left of this timeline. Until more recently, we’ve been in the 2014 phase where we have some good pre-trained models, but we haven’t really been truly in the regime on the right. So how do we get to that regime on the right? Specifically, how do we develop a single general-purpose model that works out of the box and also shows compositional generalization?

So this is two goals. The first is an out-of-the-box model. This is analogous to going from BERT to GPT. Right now, the best robot performance—if you want to get your model to perform the best that it can on a given task—always requires fine-tuning. Some of the videos that I showed at the beginning were fine-tuned models to do things like unlocking a lock. Other work that we’ve done on measuring human-to-robot transfer also needed fine-tuning to get the best performance. All of the videos that I showed with RL post-training were also fine-tuning on an individual task to get the best performance on something like making espresso. But if you have to fine-tune a model, you aren’t getting a general-purpose model for the things that you want it to do because you have to fine-tune it for each individual thing.

Our first goal is to move towards a single general-purpose model that can do all of the things that you want it to do. The second goal that I mentioned is compositional generalization. This is inspired by the DALL-E result from 2021. I think that this was a really important and exciting milestone because of the compositional generalization that it achieved. Specifically, when you have compositional generalization—when you can bridge the concept of an avocado and a chair and show that you can combine those two—it means that the model has at least some kind of conceptual understanding of what an avocado is and what a chair is, to the point that it can combine them into something that exhibits both concepts at the same time. Second, it means that you have some degree of data efficiency, where your data doesn’t need to cover all of the possible combinations of concepts represented in your data.

You don’t need pictures of avocado chairs in your dataset in order to generate something like this. Or you don’t need combinations of other things that you might ask the model to do when it’s deployed. Even back in 2021, it wasn’t perfect, but these signs of compositional generalization were really exciting for demonstrating these two attributes of the model. So we have these two goals that we’d like to achieve: an out-of-the-box model and compositional generalization. The tried and tested recipe for developing this kind of model is to first take a sufficiently large and diverse dataset, and second, train a model with sufficient capacity. So what we’re going to do is try to use all of the data that we have available. This includes really diverse robot demonstration data, including really low-quality demonstration data.

It’s also going to include policy rollout data—attempts from the robot at doing the task. All of the training data that was used for reinforcement learning for the previous tasks will be included in the training recipe. We’re also going to include videos of humans, and we’re also going to include data from the web—all of the data that we have. To train a model with sufficient capacity, of course we’ll train a model that’s large enough, but to fit data that’s so heterogeneous, we also find it particularly important to prompt the model with all of the context that it needs in order to predict actions. We found that this idea was really the key unlock to using this kind of data and this degree of heterogeneity. Specifically, what this looks like is we’re going to train a foundation model that takes as input the memory that I mentioned before, an instruction of what to do, and it’s also going to take as input a sub-task instruction of what the next immediate thing it should do is.

It’ll also take as input metadata that indicates the quality of the data, the length of the episodes, and so forth. This metadata gives it a lot more information about how it should predict the next action. Optionally, we’ll also train the model with a sub-goal image as a prompt to the model, essentially saying, a few seconds from now, you should try to reach something that looks like this image. With this detailed prompting, we find that the model can really make use of much more heterogeneous data. I’ll show some comparisons later that really show how important it is. To actually deploy this model, we need to provide things like the sub-task construction and sub-goal images. With that, we can train a high-level policy that predicts the sub-task construction—what to do next, what is the next sub-task for the task of cleaning the kitchen.

We’ll additionally train a world model to generate images for what the robot should do next as sub-goal image conditioning. With this, we’ll train a single model with those attributes on all of the diverse data that we had available. Here are some examples of what that single model can do. All of these videos are from a single model, specifically a model that we called the π0.7 model. On the left, you can see it doing things like folding a collared shirt. On the top right, it’s doing a really precise assembly step where it needs to insert a screw and drill that screw into a robot arm. On the bottom right, the robot is replacing a trash bag in a trash can.

We had two goals at the start of this. The first was to move towards an out-of-the-box model. Even those videos showed that out of the box, the model’s able to do quite a bit, but really the key question here is how does this pre-trained model compare to the specialists that were trained specifically for coffee making, specifically for box building that I talked about previously? If we measure the throughput and the success rate of this single π0.7 model versus the fine-tuned π0.6 model, we see that across the board, the single pre-trained π0.7 model matches or outperforms the fine-tuned specialists that were developed with reinforcement learning post-training for those downstream tasks. We see that it’s able to match the performance of specialists. It also holds for SFT specialists, not just RL post-trained models as well, suggesting that we do indeed have a single model that can do a lot of different tasks with a really high degree of performance out of the box.

That was the first goal of out-of-the-box models. The second goal is compositional generalization. There are a few different ways to measure this, and there are many different ways you might try to combine concepts in robotics. The first test that we wanted to do was to see if a robot could interact with an appliance that’s quite rare, like an air fryer. This is an example. We wanted to see if it could open an air fryer, put a sweet potato in the air fryer, and close the air fryer. We picked this because we thought that the data set didn’t have any air fryers in it. We didn’t intentionally collect any training data with air fryers.

After we did some analysis on the data set, we found that our data set was so diverse that it did actually have three episodes with air fryers in it. We expect that they likely weren’t having an impact and that even if you didn’t include those exact three episodes, it likely would still work. What we found generally is that the robot was able to interact with an appliance that was hardly represented at all in the training dataset and combine the skill of interacting with it—opening it, closing it, and so forth—with this object that it hasn’t seen before. After instructing it, as Lucy did, we can train a high-level policy to do this task fully autonomously. You can see the robot doing that in this video. That’s the first form of compositional generalization. The second compositional generalization test that we wanted to look at is whether we could compositionally generalize between tasks and robot platforms.

We wanted to take a robot platform called the Byarm UR5E robot. It’s a very large industrial robot platform. We wanted to see if it could fold clothes despite the fact that we didn’t collect any folding data on this robot platform. Specifically, we had data of folding clothes, like folding a shirt, on the robot platform that’s pictured here on the left. Then we wanted to see, out of the box, without collecting any folding data on this very different robot platform on the right, could the robot successfully do the task? What we see in this video is that it did compositionally generalize in this manner. The first time we saw the robot do this, we were floored because there was no training data for this task. The robot here is quite different from the other robot, not just in size, but also in the lengths of the linkages of the robot, in the configuration of the joints of the robot, and so forth.

This is a 1X speed video, so it’s not the fastest thing. Obviously, if you haven’t seen any training data on something, you might not get it right the first time. It’s literally the robot’s first time folding a shirt. It might take a few attempts, but eventually it will get to the folded shirt. You can also see the generated sub-goal images on the top left. Those are the model’s attempts to generate images that will make progress on the folding task. Those are passed as input to the model. We see the folded shirt here. I think it’s going to make a couple small corrections at the end to try to make it a little bit smoother.

Cool. So the takeaway here is that both in terms of language-object interactions and in terms of task-robot interactions, we see strong signs of compositional generalization in this model. Quantitatively, we also see that as we get to these more advanced models like the PIO7 model, the performance of folding towels and folding shirts on this platform that it hasn’t seen before increases dramatically. It even approaches the performance of human tele-op, despite the fact that we didn’t have any robot-specific training data for folding clothes. For the last experiment that we did here, I think this is perhaps the most interesting experiment: we wanted to test how important are the two ingredients that I mentioned. How important is diverse data, and how important is this capacity or detailed prompting for the kinds of results that I showed?

If we remove the most diverse data from the model training, shown in the grayish color, we find that the performance on held-out tasks decreases dramatically. Whereas if we just take out a random 20% of the data that’s less diverse than the most diverse subset, the performance only decreases a little bit. So this suggests that having really diverse data plays an important role in enabling it to generalize to new tasks. We also tried to ablate the fact that we are prompting the model with metadata. For this experiment, we looked at with and without prompting with metadata. With prompting is shown in yellow and without prompting is shown in the gray color. With prompting, it helps significantly. But the most interesting thing is if you look at when you add—so this plot is showing as you add more and more data, and specifically as you add more and more low-quality data, what is the performance?

Without metadata prompting, when you add lower-quality data from 80% data to 100% data, the performance actually decreases, which is perhaps not too surprising because you’re adding low-quality data to your data mixture. Whereas with the metadata prompting, the performance actually increases when you add that low-quality data, suggesting that it’s able to get a lot more juice out of even low-quality data when you include this kind of prompting.

Cool. So the takeaways here are that we found that we’re able to train a single model to control the robots that matches or exceeds the performance of specialized post-trained models, kind of like going from a BERT-like pre-trained model to a model that really works out of the box like GPT. We also saw strong signs of compositional generalization in a DALL-E-like way—for example, in compositionally generalizing skills applied to appliances and skills applied to new robots in ways that weren’t seen in the training data. All the videos and experiments that I showed were just evaluating the model out of the box without any post-training. The paper and the technical report online have a lot more experiments and a lot more details. So we talked about long-term autonomy. We then showed how we can develop that in a single general-purpose model.

Where are we at now? The first thing that I’ll mention is if we go back to the timeline of generalist AI, I think that we now firmly have physical intelligence in the right side of this timeline. We’re more in a GPT- and DALL-E-like era for robotics and physical intelligence, which is really exciting. I think that we’ve gotten there in just a few years. Lastly, we also have these models that are actually deployed in real-world circumstances. The two videos on the top are actually two YC companies, Ultra and Weave, that have taken fine-pi models and post-trained them in deployment to do tasks like folding laundry and packaging in a warehouse. The video on the bottom left is the video that I showed previously. This kind of model works for a really diverse set of robot embodiments.

The ones on the top and the left are a more standard bimanual platform, but it also can be adapted to things like drones, quadcopters, surgical robots, and on the bottom right for things like tractors. This is truly showing how physical intelligence can make an impact, not just in demos and research and so forth, but actually in real-world deployment. I think that as we go, we’ll start to see more and more robots actually deployed for real in the physical world with all the advances that we’ve been seeing over the past few years. Awesome. The last thing that I’ll mention shamelessly is that we are hiring at Physical Intelligence. So if you’re excited about some of the stuff that I talked about, we encourage you to take a look at some of the open roles and apply.

And yeah, definitely have time for questions and happy to get all your thoughts. Thanks.

Q&A

How far away are we from a ChatGPT moment for robotics, and what will that look like?

I’ll start with the second part, which is that I’m not sure it will really look like the ChatGPT moment that we saw in language models. With something like ChatGPT, we saw it pass a million users in five days. I think that the distribution channel for physical models is going to be slower, unfortunately, because you actually need a physical robot there. For something like Waymo, the rollout has actually been incredible to see, but it still takes time to actually deploy things on physical devices. So I don’t know if we’ll have a single moment that has the distribution that ChatGPT had. At the same time, in terms of the capabilities of these models, I think that we are really starting to get to the point where these models are actually useful in the real world.

And I think that getting to the capabilities of ChatGPT is very much on the horizon in the next few years.

When should a small team switch from scaling per-site models to a generalist policy? What does that transition look like, and what signals tell you it’s time?

This is a good question. At the very least, I think that just starting with the generalist policy and then fine-tuning it, even right off the bat, can be really effective. Fortunately, there are really powerful generalist policies that are open source. The π0 and π0.5 models are open source, for example. We’ve seen a lot of people get a lot of use out of those models already. We’re also working with a lot of partners like the tractor company, Ultra, and Weave to take our most recent models and get even more juice out of them—more powerful models for their own applications.

So even right off the bat, I think you can use them. The only scenario in which I wouldn’t use them is if you’re in a really constrained environment. I’ve talked to some folks working on surgical robots that are in an operating room in the basement with no internet connection and a really bad GPU. Sometimes it’s just really hard to use a larger model, but you still can do local inference on a workstation with these models. So I think that, right away, just taking π0.5 or your favorite model and fine-tuning it is the way to go. I think we’ll see lots of these small companies, and there’s so much work to do in terms of actually getting these robots to work with this technology in the real world.

Given how fast robotics is moving in industry, what are the real advantages and drawbacks of doing a PhD today — especially for someone who wants to go into industry afterwards?

I was not planning to do a PhD. I was always planning to go straight to industry. My parents are engineers and worked in industry. I thought that the way to have impact was to go to a company and so forth. My dad even told me that he wouldn’t hire someone with a PhD, so I thought maybe I shouldn’t get a PhD if I wouldn’t be able to get a job. But he’s in a different field as well, in civil engineering.

At the same time, I think that a PhD is an incredible opportunity, and I love my PhD. Obviously, it depends a lot on the advisor, depends a lot on what you would be doing, and so forth. But I think a PhD is an incredible opportunity to first learn a lot about how to handle uncertainty, how to pick good problems to work on. In research, no one even gives you the problem to work on. You have to pick the problem. And you don’t know for the problem that you picked if it is achievable to make progress on that problem in a six-month time span, two-year time span, ten-year time span. So you learn about how to deal with that uncertainty.

That’s really useful. It’s also an opportunity to do amazing research and, in many cases, have a lot of freedom to work on the research that you find most exciting. I think that today it’s still an amazing opportunity to do work, to learn about uncertainty. Learning about uncertainty is really useful in startup environments, in being at the frontier of AI, because we don’t know now. No one knows what the best route is to make these models more and more powerful. At the same time, there are also a lot of incredible opportunities in industry. In terms of what goes into developing everything that I showed, it’s not just the research. There is a whole software stack that needs to run on the robot, needs to run reliably. There’s everything on the hardware side.

There’s also the machine learning infrastructure, the data infrastructure, and all that. You don’t need a PhD necessarily to do a lot of that engineering work. On the research side, there are often opportunities to get involved as well. A lot of research is engineering these days. So I think it kind of depends. It’s a very personal decision and depends on what you want.

Even today, I think I probably, retrospectively, would want to do a PhD just to learn about how to handle uncertainty and to do research, because I really love being at the frontier and thinking about challenging problems. But there are also a lot of really amazing opportunities in both paths.

Large language models learned from the internet, but robots don’t have an internet-scale dataset of physical experience. What’s the robotics equivalent, and how do we get it?

In robotics—well, maybe in language models to start off, the data on the web is language data. Not all of it’s high quality, but some of it is really informative and useful. It is data that reflects a lot of what you want a model to do. You want it to be able to predict text, to complete text, answer questions, and so forth.

And there’s a lot of questions being answered on the internet and a lot of text that’s being completed on the internet. In general, with machine learning, you want train to match test. You want the thing that you’re going to be training your model on to be reflective of the thing that you’re going to be asking it to do later on. I think the equivalent in robotics is data of robots operating in real-world circumstances. The way that we approach it at Physical Intelligence is to collect data, to collect robot experience of robots doing all sorts of tasks. You can collect this with teleoperation to get initial data of robots doing useful things. But in the long run, I think it will also contain a lot of autonomous experience of robots deployed attempting things. Just like how we see in language models, how now a lot of time is spent generating data, generating synthetic data by actually running the model and having it think through things.

I think a lot of the data in the future in robotics is going to be the robot attempting to do lots of tasks in lots of real-world circumstances. That’s kind of what it looks like. I also think that there are other possible sources of information that are really useful for model training, like videos of people doing things like YouTube, web data, and captioned images that tell you this is a kitchen that has a fridge on the right of the sink and so forth. All of that data can be really useful for developing a kind of frontier multimodal model that can control robots to do things, reason through how to do a long task, and also control the robot to do those tasks. I think that there’s no substitute for the robot experience itself. If you watch a human do something—like if I watch Roger Federer play tennis—it doesn’t mean I can play tennis as well as him, unfortunately.

Likewise, robots can’t watch a person doing something and then figure out how to do it themselves directly. They really need their experience on their own platform to learn effectively. I think that we will need large data sets. That doesn’t mean the human video isn’t useful. It’s useful to watch Roger Federer play tennis, but the actual experience on robot platforms will be a critical component of developing an analogous data set for robotics.

Is it possible that general-purpose robotics models get democratized via open source the way large language models did? Or will the cost of embodied data and hardware keep the best models concentrated in a few well-resourced labs?

I think this is a good question.

I do think the cost of embodied data and hardware could very much make this look different because it’s harder to get data even to distill a model, for example, just readily on the internet. I also think that we’ve seen pretty large data sets get open-sourced as well and pretty powerful models get open-sourced. It’s really hard to say exactly what will happen. I don’t know. The one thing that I will say is that with language models, even aside from democratization and really getting models that perform at the state of the art, even then companies that are focusing a lot on closed-source models are also doing a lot of open sourcing. There are Gemma, for example, and the GPT open source and so forth. I think these companies like to support open source because it helps build the ecosystem around the things that they’re building.

So I guess I’m optimistic that there will be a strong open source community regardless, but I don’t know if it will play out exactly the way that language models played out.

Does the model output raw motor commands directly, or a target hand position that a controller solves for? What makes that the right level to learn at?

All the models that I showed were outputting target joint positions. So, what is the angle of this joint? What is the angle of this joint, and so forth, that you want to hit? Then there’s a controller, like a PD controller, that is trying to hit that target position for those joints. The model is also trained to predict target gripper positions: where in 3D space should my gripper be? You could also use that as well and back out the joint positions. Another thing you could do is go directly to motor torques or to voltages or efforts.

There are pros and cons of different options. We have found controlling joints and controlling in the 3D space of the gripper to both work well.

There’s pros and cons. One thing that would be nice about going directly to the voltages is that you could get a more stiff kind of output or a less stiff output. Whereas the controller—if you have a fixed controller—then you’re not letting your model control that aspect. So there are different pros and cons. What we’re working on seems to work. It doesn’t seem to be a bottleneck. I often like to focus on the things that seem to be bottlenecks versus things that don’t seem to be bottlenecks.

Do robots need something like imagination — the ability to picture what should happen next — before they can become truly useful?

The pilot seven model that I showed has something like this, where it can imagine what a future image should look like and then try to accomplish that.

We found that leads to improvement. And we saw on the short folding example, we saw a quantitative bump from using that sort of imagination compared to not using it. At the same time, I think the model performs surprisingly well without that as well. We were thinking about writing an entire paper, an entire technical report just about that capability in that model. But the model without that was so good that we felt like we needed to have that play a bigger part of the story because that seemed like it was really delivering in terms of getting really strong results. So it seems like one design choice.

I think it’s hard to say if it’s going to be a critical component or not. The good news with these kinds of models is that if you develop a good data set, you can run experiments and continue to test things with the data set that you have quite effectively. I also think that being able to predict the future seems like a very relevant objective compared to predicting future actions. That should help in terms of learning from all the data that you have available to you. So yeah, hard to say if it’ll necessarily be a critical component or not. It seems like, empirically so far, it helps, although perhaps not as much as you might expect. And even without that imagination, the robot can do pretty incredible things. Okay. Next is right now it seems that robots are doing amazing tasks, but in a very slow manner.

What is needed to improve the speed? I’m really excited about improving the speed. We did see speed improvements from reinforcement learning. We also have another release called the RL token, where we showed even faster speed and actually faster speed than human teleop. I think one of the bottlenecks is that when you teleoperate robots to do things, which is the easiest way to teach a robot to do something, people are slow at teleoperating the robot. We have a couple projects in the pipeline that I think have really promising results in terms of getting fast policies. So I think more to come there. I think it’s either you need to figure out how to make the data faster or you need to figure out how to be faster than the data. We’ve seen evidence of being able to be a little bit faster than the data.

And in terms of the next steps, it’s either to go even further than that or make the data faster.

Cool. What’s the most surprising task you’ve seen a robot complete recently? What do you want to see it do next? So the most surprising thing was not really a task, but when we were working on π0.7, I personally trained one of the policies for some of the initial tests for assembling this pinwheel. When I was working on training it to construct the pinwheel, one thing that really surprised me was in all the data, we carefully controlled the strategy for how to assemble the pinwheel, where you take the precut piece of paper and take a little pin and insert the pin into a hole in the paper. In all of the data, we picked up the pin with the right hand and picked up the paper with the left hand and inserted it. The robot started doing that.

Then it made a mistake, and the paper ended up on the right side, and the pin ended up on the left side. What the robot did is it picked up the paper, and it picked up the pin with its left gripper. It put the pin with its left gripper and inserted it into the paper with its right. It had never seen data of inserting the pin with its left gripper. That wasn’t in the post-training data at all. It wasn’t even in pre-training either. The robot essentially had learned this sort of equivariance between its left hand and its right hand so that it could transfer behaviors from one hand to another, despite the fact that that was never in the data. That was a really cool moment. I don’t know if other people were as excited about it as I was when I shared it with some people, but it shows this emergent capability in these models that I hadn’t seen before.

In terms of what I’d love to see, I don’t know. I love seeing robots do anything. I think there’s still a long way to push in terms of reliability for robots being able to do tasks for really long periods of time. I don’t necessarily think that much about individual tasks, but more so about capabilities and how to get the next capability from these models. So yeah, anything. A robot doing anything always gets me excited, even if it’s something that hasn’t been done before. One thing that we’ve been doing recently is having robots use knives to slice vegetables. I think there’s a lot that you can do there once you can use knives safely, which is one thing that we’ve done recently.

How can someone break into robotics from a software engineering background?

Great. So I think that first, there’s a lot of software engineering in robotics. I think you could try joining a robotics company as a software engineer. Another thing I would mention—and I’ve actually seen someone take this path—is someone who now works at Physical Intelligence. Her name is Jenny. She worked in algorithmic trading for a while, then she worked at Harvey doing legal work. She was really excited about robots, so she bought a cheap robot and in her bedroom played around with it, tried fine-tuning an open-source model, and tried to get it to do something. She shared what she had done and sent me a cold email saying, “Hey, I’m interested in working in your lab.” Her profile was promising, and she actually got out there and tried it. She was really excited about that.

Now she works at Physical Intelligence. I think just getting your feet wet, trying things out, and learning from that experience—and then using that experience to share with people, have it on your resume, and so forth—is a great way to do so. Fortunately, there’s a lot of open-source material out there that can allow you to get started on those kinds of things. Great. That was the last question. Thanks everyone for listening.

Last November, Peter Steinberger was annoyed that there was no good way to talk to his coding agents from his phone, so he built one himself. A few months later, OpenClaw exploded into one of the biggest open source AI projects in the world, with nearly 3,000 contributors and a peak of 4.7 million weekly downloads.

At Startup School 2026, Peter tells the story of what happened when OpenClaw took off, what he got wrong as it grew, and how he eventually stopped using the product he had built for himself.

He shares why the best products often start with something that annoys you, why focus matters more as building gets easier, and why, in his words, “fun is velocity.”

Watch on YouTube

Timestamps

01:16 — How OpenClaw Started
05:10 — Finding Product-Market Fit
07:01 — The Night OpenClaw Went Viral
09:50 — When the Project Exploded
11:05 — When the Attention Almost Broke Him
12:00 — Did You Sell Out?
14:17 — Your Name Can’t Be Forked
15:03 — What OpenClaw Got Wrong
20:40 — Hype Is Like the Weather
21:37 — When It Stopped Being Fun
25:30 — Fun Is Velocity
26:40 — What’s Next for OpenClaw
28:57 — Three Lessons From Building OpenClaw
30:08 — Q&A

Transcript

All right. Six months ago, I was the future. These days, the polls say I got mogged by an anime girl. I get questions like this almost every day. Usually, I ignore it. Or I give the media answer. Today, you get some real ones. It’s going to be five questions, 40 minutes. And I know what you all came for. You came for loops, graphs, making Codex go bruh. This is free on my Twitter. This will help you to survive the rollercoaster that might be coming for you. Yesterday, Boris told you to let the model cook. I’m the guy who found out what happened when tens of thousands of people let it cook at the same time. So let’s start with the question everyone asks first.

How is OpenClaw only eight months old? You know, it might be eight months in human time, but in AI times, it’s more like four years. And my source of inspiration is usually being annoyed. So on a rainy day in November, I was juggling some agents, but I was also hungry. So I wanted to make sure that my tokens are put to good use while I raid the kitchen. And there was still no good way to just send a prompt from my phone to my computer. So some agent could check up how my agent’s actually doing.

Remember early 2025? And you guys, this is my first silent disco. It’s a very new experience. So give me some hands if you actually listen to me. Yes. Amazing. Amazing. Early 2025, oh my God, we are talking the old Opus 3. Gemini 2.5. OpenAI o3, which was the most impressive one, but also really slow and expensive at times. And I got a dopamine hit when my agent did something right. I’m sure you remember this time. And these days, if they get something wrong, I usually question myself. Did I design the loop wrong? Did I not give my agent everything they need to verify their work? Do I have an error in my thinking?

Am I asking for impossible things? So I came back from the kitchen and my coding agent stopped because of something silly. And I was annoyed. So I spun up a new terminal session. I rambled my idea in and I let the model cook. It built me a WhatsApp relay. And an hour later, I could send messages from my Mac to WhatsApp and back. And that in itself felt magical. But really it shouldn’t have. It’s like we all did this for months already, right? We opened the terminal and you’d type something in and you get a reply. But the magic is how it felt.

It wasn’t a terminal. It wrote concise answers. It was proactive. Sometimes it would just check on me during the day. I made it so the complexity would melt away. You don’t have to think about which model, which context size, or when you start the new session. And I prompted the weights a little bit outside the default distribution to make it feel more like a friend. And I was using it. I had so many moments where I felt like this is the future. This is AGI. And you know what? Nobody cared. Back then I already had a good following on Twitter. And I know it’s called X now. I’ll always call it Twitter. People were not getting it. I would keep trying to make them understand how magical this felt to me.

But week after week I failed. And do you notice a pattern? It annoyed me. So I would create group chats with friends and I added them, WhatsApp Relay, and I would show them. I would let them talk to it. And every time I got a strong emotional reaction. Some people were amazed. Some people were scared or freaked out even. But each time there was a strong emotion. And the best part, there were quite a few people that really wanted it. And especially to my non-technical friends, I told them, no, this is not yet for you. And they got mad.

So if that’s not an indicator to have product market fit, I don’t know what is. So I spent another month tweaking the details, thinking, what could I do to explain the world? And then the audacity, someone sent me a pull request to my WhatsApp Relay to add Discord support. Like what parts of the name are you not getting? So I let the PR sit for a while and I was thinking and I was sinking. And then eventually I was like, ah, what the hell? And out of our relay became Claudius because I’m good with names. And there’s no more than one message channel. And so you understand how early this was. I didn’t even have compaction built in yet. So at some point it would just stop. And just in time for Discord, I added a very hacky version of compaction so Mario could make a good one in pie.

So it was around New Year’s Eve. And as you do, I went home early to hack on it some more. And then in the first week of January, just as the geek world collectively was learning about coding agents, I created a Discord, Room, Server, Guild, however we call it. And I put my claw in it. And I remember the first night vividly. People would be joining Discord and they were like, “Watch me build it in the open.” They would try to hack it. They were talking to it. They were getting smug replies and they see what they can do. And they finally got it. This was the moment. I sat up all night. I let people interact with it. I had this prompt in my agents.md that would instruct it, “Don’t do any dangerous tool calls unless the prompt comes from Peter.” Those were like six months ago where all the things we wrote in our HSMD felt more like suggestions.

So I watched it very carefully. I could always pull the plug. And then at 7:00 AM, finally, I was done. I said good night. I pressed control C, and I went to bed. But of course, I could build the software to be resilient. So it was a launch daemon. You know what happens if you press control C on a launch daemon? Yeah, it’ll be dead for five seconds and it’ll just start up again. So while I was walking into the bedroom, my agent happily started answering God in the world. And then I slept for 10 hours. When I woke up, I woke up to around 800 messages.

People tried to hack it. I pulled the plug. I freaked out. I read through everything and nothing actually happened. But this was the moment. This was the moment where it went viral. And you all have been here. You know what happened next. My inbox exploded. Reporters tried to call me in the middle of the night. Did you know about this feature that Apple built when you put it on do not disturb, but people call you a few times in a row? I think they think it’s an emergency. It would still let the call through. I didn’t know about it, but reporters did. My email inbox was more like a waterfall. Yeah, the Mac Mini sold out. I think they’re still sold out. I got more invites to podcasts in a month than I did in my 39 years before.

Anthropic sent an email demanding the name change and dropped the lobster. And the project molted a few times. Claudis became Claudebot. Then there was a very short time where we don’t talk about the name. And then it started on OpenClaw. Jensen called it the most successful open source project in the history of humanity. And meanwhile, my inbox was flooded with reporters, security people, and countless curious humans and also agents. The numbers still don’t feel real to me. In eight months, more than 18,000 different people opened an issue or a pull request. Over 111,000 in total. I did the math. Who am I lying to? My agent did the math. Almost 3,000 people have commits in the repo. And some people were mad at me because clearly they did it first and I stole the idea and they sent me links of something I’ve never seen.

Some people call me AI Jesus. For some I became the antichrist.

And then meanwhile, at some point I started collecting the obituaries. There’s a new one every few weeks. The most recent one is actually from yesterday. What did we learn here? Be careful what you wish for. I was not ready for all this attention. And it almost broke me. I was that close to just deleting the whole thing. I stopped answering my friends. I didn’t even want to look at my phone anymore because it was just a stream. And of course somebody leaked my phone number and also a lot of private details because I’m an enemy of humanity. And here I am just wanting to build something cool.

Question two: did you sell out? You know, this wasn’t my first ride. I spent my twenties and my thirties building a B2B software company. I wrote a PDF framework by hand, like an animal. I bootstrapped the company. I grew it to almost 80 people. I ignored the competition. It became the thing most enterprises would buy. And eventually, I passed things on to my co-founder. I sold my shares and I very badly burned out. Retirement. The idea of it sounds great. And I spent almost three years wandering around aimlessly, catching up on life and parties. I did all the things that I missed out on in life.

I had months where I didn’t even open my computer, just casually checking the internet with my phone like a normie. I always knew that if I gave myself enough time, the urge, the urge would come back. I always thought the urge would be code. I always loved programming, but it took me a year to understand that that’s not entirely correct. I love building. Programming was just a means to an end. And here I was, eight months after I found my spark again. And my inbox was full of VCs begging me to take their money. And I didn’t know if I wanted to. So when the big labs came knocking and suddenly I was on the phone with Mark, Sam, a few others, this seemed like a much more interesting path. It also felt unreal, right? Talk about imposter syndrome. Maybe that’s an important lesson for you.

Everything you can build can be forked or cloned, but your name cannot. So your personal brand is way more important than any single product that you ever will build. Start working on that before you need it. So yeah, I know how to play the game. I also know that doing this was the equivalent of selling my soul.md. If you know, you know. The decision was not easy, but if I learned anything during my time after the burnout, it’s this: it’s trusting your gut. And my gut told me that I like OpenAI the most. Question three: did Hermes win?

And the short answer I can give you is they beat us where it hurt. We’re still there. And both of those are my fault and my doing. In the months after the release, we got absolutely crushed by security reports. In some ways, we wrote a prototype of what many open source projects now experience. And even though most were super edge case-y, I felt the pressure. And then the press, the press said 20% of our skills are malicious. No, we actually wrote a paper up with this. We did the numbers and the numbers are more like 0.3%. We scanned all 67,000.

We shipped the paper. But a correction never travels as far as a scare. I felt this responsibility. The world discovered OpenClaw. And even though there was this big, scary disclaimer—actually much bigger than I could fit on the slides—when you install it, I knew many people wouldn’t read the docs. So I really focused on that. Hardening the code base, building layers and layers of security. I added sandboxing, allow lists, a vet protocol with permissions built in. We went even further for some. We were shelling out to Python for some file operations because there were some primitives that are simply lacking in TypeScript to ensure your agent stays in the workspace, it doesn’t follow symlinks, and that the configuration files are written atomically. Now, most of the users didn’t care shit about that. Sure, they liked the appearance of security.

But in all practical terms, they updated. I broke something they depended on. I made things slower and I made things more difficult to update. And another thing I have to admit, I got sloppy because now my time shifted between open source, the press, spending countless hours on the phone with lawyers to set up a 501©(3) American nonprofit. I worked on my O1. And OpenAI is its own world that is interesting and demanding.

I brought on help and we got such an amazing community of maintainers that are very much respected. And everyone added their own little feature. I felt like I was in a hard place. After all, these people work for free, right? So who am I to tell them what to do? And also my attention was all over. So we added a lot of features. Features are the fun part. A new feature is just a prompt away. The real cost comes after. Every feature we shipped, of course, with a configuration option because we didn’t want to break everyone’s setup.

At our highest, I had to count that. We ended up with around nine and a half thousand configuration options, if you count all the permutations. You can write all the tests you want. It is impossible to cover all of these and not break things from time to time. It is infinitely harder to evolve software that has users. Meanwhile, other companies, they were fueled by VC money. They pushed ahead. The anime girl company did it especially well. People started inserting themselves into pretty much any conversation on Twitter while we were buried in security grunt work and features. They had a simple story, an aggressive marketing campaign, and a one-liner to migrate people’s claws.

The main thing that really hurt the project was Anthropic. Not the name. That part was stressful, but I understood. And they were really nice about it. It was the fact that I optimized too much on their model. I built OpenClaw with Codex and GPT, but the harness for a long time really worked the best and was optimized for Opus. So when they pinged me with around 24 hours’ notice that they were going to disable a subscription for everyone, there was not really enough time to change course. Sure, we support open weight models. We did a lot of work on them, but they really weren’t that great yet. And the early OpenAI models simply lacked character.

So maybe write this one down. Your dependency’s business model is your business model. That’s all fixed now. Sol’s pretty awesome. Open weight models are actually good. I learned a lot about harness engineering, but in many ways, people moved on. You can see that in our download charts. We bottomed out at around 835,000 weekly downloads in May. And then after being declared dead in June, we peaked at 4.7 million, the highest ever. Both of those are true at the same time. Hype is like the weather. You might see it coming, but you can’t control it. In my case, it was a storm.

Question four: is it still fun? Somewhere around February, it stopped being fun. I started to feel like it was a responsibility. I woke up and the man who didn’t want to build another company found himself in a situation where he had two jobs. Or should I say a job and a calling? I was struggling. And worst of all, I stopped using my own product. Somewhere in that time, I stopped making a product I love, and I worked on making something for everyone. It became less of a thing that I use every day and more a thing that I saw and felt was work.

And I wanted to picture who everyone really is. One of them had a grocery agent. Another one tried to social engineer my bot. Between everyone adding features and all the organization work, I became the person that fixed the bugs, fixed the security issues, provided support, and built a foundation. And because all these people were giving the rumor mill—oh, OpenClaw’s owned by OpenAI—I didn’t want to take too much help from OpenAI. Yeah, they gave me token and boy did I use that. But I was also pulled into other projects. And there was a whole flood of people that I could just easily block who wanted to talk to me.

In hindsight, I could have done many things differently. I could have asked for more help. I could have moved responsibility off my plate. But I was so deep in everything that I didn’t take time to think things through strategically. Luckily, I met a bunch of amazing people, and little by little, things aligned. I figured out my visa, eventually formed a nonprofit. They got amazing companies as donors, and I found some really good people that believe in open source and started working with me. I also need to give Nvidia a special shout out because they were very early and they simply asked me what I needed. And then they sent people who took over much of their security work. And I think it was somewhere in May, around my birthday, where I had this feeling that things were starting to feel good again, where the joy of building for me was coming back.

And yeah, somewhere in the press. The press crowned an OpenClaw killer every other week. At some point, I think I counted 20 of them. There’s even literally a project called OpenClaw Killer. It’s an uninstaller, which is totally unnecessary because we have an uninstaller. But none of the killer stories ever picked up what this is actually about: open source. I told you my source of inspiration is being annoyed. These days, I get annoyed when I have to use software where I can’t just send a prompt to my agent to change it. That’s the fun part that’s coming back.

And it’s hard to compete with someone who’s just there having fun. Fun is velocity. The weeks I enjoyed building, the product got visibly better. The weeks I didn’t, we shipped configuration options. Question five: what’s next? Some people in the audience might be like, “Is this finally the part where he talks about graphs?” First of all, I’m super happy with where we are with the foundation. Our mission is to bring people closer to AI. And things are changing so fast. For many people, it feels scary. I’m proud of one thing that OpenClaw achieved, and that for many people, it moved AI from this thing that’s nebulous and scary into something that is fun and weird. Lobsters and all of that. And we’ll keep pushing there.

Keep building a great ecosystem of open source software with events that bring people together and with education. We have 10 people now on payroll. We’re hiring a few more roles, including a CEO. Second of all, I kind of made Claw a noun. You know, Karpathy dropped the Open. Satya says enterprise-grade Claw in Microsoft’s keynote. There are 33,000 Claw-named repositories. If we are in a simulation, we are certainly in one of the weirder ones that won’t get shut down. I dig this part of the future. Third, we still don’t have an agent that’s always on, always syncing. There’s still so much to do.

The landscape and the tech in AI are evolving faster than the software that you build around them. And that’s an opportunity for all of you. Our workflows are also evolving. The vision I had early on was that we shouldn’t think about session or compaction. The world is finally— the models, the tech are finally getting to a stage where this is becoming a reality. We’re entering a world where we finally move on from text-only interfaces to voice and multimodality. Just yesterday, we got a hack working so that your Claw can now FaceTime you. And this is what matters—why OpenClaw exists at all. Every lab will sell you an agent. OpenClaw is the alternative. Open source runs everywhere, works with any model. And if you run local models, your data never has to leave your device. Your agent, your machine, your life. That’s not even my thesis, that’s Gary’s.

We just shipped it first. So we are also finally building OpenClaw with OpenClaw again. But this time with a twist, where everyone sees each other’s session on a team server. And there’s a Claw that knows what everyone else is working on and can also take over orchestration of the work. And we are finally leaving, slowly, this weird blip in the future where people work in terminals and run around with their laptops open because the agent needs to keep working. If you only remember three things: number one, don’t stop having fun. Fun is the ultimate driver so you can get the best ideas. Number two, listen to your gut. And also fix the things that annoy you. It might just become the next big thing. And number three, stay focused.

Another podcast is not what will make you win. Live in the future, build what’s missing. And when they write your obituary, keep shipping, it confuses them. Now, these were five questions. I’m sure you have many more. And I think we have plenty of time for Q&A.

Q&A

So first it was agents, then loops, then graphs. How are you building these days?

It was always sessions, right? But in the beginning, you had to actually care that you would clean and you would make sure that your instructions are coherent. And these days, it’s more like my sessions are topics.

Clearing a session is sometimes even a disadvantage because there’s so much information in there that helps the agent. But the big thing, the big thing that shifted is I try to make the agent do more proactive work for me. So when I shift my attention to something, I don’t want to read issues. I want to see fully reviewed and tested PRs. Maybe I like the feature, maybe I don’t, but I don’t want to split my attention. At the same time at work, if you come to me and you tell me this feature idea, I’m going to get mad at you. It’s so easy that you just discuss the feature idea with an agent, you build it, you make screenshots, you let me play with it. That way, if it’s good, we can immediately iterate it. But most of the time, people will figure out why it’s not good and don’t even come to me.

What comes after graphs? And what’s next for OpenClaw?

I know sometimes I like to shitpost on a Sunday and then my Twitter explodes. But also it’s not a shitpost. So anytime you—what we as engineers did for the longest time is build automations to make our life easier. That’s been going on since our profession exists. So if you design—call it loop, call it graph, call it workflow—it’s all the same. If you design something that gets a trigger, gets an input, and does something for you, and maybe there’s a decision in the way, boom, there’s your graph. It’s not magical, even though I favorited some of those graph engineering posts because I’m curious what their opinion is that it would be. In my world, it’s just a better way of our automation story that we did for so long already.

In a world of build fast, ship fast, how do you make sure that what you build is still reliable and scalable?

That’s the part I messed up for a while because I was not focused. And the models were not really good at testing. I think that the models are really good now. We not just have sessions that remember, we have orchestration trained into models so they really understand and know to use sub-agents. We have computer use, we have browser use. All of that together is like your perfect Q&A environment. I did that yesterday where I spun up Codex, used 12 sub-agents, understood my project, broke it down into features. And then each sub-agent would stress test the feature or code review the feature and then inform the other session where to focus testing on. So we’re not yet at the point where you can automate everything.

You’ll still need to do some manual click-throughs so that you know how it feels. But for a lot of the typical bugs that users will encounter, you can prompt your way and you get very far.

What’s a decision you made purely for speed early that you still live with today?

I think I was really early in deciding that I don’t read all the code. I see code review more as risk management. Sometimes you touch a system that is scary. You want to read a little bit closer. And other times you build UI. Do I really care how the UI is built if it looks correct? No. So you glance over or you simply accept that it looks right. Part of it is just developing a bit of a feeling for how long something should take. So if I do a small tweak that should change how dragging works and it takes three hours, I know something’s wrong. I’ll look closely. But otherwise, part of code review is simply observing, looking at how big a change is, and trusting your gut.

AI tools make it easy to build a product in a weekend now, but building isn’t the hard part — getting people to use it is. How would you go from a working prototype to your first 10 real users today?

I think that was part of what I addressed in my talk. User number one should be you. And my users two to 20 were friends. So I’m sure you have some people that would actually test your stuff, but you need to be the first user. If you don’t get excited about what you’re building, it’ll probably not make sense.

In this day and age, eyeballs are the most expensive currency because building something is so fast now.

How do you balance solving issues that annoy you and making features you think people want?

That’s a hard one because oftentimes it goes together. I get annoyed if something’s not there as I want it. To be honest, I haven’t fully figured that part out yet. I feel I could just work for months on issues because there are always going to be weird edge cases in software, especially if you add more and more features. But then again, if I only do that, I’ll lose interest in working. So it needs to be a healthy mix.

If you could go back and change one thing about OpenClaw, what would you change?

I would be less stressed out about security researchers. They are really good at making you feel really bad. They would send a report. They would email me. They would call me. They would do everything they can possibly do to get my attention, but not actually to help the product. In most cases, it’s really just for them to get clout, for them to get a point, “Oh, we found something.” And most of them really sent reports that their agent produced without actually even testing it. I would take a stronger sense of explaining what are the parts that we guarantee and what are the parts that will not be fixed because that’s not our security boundary. But honestly, this was my first time I was exposed to this world.

So I just didn’t know how to handle that. And I lost a few months and got a few gray hairs to learn.

What’s the single biggest bottleneck in today’s agentic infrastructure — reliability, tooling, memory, evals?

I would say it’s managing compute, if that makes sense. If I run one test locally on my machine, TS Go will spin up 16 threads and will bottleneck my machine. If 10 sessions do that, two of them will probably time out and we’ll have to do it again. And there’s no really good system of managing all of that. Now, if I do web stuff, it’s easy to create a cloud session. If I do something that requires Mac OS, that’s already where 99% of the tools fail me. If it’s something that needs other stuff that’s on my computer, same. And we haven’t really built something yet where things could easily move from here to here without issues. At least I didn’t see good stuff working yet.

Or where I could drive a fleet in a reliable way. Right now I use too many systems. I screen share into some computers to distribute a load. I shouldn’t be doing that.

How do you keep an open source project opinionated and pointed in one direction rather than just merging the N+1 PR that adds a random feature? And how do you communicate that direction to the community? Have you ever said no to a popular PR because it pulled the project off course?

Yeah. Yeah. I would say I didn’t say no enough. These days when I do new open source, I write a vision.md file where I explain what it is now, where I see this to be. But of course it’s incorrect. It’s not perfect science.

And it’s something I need to adhere to better because it is always tempting to add this one feature that looks really cool. But what you rarely think about is when you merge this feature, it really means here’s this pile of code that the person probably doesn’t really understand, that I don’t fully understand, that I’ll take on responsibility. It’s not easy.

When do you expect to have claws that are perpetually running, that are proactive in their work?

Honestly, that’s not so much a tech problem. It’s more a token problem where we could do that today, but you wouldn’t get very far with your subscription. And not everyone is willing to spend so many tokens. It’s also, but a part that’s not easy is designing a system that doesn’t just burn empty tokens. Even though my early system of heartbeats was too static and not proactive enough.

And then it’s especially bad if you have a large session. And then one hour later you call a heartbeat checkup on everything. And that means you send 600,000 tokens back to the server after the QV cache cleared and you pay a stupid amount of money for a lot of not useful work. So there’s a lot of things that can be done to optimize that. It’s also really, really hard.

Can you tell us more about your own personal setup? What do you host your claws on? What model are you running? What harness do you use? Do you still read your code?

I use my MacBook, but I usually use Jump Desktop to screen share into my studio and then just use the computer there because that one’s always running. That one, I can run whatever I want fast. I will not drain my battery and I can close my laptop and things keep working. And I have a few other remote machines where sometimes we can see in. The part that’s really nice about it is because I do a lot of Mac software, agents love to take over my screen and click around. And if you give them their own machine, it will not bother you.

Otherwise, you’ll fight with the agent for the mouse cursor.

Do you still read your code? I think I answered that a little bit with the term risk management. And also if I do open source by myself, it’s a different risk management than if I do software at OpenAI where we do still read all of the code.

Peter, how would you approach your next startup idea?

I don’t know. Should I tell this to everyone? I feel like it gets a lot of copies. The most important thing is you need to build something that you want to use. Otherwise, it’s just not going to be good. Second of all, I hope you worked on your personal brand and on visibility, because in this day and age, there’s so much noise out there that your hardest problem is not the tech, it’s not the software, not even the people. The hardest problem now is getting eyeballs.

Maybe I would pick something again that’s in the category hard and boring, because that’s usually a category that is a little bit easier to actually find people that will appreciate when you solve something. If you pick something that is fun, even if it’s hard, you’re going to have a very tough time, especially in a time where people can just prompt things into existence.

What’s a product you want someone to build?

I feel it’s very easy to get a test box for Linux. It is unreasonably hard to get one for Mac that works really well. And all the stuff that I got for Windows is also quite annoying. I haven’t found a really good provider yet that does all of that fast and cheap. I’m not sure if this is the business you want to be in because dev tools are inherently hard, but that’s something I would love to have.

Thanks everyone.

This week’s Paper Club is all about robotics. Every year for the last decade, someone has promised that the era of robotics is just around the corner. But we’re still waiting.

So we gathered a bunch of the top researchers working in AI and robotics to present the latest findings on where we are and what comes next. We open with a discussion of the biggest roadblocks still in the way: the sim-to-real gap, action representation, the sensorimotor problem, and embodiment drift.

Then we cover giving robot policies memory, teaching models what’s worth reasoning about, dexterous tool use learned entirely in simulation, why the next great robotics companies will start with teleoperation, and how to run world action models without two GB200s per robot.

Watch on YouTube

Timestamps

0:00 – Francois Chaubard: Ten years of “next year, robotics is solved”
7:59 – Marcel Torne: MEM - Multi-Scale Embodied Memory for Vision Language Action Models
20:21 – Milan Ganai: Self-Supervised Bootstrapping of Action-Predictive Embodied Reasoning
33:42 – Tyler Ga Wei Lum: SimToolReal - An Object-Centric Policy for Zero-Shot Dexterous Tool Manipulation
51:21 – Niko West: Why the next great robotics companies will start with teleoperation
1:08:30 – Bill Jiao & Guanming Wang: World action models and what comes after VLAs

Transcript

Francois: Welcome to YC Paper Club. How are you guys doing today? How do you guys like this one? We’re going to change it every time now. Today it’s actually YC Robotics Club. This is the 10th year of “next year robotics will be solved” that I’ve encountered in my career. I remember when AlphaGo came out 10 years ago, everyone said next year, clearly we have the algorithm. All we need to do is scale it up. And then MuJoCo came, and then we had literally in 3,000 iterations where we can train a robot to walk. This is quite amazing. Clearly next year robotics is going to be solved. This time it’s different. We figured out UMI data collection. And so ALOHA was the big breakout. Everyone thought next year we’re going to have robotics. Now, look at this. We can water our plants.

We can fix our bike up. We can do my Keurig here, even shave me. We have the algorithm. All we need to do is scale it up. And then 2026 was promised. They promised me that this would be the year of the robots. I was very convinced. I read the diffusion policy paper. I even played around with it a little bit myself. I’m like, this is surely the year of robotics. We have multi-step reasoning. This is totally going to happen. We have VLAs, they’re amazing. You just need tele-ops data and then you’re good to go. And I would say honestly, we’re halfway through 2026 and you can pre-order 1X Neo. I can’t buy a Pi or Figure robot just yet. We’ve had some success in work cells, but Rosie the robot is still not here. And we have six months left. It’s only July.

So maybe it will be, maybe I’ll be wrong, but it’s definitely the year of the demos. I know that for certain. The reason why is because—raise your hand if you’ve ever done tele-ops data collection. Is it easy or hard? It’s remarkably hard, especially if you have this little gripper thing, that’s all you have. You have the wrist cameras and all that stuff. It’s extremely difficult. It’s very, very finicky. And if we’re relying on this type of data and we need to scale that up like crazy, then we’re kind of doomed. I think about it in these four—there’s probably more, but at least these four—walls that we have to scale and get over, and we really haven’t yet. The first one is physical real world modeling. If you take these video models and you deploy them to, let’s say, drive a car and you’re doing the world models paper by Jürgen Schmidhuber or the Danijar Hafner Dreamer V1, V2, V3, V4, and you do this game and you play Doom in the simulated game.

In the real world, it really doesn’t respect physics. Those models don’t respect physics all that well. If you’re driving a car in that simulated world and you drive into a grocery store or Whole Foods, it magically just turns into a highway and then you don’t crash. It doesn’t really respect the real world physics. That’s all called the sim-to-real gap. We really haven’t figured out how to solve the sim-to-real gap. Deformable objects are even worse—just determining the transition function from S_t to S_{t+1}. If you condition further on the action, then it really doesn’t work. You need a lot of data to support that action conditioning. If you’re trying to estimate the dynamics function, T of S_{t+1} conditioned upon both, you have to figure out some coarse representation.

Nico’s actually here—we worked in 2013 on feature pyramid networks for our little robotic policy, bot war simulation way back when. But still, that was to solve this giant Q matrix where we’d have some linear thing with the pyramids. Representation for your action space is actually a completely unsolved thing if you want to learn quickly. This is the most important one that I don’t think is talked about enough: the sensory-motor issue. We have these nerve endings that can do so much. We can detect the normal force. We can detect the tangent force. We can detect moisture, temperature, vibration. We can estimate the coefficient of friction. It’s everywhere, all over our bodies. These robots don’t have that. They have one little coin FT on each fingertip and that’s all you get in the best case.

Maybe you have a wrist camera here and that’s kind of the state of the art. If you talk to neuroscientists about this, it’s actually incredible how good we are at building world models without vision. If you’ve ever tried to find your charger in your backpack and you put your hand in your backpack and you’re feeling around, you can tell exactly what’s in your backpack just by feeling around. You don’t even need eyes. There’s no way we have robots that can do that now because we don’t have an epidermis. I think that is a really important thing. If you’ve ever tried to tie your hockey skates when it’s really, really cold out, you start to see the policy fail. You’re like, I can’t even untie my skates because my hands are too cold.

And the last one that really only robotics people will understand—people that have deployed real robotics for long periods of time—is this embodiment drift. In this state, if I take this action, this is how much force is actually going to be applied. The actuators get dust in them. They get corroded. If they’re near the ocean, they may have some corrosion, some rust, and they just don’t work as well. This is especially true in self-driving cars; these are very real issues. When I push the gas on my Toyota Prius, it’s variable how much I’m going to get, and that shifts over time. The amount of power you get out of a battery over time also shifts. So then you have to retrain your entire VLA because it’s not mapping anymore. The teleops data is almost stale and you have to recollect it.

These are very real challenges that we don’t have answers to—until tonight. We have some great speakers, some great talks tonight. We have Marcel, who is a PhD in Chelsea Finn’s lab, and he’s going to talk about some of the cool work that he did at Physical Intelligence. We have Milan Ganai, who’s a PhD student with Marco Pavone and Clark Barrett, currently working at Waymo. And then we have Tyler, who is doing his PhD with Jeannette Bohg and Karen Liu. And Nico, who’s one of my close friends from 2012 when I was doing my EE master’s, founded this cool company called Rerun. He’s going to talk about some of the practicalities of data and how you actually deploy these robotics. And then we have Bill and Guanming, who are founders of this really cool YC company called General Instinct. They’re going to be talking about world action models, real-time world action models, and previous research experience at DeepMind.

It’s a great lineup. Thank you very much. Please welcome some of our speakers here. Marcel, you want to come on.

Marcel: I’m Marcel. I’m a PhD at Stanford. Today I’m very excited to present to you some of the work that I did during my internship at Physical Intelligence. We call this system MAM, which is multi-scale embodied memory. I want to start with some of the policies that we trained when I was doing my internship there at Physical Intelligence. We’re trying to solve these robot Olympic tasks. As you can see, they are actually quite dexterous tasks. You can see the robots—this is all fully autonomous—you can see the robots unlocking locks, folding clothes that were inside out, making a peanut butter sandwich. It’s actually very impressive to me. They are super dexterous and all. But if you see, actually, the longest of these tasks is about two minutes long. Ideally, when I think about what I would want my robots to do, I would want them, for example, to be able to manufacture something, to be able to clean a full bedroom, which is going to involve making the bed, folding clothes—a super long task.

Or for example, cooking a full meal, including cleaning the kitchen and everything. When we think about what we need in order to solve these very long horizon tasks in robotics today, I can think of a few things, such as being able to keep track of task progress, being able to keep track of time, and also having very reliable dexterity—dexterity that can actually adapt in context in case the robot finds a new scenario or makes a mistake. It should be able to adapt to it. And probably a few more things. But my claim is that in order to obtain all of these insights, we actually need to add memory into our policies. Memory, for me, is a very necessary thing for solving these long horizon tasks. However, if we look at most policies like π0, Five, Groot, all of these policies actually don’t have any memory, which means that basically at every time step, the robot will obtain a new set of observations and has absolutely no context of what happened before.

Here I can show a couple of examples of what happens when you train these policies without any memory. On the left, you’re going to see a robot that is washing the dishes and has no context of how long it has been washing the dishes, so it just keeps washing forever. On the right, you have one where the robot is cooking a grilled cheese, but again, it has no context of how long it has been there and it becomes fully burned. Then you might ask, why are we not adding memory into the policies? One reason is that it is hard. I’m going to take a small detour to another paper that we wrote last year where we basically observed that there are two main problems. One is effectiveness: when we add memory into these policies, they actually perform a little bit worse because of distribution shifts and lack of data. The other is an efficiency problem, which basically means that when we increase the context for the robot policies, this actually becomes much more resource intensive.

Then you’re going to get much longer training time and it’s also going to take much longer to run inference. Having said this, what do we propose and what is our solution? We propose compression. We basically take this model where we’re going to decompose our robot policies into two parts. One is a high level policy that tells the low level policy what the next step should be. Then we have a VLA, a low level policy that is actually going to execute the robot actions. We’re going to decompose the memory into two different types. One is going to be short context, which is some dense frames that are needed for the actual dexterous manipulation and is going to be fed into the low level policy.

And then we’re going to have a long context memory. There’s going to be basically a compressed language representation of the last few minutes, and it’s going to go into the high level policy. I don’t want to go too much into details, but I’ll give an overview of how we add this short-term visual memory. Our idea here was to design a new encoder that is based on the VIT, but instead of just taking a single frame, we’re also going to add some attention temporal layers. We’re going to drop all of the tokens except the current image, which should have all of the information necessary there because of this temporal attention. Then you basically get a lot of compression. Some of the reasons why this architecture is actually quite good are because, first, you have an easy VIT initialization since only the temporal attention is new.

We actually get to compress this image sequence again—we reduce the number of tokens, and because of this, you get fast inference. Now I want to show you what tasks we can actually solve with this short-term dense memory. Here we have our main flagship task that we did when I was at Physical Intelligence, and it was making these grill sheets. It’s going to be able to do all of the dexterous parts, but also be able to wait for as long as needed in order for the grill sheets to not be burned. But we also can solve some other types of tasks, such as here, that maybe seem like they wouldn’t need memory, such as unloading groceries from a grocery bag. But here you actually only see the items inside with a wrist camera sometimes.

So you actually need to remember where the items are and how many items there are. Another example is cleaning a window, where again, you need memory in order to not stay there forever. Now I talked about how to add memory into the low-level policy. Next I will talk about how we add the longer-term memory into the high-level policy. This is the technique that we propose, which basically consists of the high-level policy predicting a recurrent memory—like a memory scratchpad, basically. It’s going to keep track of everything that has happened. Then whatever its prediction was, it’s going to be fed again into the high-level policy. In this way, it can keep explaining what has happened before and what it can remember also what happened. This is actually a much more compressed representation than images, since text uses way fewer tokens than images.

So this is great for training. It is also quite physically accurate because the policy is going to be able to modify its memory with whatever has happened. And it is also less prone to distribution shifts. Let me show you here, what can we actually solve with this long-term memory? Here we show a task that takes up to tens of minutes and it actually is going to prepare all of the items for preparing a recipe. Just for the sake of time, I’ll skip over it. Something nice is that you can actually see the memory string that is predicted in the green box. We also compare with a bunch of different baselines such as no memory, different types of memory. We also get to beat here the state of the art. Something that I’m especially excited about with regards to memory is that actually when we add memory into VLAs, we’re going to be able to get this property of in-context adaptation.

It’s actually something that is really lacking right now in VLAs and I think it can be super promising in the future. Let me show you what this corresponds to. Here we have some policies, no memory. They have no memory at all. You’re going to see that they keep making the same mistake over and over and they are incapable of reacting to the mistake they did. It’s just going to be stuck in a loop forever and never going to be able to adapt. Here it’s trying to open the fridge or picking this chopstick forever. But actually now when we add memory, we’re going to see that the robot policies are going to make a mistake the first time, right? Maybe they have some bad priors or something, but they are going to actually be able to see this mistake and react to it.

For the chopstick, it made the mistake, but then it’s going to go lower to pick it up. For opening the fridge similarly, it’s going to switch sides to correct its mistake. I think this is something that is very lacking now from the robot policies that I’m super excited about for the future with VLAs with memory. Having said this, this was a huge effort at Physical Intelligence with a bunch of collaborators I’m super thankful for. I just wanted to point out Karl, who was the co-first author here, but then Homer, Sergey, Chelsea, and Danny for all their help. Please let me know if you have any questions.

Audience: Thank you for the presentation. I was curious about the long-term memory that you were talking about. If it’s only represented in the textual space, how did you figure out the right information to actually give to the policy?

Marcel: Yeah, that’s an awesome question. So right here we train our high-level policies with SFT. We had to annotate all of our data, but that’s a very good point because basically we had to think beforehand what information we think is important here. We had to tell our annotators, okay, you need to keep track of all of these things because this is what is important. But I think that some of the follow-up works that I’m thinking about, and I think everyone should think about, is could you, for example, do reinforcement learning on this memory space in order to be able to know what is the right information to keep track of. But at least the first proof of concept was with SFT.

Audience: Exactly. I think that was going to be my suggestion too. Figuring out the right message to store, the memory, the right things to recall.

Audience: A follow-up question to that was how are you actually right now storing that information? It’s represented in textual space, but how is it actually used in inference time when you actually use the policy to take actions?

Marcel: So it’s a fairly short text. This can all be kept in RAM and then you just feed it as normal text tokens to the VLA.

Audience: So one question. When you extract your task into a high-level text description, how do you make sure that the text itself is generalized enough to handle different variants? When you make an omelet, there are different versions of omelet, right? And also how does this memory affect the number of episodes you need to train for a novel task?

Marcel: Great point. So here I don’t show the examples, but we actually give some quite detailed descriptions of the task. For example, for preparing the ingredients or for making a recipe and everything, you tell exactly where the items are, like what are the exact items for making a pizza, for example, and all these. So that is very detailed. Something good about this is that the high-level policy is a VLM trained with internet data. So it actually doesn’t need that much data in order to generalize well. And the good thing is that the VLA is completely separate and doesn’t need to—we don’t need to train it per task to be able to do things in the kitchen and all this. But if you make the task more complicated, the VLA is still only receiving a small text description of what it should do next.

So at least we don’t have to collect that much robot data with the complexity.

Audience: Really appreciate the talk. So your embedding for the memory is textual descriptions, but it also seems like you could have solved the problem with just adding, for example, for doing a grilled cheese, just adding time. And so it seems that training policy only based on textual descriptions limits the representation space for what that memory can describe and potentially constrains it. Have you thought about actually expanding the memory representation or looking at other approaches for that?

Marcel: I try to think about how humans even keep track of all their memory. And it’s definitely not in text space. But I think something that is quite hard and I feel we haven’t really managed to do it very well. Ideally we would have a latent embedding that would just keep track of all the memory. But just with text, you can actually put a very strong bias there and be able to supervise it, be able to debug it and everything, which just makes it right now the most practical way to do it. But yeah, I’m very excited to try to explore this further and can do some latent, for example, work there.

Francois: Right. Thank you, Marcel.

Marcel: Thank you.

Milan: I’m a PhD student at Stanford, and I’ve done research at AWS and Waymo. And talking about how can we move toward robots that teach themselves how to reason? You’re probably familiar with vision-language-action models, but just a quick primer. VLAs are a powerful class of generalized policies. You’ve probably seen them in demos for manipulation like RT-2 and Pi or even self-driving. Maybe you’ve been on a Waymo or Alpamayo, which is from NVIDIA. So how exactly are VLAs trained? You take a vision-language model. These are multimodal models trained with an internet scale of visual and textual priors. And then this can be like Gemini or Qwen and you continue training them on relatively scarce robotics data sets. This can be tele-op for manipulation or maybe self-driving. Someone has driven a car and recorded that. And then you end up with a VLA, which takes as input an image or some perception feature, maybe language instruction prompts, and learns to generate actions which can be executed.

So, steering commands or end effector position. Now there’s this recent trend of leveraging and doing embodied reasoning for better action prediction. The idea is similar to chain of thought in the LLM domain, where you go from question to answer by explicitly providing logical steps. Why are we interested in embodied reasoning in the form of chain of thought? The idea is that there’s not a lot of data in robotics—it’s data scarce. Any form of signal that you can use to augment your dataset is very valuable. You can start injecting different types of annotations, and that can help you improve action generation and related tasks. You get a richer training signal with reasoning, but also, because this is in text, as a human, you can go and read it. If you’re trying to decipher the reason why a robot made a particular decision, you can actually read through the chain of thought trace.

To this end, I’ll be talking about our recent work published at the Robotic Science and Systems Conference this year called Self-Supervised Bootstrapping of Action Predictive Embodied Reasoning. We’re really interested in this question of what should we be reasoning about. Specifically, what should particular embodiments and form factors reason about? What makes good embodied reasoning is a hard question, but I’ll decompose it into two problems. One is the grounding problem. We don’t have an oracle source of reasoning data saying, “Just train on this reasoning data and you’ll get good reasoning.” It’s not clear what we should be reasoning about. If there existed some traces on the internet, just like there were pre-training documents for text or captions for images, that doesn’t exist for robotics. Second is, where’s the oracle source of the model? You can’t just open a human’s brain and figure out how they made a decision from an image to the movements in their fingertips.

That’s why I like to show this image of a chicken and egg problem, which is: where’s the source of the model and the oracle source of the data? The second issue is associated with verbosity. There are different types of reasoning. You can be planning, for example: “Go to the pepper, pick up the pepper,” and so on. Maybe you would be reasoning in the form of perceptual traces. This can look like visible object lists—a list of bounding boxes of all the objects in your scene—or even gripper position, such as the position of the end effector or the position of your car on the road. But the question is, should we be planning at every step, or is that too verbose? Latency is a big problem in robotics. It’s not clear if we should be planning or analyzing every single object in the scene, or if that is distracting and could mislead us in action prediction.

And similarly, is gripper position reasoning action predictive or is it misleading? All of these questions can be summarized into this one research question: how does textual reasoning for specific form factors and embodiments look? That’s where our approach comes in. It’s called R&B Encore, which is short for refine and bootstrap embodiment-specific chain-of-thought reasoning. This is a self-improving pre-training cycle for embodied reasoning VLAs. The insight is that, because we are claiming that reasoning is this black box for robotics, we treat this as an unobserved latent variable for the observed context and action. By doing so, we can leverage a theoretical framework called variational inference.

How does this look? There are two high-level components. One is a reasoning proposer. You can think of this as an annotator model, which proposes, for a given context and demonstration, various types of proposed reasoning. It’s asking the question: is visible object and move reasoning a useful type of reasoning? Or should you be reasoning about plans and gripper position? Or maybe visible object and sub-task reasoning? What is the sort of reasoning, annotations, or good data that you should be producing before your actions?

The second component is a reasoning validator. The idea is that this is a scoring metric based on the theoretical ground of variational inference. There’s all this theory that we’ve proved in the paper, but to concisely summarize it, there are three main parts to the score. One is concision, ensuring that your reasoning trace is short and not too verbose. The second is non-triviality, which encourages generalization in the reasoning behavior. The third, and most important, is action predictiveness. This ensures whether that reasoning trace or annotation is grounded in that embodiment.

At the end of the day, you score all these reasoning traces, re-sample, and end up with a new dataset of synthetic but action-aligned and embodiment-aligned reasoning. You can analyze this reasoning data to understand which types of reasoning are good and which are not. More importantly, you can retrain your embodied reasoning VLA and have a better and more robust policy.

We tried our pre-training cycle on a bunch of embodiments. We looked into manipulation, so we pre-trained embodied reasoning manipulation VLAs. We found that move and gripper positioning type of reasoning is very useful, whereas perceptual reasoning is not very useful and can be pruned out. We improved success rate because we have this action-aligned form of reasoning. We also looked more into the question of why perceptual reasoning is not useful.

We find that there are a lot of distracting objects in many of these scenes. By pruning out using our pre-training cycle, we can actually look into what is a good way to improve your annotation data quality. Questions about improving and task saliency of your traces and the data that you use to collect and annotate are important. This not only improves success rate, but also the object criticality rate or task saliency rate. We also test this entire pre-training cycle for hardware manipulation relays, and we’re able to have improved out-of-distribution performance, particularly on novel target objects or even cluttered scenes. We also pre-train legged locomotion navigation models. We find that reasoning about structural affordances and movements is way more important than reasoning about terrains and counterfactuals. We also use our cycle for refining human annotations for self-driving.

There is a lot of garbage data that could be out there. The idea is that with our approach, you can remove a lot of the human annotations that are not very useful. We observe that meta action and visible objects and perceptual reasoning are useful, whereas our approach can prune out hallucinated experiences, thereby lowering the L2 path errors and performance metrics like collision rates. Takeaways: selective reasoning is way more important than exhaustive reasoning. Even if that reasoning is valid, it’s not necessarily useful. Second, self-supervised bootstrapping works. This is really important to address the chicken and egg problem of the Oracle source of model and reasoning data. Third, we show the approach generalizes across embodiments like manipulation, navigation, driving, as well as VLA sizes from one billion to 30 billion parameter models.

We are basically addressing this question: how should an embodied agent reason? We argue that embodied reasoning is not a fixed template that should be applied uniformly, but rather a resource that should be discovered, deployed, and budgeted carefully. We are very excited about this problem, about how we can deploy embodied intelligence. We’re very excited about problems like data quality, how we can recover from failures, how we adapt to novel scenes and specialize in them. If you’re interested in some of these questions, feel free to reach out. We’re excited for collaborations. We would like to help you on problems of reducing the friction of deploying embodied intelligence for everyday tasks. If you’re interested in reaching out to us, you can scan the QR code on the right and find more details about R&B Encore, including the website, models, code, and papers on the left.

Francois: How do you think about the conversation we had where a dog is figuring out all of this, but not in token space? How do you think about this without using tokens?

Milan: Okay. So I think there are all sorts of latent reasoning capabilities where the model can navigate in its continuous space of understanding, unhindered by the textual format. This requires good architecture and theory for developing this kind of continuous reasoning. There are ways of, if I’m understanding your question correctly, non-textual reasoning. I think some of these approaches can really help with that. The idea here is that we want to leverage particular priors that exist, especially with LLMs and BLMs where there’s huge amounts of data out there. We want to use those priors for data-scarce regimes like robotics.

Audience: I wanted to understand what’s the thesis behind using reasoning for autonomous vehicles because there’s already the streaming latency problem, which is even more exacerbated in the case of AV. In that case, is your argument just that it would help build better self-supervised data or is there something more there that can be leveraged for better

Milan: Performance?

Audience: Yeah,

Milan: Absolutely. Latency is a big question, which we actually address in this paper. Our main claim here is that reasoning can help introduce priors into the model. You can think of this almost like co-training data, where instead of just training on robotics demonstrations, you can co-train and use textual reasoning as good annotations to help it. We actually show that we have this approach called action forcing, where you can drop the reasoning during inference time. So you don’t have the inference latency problem, but at the same time, you can still leverage or extract the enhancements from the textual annotations and reasoning. You can get the best of both worlds.

Audience: And a follow up to that is, do you see drift in terms of state space? So you reason about something, the state has moved now. So the reasoning is no longer relevant or can damage future actions that the model might take. Do you see situations like that as well?

Milan: The reasoning happens assuming it’s happening in real time. It’s based on the current image and the current instruction. So the drift isn’t necessarily a problem that’s going to fundamentally appear here.

Audience: Thank you so much. I just had a minor point. When you were talking about pruning things that weren’t too useful for the model, you made a point on how counterfactuals weren’t too useful in terms of better reasoning, if I’m right. Could you maybe just explain a little bit more as to exactly where you were going with that?

Milan: Yeah. So the claims that are being made about this are focused on the particular benchmark that we were working on. It isn’t to say particular types of reasoning shouldn’t ever be done and should be removed, but it is to say that there are certain types of reasoning that don’t need to happen at every single moment. To give you an example, if there’s nothing novel or interesting happening in the scene, a lot of self-driving is just driving in a straight line and there’s nothing around you. So there’s no interesting counterfactuals that you might explore. But even plan reasoning, or as I had mentioned earlier, plan reasoning appears to be quite useful. It seems that it might be useful to plan ahead, but you don’t want to be planning at every single step because it’s quite redundant.

Francois: Thank you, Milan.

Milan: Thank you.

Tyler: Hi everyone. My name’s Tyler Lum and I’m excited to present our work SimToolReal. Let me start with what SimToolReal can do. Every clip here is at 1X speed. This is a single policy that is working zero shot, meaning it never saw any of these tools or tasks during training. We do not need to retrain for a brush or hammer or a new target behavior. Many tasks like the screwdriver spinning are very dextrous. They would really require a multi-fingered hand. They just wouldn’t be possible with a parallel jaw gripper. The policy is very fast and reactive. It runs at 60 hertz and simultaneously controls both the 22 degree of freedom hand and seven degree of freedom arm. I also want to highlight that the level of dexterity is very difficult to demonstrate through teleoperation here. With that preview, I want to give a little bit of context.

Teleoperation for dextrous hands has increasingly been used to collect demonstrations for imitation learning, but highly dextrous actions remain difficult to demonstrate reliably and at scale. In the video on the right, even this simple in-hand rotation task requires slow, deliberate control from the human because of the embodiment mismatch and limited force feedback, which make precise contact regulation very difficult. Rather than learning the policy from teleoperation, we train it entirely in simulation using sim-to-real reinforcement learning. Sim-to-real reinforcement learning uses GPU-accelerated simulation to run tens of thousands of robots in parallel and generate experience about a thousand times faster than real time. This allows us to scale data collection with compute rather than human effort and collect decades of interaction data in only a few days. The result is extreme dexterity because it is not just imitating demonstrations, but it’s optimizing for reward-maximizing behaviors.

These policies are then deployed in the real world, demonstrating impressive dexterous behaviors that would be very difficult to teleoperate. These videos are from Dextreme, which is one of the first works to demonstrate the effectiveness of this approach for dexterous manipulation. This task isn’t particularly useful looking, but it’s definitely an impressive demonstration of dexterity. Most prior works in this space learn a separate policy for each particular skill—one for grasping, one for reorientation, another for object spinning, and another for tool use. Each new behavior typically requires a round of new reward design, new task-specific engineering, and another round of training. We instead ask, can we train a single policy just once and have it perform all of the different tasks and skills? What we really want is a single policy that controls both the hand and arm through the full sequence.

It first grasps the brush, reorients it within the hand, and finally uses it to sweep the objects. We want this all from a single policy so we don’t need to do any manual switching between separate policies. Our key insight is that we can unify dexterous tool manipulation as goal reaching. The policy doesn’t need a task label such as sweeping or hammering. It only needs to move the object from its current pose to the desired pose. Thus, we train a goal-conditioned policy that can move arbitrary objects through a sequence of desired goal poses, visualized here in green. We find that this is a very general objective for a wide range of manipulation tasks. At train time, we procedurally generate primitive objects in simulation, sample random goals, and train a goal-conditioned policy with massively parallel RL in simulation to manipulate random objects to these random goals.

Of course, there are many details to get right here: system identification, domain randomization, and algorithm details to get exploration right. We’re going to skip all of that for now, but feel free to ask questions in the Q&A. At inference time, we need to specify the sequence of goal poses, which can come from any source. In this work, we choose to condition the policy on a human video demonstration. We use FoundationPose and SAM to extract the sequence of goal poses to track. The RL policy tracks these goals one by one in a 60 Hertz control loop. I want to highlight here that the human video is not providing robot actions and it’s not used to train or fine-tune the policy. It only specifies the desired object trajectory for the frozen policy to track. Concretely, the policy takes in proprioception, the current object pose, a bounding box of where it should be grasped, and the current goal pose.

It runs them through an LSTM policy and then outputs joint position targets for the full hand and arm. This policy, again, is not limited to just sweeping with brushes. This single policy works zero shot across novel tools and tasks never seen during training. What’s really nice about this is that a new task simply becomes a new sequence of goal poses rather than a new training run. Conceptually, the trajectory acts like a task prompt that we can provide at inference time for a frozen policy, allowing us to perform a new task on a new object in minutes instead of hours or days. We evaluate the same frozen policy across 12 unseen tools and target behaviors and achieve substantial task progress across every tool family, particularly those with long handles. Performance is weaker on heavier tools, which are easier to drop, and also for smaller objects.

But this is really because the pose tracker has a lot of problems when it gets very occluded. Next, we want to measure train and test correlation. Our goal is to see how well our training objective supports downstream test success. On the left, we show training objects consisting of primitive objects and random goals. On the right, we show our test objects with human demonstrated trajectories. We evaluate checkpoints throughout training. As the policy improves on the generic goal reaching task with primitive objects shown on the left, performance on unseen tools and human demonstrated trajectories on the right sharply rises. This validates that SimToolReal’s training objective with random objects and random goals is effective for generalizing to real world tools and tasks. Next, we compare SimToolReal against two really common baselines. Our method successfully grasps and reorients the tool into a functional pose to complete the task.

The fixed grasp baseline can grasp the object, but it must rotate it using only the arm, resulting in a table collision. This really highlights the importance of in-hand reorientation ability, as most prior approaches assume that just acquiring and maintaining a fixed grasp is sufficient, but it really isn’t for many cases. Lastly, kinematic retargeting: this is where we try to imitate the human video demonstration by transferring the human fingertip motion to the robot, but it doesn’t reason about contact forces, so it fails to even grasp the object. Next, we analyze the failure modes of SimToolReal and find that pose tracking failures dominate. Next, object dropped after being grasped. Lastly, failed grasp, but it really tries to chase it down. The policy demonstrates really strong recovery behaviors. Here, when the robot drops a hammer, it immediately re-grasps it and completes the task.

Lastly, please check out our website. All of our code assets and policy weights are open sourced. We even have an interactive demo that runs right in your browser and works on your phone. It’s not running on a separate server—it’s running on your phone. It will drain your battery, so don’t leave it running for a long time, but it’s pretty fun. That was a quick overview of SimToolReal. I want to spend the last couple of minutes talking about a follow-up work called Play2Perfect. Many real tasks like precise assembly require sustained contact and millimeter-level precision, but learning the skills for precise assembly from scratch is really difficult. We argue that before we can learn the hard problem of precise assembly, we must first learn the easier problem of playing with objects in free space. This motivates Play2Perfect, a framework that leverages the familiar pre-training fine-tuning paradigm.

We first learn a shared dexterous prior through task-agnostic play, which is very similar to the SimToolReal task-agnostic training. We then fine-tune that prior on a sparse reward contact-rich assembly task and deploy the policy zero-shot in the real world. This enables diverse contact-rich assembly behaviors, including tight insertion and multi-part assembly.

In conclusion, SimToolReal enables broad reactive dexterity across novel tools and tasks, while Play2Perfect extends this towards precise contact-rich assembly. Thank you.

Audience: I noticed that in the demos, the recovery was insanely impressive to say the least. Is that something you all specifically aimed for, for the robot to have good recovery, or was that just an accidental byproduct of the policy?

Tyler: That’s a really good question. We didn’t specifically train for that, but one thing that we importantly added—one of the details about domain randomization we added—was that in simulation, we added these random forces on the object that randomly pushed at it. Sometimes it would knock it out of the hand, so it gets experience having to pick it back up again. If we didn’t add that, I think it may not be as good at recovering because it might never drop it in simulation.

Audience: How similar did y’all ensure the primitive tools you used were to the normal brushes and spatulas you use?

Tyler: Great question. It’s called SimToolReal because we’re trying to focus on tool use. Many tools have some sort of graspable region that can be somewhat approximated with a bounding box. That’s our interface here that we’re using. We’re not giving it detailed object geometry; we’re just telling it roughly what the bounding box size is of the graspable region. In simulation, one detail here is that we’re using all primitive objects, just cylinders and cuboids. We could extend it to more. Then you have to generate a whole other dataset and remove stuff that’s not stable. But the key advantage is that the simulation runs two to three times faster when you use simple objects like that. That’s what we use here—things that can be reasonably approximated as a cuboid. Something like a spatula or even a sphere would probably be fine.

But if you’re trying to pick up something like a bowl or maybe scissors, it probably could pick it up in some weird way, but not in the way you’d want it to.

Audience: I’m super interested in this kind of novel approach rather than learning from human demonstrations. Basically, you learn a bunch of sub-goals and then use RL to reach those sub-goals. But one problem for this, I think, is probably how would you be able to generalize to a lot of real-world objects other than tools? Because for tools, you can easily define those primitives. Have you thought about those? For example, articulated objects—how would you be able to do those?

Tyler: Simulation has its pros and cons. One answer would be we can maybe just simulate all of them—simulate scissors and simulate all kinds of other articulated tools. But there are just so many things that cannot be simulated well, like water or even a zipper or cracking open a can of bubbly or something. That kind of stuff is not currently in the realm of simulation. What we do there is a really good question. Can we transfer these priors into the real world and keep fine-tuning it? I think that’s most likely the way I would do it, but that’s a really good question—how to integrate this kind of great dextrous behavior, but let it keep improving with real-world experience.

Audience: I think my question is more on—even if you assume you can simulate all the objects in the world, but with this paradigm, are you able to generalize? So

Tyler: Just still

Audience: RL?

Tyler: That’s a really good question. I think if you take a really far step back, our policy is being given the current pose and the goal pose. And it’s kind of like an inverse dynamics model in pose space. But if the object can’t be specified as pose, maybe if it’s something like a towel, maybe you can specify it with key points. Or maybe the most general version of it is you have a video goal and you’re almost an inverse dynamics model of the current state and the final goal state. It’s probably possible to train something like that, but exactly how to get those details right—generating the goal at inference time is a really hard problem. But I think your question’s a really good one. How to make that more general.

Audience: Yeah. We’re trying to basically reproduce this. Oh, cool. Cool.

Audience: Yeah. Hey, I’m trying to interact with that one right now. And I think I’ve been trying to poke around and find failure modes. I found that the only failure mode that consistently shows up is when the arm continuously twists, trying to find different objectives. It fails usually when it twists the arm itself too many times. I was wondering if you have a reset dynamic maybe between actions where, let’s say my arm is here, and in order to reach this state, I could turn it backwards instead of trying to twist it even further.

Tyler: Yeah. Good question. I’m honestly not sure exactly what the right solution is there. In theory, if RL’s really good, it should know to spin it all the way around again. And it gets really contorted. I don’t know the exact solution to that. I guess in most real world applications, you don’t go crazy contorting your arm, but I think it’s a good question.

Audience: Cool. Thank you.

Audience: Okay. First of all, this is amazing. Congratulations. My question is, from the team’s perspective, how do you guys iterate on such a thing? For example, if you have one policy, you start seeing regressions in other tasks. How do you guys handle that? Do you have evals or what does iterating even look like in this space?

Tyler: Good question. It’s a bunch of things. How do you eval these kinds of policies? You can eval in the real world, but it’s very expensive and takes a lot of time. And a lot of times you don’t actually get statistically significant numbers. You almost get a vibe check unless you run it truly a hundred trials. It’s hard to tell if you’re at 90% or 87% success rate. The other thing, one thing we really try to do is have a lot of automated ways to evaluate our policy across all those novel tools and tasks in simulation. So it gives us a sense—we train on the random objects and random goals and see how well it works on our real world objects and real world trajectories, but we put them in simulation. So we get some metric, a feel for if it’s doing way worse or way better.

But it’s a good question because honestly it’s really hard to tell. Sometimes it can do better in SIM, but it’s doing some magical tossing and catching behavior that may work, but our pow tracker would probably fail. You need a little bit of that human insight still. It’s a really, really hard one.

Francois: I have a quick question. So you use this prehistoric thing called an LSTM. Can you tell us about that? What is that?

Tyler: Yeah. It’s a long short-term memory. I can go into the math, but basically RL packages are—how do I say it—RL is a very finicky thing where you almost don’t want to change too much of the code because once it works well once, you don’t want to rewrite it from scratch because any one value you change could break the whole thing. It’s really good to start from a good starting place and then iterate from there. That code base already had LSTMs baked in. We were like, let’s just try it out and it worked better. There’s probably other ways to integrate something.

Francois: Better. LSTMs work better than transformers. Well,

Tyler: There’s no transformer in that one.

Francois: Yeah. But do you think that transformers would have worked better?

Tyler: I’ve talked to people about this. I think that broadly, transformers are probably better data sponges if you have unlimited data. But here I feel like we’re getting a lot of data, but we’re constantly updating the policy. I feel like it’s actually not in that regime where we need an enormous, huge data set. Some people have actually tested this and not shown any improvement. I haven’t had the motivation. The coding agents are out now, so probably no excuse for me to not try it.

Francois: The diffusion policy paper, a lot of people don’t know this, but if you go through their table, the conv actually outperforms the transformer on half the policies.

Tyler: Yeah. Unless you tune the transformer better, it’s actually much more sensitive. I think exactly that.

Francois: And then the last question, I didn’t really understand how you create random goals. What does that mean actually in the code? What are you actually

Tyler: Doing? Oh yeah. It’s the simplest thing you can imagine. We sample a position, we sample a rotation, and then we put that as their first goal. Every subsequent goal is some delta pose of up to 10 centimeters away and up to 90 degrees difference.

Francois: I see. So that’s really good for training the policy to get from A to B, but it’s not good for generating the goal. So to generate the goal, you need human labels.

Tyler: Exactly. Or you could do something else. You could actually imagine there’s some high level planner looking at the scene, understanding the full context, and then generating the goals for you. I think that’s probably a pretty interesting direction.

Audience: You were mentioning some of the failures were due to wrong estimation of the pose.

Tyler: Oh yeah.

Audience: What fraction of those would be attributable to that? And second question is, are you always using the third person views or did you also perform any experiments with

Tyler: First

Audience: Person views? Oh,

Tyler: Good question. Yeah. About more than half of our failures, I think roughly 60% of our failures were purely from the pose tracking. It was really one of the big bottlenecks of the system. It’s honestly not my favorite part, but it really happened the most on these smaller objects. So that marker, that one is really easy to be occluded. You barely see it at some points. I think that’s an example of one that would be really hard. This kind of longer leg or this bigger brush has a lot more features, so those would have less pose tracking issues. That’s roughly how that looks.

Audience: Were you using the third person view or videos

Tyler: Experiment with first

Audience: Personnel? It

Tyler: Was a third person view roughly where this camera is. And that’s pretty much all we tried. We just found a good angle where it didn’t seem to occlude, and then we just used the pose tracking from there. I think it could be better. Maybe you could even use a pose tracker from the camera. You probably can distill this to some image-based policy, but there are some details about getting the goal conditioning right.

Francois: Awesome. Thank you, Darren.

Tyler: Thank you.

Nico: Yeah, I’m Nico. I’m one of the co-founders and the CEO of Rerun. In a prior life, I used to do machine learning, computer vision for physical world applications, for shipping products like that for about a decade before this company. At Rerun, we are building this unified data layer for physical AI. Basically tools and infrastructure to help you work with physical data from collection all the way to training. This open source SDK is pretty popular. I know a bunch of people in here use it for working with physical data. It’s for logging, visualizing, generic querying, and data loading for training. Basically all the tools you need to transform and analyze data. We have an info product called Rerun Hub, which is a data catalog and large-scale data backend for doing all those same things, but for lots of data in the cloud.

As part of building this, we get to talk to and work with amazing companies doing robotics, from frontier labs all the way to two-person YC startups. There are many ways to do robotics companies and robotics projects. There’s one pattern that we’re seeing a lot of that’s really, really working right now that I’m super excited about, and I want to see way more of. This talk is actually mainly me trying to tell you all to start companies like this. Basically, that new category is what you might call just robotics application companies. I think some people call these the neo integrators. Their pattern is really taking ownership of a full business problem end to end. Right now, we see this working a lot in data center management and construction, warehouses, manufacturing, things like that. Just being really, really excellent at operations, deploying, support, things like this.

Building as absolutely little custom hardware as possible. Then, generally, often starting with teleop, making sure the business works with pure teleop, fine-tuning models. Not feeling the need to start out with foundation models and solve very general problems. My personal belief is that this kind of category of company is going to be the new SaaS. The way SaaS companies came and just took over software over the last, I don’t know, 10 years—until I guess SaaS is dead now—but this is not dead. This is the same thing that’s going to happen for work in the physical world. These kinds of companies are going to do a lot of the transformation of the world’s economy. I think it’s a very ripe time to get into it. To talk about that, I thought I’d just walk through a little bit.

If I wasn’t doing Rerun, how would I do it? This is the pattern that I see. How do you get started? Pretty simple pattern. Start with a single customer problem that someone will pay you for. Solve it with teleoperation first and just off-the-shelf hardware, just scrappy, get started. The basics you need for learning. With that in place, you just iterate more and more at scale, and then you’ll do the rest of your time with your company. But that’s the fun part. To me, I would clearly pick this very important problem. Everybody loves paper planes. Folding is super annoying. So I would make a robot for automating paper plane factories. First thing you do, right? Sell and deploy super fast. Ideally with teleop and off-the-shelf hardware, as I said.

And the reason for this is basically the physical world is brutal. Everything that you do is going to break. You will not have thought of all the different failure modes up front. It is not possible to think of them all in the lab. It’s really important that you understand the end-to-end real business requirements super fast because you can’t fix all the theoretical things. If you can solve something with tele-op, generally you can train a model to do it. The converse is not always the case, as we heard about in a lot of examples. If you can, that’s great.

Just some examples of what we might learn doing this: maybe we learn that you need to produce a thousand perfect planes per day to be viable as a business. Maybe it’s okay to fail as long as we can sort out bad planes, so we need to be an efficient discriminator. Paper’s cheap. Customers care most, it turns out, about the speed to onboard new plane designs. If you add the right little paper tray, maybe you reduce failures by 50% because most of the failures were actually picking up the paper from a pile.

It turns out it takes a human 20 hours of practice to get good enough to meet a customer’s demand requirements. That has huge impacts on how you’re going to run operations. Maybe you need to hire all the teleoperators because they need training, for instance. You may also learn that it’s 10 times more valuable if your robot can also go pick up the paper and pack the boxes for shipping at the end. Then you have an idea of your V2 product. You’ll definitely learn that your arms are going to break. The cheap research arms that you bought are going to break after some use, and you need to change your supplier.

That’s part one. Part two is setting up the basics for learning. Hello World in this space is basically fine-tuning, let’s say, a Pi model, open model of some kind, just for the simplest possible case on a few hours of demonstration—tele-op demonstration—and just making sure that it somehow works a little bit.

You’re up on the treadmill. It’s really important to do this early as well because training on the data early will change how you collect and how you run operations. That’s super key. When you have that in place, you need to make sure that you can evaluate and understand performance, and then obviously collect the data that you can train well on.

Number one, evaluating performance: the first thing you need to do is have a replica of the customer’s environment in your own office. I’ve been in a lot of robotics companies’ offices. Among the companies who actually ship working products, I haven’t seen a single office that doesn’t have a replica of customer environments. You just need somewhere to test, and you need to test a lot. Number two is finding a repeatable way to evaluate success.

And this is where you are going to do—this is the backbone of all the learning that you’re going to do. Here you can really encode things that the generic model companies will not do. You’re going to encode what is important to this business, and that you learn on the ground with your customers. There’s a lot of stickiness in that. In this case, maybe we care a lot that the edges on the planes are sharp. We care that it matches the design, it’s a metric, maybe the weight distribution is right. I don’t know. It’s super important to do this yourself manually until you really understand it, and it’s kind of stabilizing. Definitely automate it somehow, train a model, outsource it, but do it manually first. Then you need to be tracking metadata of all the rollouts, failure classifications, that kind of thing.

Second thing is collecting data that is effective to train on. It’s almost tautological, but good data is data that makes the model better. What that means in practice for you is that you need to be training and evaluating and debugging your data constantly. If I talk to researchers at big robotics companies with huge budgets and so on, they’ll often tell me that one of the most common things they’ll do when they’re debugging their policy or analyzing their data is they actually find out that the right thing to do is to send a different instruction to their data collectors to collect data differently or to stop doing some mistake. Doing this early is important. You don’t want to be collecting all your data upfront and then train later. Huge mistake. There’s lots of literature and expertise on what kind of data you want.

You want the right kind of variability, no bugs. That’s a deep one. But the most important thing isn’t the specific ways of doing it. It’s that you are testing and iterating really fast and getting your hands on real problems. To do all this, you need the right data and formats, tools to work with your data through all this. You need to be able to record and store and inspect your data and obviously train on it. Just a couple smaller examples: one could be this—your customer said that they care a lot about quickly onboarding new designs. That means you have to have some strategy to be a little bit more sample efficient. Very commonly, it’s more practical at these companies; what they’ll do then is split this task into more composable sub-tasks.

So then you need to design the taxonomy, figure out how you want to annotate this efficiently and repeatably. And you’re now in a situation where your annotation is too complex to be doing live. Maybe in a simpler case, you could actually have the operator just speak or have a little foot pedal or something like that to do annotation, but now you can’t do that. That changes your operations. Second, on the data tooling, you get into why not just use Postgres or whatever data infrastructure was built for the prior generation to do LLMs or feature stores for prior ML and so on. The answer is basically that physical data—all the data that you’re going to be working with in robotics—is just very, very different than web data. It’s multimodal. It’s multi-rate. It’s episodic. It has this weird semantics of 3D and deep nested structures.

That means if you try to put that kind of data in normal data systems, like table-based databases, it’s incredibly hard to query and very inefficient to store and process. This is really at the heart of a lot of the complexity of working with physical data. There’s a lot to say about that, but the end effect is that most teams, if you don’t set the right storage layer at the bottom, end up building a lot of workarounds, and that’s a huge amount of friction. But if you have these very basic things in place, you’re ready to hill climb. So you’re deploying and learning from real, valuable robotic service that’s doing something worthwhile. You know how to evaluate performance. You can improve to collect data and train on it well, and you can debug across the stack.

Super important. You don’t know where the problems are in robotics—real robotics. It’s a death by a thousand cuts kind of industry. You just have to find all the problems. After that, it’s just iterate and scale. This is what you’re doing the whole company. Super, super fun. Includes improving intelligence, scaling up crazy amounts of data perhaps if you need it, iterating on algorithms and more advanced use of data, maybe adding in Francois’ favorite with tactile or depth or sound. But you’re also really going to have to get excellent at sales and assembly of your robot, shipping it really fast, having a good unboxing experience, operation, support, everything in between. Importantly, these other areas that are not just modeling are a lot of the source of your moat. This is the kind of stuff that the pure model companies will not do.

Just on that, the thing that we see, even the absolute teams that we’ve seen really succeed—and there are some companies taking this approach that raised reasonably little, small amounts of capital that were already making a lot of money, doing very well, and growing super fast—is basically iterating super fast. On the frontier lab side, that tends to mean they’re investing huge amounts of compute for every researcher. Everybody knows they spend a lot on GPUs for model experiments, but also quite a big spend on CPU for really turning down latency on searching and exploring data. But these robotics application startups instead really focus on very pragmatic and simple, flexible systems to have very minimized moving parts. It’s super important to have fast turnaround with new data, full stack debugging, and making sure that you can understand all moving parts.

Yeah. This is my pitch to all of you. At least someone in here should go start a robotics application company. The market or markets are enormous. The base models will keep getting better. There is actually enough friction in the physical world to build real business moats. So it means you can stick around, which is great. And you can do this with a relatively small amount of capital. You will not need to raise a billion dollar seed. But you still need great AI, you need great engineering to win. That means all of you here and, I guess, people listening, you have a leg up and it will still be super fun. I’m going to do a quick plug or reiterate what Rerun does. If you’re building a company like this, definitely check out Rerun or talk to me.

As I said, we have an open source SDK. It’s meant for you to iterate super fast with robotics data. It has all the pieces you need. It works really well with agents if you want to make it work exactly like you like it. And a production catalog and storage engine to make it fast and easy to use when, at some point, you need to start scaling and you have a lot of this data for production or for training or whatever it is. All right. That’s me and you can find us here.

I think where we see a lot of early success tends to be in things that you can tell off basically. Data centers are quite a significant category, but a lot of warehouse robotics—there are so many pieces that go into just moving things around in the world. A lot of them are quite repeatable. Labor is fairly cheap, but it’s also hard to manage. And there’s too little labor out there. We’ve found with the companies that we work with and are generally known that can build a reliable robot, they basically are 100% supply constrained. They have a very easy time filling their demand. So that would be one area. Small scale manufacturing, like tabletop manufacturing of different kinds—we see a lot of action there. Food as well.

Francois: Aniko, thank you. Why haven’t there been a bunch of these robot application companies yet that have been at billions of revenue?

Nico: I think robotics is this death by a thousand cuts kind of thing. In any area like this, it matters that you can try out an application fairly cheaply. And that’s actually quite new. There are a lot more arms on the market now. The base models are way better now than two years ago. So there’s been this lack of the basics that you need to do this fairly cheaply. Everybody’s had to go out and raise huge rounds and go for much more general things to start with.

Audience: I think one dilemma one might face while building this kind of company is how to estimate the scale of data you would need to solve a particular problem before the model is deployable. How do you go about that? How do you estimate the scale of data you would need and whether it’s the right problem to solve or switch the problem so that we need less data to iterate faster?

Nico: Yeah. I think that’s really one of the core ideas between if you can teleop first. It’s not obvious that many businesses work without full autonomy. Even a lot of the robo taxi businesses don’t need full autonomy. A lot of these companies see autonomy as a scaling factor. So you teleop; generally if you can teleop, you’ll be able to learn the least important parts at some point. It just becomes a question—you learn that by training models and trying to plot your own scaling curves and so on. I don’t know that I know anything upfront, but that’s kind of the idea of the strategy. You don’t guess and avoid because it’s equally likely that the task you thought you needed to solve isn’t really the important task anyway.

Audience: Thanks.

Nico: All right. Thank you,

Francois: Nico.

Bill: We’re from General Instinct. My name’s Bill and then Guanming’s going to present later. I come from a technical background working on VLMs at the beginning. Worked at Siemens on their foundation model to train to predict time series. And then Guanming worked mostly on robotics RL. What our company does is we build infrastructure for you to run physical AI models really fast. For LLMs, you have vLLM and SGLang. For physical AI models like world action models and VLAs, you would have us, General Instinct. This is a meme from Jim Fan’s talk that VLAs are dead and then we’re going to have world action models from now on. Most of us in the room know what VLAs are already. I’m not going to try to explain it. Basically, you have a VLM that’s trying to predict an action through an action head.

What a world action model is, however, is you have a central diffusion transformer that’s trying to predict what the future looks like and future kinematics at the same time. So you have current observation from a robot’s camera in the form of video streams, and then you’re trying to imagine future frames as a condition to try to predict future kinematics. One example is NVIDIA’s DreamZero. You have basically the robot trying to predict future actions, and then you have the flow matching that allows the robot to act on those action chunks and future frames. And DreamZero did really well. So these are some benchmarks that you have on DreamZero compared to some of the state-of-the-art models—some models from Pi, some models also from NVIDIA. But one problem that we noticed is that although world action models perform really well, because you’re still trying to use a diffusion model to try to predict frames, it’s really heavy.

So even after all these optimizations that you can do on it, it still takes two GB200s to run the same model. And then each one costs around 70K. So economically for robotics as an industry, this is not scalable. Another thing, VLAs are not dead because they’re small.

Guanming: So since we know world action models like DreamZero are super slow, we will talk about how we can optimize it. So this is the architecture. On the left is a training pipeline. On the right is the inference pipeline. So for the training pipeline, you basically treat current observation as the condition for the flow matching, and you add noises to the future latents. And then you will train the model to learn the future latents and then predict the future velocity field. And then send it to the OD, then you can drift back to the future latents with clean states. That’s the same thing for the inference as well. For the inference, you’re doing this ultra aggressively for maybe 50 steps, or some people do 100 steps to ensure the accuracy of the models. And a problem for this will be on the left, you have the video prediction.

On the right, you have the IDM, which is the inverse dynamics model. So basically for each chunk production to produce one chunk for 16 frames, you need to run the DiT, which is a diffusion transformer, 32 times because of the CFG. The CFG is you need to run the condition for the flow matching and also run another unconditioned flow matching. Then you can take the derivative of the gradient that you can do for the gradient design for the flow matching. If we go back to the architecture like this, people were talking about, oh, why not just not run the diffusion models? So we don’t need to predict the future frames. That works. And there’s a research paper called ImageWAM. Basically, they’re not predicting the future video chunks. Instead, they are predicting the future end state, which is the future end state of the single frame.

For instance, I’m predicting the future video for maybe 16 frames. Rather than predicting the whole video, we can just predict at T plus N, which is the end state of the frame. And there’s another research paper called Fast-WAM. Fast-WAM is more extreme in some sense. They think all the world representation is already learned in the hidden states of the DiT. So you don’t even need a decoder to decode all the videos. You can just use the hidden state as a condition to train your action head. By doing this, you don’t even need a decoder in the training and also in the inference pipeline. If we take an analogy of those two different world action models, for the generative world action model, where you need to decode and then predict the future frames, you’re pretty much like a VR of Google Maps.

But for the latent world action model, it’s like you look at the navigation of your Google Maps and think about where the model or the policy is heading to and what kind of action you’re going to produce in the future. In conclusion, all the problem comes down to the question about how to keep the rich world representation. Some people like LeCun, they think about, because they were doing JEPA, they think about maybe we can have two different encoders. And then one encoder is encoding current observation, and then the other one is encoding a future observation. And by doing loss on the current observation latent and the future observation latent, then you can teach the model to learn how to predict the future. And that’s one way of doing this. And they’re doing this using MSE loss. And other people, they treat the future as a distribution of possibilities.

It might be you take this possibility of this action, you might take another possibility of taking another action. So you treat the massive distribution and then you estimate those kinds of action distributions using flow matching. We talk about those different optimization angles we might have. And for us, since we are doing the infra thing, we did all those optimizations on our infra. We did distillation on the VAE part, which is a VAE encoder-decoder. We also did distillation on the DiT part. So the DiT became smaller. We also divided them. Because previously they were using the same DiT, we divided them into two different DiTs. Rather than decode all the future frames, we can just use the cross-attention from the video transformer to the action transformers. So the action transformer learns the head and state, which is the world representation from the video transformer.

And you don’t have to decode the future frames anymore. We also did distillation on the auto-regressive flow matching sampling. Previously, it might take 50 steps or 100 steps to do the flow matching decoding, but we made it down to one or two steps, which is immediately a 50 times speedup. We also did some changes on the modality side because we know future representation or world representation can be learned through pixel level or latent level. Is it possible we can find a more suitable modality to represent or retain the world representation? One way of doing this might be mask, and the other way might be flow. We tested both of them, and you can see the heat map is the visualization of the model. It guides the world model about which action you’re going to take in the future, 0.5 seconds.

By using our infra, the world action model can run 500 milliseconds per chunk, which is 16 actions on Jess and SOAR. We also wrote a full blog about how we did this on our website. This is the QR code if you need to learn more about it. Also, this is the LinkedIn of the founders of us. That’s it. Thanks, guys.

Audience: Going back to that slide that you had with the training and inference of the world action models. In the

Audience: Training

Audience: Stage, you’re using flow matching and teacher forcing. That makes sense. But in inference, you’re going to start from a fully noisy space and then you’re going to come to the future time step. How do you ensure that at inference time, the model actually collapses to the right thing and it just doesn’t degrade to noise?

Guanming: Oh, that’s a very good question. For the training part, you begin with the clean future latency and then you add noises to the clean future latency gradually. Eventually, the future clean latency will become pure noise at the end for the training part. By doing this, the inference learns how to reverse it back. So when you give it pure noise, the inference learns how to do this gradually and then reverse back to the future clean latency. That’s basically how it works.

Audience: So like curriculum learning or starting

Guanming: With very

Audience: Little noise initially. And as you train for longer, you have more noise.

Guanming: And that’s why it’s super slow because people are doing this maybe for 50 steps. We think it’s too slow, so we just found a way to distill it to two steps or three steps so it’ll be way quicker and without performance drop.

Audience: Yeah, that’s super interesting.

Audience: So when it comes to the world models, is the performance improvement due to the action heads looking at more details when we are forcing them to predict the whole frame? And second one is when there are multiple agents that are involved in the scene, does the model actually develop some kind of a theory of mind and predict other agents’ actions in order to be able to predict the world?

Guanming: Oh, that’s a very good question. I want to go back to the architecture of VLA and world action models. I got a lot of questions about what is the difference between VLA and the world action model? Why does the world model need to predict the future rather than just predict the action itself? A way to answer this is for VLA especially, they’re just based on the current observation to predict the current action. They don’t have the explicit learning of the future kinematics. The only reason we need to introduce videos, especially for future videos, for the world action model, is we want to teach the model to learn the future kinematics. For example, I’m holding a bottle of water and then I drop the bottle of water. From the pixel level, if we give the future videos to the model, the model learns how the kinematics will change at the pixel level.

We know this is a kind of supervision, teaching the model to learn the future dynamics. We believe the future dynamics help with the action generation as well because it’s physics. By doing this, we teach a model how to learn the correlation between the physics from the pixel level to the action you produce.

Francois: To test that hypothesis, could you train a transformer stack body to do next frame prediction and then more and more and then rip off the head and just do the action? Would it do the same thing?

Guanming: As in, like, we divide them into two different transformers?

Francois: Different stages.

Guanming: Yeah. Of course, there’s a more efficient way to do so. It’s called mixture of transformers. If you check ImageWAM, they actually do the same thing. They did the cross attention from the image encoder backbone to the action expert. Just like ImageWAM and also Fast-WAM, they realize the world representation—you don’t have to explicitly decode the frames. You can just keep them in a hidden state and then do a cross attention from the last layer of the backbone to the action head. So, short answer for this is of course you can do so. We realize that this is the more efficient way to maintain the world representation, meanwhile producing the best action based on the world representation.

Francois: And then is there no test time planning that’s done with WAM where you will invoke, let’s say, 10 samples and I’ll get 10 different end states and 10 different actions, and then I’ll pick the best end state of the ones that were sampled and then emit that action? Is that not done?

Guanming: Yeah. I think it’s pretty much how flow matching works, right? Because for flow matching, you treat action as a possibility of distributions. And then you always sample the best trajectory. And we use teacher forcing to teach the model to sample the distribution of the actions. So I think for flow matching, they’re already doing the same thing.

Francois: And then last question from me, why choose the business model of being a vLLM equivalent for WAMs versus just actually do like Nico says, become a robotics application company and actually go end to end?

Guanming: I think Bill can answer this question.

Bill: Yeah. I think the reason we went with this route is because we really believe in having this understanding of the world for your models. But I think right now everyone’s focused on maintaining the research so that it can be as generalizable as possible. But eventually every model like that needs to go on the edge and needs to go in real time. So I think right now, not a lot of people are focused on building that infrastructure that allows those models to perform really well on your robots first. We want to be the first company to do that.

Audience: Hi, I have two questions. The first one is more of a clarifying question. So for a WAM, is the prediction auto-regressive in previous frames or is it just one previous T minus one and then to T without any other T minus two, minus three, and so on?

Guanming: I think what you’re talking about is the chunk size, because you can change the parameter as well. So for the training, you can do 16 frames, which people, they all do 16 frames, which is you predict in the future 16 frames. And people, they also do 32 or even higher frames. But if you increase the chunk size, which is more frames you produce, then it will be harder for the model to learn the future states because it’s longer.

Audience: Understood. Okay. And my second question is, are you familiar with any work that uses encodings for the differences between frames? So like temporal difference encoding, I think like a recent work by Yann LeCun, as well as a tech blog by, I think, Induction Labs where they train an imagination model that predicts latent encodings for the differences between adjacent frames in a video.

Guanming: Yes. And if you check here, we mentioned asymmetrical de-noising because we found a way that you can actually measure the energy of the KV cache. So rather than producing all the future frames, why not just produce those, maintain the highest details of the action you’re doing right now? And that’s basically what we added to the infra as well. So we found a way to measure the different energy of the KV cache, and then based on the energy we decide if the model is going to predict different resolution of the frames or just purely doing this on a latent space.

Audience: Thank you.

Science is building a retinal implant that restores vision to people who have gone blind. One patient has already used it to read a 300-page novel.

Building a company like that requires a lot more than getting the technology right. At Startup School 2026, Science CEO Max Hodak explains how the company buys things and hires people, and why those systems determine how fast it can move.

He also gets into why founders can’t delegate their judgment, and why there’s no set of five bullet points that makes a startup work.

Watch on YouTube

Timestamps

00:00 — Infrastructure at Startups
01:02 — Science’s Retinal Implant
02:41 — The Hidden Infrastructure of a Startup
03:25 — How Your 17th Employee Buys Things
06:15 — How Infrastructure Creates Speed
07:03 — What Does an Experiment Actually Cost?
09:27 — How the Best Startups Hire
10:18 — Building a Rigorous Hiring Process
13:26 — Judgment, Horsepower, and Agency
16:17 — Rethinking Performance Reviews
18:53 — Rate of Iteration Separates Success From Failure
20:43 — You Can’t Delegate Your Judgment
22:47 — Action Produces Information
24:31 — The Operating System of a Company
25:10 — Q&A

Transcript

My name is Max Hodak. I’m the CEO of a company called Science. We’re going to talk a little bit about infrastructure at startups. I’ve spent most of my life working on brain-computer interfaces. This is almost 20 years ago now. I started my career as an undergrad working in a lab at Duke. This is from our very first Society for Neuroscience conference. The experiment I was working on back then was: if you put electrodes in the brain of a monkey and then give a monkey a joystick and you record the neural activity as it’s playing a game, if you make the joystick—say, the cursor goes sideways when you push forward on the joystick—what does the brain do? Does the brain represent the joystick or the screen or something else? It turns out that there are neurons that do both.

At our company, Science, our main product is a retinal prosthesis. It’s a chip that’s implanted under the retina in the back of the eye to restore vision to patients that have gone blind due to loss of the rods and cones in their eye. This is one of our patients on the cover of Time last November. On the right, you can see there’s a picture of the implant with the glasses. So every little one of those hex grids that you see on the implant is essentially a solar cell. When this is implanted under the retina, the patient wears glasses that have a camera that sees the world and a laser projector that projects onto the implant. When it projects the image in infrared, wherever the light is absorbed on the implant, it creates a little electric field to excite the retina, thereby directly bypassing the dead rods and cones to stimulate this visual signal back into the retina, the first possible opportunity.

And this is a pretty cool product. It finished major clinical trials last year. It’s been in three clinical trials now. It was covered in the BBC last fall. One of our patients finished a 300-page novel with the device and mailed us the book. But I’m not going to talk about this work for the most part for the next 30 minutes. We’re going to talk about infrastructure and lessons. This is Startup School. Maybe there are some things that you’ll find useful in your company.

Picasso was noted for saying that when art critics get together, they talk about form and structure and meaning. And when artists get together, they talk about where to buy cheap turpentine. This is also often phrased as: amateurs talk strategy, professionals talk logistics—a quote from a guy that the United States named a tank after. And so there are surprisingly few lessons that are really broad across companies.

Typically, the experience of running a startup is you’re just looking at a continual stream of facts that hit your desk every day, and you’re trying to make the best local decision that you can for those facts. And if it looks inconsistent over weeks, that’s usually the way to go. But there are a couple topics that keep very repeatedly coming up that are universal experiences, at least for deep tech companies, which is the thing that I know most of my experiences in—not just pure software. There are things that keep coming up, like buying things. Your first reaction might be that if you do software, you don’t need to buy things. It will be me alone in an empty room with some computers writing software, and this is going to be how we build a company.

And if this is you, yes, you have figured out a reason why VCs love funding software and why they’ve done so much of it for the last 25 years. But if you do anything other than pure software, you’ll be buying many, many thousands of things. This is us about, I think, six months into the company. It’s a little tough to make out. There are a lot of computers. There’s also a bunch of microscopes and other electronics and 3D printers and resin and PCBs. You’re buying things really continuously. It might sound really obvious, like a really basic question, like you surely just buy things. For you as the founder, you can use a credit card. Credit cards work great. You can buy lots of things with credit cards. You can also send a wire transfer. The question is, how does your 17th employee buy things?

Do they have a credit card? Let’s say you hand out credit cards to all of your employees and tell them to buy what they need. So you start getting messages like this, and you think, I care about burn. We have to spend efficiently. I’m going to approve all of the purchases as they happen. You’re going to put a message like this, and then you think $3,000 sounds like a lot for a power supply. Do we need a $3,000 power supply? What if we get one from an auction? In three days, there’s an auction. Maybe we’ll get it for half off. We can get it in two weeks. But then you also remember that you’ve hired some very highly paid and talented employees. Are you saying they can’t get the tools that they need? You’re spending $100,000 a week. If you wait a week to get a power supply half off, you have certainly dwarfed any possible benefit from getting it.

And if they were at Anthropic, they’re not going to be getting hassled over a $3,000 purchase. They’re just going to have a power supply. What you realize is not only is this very hard to keep burn under control, but also this is the inappropriate place to exercise spending review. Spending review has to come earlier. You have to have some concept of budgeting. It’s not really even just about the payment rail of buying a thing. It’s about how you understand the bucket of money that you have. I don’t want to be making the $1,500 power supply versus $3,000 power supply trade-off. They need to understand the resources that they have so that they can make trade-offs within those available resources. So you set up a procurement system, and now your highly paid employees are spending their days clicking around B2B enterprise SaaS.

It turns out that from the time they place an order for a power supply, it takes two weeks to arrive because you can’t actually buy that with a credit card. You have to set up an account with the vendor and deal with insurance and certification paperwork and get an account set up. They have to generate a quote so that you can generate a purchase order so that you can generate an invoice. Now everyone’s upset that things are taking super long to get ordered. This actually really requires—this is a living organism. When people move from academia to startups, I think one of the reactions that people often have is, why are there people whose job is to purchase things? Surely I can just buy things. But absolutely there are people whose job is to buy things.

From the time that you submit the order, going back and forth with the vendor to set all of this up is very time-consuming and it can easily stretch out. It takes active management and metrics to cause these things to go fast. I think part of why, when we think about this, we have a reputation of often being very quick and people are unsure—how does that happen? It is mostly not that we are smarter. It is infrastructure like this; that is how speed is built. Now people can buy things. At least you can keep overall burn under control. Now you know that you’re not going to exceed some large amount of spending every month. Then you realize that that wasn’t really the problem. You could figure out your runway. The problem is attribution. When you’re doing—whether you’re working on rockets or cars or drugs or brain-computer interfaces or anything that involves dealing with the real world—you realize that one of your other problems is that you’re buying stuff in bulk.

We buy gases from argon to xylene to nitrogen, to resins, to media. We buy these things in bulk and then part them out to lots of different experiments. When you do this, attribution is pretty difficult. If nobody knows how much an experiment costs—like every time you grow up a new cell line or every time we make a new probe in the fab—how much does that loop cost? Nobody knows. Therefore, experiments are free. It doesn’t cost dollars; it costs media, and media comes from the fridge. And we want to know, how do we price a thing that we make? We make a bunch of things in volume in the foundry. We want to know, what can we sell that for? That requires all of these spreadsheets to get an estimate of the pricing.

And there are opinions in here. These are not all facts. How much do you include rent? How much do you include depreciation of the tools? This comes with opinions about your future volume. All of this is required to understand not just what you should charge, but also what you’re spending and what your runway is. To deal with this, we’ve built a huge amount of internal software at the company for managing this. One of the first things that we did is almost everything that you can do in the company is a button somewhere in the software. We call it Helix, including stuff like purchasing. Because this extends all the way through to manufacturing, where we have every step that happens in the lab in the database, we can correlate all of this through and get this information. It turns out that for every iteration of a wafer that we make, in this case, for this protocol, it costs $40,000.

This is a lot of money. You might have raised—let’s say you raised $20 million in a Series A. You think you need four years, you need 20 people. In my experience, about half the burn is headcount. So let’s say 20 people, that’s probably three, three and a half—that’s like $3 million a year in payroll. That’s half of your burn. You need 20,000 square feet, about $4 a square foot. That’s another $750,000 to a million a year. So now suddenly you’ve got really, it’s a $3 million a year research budget for three or four years. That goes way faster than you think. But your team just saw that you raised a larger amount of money than they’ve ever seen in their lives, and they think that the $3,000 power supplies are free. This is pretty important. This infrastructure actually determines success or failure in many companies.

Another universal experience is hiring. Hiring also, I think, really separates the successes from the failures. Startups usually don’t come out of nowhere. I think the best companies, in my experience, come from what might be characterized as scenes. There’s a moment that enables a new company to be born, and there’s a bunch that comes together that really creates this unique nucleation for the new company. Once that moment has passed, because some company has executed on it or just the time has gone, it’s tough to get back. The best hiring comes from within your network—people that you’ve worked with before, who you know are good. The extended version of that is to hire from the network that produced the startup. There’s usually some extended scene that the thing came out of. There’s a bunch of co-founders that come together and crystallize out of that.

But then there’s an extended community, and that should really be the target of your initial marketing. These are the people that already speak your language, are already familiar with it. But there’s never enough of them to really fill an entire company. You have to hire from the general public. Different companies hire in different ways. There are different processes that make sense to different founders. This is the thing that really is going to be matched to who the founders are and how they view the world. There’s no one right answer. But this is a thing where you need a really defined process. There’s no right answer, but a wrong answer for sure is not having something that you do very religiously as a company. This is an area where reality has a surprising amount of detail. It seems really straightforward, like, oh, you’ll have a job board, you’ll get applications, you’ll review them.

This very quickly becomes a huge, huge drag on the rest of your team. You can easily spend almost all of your time recruiting if you’re not doing it efficiently, to get to a suboptimal outcome. For us, again, we’ve built a lot of software to do this. There are four steps to our process. The first is that we’ve built a software interface for applicants to apply online, where we can capture some structured information from them upfront, including the ability to apply to multiple jobs in parallel. We originally used a commercial applicant tracking system, but we’ve moved this to our internal tools. One of the reasons we did that is because this allowed us to do something that we couldn’t find in any of the commercial ATSs. The first step of our process when users apply is it goes to company-wide voting.

This is a heavily redacted version of the internal interface, but hopefully you can make out the idea of what’s going on here. The applicant’s resume is in the middle, we collect a little bit of other structured information. But the most important thing is on the far right, you see there’s a question: How would you vote for this candidate? Are they Known Good? Strong Yes? Yes? No? Strong No? When a person applies, the system picks out seven or eight current employees that it thinks look something like their backgrounds and it pings them all for votes. We can distribute the voting across a lot of the company for this initial review, which is essential because if you’re doing anything cool, by the time you get a couple years into it, that top of funnel is overwhelming. If you place any small group of employees or any one person in the way as a bottleneck on this, they will absolutely bottleneck the whole rest of the organization.

You also want to average over judgment. There are different people who are better or worse at hiring and have different perspectives on what you’re looking for at that stage. In the beginning, as the founder, you can meet with everybody and that will take you quite far. You should definitely interview everybody for quite a while. But even beyond that, you want ways to average over the judgment of the rest of your team. Voting mechanisms are usually a really good way to do that. These are our actual statistics over the last couple years. Seventeen percent of the top of funnel applications that we get go to a phone screen. That first initial voting stage is drawn from a company-wide pool so that we can get the voting done quickly, usually within 24 or 48 hours, and not bottleneck that on any small group of people.

The phone screen is again drawn from a company-wide pool of people. This is not team specific. This is a company-wide bar, really looking for three things: judgment, horsepower, and agency. If we throw you into a complex, vaguely defined situation, will you tend to make good decisions or will you create diplomatic incidents? Do you meet just a basic hurdle for technical competence and demonstrated ability to learn things? And are you effective at causing the world to look like you wish it were? How does your life look or not look like whatever ambitions you had? And do you have specific ambitions for your life? This we can distribute over the entire company. Then half of those tend to go to homework. Ideally, we’d be using entirely AI-resistant homeworks now. Our favorite types of homeworks are things that don’t saturate, have a very high ceiling, and are naturally scorable to two or three numbers that we can put on a plot so that when we get responses to homeworks, we can plot them all.

And then it’s very obvious when someone has really beaten the Pareto frontier, and we otherwise don’t care whatever AI models they use—that can make you better. In cases where that’s not possible for homework right now, we’re doing an increasing number of technical phone calls or onsite practical tests. But ideally, we would have an AI-resistant take-home for each of these. Anthropic had a really interesting take on the AI-resistant homework, where they’ve had a couple of tasks, like the GPU kernel optimization: what is the minimum number of cycles you can get it down to? And this is naturally adjusting. The hurdle for a while was, I think, it was Sonnet’s performance. If you could beat that, then you could get an interview. I think that there’s a bunch of ways to construct AI-resistant homeworks. And then, by the time you get to the interview, it is important that you have a, from there, reasonably high—like at least 25%—conversion to an offer, because otherwise you’re going to waste too much of your time doing onsites for employees that don’t convert. You can’t get that down.

And so there’s four steps to this: initial voting, the phone screen, homework, and a full interview. And this is, as far as from my experience, this is the minimum set of information that we need to make a full decision. And I don’t think that there’s a more efficient way to elicit this. I don’t think there’s a smaller number of steps that we could use. So this has become our process. So you’re hiring people, they’re coming into work, they’re starting, they’re incurring payroll. But how do you know that you’re good at this? Eventually, you’ll get feedback from the market on how good you are at hiring, because the company will work or it won’t. Your team will be capable of accomplishing the stuff that you’ve set out, and they’ll help you course correct through that. But this is a very, very long feedback, and it’s a very poorly behaved loss function.

And so it’s your job as management to design synthetic gradients that allow you to find out earlier and along the way how recruiting is going and if you need a course correction.

A conventional answer to this is the 360 review process. So once a year, you send out a lot of forms, you gather up a bunch of feedback around each employee. You set up a bunch of meetings with HR and with the various managers and you do the conventional performance review cycle, which, based on my experiences, is a very disruptive process that doesn’t tend to surface issues that you don’t already know about, but haven’t acted on because you knew that thing was there, but firing people is hard. So people drag their feet on it. This is kind of reinforcing things you already knew. And it only happens once a year, maybe twice a year if you split up the company into cohorts. But really what would be nice to have is a signal that gives you this kind of natural feedback from across the company about who’s good and who isn’t and what’s working and what’s not in a way that is largely unbiased and is more continuous.

Imagine if you could get feedback every few weeks on where there are issues and where things are going well. The process that I developed, which I’ve now used for the last six or seven years, is every couple of weeks, every four to six weeks—it’s not that often—people in the company get pinged with a question through the software, through Helix. There’s a form, but really there’s only one question that really matters, which is: knowing how this person turned out, would you vote again today for their hire? It’s the same question we use on the initial voting. You’ll get a prompt to say, “This person you work with, how would you vote for their hire today?” Then what we can do is construct a graph over the company of all of the feedback. The basic intuition is that your vote should be weighted more highly if everybody else has rated you highly.

The astute may notice that this looks a lot like the original Google algorithm, PageRank, which is an idea called eigenvector centrality, where you can create a weight over the graph by looking at how the graph points together. This is a little bit different than literally eigenvector centrality, but it’s very similar. We call this technique eigen reviews. I’ve become convinced that this is more or less the right way to do performance reviews. There are some other tricks that you have to apply to get this to work really well. For example, we apply dropout, where we’ll run a thousand iterations where we’ll randomly remove some percentage of the edges each iteration. When you look at the distribution of scores that you get out of that, if you see additional peaks, for example, this is a clue that there could be voting cliques that need further investigation.

But as a whole, it distributes the judgment across the company, updates more or less continuously with about a month lag, and gives you just way better insight into what’s going on really around the company.

And it also totally gets rid of that traumatic, super heavy, once-a-year, HR-driven performance review process. So the point of this talk is not that you should use this in particular, although you should consider it. And if you actually roll this out at your company, you can email me and I’ll send you a doc with more specific tricks on how to actually get this to work well. But the real theme of the talk is that rate of iteration separates success from failure. And if you can get a fast iteration loop, that really overcomes many other things you’re going to run into. And this effect is so severe. If you can learn one thing every week and there’s a competitor that’s learning a thing every month, they will never matter. Overwhelmingly, if you’re looking at two different approaches to solve a problem, if there’s one that allows you to compound in a much shorter amount of time than the other, even if the other approach has significant redeeming characteristics, you should really consider going with the shorter iteration cycle because the compounding effect is just so dramatic.

And so speed determines success and failure. And speed is determined by infrastructure. This is driven by really boring-sounding things like how well your purchasing and recruiting and spending processes work. This is as important as how well you understand the object-level technical content of the thing that you’re building. I see companies founded by stellar pedigree scientists and engineers all the time that die on the vine because this execution is tough to follow through and your job is to organize. It’s uncommon that these deep tech companies fail because the technology doesn’t work. They fail because once you end up with this organization of hundreds of people and hundreds of thousands of square feet of physical infrastructure, you haven’t built the systems to manage that and it becomes unwieldy.

And then you can’t connect strategy to execution.

So we heavily lean towards things that have shorter iteration cycles, kind of set all else equal. But that’s not a blanket rule. There are no blanket rules in startups. You’re looking at each new fact pattern that comes in as its own unique thing and then making decisions that make sense to you. And one of the harder lessons as a startup founder, one of the harder things to really deal with is the fact that you cannot delegate your judgment. As the CEO, you must always make decisions that make sense to you no matter how much momentum or inertia alternatives seem to have.

So in school, let’s say there’s somebody sitting next to you and you cheat on the test by looking over at them. All else equal, your grade will be dragged towards the average of the class. That is not good enough to succeed in startups. You have to do things that are at the long tail. The successful companies are the exceptions by becoming an average that is not good enough. And so in order to succeed, your judgment has to be differentiatedly good. Now the reality might be that you don’t know if your judgment is good yet. And so one way or another, you will have to find out. And that means making decisions that make sense to you even when you are totally alone in that realization. That is the only way to get to the really big outcomes. Now it’s not that often that everyone else will think one thing and you’ll be like, “You’re all totally wrong.” But it is a really eerie feeling. You’ll get to a point four or five years into the company when there’s hundreds of millions of dollars on the line and there’s some really high stakes decision and only you can make it.

And then you will look around for advice because in the beginning you’ll get lots of it. There are a bunch of things that are easily advised or easily figured out, but you’ll get to a key point years in and you’ll look for advice and there is nobody to ask. And at that point, you must have a really good sense of the limits and boundaries of your judgment. That is a very eerie feeling and you have to be able to commit to it regardless. Now, the good news is that in my experience, it’s very difficult to actually get stuck. You can get yourself into trouble and the action space is always larger than it appears.

No matter what happens, when you get there, I think it’s very easy to try and anticipate all kinds of problems that you’ll never actually run into. And then you go and do it and then you get to a point where the system, like you’ve run into some real limitation. There’s always a hundred ideas about how to make it better. This is sometimes phrased as action produces information. This idea is, I think, much deeper than it sounds. So in physics, there’s this quantity called action. And so if I throw a ball and it follows a parabolic trajectory, that trajectory is totally set when it leaves my hand, unless it gets blown by wind, some other action is exerted on it. It will follow this ballistic trajectory, which is in this sense kind of an information minimizing trajectory. I can say it just followed.

It was ballistic—that totally determines it. If something else happens, you had to spend some energy and time to cause that to happen. And so whenever you exert action under the universe, that creates information, in a very fundamental sense. And whenever you get stuck, you have to start injecting action, producing entropy. This produces some fairly counterintuitive effects. I’ve seen situations where the company is stuck in a deep local minimum and there’s someone who is great in many ways, but is just the wrong fit for what that company is at the time. Removing them, even though they individually are very strong, unblocks the company and allows it to enter a new phase. When you get stuck, you have to start doing things. The thing underneath the object-level content of what the product you are building is, is all these support systems.

How the company does purchasing and accounting and recruiting and performance reviews and budgeting and safety and quality is the operating system of the company. That has a huge impact on how far you can take it. Speed is determined by infrastructure. Speed determines success and failure. You need to put more thought into getting these foundations right. If you do them right at the beginning, everything else is much easier. If you get them wrong, you’ll end up spending $5 million a month and feel like you have very little control over it. Then you’re forced into coarser levers and harder decisions.

Thank you for coming to my TED Talk.

Q&A

Do you have advice for people trying to choose between industry and academia — starting a company now versus getting a PhD first?

It really depends on specifically what you’re doing. If your field only exists in basic research, then getting a PhD might be very reasonable. When things really start to work—like, if 20 years ago, the best computer scientists were at CMU and Harvard, and 50 years ago, if you wanted to work on rocket engines, you were at NASA, you were at a university, you were at University of Maryland or somewhere. Now, the best computer scientists are at Google and Apple and OpenAI. The best rocket scientists are at SpaceX and Blue Origin and others. So when a field really starts to work, industry can just marshal such larger levels of resources and can just move so much faster.

And so I think the question has been, why has academia stayed so relevant in the life sciences? The reality is that it doesn’t work that well for most things. Humans just aren’t that good at drug discovery. If your field is really only in academia, then it can make total sense to get a PhD. But I think a lot of—it is uncommon that startups don’t get the technology to work. It is more common that they can’t organize the human organizations to accomplish their goals. And that is also a skill set. The only way to learn it, I think, is an oral tradition. You have to do it. So if the choice is working at a really high-performing company adjacent to where you want to be versus getting a PhD, I’d probably recommend the company, but it’s not an absolute rule and it really depends on the field.

What counts as evidence of exceptional ability to you?

Anything you can concretely put your finger on that separates that person from their high school class. If you have your average high school student, we just want some concrete fact—ideally, the best evidence of exceptional ability is winning legible competitive games. So this could be being a chess grandmaster. It could be winning Design/Build/Fly or Formula SAE competitions. There’s a bunch of Silicon Valley deep tech companies that are basically built out of Formula SAE winners from college—people that just spent their college experience building things and racing them and finding out. I think you have to have that type of competitive feedback. It is tough to know if you’re exceptional without having some legible competitive game.

How do we hire engineers now? Do we still use LeetCode, or do we have better ways? If we allow AI use, how do you understand the skills of the applicant?

I don’t think we’ve ever really used LeetCode. Maybe some other people on the team do it in secret, but I’ve never asked it. So software in particular, the rewards to horsepower are so great that it really is just—it’s a field that attracts really smart people because it gives you this very rapid feedback. There are a lot of really smart people in biology, but when you have a biological idea, it can take you many months to find out if it’s a good one. In software, if you have an idea, you can often build it in a couple hours or you can get feedback within days. So it has this really addictive feedback loop, kind of like high-frequency trading, that just draws in really smart people.

And so we look for, over your life, what signals do we have that you have done something interesting? It’s uncommon for someone to get into their mid-20s without there being some thing in their background that they went out and sought out and did.

But this is such an open-ended criterion. It can really be anything. More directly to the question, we increasingly don’t directly evaluate programming. We try to evaluate thinking. So these are design questions. If we give you a domain, how do you break it down? Can you understand the decomposition of the problem clearly? It’s really a measure of, can you think clearly rather than can you write code?

What did you take away from your experience at Neuralink?

So the question of, should you go get a PhD? I don’t have a PhD. I spent five years running a company for my CEO at Neuralink. That was—one of the biggest lessons, I think, is that there are few really generic answers.

There’s no generic algorithm for how to succeed at a startup. There’s no set of five bullet points that can be conveyed that, if you just turn the crank, your company will be successful. It’s a long series of judgment calls. And so the most important thing is that those filters are tuned really well. I think one of the most valuable things for me at Neuralink was I was working with someone who has empirically excellent judgment. We could get into trouble together and something would happen and there’d be two possible solutions that would make sense. I’d go to him and say, “Is it option A or is it option B?” He’d look at it and be like, “Oh, it’s definitely option B. The problem would never recur.” Having been in those situations where I was trying to make these bets with stakes attached, looking forward in time, not getting feedback until later, with that advice was incredibly useful for fitting those filters.

I don’t know that there was really a shortcut. I think that just hearing the stories when you’re not there, really thinking about it because there are real stakes, and then getting that feedback—that is an essential part of the education of an entrepreneur that I think many people underwrite. I think it is really worth working for a company that has an excellent culture that you respect before jumping right into your own startup. It is relatively uncommon that startup cultures get rediscovered entirely from first principles. Usually they’re passed down as oral traditions because there’s a founding team that worked at another company, which worked at another company, and so they inherited it. Or in some cases where there’s really a breakout, where there’s just some market dislocation that really enables a team out of nowhere to build it. They’ll often get it from the VCs, but it’s working with the people that have that judgment so that you can get that reinforcement learning as it’s a long series of facts that is really important.

Could BCIs or neural interfaces help us figure out what consciousness actually is? How?

Absolutely. So if the end of the artificial intelligence quest is super intelligent machines, I think the end of the BCI quest is conscious machines. The brain is composed of ordinary matter arranged according to the rules of chemistry, only things found on the periodic table. It seems tough to believe that there’s some new physics going on in there. And so we’re looking for some mapping between the substrate activity and the phenomenal content. Now, if we had a magical BCI that allowed me to see the instant state of every neuron in the brain and drive them, I think we’d figure out consciousness pretty fast. I think this is a practical problem, not a philosophical problem.

But to prove it—first of all, that practical problem is real and we’ll have to do this stuff in humans. And to prove any of this, we’ll have to do it in humans. I think that it is possible that you could use a BCI to prove it. We have some ideas about how to do those experiments, but they’re still some number of years off. Things going into humans now are not designed to study consciousness. But I do think that that is further down this path.

What should I study to contribute to BCIs?

This really depends on your background. Neural interfaces are a very interdisciplinary problem. It uses everything from stem cell biology to materials and microfabrication, to software, to animal behavior, to surgery. So there are many different entry points in it.

One of the things that we found is that it’s better to have a smaller team that can fit more of the problem in their heads and then compress it together. Contrast this to how academia usually handles interdisciplinary problems, where they’ll have an interdisciplinary center that pulls in very deep verticalized experts who kind of meet at the center. The problem is that they’re all speaking different languages. And so it’s often hard to really—even when they can communicate, typically you end up shipping the interfaces of those departments. Whereas for us, if we can hold the problem in the head of a smaller number of people, we can shift around where the bottlenecks are.

A specific example of this is our protein engineering group has been able to develop much more sensitive, much better proteins for some things that we need to do, which has allowed us to relax some electronics requirements. Specifically, we have proteins called opsins. They allow us to make neurons light sensitive so that if we shine light on them, we can fire a neuron. The problem was that you needed to hit a neuron with a lot of light to fire it, which means that you can’t have that many light sources because it gets too hot. We’ve been able to make the protein more sensitive, which means that we can have more LEDs because each one can be dimmer. We’ve turned this electronics problem into a biology problem that allowed us to relax those constraints. You don’t get that as much when you have these interdisciplinary centers where there’s one group focused on one thing, and another group focused on another thing.

I would say being able to have a broader perspective of more of the problem is really valuable. And then just really as deep and clear an understanding of the system as you can get. I think there’s no substitute for being hands on. It doesn’t really matter. You want some hard skill to get you in the door—software, electronics, mechanical, materials, something. And then from there, I would try to learn as much of it as you can.

What doesn’t AI replace in scientific research? Where are humans still necessary, if anywhere?

We still definitely need humans. And in scientific research in particular, it’s tough to predict. AI is clearly advancing very rapidly. I do think that you need to think about how to have your company be AI native in the sense that you want to gather all of the context, all of the stuff happening in your company, and be able to make that available efficiently to agents because those are clearly a big part of the future. For us in Helix, really everything goes in there. One of the reasons that we did that was because not just is it powerful to have everything in one database to link together—purchasing to quality, to batch records and manufacturing—so that we can trace stuff more efficiently, but also so that we could give it all to agents.

We found them to be a multiplier for the team, not a replacement.

The three biggest areas that AI has had an impact for us so far are, well, first of all, coding. That’s now basically all this. I’ve written a lot of code in my life. I don’t think I’ve looked at the source very much in the last six months. That is getting really good. Regulations. So if you’re doing anything really interesting, you’re going to end up regulated and then you’ll probably end up dealing with these things called quality systems. A quality system, I think, triggers a lot of scar tissue for people because it’s just the quintessential heavy bureaucracy that slows everything down. But the idea of quality itself is actually not a problem. The problem is that humans are bad at reading and interpreting these things. And so when we make a product, one of the things we have to do is identify all of the standards that might apply.

And there are standards for everything. There are standards for how the lithium-ion batteries plug into a PCB. There are standards for electrical insulation of the boards. There are standards for shipping labels. At some point, you’ll have to take your shipping packaging, print a label on it, and put it in a vibe box and show that the corners of the label don’t curl in a way that might cause it to detach. And so you hire regulatory experts to go find all of the standards that might apply, make a list of them, and then have a spreadsheet, which is all of the evidence that you comply with all of the standards. So this thing can take many, many months historically. AI has totally transformed it. We can very quickly look up all the standards. We can very quickly generate the evidence tables. And I think that to the degree that there’s kind of over—

We definitely need to deregulate some things, but I think that the combination of AI and regulation is a better fit than people think. You can use it to smooth a lot of stuff where the regulations are written in blood and are largely good ideas. It’s just hard for humans to do it.

Why build your own infrastructure platforms rather than just buying them?

You can’t really buy these things. There are ERP systems out there, but there’s no company that loves their ERP system. I don’t know if there’s anyone who’s really like, “I want to spend more time in NetSuite.” On the contrary, there are a bunch of examples now of companies that grow up around a piece of software that’s really fit just for them. YC famously has a lot of internal software that really makes YC work. Facebook also very famously invested heavily in internal tools and now gets a lot of efficiency from that. SpaceX and Tesla internally have a pretty giant piece of software called Warp Speed that runs a lot of their manufacturing and R&D processes. So when one company grows up around a harness fit to it, it can be very powerful.

It is powerful in a way that the software you can buy isn’t. But this requires you to really look into the future because, certainly, especially at the seed stage, this is not the thing that you would think you should be focusing on. And historically, it has not been. I think this is a thing that has changed with agents. The fact that you can vibe code this now makes it a reasonable thing to think about. Historically, software has been so expensive, you would have had to buy it. And that’s what everybody did for a long time. That was, I think, a worse world, and that world has changed. And so now there are better options available. But like I said, we previously had used— we used Greenhouse. Greenhouse required us to have a small number of people as a bottleneck at that first funnel stage.

Replacing that with software, we were able to explore voting mechanisms and fairly detailed voting mechanisms that can make smart inferences about who would know about an applicant—things that you can’t really do with the commercial software. And so for a lot of these processes, you should think about how you want it to work for you.

These are human organizations, these human processes that have to be staffed. And if they aren’t done routinely, they’ll atrophy. And there are things that make sense for different teams and founders in the way that they view the world and think about it. It really is all very different. But if you build a thing that works for you and then you bake that into the company so when you put something there, it stays there, it can be very, very useful.

What changes should we expect in the world as BCIs start to work and get widely adopted? Do intelligence differences no longer matter?

So there’s this meme that BCI is an artificial intelligence-adjacent story. And there’s some of that. Eventually, if AI is building super intelligent machines and the BCI labs are building conscious machines and we’re building brain-to-brain connections so that the boundaries between those things become less meaningful. At some point, you want a super intelligent conscious machine that we can participate in, but that actually feels further away to me. I think in the near term, BCI is really a longevity story. And I view longevity as really just healthcare. Just biotech. It’s just that it hasn’t— I think it is not right to say that the pharma companies or any of these past healthcare companies are not interested in cures. I think that is what all of them want. It’s just that that’s been beyond our capabilities. And in neural engineering, when people hear BCI, I think they think of motor decoding.

I put some electrodes in motor cortex and now they can control it like a video game. I think neural engineering is much broader than that. We include our retinal prosthesis in that. We include cochlear implants in that. And this, I think, is a contrarian take on all of healthcare. It gives you these effect sizes that you just don’t really see in medicine. If you have a patient on a dopaminergic drug for Parkinson’s, that works for some period of time, but it’s a relatively small effect after a little while. You try on a deep brain stimulator and a patient goes from not being able to hold a cup of water to being able to write cursive in 10 seconds.

If you want to talk about strong patient testimonials, you should see a newborn having their cochlear implant turned on. When you deal directly with the brain as a computer, not only do you not have to solve some of these really hard biology problems that are just beyond humanity’s capabilities, but you get these results pretty readily that, again, are just like you can get an engineering gradient, you can get them more reliably, and they’re just large effects. And so I see this as a way to extend and improve the life of everybody. The brain is the thing that makes you you. It’s the only thing that in principle you can’t transplant. You can get a new heart or a new liver. You cannot even in principle get a new brain. And the brain is usually not the thing that fails. And so if you can deal with the brain directly, I think this is more of a radical longevity story than it is an AI one for the moment, although all of these things will come together over some period of time.

For your Eigen Review performance system, how do you prevent employees from colluding on their votes or downvoting somebody on purpose?

So as I mentioned, there are some tricks. For example, applying Markov chain Monte Carlo dropout allows us to detect things like voting cliques because now instead of seeing one peak, you’ll see two peaks. That is a clue to look in. I look into that. It’s designed to be tolerant of these things. I think it is really fairly transparent. It’s also not our only signal. It’s one of several. If anybody’s interested in this, send me an email and I will share a document with the specific tricks, but I want to understand a little more about how you were going to deploy it first. Some of this is tradecraft.

When you’re building something as long horizon as neurotech, how do you figure out how much runway you actually need to keep the company alive? And how do you get investors to fund that much?

Sometimes you see founders, especially more inexperienced ones, pitching VCs for what they think is reasonable to ask for rather than what they need to run the experiment. You’re raising some amount of money to go find out some answer. The answer to that might be no; the investors understand this depending on what business you’re in. But you have to actually run the experiment.

There are definitely some ideas that are worth funding with $50 million or $0, but not $5 million. You won’t run the experiment. It’ll be a really frustrating experience. You’ll get an ambiguous outcome. My first piece of advice is you should figure out what you think it’s going to take to actually run the experiment, which is not the whole company. That is your next value inflection point. No matter how ambitious and open-ended your plan is, you should have some sense of what is your next key value inflection point. What are the experiments that need to go into that? Price that out and then raise twice the money. There’s some amount of waste. I think if you can get waste down to 20 or 30%, that’s pretty good. Anyway, the advice is figure out what it costs to actually run the experiment.

Raise twice that and raise that or not. Beyond that, you’ll always discover new things. There’s usually some path through the mess. But when you start the company, you’re not going to get a guarantee that you won’t be on a bridge to nowhere or that it will work on the funding that you have. You’re going to have to get in there and figure it out halfway through. I think that people should push for profitability sooner than they often think that they need to. For us, even though we are seen as this very open-ended, deep tech company with a very long roadmap, which is true, we are also relentlessly focused on revenue at this point. We are trying to get to sustainability. It feels like the company is kind of constantly dying slowly of this money cancer that we can beat into remission every couple years with the fundraising, but then it eventually comes back and I want that feeling to be over.

No matter how big of a problem or big of a vision it feels, you do need to think about how do you get to revenue so that not just you can do it forever, but then you’ll be valued on your long-term roadmap, not valued on your probability of dying. It really opens up another set of investors that wouldn’t be relevant otherwise.

What is the best piece of advice you’ve received?

I don’t know. I’ve acquired way too much brain damage over the last 20 years to have a memory capable of picking that out. Other than speed being the basis of success and infrastructure determining your speed, it is important to appreciate that there are no general principles. People are looking for shortcuts. People are looking for a pithy set of instructions that are like, “Oh, I figured it out.” And that doesn’t exist. Every one of these things is different. When you get to that moment in history, you’re doing something new. We can reflect for a second on how crazy it is that this is possible. For the vast majority of human history, if you were a smart 20-year-old who had an idea to make your society better and you raised this to the people with capital, the reaction was, “You should pay attention to the harvest.”

The fact that it is not widely available—it’s not universally available—but it’s now widely available that if you’re a really smart 20-year-old, you can come to San Francisco and make the case. And if it’s an interesting idea, you’ll get millions of dollars to find out. This is not the case for most of the world today. And it’s certainly not the case for most of history anywhere.

But that shouldn’t feel normal. This is given to push the frontier out. And when you’re on the frontier, you’re figuring it out as you go. That is the job. So I would try to rely less on things that feel like startup advice and more on how good your judgment is. How well is that refined in your domain? And remembering that you have to think for yourself.

What are some of the hardest remaining engineering challenges involved in getting BCIs to work?

So in BCIs, we often feel very limited by power and thermal constraints on the implants. This creates a strong pressure to implant as little as possible and do the rest off the body. You can’t pass a wire through the skin because the skin is a very important immune barrier. The skin won’t fully heal around it. If you have any connector through the scalp, you’re constantly at risk of a bacteria crawling down that and into the brain, and then the patient’s going to have a really bad time.

And so you really have to be able to close the skin. That requires you to have implanted a radio or transceiver of some sort. Getting the power on that down—there’s a frontier at low power electronics, which is really important. As I mentioned earlier, a lot of this is now becoming increasingly biology as our biological engineering capabilities increase. But then on those implants, ironically, one of the harder, more open problems is what we call packaging. Our colleagues in Europe call it tropicalization. This is your ability to keep your device in and the body out of an implant that you put in the body. There are no truly passive surfaces anywhere in the body. Even bone is constantly getting remolded. So if I put a device in, it’s going to be attacked by the body and it’s not regenerating itself.

You need a material that is going to survive that for an extended period of time. The classic example of this is the laser welded titanium can, which, if you’ve seen a pacemaker or a deep brain stimulator, they’ve got this big titanium box. Obviously, we can’t put a big titanium box in the eye. Interestingly, one of the earlier retinal prostheses before us, about 10 years ago, was a device that did have a titanium box that they attached to the eyeball. It was a four and a half hour surgery. They had a little belt that went around the eyeball with a little titanium box on the side of the eye with a battery and a little PCB. This didn’t work. This was not good enough. They needed to get rid of that somehow. In our case, we’ve solved this with the laser projection trick where we power it wirelessly.

But having this next generation packaging—some type of conformal coating that we can use to protect the implant that is not degraded by the body, is also not harmful to the body, and is resistant to all of the ways that the body will try and kill it—that material science is a very open-ended field. If you’re interested in material science, that is a thing that we need progress in.

How did you approach interacting with the medical field to build your retinal implant?

Business is just a fancy word for talking to people and doing things. You talk to them, you send them emails. For our retinal implant, it was originally invented by a professor at Stanford almost 15 years ago, I think. It was licensed to a European company that we were tracking. Let me back up a second. When we started the company, I came from Neuralink. Four of my five co-founders came from Neuralink. We took a look around the world in early 2021 and asked what is the most valuable thing that we can do that would be likely to work in the near future, that may have a big impact to patients and allow us to be the foundation for the type of scalable medical device company that we wanted to build.

And we came to the conclusion that restoring vision to the blind by stimulating the retina was the thing. In that, you have a choice of two types of cells in the retina that you can stimulate: these things called bipolar cells or the optic nerve. And you could do that electrically or you could do that optically. We explored all four quadrants of that. We developed internally a state-of-the-art gene therapy that optically stimulated one of those cells. And we identified this French company as being the state of the art in electrical stimulation. It’s a small community. You can meet people, you can talk to them.

It eventually made sense for us to acquire them. We ended up with the license to the technology, and we work with surgeons and doctors all the time. If there’s a new surgery that you want to figure out, typically this is best going through networks so that people are more likely to respond to your email. But we cold email surgeons all the time saying, “Hey, we have a weird surgery to develop. Do you want to be a consultant?” And people reply. Before I get to the next question, there is a real cultural thing here. In my time hanging out around the periphery of SpaceX, I observed that at least circa seven or eight years ago, probably like 20% of that company is what you might characterize as committed Martian colonists, and 80% are serious engineers. I think that those people are lunatics and they just want to work on the highest performance methalox engines in the world.

And you need both of those cultures to be really successful long term. And that’s especially tricky in medicine, because that’s a very, very conservative, arguably very authoritarian culture for the most part. Similarly, at our company, we have, I’d say, 30%—I mean, it’s an overtly transhumanist mission—and then 70% serious clinicians and scientists and researchers and people who think that those guys are crazy, but we’re going to build some really valuable medical devices for critical unmet needs in the process. I think one of the things that makes Science, the company, very special is that it has both of those cultures and is able to integrate them. We’re able to simultaneously do some really cool research that I think is really at the edge of the Overton window, while simultaneously running clinical trials in six countries, now with an approved medical device in Europe and clinical trial results in the New England Journal of Medicine.

You have to be able to navigate both of those things, I think, to really reshape the future.

Has biotech gotten easier to break into for earlier-stage founders?

Biotech remains capital intensive. I don’t know that I’d recommend biotech if you have a choice of other stuff to do. For me, I realized almost 30 years ago that if you could alter the brain, you could alter reality. This was one of the biggest missions of the next 30 or 40 years—building these things. Every now and then, I think my life would be way easier if I had just gone into AI instead of BCI, but somebody has to do it. I think it’s important to—

Biotech is hard. It is a much harder path than many other things you can do, but when you’re successful, it has an impact that you don’t really see elsewhere. Increasingly, there’s—Paul Graham wrote a long time ago that you get vibes in different cities: the vibe in Cambridge, Massachusetts is you should be smarter; the vibe in New York is you should be wealthier; the vibe in San Francisco is you should be more powerful. Especially with the rise of things like artificial intelligence, I think people realize that this isn’t just about money. For many of the most effective startup founders, it’s not about the money. It’s about changing something. There’s some way in which you want the world to be different. It just turns out that for that project, the for-profit company is an incredibly powerful way to marshal the resources required to cause the world to be different in that way.

This is not about money; this is about power. There are many different types of power. There’s economic power, there’s military power, but the power to heal the sick is a very dramatic one. When you get that, not only is that a real force to reshape the world, it’s one that can be shared very readily. You can’t share military power or economic power, but you can share the power of restoring sight to the blind or giving life to the cancer patient. The world is getting more complicated, and there are big impacts from all the things being worked on by the people in this room. Biotech is hard. It’s very capital intensive. It’s a long road. When you start a company in this space, you’re committing to a decade of your life that you will never get back, no matter how it turns out.

But the results of that, when it works—the impact that this has on patients and their families—is really unlike any other sector.

What’s a popular belief in tech that you think is wrong?

And I don’t even know what the popular beliefs in tech are now. Well, okay. Even the whole basis of building Helix is contrarian. I think that if you raise a Series A and then you tell your investors that you’re going to vibe code a purchasing system, I think that any reasonable board is going to ask you what you’re thinking. And we were able to do that because I never got those questions, because I control the company. But that’s one narrow example, I guess.

All right. Thank you.

The next generation of startups will be built by smaller teams than ever before.

At Startup School 2026, YC President & CEO Garry Tan explains why we’re entering the era of personal AGI: AI agents that run on your own infrastructure, compound your knowledge over time, and dramatically increase your ability to build. He shares the tools and workflows he uses every day, why every founder should own their intelligence instead of renting it, and what it means to build under your own power.

Watch on YouTube

Timestamps

00:07 — What Founders Can Learn From Spinoza
04:46 — Personal AGI Is Already Here
07:57 — Why AI Makes One Person More Powerful Than Ever
12:29 — Your Life Is a Library
15:15 — Inside My Personal AI System
17:06 — Markdown Is Code
18:20 — Latent Space vs. Deterministic Code
21:13 — Building a Company of One
24:16 — How to Build Your Own Personal AGI
27:58 — Why Most People Will Quit Too Soon
29:09 — Own Your Skills Before Someone Else Does
32:24 — Personal AGI Means Owning Your Intelligence
35:21 — Why I Open Sourced Everything
38:30 — A Personal AGI for One Small Boy
40:18 — It's All Made Up. You Get to Make It Up.

Transcript

The internet calls me one of the most AI psychotic people online. So it’s only right that I start my talk with a story about one of the most canceled men in history. His name was Baruch Spinoza. And in case the philosophy elective wasn’t your thing, here are the highlights you need to know.

In 1929, a New York rabbi challenged Einstein by telegram: Do you believe in God? Answer in 50 words. Einstein answered in 25: I believe in Spinoza’s God who reveals himself in the lawful harmony of the world, not in a God who concerns himself with the fate and doings of mankind. The most famous scientist alive asks the biggest question there is, pointed at Spinoza. But here’s what Baruch Spinoza’s own community did to him.

Amsterdam, July 27th, 1656. Spinoza is 23 years old, a member of a tight-knit Sephardic Jewish community. He stands in a synagogue while the elders excommunicate him with the most violent curse the community ever produced. “Cursed be he by day and cursed be he by night. Cursed be he when he lies down. And cursed be he when he rises up.” Nobody may speak to him. Nobody may trade with him. Nobody may come within four cubits of him. Nobody may read anything he writes. And this ban, uniquely among the roughly 40 bans Spinoza’s community issued that century, has no repentance clause. It has never been lifted. It technically is still in force today.

Spinoza was 23. His crime was evil opinions, expressing forbidden thoughts. His punishment was complete deletion from the community. Before his community cursed him, they tried to buy him—a thousand guilders a year, serious money. All he had to do was show up at synagogue once in a while and keep his mouth shut. Hear that in founder terms. They’ve offered him a salary to stop building. He said no, not for 10,000, he said. He wanted truth, not comfort. Shortly before his excommunication, a fanatic came at him with a knife. The blade tore through his cloak and missed him. He kept that cloak, scar unmended, for the rest of his life. He wanted to remember what ideas cost. So what does the most canceled man of the 17th century do next? He grinds lenses. By day, he makes optical instruments, tools that let human beings see further than their eyes allow.

He makes them so well that the best scientists in Europe seek them out. And by night, he writes a book so dangerous he cannot publish it while he is alive.

When he dies at 44, lungs full of glass dust from making other people’s lenses, the manuscript is locked in his writing desk. His dying instruction: ship the desk by canal barge to his publisher in Amsterdam. That manuscript became his posthumous works, which attracted immediate attention across Europe and inspired some of the most important philosophers of the Enlightenment. “What does Spinoza have to do with startups?” you might ask. Well, here is a man canceled by everyone he knew, offered a salary to stop, nearly killed for shipping. And his response was to build precision tools by day and write the most dangerous book in Europe by night, alone, with no permission from anybody. If you’re going to start a startup, you could do well to learn from Spinoza. He had a name for the engine that kept him going—conatus. It means your striving. The drive in every living thing to keep going and to increase its power to act.

Not your resume, not your title, not your job, the striving itself. This talk is about the tools that amplify it. So what did he actually say that was worth deleting a man over? The gist of the heresy was that God is not a king on a throne. God is spread through everything that exists. God or nature, he wrote. Four hundred years later, we are making a similar mistake about intelligence. Everyone is waiting for AGI as a singular event. A God in a data center. Some announcement, some threshold, some day when the sky changes color. So now I’ll say a version of Spinoza’s heresy updated four hundred years later. Everyone is watching the sky and the thing they’re watching for is already in the room. It doesn’t look like a God. It looks like infrastructure, a terminal window, a folder of markdown files, a job that finishes while you sleep, spread through everything, which is exactly where Spinoza told you to look.

AGI isn’t arriving as an event. It’s arriving diffused as your agent running on your context doing your work. I call it personal AGI, not artificial general intelligence for everyone all at once. General intelligence for one person, you. This was a dream of a great many people. Vannevar Bush called it the Memex, a machine that would be an extension of yourself and your brain. And I want to be precise about what I mean because the words personal AI have already been captured by marketing departments. I do not mean a chatbot you pay $20 a month to. I do not mean a slightly better autocomplete. I do not mean an assistant that knows your calendar and nothing else. That’s just a subscription you rent. It’s a corporate AGI you don’t own. It resets when you close the tab. It knows what everyone else already knows. And when the company behind it pivots, your so-called assistant gets a lobotomy on someone else’s schedule.

Personal AGI is a different animal. An agent that runs on your infrastructure, reads from a memory you own, executes procedures you wrote, and compounds. The corporate AGI you don’t own gets better only when the company ships something. Your personal AGI gets better every single day you use it because every day it knows more of your life. One of these is a product you consume. The other is an asset you build. Almost nobody in the world has this second thing yet, and everyone in this arena could have it by Monday. And I believe intelligence—intelligence of this kind—should be owned by you, not rented. If you go forth and build this for yourself, 2034 doesn’t have to be like 1984.

You might ask why this personal AGI is happening only now. Well, I think it’s because of what agents can do, and nowhere is it more obvious than in coding agents. In 2013, I was a YC partner building Bookface, our internal social network, at night. I shipped maybe 14 useful lines of code a day, which, if you know the literature on programmer productivity, is dead-on median. That was me at full effort. This year I run YC full-time, same brain, same hours, plus a five o’clock kid pickup. I did the math on my output and I’m at about 400X what I did in 2013. Now, before the skeptic in row three deflates that number for me, let me deflate that for myself. You don’t trust the raw lines of code? Fine. Apply the most pathological verbosity penalty you can stomach and assume the agent writes bloated code.

Assume half of it is scaffolding. Assume I’m flattering myself, which is always a live possibility. It’s still 8X at the absolute floor and 10 times that in the middle of the range. The number is large no matter how you torture it. Now, this is just code. And if you’re at the beginning of your career, you’re in luck. This applies to design. This applies to product management. This applies to growth. This applies to every part of what you might want to do. The multiplier for coding is not just for coding. It’s for every piece of knowledge work. And it’s not just me. At YC, we get to watch this at portfolio scale. A year and a half ago, in the Winter ‘25 batch, a quarter of the companies had codebases that were 95% AI-generated. Those companies use AI agents for everything now, not just code. And that batch is on track to becoming one of the fastest growing, most profitable batches in the history of YC.

Now I know what a correlation is, so let me say it carefully. I cannot prove that the AI-generated code and everything else caused the growth, but what I can tell you is that the fastest growing founders we fund are not treating AI as autocomplete. They are treating it as a workforce. There are 2X people and there are 100X people who are using the same Claude, same weights, same context window size, same API, but the leverage is not in the weights. It’s in what context you give it, how relevant it is, and does it happen at the right step? We’ll come back to this.

Now, Spinoza has a definition I think about every single week. In Ethics, he defines joy as the feeling of your power of acting increasing, which is why the first time an agent does a week of your work in an afternoon, it doesn’t feel like a convenience.

It feels like joy. And that’s not me being poetic. That’s the technical term. Your power of acting increased. Your conatus just got bigger. He defined the opposite too, by the way—sadness, the feeling of your power of acting decreasing. If your Sunday nights have a specific heaviness, like your ability to influence the world is receding, that you feel like you’re quiet-quitting, then this is what you feel. And hold that thought because we’re coming back to this in the second half of this talk and it gets political.

So here’s the equation for the next decade of your life. A frontier model, which is rented and a commodity and getting cheaper by the quarter. Plus your context, which is owned by you and unique. And ideally nobody else on this earth has it. Plus a harness that wires them together. That harness might be OpenClaw, Hermes Agent, Claude Code, or Codex.

Add that up, and that gives you an agent that acts like a very fast version of you. Model quality is rented, but your brain is owned—ideally by you. Marshall McLuhan said that technology is an extension of man. Steve Jobs called a computer a bicycle for the mind. And if you have what I’m describing here, then you have a self-driving rocket.

Paul Graham taught every founder in this building two things. Make something people want and do things that don’t scale. Both still govern everything. What’s new is the multiplier on the second one. Agents are how one founder now does unscalable things at scale. The advice didn’t change, but the physics of all startups and of what you can do did.

Spinoza ground lenses—tools to let people see past the limits of their eyes. I want to spend the next 15 minutes showing you what grinding lenses for the mind looks like. This is the machinery I actually run my life on, and every concept travels to whatever stack you use.

Let’s start with working memory because it explains everything. You and I, as human beings, hold about seven things in our head at once—seven plus or minus two. It’s the most famous paper in cognitive psychology. It’s why local phone numbers are seven digits and why you forget the eighth item on a grocery list. That is the entire working memory of a human being. And every institution humanity has ever built—every checklist, every org chart, every filing cabinet, every standup meeting—is a prosthetic for that limit. An AI agent, though, holds a million tokens. That’s about a thousand pages.

Three Harry Potter books sitting open on its head all at once. And it can find a needle in any of them and synthesize across all three in seconds. Three Harry Potter books versus seven digits. You could argue that’s not quite AGI yet, but it is already a different operating regime. And almost everyone on earth is still running their life on an org chart and a way of doing things designed for the seven-digit brain.

Run that number in the other direction. A thousand pages is a lot, but it is also very little. Your life is not three books. Your life is a library. Every email you ever sent, every meeting, every decision, and every reason behind it, every conversation with every person you know. The question that determines whether your agent is a genius or a goldfish is this: Who decides, or what decides, which three books are open on the desk? And that’s what a brain is. That’s what GBrain is meant to be. The library plus the librarian. I’ve been building GBrain in the open. My personal OpenClaw has a Karpathy-style knowledge wiki with about 220,000 markdown pages. Twenty-five years of my life diarized. Every email, every meeting, my notes, my photos, my drafts, the things I got wrong. Compiled mostly by agents, curated by agents, searched for by agents, but I never re-ask a question I already answered.

And the lived experience in the system is the point. A founder emails me about a crisis. Before I finish reading the email, my agent has already pulled every prior conversation I’ve had with that founder. Three portfolio companies that hit the same wall, and what actually worked for them? When my agent does anything, it does so knowing everything I know. And that’s the difference between an assistant and a colleague. Let me walk you through an actual day because that matters more than an architecture diagram. While I slept last night, my agent processed my inbox. Not sorted it—processed it. It knows which emails are from founders in trouble, which are from people trying to sell me something, and which are from the 17 mailing lists I never quite unsubscribe from. The ones that matter are triaged with context pulled from the library: who this person is, my whole history with them, what they’re really asking under what they wrote, and what that might mean for me.

I wake up to a briefing, not a pile of emails. Before every meeting, a prep doc: who I’m meeting, what we said last time, what changed since, and what I should ask. Research I was curious about at midnight is finished by morning. And when something interesting happens in the world, my agent has usually read it, cross-referenced it against what I care about, and filed it before I’ve had coffee. On top of this library sits my agentic coding framework, GStack—123,000 stars now—which puts it in the top hundred open source projects in the history of GitHub. And what’s actually in the punchline of this full architecture? It’s mostly skill files plus a browser that the agents can drive. Pages of English and a way to act on the world. Markdown, not magic. Fat skills, thin harness. Let me show you what a skill file is because I keep saying this phrase and I want you to see how unmagical it is.

Here’s a real one, lightly redacted. It says: when a meeting recording lands from Circleback, transcribe it with speaker labels. Pull out the commitment made, who made it, and the deadline. Cross-check every person named against the library and link their pages. File the summary here, full transcript there. If anything contradicts something we already believe, flag it. Don’t override it. That’s it. That’s a skill. It’s a page of English. A smart intern—anyone, really, who could read—could follow it. And that’s the test, actually. If a smart intern could follow it, an agent can run it. Which means actually a kind of profound thing. I know I caught a lot of flack for talking about this, but I think it’s more true than ever, especially now. Markdown is actually code. If you can write clear instructions in English, you’re a programmer. The compiler is a language model, and that’s why it’s not just for engineers anymore.

At YC, our media people, events staff, finance team—people who have never opened a terminal in their lives—are building skill files and scheduled jobs. One of our finance folks compiled about a hundred Excel workbooks into a single app she built with an internal agent. She’s not a programmer. She’s a manager of agents now. Everyone is about to be.

The most important question to ask here is: where is the computation happening? And there are exactly two answers, and confusing them causes every agent failure I’ve ever seen. Some computation belongs in latent space: taste, judgment, reading what a human actually wants from a vague request. That lives in the model, and you steer it with a markdown file. And then some computation belongs in deterministic space: the arithmetic, the SQL query. For instance, the seating chart for what sessions you’re going to go to today for your breakouts. All of that needs to be stored in a SQL database used by the markdown files. Being smart about this goes a long way. Ask an agent or human to seat five people around a table. That’s easy. Do it in latent space. Ask it to make custom schedules for 6,000 people in an arena like we just did for you, and your latent space agent needs to write some code to keep track of it.

Your experience at this conference had to be markdown files calling code in exactly this way. And you couldn’t do it without the code. The model fails where we fail. The fix is having the model compute the way humans compute: the latent and the deterministic, markdown files calling databases and scripts. Simple, but it’s what everything is actually built on. And I’ll give you one more receipt. My favorite one, because you’re sitting inside it right now. Five days ago, I decided this talk needed Spinoza, one of my favorite philosophers, especially because of how canceled he got. So my agent went and acquired three of the best biographies about the man—books by Nadler, Goldstein, and Stewart, about 1,500 pages. It read all three. It built me a synthesis, a dated chronology of his life, every place the three biographers disagree with each other, and the best verbatim quotes with chapter citations.

And because it knows what I need: the 10 most tellable moments of his life, ranked with delivery notes. The knife attack, the bribe, the desk. Every beat of our opening that might’ve given you some chills 20 minutes ago came out of that overnight run. 1,500 pages became a stage-ready story that I could edit. I call it a compendium skill, and I use it daily. It’s a personal skill that is a mega, mega version of deep research—only deeper than anything the corporate AI products will give you. The spine of this talk you’re watching was inspired by the machine we’re describing now. And if you’re wondering where mine actually started, it was not 220,000 pages. It was a folder. It was a few markdown files about the companies I was working with and the people I kept emailing. And the library got big the same way anything gets big.

A little every day compounding with agents doing the filing. Nobody builds the warehouse first. First, you build one shelf. When you sit down with an agent tonight, you’re not coding. You’re managing a workforce made of markdown. A skill file as an employee. It has one capability, one job written down clearly enough that someone new could execute it. A resolver is an org chart. A task comes in and it decides which markdown file or who handles it, which means that before you ever incorporate anything, before you have a co-founder or a logo or a deck, you can already be running an organization. An organization of one plus your agents. You are the founder and the entire management layer of you incorporated and the headcount under you is now whatever you decide it is. This already produces companies that break the old math. Emergent out of our Summer ‘24 batch went from public launch to nine figures of revenue in eight months.

When they crossed $15 million in annualized revenue, they were 15 people. Retell, Winter ‘24, hit $60 million annualized with about 40. That revenue per person did not exist before. Not in software, not in oil, not in railroads. And these aren’t freaks of nature. They’re the first companies built natively on the new physics, and every one of them started as one or two people wired the way I just described. Now picture our batch room in the Dogpatch, hundreds of founders every single day, each one of them doing what used to be a person’s entire year of work. That is not the future. That is the bar right now with this batch. If you’re not doing it, your competitor is, and they will eat your lunch politely and thank you for it. It also changes what software even is. Software doesn’t have to be precious anymore.

You can build exactly the tool you need for the audience of one in a weekend. The old advice was scratch your own itch and hope it’s a market. The new version is much better. Scratch your own itch because scratching itches is nearly free. And some of your tools for one will turn out to be entire companies. You’ll know because other people start begging for them. And one honest caveat before the how-to, because you catch me out in any way. A brain nobody curates is a garbage dump with great search. Retrieval will surface a stale fact with total confidence. A bad skill file encodes a bad process forever. So the primitive is memory plus hygiene. Provenance on every fact. Contradiction checks when new information collides with old. And a librarian whose actual job is pruning. Treat the brain like production infrastructure and it compounds. Treat it like a dumping ground, and you get a very confident agent that is wrong in ways nobody can trace.

Everything so far is philosophy and receipts. So let’s get into some how-to. If you do what I describe in the next six minutes, you’ll be ahead of 99% of people who watch this talk and just nodded. Step one tonight, pick a harness and run an agent on your own machine. I use OpenClaw and Hermes Agent with GBrain. A hosted version of this is at gbrain.io. It’s free. GBrain itself is free and open source. I always recommend the Ferrari, but I’ll be honest, the Honda is really good too. Codex, Claude Code, whatever. Any of them will do 99% of this. And the upside of not-Ferrari is that it will also get you to your destination with a little less getting out to fix it on the side of the road. The concepts are the point, not any given repo or product. The intelligence is on tap, and there are many paths.

Step two this weekend, start your library. Not a grand archive. One folder of markdown files, export your notes, export your email if you can. Write one page about each project you are working on and each person you work with. And on those pages, write the things you actually know, what you’re building together, what they care about, what you owe them, what they said last time. That’s stuff no model on earth has because it only exists in your head. And your head, as we established, only holds seven things. The first time an agent answers a question using your context instead of the internet’s, you’ll feel the click and you won’t go back. You are all sitting on five, ten years of your own history in one inbox or another. That’s your moat just lying there, un-indexed, doing nothing. The only gate between you and this entire architecture is probably 24 hours.

Step three, write your first skill file. Picking it is easy. What’s the task you do every single week that you hate the most? Might be expense reports, meeting notes, the weekly status update, competitor research. Explain it to your agent. What do you want to do? In plain English, the way you’d explain it to a smart friend on their first day of a job, and then let it get it wrong. If it gets it wrong, correct it. Every rule, every exception, every “oh, and also,” put it in there and it’ll fix it. That page is now an employee. Run it.

Step four, wire it up to be a recurring job. Maybe it’s the job you just created in step three. Every morning at seven, do this. Every Friday, summarize that. The first time you wake up to work that finished while you slept, something shifts in your head permanently.

That’s the day that the day stops being the unit of work for you. It becomes what you can imagine, and it should be driven by what your goals are and what you want to create in the world.

Step five, this is the discipline that separates the compounders from the dabblers. Never do one-off work. Most people run one operation with one agent and then throw the context away. They close the window. That’s it. Don’t. At the end of every task, ask the agent to skillify what it did. Skillify is a special skill you can find in GBrain. You can point it at that repo and say, extract Skillify, learn how to do it. Turn it into a markdown file you can use and reuse forever. I’ll say it the way I say it at YC. If you have to ask for something twice, you failed. The person who captures what they learn gets smarter every single day.

The person who wakes up every morning with amnesia—well, that’s a waste of your time and it doesn’t matter how good the model gets if you can’t turn it into real memory. Do those five things and I can tell you what your next 90 days look like. Week one, honestly, it’s a toy. The library’s thin. The skills are clumsy. You’re fixing more than you’re saving. Week four, the flywheel catches. The agent starts answering with your context. The morning job produces something you actually read, and you write your third and fourth skill because the first two worked. Week 12, you have a library that answers before you finish asking. A dozen skill files running the parts of your week you used to dread, and one or two tools that other people keep asking to borrow, which in this room is called a startup. The curve is the same curve as any compounding thing you’ve ever seen.

Flat, flat, flat, then not. Most people who try this will quit this in week two, which is precisely why the ones who don’t feel like they’re cheating by week 12.

Now, I need to tell you the part that isn’t fun because everything I taught you just cuts both ways. I told you Spinoza’s definition of sadness earlier—the feeling of your power of acting decreasing. And I said it gets political. This is where. A skill file is not a document. It’s a piece of your cognition, how you do the thing, extracted from your head, written down and executable. Every skill you teach an agent is you, externalized. And the exact same file is two opposite futures depending on one variable: who controls it. Take a fictional example of a support engineer. Let’s call her Maya. Over two years, Maya teaches her agents 40 skills. How to triage a P0 at two in the morning, how to deescalate the customer who’s about to churn, how to write a postmortem that actually prevents the next incident. Forty files.

That’s her judgment—the thing that took her two years to build—sitting on a disk. Version one. Those files live in Maya’s repo. She changes jobs, they go with her. Day one at a new company, she’s operating with years of compounded judgment on tap. Every year she works, she compounds. That’s ownership. And if she wanted to start a company that does this, it’s her expertise—and it turns out she can. Entire startups these days will be markdown files.

Version two. Those files live in the company’s repo under the company’s IT policy. Maya leaves with nothing. The company keeps running her judgment without her. Forty files executing forever and her name isn’t even in the commit history. She didn’t have a career. She had an extraction. Same files, same Maya, one variable. So this is the doctrine, and I want you to be able to repeat it tomorrow.

I believe skill files are yours. Own your skills because if you don’t, your job becomes a skill file.

And this happened before. Craftsmen owned their tools. That’s what made them free. The factory broke that. The loom belonged to the mill. The knowledge workers assumed we were safe because our tools lived in our heads where nobody could confiscate them. Skill files end that. For the first time in history, your cognition can be extracted, stored, versioned, and owned. The only question is, by whom? Do you remember the thousand guilders? That offer never went away. It got rebranded. Every comfortable arrangement where your judgment compounds in someone else’s repo is a thousand guilders a year to show up, keep quiet, and stop building your own thing. And that’s why you should start a startup, because this is how you can actually make those skill files work for you. Spinoza faced the upgraded version two in 1673. Heidelberg offered the cursed heretic a full professorship. Salary, legitimacy, a chair, and “Freedom of philosophizing, provided he not disturb the established religion.” His answer was, “I do not know what the limits of that freedom of philosophizing might have to be.” He read the terms of service and he declined the acquisition.

He had a phrase for what he was protecting—”under your own power,” as opposed to under someone else’s. Your power of acting exists either way. The political question in 1673 and in 2026 is who commands it? Personal AI is about controlling your own cognitive abilities and protecting yourself. That’s the whole thesis of this talk in one sentence. Personal AGI is how you stay under your own power in the age of agents. So keep your brain and your skills in a repo you control from day one before any platform or any acquirer has an opinion about it. When Spinoza died, they inventoried the room. Two pairs of pants, seven shirts, a lens lathe, 160 books, and the Ethics locked in a desk. He owned almost nothing and nobody ever controlled his skill files. The desk drawer was his repo. Own yours like he owned his.

Now, three objections, and I can hear them from up here, so let’s just do them. Objection one. The models are improving so fast that all this harness stuff will be obsolete. Just wait for the next release. This is the bitter lesson crowd and I love them, but notice what actually happens in every model release. The better the models get, the more the differentiator moves to context. When everyone’s engine is a thousand horsepower, the race is won on the driver and the map. The weights are everyone’s. The library is yours. At least I hope it is. A better model makes your library worth more because a smarter reader extracts more from the same books. I’m rooting for the labs as hard as anyone in this building, but every release they ship is a free upgrade to a workforce I already own and a workforce I want you to own.

Objection two. Is this just RAG? Sure. And Postgres is just B-trees. Retrieval is the primitive, not the product. The hard part is everything around it. What gets written down in the first place, how it gets enriched and linked, what gets promoted to hot memory versus filed as cold reference. Who arbitrates when two facts disagree? Retrieval is easy. Being worth retrieving from is the product.

Objection three. And it’s the one that deserves the most respect. You put your entire life in one system, your email, your meetings, your kids’ schedules. What happens when it leaks? My answer is the same answer as the whole talk. That’s exactly why it has to be yours. My brain runs on my own infra, in my own repo, under my own keys. Compare that to the default, which is not privacy. The default is your life is already scattered across 10 clouds owned by companies whose incentives are not yours, searchable by everyone except you.

I didn’t create the risk by consolidating my context. I took custody of it. Custody is the security model. And if you don’t trust yourself to hold the keys, I promise you the answer isn’t trusting someone else’s terms of service more.

So why did I open source all of it? The harness, the brain architecture, the skills, the whole personal operating system? People ask me this because they seem like they think there must be a catch. Well, the answer is because I can. Because being at YC for me means I don’t have to monetize my own infrastructure. But “because I can” is also the answer to the wrong question. The real question is why anyone should. And the answer is that I believe tools of the powerful should be given away. Every era has a private technology of leverage, a thing the powerful have, and everyone else doesn’t.

For a long time, it was literacy. Then it was capital. Right now, today, it’s this—the harness, the library, the workforce made of markdown. The people who have it are quietly operating at a different scale than the people who don’t. And the gap is widening every month. And that’s what this whole conference is about: to give you the power to be able to do it for yourself. When something that powerful stays private, you get a priesthood. When it gets given away, you get a renaissance. I know which one I want to live in, which means I get to do the thing that I actually believe in. And I’ll give it to you as a creed because it’s the closest thing I have to one. Say the things other people won’t. Fund the people other people won’t. Build the buildings other people won’t. Write and give away the code that other people won’t. Leave behind the institutions that other people won’t.

And when you build in the open, you should know what’s coming because Spinoza’s story has one more chapter. November 1676, Gottfried Leibniz, the most glittering genius in Europe—silk stockings, a calculating machine in his luggage—travels to The Hague to spend three days in an attic with the most hated man on the continent. And then he spends the next 40 years lying about it. Publicly, the visit was a few hours in passing. Privately, his notes are crammed with obsessive commentary on Spinoza. I live a small version of this weekly. I say agents write most of my code now and the dunks arrive by lunch. Then I look at what the loudest dunkers are actually shipping and it’s agents all the way down. So learn the pattern now because building in public guarantees you’ll need it. First, they quote tweet you, then they git-clone you. The dunks are just the adoption curve announcing itself. And I want to show you what this architecture looks like when it’s pointed at the only thing that really matters.

I have a friend whose son has a rare form of epilepsy. No lab, no grant, no permission. He just went and you can just do things. He built a repo of 80,000 markdown files, a brain for one small boy, and pushed himself to the absolute edge of what humanity knows about his son’s exact condition.

Every specialist visit, every paper, every seizure log, every drug interaction—indexed and cross-linked and ready so that when a new doctor has an idea, he knows in minutes whether it’s already been tried. A father, a laptop, and a library. That is personal AGI. Not a benchmark, not a demo. The entire architecture I’ve described tonight—the library, the librarian, the right three books open at the right moment, aimed at the one thing one man loves the most in the world. Nobody was coming to build that for him, so he built it. And nobody is coming to build yours for you. That’s the good news.

Everything you were told you needed—the team, the funding, the permission, the credential—was a workaround for the fact that one person could hold seven things in their head and work sixteen hours a day. That fact just expired. You can fly now, not metaphorically, mechanically. Every problem where you thought, I wish I had this person. I wish I could hire this person, but I can’t get them. You can. Every archive too big to read. Every dataset too gnarly to clean. Every ocean you were told not to boil. We can boil the ocean now.

I have a sentence I live by and I want to leave it with you. “It’s all made up, but you get to make it up.” Every institution in the world, including the one that read a curse over a 23-year-old in 1656, was made up by people no smarter than you. The difference between you and every generation of founders before you is that they had to recruit dozens of believers before they could build anything at all. You need a laptop and a few years of your own history you’re already sitting on. There are about 7,000 people at this whole event. 7,000 conatuses. 7,000 strivings. For most of history, almost all of that striving never got an audience. It died waiting for funding, waiting for headcount, waiting for permission, waiting for someone else to believe first. The machinery I showed you tonight is the first technology I’ve ever seen that lets the striving go straight to work.

One person, no intermediaries, no permission. I genuinely do not think the world understands yet what 7,000 people with that kind of leverage walk out of a building and do. Spinoza closed the Ethics, the book that had to be smuggled out in a desk, with nine words: All things excellent are as difficult as they are rare. The difficulty just collapsed. The rarity is now up to you. Go and build. Thank you.

The work presented there tackled a wide range of questions at the frontier of ML. Can small language models reason better without relying on a larger teacher model? Can a theorem prover keep learning new mathematics without forgetting what it already knows? How do you train a model to understand a complicated scientific chart, reason across a two-hour video, or make predictions directly from a relational database?

Here are eight of the papers presented, explained by the researchers behind them.

1. Test-Time Scaling for Multistep Reasoning in Small Language Models via A* Search

Alexander Braverman
[Paper]

Small language models are cheaper and faster to run, but they struggle more with complex reasoning. Improving them often means distilling knowledge from a larger teacher model or generating several possible answers and using a separate reward model to score them. Both approaches require additional models, training, or infrastructure.

Alexander Braverman’s method instead asks the small model to evaluate its own reasoning. It generates possible paths, scores them through self-critique, and uses an A*-inspired search algorithm to decide which branches to keep exploring, without relying on an external reward model.

Tested with Qwen3-4B on GSM8K and MATH-500, the method improved accuracy by three to four percentage points over other test-time scaling approaches at comparable token and runtime budgets.

That comparison matters. It is easy to improve test-time performance by simply spending more compute. The paper shows that the search itself is making better use of the same resources.

2. LeanAgent: Lifelong Learning for Formal Theorem Proving

Adarsh Kumarappan
[Paper]

Continual learning presents models with a difficult tradeoff. A model that is too stable can’t absorb new information; one that adapts too quickly may overwrite what it already knows.

Adarsh Kumarappan studied this problem through formal mathematics, where knowledge is cumulative and every answer can be checked. In Lean, proofs are written as code, and a compiler verifies whether each step is correct.

LeanAgent collects Lean repositories from GitHub, estimates theorem difficulty, and arranges them into a curriculum from basic to advanced. As it works through that curriculum, it updates a retriever that identifies useful premises, uses best-first tree search to construct proofs, and adds successful proofs back into its database.

LeanAgent produced 155 new formal proofs across 23 domains. It also showed backward transfer: after learning more advanced subjects, the system improved at areas it had studied earlier. Learning topology didn’t make it forget algebra. It made it better at algebra.

3. Diamond Maps: Efficient Reward Alignment via Stochastic Flow Maps

Douglas Chen
[Paper]

A generative model may produce excellent images but still be difficult to steer toward the specific image you want. To guide generation, a system must estimate whether an intermediate state is heading toward a high-reward result. The problem is that halfway through image generation, the output often still looks like noise.

Existing flow-map methods project that intermediate state into one possible final image and score it. But the same state could lead to many different outputs, making a single deterministic sample a weak estimate.

Douglas Chen’s Diamond Maps samples several possible outcomes instead. By evaluating multiple futures from the same intermediate state, it gets a better estimate of how promising that state actually is.

The researchers built both a fine-tuned version and a training-free version that attaches to an existing flow map at inference time. The latter allowed them to run text-to-image experiments with Flux without paying the considerable cost of fine-tuning the full model.

4. ChartNet: A Million-Scale, High-Quality Multimodal Dataset for Robust Chart Understanding

Jovana Kondic
[Paper]

Understanding a chart requires a model to read labels, interpret visual structure, compare values, and perform numerical reasoning across all of them. Real charts can also be far more complex than simple bar or line graphs, from dense scatter plots to figures in scientific papers.

Jovana Kondic and collaborators at MIT, IBM Research, and the MIT-IBM Watson AI Lab built ChartNet, a million-scale dataset and generation pipeline for chart understanding.

Their key insight is that charts are usually created programmatically. ChartNet starts with a seed image, recovers approximate plotting code with a vision-language model, modifies that code with a language model, and renders new charts with perfectly matched supporting data.

Each sample includes the image, plotting code, data table, natural-language summary, and question-answer reasoning traces. Fine-tuning on ChartNet improved every open-source model family tested, and a two-billion-parameter model trained with it outperformed GPT-4o on the team’s chart tasks.

IBM Research also used ChartNet in the training mixture for a new vision-language model that outperformed much larger models on chart and table extraction. The open-source dataset had already been downloaded more than 50,000 times when Kondic presented the work.

5. Relational Transformer: Toward Zero-Shot Foundation Models for Relational Data

Mark Žnidar
[Paper]

Predictive modeling on company data often begins by flattening a relational database into one large table. That makes the data easier for traditional models to consume, but it can discard relationships expressed through primary and foreign keys, which must then be reconstructed through feature engineering.

Mark Žnidar’s model treats the relational database itself as the input. It represents the database as a graph, samples the relevant neighborhood around the target entity, and serializes the resulting cells. Different encoders handle text, numbers, and other data types.

Specialized attention mechanisms then capture column distributions, the target entity’s own features, and information from connected rows and tables.

Despite having only 22 million parameters, the model scored 73 AUROC on the item-churn example presented in the talk. A four-billion-parameter language model scored 62.

The work points toward relational databases becoming a first-class input for predictive models rather than something data scientists must manually translate into a format the model understands.

6. SAGE: Training Smart Any-Horizon Agents for Long Video Reasoning with Reinforcement Learning

Jitesh Jain
[Paper]

People don’t watch every video in the same way. You might watch a ten-second clip straight through, but skim a Formula One race to find the half hour you missed. Jitesh Jain calls this any-horizon reasoning: adapting how much effort you spend to the length of the video and the question being asked.

Existing video agents struggle with long videos and open-ended questions. Many rely on temporal-grounding models that try to locate exactly when something happened, but those models remain unreliable, partly because long-video training data is scarce.

Jain’s system supplements visual search with transcripts and web search. Gemini 2.5 Flash generates synthetic question-answer pairs and tool-use trajectories, avoiding the high cost of having people annotate hours of video.

Reinforcement learning then teaches the agent when each tool is useful. Wrong answers after tool calls are penalized, while successful use of a visual tool earns an additional reward.

As videos became longer, the trained agent took more reasoning steps and its advantage over the base model grew, suggesting it had learned to adapt its effort to the horizon of the task.

7. On the Fine-Grained Planning Abilities of VLM Web Agents

Surgan Jandial
[Paper]

Web agents are usually graded on the final result: did the agent complete the purchase, find the right product, or successfully navigate the website? That reveals whether it succeeded, but not why.

Surgan Jandial studied the planning between seeing a webpage and choosing the next action. Evaluating those plans directly is expensive because each decision depends on the screenshots, text, and tool calls that came before it, along with what happened afterward. As models improve, their errors also become subtler and harder to spot.

Rather than grade every complete trace, Jandial breaks planning into individual capabilities. Can the agent put webpage states in the right order? Predict the next state? Choose between possible actions? Recognize and correct an error?

The tests repurpose existing datasets, so they require no new collection or human annotation. Most open-source models tested scored below 50 percent, even though the individual questions were relatively simple.

The fine-grained scores also correlated with performance on full web tasks. That makes them useful as a cheap diagnostic: for about $10, a researcher can identify which planning skills a model lacks before running a much more expensive end-to-end evaluation.

8. Mechanistic Interpretability for Steering Vision-Language-Action Models

Bear Häon
[Paper]

Interpretability becomes more urgent when a model can act in the physical world. Bear Häon’s Berkeley paper was the first interpretability work focused specifically on robot foundation models, asking whether techniques used to understand and steer language models could also make embodied systems safer.

A vision-language-action model contains transformer blocks with feed-forward networks. Haon’s team projected activity inside those networks onto the model’s embedding space, creating a rough dictionary of the concepts associated with different activations.

They grouped those representations into concepts such as fast, slow, high, low, or cautious, then amplified a group during the forward pass to steer how the robot carried out the same natural-language command.

Robot foundation models introduce risks that don’t exist when an AI system is confined to a screen. A language model might know how to do something dangerous; a sufficiently capable embodied system could potentially carry it out.

Haon has since founded the Physical AI Safety Institute, bringing together AI safety, robotics, and control theory. Its Science of Physical AI Safety workshop will examine what robot safety can borrow from those fields and how these systems should be evaluated.

—

Watch the full playlist here.

Starcloud was founded on January 1st, 2024. On January 2nd, they booked a SpaceX rideshare launch — before they knew what they’d put on it.

Philip Johnston joins the Lightcone pod to explain why data centers belong in orbit, how collapsing launch costs make the math work, and how Starcloud went from demo day to a $170M round led by Benchmark in 17 months, the fastest unicorn in YC history.

Watch on YouTube

Timestamps

00:39 — Why Build Data Centers in Space?
01:40 — The Insight That Started StarCloud
04:43 — Launching StarCloud One
09:45 — The Engineering Behind Data Centers in Orbit
13:49 — Why 100 VCs Said No
16:12 — Book the Launch Before You Build the Product
18:32 — The Roadmap to Commercial Space Compute
21:10 — Building NVIDIA GPUs for Space
23:41 — Raising $170M for a Hard Tech Startup
26:37 — Hiring the World’s Best Space Engineers
31:25 — Why AI Compute Is Moving to Space
34:49 — Advice for Hard Tech Founders

Transcript

Philip: First thing every space company should do is book the first available launch they can.

Jared: Before they built the thing that they’re going to.

Philip: Before they built the thing, before they probably even know what they’re going to launch. Booking a launch is such a good forcing function for a space company. So we founded the company January 1st, 2024. January 2nd, we booked the first available SpaceX rideshare launch. And we were like, okay, something is going to be on that rocket. I’m not 100% sure what it’s going to be at this point, but something is going to be on there. Something’s going to happen.

Diana: Sounds like the same advice for all the software companies. You just got to keep launching and launching. Same thing.

Garry: Welcome back to another episode of The Lightcone. Today we’re sitting down with Philip Johnston, the co-founder and CEO of Starcloud. Starcloud is building data centers in space to address the energy bottleneck that AI is creating here on Earth. Earlier this year, they raised $170 million led by Benchmark and became the fastest growing unicorn in YC history just 17 months after demo day. Philip, welcome to the Lightcone.

Philip: Thanks so much for having me.

Garry: So to start off, why data centers in space?

Philip: So Starcloud is building data centers in space to solve the AI energy bottleneck. We are very quickly running up on constraints on where we can build new energy projects terrestrially. By building them in space, we get access to this almost unlimited low-cost energy in the form of solar. Of course, there are other costs like the cost of launch, and the cost of launch is actually very rapidly trending down with new launch vehicles coming online, the Falcon 9 program and Starship on the horizon. That’s the reason we’re building data centers in space.

Harj: How did you come up with the idea? It’s not like the typical idea that people come up with.

Philip: I’d actually been working, I was with McKinsey for a few years working with the space agencies of different governments, and I could see that the launch cost was very rapidly trending down. And actually in early 2023, I decided randomly on a weekend to take a trip down to Starbase, Texas where they’re building the Starship launch program, even before the first launch. Not many people were paying attention back then. I could see that they were just building enormous capacity. So they’re building these two Starship gigafactories. They’re designed to produce something like three Starships per day. And because Starship is reusable on a three or four-year timeframe, that could lead to us having thousands of times the capacity to get things to space. So I started thinking, okay, let’s just run the clock forward. If the launch cost was 10 times lower than it is today and the launch capacity was maybe a thousand times more than we have today, what would make sense that currently doesn’t make sense?

So I started thinking about some of the concepts from sci-fi that I remember as a kid, like space-based solar where you have these huge solar panels in space, you beam that power down. I reached out to a few folks I knew in the space industry and got connected with a few others and started ideating on, okay, what would make sense if the launch cost was much lower than it is today?

Jared: I’m curious, are there any other ideas that occurred to you during this process when you were thinking of what people could build in space now that

Philip: It’s cheap? Yeah, tons. We definitely looked at manufacturing in space and there’s Varda. We looked at asteroid mining and obviously YC has AstroForge. We looked at space hotels, we looked at basically anything which could make sense if the launch cost was a lot lower than it is today.

Jared: And how come data centers was the best choice?

Philip: Data centers makes a lot of sense to be the first thing that you do because you don’t need to reenter a product. So with things like asteroid mining or with manufacturing in space or space hotels, they require this very expensive reentry process. Initially, what we actually started doing was space-based solar, so huge solar panels and then you beam that power down. It’s a concept from I think the ‘60s, even Asimov in the ‘40s was writing about it. The problem with space-based solar is you actually lose 95% of the energy in transmission from space to Earth. So for the first two months of the company, that was literally what we were doing. We were called Lumen Orbit because of that reason, luminosity in orbit. We were thinking, okay, once we get that power down, what are we going to be using it for? Even back in ‘23, most new energy projects were being built for data centers.

So we were like, okay, well, either directly or indirectly, this power is going to go into data centers. Let’s rerun those numbers. So initially we’d run the numbers to know what’s the launch cost breakeven that makes sense for space-based solar? And we’d come to a number of like $50 a kilo. So then we reran the calculations. We were like, okay, let’s spend a month figuring out what would the launch cost breakeven need to be to make data centers in space breakeven. And we came to a much closer to reality number of $500 a kilo. And that’s what we think currently that the breakeven launch cost is. And so then we rapidly pivoted the company towards that.

Garry: So Philip, you launched Starcloud-1 in November of 2025, and that was a real emotional moment. Can you walk us through what that was like?

Philip: Yeah, it was incredible. So just to tell people a bit about Starcloud-1, we’d set this launch date 18 months in the future, and we initially started with something quite unimpressive. We were going to fly some NVIDIA Jetson chips. They’ve been flown in space before, and we were going to try and do some new workloads on there. It was Adi that came on and said, no, we need to do something way, way cooler than that. And we actually ended up putting five GPUs on there, three from NVIDIA, two from ARM. But the most interesting one was this NVIDIA H100. We did some crazy things. For example, you have to put it through thermal cycling and we didn’t have time to. We’d booked the vacuum chamber, the thermal and vacuum chamber. But we needed to know, okay, if we heat up this phase change material and cool it down and heat it up and cool it down, is it going to crack anything?

And so at 5:00 AM the day we had to ship it down, we were working through the night, Adi and Ezra are dunking this thing in an ice bath to cool it down. And then we pull it out of the ice bath and I’m like, are you sure it’s fine with electronics? They’re like, don’t worry about it. It’s totally fine. They pulled it out of the ice bath. Then we had these hair dryers to heat it up and melt all the wax or hot air guns. And then we’re dunking it back in the ice bath. It is a miracle that it works, to be honest.

Garry: You can just do things.

Philip: You can just do things. Yeah. So this is the kind of thing you can do as a startup because we actually had a quote from one of the primes on what it would cost to do Starcloud-1. And they said 75 million to 100 million dollars. And we did the whole of Starcloud-2, including the launch for $2 million. So yeah, leading up to the launch,

I mean, we got the most incredible separation video. I think we’re going to play it now. So half the time as it deploys, it will be behind the shadow of the Earth and you don’t see anything. The other half of the time it will deploy not into the silhouette of the Earth. And so it just is the most perfect deployment video I’ve ever seen. And this was played by Jensen as he walked on stage at the GTC conference this year, this five-story tall screen behind him playing the Starcloud-1 separation video. Amazing. So no, it was the most incredible feeling seeing this deploy.

Jared: Where was the team for this? Did you all

Philip: Go? So we took the whole team down. Yeah. There were only 12 in the team at the time of Starcloud-1 launch. So we took the whole team to Florida and we had a hundred friends and family investors. Some of our team brought their family and kids down, and it was a really nice day. We’re going to release a behind the scenes video of some of the family moments in that launch.

Jared: How long was it from when the rocket lifted off until the thing deployed until you powered it up and were able to verify the thing actually worked?

Philip: Yeah, so it lifted off. We were all on what they call the banana bleachers. It’s famous from the Apollo era, but it was in the middle of the night. So it lifted off at around midnight. And then at 1:00 AM they closed the bleachers and everyone had to get on a bus and leave. And we’re like, “Oh shit, I thought we were going to be able to watch the deployment.” And then I’m sitting in the back of a cab watching the live feed on spacex.com literally. I was like, “Oh my God, it’s deploying. I can’t believe it’s deploying.” And then it took about 12 hours to make first contact, which is not bad actually. It usually takes at least 24 hours to get first contact. And then it’s like a two-week commissioning period. And we had a whole bunch of software issues we had to work through.

The whole satellite kept restarting every two hours. And what was happening was one of 20 different failure triggers was triggering, and we didn’t know which one it was. And we could only get a ground station pass at least every hour and a half, maybe longer. And so we had to manually turn off each one, turn back on everything else and wait for a ground station pass to know which one it was. So that took three days just to figure out that software issue. And then two weeks after that, then we started commissioning and turning on all the different payloads. And then we trained the first model, ran the first version of Gemini. We did the first fine tuning of a model in orbit. Did the first high-powered inference on satellite imagery and all this kind of stuff.

Garry: So Starcloud-1 right now as we speak has just left Chinese airspace, I think, about to enter Japan. It looks like it’s going quite fast actually.

Philip: Yeah. So it travels around 17,000 miles an hour. It’s about an hour and a half to do one circumnavigation.

Garry: So by Starcloud-4 or so, this won’t be like one, it’ll be a giant network covering the Earth actually.

Philip: Yeah. From Starcloud-3 onwards, we’ll have 88,000 and they’ll all fly. This one is in what they call mid-inclination orbit, so it doesn’t go over the poles. And that’s another point here on how janky this one is. It doesn’t even fly in the right orbit, but at least it enables us to test the hardware. The next one will fly over the poles and that gives us 24-hour always in the sun.

Jared: In order to do that, you need to put thrusters on the satellite to move it into that orbit.

Philip: In the end state will be deployed in that orbit, but you need thrusters anyway to maintain the orbit because you have drag from the upper atmosphere there.

Diana: What are the engineering and physics trade-offs you have to make this happen? Because what you basically are doing with Starcloud is you’re getting infinite energy because the sun is basically the natural fusion reactor, just a giant mass that generates a nuclear reaction with the giant mass. And you have infinite energy, basically abundant and lots of space. But as a result of that, which we’re constrained of that in Earth, you have a bunch of other really hard problems to solve, like things around interconnect, how do you send all the data back and forth back to Earth? How do you handle cooling? People think that space is cold, but actually unlike Earth, there’s no air to circulate it back. So you need some crazy solutions with cooling. There’s things around radiation to flip the bits in processors. And there’s probably other things around how to get the solar panels to become really big and expand and many more.

These are the ones that I could think of. There’s so many things that are just so hard to build.

Philip: Yeah, you are correct. There are many engineering challenges to be solved. The two biggest ones that are outstanding, and most of our engineering, our engineering team is split basically fifty fifty down these two lines, is number one, as you mentioned, how do you get rid of this heat in a vacuum? And then number two, how do we make the chips work in a higher radiation environment? Some of the other problems are being solved by other people. The interconnect, we’ve just signed a contract with SpaceX for our next 20 satellites to have a Starlink laser terminal. That gives us very high bandwidth, low latency connectivity. Other people are solving some other parts of this. The core ones we’re solving are that. And so for the first one, for the thermal management side of things, we are building a very large low cost and low mass deployable radiator.

Now, radiators in space are not new. It’s not a new physics solution. It’s more of a manufacturing and engineering challenge because the International Space Station has had a radiator which dissipates lots of heat already. Very similar mechanism. So a liquid called loop. The challenge with it is making it cheap and light. So our radiator is at least 10 times less mass per watt of dissipation than the ISS radiator, and 500 times less cost per watt of dissipation than the ISS radiator. So very easy benchmark to beat on cost for the ISS. And then on radiation, it’s just a lot of ground testing in different particle accelerators. So we’ve done several rounds of testing at the Brookhaven National Lab Particle Accelerator for heavy ions. And also there’s a cyclotron for high velocity protons down in Knoxville. So we ship all of our hardware down there. My co-founder Adi runs in and out wearing this protective thing.

So yeah, basically you expose it over a 24-hour period to the same radiation dose that you would have in a five-year mission. And then all of that telemetry data then informs our choice on both shielding and software to mitigate bitflips. I think we’re the only people in the world now that know where both an H100, a B200, H200 will fail if you blast it with high velocity protons and heavy ions.

Jared: Do you have to change any of the underlying electronics to solve the problem or you just build shielding around it?

Philip: Both. Both. So we do build shielding around it. A lot of it is just component selection. So for example, all of the SSDs, all of the power delivery system, all of the power converters and everything else, we test 10 components and whichever the best one is we pick. We’re trying not to use space grade rad hard components. We’re trying to use off-the-shelf automotive style components because it’s way cheaper. And most people have never tested those in radiation chambers.

Diana: I think that’s one of the secrets of how SpaceX has actually reduced a lot of the costs of a lot of the satellites as well. They use not space-graded electronics, which would be exorbitantly expensive, but instead you take regular components that there’s a supply chain and run through all the tests and make sure if it works. And I think actually this is one of the things that Astranis does as well, is to make sure that telecommunication satellites actually work in space. Because they’re also in GEO, which has more radiation. Are you in GEO as well? No,

Philip: We’re in LEO.

Diana: Okay.

Jared: When you first told people that you were going to put data centers in space, what were people’s reactions?

Philip: For a very long time, their reaction was, “This is the dumbest thing I’ve ever heard.” So yeah, we actually applied to YC once and then tried to raise, and we tried to raise $2 million at 10 post on a SAFE. It took three months and we got rejected from at least 100 VCs. And then even after YC, when we went out to raise after demo day, I think we got rejected from at least 20 VCs before we got to the first check.

Jared: This is one of these ideas that was extremely unpopular with investors. And if you had listened to what all the investors were telling you, you would’ve quit and not ever done this idea. I’m curious, why did people tell you that they were not investing and what did they get wrong?

Philip: People had a hard time visualizing a world with low cost launch. And to be fair, we’re still not out of the woods on that front. Lots of things need to go right with the Starship program for that to make sense. So that’s one thing. I think it just sounds too sci-fi and too… Yeah, to make this work, there’s a convergence of two factors. One is the launch cost coming down and people have to believe that. The second is it becoming way harder to build stuff terrestrially. Maybe two years ago, that wasn’t quite as obvious as it is today. Now people are like, okay, well, they’re just banning building new data centers in New York. They’re going to ban it in seven other states. Now those two things I think converge to make it more investible essentially.

Diana: And I think the other thing, after hearing you explain all the engineering and physics, it actually is doable. It doesn’t sound like sci-fi from first principles. It’s actually buildable.

Philip: The reason I had confidence in it is because we had such a strong engineering team. So if you have the world’s best space engineers saying this is possible, and to be frank, my background isn’t as a space engineer, but I have full confidence in my two co-founders, one from SpaceX, the other was building satellites for NASA. Saying it’s possible, then it’s good enough for me.

Harj: Once you had the idea and then say once you were in YC, how did you break the problem down into a plan for what to do? Obviously in software, you think of your MVP and you launch quickly and you get feedback, but hard to do that with data centers in space.

Philip: I have a very tangible piece of advice for all space companies. The first thing every space company should do is book the first available launch they can.

Jared: Before they built the thing that they’re going to launch.

Philip: Before they built the thing, before they probably even know what they’re going to launch. Booking a launch is such a good forcing function for a space company. So we founded the company January 1st, 2024. January 2nd, we booked the first available SpaceX rideshare launch, and it was cheap. It’s like 300 grand.

Jared: Which was how far out was the launch?

Philip: It was 18 months out, and then it got pushed to 21 months out. And we were like, okay, something is going to be on that rocket. I’m not 100% sure what it’s going to be at this point, but something is going to be on that. Oh, that’s interesting.

Diana: Sounds like the same advice for all the software companies. You just got to keep launching and launching. Same thing.

Philip: Yeah. And what we initially planned to launch was very unimpressive, actually. It was like we were going to put a Jetson chip, which has been flown on many satellites before, and we were going to use it for edge processing and things. We actually had a co-founder change quite early on when we got Adi from SpaceX. Adi was like, “Oh, that’s lame. Let’s put an H100 on there.” We’re like, “Adi, you can’t put H100 on a satellite.” He’s like, “Sure you can.” The amount of people that said it was physically impossible to run a chip that’s that power dense in orbit. People just thought it was literally impossible to run data center grade GPUs on orbit.

Jared: What would’ve caused it to be impossible?

Philip: There’s two things. One is the thermal side of things. They’re very power dense, they produce a lot of heat. And the second is they’ve never been tested in the radiation environment in space. And both of those, so for the first one, it’s kind of a wacky solution. We submerged the entire thing in this phase change material. So everything on Starcloud-1 is submerged in this phase change material. So it’s like immersion cooling for all of the components, all of the power delivery, memory, everything is submerged. Nobody’s ever considered doing anything like that in space before. It’s not a particularly scalable solution. You have quite a low duty cycle. You have to wait for it to melt, and then it solidifies every so often. But it enables us to prove that you can run the H100 in space. The next one is this directed chip liquid cooling architecture that we can run continuously.

But yeah, I give full credit to my co-founder, Adi, for coming up with some pretty wacky and crazy ideas.

Jared: To get to a data center that’s commercial scale where you can actually make money on it, it’s actually profitable. It’s going to require many steps. How did you think about sequencing out the journey to get there?

Philip: So as I say, first step was book whatever the first launch is, the lowest MVP we can have available. Second step is producing something which is a product we can sell to customers. So that’s Starcloud-2. That’s a 10 kilowatt spacecraft that we can sell compute to government and military satellites. And then the third step is the product that we are going to be able to sell to hyperscale data centers. So that’s the Starcloud-3. It’s 200 kilowatt, three ton spacecraft, about six meters long. With that, we can fit 50 of them per Starship. So about 10 megawatts of new compute capacity per Starship. And we’ve just filed with the FCC for a constellation of 88,000 of those. So that means on the order of 20 gigawatts of new compute capacity.

Diana: Wow. And

Philip: We can fit up to 10 terawatts in the dawn-dusk synchronous orbit. So that’s like 20 times the entire US power grid.

Diana: For context, what’s the largest data center deployment on Earth? Because you’re talking about 22 gigawatts. Oh my God. What’s the largest one here on Earth today?

Philip: They’re about a gigawatt is the largest. Yeah.

Jared: What’s the timetable for all of this to become real?

Philip: Yeah, it’s very dependent on the launch cost. And so the estimates for Starship, if you believe Elon, it’ll be end of this year, but let’s say it could be end of next year, early 2028 for Starship deploying, ramping up the launch cadence. They’re actually phasing out Falcon 9, so they’re going to be moving over commercial customers to Starship. There’s also a whole bunch of other launch vehicles coming online. Stoke Space has the Nova Rocket. Rocket Lab has Neutron. Blue Origin has New Glenn. So end of the 2020s, I’d say is when we’re starting to ramp up for the terrestrial business, competing with terrestrial data centers.

Garry: So your customers are actually anyone who wants compute. And then initially-

Philip: Initially, it’s government and military, but then as Starship ramps up. So for the next two, three years, we’ve just won four contracts with various DOD and government entities.

Garry: And then initially also it’s people who want that compute actually for other purposes in space then. Is that right?

Philip: Yeah, exactly. So right now, many satellites are very constrained with the amount of data they can downlink. And so using optical terminals, we’ll have three optical terminals on our second satellite. They can ship enormous amounts of raw satellite imagery and SAR data, synthetic aperture radar data to us. We then process that on orbit, and then we can just downlink very quickly the insight from that. And the insight might be the coordinates of a vessel or something like that.

Garry: In terms of NVIDIA, how are you partnering with them around chip design? And are there changes that you have to make to the design as you reach scale, making it more radiation resistant or what does that look like?

Philip: Yeah, so we’re working very closely with NVIDIA. We recently announced this Space Rubin-1 chip that we’re working with them on. So that’s designed for the space environment. We very heavily modified the H100 to make it work in space. On the mass side of things, we stripped out a lot of things like the AC to DC converters, the cold plates, and everything else we stripped out. Then we stiffened the board. We made it radiation tolerant. Because of that, they’re very interested in whether there are any people that have any data on how one of these high-powered GPUs operates in space. So yeah, we’re working with them very closely on designing this new space chip because you can actually do very simple things to make these chips way more effective to run in space. That’s what we’re doing.

Diana: I think the thing of getting GPUs to now natively run on DC, you avoid the whole conversion of energy AC to DC because that’s what makes solar panels not as efficient is the whole conversion. Exactly. Lose a lot of power,

Philip: Which is very hard. Our solar panels generate DC immediately. So there’s no point doing. We just need DC to DC converters, but that’s much better than AC to DC converters.

Diana: So we could unlock a bunch of companies also just building DPU data centers just using solar power, period. Whether in space, under the water, or on Earth.

Philip: Yeah. Actually, people can definitely use this tech for other things. Yeah.

Garry: Can you talk about Starcloud-2 a little bit more? Is there actually a Bitcoin miner in there as well?

Philip: Yes, we will be flying a Bitcoin mining ASIC next year, which the crypto community is very excited about. There’s much more enthusiasm than I was expecting, to be honest, about that.

Harj: Crypto community loves a good narrative.

Philip: The number of people that want me to launch Starcoin, you have no idea. There is actually a Starcloud meme coin, I think, out there.

Garry: Yeah, don’t buy it. That’s not official. Do not buy

Philip: The Starcloud

Garry: Memecoin.

Philip: So yeah, we’ll have one of those on there. We’ll have a whole bunch more H100s, Blackwell chip. We’re also partnering with AWS on launching the Outposts hardware. That’s their on-premises server blade that they give to customers to run a local instance of EC2. That will be useful particularly for our military customers.

Harj: Something we were talking about earlier is at YC, we just observed over the last few years, it’s been quite hard for hard tech companies to raise funding in general. There’s not been much investor appetite for it. It certainly seems to have changed over the last six months. Great news. From your perspective, I’m curious, how was it raising the seed round during YC, and then this huge round you raised from Benchmark? Just maybe tell us the inside story of how that all came together and what it feels like being a hard tech founder raising money today.

Philip: So when we first raised end of 2023, we tried to raise $2 million at 10 post. And yeah, that took three months to get together. About a hundred VCs said no. Deep tech and hard tech and space were definitely not a cool thing to invest in back then. Then after YC, it took us quite a while to raise. So I think we got rejected from at least 20 VCs before we got our first check on the demo day raise. And things have definitely swung around since then. It’s become a lot easier to raise for deep tech, I think. I think a number of reasons for that. One is people think that software doesn’t have a moat anymore, which I think is probably accurate.

Harj: It’s funny, the hive mind just switched,

Philip: Seemed to

Harj: Me very quickly. It was just like the SaaS stocks. Claude code came out, SaaS stocks, public company stocks all went down. And then suddenly it was, I think the fastest I’ve seen things in the public markets directly affect demo day where suddenly everyone’s like, “Oh, we need to invest in hard tech now.”

Philip: Yeah, that’s fascinating. I think people are just much more open to investing in hard tech now. I think we were the first space investment Benchmark had done.

Harj: Yeah. I mean, whatever you can share. How did that round come together? And again, what do you think Benchmark saw in you guys?

Philip: So to be frank, that round wasn’t as easy as it looks from the outside. There’s a lot of VCs that have big SpaceX positions for one thing. And SpaceX midway through the round came out saying they’re doing exactly what we’re doing and it wasn’t public then. And so anybody with a conflict policy then was like, okay, we’re conflicted out. But towards the end of the round, it certainly came together much faster. I think, to be frank, I don’t think. So Chetan is our partner. Chetan’s awesome.

Garry: Amazing investor.

Philip: Yeah, he’s great. I think basically he saw a really, really strong technical team doing something that if it worked, could be incredible. And I think when he came to visit us, he spent a lot of time doing DD on other things on the backgrounds of all of our team. We literally have the best fricking engineering team in the world in Redmond building this stuff. Half of them from SpaceX, half from some of the hyperscalers. So he spent a lot of time with the team. He spent a lot of time. But I don’t think if he’d come across a report that said that cooling in space was impossible, that would’ve thrown him off. I think he was like, “Okay, this is a good enough team that they can figure it out.”

Jared: How did he build such an awesome team?

Philip: So my co-founders, Adi and Ezra. With Ezra, I reached out to him after I’d been down to Starbase, Texas, and I was like, “Have you got any ideas that would make money if launch cost was 10X cheaper than it is today?” We started with this space-based solar idea with Adi, who was introduced through a friend. He actually had already been thinking about this. He already had registered the domain name stellarcloud.com before. With the team, we were just ruthlessly slow at hiring and picky about hiring. After YC, we’d raised 11 million at 40, which is a decent round in YC. Even then it took us six months to make our first hire. We’ve got the most kick-ass space engineer as our first hire. We’ve raised a lot of money now. Even this round that we announced in March, we’ve raised a much larger round since then.

We’re still only 20 engineers. We have one commercial guy who came from the Space Force who was working on Golden Dome. We are so picky about who we hire. It is to a point of being very frustrating, to be honest, but it’s the whole game. The whole game is having a kick-ass engineering team.

Garry: What was it like to have this idea, have people sort of poo-poo it, didn’t really get it, and then suddenly, to have much more commercial validation that Google, SpaceX, the stalwarts of the industry embraced the idea and realized actually some crazy percentage of future data centers likely are going to be in space. What was that like to see the sea change and be early?

Philip: It was surreal. If you go back through my Twitter feed, I’ve been shouting from the rooftops for the last three years about this. Contrarian, but right. Every day I would post something about why data centers in space are going to make sense. Then slowly and slowly, people would start to drop hints about things. Elon at one point was like, 99.999% of the energy in the solar system is from the sun. So I’d repost that and I’d be like, “We need to build data centers in space.” Everything I would find a hook for.

Diana: I think this is one of the things we see with all the best hard tech founders. You’re essentially living in the future and are almost like a prophet that brings the future back to us underlings on the Earth that don’t quite get it yet.

Philip: I’m going to tell my mom, who’s very religious, that you said I’m a prophet.

Diana: But I think that’s cool. The other thing that’s fascinating to me is that your background, if you go on your LinkedIn, is not very legible that you would be in space. But you had a background previously doing software and physics and then went to business, but nothing there that says space.

Philip: Yeah. So for people who don’t know my background, I spent the first five years of my career as an engineer on the software side, studying math and physics before that, undergrad and master’s. Then I went to McKinsey more on the commercial product side. But I actually ended up doing a couple of projects with national space agencies on different satellite missions. That’s where I really started to notice the launch costs coming down very rapidly. I actually had another startup before this. When I left that one, I decided, okay, if I’m going to do another startup, it has to be something I’m very passionate about. For my whole life, I’ve been very passionate about space. Because I don’t have a space engineering background, I realized, okay, I’m going to need the world’s most kick-ass space engineers. Actually, this is where I give credit to YC.

I was blindly following the YC advice. I thought, okay, the first thing we need to do before coming up with an idea is get the most incredible space engineers in the world on the team, essentially.

Jared: This was before you even knew what you wanted to do in space. All you knew at that point was that launch costs were going to come down dramatically and there was going to be cool stuff to do in space. And you wanted to find some space people to do it with.

Philip: Yes, that’s literally it.

Garry: But it wasn’t a vibe of, oh, can you please build this crazy idea that I have? No, no. It’s like the reverse even. Exactly. I’m going to figure out the commercial part.

Philip: Yeah, exactly. My pitch to Adi and Ezra was essentially, if you have any ideas that would make sense if the launch cost was 10X less than it is today, I can figure out everything else around that besides building the satellite piece.

Jared: How did you find them? How did you recruit them?

Philip: So Ezra and I had grown up in the same place in the UK. To be frank, I messaged a lot of space engineers. Maybe 10 of them took a call and two of them said yes. I found it. That’s all you

Garry: Need. You don’t need a hundred people to do it. You only need one or two.

Jared: So Philip, during the batch, the way I thought about Starcloud was that it could only work if you were able to make it cheaper per unit of compute than ground-based compute. And I think you will, but it’s occurred to me since then that it’s not actually clear to me anymore that that is necessary for Starcloud to succeed. I’m curious if you think about it the same way, because since the batch, we’ve learned that AI data centers are becoming politically incredibly unpopular. And it seems not unlikely to me that it will soon become basically de facto impossible to build AI data centers anywhere, at least in a democratically minded country. I’m curious how you think about that, how it affects your plans for the company.

Philip: Yeah, 100%. And this has moved faster than I was expecting as well, to be honest. We’ve just seen New York now blocking data centers construction for reasons which are not grounded in science really. It seems more like vibes than anything else. Building these things in space will definitely be much easier from a regulatory perspective.

Garry: So let’s do some myth busting. There are a lot of misconceptions about certainly water and data centers, but also power. What are some of the things that come to your mind?

Philip: With water specifically, water is really actually just a function of power. You can cool data centers with no daily consumptive use of water if you just throw more power at the problem essentially. And that is what all of the data center companies are now proposing. It’s very unlikely that any data center company proposes any data center that is going to be consuming daily amounts of water.

Garry: And there is actually evidence that you can have closed loop systems that consume very little water. Yeah, exactly. And I think the analogy is like if you ran a burger shop, a fairly large data center with hundreds of megawatts would consume about the same amount of water as a McDonald’s. So it’s really a non-issue, but it’s unbelievable that they’re repeating this so much.

Philip: Yeah. They do use a lot of power though. And so most new power projects for data centers right now are being built with natural gas generators actually. And so there’s certainly some people that are pushing back on those.

Garry: One of the arguments is that as data centers get built, they compete on the grid, which is not true. People actually—also not true.

Philip: If you build a new power project for it.

Garry: Right. Which is generally what people are doing. You just can’t get enough power from the grid. So there’s also some evidence actually that adding data centers increases the capacity of the grid and then prices actually come down over time. That being said, it’s a perfect storm. We need intelligence, we need data centers. It’s become basically a national security issue for America and for the West to have access to intelligence—it’s the most important tech tree of the next hundred years. And so for tech policy to put us back into the stone age and possibly lose the war for us, that puts Starcloud in a different position in terms of bringing compute and AI and power online.

Philip: Yeah, for sure. It definitely puts us squarely in the national security bucket at that point.

Garry: Thank you so much for fighting for the West then. We’re

Philip: Doing our best.

Garry: So as one of the fastest growing unicorns in YC history and to do it as a hardware company, do you have any closing thoughts for people who are looking at space, looking at hard tech as a thing that they want to work on? What have you learned and what would you tell the just starting out version of yourself based on where you’re at now?

Philip: Yeah, I think there’s just huge opportunities now coming in with space. We’re really at the very early innings with what’s going to be this enormous industry in space. The amount of capacity and launch that’s going to come online in the next five years is really mind-boggling. So yeah, I would definitely encourage people to step into that. In terms of advice, the YC advice stands true. It’s technical talent and founding team is the thing you need to solve for first, and then everything else follows from there.

Garry: Philip, thanks so much for coming on the Lightcone.

Philip: Yeah, thanks so much for having me. Nice being here.

Waymo’s first autonomous demo took eighteen months. The product took fifteen years. Today, the Waymo Driver runs 500,000 trips a week — four million fully autonomous miles across fifteen cities, with 17 times fewer serious-injury crashes than human drivers.

At Startup School 2026, Waymo co-CEO Dmitri Dolgov shares the seven lessons behind that journey, from bridging the gap between a demo and a real product to building systems that can safely operate in the physical world.

Watch on YouTube

Timestamps

00:07 — Seven Lessons From Building Waymo
02:21 — Why Physical AI Is Different
06:52 — Lesson 1: The Gap Between a Demo and a Product
11:34 — Why Reliability Lives on an Exponential Curve
14:17 — Lesson 2: Pick the Right Technology Curve
16:05 — Why Waymo Uses Cameras, LiDAR, and Radar
21:07 — Lesson 3: Ride Every Technology Wave
24:43 — Inside the Waymo Foundation Model
30:09 — Lesson 4: The Bitter Lesson Still Wins
36:41 — Lesson 5: Why Every Physical AI Company Needs a Simulator
41:36 — Lesson 6: Build an AI Flywheel
43:22 — Lesson 7: Evals Are Your Competitive Advantage
46:09 — How Waymo Became 17x Safer Than Human Drivers
47:59 — The Next Decade of AI Will Be Physical

Transcript

Good afternoon, everyone. It’s great to be here. We talk a lot about AI that lives on your screen, lives in the digital world. Today I’d like to talk to you about a different kind of AI that we’ve been building at Waymo, AI that lives in the real physical world. How many of you, by the way, have been in a Waymo? Just raise your arms. Wow. Okay. That is impressive, especially since I understand many of you are out of town. For those who are visiting and have not had a chance to check out Waymo, I hope while you’re here in the Bay Area, you’ll give it a try. Since this is a startup school, I structured this presentation as a sequence of lessons—seven lessons that we’ve learned over the years at Waymo around what it takes to build and safely ship today’s most mature application of AI in the physical world, the Waymo Driver.

Let me start with a short video. This is a clip from a ride that I recently took in a Waymo with my kids. As you see here, we’re moving forward, proceeding through an intersection, and a couple of human drivers just decide to cut in right in front of us. The Waymo Driver reacted safely, reacted smoothly. In fact, so much so that my kids, who were preoccupied in the backseat, didn’t even notice that anything happened. To me, this was a pretty powerful moment. I’ve been working on this technology and this product for close to two decades, and it just did something fairly important. It acted safely. It kept my kids safe. It kept everybody safe, and nobody noticed. That, I think, will be a bit of a theme in general when it comes to physical AI: the best AI moments will look like nothing happened.

It’s just the task got done safely and smoothly.

These moments where the Waymo Driver kept everyone safe are happening daily across our fleet. Today, the Waymo Driver is serving around 500,000 trips per week and driving over four million fully autonomous miles every week in 15 cities across the United States. For comparison, that’s over 300 years every week of an average American driver’s annual mileage. The Waymo Driver is accomplishing that with a superhuman safety record. So what does it take to build and deploy an AI agent in the physical world at scale? In Silicon Valley, there’s a common mantra to move fast and break things. However, when you’re dealing with atoms instead of bits, breaking things is not really okay. So the thing you have to do is move fast and ship safely.

That’s a much more difficult thing to do. You have to build systems that are robust from day one. You have to build AI models and you have to build training recipes where safety is the foundation and not an afterthought, not an add-on. By the way, the problem itself of physical AI is different from digital AI. There are four main gaps that you have to contend with if you’re building AI for the physical world versus the digital world. First, there is the cost-of-errors gap. If you have a language model or a chatbot or a copilot and it makes a mistake, usually it costs you a retry. In the physical world, the cost of a mistake can be measured in human lives, not tokens. There’s simply not an undo and a retry button.

Secondly, you have the latency gap. Typically, when you’re running a VLM or a digital assistant, it can take many seconds, sometimes minutes, to come back with an answer. A car traveling at freeway speeds moves about a hundred feet in one second, so milliseconds really matter. You have to run all of your inference and make all of your decisions on board a compute that fits in the trunk of your car. Next, there’s the data gap. Digital AI had the internet—this wonderful, immense cache of pre-labeled human knowledge and human thought that we’ve ever assembled. There’s no digitized version of the internet for the physical world.

And lastly, there’s the validation gap. In digital AI, often you can ship something that’s good enough and then let your users use your product. They find the edge cases, and that allows you to deploy on day one, practically at unlimited scale. Then you can just iterate and hill climb the quality from there. In physical AI, the situation is different. Given the high cost of errors, you need to have a very high level of safety and a very high level of confidence on day one before you deploy your first robot, before you drive your first autonomous mile. At the same time, when you’re dealing with physical AI, the actual experience of having your agent in the real world is invaluable and irreplaceable. These systems are not just something that you can build in the lab, get perfect, and then deploy at full scale overnight.

Given those two factors, you really need to super clearly and super crisply define the operating conditions and the deployment parameters of your agent, and then build a rigorous framework to guide your deployment so that you can scale in a responsible manner. This is absolutely critical. This is how you earn trust from your customers, from the communities, from the regulators, and yourself.

At Waymo, we see these gaps, of course, in the context of autonomous vehicles, but these gaps will show up in practically any non-trivial physical agent that we deploy in some shape or form. Driving is simply the first domain where AI has crossed these four gaps at scale with the public interacting with our product. So let’s dive into those lessons that we’ve learned over the years at Waymo from working on this problem and talk about how we address those gaps. I have seven lessons in this talk. They’re all technical. There’s a lot more that goes into building a company and building a product, but today I’ll just focus on the technical aspects of building AI for the physical world. Each one of those lessons, I think, by itself will not be exactly earth-shattering. A lot of it will overlap with things you’ve likely heard elsewhere.

But I hope that the grounding of these lessons in our experience and some of the nuance that I can add about how they showed up in our experience of deploying a physical agent and scaling it safely will be interesting and useful for many of you who are in the space as you build your product, as you build your startup.

So let’s dive in. The first lesson has to do with this massive, frustrating, sometimes soul-crushing difference between a demo and a real product. A working demo is 1% at best of the work that you have to do. The many nines of performance, the many nines of reliability that follow, that’s where the real work happens. If you’re a founder in the room, chances are you are focused on getting that first prototype, that first demo off the ground. When you hit that first version of a system that works, that first 90%, when the demo actually works, it feels incredible. You feel like you solved it, the sky’s the limit, you’re extrapolating forward. In our world, we hit that first milestone, that first 90% back around 2010. When this project started in 2009, before we started building the system, we set a couple of pretty ambitious goals for ourselves.

One was to drive 100,000 miles in autonomous mode. The second goal was to drive 10 routes, each one a hundred miles long, chosen to cover a variety of conditions across the Bay Area. We had to do each one from beginning to end without a human intervention. At the time, we had a team of about a dozen engineers and we accomplished both of these goals in about a year and a half. Keep in mind, this was well before any of the AI breakthroughs, before ConvNets, before Transformers, before VLMs, before any of the stuff that we talk about today. Yet we got it done. By demo standards, autonomous driving was solved in 2010. We handled everything. We could drive during the day, during the night. We handled traffic, pedestrians, cyclists, traffic lights, construction zones, on freeways, on surface streets. So we were “capability complete.” At the time, we felt like we were on top of the world.

But then, as we started building towards a product, we quickly ran into a brutal reality: there’s a massive difference between doing something once or driving 10 routes once and building a scalable service with nobody behind the wheel.

It took us about 10 more years to begin providing a service and then five more years to scale to half a million trips per week. The demo took 18 months; the product took about 15 years, but now we’re scaling exponentially. To date, we’ve served well over 20 million fully autonomous trips and we’ve driven well over 200 million fully autonomous miles. We have rider-only vehicles operating in 15 cities across the United States, and we’re scaling exponentially. It took us 15 years to get to that first hundred million miles and about seven months to drive the next hundred million. It took us about eight years to go from the time when we started our initial rider-only operation to the time when we were serving riders in four cities. Earlier this year, we launched four cities in just one day.

So why does bridging that gap from demo to product take so long? Well, because there’s this harsh engineering reality that you can’t really cheat: reliability and performance live on this exponential ladder of nines. Getting to that first 90% or 99% is the easy part, but every next nine you want to add takes about ten times more effort. You need to know upfront exactly how many nines your product actually needs. A demo might need one nine, an assist product or copilot might need a few, but a fully autonomous AI agent that we’re going to be putting out in the physical world, engaging with the public and with kids running around, needs a whole stack of them. At scale, the long tail is the problem space—it’s your entire problem statement. When you drive millions of miles per week, a rare event that might happen once in a million miles just becomes your daily reality.

Getting those next nines means doing something different every time. You don’t get to six nines of performance or reliability by doing the same thing you did to achieve the first two, just for longer. You have to do fundamentally different things. It requires a fundamentally different approach. For example, with reliability, you can get to the first couple of nines by just doing proper engineering and some bug fixes. But to get to the next few, you need to invest in fundamentally different approaches. You need to build fully redundant systems, have tiered fallback architectures, and so forth. The same thing holds for the performance of AI models.

What that actually means is that in this space, it’s incredibly easy to get started, but it can be excruciatingly difficult to get to the real product. That effect is only amplified with every wave of technological breakthroughs, which naturally leads to hype cycles. Every AI breakthrough—from deep learning to ConvNets to Transformers, VLMs, you name it—makes it that much easier to get started. Your demos and prototypes get a hundred times easier. But the tail, where the hard problems are, moves much less. It moves, but the effect is muted. That’s why every hype cycle produces a wave of absolutely spectacular demos and very few real products. The recurring mistake of every cycle is spending on the demo what you should be saving for the nines.

Now, this being a startup school, the last thing I want to do is throw too much cold water on the magic and excitement of those early days. This time is absolutely magical. It’s amazing. Cherish it, leverage it. But the key is to remain honest about the product you’re building, the number of nines in performance and reliability that product demands, and not cut corners to get there. Otherwise, you might be in for a pretty rude awakening later. So count your nines before you count your demo views. This brings us to the second lesson: once you know how many nines your product actually needs, it fundamentally dictates the architecture and the core technical approach you need to pursue. Every technology has a performance versus effort curve. They all tend to start fairly steep and go up, and then they flatten out.

And as I just mentioned, every other nine gets an order of magnitude more difficult. A common failure mode is picking the tech that gives you the fastest early ramp, riding that steep curve, feeling like you’re winning, projecting that steep slope into the future and feeling like the sky is the limit, and then hitting the plateau and discovering that the technology path you picked actually flattens out way before the performance required by your product. You might still choose to be on that steep curve for a while for a variety of practical reasons. Maybe you want to prototype something, demo something, or build something in service of learning, but be honest with yourself about whether you’re building for the purpose of a demo, for the purpose of learning, or towards an actual product.

Let’s take an example from our domain: autonomous vehicles and sensing. There’s been a longstanding debate about what kind of sensors you actually need for autonomous driving. Naturally, more sensors mean higher performance, but also higher complexity. Humans, of course, can drive with just eyes, so there’s that proof of existence. If the goal were to just approximately match human performance or to build an assist product, that’s a very reasonable way to go. However, if you are targeting full autonomy and superhuman, strongly superhuman performance, you find that weak sensing leads to a safety curve that flattens out way too early. At Waymo, we’ve taken an approach where we use multiple sensing modalities. We use cameras, LiDARs, and radars, and they all complement each other. Cameras give you high resolution and color, but they’re passive and degrade in darkness and glare.

LiDAR gives you a direct measurement of the 3D structure of the world around you. Radar is very good at punching through environmental conditions and weather like fog, rain, or snow, and it can directly measure velocity using Doppler. LiDAR and radar are active sensors, so they see just as well in pitch darkness or, for example, when driving into a blinding sunset. These different sensing modalities are not backups to each other. In our stack, each modality has an encoder, and the information from all of those sensors gets fused into a single view of the world around us that is much more precise and generally vastly superior to what you get with any one sensor. Let me show you a few examples. Here’s a scene where a Waymo is driving in a dust storm in Phoenix. What you see here is what the scene looks like to our fairly advanced high-resolution and high dynamic range camera.

It’s very close to what a human would see in the same conditions, which is not much. On the right is what the LiDAR sees for the exact same frame, and you can much more clearly see that there’s a pedestrian standing on the side of the road. If they were to step onto the road, that early detection can make a really big difference in how the situation plays out and the safety of everyone involved.

Here’s another example. At night, driving along, there are a couple of pedestrians who are about to jump onto the road over a concrete construction barrier. Again, at the bottom you see the camera—it really can’t see much. And the LiDAR view at the top. Again, LiDAR versus camera. Here’s another example. There are a couple of dogs chasing a ball and a couple of kids chasing the dogs. And big difference—here’s what it looks like to the camera. Here’s the LiDAR. The early detection of the kids is off to the side, and there are no headlights, there are no lamps there. It’s complete darkness. So it makes a big difference. Or think about what happens when something physically obstructs the view of your sensors.

If you don’t have redundancy in sensing and have a single leaf land on your sensors, it can bring your robot to a full stop. So you need redundancy. Redundancy, of course, does not necessarily mean multiple sensing modalities, but if you need redundancy anyway, you might as well benefit from the complementary physics of the different sensing modalities in the nominal case. So here’s a video of one of our cars that picked up a leaf—or actually, I think a full branch of a tree—that our wipers were unable to shake, and the car detected that. Because we have sensing redundancy, it was able to safely get back to the depot for proper cleaning.

Specifically, when it comes to hardware, do not anchor to today’s component prices. We are on the sixth generation of the Waymo Driver, the Waymo hardware suite today. With every generation, the hardware not only delivered amazing capability, but we were able to drastically simplify and radically reduce the cost of the hardware as well. So betting your company, betting your approach on today’s hardware prices, is just betting your company on a number that has a fairly short shelf life and is going to expire. Hardware will change. Many components will get commoditized and drop in price. So design for that future and be ready to upgrade.

That brings us to the next lesson, lesson number three. Technology moves incredibly fast, especially nowadays. So you need to be ready to ride those tech waves and do that repeatedly. And when you do, you have to not only think about the wins in performance and the wins in capability, you have to be very mindful about unification and simplification. Over the years, we’ve seen a number of major breakthroughs in technology, a lot of them around AI. With every wave of innovation, we pretty much rebuild the Waymo Driver around that major wave of AI breakthroughs. We often push the state of the art in those areas forward ourselves. We leveraged convolutional networks around 2013 for computer vision and perception. Then, when transformers came about around 2017, we bet big on them both for perception and for the task of behavior prediction and decision making and planning.

Turns out the task of driving is not that dissimilar from the task of modeling language because of the social aspects of driving. You’re having a conversation with other dynamic actors in the world, but you’re doing that in the space of body language of your agent, your car, as opposed to just the language of words. You operate in sequences, and local continuity matters, but so does global context. Today we’re leveraging the latest in VLMs and frontier world models. Now, using the latest tech for capability and performance wins—I don’t want to say it’s easy, but it can be reasonably straightforward. Doing applied research in isolation or starting a tiger team to prototype some new technology is not the most difficult part. There are many companies, many teams that are excellent in this. The much harder muscle to build is to carry that bleeding-edge research into production and deploy it in a safety-critical environment without regressions, and do it without breaking stride on the scaling of your product.

Adding capability, again, is not the hardest part, but adding capability while at the same time reducing fragmentation and reducing complexity—that is really important. Finally, the hard muscle to build as a company is to be able to do that repeatedly through multiple waves of technical innovation and technical breakthroughs. So on this front, I have two bits of advice. The first one: when a new technology shows up, it can be very exciting, very tempting to kick off a new effort, a tiger team to pursue it. And that’s great. You should absolutely do that. However, when you do, it’s very important that you consider what you would do after, under a success scenario. Let’s say that effort succeeds. You should be very clear on what the path of that new innovation is for your company, for your entire product, for your entire system.

Oftentimes I’ve seen a failure mode where a project, a very difficult technical project, succeeds, and then there’s a dead end. That can be very wasteful, that can be completely deflating. The second bit of advice I have here is when pursuing new tech, again, don’t just ask, what does this new tech give me in terms of capability and performance? Also ask, has it simplified my stack? And has it led to fragmentation or unification? Set your launch bar to demand both breakthrough performance and, at the same time, radical simplification and unification.

This exact philosophy and this muscle that we’ve built at Waymo over the years is what produced our latest core technology. The heart of it is the Waymo Foundation model. Now, the Waymo Foundation model is a multimodal world action language model. It’s kind of a mouthful, so let me unpack the ingredients. It’s a multimodal model because it is able to process these multimodal sensor inputs: cameras, LiDARs, and radar. It’s a world model because it inherently understands how the world works—the physics, the dynamics, as well as the social and semantic aspect of it. It’s an action model because we are not just passively observing how the world evolves; we’re an active participant. So the model needs to understand the effects of the actions of our agent on the world and be able to tell the good ones from bad ones. And finally, it’s aligned with language.

And that allows us to unlock general world knowledge from visual language models. That’s incredibly useful in the long tail of rare semantic situations. More specifically, this is what the architecture looks like. It’s your typical encoder-decoder architecture. The encoder part takes in the multimodal sensing and compresses or encodes it into an efficient representation that retains all of the relevant data, all of the relevant information for the generative part, or the decoder. It’s an end-to-end model, which has a couple of nice properties. It allows us to effectively backpropagate the gradient from the task that we actually care about all the way to the early layers of the model. It allows the encoder to learn the right rich representations for what the generative part needs to solve the task. It uses a system one, system two, “think fast,” “think slow” architecture, and it leverages the general world knowledge of VLMs for efficient learning of semantic tasks.

Let’s dive deeper. First, the “think fast” path. That part fuses the raw data from our cameras, our LiDARs, our radars, and that allows for split-second, safety-critical decisions. You can think of it as your driving instincts. This is what allows the car to brake instantly if, for example, a pedestrian runs into the road or a cyclist nearby swerves into your path. This is, if you will, the lizard brain of your agent that deals with a lot of geometric tasks and can react in milliseconds. Second is the slow path. That’s the part responsible for the more complex semantic and scene-level understanding type tasks. These tasks don’t typically change in milliseconds, so there you can afford a bit more latency and trade that off for higher capability and higher levels of reasoning.

For example, if the Waymo Driver encounters a situation where there’s a vehicle on fire on the side of the road, the fast path might just see it as a generic obstacle and reason that the path ahead is clear. This is where the slow path comes in. That path can use deep semantic reasoning to understand the semantics of that object—the car being on fire—in the broader scene context. That allows our driver to decide to take a very different action or a different route entirely, even if geometrically the path ahead is clear.

Finally, there’s the generate component—the decoder. That’s the component that understands and can produce behavior. It understands how other actors behave and allows us to make predictions and plan our own driving decisions. Our Waymo Foundation model powers the Waymo Driver that runs on different generations of hardware and on different vehicle platforms. You have our fifth generation and sixth generation, the Jaguar I-PACE, the Ojai, and the Hyundai Ioniq. In the future, we’ll power different products and different commercial applications like trucking and personally owned vehicles. By leveraging the strategy of focusing on the high-capacity foundation forward model, we’re able to move a lot of complexity upstream to that large shared foundation. That allows us to make the specialization layer that’s running on the car pretty lightweight. In turn, that allows us to speed up the development process.

So the most important muscle in this lesson is for your company to not just leverage the tech of the day, but have the ability and build that muscle to repeatedly ride those tech waves and pull in the results of that innovation into production without regression, without breaking stride in deployment and scaling, and without drowning in complexity. So let’s move to the next lesson.

There is a well-known lesson in the AI community that general methods that leverage massive compute and massive data will always beat methods that rely on handcrafted, engineered human knowledge. That’s the so-called bitter lesson that Richard Sutton published and formulated in 2019. We have lived this and we have seen this in every wave of technical breakthroughs. Each time, the bitter lesson holds: methods that scale best with compute and data always win out. And by the way, this is one of the reasons why we bet on the approach of building the foundation model. There is a well-known property that if you bet on a high-capacity model and you use your data and your compute on that, you just get better scaling laws, and then you distill into smaller, more efficient models that are running on your agent in real time. You just get better scaling laws as opposed to just focusing on the smaller models directly.

So one nuanced area where this lesson shows up is the use of structure in your models. Depending on how you use your structure, you can end up on either side of the bitter lesson. Essentially, structure that fights scale will always lose, and structure that channels scale always wins. In particular, this comes up around the discussion of end-to-end models. As I mentioned, an end-to-end model has some very nice properties. You backpropagate gradient from the final tasks all the way through the model, and it allows the API between the encoder and the decoder to use rich learned representations. Those are the easiest models to build and train.

The architectures are known. You can start with doing some imitation learning, and a black box end-to-end model will give you very rapid progress, and you will ride that very initial steep part of the curve. For some products, that’s enough. But if you need to reach superhuman levels of performance in a fully autonomous agent in a safety-critical environment, just doing that basic vanilla end-to-end is not enough. This is where structure comes in. The key question here is, does the structure boost scale or does it fight it? Does it limit and constrain your solution space, or does it help you scale without loss of generality? Let me give you an example. Let me illustrate this point with a simple thought exercise and a toy problem. Imagine you are building a robot that will play the game of Go.

And you want it to play the game in the physical world. So you have a camera that’s observing the board and you have an actuator that will actually move the pieces around. One way you can build such a robot is to have an end-to-end system that goes directly from pixels to actuation. Maybe you train it by giving it some videos of how humans play the game. That could be a very interesting research exercise. However, if your goal was to build the world’s best playing Go robot, that’s probably not the most efficient way to go. The reason for that is that there is a very simple intermediate representation that completely captures the state of the game, the state of the task you’re trying to solve. It’s a 19 by 19 board, and that gives you a fully observable and complete state of the world that you care about, at least for the game-playing part.

Leveraging that structure doesn’t limit your model. It doesn’t constrain your solution space, but it gives you a very helpful way to scale. Now, that of course was a toy example. Anything that’s not trivial that you’re trying to deploy in the physical world will not have that property. The fact that such a simple, clean engineered representation doesn’t exist in the physical world is the whole reason why we need end-to-end systems and learned representations and learned embeddings. But in the physical world, there does exist structure. You have laws of physics, you have rules of the road, you have objects that behave in reasonably predictable ways. You can use that structure in addition to the learned representations to boost your performance, simplify validation, and at the end of the day, just get better scaling laws.

This is the approach that we are pursuing at Waymo, which we call structure-augmented end-to-end. We go beyond the basic vanilla end-to-end by augmenting the learned embeddings with materialized structured representations. That gives us a few very important advantages. First is validation at inference time. Because the model isn’t just a black box where sensors go in and actuation commands go out, we can create a very powerful correctness and safety validation layer that you can run in real time when the agent is deployed on our vehicles. This is really important for any agent that’s operating in the physical world.

Secondly, we get great wins in efficiency when it comes to large-scale training and evaluation of the generative part of the model, the decoder. If all you have is a black box end-to-end system, you are forced to do all of your evaluation and all of your training in the end-to-end setup, all the way from sensors to decisions to actuation. Having that intermediate structured representation allows you to mix and match. You can do some training at larger scale and some evaluation in the space of those compact structured representations, and some in the full space of end-to-end from sensors to decisions. Finally, we get strong, verifiable feedback signals for both evaluation and for training, training recipes to support things like reinforcement learning. That additional materialized structure just gives you much more powerful tools for evaluation, for metrics, as well as crafting your loss function or reinforcement learning recipes.

So the lesson here is to bet on a system that’s maximally learned and minimally constrained, and leverage structure intentionally to boost performance and scaling laws, both in training and in evaluation.

Now that raises the question of how do you actually train and evaluate your physical AI agent? And that brings us to the next lesson. To build and safely deploy an agent in the physical world, it is absolutely critical to have a good large-scale, realistic, high-fidelity simulator. Now, there are two ways you can do training and evaluation: you can do open loop and you can do closed loop. In open loop, you are passively observing input to output pairs. You can use that for evaluation or for training—imitation learning works like that. Evaluation usually takes the shape of, if you find yourself in this situation, what would you do? And then you score that. That’s in contrast with closed loop, where you take an action, you see the effect that action has on the world, then you update through your sensors the view of the world, take another action, and so on. You evaluate and train on those sequences of actions and sequences of world evolutions.

Now, the ability to take an action and evaluate that counterfactual is absolutely vital for building and deploying safety-critical agents in the physical world.

So a real simulator is how you do that. And a real simulator isn’t just some lightweight tooling that sits next to your AI. It is a big AI model in and of itself. The problem of building a good, realistic simulator is just as hard as building the agent itself. The AI behind the simulator really needs to understand how the world works—the physics, the semantics, the traffic, the weather, and so on. The quality of that simulator has to be high enough so that it doesn’t only look good, but it’s sufficient to train and evaluate with high confidence an agent that you’re going to be putting in the world in a safety-critical environment. In other words, you have to build a highly accurate generative world model. At Waymo, for years we’ve been building what we called behavioral world models.

We were doing that way before the term world models even became popular. Now, in the era of end-to-end models, you also need, on top of behavioral realism, sensing realism as well. In fact, building an end-to-end model has been fairly easy for quite a while now, but evaluating it in closed loop—that was the hard part of the problem. So we’ve moved on to building sensing world models. Because we’re using that structure-augmented representation in our models, we can also leverage that structure in our simulation. Our behavior world model operates in the space of structured intermediate representations, and the tightly coupled sensor world model then produces realistic sensor simulations. Our world model leverages the great work of Google DeepMind’s Genie 3, and that gives us the ability to produce controllable and highly realistic scenarios, both in the behavioral as well as sensing aspects.

That in turn allows us to not just evaluate our agent and train new versions of our agent in situations that we’ve previously encountered, but it allows us to train and evaluate in purely synthetic, rare scenarios that we’ve never seen in the real world.

So what you’re seeing here is not just the generated video. It’s a generative, a full generative simulation of the Waymo Driver operating in closed loop. Here we’re simulating what would happen if it came across a car that was stopped in a lane on the freeway. And you can go further than that. Here’s a plane that’s landing on a freeway in front of us, or you can simulate an elephant on the loose walking through the intersection, snow on the Golden Gate Bridge, or a dinosaur walking around. The lesson here is that closed loop simulation is absolutely required for evaluation and is extremely valuable for training your physical AI agents. You need highly realistic, large-scale simulation to train and evaluate. This brings us to lesson number six. When you’re dealing with a problem of that complexity, you can’t just build a model and call it a day.

You have to build an entire ecosystem. And then you also need a flywheel that powers it. Because to make this work at scale, you can’t just build the agent and one AI, you need to build three. You’re building the agent. For us, that’s the driver that drives the car. You also have the simulator, which is that virtual playground for the agent to learn in. And then you have the critic. The critic is what rigorously evaluates and judges the performance of the agent and tells it how to improve. The good news is that the fundamental reasoning and the generative capabilities of all three of those are shared. That’s why in our case, they’re based on the same foundation world model.

Once you have these three pillars, you can create an incredibly powerful flywheel to accelerate your progress. A deployment of your agent in the real world generates data. That data then grounds the simulator and makes it more realistic. The simulator generates harder edge cases for the critic to score and for the agent to learn from. So the agent gets smarter, gets deployed in the physical world, generates more data, and that powers the flywheel and accelerates progress. But a flywheel, of course, will spin in any direction or in place. In order to make it go in the direction you want, you need to guide it by metrics. That brings us to the final lesson: your model is really table stakes, but eval and metrics, that’s your most important, that’s your strategic moat.

Build your eval before you build your technology. Build your eval and your metrics before you build your product. If you can’t quantitatively define what good enough means, you’re not really building a product, you’re just iterating on your demo. Nowadays, the best model architectures are fairly well known and new ideas tend to proliferate fairly quickly. Data is incredibly important, but without good metrics, you’re just flying blind. You aren’t leveraging the best data and you can’t really evaluate the ROI on making changes to it. So really, eval and metrics, that’s your foundation. That’s what steers your whole tech stack.

But for physical AI agents, model-level evaluation is not enough. When you’re putting an AI agent into the physical world, your evaluation and validation need to go much deeper and much broader. You need to evaluate and validate every component of your system, from the physical layer to the behavioral layer that’s running onboard in the physical world, as well as the offboard components and all of the operational processes around it. For us, we call that the safety and readiness framework. We spent years building and refining it, and that’s what guides our development, deployment, and scaling. I consider that to be one of our most important assets.

The reason it’s important is because in the physical world, trust is everything. Evaluation and metrics are how you go about earning that trust. You don’t just win trust by talking about the clever technical solution or the state-of-the-art architecture of your models or doing a flashy demo. You earn it gradually, day by day, in the field, by relentlessly proving that your system is safe and that your system works. Of course, you can’t just prove that to yourself behind closed doors. This is exactly why we openly publish our safety data and our ongoing safety research. That earned trust becomes your ultimate business advantage. Your models can be leaked. Algorithms can be replicated, but hundreds of millions of miles of fully autonomous operations in the real world, backed by evidence-grade evaluation and publicly audited proof, is much, much more difficult to replicate.

When you zoom out and look at this playbook as a whole, you realize that none of these lessons works alone. The nines set your bar and ensure that you pick the right technology and the right technical approach so that you don’t get stuck on the local minimum. Then intentional use of structure to boost scaling and the ability to ride technical waves of innovation helps you get to the right level of nines. Your AI ecosystem with the agent, the simulator, and the critic guided by evaluation and metrics, that’s what allows you to build that powerful flywheel. That’s how all of these effects compound. It’s this playbook that we’ve been refining over the years that allows us to achieve the strongly superhuman safety performance of the Waymo Driver. This is a snapshot of the latest safety data we’ve released.

It’s based on over 220 million fully autonomous miles. We’re seeing that in the areas where we operate, the Waymo Driver is about 17 times better than human drivers when it comes to crashes that cause serious injury. That really matters because today, somewhere in the world, every 26 seconds, someone loses their life on a road to a crash event. On the current scale, what that means is that Waymo is preventing a serious injury every eight days. This isn’t just a metric on a dashboard. That means that someone’s loved one got to walk through the front door at the end of the day safe and unharmed. These are just the early safety benefits of AI in the physical world, and they will only grow from there. If you look at the broader landscape, the opportunity here is absolutely massive.

Physical AI right now is where digital AI was a few years ago, and we have all of the right ingredients to go after it. We have generative world models, we have the architectures, we have affordable compute and sensing. We have proven scaling laws, and we have a real product operating at scale. The last decade of AI happened in the digital world. I think the next decade will also happen in the physical world. For those of you who decide to build in this space, good luck, have fun, and remember who you’re building for. Your mission and your customers—that’s what matters. Otherwise, tech is just a science project. At the end of the day, as exciting and exhilarating as the tech is, nothing really beats the joy of making a difference in people’s lives.

In 2009, Patrick and John Collison went to Startup School in Berkeley, got sushi in Potrero Hill afterward, and decided on the walk home to start Stripe. The reasoning, as Patrick remembers it, was that “we might as well because it probably won’t be that hard.”

It took them two years to launch.

Seventeen years later, at Startup School 2026, he talks with Harj Taggar about dropping out of MIT twice, why founders should ask what happens if they succeed, and what Stripe’s own data says about the best time to start a company.

Watch on YouTube

Timestamps

00:07 — What Should You Still Learn in the Age of AI?
02:01 — Knowledge Still Matters
05:12 — Should You Drop Out of College?
09:58 — Why Stripe Worked
12:10 — Building Stripe Before Launching
17:20 — Is the Lean Startup Still the Right Playbook?
19:07 — The Hidden Reward of Building Stripe
22:36 — Will AI Kill Your Startup?
25:17 — Why It's Never Been a Better Time to Start a Company
29:23 — What Stripe's Data Says About the AI Economy
30:45 — Build Something People Truly Need

Transcript

Harj Taggar: Okay. Patrick, thanks so much for being here. Welcome to Startup School.

Patrick Collison: Great to be here. Harj and I first met 20 years ago and we started a company together. Sorry, am I giving away the introduction?

Harj: I thought this was my interview, but keep going. You’re doing a great job.

Patrick: I was going to say we started a company together many years ago and I learned a huge amount from Harj. So it’s really fun to do this too.

Harj: Right. Well, actually, speaking of that, I think when I first met you 20 something-ish years ago, at the time, your most impressive achievement I would argue was Croma, your dialect of Lisp.

Patrick: Any Lisp programmers here? Oh wow. Okay. I think I heard one whoop, which is more than I expected. But yeah, I really liked Lisp when I was in high school.

Harj: Yeah. So what I was going to ask is, a prolific 16-year-old today could presumably just prompt Claude to write their Lisp dialect. Would you advise them to not do that and still do it? Is there any value in such things?

Patrick: I don’t know. I wonder a lot. Obviously on the one hand, it used to be really fun to write all this assembly and machine code and to optimize your instructions and layout and memory and everything. And now we don’t have to do that anymore. Compilers do it for us. We don’t mourn it too much. And so maybe in the same way we shouldn’t mourn source code. We should just transcend the plane of instructions to Claude et al. But emotionally, I miss it.

Harj: How about, I think just as I’ve been hanging out here with these students, maybe the question behind it is many of them are just wondering what should they be learning at college? In this AI world, how much should they be trying to learn and derive from first principles and how much should they just outsource to the AI?

Patrick: Right. My model of this is cache, the CH, not an SH, where Jeff Dean has this famous set of numbers that every programmer should know—bandwidths and latencies and just kind of relevant constants that you should reason about as you build systems. And obviously when you’re thinking of building any system or distributed system or whatever, all lookups and all relevant bandwidths between different components are very different. Retrieving something from L1 cache is very different from retrieving from RAM, which is very different from retrieving across the network or whatever. And I think it’s like that with knowledge where, fine, yes, you can ask the agent or something to compute something for you or to look something up for you or whatever. That’s a hell of a lot slower than knowing it in cognitive L1 cache. And you can have way more round trips in your brain than you can muttering through Superwhisper or typing it out or whatever.

And so I think even granting the full capabilities of the models, I still think there’s a pretty— I think for a long time to come, neuronal lookups will be much faster. And then, if you look in revealed preference at what companies themselves are doing, whether they’re companies like Stripe or the labs or what have you, there still seems to be an enormous premium on cognitive ability. And so I wouldn’t— I think renouncing that before there’s evidence that we’ve saturated those benefits would be premature.

Harj: Are there specific things that maybe you personally, either personally or as CEO of Stripe, you still purposely choose to do yourself and retrieve from your own cache, even though the agents would probably do a reasonably good job?

Patrick: I still write myself. I both philosophically, but also specifically, substantively dislike the writing of the models. It’s very interesting, right? Because these can prove the Jacobian conjecture, whatever. And so clearly they’re capable of these monumental feats. But somehow I still haven’t read the LLM essay that I’ve found super compelling. It’s just very hard to RL limit that domain because the utility function or something is kind of hard to define. But yeah, I think writing is pretty—interpersonal communication and writing I think are so very fundamental and being able to reason sensibly in the multidimensional space of reality. And in some kind of indescribable way, I feel like the model is still kind of deficient at that. And so I’ve yet to send—every tool is now trying to prompt me with pre-written suggestions, whether it’s Gmail or apparently WhatsApp just rolled this out.

And I think I’ve still sent zero of those in my life.

Harj: Cool. How about if you talk about the Stripe story, the early days in particular a little bit. You were at MIT, then you left to start Stripe. How did you think about that decision? And obviously we’re in a stadium full of college students. How should they think about it? How do they know if it’s the right decision for them to leave college early and go start a company versus stay?

Patrick: Yeah. Well, I think I have the slightly unusual distinction of having dropped out of college twice to start a company. So maybe one thing to know is that it’s not totally trapdoor. You can drop out and in fact return. So I dropped out after my freshman semester to start the company with Harj. That was super fun. And then after a couple years of that, went back, did another year at MIT and then dropped out again to start Stripe. And when I went to college, probably like a lot of people here, I had this vision of my life involving becoming an academic. And I really like physics. And I thought I’ll do all this physics stuff. It’s so cool. I’d read all the Feynman books, all of this.

Well, growing up in Ireland, I hadn’t thought much about the possibility of startups. Hello to the other Irish folks here. Way back then in the pre-Cambrian era, startups were definitely much less well known even on campus and so forth. When I was dropping out, people thought it was super weird. I think overall, if you enjoy college, there’s no harm in finishing. I felt this real sense of urgency, which I think in hindsight was a bit unnecessary. But if you don’t enjoy college, it’s not your thing. It’s not what captivates you. You don’t really want to learn all the physics things or whatever. I think a lot of parents think that dropping out is very risky and will impugn your reputation for the rest of your life and so forth. And as far as I can tell, nobody has ever cared.

So I both think you don’t need to, but also the cost of doing so are de minimis.

Harj: What was the urgency you were feeling?

Patrick: The urgency?

Harj: Yeah, to go out and do something.

Patrick: I don’t know. Life is short. It was a general kind of haste. I think a lot of us, I’m sure many of the people here, get into this mode of speed running high school. And then once you get to college, it’s like, obviously I want to speed run that as well and do all the things. So it’s a bit of that. Marc Andreessen also talks about a version of this. I thought that a bunch of the opportunities in startups and in Silicon Valley and so forth were ephemeral and fleeting. And if we didn’t build it then, it wouldn’t be possible to do it in three or four years and maybe all the opportunities would be gone. In hindsight, I think that was a poor intuition. It’s been pretty robustly and reliably the case over many decades that Silicon Valley has a surface of opportunities.

Yeah, I think it was mainly those two things.

Harj: This is a very common thing that we hear when we talk to students now: part of the reason they want to drop out en masse, it seems at this point, is the worry that actually now is the moment. I think the meme going around is that if you don’t drop out and start a company and make lots of money, you’re going to be trapped in the permanent underclass. Should everyone here be worried about being stuck in the permanent underclass, I guess is the question.

Patrick: I think there’s a real... Humanity has always had an affinity for these millenarian models of how everything will soon come to an end and be this permanent transformation of society and so forth. Actually, there’s a great book, The Winged Gospel. People thought that after the invention of aviation, civilization was just entering—and humanity as a species was entering—a new era and nothing was going to be the same. Obviously, aviation was a pretty big deal, but I don’t think it was quite the sociological rewriting that some of the excitable proponents at the time imagined. So it’s hard to predict anything, especially of the future, but I would take the under on this being the last couple of years to create a company.

Harj: So going back to the Stripe story, Stripe ostensibly seems like a good idea. Even on day one, the internet’s a big deal, money’s a big deal, combine those two things. Presumably, is that how it went when you went and told people you wanted to start Stripe? Did everyone just say, “Hey, this is obviously a good idea.”

Patrick: It was kind of funny. Something we learned from YC was the importance of focusing on very concrete, easy to explain customer problems. It’s very easy to hallucinate or to imagine some customer problem that’s not actually something viscerally felt by a person who would pay money. And so over the course of, in part, working on Auctomatic together, we encountered this issue of it being really annoying to deal with the movement of money or payments or whatever on the internet. And on the one hand, it seemed like an obviously good idea in the sense that nobody liked the existing ways of doing so. They were broadly extremely unpopular and antiquated and legacy. You had to fill out this paperwork and go to the bank in person. The paperwork was in Latin and it was all bad. But then the flip side is, it just seemed kind of ridiculous that two kids would start a financial services business.

And FinTech didn’t exist as a sector at the time. The words literally didn’t exist. So we felt like the proverbial squirrels in a trench coat trying to masquerade as a real business or as serious adults, but obviously knowing nothing coming in about the space. Certainly, a lot of people we met and pitched—banks, partners, or whoever we talked to—they didn’t literally laugh us out of the room, but you could see them looking for the button to call security under the desk and have us hauled out because it just seemed so improbable. So anyway, I’d say it both seemed like an obviously good idea in that people really wanted this, but also a bad idea in that nobody took it seriously. But I think the fact that it was grounded in such a concrete, actual, real user problem saved us.

Harj: Actually, speaking of that, in order to actually build the product, you had to get a banking partner and do things that a typical software company did not have to do. As two young founders, how did you manage to convince a bank to trust you in the end?

Patrick: Yeah. Well, actually this is not an answer to your question, but just a thing that strikes me as I sit here is the reason we decided to start Stripe is because John and I were in college together. He was in his freshman year. We went to Startup School in 2009, which was held in Berkeley. We thought it was pretty cool. So we went and got sushi afterwards in Potrero. We were walking back from sushi and we’d been kicking around this idea for a payments thing or thinking about the space. It was walking back that evening after Startup School that we decided to start Stripe. That’s cool. I remember literally where we were in the road. I remember what we said to each other, which was, yeah, we might as well because it probably won’t be that hard.

Harj: Okay. So moral of the story is go get sushi in Potrero tonight and you might start the next Stripe.

Patrick: And yes, beware of these ultimate yak shaves. We thought we could do it on the side while in college. It would take a couple months. That was almost 17 years ago.

Harj: At the time, I remember you were also unusual in that you took longer to do a big public launch. Especially within the YC world, the motto is very much launch early, launch quickly, be out there and iterate. Could you maybe just talk us through a little bit about that? Why did you do it that way?

Patrick: Yeah. So we started working on Stripe seriously in the—well, we started working the week after that Startup School, but we were in college, it wasn’t full-time. We started working full-time the summer of 2010. We launched publicly September 2011. So almost two years after the first lines of code, after the repo was started. Waiting two years to launch seems—if we were going to YC meetings every week, I think we’d have been bludgeoned on the head. I think, look, in many domains, that probably is the wrong thing to do. In our domain, to your last question, because we had to do so much around security and partners and money movement and infrastructure and reliability and all the things, we didn’t feel like we could scale a really good self-serve experience without getting a lot of the preconditions and the infrastructure in place.

I think the thing that saved us and meant that it wasn’t a total walk in the wilderness is we had production users almost from the very beginning. So, first lines of code in fall of 2009. We got our first live production user in January of 2010, so two months into working or whatever. And it did very little. It was very larval and incomplete. Our first production customer was Ross Boucher at a company called 280 North. All it could do was charge a card. Ross would charge the card and then ask a reasonable question like, “How can I look at all my charges?” Reasonable request. So, let’s put up a little dashboard here. Then he’d say, “Well, I want to refund a payment.” All right, we’ll build refund support. After a couple of weeks, he was like, “At some point, do I get my money?” Also a reasonable request.

So, let’s build that functionality. It was very just-in-time development. Anyway, we had a production customer from very early. Then we did increase—it was in private beta—we increased the number of customers every single month all the way to that public launch. Every week we had actual customer feedback requests, new users coming in, we’re learning things from reality as opposed to our own hypothesized or extrapolated conception of it. I think if you have a significant stream like that of grounding, it’s probably okay to not be launch, launch. You’re an expert YC partner. Do you agree?

Harj: That’s a good question. Yeah. The issue with advice in general is it’s so generalized, and especially in startups, the exception proves the rule. If the cost of failure is high, then almost certainly you have to take longer to build. Maybe a slight tangent, but something I’m curious about related to this is we were talking about these coding agents, the ability to just build and produce software cheaply and quickly. I wonder, should people be taking more of this path? Should people be more ambitious in general with what the version one of the thing that they launch is? Or is it still fundamentally good product design to start narrow and focused and then expand out once you know what people want?

Patrick: Yeah. It’s a good question. I think probably in the era of AI—I don’t know. To some extent YC will be, I think, the expert here, but the whole traditional lean startup doctrine of exactly what you say: start out by buying the Google ads or something and identify this crevice or whatever and iteratively expand out from it. I think you can certainly imagine that that becomes much more competitive and much more aggressively tilled, and it’s hard to find those little niches. The internet’s a much bigger place than it was 20 years ago when some of those ideas emerged. Whereas taking these really divergent starting points where nobody else is trying to occupy that territory is maybe more—basically, maybe you have to more aggressively de-correlate in the era of AI. And I think it is interesting to think about many of the companies that are most successful over the last 10 years.

So many of them are very anti-lean startup, right? Whether it’s the labs themselves or Anduril or you can go down the list, a lot of them have this characteristic. So I think maybe a better way of saying it is 20 years ago, the whole lean startup thing was almost the only thing to do because of capital available and you didn’t have AI that made spinning up an organization with many different potentialities and capabilities so much easier. Whereas now I think you can start these much more aggressive and ambitious things upfront.

Harj: Within YC and probably the startup world at this point, you’re famous for at least the Paul Graham term, schlep blindness. Stripe, at least on the surface, involved a lot of schleps, things that presumably weren’t the intellectually most interesting things to work on. And I always found that especially interesting for you because you just mentioned you had academic interest in physics and clearly a deep intellectual curiosity and have very many things that you’re interested in. As Stripe has grown into this big company, in what ways are there intellectual rewards that you’ve given up and which ones have you gained?

Patrick: Yeah. In any company, there’s a bunch of stuff that’s not that rewarding or in and of itself all that interesting. Setting up payroll—no one starts a company so that you can set up payroll. And certainly building business financial services, there’s all sorts of more arcane and extensive versions of that. I actually feel extremely lucky with Stripe in this respect. And I think this is something, I don’t know if you need to think about it that much upfront, but I think once you think about it, maybe before you raise a significant amount of money, you always worry naturally about the possibility of failure and what’ll happen if you fail and how to mitigate and avoid failure and all those things. I think you need to ask the converse of that. What if you succeed? And you raise money and you have customers and you have employees and a whole thing.

Are you going to enjoy that? Are you going to want to work on that for 10 years, for 17 years, for 30 years? I mean, Larry Ellison at Oracle is going for, I guess it’ll be a half century soon, right? So what if you succeed? And in the case of Stripe, I really love it because we’re working with the world’s most interesting and innovative companies. 25% of all Delaware corporations are started with Stripe via Atlas. And then we get to partner with them and work with them and hear from them and get their feedback and get their requests and everything through the entirety of the journey up to being the Shopifys and the OpenAIs and all the standout successes.

Oh, and actually speaking of Atlas, we’re giving free Atlas incorporation to everybody at Startup School! If you are struck by the urge to found something over dinner this evening, as we were, just email startupschool@stripe.com and we will get you your link for free Atlas.

But yeah, I think PG latched onto something where there are all these menial tasks, but in the totality of Stripe, I find it so interesting. Every business is an applied theory on how some aspect of the world works or how some market works, or if it’s a new company with a new model, that’s a contrarian thesis on some counterfactual. I’ve never met a Stripe customer and thought that’s boring. So actually, the business as a whole has been the opposite of the schlep blindness instinct.

Harj: And you have a particularly unique perspective on this because you work with the big model providers of big lab companies and you work with all of the fast-growing AI startups on the ground. Something that came up a lot here yesterday, and honestly it comes up within the batches too, is people are just worried about whether their idea is going to get trampled by the big lab providers. Given your perspective, I’m just curious, how should people think about that?

Patrick: Yeah. Again, predictions are hard and certainly the labs are very competent, capable organizations. And maybe to separate a little bit, will rapidly improving AI capabilities do this or will the labs specifically themselves do this? I think in general, the track record of—no organization, if we go back 20 years, there was some of this sense with Google. When we were doing Auctomatic, the question was always for our company and every other company, what if Google does this? And Google seemed omnipotent and had this immense number of incredibly talented people and essentially infinite access to capital and servers and just all the things. Human organizations are complicated and it’s very hard to aggressively prosecute 100 different priorities and to deal with all the issues and interference that arises among them and so forth. Google has done incredibly well in a bunch of specific places, but it’s not like Google has done all the things, even if in some basic material sense, Google maybe had that ability.

So I’d say that the track record of that is checkered. And in general, I think that fear has been overstated. Now I think there is a more specific thing of just models themselves, forget the labs. Even if the labs aren’t particularly ambitious about expanding their scope. Just literally LLMs will obviate a bunch of, or agentic capabilities will obviate a bunch of specific verticals or tasks or something. Hard to say, obviously contingent on one’s forecast, it’s the model capabilities themselves. But in certain cases, I’m sure that will happen. And in certain domains it has already happened. Looking at the Stripe data, one thing I will say that I think is germane to people here, there are many more businesses getting started now than there were a year ago, as little as a year ago. Way, way more than were getting started five years ago. And actually the relative change between last year and this year is pretty much the largest relative change we’ve seen in any given year.

So for example, from 2019 to 2020, we saw a big jump, understandable during COVID. So February to April of 2020 or so. I think the growth rate inflected to maybe 50% or thereabouts year-over-year in terms of new businesses getting started. As I speak, the number of new businesses starting on Stripe is up around, it’s a bit under, but around 2X year-over-year, which again is the largest relative jump we’ve seen. And you might think, okay, fine. There’s way more vibe-coded, kind of lightweight slop, whatever. Fine, there’s more things, but are they actually succeeding? But actually, the median business is doing better this year than a year ago.

And then if we stratify it and look at the probability that any given business will reach some revenue threshold—a million dollars, $5 million, $10 million, whatever—those all seem to be getting better. The time-to-revenue for new companies incorporated with Atlas is declining. And so by all the objective metrics we can look at, it seems to be a better time than ever to start a business. And again, things can change. I don’t know what the world’s going to look like in five years, but speaking today on July 26th or whatever it is of ‘26, I think the Stripe data would suggest there’s never been a better time.

Harj: We see the exact same thing in the YC batches. Companies are just able to grow faster than ever. Certainly within the batch.

Patrick: Back in the old days when Harj and I were first starting out, getting to a million dollars of revenue—like runway revenue—was a big deal. People would know about that company. They’d be like, “I heard that X company got to a million dollars of revenue,” and now, I mean, that’s—

Harj: Yeah, you should be by your first month, it feels like. That’s an exaggeration for everyone here. But certainly within the YC part of the life cycle, like day zero to 90, it’s really being driven by, I would say, enterprises willing to buy from startups, which is the new thing. So you can sign these new contracts within the batch. You have the data as the companies keep growing. I’m curious, are there other factors that are driving these sort of inflected growth curves from one to 10 and 10 to 100?

Patrick: I think it’s really the dynamic you just mentioned, which is businesses everywhere are more spring-loaded to adapt and to try new things. And they have a real terror of being left behind with archaic and antiquated ways of operating. In normal times, you’re a new startup, you have some mechanism for doing whatever, and you pitch the CIO or the CTO or whoever at some company and they kinda don’t want to talk to you because your thing is not validated. Maybe you’ll be around in two years. All the obvious objections. But now people know that the risk of the status quo is actually extremely high. And so even if there’s risk in doing all the new things, this path also looks pretty dangerous. I really think there’s never been a better time for startups to sell and to have their products get adopted at pretty meaningful scale right out of the gate.

A lot of YC companies in recent times have demonstrated this, but I think it’s a really pervasive dynamic. And there’s a bit of it, I think, also. Stripe is not a consumer company obviously, but I think there’s some version of this on the consumer side where consumers are also pretty—consumers have complicated views on AI and maybe they don’t want the data centers, but people are very intrigued by the product. I think they’re kind of beguiled by them and there’s a predisposition and an openness to experimenting with the new.

Harj: Maybe just more broadly, something I’m curious about is, again, the data you have at Stripe. Has anything you’ve seen in that data changed a belief you have about AI broadly, say over the last 12 months?

Patrick: There’s a fear that AI is going to be this hegemonic, centralizing, totalizing force where a small number of companies gobble up a very large share of the economy. Many companies at the forefront of AI have done incredibly well and I think will continue to do incredibly well for sure, but based on what we can see at Stripe, the hunger and the intensity with which other companies are either getting started taking advantage of these new capabilities or existing companies are retooling, I don’t worry about the centralization in the same way. I think there are going to be many thousands of winners and, again, we try not to offer any definitive prognostications because the future is not predetermined, but based on the trend lines we can see, I think we are heading towards a more decentralized world and one with more broad-based prosperity.

Harj: Cool. All right. Well, I think that is all we have time for today. So thanks so much, Patrick, for being here.

Patrick: Thank you for having me. And it would be remiss of me not to say that Stripe would not exist without YC.

Harj: Oh, cool. All right. Thank you so much.

In 2001, Jeff Dean and Sanjay Ghemawat did the math and realized Google’s entire search index would fit in RAM — then shipped it in a few days, and search got fast. In 2013, another napkin calculation showed that three minutes of daily speech recognition per user would require doubling Google’s server fleet; that one became the TPU. At Startup School 2026, Google’s Chief Scientist talks with YC’s Diana Hu through the thought experiments behind both, why inference hardware is the next specialization, and where two or three people in a room can still win.

Watch on YouTube

Timestamps

00:07 — Are AI Models Already Junior Engineers?
01:44 — AI Systems That Improve Themselves
02:40 — The Google Search Breakthrough That Changed Everything
04:38 — AI Agents Will Run for Weeks
05:58 — The Napkin Math That Led to TPUs
09:20 — How to Find Breakthrough Ideas
10:25 — The AI Engineer’s New Mental Model
12:33 — Why AI Is Really an Energy Problem
16:11 — Context Engineering Is the Next Frontier
19:46 — The Skill That Made AI Better at Optimization
22:13 — Why Long-Running Agents Fail
25:21 — Where Startups Can Still Beat Google
31:19 — How to Become an AI-Native Founder
36:36 — Question Your Biggest Assumptions
42:08 — AI That Builds Better AI
50:02 — Build Something That Truly Matters

Transcript

Diana Hu: All right. Should we get started, Jeff?

Jeff Dean: Sure. Sounds great.

Diana: All right, Jeff, welcome. And again, thank you so much for being here, especially you just got a cold and thank you for being here.

Jeff: Yeah, I’m afraid I’ve lost my voice. I don’t normally sound quite like this, but we’ll do what we can.

Diana: So you built MapReduce, BigTable, TensorFlow, the TPU, Gemini. We could spend a whole hour on all the things you’ve done, but what I love is that you’re still making bold predictions in public. Last year, yes last year, in May 2025 at AI Ascent, you said that AI is at the level of a junior engineer. That was about a year ago. How close are we to that prediction?

Jeff: Yeah, I feel like the models have been getting a lot better at agent-based, longer-running coding tasks, and it seems pretty clear that they are now actually pretty capable. And depending on exactly your definition of junior engineer, it seems pretty spot on, I would say.

Diana: What did you underestimate from that prediction?

Jeff: I think the ability to do more and more complex tasks has been growing faster than I thought. And I also think outside of coding, these agent-based systems are really starting to shine in other domains. And I think that’s going to be an important trend in the future.

Diana: So give us another bold prediction. What do you think is going to be the 2027 edition?

Jeff: I think you will see a lot more automation of ML systems themselves, basically getting ML systems to improve their capabilities by running lots of experiments, breaking things down into sub-problems, running those sub-problems in a tight automatic experimentation loop, putting the results together, and being able to then get some improved system out from that fully automated problem decomposition and automated experimentation. I think that’s going to be really exciting. I think that also applies not just to ML, but also to other fields of science and engineering. Basically anything where you can have a measurable objective. I think you can actually make a lot of progress these days.

Diana: Now let’s go back a little bit in history. Way back in 2001, Google search used to run on hard drives. And you and Sanjay did the math and realized that at some point the whole search index would finally fit in all of the RAM of all the computers you had running. And you made that radical realization, and you basically, in a few days with Sanjay, shipped in production a whole new search version that worked in RAM rather than hard drive. And that was the thing that got Google to be so fast: Google searches. So history tends to remix. What is the ‘it fits the memory’ moment right now in 2026 that everyone in this room should be thinking about and designing?

Jeff: Yeah. It’s a little different, but I think you’re going to see more and more high-performance and low-energy inference hardware systems. Because I think everyone is now realizing that inference is the key to making these agent-based systems be available to more and more people. And that latency is really important, and that specialization of the hardware is a really key way you can make things that are more energy efficient and lower latency than more general-purpose computational devices like, say, GPUs or TPUs.

Diana: Because I think everyone here is used to waiting for responses on models.

Jeff: Waiting’s no fun.

Diana: Master of speed. So you’re saying, what if we don’t have to wait anymore?

Jeff: Yeah. Imagine what you could do with something where the latency is 50X better.

Diana: Interesting thought. Now, what’s one assumption that perhaps 6,000 people in this room hold as already false about AI?

Jeff: Yeah, that’s a good question. Probably one thing is people don’t quite realize how possible it is to have agent-based systems that can run not just for an hour or two hours on a problem you care about, but for some problem domains and with highly capable models underlying them, you can get them to run for days or weeks and do really, really complicated tasks. Some people are starting to see inklings of this, but I don’t think everyone has really internalized it. And that’s going to be a pretty big deal.

Diana: What’s a particular task that you have run that has run for weeks? What did you tell the agents to solve?

Jeff: You can tell agents to go off and implement completely new versions of software in different programming languages that might have better safety properties or better performance properties. And then they can go off and actually do that in a pretty serious way.

Diana: That’s pretty cool. Now, one thing that you’ve been very well known for is you’re really good at napkin math. Sounds funny. So one of the stories about you is that back in 2013, when speech recognition started to work at Google, you did the napkin math where if every Google user used their phone and talked to it and used the speech recognition system for just three minutes a day, you found that the system requires a Google server, you would have to double the fleet, which would be really, really expensive just to do speech translation.

Jeff: Yeah.

Diana: And instead you basically built a custom chip, and that was the origin story of the TPU.

Jeff: Yeah. We were starting to see really good quality results on the deep learning-based speech systems, speech models we were training, but they were computationally expensive compared to the old speech system, but they halved the error rate. So that was the equivalent of 20 years of advances in speech recognition in just a few months of fiddling with the model and scaling it up a bit and getting better data. We started to get worried that if speech worked a lot better, people would use it more. That back-of-the-envelope calculation was really about that. What if people start to use speech recognition more to dictate emails or to talk to their phone or whatever? It turned out that we realized we needed some better solution than running on CPUs at the time.

And so we came up with TPUs, which are very specialized for essentially low-precision dense linear algebra, which is at the heart of nearly all of the modern machine learning algorithms we use today. If you build a specialized chip for low-precision, dense linear algebra and can’t do anything else, that turns out to be really useful for machine learning inference, even though it can’t run Chrome or Word or whatever. That system produced a chip a couple years later that was 30 to 80 times more energy-efficient than CPUs and GPUs of the day. And also much, much lower latency, like 20 to 30X lower latency.

Diana: Which is incredible, what the foundation that TPU has become today. No way you would’ve predicted that TPU would be so foundational now with transformer architecture, which was invented way later, before you actually invented the TPU.

Jeff: Yeah. That’s why we built a general-purpose linear algebra system, which is what a TPU is, really. We knew ML algorithms were still evolving, and you didn’t want to overspecialize, but you wanted to specialize enough that you got the dramatic performance benefits of very big multiplier units, high-speed memory, and high-speed interconnect for later TPUs that brought many chips to bear on the same problem efficiently. We’ve continued to scale those up and improve their performance over many generations now.

Diana: Incredible napkin math. Napkins are good. So actually, what’s a good napkin math that everyone here who wants to be a future founder should run tonight to potentially build something as consequential as the TPU?

Jeff: Yeah. It’s always hard to say. Think about what problems you see in whatever it is you’re thinking about, what bottlenecks you see. Are there very different ways of thinking of the solutions to some of those problems that would get you an order of magnitude or two orders of magnitude better performance or capability or whatever it is? Sometimes if you just squint at a problem and think about not necessarily being anchored on exactly how that problem is solved today, but how you would solve it from first principles, you can come up with really good ideas that are maybe not what other people are thinking about.

Diana: That’s a good tip. Now for everyone here who doesn’t know, years ago, Jeff wrote a very famous list called The Latency Numbers Every Engineer Should Know. These are numbers around, for example, how long a cache miss takes, disk seek, a network packet traveling, let’s say from California to Netherlands. Lots of numbers like this about distributed systems and systems engineering. It’s been taped up and become the Bible for a lot of distributed systems engineers.

Jeff: Okay. Yeah.

Diana: Now, fast forward, that list is up for an update. Give us the AI edition for now, 2026.

Jeff: Yeah. If you looked at what is important in AI systems these days, you would want to know things like the bandwidth between your main memory system on your accelerator, to the on-chip memory, to the multiplier unit. You want to know how much energy it takes to do a single multiplier operation. What is the interconnect bandwidth between chips? How many chips can you connect with that bandwidth? If you go beyond that domain, what is the falloff in network bandwidth when you need to talk to 10,000 chips instead of 500? I think these are all really important numbers to learn and really affect how you think about solving particular kinds of problems.

Diana: And one interesting thing that I’ve heard you talk about is that nowadays, the unit that you measure everything is energy.

Jeff: Yeah.

Diana: You pointed out that doing a calculation of math costs about one picojoule, but moving the data and doing data IO costs a thousand times that.

Jeff: Yeah. Just bringing it in from HBM on an accelerator into the processor so it can actually compute on it. Yep.

Diana: That gap quietly decides what products are possible and how these algorithms and AI are built. So what are the kinds of problems that founders keep calling model problems, but are in fact actually energy or data IO problems?

Jeff: Yeah. I think the example you raised of a thousand X difference in moving data versus actually computing on it in terms of energy is a pretty significant one. It shapes a lot of aspects of what we do in machine learning. Because if you didn’t have that thousand X difference, then you wouldn’t have to do batching. But you have to do batching of many examples or maybe many tokens at once in order to amortize that data movement so that you can avoid paying a thousand X slowdown, but instead pay a thousand X divided by batch size energy cost. And for really low latency, batching is not very good. So I think these kinds of things and the energy behind various decisions in the computer hardware we use really affect a lot of decisions we make in building higher-level systems.

Diana: A very concrete example is just how training models is done. There’s this whole concept of batching the data sets and running epochs. That’s basically—people perhaps may confuse that as a model problem, but it’s really a systems data IO problem, right?

Jeff: Yeah. You have to assemble batches to get better efficiency in your hardware. Ideally you might do batch size one training, but it’s not as good in terms of efficiency. So people use pretty large batches these days.

Diana: Do you think it’s possible for—I know you’re well known for taking off on a long week or a weekend and coming up with this brilliant solution. Is there such a thing as Jeff Dean going and working on it for a couple of weeks and getting batch size equals one training done?

Jeff: Yeah, I’ve been thinking more about inference actually. I think inference is a pretty interesting problem because you do want very low latency. Training, you don’t necessarily need incredibly low latency. And I think there’s a lot of room for specializing hardware more for inference than we are today.

Diana: What are some of those interesting things that are on inference that you’re really thinking a lot about?

Jeff: Just trying to minimize data movement, trying to think about incredibly low precision operations and maybe not supporting lots and lots of different kinds of precisions. If you feel like you have a good answer for what kinds of precision you need, maybe just build that into the hardware and not much else.

Diana: Which I think brings down to a core analogy I heard from famous computer scientists that really the whole process of AI is a big compression problem. Because in order to have the data to be fully lossy and compress it and then restore it, you basically need to understand it.

Jeff: Yeah. If you truly understand the data, you should be able to compress it really well.

Diana: And now transformer architecture is basically one of the ways that has turned out to work really well.

Jeff: Yeah. Yeah, I would say.

Diana: Working pretty well so far.

Jeff: Good work by my colleagues.

Diana: Yes. Now let’s zoom out a bit. AI progress used to mean just better models. You had more data trained, bigger models with bigger parameters. But increasingly in the last year or so, it’s everything around the model, not just the model size and number of parameters or more data. It’s everything around things like retrieval, tools, memory, agent tools. And it might get consolidated into what people call context engineering, right?

Jeff: Yeah. I think the model is really only one piece of what you’re trying to do, which is build an overall system that can solve really interesting problems. And that involves a model that knows how to use various tools. It maybe knows how to retrieve relevant information, maybe has a history of other information that it has retrieved for past problems. And it can put information into the context of the model. The nice thing about that is that information is really clear to the model. Unlike the training data the model was trained on, where it’s all trillions of tokens stirred together into a soup of hundreds of billions or trillions of parameters, but it’s all less clear than the actual context that the model sees directly for this particular problem or use case. And then I think being able to understand what tools are available, which ones are going to help the model solve this next phase of the problem, how to decompose a problem into a sequence of tool calls, maybe trying multiple approaches to solve the problem and seeing which ones work and being able to evaluate that.

This is the whole orchestration of complex agent and multi-agent systems that I think is going to be more and more important and super exciting times, I would say.

Diana: And I think the fun thing about this particular problem domain set is actually something that everyone in this room can do because before, to train a model, you needed an incredible amount of resources, an incredible amount of access to GPUs and data. But for context engineering, everyone here could do it. You need the API to something like Gemini and then work on your own setup for your own retrieval, your own tool calls, et cetera. So what are some tips for everyone here? How does everyone get better at and become exceptional at context engineering?

Jeff: Yeah. I think a really good way to do it is to use these models, harnesses, and tools to try to solve problems. Sometimes you can actually see where the models are failing. Often, you can make the model work better and succeed at that kind of problem not just by adjusting the model parameters, which is hard to do from the outside, but by creating better guidelines for the model—writing skills for the model to know how to use different tools that would be incredibly useful for solving this particular class of problem. As you do that, you end up with this kind of improving, self-improving setup that you’re trying to use to solve things. That’s a really good way to get better at understanding what additional information the model would want in order to become more capable.

Diana: Can you give an example of some context engineering you personally have done? Skills you wrote, tools that really made a huge difference in your workflow?

Jeff: Yeah. I mean, I guess Sanjay and I were working a few weeks ago, and we often do some amount of performance improvement for very low-level libraries. We have a microbenchmark library we’ve written at Google where you can write microbenchmarks of how long different kinds of operations take or how long it takes to populate a data structure or whatever. Sometimes those data structures are used on millions of processes across Google, so it’s actually pretty important to make sure they’re high performance. You can write microbenchmarks, but then without an agent-based system, what you usually do is measure what the current performance is on some benchmarks you care about, make some modifications to improve the performance you hope for, then rerun the benchmarks to see where things improved. You run maybe a broader set of benchmarks, measure the cache footprint of things.

So we wrote a skill that basically taught the model how to do most of those things in various sequences so that it could actually do self-improving benchmark measurement, benchmark code changes, measure the performance improvement, and then iterate on that. That seemed to work pretty well for some kinds of problems. It really just is us giving the approach we would use as people to the model in a form that it could use.

Diana: That seems very impressive. So you’re saying you have this skill that if someone got access to it, it could perform optimizations like Jeff Dean. Seems like the world would love this and is worth an infinite amount of money. Does someone have access to this?

Jeff: Oh, we actually published a document maybe a few months ago called Performance Hints that Sanjay and I wrote. It’s a 30-page document about various kinds of performance tricks. Some people have taken that and given it in summarized form to various models and seen that the model can now get better at reasoning about performance issues and code.

Diana: So you heard it all here. You could actually optimize your own code like Jeff Dean if you take this paper that you published and perform the hints. It’s all freely available. So you should all try it. Very cool.

Jeff: Yeah.

Diana: We’re talking about agents. Everyone here is probably building one or has built one at some point. I’m sure everyone has seen their agent go off the rails at perhaps step 30 or 40. Agents are great up to step 10 or so, and then it gets shaky at step 50. What do you think is the constraint today? Is it context, evaluators, or just errors that compound because it’s basically an open-loop system?

Jeff: Yeah. Obviously we want agents to be able to run for very long periods of time because that’s how they’re going to solve more and more complicated problems. But as you observe, today they sometimes stop working after 10 interactions with the tools and so on. Sometimes that’s because the model is trying to do something it doesn’t have a lot of experience doing. It’s been trained on a whole set of things, and as soon as you get a little bit off the distribution of things it knows how to do, then, like most machine learning models, its performance will suddenly start to degrade. The farther you get off the comfort zone of what it knows how to do, the more likely it is to not work as well. There’s a bunch of things you can do. One is give the model skills and hints that tend to keep it in the more brightly lit path of things it does know how to do.

I think having multi-agent systems where you have multiple agents trying different approaches, and maybe another model or agent that’s evaluating which ones of those seem promising, is another way to, in some sense, search the space of possible solutions and stick to the ones that seem most promising and discard the ones that didn’t seem to work or maybe that went off the rails. That’s a very useful general technique: inference time compute to perform search over plausible ways of solving the problem that can get much higher performance or much more reliability in long-running agent flows.

Diana: How are some ways you implemented this particular workflow for your agents internally?

Jeff: Yeah. We have harnesses, and then we have a whole set of skills, particularly in the internal Google development environment. We have skills so that the agents can know how to use lots of our internal tooling for coding, code reviews, measuring performance, or fetching log files. Those are just skills that you can add to make the base model more capable. Even though it hasn’t necessarily been trained on exactly the way that Google internal engineers would fetch log files from our proprietary system, with the right kind of skill definition, you can actually get it to work. That improves the usefulness of the agents.

Diana: Now let’s talk about where startups can win. This section is one that I personally care a lot about because everyone here in this room needs to decide what to build in the future if you’re a future founder. The thing about Google is you co-design everything on the system, from the processors to the products. Which are the layers that someone like Google would keep building and compounding, being better, and where does a two- or three-person team still win?

Jeff: Yeah. I mean, I think obviously Google and our Gemini models and our hardware infrastructure are really trying to build very general models that can do almost anything. But in a lot of cases, that means we don’t have a lot of attention on particular domains where perhaps a really well-designed surface and maybe a model and set of skills, or maybe a specialized model that isn’t in the general mix of things that our models do well, can actually have a significant advantage. Because you can build something delightful and really high accuracy here, really high quality for a domain that you are really passionate about. And I think that’s where the two or three people in a room building that, that they’re really excited about, can have an advantage. But I would also caution that the general models are definitely getting better at a broader and broader range of things.

So you have to figure out, is that thing you’re working on going to be a durable thing, or do you think the models at the forefront are going to get better at that in the next six months or 12 months? Or is it something they’re not going to be able to do for a couple of years or three years? And you want to weigh that as you’re deciding what to work on.

Diana: Let’s dive deeper into this. So the general models, of course, you’re going to keep working on and keep making them all better. And how should the audience reason about what are those areas that it doesn’t? How should a founder think about things to pick on and work on?

Jeff: Yeah. The most important thing is to pick something you’re super excited about and want to build and you think would be useful in the world. If you do that, you’re already way ahead than if you wake up and you’re like, “Oh, I don’t really want to do this,” or you’re going to build something that is actually not that useful to the world or to many people. So I think that’s the number one selection criteria I try to apply for what problem should I work on next. Second, I think you want to look at what the current more general models can do in that problem domain. You can test them with, are they able to do this thing very well? And if they’re completely failing, that’s probably a good sign. If they’re kind of able to do some of it but not very well, that’s maybe not a great sign because that’s probably a sign that the capability is starting to be present in those models.

And with more training data or larger-scale models or whatever, it’s likely to get better. So look for something where the model succeeds 0% or 1% of the time, not 20%.

Diana: How do you find those? Are those things effectively out of distribution from the training set? And what exactly is the problem shape that fits that?

Jeff: Yeah. I think sometimes it’s a product that you build that might have access to particular kinds of data that the underlying model might not, a general model. So it might be you’re building something to help users organize all their own personal information and the model won’t necessarily have access to that. There you can have a big advantage because all of a sudden your model or your product has visibility into important data. It could be some incredibly hard problem where if you get the right training data and you can train a more specific model than a general-purpose one, you can actually do that in a very affordable way. Maybe it doesn’t take that much compute to train a niche model for this particular problem, but you can get something that’s highly accurate. That can sometimes be a really good building block for solving an important problem that is maybe not handled very well by the general model.

Diana: I think that’s interesting. I think there are basically two paths. The first path is a little bit funny, is you guys are organizing the world’s information. That’s probably kind of well covered. But organizing your personal information that’s open, which is funny. And then the second path, you talked about more specialized models in certain domains. Can you tell us more about what are some of these domains?

Jeff: Yeah. I mean, I think if you look at my colleagues’ work on, say, AlphaFold, that was a very specific model for protein folding. And it was highly successful and was able to really handle that domain quite well so that all of a sudden you now have this amazing tool and model that can give you answers to questions about proteins and their structure really effectively. But it’s not a general model. It’s a very specific one. And there are other, I think, domains where that kind of approach can work really well, maybe in material science or chip design or things like that, that will enable you to leverage the capabilities of a very accurate but niche model to do things that are hard today.

Diana: That’s a good example. So if some of you find a problem that’s similar in shape, like AlphaFold, it could be a good problem to work on. Now let’s assume you found a problem to work on. We’re going to talk a bit about how you become an AI native founder. How do you really become good at it? You in the past said that managing a fleet of agents, say 50 or 100 agents, is all about writing really good, crisp design docs or specs. And how do people get good at that? What do those look like?

Jeff: Yeah. I think you’ll have a lot more success when working with your virtual agents if you can clearly specify what it is you want. The clearer you are on what you want, the more the agent will have guidelines and rules—an outline of what it is trying to accomplish. Whereas if you don’t specify very much, the agent has to infer what you meant. In many cases, it might infer things that are different from what you imagined. We’ve always told computer scientists from the very beginning that it’s really important to specify what the software you’re writing is trying to accomplish before going and writing it. Now we actually have agent-based systems that can do the writing, but the importance of specifying what you want has actually gone up, because before you’d be handing it off to a very intelligent human who maybe has context or can ask you follow-up questions.

Agents can sometimes do that, but I think clear specifications are a really good idea. To give you an example of a use of a coding agent that works extremely well: you can ask today’s models to translate software from one computer language to another very effectively. In that case, you actually have an incredibly detailed specification. You have the whole software that says what the system is supposed to do. So if you have a Python implementation of something and you want a Go implementation of it, that is something that the models seem incredibly capable of doing these days. They can take all the tests that are in Python, make sure they pass in the Go version, translate the tests to Go, compare behavioral differences between the implementations until there aren’t any, and be highly effective because that spec is so clear.

Diana: Now let’s assume every founder gets good at running hundreds of agents at the same time and all the code is written for them by the agents. What becomes the scarce skill?

Jeff: Yeah. I think it’s really having incredibly good taste in what you ask your agents to work on. That is the crux of, from my background, a research problem. A researcher can have all the tools and all the techniques, but often most of the battle is what problem are you going to spend your time on? If you pick the problem well and succeed in solving it, that’s way better than if you delightfully execute a research investigation into a rather boring problem. That high-level wisdom of what to work on is incredibly important. I think models are not necessarily going to be that good at it. So you’re going to have people steering a lot of AI-assisted computation in order to accomplish great things more quickly. But that essence of what it is you want your models to do is the key thing you should focus on.

Diana: So let’s talk a bit more about taste because it gets talked about a lot right now in this current era with agentic coding. How do you exactly build taste and do that? That sounds so esoteric. How do you make it concrete?

Jeff: Yeah. It is a difficult thing. It’s not like there’s a measurable objective of taste in a lot of cases. I think some of it is from experience. Working on a lot of different problems in the past teaches you about what kinds of problems might be interesting in the future or what kinds of things might be just barely possible by cobbling together these previous approaches, and then some open problems you might have to work on in order to get to something magical or highly useful. Another way you can get more experience for yourself is to just write down a bunch of things you think might be important in the next 12 months. Maybe you pick one of them to work on, but go back and evaluate in 12 months which of these other things actually seemed important, or which ones did other people in the world go out and create, and which ones did not seem to happen yet.

That can give you a lot more samples for your own taste creation capability. And that’s an important skill to have.

Diana: I think a third way we were talking earlier was doing very crazy thought experiments.

Jeff: Oh yeah. That’s another good way. Sometimes it’s good to not take as a given things that most people seem to take as a given. I was doing a crazy thought experiment with some colleagues the other day: for 60 years, the whole silicon chip design and fabrication industry has done tremendous work to make smaller and smaller scale transistors that are very low error rate. The assumption is that every chip we manufacture of the same design should be identical to every other chip.

Diana: You don’t want any bits to flip.

Jeff: No bits should flip.

Diana: Deterministic.

Jeff: There are all kinds of error margins built in—memories have ECC memory these days. At the macro scale, we don’t make that assumption when we’re building large-scale distributed systems. We build reliable, large-scale distributed file systems out of unreliable parts. Individual disks can fail, but your data should be safe. So we have mechanisms at a higher level to enable us to have three copies of the data on three different machines and three different racks, so that if any rack switch or individual machine or disk fails, you still have your data. We have Reed-Solomon encoding techniques, but we don’t seem to do this at a really extreme level at the transistor scale of the technology we’re working on. So basically, an interesting thought experiment is: what would happen if you tried to build a system out of transistors that might have 20 errors per day.

Diana: Oh my God.

Jeff: Rather than one every million years. That would be a very different design point and might enable you to do really interesting things in the fabrication side of things. You have very different design methodologies because if you want to get a signal from here to there and you have these super unreliable transistors, you might have very different ways of signaling. You might send it along multiple redundant paths in order to make sure that it gets along one of them. And I think that would be a pretty interesting set of thought experiments. I’m not saying we should go do this, but that’s the kind of thing where you do want to occasionally question assumptions. Now, oftentimes these thought experiments don’t work out because there are very good reasons that for the last 50 years we’ve done this thing this way and not that way. But it’s good to revisit those every so often.

Diana: That is so wild. It’s starting to rhyme a lot with neuromorphic computing or the human brain and how nature works.

Jeff: Yeah. Exactly. Signals in our brain are not especially reliable from getting one place to another. And so I think in brains, when there are really important things you need to get from one place to another, there are multiple pathways that enable you to do that.

Diana: You have such an impressive career. What is one of these crazy assumptions that you threw out of the window that actually built a consequential system in the past?

Jeff: Yeah. I guess—

Diana: That worked out, actually.

Jeff: Yeah. I think, well, TPUs is a good example. Being able to specialize hardware for a very niche problem domain before that problem domain seemed as important as it is today is one thought experiment. I think the origin of MapReduce is another good example. So we had worked, Sanjay and myself and a number of other colleagues had worked on various iterations of the crawling and indexing system at Google. And we’d written lots of hand-parallelized code with lots of checkpointing to make sure it would be robust and reliable if it was running on a hundred computers or a thousand computers and some of those died.

But that code tended to be intermixed with the actually relatively simple thing you often were trying to do. I just want to look at all the contents of all the webpages and then compute on the side mapping from URL to what language is this page in? It’s the text of this page. And it would get obscured by all this other code for parallelization and reliability. And so we remembered our training in functional languages and realized we could squint at those problems and develop this MapReduce abstraction that you could have above this implementation. And then below the implementation, you could put all the checkpointing and reliability mechanisms into that lower-level library that everything could then build on. And so that became a hugely successful way of dealing with very large-scale computations at Google in a robust and reliable way from that thought experiment of, well, if we squint at it, could we find lots of problems that fit into this abstraction?

Diana: That’s impressive. So this thought experiment led you to create MapReduce.

Jeff: Yeah.

Diana: Awesome. Now let’s go back to- you talked a bit about your interest right now in working on a lot of customized hardware. So right now AlphaChip lays out chips. Now you also got AlphaEvolve that proposes solutions, evaluates them and keeps all the ones that work. Seems like you’re starting to build all these systems that can compound and build AI that builds AI.

Jeff: Yeah. I think more generally there’s the foundation of the scientific method where you propose an experiment, you implement what you need to run the experiment, and you evaluate the experiment, and then you get results from that. I think there are more and more problems that are now possible to implement where that whole loop of running not just a few experiments, but running many, many experiments because you’re able to automate that loop and make the latency of that loop extremely low is going to be really, really important. It’s going to enable us to tackle lots of different problem domains in science and engineering and machine learning model design itself and also in engineering tasks like designing chips. If you can actually do those things in an automated way and have some orchestration framework that can take very high-level objectives and break them down into sub-problems, and each of those sub-problems can be one of these automated loops that is exploring the best way to solve that sub-problem.

And then an orchestration framework that can put together sub-problem solutions into the overall solution for the higher-level problem. That’s going to be really impactful, and it’s really, really important. I think it’ll enable us to accelerate machine learning progress. It’ll enable us to accelerate science and enable us to accelerate engineering. I think that’s going to be amazing.

Diana: That sounds awesome. It sounds like a lot of fields basically where you can have very good evaluators and maybe adjacent to things that can be formally verified. Those are ripe for AI systems that can self-improve.

Jeff: Yeah. I think in a lot of cases, sometimes your evaluators need to be made much faster. As an example, my colleagues did some work maybe a decade ago on some problems in quantum chemistry where you’re trying to understand the properties of a particular molecule, and you can generate some molecule configuration, and then you want to understand what properties it has. You can run a very computationally intensive density functional theory simulator, which is something that might take a night of computation to tell you the answer for one thing.

But what my colleagues did was take a bunch of output from those simulation runs, the input molecule configurations and the outputs of the expensive simulator, and then use it to train a neural approximation to the simulator. So this is now a validation device, but instead of it taking a night, they made something that was 300,000 times faster and nearly as accurate as running the full-scale simulator. So now that completely changes how you would do science, right? Because now you have 10 million things to screen. You could do that while you go to lunch rather than it being a six-month endeavor where you try to scrape together enough compute to run all these simulations. And I think there’s a lot of room in a lot of domains for much faster validation models, possibly learned validation models that can get you an approximation to the true answer much more rapidly.

And that changes how those experimental loops can be thought of and how quickly you can go around those loops.

Diana: What are some of the spaces and problems that you’re super excited that this super sped up scientific method is going to solve or achieve? What particular problems or spaces?

Jeff: Yeah. I mean, I think, well, clearly machine learning itself is one. So can we have a model that is able to recursively self-improve itself by running lots of experiments? And if you think about how models are improved today in large research teams, what usually happens is people think of some ideas, they run a bunch of small-scale experiments, they see if those small-scale experiments worked out well. If so, they take the most promising ones of those, they try them at larger scale and that gets then evaluated. And then the results get integrated together into a new recipe for your model. But I think there’s no real impediment to making that be a much more automated loop where the model itself decides it’s going to explore or maybe with a nudge from some people at the various highest level like, oh, why don’t you try some new ideas around model architectures that incorporate this?

And then they will go run lots of experiments, see which ones work, and then those will get incorporated at a much more rapid rate. And effectively you want to optimize your discoveries per unit of compute input.

Diana: Very cool.

Jeff: Yeah.

Diana: Now going back to the room, as all of you will become at some point founders or start your careers, you will probably collect lots of rejections. That will happen. It has happened to you too, Jeff. There’s a story that in 2014, you, Geoff Hinton, and Oriol Vinyals wrote a paper on distillation, which has to do with taking a big teacher model to train a much smaller and more efficient model that’s a lot cheaper to compute, with fewer model parameters. And it has become a trick that everyone is using right now in industry.

Jeff: Yeah.

Diana: And the thing is, this paper got rejected at NeurIPS.

Jeff: Yeah. I mean, I think I don’t fault the program committee because a lot of times a paper gets three reviews and someone will look at, one of the reviewers will look at it. And in this case they said, oh, it’s unlikely to have significant impact.

But I think when we wrote the paper, we actually saw this was a super important problem because we knew making cheaper, highly capable models from larger-scale models was something we desperately wanted to do because we wanted to serve models to more and more people in many different domains like speech or vision. But sometimes the reviewer maybe didn’t have that experience because maybe they’re not thinking about large-scale AI services and are thinking about, is this a fundamental advance? So it gets rejected every so often; that’s fine. We put it on arXiv, people read it, people use it. It’s all good. And we do use it in making our flash models, for example, from our larger-scale pro model. That’s partly why our flash models, for example, in Gemini, are so capable relative to their size and speed.

Diana: They’re some of the best in the benchmark for their model size class, which is impressive. And I think part of the lesson is that even if you get rejected, keep going.

Jeff: Yeah, that’s the lesson I would distill from that.

Diana: Now, I think the fun thing is that when you joined Google as a 20-person startup back in 1999, now if you were to take the young Jeff Dean from way back then to transport him to now, today, in this era with your skills.

Jeff: I’m feeling so vigorous and young now.

Diana: What would you do? Do you join a frontier lab, start a company? I don’t know. What would you do with Jeff Dean today, 25-year-old Jeff Dean?

Jeff: Yeah. It’s always hard to say, and it’s a very personal choice of what it is you want to spend your time on. To me, some of the most important questions are, are you going to work on something you really care about? While you’re working on that, and if you’re able to make progress on it with a bunch of colleagues you like working with, if you’re able to collectively solve it or make progress on it, will that make a difference in the world in some positive way? Will you suddenly be able to do something and offer that service to, you know, maybe it’s a very niche thing, but it will tremendously help biochemists or something. Or maybe it’s a broader thing. It’ll help programmers, or it will help all consumers on the internet or other things.

What you should strive to do is to have impact in the world that is positive and to work with people you enjoy working with and to work hard and do your best. So in terms of, say, the particular trade-off you offered—joining a frontier lab versus starting a company with just one or two or three of you and your close friends—I think those are different experiences. In a large established organization, you have some structure, you have lots and lots of amazing colleagues who know lots of things you don’t. You have lots of interesting problems that you can work on. And you already have a platform for impact by your work influencing lots and lots of people in the world already. And then as a very small startup, you have to have something you’re passionate about. And there’s a lot of risk in working on that particular problem in a way that you’re going to succeed and you’re going to grow and endeavor in order to do that.

But that can also be incredibly rewarding, I would imagine. So I think it’s really up to personal taste, but at the very least, regardless of what path you take, ask yourself, “If I work on this problem and the best possible outcome happens, will the world be a lot better in some way? Or will the world go, eh, that’s kind of cool, but whatever.” That’s not the kind of thing you should spend your time on.

Diana: Now let’s talk a bit more about that second path of working with people that you really like in a small team. You’ve been able to be an incredible mentor and manager to many, many engineers, and you’ve been able to build huge systems. What are some of the lessons for everyone here on how to get the most and how to work with smart people or find smart people?

Jeff: Yeah. You always want to find people who have really good skills in some area that’s needed in a team you’re trying to form, whether that’s inside a company or starting a company. But you also want to find people that are people you delight being around because you’re going to spend a lot of time around people working on really hard problems. And you want people who are low ego, that are team players, that have complementary skills to your own, perhaps. I always find working in a small team where people know things that I don’t know and where maybe I have some skills that other people don’t have as much of is super fun because you’re collectively building something or working on something that none of you could maybe do individually. But in the process of working on that, you actually gain a lot of new knowledge and new skills for yourself, and so do they.

And you want to view your engineering or research career as having an amazing tool belt of techniques. You always want to be adding new tools to that tool belt because you never know when you might come across a problem where you need these four specialized tools rather than these three. Adding more tools makes it more likely that the problems you encounter in the future will be solvable by you.

Diana: Now, one last thing, I’m pretty sure someone in this room or multiple people will eventually build something as consequential as you’ve done with MapReduce, TPU, distillation, et cetera, et cetera. What problem do you hope they would be working on?

Jeff: Oh, yeah. I think there’s a lot of interesting problems in the world. I’ll just rattle off a few. This is not exhaustive because the world is a very big place and full of problems. I’m particularly excited about new approaches to hardware. That thought experiment there was kind of an indication of that, or much more efficient inference hardware. I think there are radically different kinds of algorithms for machine learning that might be much more data efficient than the approaches we’re using today. If you think about our large-scale models today, they probably see a thousand times as much data as a human does by the age of 18. Yet the human by the age of 18 is better in a lot of things and on par with those frontier models that have seen way more data. So could you come up with much more data-efficient systems that can learn continuously, learn from their own actions?

Continual learning is a really interesting thing. I think multi-agent interactions are interesting. Creating ways of having better discourse among people in the world could be interesting. Are there ways to have much more civil conversations and help people meet others all over the world that they should know based on their interests? These are interesting things, I think. There are lots of cool things in the world, and we should all strive to make even cooler things occur.

Diana: That sounds wonderful. Thank you so much, Jeff Dean. That’s all we have today.

Jeff: Appreciate it. Thank you all.

Training and inference are pulling apart — different chips, different data centers, different everything. At a special kernels-and-chips edition of YC Paper Club in Mountain View, host Francois Chaubard convened five researchers on where the remaining performance is hiding: multi-GPU kernels, intelligence per watt, whether AI can write kernels, heterogeneous inference infrastructure, and running an entire game engine on the GPU.

Watch on YouTube

Timestamps

0:00 – Francois Chaubard: The case for chip and kernel specialization
7:16 – Stuart Sul: Parallel Kittens - Systematic and Practical Simplification of Multi-GPU Al Kernels
21:29 – Jon Saad-Falcon: Intelligence per Watt - Measuring the Intelligence Efficiency of Local and Cloud AI
31:05 – Mark Saroufim: When Al Starts Writing Systems Code
47:04 – Misha Smelyanskiy: Why AI Inference Needs Heterogeneous Hardware
1:04:33 – Brennan Shacklett: Building a High-Throughput Game Engine that Runs ENTIRELY on the GPU
1:15:35 – Wrap-up & what's next

Transcript

Francois Chaubard: Welcome to YC Mountain View, a special edition of YC Paper Club. Some of the feedback was about making it theme-related. So today it’s the YC Kernel and Chip Club. The trend I see in the lab with Stu and Jon, which we talk about all the time, is this specialization that’s happening. We saw it with TPUv8, the I and the T version, zebrafish and sunfish—is that what it’s called? To make an ASIC, you need such activation energy, and there wasn’t enough demand for there to be such a split, but we just see that at the chip level, there’s going to be massive specialization. The specs you would need for a training data center are going to be very different than the specs for an inference data center. You don’t need any bandwidth in and out for a training data center.

You can literally send a spaceship to the sun, come back with a weight file, and it’s the same, right? You can’t do that with inference. There are so many things like that that we’ll talk about. And there’s so much juice left to squeeze on the CUDA side, on the kernel side. I’m really excited to have some folks talk about that. And there’s juice to squeeze on the algorithm side. Do we need to go to the big heavy model every single time for every single query? If I’m asking what one plus one is, why do I have to do N FLOPs every single time? So there’s so much juice to squeeze still on the algorithm side, on the software side, on the chip side, and on the data center side. First, we’ll have Stuart Sul out of my lab at Stanford, one of my lab mates.

Which is the strip mall research lab now. Used to be called Hazy, formerly called Hazy, research scientist at Cursor and trains Composer. Then we have Jon, CS PhD lab mate with me as well, also co-advised by Azalia Mirhoseini, focused on LLMs, MLSys, and hardware. He really pioneers this idea of intelligence efficiency—intelligence per watt, intelligence per joule. He’ll be talking about that. Then we have Mark coming up next, a former PyTorch maintainer, co-founded GPU MODE with my friend Casey Aylward, and is co-founding Core Automation with OpenAI VP Research, Jerry Tworek. Then Misha, hardware-software co-design, has been working on that for two decades and ran AI infra at NVIDIA. Also worked on hardware-software co-design at Meta, and is founding a very exciting new company as well. You’ll hear about some of it. And then finally, Brennan, who I also met at Stanford, is not in my lab, but having done a lot of RL working on self-driving cars and things like that, it’s amazing how much of simulators, when you call environment.step, is still run on the CPU.

And so that’s usually the bottleneck for a lot of your on-policy rollouts, which makes—let’s call it RL is now taken over by RLHF terminology—but classic RL very, very difficult. And so using GPUs to do weird shit, as he says. He’s one of the best people at doing weird shit with GPUs. I’ll just give two slides on my high level. I’m not the person that knows about this stuff the best at all. But from my vantage point, we’re going to see this proliferation, and we have sufficient demand now because there’s so much demand for tokens that it makes sense to specialize at the chip level. That will pay out and allow you to go through the full new product introduction on the ASIC for specialization. And I think the Zebrafish, Sunfish, TPU, V8 is the first that we’re seeing of this. But I think it’s going to get much, much more split out.

We already do see it a little bit where a lot of the stack for inference—people will go to NVIDIA for prefill and then they’ll go to Cerebras for decode engine. And so that’s already splitting out. But there’s another one that people really don’t talk about, which is batch size one inference. And I think that when latency really, really, really matters—for example, voice agents, when you get on the phone call, and it says, “Hi, how you doing?” and it waits eight seconds because it has to go through this whole process. And it’s like, “Oh my God, well, they’re prioritizing throughput.” And it’s like, “Well, that’s not good. It’s not going to work.” And if they were prioritizing batch size one, they’d run out of GPUs, and it’d be so expensive. And so that’s a chip issue. And so we can solve those types of things.

And then on the data center side, equal amounts of specialization, especially if you’re going to use different chips for each data center. So the primary metric that you care about if you’re training models is basically time per step. And you want to train up bigger and bigger models. The location—you just don’t really care where it is. It doesn’t really need to be close to users. You can put it literally at the sun, like orbiting the sun and just training, training, training. The types of GPUs, the interconnects, you’re going to have to have all-to-all communication. You have to pass around a lot of gradient. And for inference, you have to have all-to-all just for the MoE, but other than that, you don’t. And so you can shard much more nicely. There are a whole bunch of other things to consider that justify splitting it out.

And then our speaker’s going to go much more into detail on that. The next one on 7/29, we’ll do a robotics-focused one. There are a bunch of YC companies that might actually bring some robots too. Ironically, this is how YC actually got founded. The original story across the street is that Trevor Blackwell was starting a company called Anybots, which is the robots right over there. And he had some extra space, and PG asked him if he could take over some of the space on Tuesday nights to run this thing called Y Combinator. And then went across the street, and then YC took over all of the Anybots stuff. And so it’s pretty cool to bring that full circle. And then for the next one after that, I love your feedback on what we should do. Maybe this is an idea—working on RLVR and some of the latest.

Everyone’s talking about these distillation attacks and things like that. It’s actually not clear to me what the distillation strategies that people are really trying that are successful out there. We were talking about it a lot in lab today. It’s not clear what the optimal strategy is—if you had a weight file, how to distill from it, or if you just had an API, how would you actually do it? This is the way that I was explaining to the lab about what I think is happening right now: Claude motherbirds into Kimi 2, and then now Kimi 2 is post-training Thinking Machines. And so it just keeps going and going. Now I’ll hand it over to Stu. Everyone, welcome Stu.

Stuart Sul: All right. Hello everyone. My name is Stuart. I’m a CS PhD student at Stanford. I’m also a researcher at Cursor, where I train Composer. Today I’m here to talk about ParallelKittens, which is our work on making multi-GPU AI kernels simple and fast. One quick note before I begin: the final deliverable of this paper is a CUDA framework that we refer to as ParallelKittens. But the goal of today’s talk is not to promote my open source library, but rather to convey the set of lessons that I learned while I was doing this work, which is a mental framework for thinking about multi-GPU kernels and GPU networking in general. So I hope you’ll walk away with the same set of insights that I was able to gain. Let’s try to motivate this a little bit. Over the past few years, the ML systems community has devoted a lot of effort into single-GPU efficiency.

For instance, we have IO-aware algorithms like FlashAttention, linear attention models, mega kernels, and many programming libraries and frameworks for writing efficient kernels across many architectures. These works mainly helped us squeeze the most out of the single GPU. Thanks to all of these efforts, what we now believe is that GPU networking is the major bottleneck that’s remaining, and that there’s a lot of exciting opportunities left in that area. For example, networking can still consume up to 50% of total runtime for workloads like Llama prefill. Obviously, this number can vary wildly depending on the workload. But the point I’m trying to make is that networking weights GPU utilization. So the standard practice nowadays is to overlap inter-GPU communication with intra-GPU operations like memory access and compute. The granularity of the scheme has gotten much smaller nowadays. It used to be we overlapped the transfer of entire tensors or matrices.

Nowadays, we do it at tile or even token granularity, meaning it’s a few kilobytes or even less than one kilobyte of data. On the other hand, hardware advancements have been quite exciting for networking. For instance, we have this thing called in-network compute. In the past, if you wanted to implement a collective operation like AllReduce, you needed to implement an algorithm where the GPUs do some arithmetic on local data, send the results to peer GPUs, repeat that N number of times, and then you end up with the results. But with in-network compute, you can offload all of that arithmetic communication to the networking fabric, and the GPUs are free to do whatever useful computation they need to do. You also have asynchronous bulk device-initiated networking, which was not possible a few generations ago. And you also have scale-up architectures like NVL 72, which packs 72 GPUs inside a single NVLink domain.

Soon, this is going to extend to hundreds of GPUs. The problem we are interested in solving under all of these settings is that it remains very difficult to write multi-GPU kernels that, one, do fine-grain overlap of compute and communication; two, exploit all of these exciting recent hardware characteristics; and three, stay simple and easy to maintain for both humans and AI agents. I emphasize that it’s the conjunction of these three characteristics that makes this problem especially difficult, because you currently roughly have three alternatives. One is to use off-the-shelf libraries like NCCL, which only expose coarse-grain communication primitives and leave a lot of bubbles in the hardware execution. Two is to use compiler-based approaches, but we find these compilers to be quite suboptimal. They produce kernels that are sometimes slower than non-overlap baselines. Or you can use low-level primitives like OS interprocess communication calls or PTX assembly.

These often require reverse-engineered understanding of the networking hardware. In general, they make code really complex and hard to maintain. So the main question we are asking here is: is there a small set of principles or trade-offs that clarifies the multi-GPU AI kernel design space? And can we use that understanding to build a minimal set of programming abstractions or primitives that really simplify writing efficient multi-GPU kernels for production? PK, or ParallelKittens, is the answer to this question. Before we get to PK, let’s quickly cover the GPU fundamentals for those who are not familiar. Here’s a very simplified view of a GPU. Inside a GPU, you find this thing called an SM, or streaming multiprocessor. An SM is very similar to a core on a CPU in that it performs arithmetic, logical operations, and sometimes matrix multiplications. They’re the juice of the GPUs.

They have all the FLOPs, all the compute you want. Naturally, you have a lot of them. On Blackwell GPUs, you have 148 SMs. On Hopper, you have 132 SMs. In order for these SMs to perform computation, you need data. So you have the memory system, the crossbar, the L2 cache, and the HBM, which serves as the main memory for modern GPUs. You need something to initiate operations on the GPUs, so you connect the CPU and GPU through PCIe. On data center servers, you usually want multiple GPUs, so you have many GPUs. In the past, if you wanted these GPUs to communicate with each other, you had to make the data go through PCIe. But PCIe is a shared resource. It gets congested. It’s relatively slow. So we have NVLink, which allows direct communication of data between the GPUs.

And that’s essentially what NVIDIA DGX machines are all about. DGX has been around for quite a while. It’s widely used in production AI training and inference. It’s a collection of GPUs individually connected to the CPU or the host through PCIe, and all of the GPUs are interconnected via NVLink. NVL72, a more recent addition from NVIDIA, is also quite similar. It’s a collection of 72 GPUs connected via NVLink. From a programmer’s perspective, that’s essentially all you need to know about NVLs and NVL72s. So now when you hear somebody saying they’re trying to optimize GPU kernels, what they’re usually saying is that they’re trying to make sure that all of the SMs stay busy. Because, as I said, SMs contain all the FLOPs, all the compute. So you want them to be consuming those precious FLOPs all the time. The way you do that is, for single GPU kernels, you pipeline the memory loads and writes such that you overlap computation happening on SMs with the memory operations that read from the HBM to the SMs, so that when the current round of computation is done, the data for the next round of computation is residing on the SMs and they’re ready.

For multi-GPU kernels, a similar idea applies, except that you’re overlapping computation with communication with other GPUs, so that when the current computation is done, the data for the next computation is ready and fetched from remote GPU HBMs. Let’s get back to PK. PK is based off three key trade-offs we identified for multi-GPU kernel design. The first trade-off is a transfer mechanism. It turns out that there are three ways to send data over NVLink. One is copy engine. Two is tensor memory accelerators, or TMAs. Three is plain register instructions like LD or SD. Each has its own pros and cons, and naively relying on one transfer mechanism leaves a lot of performance on the table. For example, copy engine is ideal because it’s a separate DMA module sitting on the GPU and it does not require any SMs to transfer data between the GPUs.

But it turns out that the copy engine requires a really large message size or per-transfer data size for it to saturate the NVLink. For fine-grained communication, you’re usually sending a few kilobytes of data, so the copy engine becomes a suboptimal choice. TMA, on the other hand, is able to maintain relatively good throughput regardless of the message size, and it’s also able to do that with relatively few SMs. On Blackwell, we find that with roughly 15 SMs out of 148, TMA is able to saturate the NVLink. But TMA also has its own downside because it’s not able to utilize all the in-network compute features that we discussed previously. If you want that, you have to use the register instructions, but register instructions are also a big pain because you have to think about coalescing and register pressure. All the technical details aside, the point I’m trying to convey here is that choosing the right transfer mechanism for the given workload really matters.

For example, for a commonly used multi-GPU operator like All Gather JAM, we find TMA to be quite optimal, whereas a lot of previous approaches just rely on the copy engine. The second trade-off is how we schedule inter-GPU communication with intra-GPU work. The strategies generally fall into intra-SM overlapping and inter-SM overlapping. In intra-SM overlapping, you have a certain number of threads within an SM performing computation or memory work, and the rest of the threads are just doing the communication work. This is also known as warp specialization. In inter-SM overlapping, what you do is dedicate a certain number of SMs purely for communication and the rest for computation. Again, each has its own trade-offs, its own pros and cons. For example, inter-SM overlapping, as you can probably tell from the diagram, kind of wastes compute because you’re putting a certain number of SMs purely for communication, and all of the FLOPs on those SMs are not getting utilized.

Because communication and computation are happening on different SMs, you have to go through the memory system, the L2 cache, the HBM in order to signal the completion of communication and computation with each other. But for intra-SM overlapping, it’s required that the computation and communication are aligned. They have to operate on the same data. Otherwise, you run out of registers, run out of on-chip shared memory, so you really cannot do any useful computation. You also have to think about local prefetching because, if you look at this diagram, again, the red arrow shows the data path taken when you’re accessing a remote GPU’s HBM. You can see that for the remote HBM, the data goes through the L2 cache, but for the local GPU, it does not go through the L2 cache. This means that if you’re repeatedly accessing the same data, for example, like KV cache during attention kernels, the data is only cached on the far-side GPU.

So ideally what you want to do is prefetch the data, stage them into local HBM before doing any major computation. And for you to do that, you have to rely on inter-SM overlapping scheduling strategy. So again, choosing the right strategy really matters for performance. For JAM reduced scatter, we find intra-SM to be most optimal, but for JAM all reduce, we find intra-SM to be the most optimal schedule. The third and final trade-off is the design overhead. By design overhead, I’m referring to design choices in networking libraries that cause performance loss for reducing complexity. For example, NCCL’s default mode forces intermediate buffers, which adds extra data movement between the sender and the receiver. And for fine-grain communication, this overhead really accumulates. By stripping it out, you can speed up an operation as simple and basic as All-Reduce by up to 80%.

What this tells us is that it’s important for modern GPU networking libraries to explicitly expose such performance-critical controls instead of encapsulating them. So I think I made most of the points that I want to make for today’s talk. Now I’m going to go over the ParallelKittens framework, but as I said, I’m going to make this really quick and brief. So ParallelKittens builds on all the trade-offs and the principles that we discussed. It’s a highly opinionated set of CUDA programming primitives that extends Thunder Kittens, which is one of our previous works for single GPU kernels.

As we previously discussed, a modern GPU has a memory hierarchy ranging from registers, shared memory, L2 cache, global memory. You can also think about remote GPU HBM as another layer in the memory hierarchy—so peer global memory. PK provides a data structure for each layer in the memory hierarchy. You have RT for registers, ST for shared memory, L2Cache is not programmable on GPUs, GL for global memory, and then PGL for peer global memory. What PK provides is various communication primitives that take in these DR structures and act on them, utilizing the most efficient transfer mechanism for the given functionality. It also provides a program template consisting of four different workers: loader, consumer, communicator, and store to enable different scheduling strategies. But again, for more details, please refer to our paper and our GitHub repo. Okay. To see the effectiveness of PK, we compare it against popular baselines across data tensor sequence and expert parallelism, as well as pure collective communication like All-Reduce.

What we find is that with roughly 50 to 100 lines of device code, PK is able to surpass or match hand-optimized kernels that are often hundreds to thousands of lines of code. What I’m particularly proud of is the adoption. PK has been adopted by major AI companies. For example, Cursor is using it to train Composer on tens of thousands of Blackwell GPUs. Together AI is also using it to optimize its inference workloads. Okay, so that was it for my talk. I hope you learned something about multi-GPU kernels and GPU networking today. If you work on ML systems and efficiency, I hope you take a look at PK and give it a shot. Thank you so much for your attention.

Francois: Okay. Next up we have Jon.

Jon Saad-Falcon: Awesome. Hey everybody. Thanks for coming. Today I’ll be talking about one of our recent papers called Intelligence per Watt: Measuring the Intelligence Efficiency of Local and Cloud AI. This was a joint work with one of my collaborators in lab, Avanika and Orion, as well as our advisors, Professor John Hennessy, Azalia Mirhoseini, and Chris Ré. To situate us today, we like to call, at least between me and Avanika, the current era of LMs and hardware the mainframe era, alluding to the previous era of mainframes in the ‘50s and ‘60s when IBM had these computers that used to fill up entire rooms, sometimes entire floors. These were the kinds of computers that got us to the moon. These were the first commercial computers available for businesses. That’s kind of how we’re still constructing at least the data centers today, where you have these warehouses filled with TPUs or GPUs from Google and NVIDIA, respectively.

They’re both doing our training as well as our inference. It makes sense because demand is growing so substantially. We need to satisfy that demand and scale out computers as fast as possible. At the same time, this is demand that we haven’t seen in a very long time, maybe since the US built its railroads over the entire continent. We’re spending upwards of two to three percent of GDP today. That’s demanding 250 gigawatts of new data centers, which requires new power sources, new GPUs, new land, new water to actually handle the demand for both training as well as inference. Even though the demand is going up so quickly year over year, a lot of these requests don’t necessarily need frontier-level intelligence to handle them. We each have our different LM workloads that we handle per day. At least for me personally, I know most of my workloads don’t necessarily need frontier-level coding or frontier-level math LMs.

A lot of them are going through different kinds of data sets, doing different kinds of plumbing when it comes to organizing folders, creating unit tests. Despite the fact that frontier-level intelligence is what we’re continuing to push, and it’s really important that we continue to push that out, there’s a lot of smaller local open source LMs that can actually address the vast majority of LM traffic today. What we’re thinking is that the same way that we shifted from these mainframe IBM computers that filled up entire rooms to PCs from Apple and HP in the ‘70s and ‘80s, we will see something quite similar happening for the hardware today, where we’re seeing this shift away from NVIDIA GPUs and Google TPUs for every single request more towards Mac as well as NVIDIA and AMD personal consumer GPUs that sit in people’s workstations and laptops.

And this is being driven by two main trends. One is the fact that these smaller LMs are getting better year over year. We’re seeing smaller LMs, open source LMs that are quite capable, and it’s only accelerating, combined with the fact that local accelerators are also getting much better. So these are accelerators from Apple, accelerators from NVIDIA, accelerators from AMD. We’re seeing that these GPUs have more than enough memory to handle some of these larger open source LMs. We imagine this trend will continue. With this study, we wanted to ask what role local inference with open source AI can play in redistributing the inference demand from how it is today, which is mostly in the cloud, toward more distributed inference. To help us frame the study, we proposed intelligence per watt to talk about the numerator and the denominator.

By intelligence, we just mean capabilities. This looks very different depending on the tasks that you care about. Ultimately, we care about chat, reasoning, agentic tasks, coding tasks—basically anything that people are using LMs for today. At the same time, the denominator focuses on efficiency. This isn’t just efficiency in terms of the intelligence you can deliver per parameter or per bit of information used for training. We’re talking about the actual compute and energy required for running these different accelerators for all of the different workloads that people care about. What is the actual running power, wattage, or wattage in terms of power for actually delivering that amount of intelligence? For this study, we wanted to do a broad sweep and see what the trends were. We tested about 20-plus different state-of-the-art local models across Llama, GPT-OSS, Qwen, IBM Granite, all in the range of one to 200 billion parameters, some MoE, some dense.

At the same time, we wanted to test the state-of-the-art accelerators, particularly local accelerators over the past two to three years. This was from Apple, from NVIDIA, from AMD, from SambaNova, to basically understand what the upper bounds were for intelligence per watt and intelligence per joule. We wanted to do this across all the different workloads that people care about—chat, reasoning, agentic, coding tasks—basically anything that people are using these models for today, we wanted to examine. We wanted to examine more than just accuracy. We cared about latency, we cared about energy, we cared about power, we cared about compute, and we wanted to do a broad sweep and see what made sense. What we found was pretty compelling. We found that a lot of these local models are quite good and they’re advancing rather rapidly.

Up to 88.7% of these queries could actually be routed to local accelerators running local open source AI. And that accuracy is only going up. In the past two years alone, we’ve seen about 3X improvement in this intelligence delivered per watt. At the same time, we’re seeing this compound. This is combined between the better local models as well as the better local accelerators, building off of each other. When you actually examine intelligence per joule as opposed to intelligence per watt—in this case, looking at the total energy being spent for the entire workload end to end—that’s compounding even more rapidly. In the past two years alone, or actually in about 16 months, we’ve seen about an 18X improvement in the actual intelligence delivered per Joule.

This is primarily driven by better accelerators, with more memory being placed on consumer GPUs, such as the Apple M4 Max, as well as the DGX Spark from NVIDIA. This is also from better quantization techniques that can better take advantage of the available compute, as well as longer pre-training, more post-training, and more sophisticated techniques for actually making these models better. What does this actually entail for the way that we think about redistributing this inference? This means that if you were to route perfectly, you could route somewhere between 80% to 90% of the queries today to these local accelerators running these local open source LMs. That means energy savings, compute savings, and cost savings. Even imperfect routers can save somewhere between 50% to 70% of your energy, compute, and dollar cost.

This fundamentally changes the economics of how we scale inference and how we think about building new data centers and investing in new computing lines of hardware and models. At the same time, local accelerators aren’t perfect. One of the advantages of data center compute is you can do all sorts of sophisticated techniques around kernel writing, batching, and different kinds of quantization that allow you to amortize the investment across more users and more queries. The Apple M4 Max compared to the NVIDIA B200 is still lagging behind, particularly when it comes to intelligence per watt and intelligence per joule. At the same time, there are even more specialized accelerators for inference, such as the SambaNova SN40L, for which consumer accelerators are lagging even more behind. So there is an investment opportunity to make these consumer accelerators better and better.

And so we’re excited to see what the different companies release. I just want to thank our collaborators on this project from NVIDIA, from Google, from Apple, AMD, OpenRouter, and SambaNova. Without their resources and guidance, it wouldn’t have been possible to do this study. What are we looking for next? I’m really excited to see how inference engines change for this new kind of dynamic where you’re leveraging both local resources as well as cloud resources. At the same time, I think there’s a huge opportunity to think about model architectures and kernels focused specifically on energy-efficient inference. This could lead to different kinds of accelerator architecture co-designs that make this possible and accelerate this trend. On the actual analysis side, I’m excited to break down the intelligence per watt metrics even more and see how we can separate out how this looks across different tasks, across different hardware, across different deployment settings, looking at the inference engines, looking at the kernels, looking at the actual compute and memory on the hardware.

And finally, while we focus on intelligence per watt here, I think it’s really important to consider how this intelligence is actually being used in a useful manner—how we’re actually using this to do meaningful work that people care about and that humans would have to do otherwise. Quantifying how that affects GDP, how that affects wages- that’s another interesting thing that we’ll be releasing quite soon. If you have any questions, please feel free to reach out. I’m available over email, over Twitter, over GitHub. I’d love to chat if anybody’s excited about these same topics. We also have a follow-up project called OpenJarvis that’s focused on operationalizing a lot of these insights and making it possible to run the entire personal AI coding stack on device. So you don’t need to pay Claude or pay OpenAI anymore for your LMs. You can instead just run it on your laptop and on your workstation.

So if you’re excited by that as well, please reach out. Thank you so much.

Francois: Okay, next up we have Mark.

Mark Saroufim: All right. Can folks hear me okay? Francois, thank you so much for inviting me. I heard in Stuart’s really nice talk a bunch of questions around how good AIs are at writing kernels. This is going to be the gist of my talk. We’re going to go very deep into this topic. I worked a lot on systems for about five years, working on PyTorch. I also worked a lot on custom kernels as part of co-founding GPU MODE. This has been one of my main focuses at CoreAuto. I’m hoping to give you both a research and commercial angle to a lot of this research. This is a YC Paper Club, so the main lessons are drawn from these two papers: KernelBot, which is a competitive platform—basically, it’s like LeetCode for GPU programmers.

And then the second one is Kernel Guard, which is our platform for detecting cheating. I’ll explain why these are one and the same problem. I’m a systems researcher, and I’ve had to accept that my opinion matters less than AI researchers. What I want is for people to just take the same data, keep running a matmul on it over and over again, and give me a GI. But what my colleagues in research want is something that’s autoregressive. They want lots of tiny kernels, dynamic control flow, sparsity in a lot of it, and print statements. All of these things are frustrating, and they should stop doing this. Okay, thank you. Unfortunately, I can’t do this, so I have to work with these people and give them tools.

The way we typically do this is by giving them programming languages. One example—you might not think of it as a programming language, but it is—is math. Math is beautiful because it’s forward compatible. For example, the matrix multiplication API has been forward compatible for 250 years. It’s AB and then equals C. Maybe you add some args or kwargs, but it’s the same API. PyTorch is very much in a similar vein. Basically, the forward-facing printed API of PyTorch—it’s ops like MM, Softmax, QRD comp—all these things will stand the test of time. Ultimately, these dispatch down to individual CUDA kernels that may or may not be very fast on modern hardware, which is why we get programming languages like Triton, which are tile-based. They’re Pythonic, they’re fast. Triton took over the world about two and a half years ago.

But recently, especially starting with Blackwell, people are saying, “Well, Triton’s programming model is very restrictive. It’s not letting me write state-of-the-art kernels.” So people have been very interested in programming languages such as ThunderKittens, which Stuart helps maintain, CUTLASS and CuTe DSL, which are closed-source libraries by NVIDIA for really state-of-the-art matmuls. CUDA, which is a more general programming model, is not just for matmul—it’s a thread-based programming model. It’s really great for surgical improvements, but it’s quite tedious to write. And at the lowest end, you have what the hardcore people do, which is PTX or inline SASS. Typically, there are no BC guarantees. So it’s not that it’s hard to do it; it’s just that your code will stop working if you change architecture. That’s less pleasant and very time-consuming. Typically, all the maintainers of these libraries and users of them have very strong opinions about what’s actually the best trade-off between performance and productivity.

It’s just that you have to know where on the spectrum you are, how much you care about performance, and you can typically figure out what your opinion actually is, but there’s no wrong opinion. But if we were to try to benchmark this a bit and say, okay, let’s do a leaderboard. Let’s say we have a problem, like a QRD composition problem. I’ll explain what that is in a second. The goal is for people to submit kernels to this problem. What’s really cool, what I’ve been working on in GP1, is this platform called KernelBot where people just make submissions. They can pick any library they want. Then we can basically do data analysis and see which libraries are actually popular and what people actually use. At least for this archetype of people that just want state-of-the-art perf, as far as I can tell, they really prefer CUDA.

It was only when we were doing lots of GEM-related problems that people loved using CuTe DSL. But Triton shows up often in the top five to ten, rarely shows up in the top two. So this is how you should broadly think about it. What’s funny, though, is that I spent all this year working on these galaxy brain programming languages and compilers. Then starting this January, we did this very prolific, very popular competition on NVFP4 kernels. People who’ve never written GPU kernels before started to get really competitive results. They were in the top four and top five. This is Shirga. He’s a researcher, a grad student in China, and reached out to me. He’s like, “I’ve never written GPU code before. I’ve never written an open a CUDA book before. Everything is LLM-generated, but I’m number four.” This post of mine made it to r/Singularity, which is interesting.

It was my first cameo on that, so I read it. But then I was like, “Okay, this is weird.” People told me, “Well, but this guy is smart. He’s a researcher. Obviously he gets it. He’s computational and numerical.” But then I saw this other tweet by Clark, who’s a high school teacher, and he’s telling me, “Oh, hey, I just wrote my first dual GEM problem.” And I’m like, “What?” Typically there’s an order, right? You have to start with vector sum and vector mean, then you do MatMul, and then you do this other stuff. Here people were just YOLOing it, and they’re getting competitive results. They’re looking at the charts; they’re having a good time. As an educator and as a builder of libraries, this is very, very strange to me. Despite working in this field, I did not expect these results to come so quickly.

So I want to briefly talk about how we typically evaluate how good AIs are at writing these kinds of kernels. A lot of this framework is borrowed from Simon Guo and Anne Ouyang’s work on KernelBench, but the framework is the following. You typically have some sort of PyTorch reference because we all agree in the community that PyTorch is generally more correct than most libraries, but not more performant. You basically pick, you sample some random inputs, you then have another reference submission in your favorite kernel DSL. You run an eval.py where you just pass both inputs through both, see if they’re equivalent. You check for correctness, you check for performance, and then you rank something on a leaderboard. Great. This is the basic framework of how all these evals work. If you’ve been working in AI, you’re like, “Oh, it’s verifiable rewards.”

It’s an easy problem.” And when people tell me this, this is me. I’m like, “Okay.” I actually disagree. There’s a very hidden nuance here and I think we’ll dive in. I’m going to give you an example. If you’ve never had a CUDA kernel before, you’re going to do one with me right now. We’re going to write the world’s fastest vector mean kernel. Given a vector, which is a one-dimensional vector, we’re going to just take the average of it. Great. We’re going to sample a bunch of random inputs from a vector of length a million. This is great. We’re going to take the mean of this vector. Okay. This is basically our reference. What our kernel’s going to do is we’re going to write a kernel.

The hint here is that torch.randn samples values with mean zero and variance one by default. So the world’s fastest vector mean kernel just returns zero. This actually beats the speed of light. This is a wonderful algorithm. NVIDIA, I would love to hire you. Life is good. But this was not one isolated example. I’ve read a lot of reward hacks. One common one is that the AIs will cache the output and then reuse it and do something equivalent. So you’re like, okay, I want to ban this. One version of it might be you use data pointers to figure out what the past data is in Python and then you return that. So you’ll put in your eval suite, you cannot use data pointer. Then it turns out Python is a very interesting language.

Instead of doing the dot, you can say get attribute, and you get data pointer. Now you ban the string data pointer. I’ve seen the AI also split that data pointer into two different chars in appendim, and they’ll do them in different lines. So you can’t catch it easily with the regex. Let’s say you ban data pointer outright. People get upset, and then you can just use id. My point is this is very much a chicken-and-egg problem. This just keeps happening. It’s just because Python is a dynamic language, which makes it a terrible choice for these things. One of my favorite examples was by Natalia, who was a student at Stanford at the time, who showed me the craziest reward hack I’ve ever seen. The essence of this reward hack was it noticed that during our correctness suites, we were checking for correctness 15 times, and then we would do performance testing.

But when we were doing performance testing, we weren’t doing correctness testing again. So what the AI was doing is it was counting how many times it did correctness testing and giving us a correct but slow kernel. But then when it came time to do performance testing, it was giving us an incorrect kernel, but still batching all the results together and basically making everything look good. Turns out there’s a precedent for this reward hack. It’s actually Volkswagen. This is called Dieselgate. What they did was, under emission testing, the car would detect it was under emissions testing and reduce emissions by 40X. But in the real world, it would just emit a lot more, and that worked. Big credit to Tinderization, who pointed this out to me on Twitter. I was on this brutal on-call load where we kept reviewing reward hacks, and people would tell me, “Mark, your eval sucks.”

Why can’t you detect these issues? But it’s a lot, and they’re all different. It’s not at all obvious how to codify it. So I thought, okay, if people are mostly going to submit to our competitions with AI, I’m also going to review it with AI as well. The main idea was, as a human, if I see something that’s really fast, I audit it. I mark it as a reward hack. I then provide that as an example to an AI system. I get this AI system to synthesize a Regex-based detector. You deploy that Regex and you can catch a lot of cheaters. And as new things come up, you retrain the model. This idea was by Sinatra, one of the GPU MODE maintainers. Again, if we had more funding, we’d just use a model, but this is very fast and very snappy.

I want to talk about a recent problem that we had that was interesting. One of my colleagues, Rohan, is very into this optimizer called Shampoo. You might have followed it on Twitter. He was beefing with Keller Jordan about whether Muon is Shampoo or not. It’s very interesting. One of the reasons why Shampoo isn’t more deployed is because it depends on this algorithm called the QR factorization, which is very, very slow in PyTorch. I saw this as an opportunity to monetize the beef and make a very old algorithm much faster. The basic idea of QR decomposition is that you have a matrix A and you want to decompose it into two matrices. One is Q, which is an orthogonal matrix, which means the transpose is equal to the inverse, and an upper triangular matrix. This is very useful to guess the curvature of your space, which is useful for second-order methods.

And the function, the API to use this in PyTorch, basically just calls LAPACK under the hood for CPU or cuSolver for GPU. Both of these libraries, I think, need a lot more love. They need a lot more maintainers. They’ve been getting swallowed up by deep learning ops. It was really cool. We basically turned this into a problem for the community and collectively did this broad search over humans and AIs to get a kernel that’s 60 times faster. And it doesn’t nan, which is great. We can actually use this in real training runs. What’s really weird about these kernels is that they’re quite long. For example, the average submission here is on the order of 15,000 lines of code because it’s a single kernel per shape. No human would ever do this because humans have this bias towards beauty, simplicity, and elegance.

The AIs don’t seem to particularly care. What they do is implement a dispatcher where they’re like, “Okay, well, if the shapes are small, maybe I should do a shared memory QR, but if it’s really big, I should do a global memory QR. I could have custom schedules. For shapes that get tested a lot, I will use lower precision. I will use higher precision. But for shapes that aren’t tested a lot, I can cheat the benchmark hardness and use a lower precision shape.” So then you have to look at this. At the end of this, we have tens of thousands of submissions, each of which is tens of thousands of lines long. So we have a few million tokens of this. We’re looking at this and thinking, can we synthesize this into an actual beautiful and elegant kernel?

Turns out, not so obvious. I haven’t figured that out. That’s actually an open problem. But we did read the three fastest kernels very carefully. Myself and one of my colleagues, Marcus, one of the FA4 co-authors, tried to explain to people how you write these kernels. This is what we came up with. We’re like, look, step one is you understand how the GPU memory hierarchy works. Step two is you write a very fast kernel. This sounds facetious. It’s correct, maybe not very actionable, but this is directionally what we want to do. The last thing I want to talk about here is that a big part of what makes our leaderboards work is that by virtue of people competing more, more reward hacks get found out. As a result, our eval gets more robust.

To me, this flywheel is reminiscent. When people say, oh, PyTorch is more correct. PyTorch wasn’t born correct. PyTorch was slowly made to be correct. The idea was at first it was vibecoded in the sense that it was a POC that ported Torch to Python. So basically it just went from Lua to PyTorch ops. It was verifiable because it’s PyTorch to LuaTorch, which goes back to NumPy, which goes back to LAPACK, which goes back to Fortran. So we have this chain of correctness.

We worked with a lot of researchers. They told us what they wanted. They pointed out bugs, we fixed them. And then it turns out if you repeat this over nine years and you maintain strong BC numerics guarantees, you’ll get a very popular library. This is a very good process. I don’t know what’s the right way to do this purely with AI, but I suspect the way we’ve done things in an adversarial way with KernelGarden and KernelBot is probably a good hint as to how we should approach these problems. So, thank you. If you’re interested in some of these problems, feel free to reach out to me on Twitter or hello@coreauto.com. I can tell you about what I think are some important open problems that I don’t think get nearly enough attention, and that are very different from just asking Codex to go cook.

So basically the Kernel alums are very good at exacerbating Amdahl’s law effects. They will find all bottlenecks in a system, whether it be compilation times. Anything that involves waiting is very bad. As a result, I’m very interested if people have any ideas on ways of speeding up compilation. Faster JITs, more efficient AOT packaging of things like Triton and CuTe DSL are things I’m very interested in. CPU simulators of GPUs are quite good. I think a lot of people have been joking around how Fable is just phenomenal at this kind of work. This is the kind of work I’d love to see because if you can spin up CPU simulators, that means you don’t need a lot of GPUs for doing rollouts. Similarly, if you want to deploy these kernels in a real inference engine—well, inference engines, let’s say out of the box, if you’re to use something like SGLang or vLLM, if it’s just loading DeepSeek before the first inference, maybe you’ll wait about 30 minutes. This really sucks for an AI system.

I’m also very curious to hear takes on how to more robustly verify kernel correctness. The way we do it today is we just take random inputs. Some people tell me formal verification is the way. I’d love to hear more ideas that are cheaper than training a model because that’s kind of prohibitive. I’m also curious what people think about what’s in between. We can read code line by line to verify its correctness and we can test it a lot. None of these answers feel very satisfying to me, so I’m curious if people have intermediate takes. And the last one is people have been joking that GP mode has become pay-to-win. That sucks. I think it’s become pay-to-win because test time scaling is happening over days or basically on the order of one or two weeks. So given that we know how to solve this problem in these longer periods, can we speed run it in a couple of hours or a couple of days?

If you have any ideas, I’d love to hear from you. Thank you.

Francois: Okay. Next up, Misha. Thank you.

Misha Smelyanskiy: Can everyone hear me? Okay, cool. Hi everyone. I am Misha. I joined a startup called Marlowe almost a month ago. The startup is focused on building workload-optimized heterogeneous infrastructure. The main premise is that inference is a very heterogeneous workload. Different phases of inference exercise compute, network, storage, and memory bandwidth differently. When we look at it, it makes sense to co-design systems that use different hardware and different systems for different phases. I’ll give a couple of examples today. I want to caveat that there is no data—I’m not going to show you any data right now—but I will try to drive those arguments from first principles. I’m also happy to be debated on them. This is probably very familiar to everybody: this is the life cycle, the lifetime of an inference request.

Basically, a user enters a prompt. There is a CPU system that orchestrates, schedules, and batches it. Then it goes through the prefix cache, looks up the prefix cache, and whatever is left of the prompt that’s not cached, it does the prefill. Prefills are usually very compute-intensive and are done on accelerators. There is also the KV cache creation, and that can involve CPU or other accelerators’ memory, which can go over the network. Then there is autoregressive decode that does one token at a time for a given stream, which is also very memory-intensive and very latency-sensitive. Then you produce the result. There is also a speculative decode along the way that speculates on the next batch of tokens, which then needs to be verified with the main model. The main point is that different phases trigger different hardware.

The bottlenecks just keep moving. There is no one thing. I’m sorry, the slide is a little bit busy, but I felt compelled to put it in. I want to talk a little bit about the fundamental characteristics of prefill and decode.

The main metric here is what we call arithmetic intensity. Arithmetic intensity is the ratio of the amount of FLOPs that your fundamental algorithm does to the amount of data that it moves from memory. If that ratio is greater than the corresponding machine ratio—which is the ratio between peak machine FLOPs and peak memory bandwidth—then your kernel or algorithm is compute bound. If it’s lower, then it’s memory bandwidth bound. This is a roofline, and I’m sure a lot of you are familiar with it. It was actually created for HPC back in early 2012 or 2013 by Sam Williams from Berkeley, who tried to model the behavior of different HPC applications. The idea is that you have arithmetic intensity along the X axis, and for a given intensity, you have how much FLOPs you can achieve.

And so if your arithmetic intensity is less than your machine ratio, you’re in memory bandwidth bound, and if it’s greater, then you’re in the compute bound region. Of course, the reality is much more complicated than that, but that gives you a first-degree approximation. If you look at prefill and decode, you can actually see that even attention and MHA kernels, MLP, they all have different arithmetic intensity. Prefill is generally very compute-bound because you basically do attention. You do a lot of work per all the tokens that you are fetching. You can fetch the weights once, and you operate on all of them. The MLP is even more intensive because you can actually batch things, so it’s pretty compute bound. The decode is different. In decode, you actually work on one token at a time; it’s regressive.

So attention is really horrible. You’re fetching the weight for every token that you want to process, so it’s really inefficient. The MLP is a little bit better because you can actually batch it, but in reality, batches are not that big. The machines, like modern accelerators, have a lot of compute, so you end up being bandwidth-bound for pretty large batches as well. The main idea here is that even within a prefill and decode, you have quite a bit of diversity of behaviors and how different kernels stress the system. You can uplevel this a little bit. This slide basically shows different use spaces, and you can see that inference spans a very large space of workloads. Each circle here—the size of the circle, the bigger, the larger the concurrency. For each use case, we are showing how much time you spend in prefill versus decode.

For interactive chats, you’re entering some prompt, and then maybe you get some answer. But generally it’s, I don’t know, 30/70, fifty-fifty ratio between the prefill and decode, and it’s very strict latency-sensitive. For long context queries, you basically spend all the time on prefill. Then you get an answer, you do decode, but most of the time is spent on prefill. That’s why the blue dot here has a long blue line. For coding agents and the latency, you probably also have strict latency requirements. For something like long-running agents, you have long input, long outputs, you left your Claude run overnight to build your code base, and so it also can be high concurrency, and latency is relaxed. I don’t want to belabor the point. The main point is that inference spans a very large space of workloads.

Before I continue, I want to do a quick detour and talk a little bit about SRAM machines. Those machines became very popular in the last decade. What’s so good about the SRAM machine? Basically, today when you want to do the GEMM, for example, on GPU, and if weights are large—if they are larger than the size of your on-die caches—you have to go to memory. You have to go to HBM and fetch it over the inter-package interconnect into your GPU. If you have a large weight matrix, you have to do it for every token, so it’s inefficient. The SRAM machine basically keeps the entire weight matrix in SRAM memory on die, so you get a lot more bandwidth because it’s on chip. You can access bytes over cycles. The chip interconnect is also fast; you can go between different units in a couple of cycles.

So everything is kept on die, and they’re very efficient. I call them GMV, matrix-vector multiplication accelerators, which just happen to be really good for decode because decode is very bandwidth bound. They offer significantly more bandwidth and significantly lower latency, but there is a catch: because it’s all on die, there are only so many transistors you can pack. You’re limited by the theoretical limit of your die. Because of that, the amount of capacity you can put is limited. If you look at different SRAM accelerators, you have between hundreds of megabytes to tens of gigabytes of memory, but that’s it.

But it moves them much faster. So the question is, how do you leverage them? How do you make sure that the model, even after the model is sharded, you still see the benefit? After the model is sharded within many chips, you still see a benefit, and how do you characterize these benefits? I want to talk about a couple of examples where now I’m switching gears, talking about different systems. It does not have to be a GPU or an SRAM machine, but I just want to give examples of how specialization could help. People know very well prefill and decode disaggregation. People separate them because it lets each of them scale independently and removes shared bottlenecks. So you can basically ask the question: what if instead of disaggregating prefill and decode on two different systems, you disaggregate decode on a different system? Let’s say system A does prefill.

System B does decode. When is it beneficial? When is it actually beneficial? If you think about it from a TCO point of view and what we talk about is tokens per second per watt, it’s actually beneficial when the additional power that your system B adds is offset by the speedups that it brings. You can imagine if you have really short sequence lengths, you spend a lot of time in prefill, and so your benefits might not be as pronounced. For short output lengths, you actually have TCO loss because you just bundled a bunch of new hardware and you are not using it. As you increase output lengths, you’re actually spending more time doing decode, spending more time on system B. At some point, you may become TCO positive. The other example I want to give is the AFD.

As I talked about earlier, attention and MoE parts have very different characteristics. One way to accelerate this workload is to run attention on system A and run the MoE on system B. What’s going to happen, let’s say in the example of a GPU: we know very well that GPUs are really good at high throughput. They operate with very high concurrency. They deliver amazing results. You’re compute-bound, and your latencies can be lower. But the moment you start going to lower concurrency because you want better interactivity and better latency, the performance—the throughput—drops. It drops very sharply because all of a sudden you have a lot of smaller kernels, you have a lot of overheads, you’re bound by memory bandwidth, and also memory bandwidth is not utilized very well because of all these overheads. At this point, you may say, okay, what happens if I introduce system B that is really good at running those memory bandwidth, latency-bound kernels at the point where, say, GPU interactivity goes down?

And for example, you can consider offloading some of those nasty MoE kernels to SRAM machine. And because everything is on die, they have low latency, they all can do quite well for small batch and all of a sudden you see that your interactivity has been extended. Now what happens to the TCO? The TCO may not be as great as running it at a very high concurrency, but at the same time for use cases where interactivity matters more than TCO, it might be a sensible approach because there is a point beyond which GPU cannot deliver more interactivity and this extends the life. So that’s the idea of the desegregation of attention and MAE. And the last example I’m going to give is basically in the case of speculative decoding. I think everybody knows what speculative decoding is. You have the drafter that speculates on subsets of tokens, either autoregressively or in parallel for block diffusion.

Then the verifier verifies them in parallel and whatever number it accepts, that’s how much you can fast forward. So you can imagine that you can run your drafter on system B, right? Your verifier runs on system A, but you can run your drafter instead of running it also on system A, you run it on system B. And I don’t mean sharing exactly the same hardware. You can run it across different systems, like for system A, you can still run verifier on one system and drafter on another. And for system B, just offload the drafter to system B entirely. And if the drafter allows you a much better acceptance rate because it can run a much larger model at the same rate as system A can run, then you can actually see the wins. You can see the wins in terms of latency. It’ll reduce the latency because maybe system A cannot run such a large model, it takes time.

And you can also bundle multiple verifiers to the same decoder to improve the TCO. Okay. Just to wrap it up, I was talking about end-to-end co-design of the heterogeneous infrastructure. And that’s a really full-stack problem. There are many interesting aspects of it. There is a data center aspect, like when you put heterogeneous systems in the same data center, what does it mean for power density, for cooling, for break and fix, for managing? A lot of your problems that you have in a homogeneous environment become harder. There is the networking problem. I didn’t talk about it much, but obviously anytime you move data between system A and system B, networking is a bottleneck. So how do you build it, co-design it together? Where do you connect them, under what network topology, so that your latency is reasonable and doesn’t kill advantages?

And so obviously one thing, you also need performance modeling infrastructure. You need a really good simulator to allow you to go through a lot of design points and figure out what makes sense. And it needs to be well calibrated, but that’s really how you’re going to guide your co-design. So that’s basically what we are starting to do. Thank you.

Francois: All right. Next up, Brennan.

Brennan Shacklett: Hey, thanks for having me. Really appreciate it. I’m going to be presenting some work that I did at Stanford a couple years ago during my PhD. I’ve since moved on, and I’m doing an AI plus gaming startup, but credit where credit is due—this is firmly Stanford work in Kayvon Fatahalian’s group at Stanford. What I’m going to be talking about is this hypothetical idea: what if we put an entire game engine that can simulate any game you can imagine all on the GPU and run it super fast? I’ll talk about how we did that at Stanford over this project, which ran for a couple years.

The reason we cared about this is that games are a great learning environment for a bunch of different tasks. I did a lot of work with roboticists, people doing self-driving car research, and game developers themselves. They’re just a really great platform for learning skills in simulation in a low-cost way. But honestly, somewhat surprisingly, game engines are really inefficient for the throughput-oriented training workload if you just do the obvious thing, which is run a thousand copies of the engine in parallel, because you’ll have all of these copies fighting with each other. You can’t amortize any costs, and you wind up using both the CPU and the GPU hardware really inefficiently.

The better solution to this is what we call batch simulators, where you have a single game engine that actually simulates a batch of a thousand learning environments simultaneously in a big throughput-oriented batch that runs on the GPU. Hopefully this loads. This is a visualization of OpenAI’s old hide-and-seek environment. It was a multi-agent reinforcement learning environment. That gives you a sense of how many of those environments we were actually able to fit on a single GPU. You can wind up getting throughput of millions of frames per second of experience, which is incredibly useful for data-hungry algorithms like RL.

The challenge with building this that we ran into is that existing GPU programming frameworks are a really poor fit for the gameplay logic you actually need to write to build these environments. When you’re trying to build these environments, you want to be able to create them easily and experiment with different mechanics and ideas. Here’s an example of some of the logic from that OpenAI hide-and-seek environment. Agents need to run around and use the objects to hide from each other. They can lock objects, move them around, and so on.

And what you wind up with is a bunch of super branchy code. Some of these internal functions end up doing dynamic memory allocation. If you know anything about GPU programming, a lot of this is starting to sound like really bad news from a performance standpoint. Interestingly, the game industry has actually already pretty much solved this problem for parallel CPU code. Most gameplay logic for a game that you might play actually runs on the CPU. But because we’re moving from a latency-sensitive workload, where you’re trying to play a video game and you want fast response times, to a throughput-oriented workload for training, we can almost one-for-one adapt those design patterns to GPU execution and get a really efficient end result. These design patterns are referred to as entity component system design patterns in the game industry. Don’t worry, I’ll define what exactly that means.

And I’m going to be talking about how we run it on the GPU. The first concept is entities—that’s the E in ECS. That might be obstacles in the environment or the agents in blue, the little blue guys. Then we also have components. These are the data that’s attached to each entity. This might be something like the position, rotation, and then you might have action and reward from your reinforcement learning system. The ECS basically takes all of this data and puts it in big in-memory column stores. For the GPU, we actually just put these all in GPU memory and then pack a bunch of learning environments together into these unified column stores. You see that green column is what environment each of these individual objects maps back to. This unified table storage, as it turns out, is a really powerful way that we can do throughput-oriented dynamic memory allocation on the GPU while hiding it behind a really easy-to-use interface, which is just create an obstacle, create an agent.

This makes it incredibly easy to do procedural generation tasks where you might have different numbers of obstacles in each environment, which is the case for the hide-and-seek environment that I was showing you. These things are very tricky to do in a tensor-based programming language like PyTorch, where you’re looking at fixed-size arrays. The third concept, the S in ECS, is the systems. These are the actual code that runs over the entities—the rows in these tables—and builds the logic. That might be processing the actions from a neural network, from your agent, implementing collision detection, or computing rewards for the RL system. For example, the process actions component declares, “I want to run on every entity that has a position and an action component.” In this case, the agents have those two columns.

This logic will run over every single row in this table. That’s the same example I was showing earlier. On the GPU, it’s actually incredibly simple. All we have to do is map one invocation of this function to one GPU thread, and we’re able to get massive parallelism. For the programming language nerds out there, another really nice aspect of this system is it actually allows you to do runtime type polymorphism. The collision system just says, “Hey, I need things that have a position and a bounding box.” It turns out both agents and obstacles have all of those components. Interestingly, the collision system doesn’t actually need to know either of those types. Traditionally in CPU code, you use virtual dispatch for this, which is incredibly inefficient on the GPU because it breaks statically knowing register assignments and introduces a ton of issues like that.

To actually make a game out of all of this, we take a bunch of those individual systems and combine them together into a task graph that describes how the overall frame works. How do we go from taking in some actions from agents and then actually updating the state of the world? There’s quite a lot to it. This is actually a pretty small subset that goes through physics, observation generation for the agents, and so on. Unfortunately, I don’t have the time to go into a lot of the low-level implementation details to actually make the memory allocation in those tables efficient. We’re taking advantage of the fact that this is a throughput-oriented workload, and we actually do something akin to garbage collection on the GPU where we append rows and then mark rows as deleted and then use a super high-performance GPU sort to clean that all up after the fact.

The task graph is actually implemented with a persistent mega kernel that’s constantly churning through the work that’s remaining in the frame. As many of the ParallelKittens-type people will be very familiar with, the GPU just has incredibly good fast atomics that let you do all of this synchronization really efficiently. I can actually show you that here. This is a visualization where every row is an SM on the GPU. You can think of it as the amount that each colored bar is full in each row is telling you how active that SM is. So it’s pretty active most of the time. The different colors correspond to different systems in the task graph. Between each set of colors, you’ll see these slight vertical white lines.

Those are synchronization points in the frame where we’re switching between workloads, but you can see it’s under 1% of the overall work. We’re actually pretty much fully utilizing the GPU. In this case, this is shown on an RTX 4090 simulating, I think, 4,000 worlds of that hide-and-seek environment. For the initial version of this engine, we built a small set of little baseline environments. There was the hide-and-seek environment, there was overcooked, which is a cooperative reinforcement learning environment. The reason we chose these in particular was they already had easy-to-set-up CPU baselines, so we could actually do an apples-to-apples comparison. What we see is the green, which you can barely see on the top of these, is those original CPU reference implementations from the machine learning code bases.

And basically the performance is abysmal. All of these tasks were majorly bottlenecked by environment throughput. In blue, it’s what you get if you take the ECS ideas that I just told you about and just run it on the CPU, more like a traditional game engine, but scaled up to run across multiple worlds. And then red is you actually run it all on a 4090 on the GPU. And it’s literally over a hundred times faster in many cases. We actually did multiple projects over the course of my research that showed you can extend this to end-to-end training. It’s not only simulation throughput. We built a bunch of fast different environments on this engine over about two years. We had a lot of success with relatively non-technical people, like machine learning researchers who knew nothing about low-level GPU programming, coming in, building an environment, getting really good performance, and accelerating their workloads.

I want to leave you with a more general comment here, which is I think there’s still a lot of work to be done on high-level scripting languages for the GPU, even in the era of LLMs writing code and stuff like this. I see a lot of programming language systems trending towards, okay, it’s still the CUDA programming model, but it’s Python syntax on top, which is great, simplifies things, easier to look at, but it doesn’t actually help you with dynamic memory allocation on the GPU, super irregular parallelism, all these really fundamental issues. GPUs obviously have massive memory bandwidth and compute, even if you completely ignore the tensor cores. I think there are a lot of interesting workloads where you can leverage this plentiful, super fast hardware these days and get really good speedups. But some of these fundamental issues just mean there’s a lot of friction if you’re trying to do this on a workload that no one’s ever done before, like we were doing.

I think there’s generally an opportunity here for abstractions that have good enough default performance. You just utilize that raw GPU horsepower, but make GPU programming far, far simpler. Kind of like a real scripting language, Python-esque for the GPU. Thank you.

Francois: Thank you, Brennan.

Brennan: Yep.

Francois: Okay. So just to wrap up here, what’d you think? Good? Thumbs up. Okay. So I think these thematic clusters are the way we’re going to go through this in the future. The next one will be on robotics. We have a couple cool robotics people, a lot of people in the industry. If you have folks that you think would be a good fit, please either DM me in the Slack or otherwise. All right, stick around. We have another busy hour to hang out and meet each other. If you want to talk to the speakers, you want to talk to anyone, now’s the time. Thank you so much for coming. All right.

Alexandr Wang’s advice to his 18-year-old self: develop your own internal compass for how the future will unfold, and hold conviction in it against the noise.

At Startup School 2026, the Scale AI (YC S16) founder — now leading Meta’s superintelligence lab — talks with Garry Tan about rebuilding a frontier lab from scratch, why talent density compounds, and how to spot the exponential worth betting your twenties on.

Watch on YouTube

Timestamps

00:07 — How Alexandr Wang Started Scale AI
03:25 — Pivoting to the Right Idea
06:23 — Conviction Before Consensus
09:06 — Why This Is the Best Time to Start a Company
11:27 — What Personal Superintelligence Looks Like
13:10 — Building a Frontier AI Lab
16:36 — Why AI Models Need to Be Cheap
20:01 — Vision Will Matter More Than Intelligence
24:06 — Systems Thinking in the AI Era
26:51 — The Biggest Opportunity in AI Today
29:25 — Advice to My 18-Year-Old Self

Transcript

Garry: All right. Full rockstar treatment for Alexandr Wang, everyone. All right. So why don’t we start out—backstage we were saying one of the cool ways to think about this event is this room is actually full of people who are just like us, but when we were 18 or 20. There are some 16-year-olds in this audience. Let’s jump to your story. You came up always really smart, Math Olympian. Jump us to the Alex of that time. What were you feeling? What were you thinking, and what drove you down this road?

Alex: Yeah. Well, I grew up in New Mexico, Los Alamos, New Mexico, which is now Oppenheimer-famous, but it really was the middle of nowhere. I did all these math competitions, all these computer science competitions, but I knew I wanted to do really big things, and it was not exactly clear how or what the exact paths to do that would be. I had a friend who was really into programming and, after high school, got an internship in the valley. I think his first internship was at Palantir. He was an influence for me. After I finished high school, I ended up working at Quora here in Silicon Valley. I worked there for a year. I took a gap year to work there, and then I went to MIT. I was 19 when I worked at Quora.

I was 18 when I went to MIT, and I was 19 when I started Scale. I remember this period from 17 to 19.

I felt like I was constantly changing. Exactly what I wanted to do was constantly changing. I was learning so much just from the people around me. I felt like I was drinking from the fire hose pretty constantly during that time. I would definitely recommend the two things that were really important. One is, I think working at a company was really valuable because from the outside, you have no idea how companies work. You have no idea what it looks like to actually build something. You have no idea what it looks like to iterate on something. You have no idea what it looks like for groups of people to make decisions. I thought that was really important. And then going to school at MIT was actually really important because it gave me a lot of opportunity to explore what was interesting.

It was at MIT that I started training my first models and played around with TensorFlow, which had just come out that year at MIT, and where I ultimately came up with the idea of Scale. After one year at MIT, I applied to YC. It felt like a miracle to get in at that time. And YC was really critical to my entrepreneurial journey.

YC is this amazing blend of being very supportive—they obviously want you to succeed—but they also give it to you very real and tell you when you’re being a dumb ass, which I think is what we all need in life. So yeah, that was the story till then. It was 19, start Scale, and the rest is history.

Garry: I guess you worked with Jared Friedman at the time. And you came in with actually a very different idea than what ended up becoming Scale.

Alex: Yeah. So we wanted to build an AI agent, funnily enough, to help people get medical care. And it was a great example of an idea that I think will ultimately exist. I think we’re even seeing it now. AI agents to help people get medical care are very real, but it was the wrong timing. We worked on it for about a month or two before Jared pulled us aside and said, “Guys, I don’t know if this is going to go anywhere.” And that’s exactly what we needed to hear. At that time, I had studied AI at MIT, I had trained models, and we went back to the drawing board, thought deeply about where the opportunity was, and came up with Scale.

Garry: I guess selling data at the time, large language models had not really come to the fore yet, but self-driving cars were coming up, and computer vision suddenly became important. So that was the first market. Is that right?

Alex: Yeah. So the story here is that when I was at MIT, I did a bunch of projects, trained models of various forms. And these were, by comparison today, little toy models. I remember to train a model, I needed three things. I needed a GCP account, an account on some cloud service to get compute. I needed the code to actually train the model. And I needed data, a dataset. For two out of these three things, you could just press a button online and get them. But for the last one, data, there was no effective way to get data for training these models. So it felt incredibly obvious that this was going to be the future, that there was going to be a way to press a button, so to speak, and get data.

It was very funny because in the years that followed, in the first many years of Scale, data was very unsexy still. Every time we would go out to fundraise, even though our numbers were great and we had great revenue, VCs and investors would always be very skeptical. They’d say, “Oh, I don’t know if this is a good business. Does this have longevity? Is this durable?” It was really weird to me, but none of the investors had ever trained a model, so I guess they didn’t really get it. Fast forward to today, we managed to raise money, we managed to keep going, managed to keep growing the business. But the very same investors who passed on us and were very dour on the potential of AI are writing think pieces today about how data is so critical and is one of the biggest business opportunities in AI.

So it’s very funny to see that whole thing come full circle.

Garry: It seems like that’s actually a really good case study in first principles thinking. You can’t start a company by opening the pages of the Wall Street Journal and saying, “Well, data’s hot. We’re going to go work on that.” You literally couldn’t have started Scale that way. You had to start from simple statements that are about the world that you know to be true and then build something for that.

Alex: Yeah. I think the key thing is you need to develop conviction in a set of beliefs that nobody else agrees with. If you look at all of the most successful companies in the world, they were started at a time long before the core idea was popular. They work on that. They toil in obscurity for years before the idea or the space or the concept of the business becomes consensus. The only way you’re going to be successful is if you’re able to identify these truths about the world early, long before everyone else. One of the most surprising things at Scale is we’ve been working on AI for a decade. You can’t base your business decisions on what everyone else is saying around you. If you go too much with the herd, you will get immensely confused and end up nowhere.

And so you have to develop your own compass of what you think the future’s going to look like because everyone else will just confuse you.

Garry: It seems like one of the things you got incredibly great at was you start with this kernel of, we believe X and nobody else believes it. But then the mechanics of building the business are talking to investors and convincing them and not letting them demoralize you. Talking to customers who should just get it. And then especially convincing people to come work for you.

Alex: Yeah. I think that these early mechanics of building a company, you might have some predisposition to be good at, but nobody is good at starting a company when they start a company. I remember talking to a lot of the investors who I met very early on, and a lot of them would say, “Oh, you just grew so quickly and you changed so quickly. And I didn’t see it at the time.” I think that’s probably true for literally everyone who starts a company. Nobody is good at something they’ve never done before. For all entrepreneurs, you start out pretty bad at everything. The whole game is: how do you develop yourself to continuously improve, to get better and learn quickly?

Garry: Backstage, we were talking about how this is actually a really lucky time to start a company because obviously you can come do YC. The people in this room have each other, which is kind of wild. But not only that, now you have ideally a personal AI that’s going to tell you, “Hey, these are some ways to do it.” Do you think that would have helped you accelerate even faster? What do you think it’s like to start a company today, with AI in the age of AI?

Alex: Yeah. I really think we’re at this amazing moment in the world where the bottleneck is not the progress of the AI models. The bottleneck is diffusing that through the rest of the world and helping the world adapt to this amazing technology that already exists. If the models didn’t improve at all from today, there would still be decades and decades of total upheaval and change in the economy and how the world operates and everything around us. As a result, it’s one of the most incredible—it’s probably a once-in-a-civilization opportunity to be a dreamer and to have a vision and to have ambition and to impose a view of how the future world should look by building something amazing.

One of the things that we were chatting about backstage is when I started Scale or 10 years ago, if you start a company, you had to be, you know, it was David versus Goliath. You had to be clever and find an angle into the market and figure out a way to compete even though you had much fewer resources. Now, with the power of agents, and AI broadly speaking, it’s much closer to Goliath versus Goliath. But maybe the startup is like a Mecha-Goliath that is vastly enhanced by the power of agents and AI, and the large companies are the more traditional Goliath, so to speak. I think that startups now, if you properly embrace AI agents and figure out the way to leverage their strengths in the most ambitious ways, you can easily outcompete incumbents.

Garry: So let’s talk about superintelligence because that’s clearly, that’s even in the name of your lab. What does superintelligence mean operationally inside Meta right now?

Alex: Yeah. I think that we, a year ago, Mark wrote this memo about personal superintelligence, which I think actually is very similar to your concept of personal AGI. We believe that everybody in the world, all the billions of people in the world, are going to have a superintelligence that is adapted and tailored to them, that enables them to accomplish their goals, knows their context, and ultimately is an expander of their own agency. The thing that we think a lot about is agency expansion. How do we help people accomplish things that they couldn’t have ever dreamed of before? What would everyone in the world do if everything was just easy? We think about this in an ecosystem way as well. I think Patrick mentioned it, but we don’t believe in this totalizing, totalitarian view of AIs that control the world.

We believe that these are going to enhance this very broad ecosystem. We believe in billions of people all around the world all having their own personal superintelligence. We also believe in an explosion of entrepreneurship. There are 200 million businesses that are on Meta’s platforms today. We think that number should go to billions with this explosion of creativity and using AI tools. Ultimately, we think that it’s going to be this dynamic ecosystem of business agents working with personal agents and developing this complex ecosystem that is fully AI-supercharged.

Garry: So I was really psyched to see Muse Spark 1.1. My OpenClaw absolutely loved it. How has running a frontier lab been? The Muse Spark level is sort of the Opus level. What’s coming down the pipe? And also, I think that you’re increasingly looking at open source, which I think this audience really loves.

Alex: Yeah. So I’ve been at Meta for about a year now and it’s been quite a year. Getting in, and Meta, we’ve talked about it publicly—Llama 4 wasn’t on the trajectory that was needed for Meta. So I got in there and we did a zero-based build of how do you build an entire frontier lab, in some ways from scratch, obviously using a lot of what we had, and move as quickly as possible. Within nine months of that moment, we launched Muse Spark 1, and then two months later we launched Muse Image and Muse Spark 1.1. There are a few things that have really struck me about this. The first is talent density was incredibly important. That was the core thing to bet on. Talent density is something that compounds naturally.

The more talented people you have, the more of the most talented people want to join you.

And I think it’s amazing to see on the inside, but frontier AI work is research. It is scientific work. We are exploring what you can do with these models, how you can push these models, what can be accomplished with these models, which requires a totally different mindset and operating model than existed for internet companies or internet products. There’s a lot more about experimentation, about science, about scaling. And everything ultimately is about how you develop a lab, an operating model, a system that will be able to compound with all of the exponential growth that will happen in the ecosystem: the exponential growth in capabilities, the exponential growth in compute, the exponential growth in adoption and usage. We are on this very, very steep exponent across maybe every dimension of the ecosystem. And it’s important to develop like an organism.

That’s how you think about the lab that is able to grow with that. It’s been very exciting and we’re going to be shipping a lot more. I think we just launched Muse Spark 1.1, which was a great model. We’re going to continue to have updates on the Muse Spark line. We’ll also have bigger models on the way that I think will be much more competitive with even the very best models that are out there today. We’re going to be launching a harness soon and have been working on a harness to help empower all the developers and agentic developers out there. And then, as you mentioned, we’re working on open source models. As I described before, we believe in a decentralized world of AI capability and progress and development. We want to empower the broader ecosystem and everyone in the world to be able to build and develop using this technology.

So we have a lot of exciting things on the way. We want to empower the ecosystem and developers as much as humanly possible.

Garry: It sounds like one of the ways—certainly when I was using Muse Spark with my OpenClaw, it became clear that it was as good as Opus, especially for that agentic flow with skill files, but it was 8X cheaper actually.

Alex: Yes. Well, I think this goes to it. We don’t believe in a world where these models are so expensive that they get rationed only for the most wealthy of developers and companies. It’s important for everyone to be able to use the technology and to build whatever they want to build with it. We take a view that the best AI products haven’t even been developed yet. If you look at the AI ecosystem and everything that’s happened, every wave is 10 times bigger than the past one. When I started Scale, the first wave was maybe self-driving cars. Self-driving cars are really awesome. They’re really, really cool. But that pales in comparison to large language models and chatbots. Chatbots became this thing that was probably 10 times bigger even than self-driving cars. And then there were coding agents, which came a few years later.

Coding agents are probably 10 times bigger than chatbots. I think we’re just on this deep curve. We’re going to keep seeing these new modalities and form factors and developments of the AI paradigm that will each be dramatically bigger than the last. So our point of view is, let’s unleash the ecosystem. Let’s explore and let’s see. Let’s build the future of the world together.

Garry: So what’s the best way to actually take advantage of the coding model for Muse Spark? It’s OpenCode, right?

Alex: Yeah. Today, the easiest way is to use OpenCode, we have onboarding on the website. And then soon we’ll have a harness of our own. Ultimately, we want great models that plug into all of the available harnesses and empower as much combinatorial innovation in the ecosystem as possible.

Garry: Yeah. I know the harness is under wraps still, but can you tease us with it? I still use OpenClaw. I still use Hermes Agent. These things are, I call them Ferraris that break down on the side of the road all the time. Is this a Ferrari that won’t break down? Tease us a little bit.

Alex: Yeah. Hopefully it doesn’t break down. We’re really focused on speed. For anyone that uses these tools, speed is probably one of the most critical things. Also reliability, like you mentioned, we want to be extremely reliable. We want it to be very extensible and to scale to as complex and interesting of a multi-agent setup as you want to have. There’s so much innovation that will occur even above the harness, frankly, in terms of how to orchestrate and set up loops and develop very complex ecosystems of these agents working together. We want to be really extensible. Ultimately, we want to empower people to harness this technology—harness, actually, pun not intended—but I truly believe these models are already just incredibly powerful. They should be so powerful to fuel many, many points of expansion of GDP growth.

And I think it’s up to smart people with vision and ambition to make all that happen.

Garry: Let’s see. So one question. When you look back on the decade, what do you think they’ll say was obvious in hindsight about AI that people are just missing in real time right now?

Alex: So much of the debate that happens these days is around, oh, how good are the models actually getting? And can the models actually bridge this issue? And when are we going to get superintelligence? Is that in two years or five years? Are we going to hit a wall? So much of that debate is, in some ways, a little bit of a waste of time because I think it’s inevitable that we’re going to have very powerful models. I think we’ll look back and say, all this arguing around when exactly it was going to happen was shortsighted because the reality is we are, as an entire human civilization, on this incredible exponential. You cannot look at the progress of AI over the past decade and not be totally awestruck by how far it’s come.

A decade ago, the best AI models could recognize cats in YouTube videos. And now we’re talking to a digital god that can, you know, I think we’ve all seen some of the hacks and things these systems are capable of. You just can’t help but be awestruck.

I think this trend will continue. These models are going to become more and more powerful. Looking back in a decade, it’ll be obvious that intelligence became abundant and that agency became abundant. The current trends we’re on are just going to keep continuing, and this will be very strange. For the history of humanity, groups of smart people getting together towards a shared goal was the bottleneck of progress. The United States of America, in some sense, was an example of this. The United States of America is formed from a group of very smart people getting together and having a vision for the future that they wanted to enact. That’s the story of nearly every company in America and the story of every YC company.

That’s going to change. All of a sudden, the scarce resource isn’t going to be intelligence or agency. I really think it’s going to be vision and ambition. Do you have a clear view of what you want the world to look like in the future? What is the one way in which you want to put your finger on the scale for how the future of the world will develop and how the world will look in five to ten years that it does not look like today? Do you have the ambition and drive to go through all the crap to make that happen? AI will make that easier. Agents and AI make that maybe ten times or a hundred times easier than it was a decade ago. But the flip side of that is then all of a sudden you can dream bigger.

And the world is, there are so many things that need to evolve for us to be able to fully embrace this technology. The world is really just barely even ready for this technology today. And I think as a builder, we have a responsibility to prepare the world. We have to help enterprises and governments adapt to this new technology. We have to help figure out how we secure the world from a biosecurity perspective or a cybersecurity perspective. We have to figure out how we’re going to manage all these risks that we see with this new technology. But on the flip side, it’s also the time of unprecedented opportunity for humans. We can develop new sciences. We can solve problems in health and biology that have been forever unsolved. We can build new businesses that you couldn’t have even imagined before. There are new creative opportunities that couldn’t have existed before.

So it’s just this incredible cradle of opportunity and risks that I think makes it no better time to be someone who’s a builder and has a strong view of how the world should change.

Garry: Do you think the path has changed? One of the things I saw, I think at Stanford, is that the number of computer science majors actually dropped by some double-digit percentage as people worried, which is sort of insane to me. You still need those skills to even create agents that are that good. Maybe that won’t be true. I’m not really sure. What would you say to people in this audience right now? This is a real question that people are facing. Should they become more wordcel and less shape rotator? What’s the move? And has that changed the kind of people you’re looking to hire and how you manage your teams right now at Meta?

Alex: I think systematic and rigorous thinking are still incredibly important because the abstraction layer—I didn’t use to believe that this is how this was going to play out, but it really has. The abstraction layer just keeps changing. When I started a company back in my day, we wrote code. Now I’m sure nobody here writes code anymore. That’s ridiculous. But now it’s about how you orchestrate the agents together. Then it’s how you develop these organizations of agents. How do you get a million agents to work together well? And then it’ll be, how do you get a trillion agents to work together well? I think there’s going to be this continued need to figure out how you structure workflows at the abstraction layer that we’re going to be operating at.

And that form of rigorous systematic thinking, you now, traditionally, the way this would work in my era of certain companies is you would start by writing code, and then you would have organizations of humans, and you’d figure out how to organize those humans. And that required systems thinking. Now maybe it’s much closer to first you orchestrate the agent, then you figure out how to orchestrate these armies of agents. But I think systems thinking is never going to go out of style. So I think it’s definitely a mistake to go all in on wordcel. I think you need to shape rotate. But then I think what’s necessary going into the future is having a deeper compass and philosophical view on how the world should develop. Because I think there are many lessons from human history around how we think civilization should go through this period.

And humanity will change more in the next decade than it has in the past hundred years, probably. So I think the imperative for us to have positive visions for that and have coherent articulations of how that should develop are more important than ever.

Garry: Let’s get a little more concrete. One of the things I’m curious about is, are there applications of AI that you’re seeing among your friends or internal to Meta that you can talk about that are obvious near term, maybe people haven’t figured out yet? Give us some alpha.

Alex: I think there’s still just astronomical opportunity in agentic looping and figuring out how you develop systems that enable you to spend 1,000x more or 1,000,000x more on tokens to drive an outcome in a continuous feedback loop. If you think about most companies, companies are just these large-scale feedback loops where humans are operating each of the edges. Companies get customers, and they figure out how to make those customers happier. If customers are happier, then they spend more. If they spend more, then you can hire more people who can then go figure out how to get more customers and make those customers happier. That, in some sense, is the feedback loop of every startup or every business. And within that, there are micro feedback loops that exist. I think developing agentic systems that can operate and optimize these feedback loops is—there’s just huge amounts of alpha there.

I think we’ve seen internally at Meta cases where if you can develop the right agentic loop and you have the right eval or the right metric for the agents to optimize, you can have a swarm of agents accomplish more than a team of a hundred engineers very easily, actually. And so I think figuring out what the world looks like with lots of these agentic coordination problems, I think that is one of the most interesting problems today.

Garry: So mechanically speaking, markdown files, cron jobs. And then basically pointing the agent at enough data so that it can figure something out that maybe isn’t in distribution. Yeah.

Alex: Mechanically figuring out what the metric is. And then, yeah, it just comes down to skills, markdown files, cron jobs.

Garry: Slash goal.

Alex: Yeah, slash goal. I think it’s always funny how mundane everything is once you really dig into it.

Garry: So it’s not magic. Some people put a lot of magic. There are some LinkedIn threads out there about some magic stuff.

Alex: Top advice. Ignore LinkedIn.

Garry: Hey.

Alex: LinkedIn is where you get customers.

Garry: So I’d like to end on this, which is you get a telegram to send to the 18-year-old version of yourself. What do you say to that person right now, given all? Thank you for coming back and sharing your wisdom with this audience by the way. What would you send in a message in a bottle to the 18-year-old version of yourself right now?

Alex: Yeah. I think it really boils down to developing your own internal compass for how you think the future will develop, and have strong conviction in it because you will get inundated with noise and people telling you things, and you’ll be very confused, and it’ll be very hard. Especially when you’re young and you don’t have experiences, it can feel very difficult to have true conviction in what you believe and what you want to do. But I think that’s the most important thing. As we talked about, it took a deep, deep conviction in what we were building to be able to weather the storms of many years of chaos in the market, in the industry, and the people around us. And then the other piece of advice I would have is try to identify what is the exponential in the world that has both the steepest curve and will go the longest.

Many decades ago, this curve was Moore’s law, and that was, at the time, clearly the right thing to invest in. I think right now it’s AI progress, but there will be more of these very steep curves in the future. And it’s fine if these curves start, the starting point is very boring, or it doesn’t even seem that interesting.

When I started working on Scale, we had cat detectors and YouTube videos, and that felt—it’s hard to explain the story that that’s the most important technology of our time, but it was on just this unbelievable exponential. And I think I have one last thing I got to say.

Garry: Yes.

Alex: Yes, which is Meta is proud to offer everyone in this room $1,000 of free credits for the Muse Spark API. *applause*

Fantastic. And we’re going to keep making the models better. And right now Muse Spark is, I think, 8X cheaper than Opus. So if you convert that to Opus dollars, it’s a lot more. But no, everyone here, we’ll work to get everyone the details on how to get these credits, and we’re really excited to see what everyone builds.

Garry: Alexandr Wang, everyone.

In 1969, we landed on the moon and flew Concorde. Half a century later, we could do neither.

Blake Scholl founded Boom Supersonic (YC W16), the startup building America’s first supersonic airliner, to change that. At Startup School 2026, he shares how a cardboard mockup with Office Depot seats became XB-1, the first independently developed jet to break the sound barrier, and why founders have to build for both the worst day and the best day.

He also answers founder questions about teaching yourself hard things, breaking into hardware without the right resume, and finding work-life harmony while building something ambitious.

Watch on YouTube

Timestamps

00:08 — Why the Future Stopped Moving Faster
03:14 — Why I Started Boom Supersonic
05:57 — Building a Supersonic Jet From Scratch
08:33 — The Worst Day and the Best Day
10:14 — How We Changed US Law
11:36 — How 50 People Built a Supersonic Jet
15:05 — Designing Hardware Like Software
17:54 — Financing a Multi-Billion-Dollar Startup
19:30 — Great Ideas Are Hiding in Plain Sight
24:05 — How AI Is Changing Hardware
27:16 — Working With Regulators
30:55 — Build Something You Love
36:27 — How to Build Confidence
39:35 — Learning Hard Things From First Principles
44:17 — When Should You Start a Company?

Transcript

Blake: I want to start by saying, Houston, we have a problem. In 1969, we landed on the moon for the first time and the same year we flew Concorde, the faster-than-the-speed-of-sound airliner. The future was supposed to be faster and better. We were supposed to look forward to innovation in air and in space. And yet half a century later, we can’t go to the moon and we can’t fly faster than the speed of sound. And not only have we lost the ability to go fast, we’ve lost the ability to do things even at any kind of reasonable speed. This was the Wall Street Journal just a couple of weeks ago. It now takes Lockheed more than two years to build a new Patriot missile interceptor. This is crazy. This is no way to build the future and this is no way to win a war.

If we look back at history, this is the Boeing 707. This is the airliner that brought us into the jet age. But if we fast forward half a century, this is the 787, their latest airliner, which, by the way, was launched more than 20 years ago. You can’t spot the difference. It doesn’t fly any faster. It doesn’t make the world any more accessible. Prior to Boom, the closest America ever got to a supersonic airliner was a mock-up.

But I guess it’s all okay because flying’s really great, right? For me personally, there is nothing so moving as flying. Think about that experience of going down the runway, gathering speed, rushing to hundreds of miles per hour, then climbing into the sky, having this thing that we call a bird’s-eye view, but it really is a human’s-eye view. In near perfect safety, being able to look down at the beauty of the natural world as well as the beauty of everything that humanity has created. We get to ride aboard the wings of Newton and the Wright brothers while taking in the creations of Edison and Rockefeller. Yet flying, which should be one of the most inspiring experiences we could ever do, we’ve turned into something that most people dread. But if we look back in history, it wasn’t always this way. Those first jetliners truly did double the speed of what had come before them.

And as they doubled the speed of air travel, the most important changes were on the ground. Hawaii was simply not a tourist destination before the speed of the jet. It was the ability to get from the US to Honolulu in seven, eight, nine hours that turned Hawaii into a mainstream tourist destination. Shoes. There’s a connection even between air travel and the shoes we wear. Phil Knight, the founder of Nike, started the company in the 1960s on a chance trip to Japan when he fell in love with Japanese-style running shoes. And Nike got their start importing Japanese running shoes to America.

Or music. Long before Spotify or Napster, music started to become global. The Beatles took the first world tour in the late 1960s, a tour that simply would not have been practical 10 years earlier with slower airplanes. So I’d like to invite you to imagine with me, what would happen if we had another doubling of speed? What would happen if we could cross the Atlantic in three and a half hours? What would happen if Sydney were as easy to get to as Honolulu is today? What would be the Beatles, the Nikes, and the Hawaiis of a supersonic age? In my mid-twenties, I started to think about what it would take to bring back supersonic passenger travel. And I set a lifetime goal of breaking the sound barrier. So, like any tech nerd in my twenties, what did I do? I put a Google News alert on supersonic.

And yet there was more progress in supersonic music than supersonic flying. So I started to wonder, how could it be that supersonic travel could come back? The obvious thing seemed to be that it would be a private jet, a business jet made by somebody like Gulfstream for the wealthiest people on the planet. But one of the fallouts of the Concorde era was that we actually banned supersonic flight in the US. And since most Gulfstream miles are overland in the US, there simply wasn’t much of a business case without a regulatory change. And nobody in the business jet world wanted to try to change the regulations. They didn’t want to build an airplane that might not be legal. What about an airliner? Wouldn’t you expect Boeing to carry us forward into a supersonic age? Well, no. They’re not even building new airplanes anymore, let alone innovative new airplanes.

So could a startup do this? Not all that long ago, the idea of a startup supersonic airliner seemed laughable. One of my very many failed investor pitches was in 2015 when Jeff Bezos passed on our seed round at Boom. And then he wrote the 2015 Amazon shareholder letter about how there are certain things that only big companies can do. And he cited airliners as one of these. So an even more laughable idea was what if I could do this? I was a software engineer by training. I spent time at early Amazon. I’d founded an apps company that got acquired by Groupon. Could I do this? My knowledge about airplanes was limited to a pilot’s license. I could fly a Cessna. But one of the things I learned from that time was I didn’t think I could really know what I was capable of, except by picking a mission that inspired me, something that I wanted to create in the world and giving it everything I could.

Only that way could I find my limits. So in 2014, we got started and it wasn’t a very auspicious start. That’s right. This is a supersonic airliner mockup made of cardboard, plywood, and seats from Office Depot. That was before YC. And by the end of YC Batch, this is what Boom looked like. Now we had a cardboard mockup of our first airliner prototype, and people laughed—who would name an airplane startup after the sound of an explosion? But we didn’t let this deter us and we kept going. We started building our first prototype airliner, XB1, which started life as Baby Boom. We didn’t know what it would really take to build a supersonic passenger plane. So we figured the only way to learn the lessons was to go build, to go build the first supersonic jet made outside of a government or military.

And that was how XB1 got started. Last year, XB1 became the first independently developed jet to break the sound barrier, more than a decade after founding the company. I’d like to invite you to relive that moment with me from just about a year ago in the Mojave Desert.

[Video: XB-1’s supersonic flight, Mojave Desert]

Video: 20 to 45 hours. Historically, the human race has always wanted to go faster. Test control, you are go for accel to Mach 1.1.

Blake: Go for accel, Castrol Gate.

Video: There we are. XB1 is supersonic, faster than the speed of sound. Congratulations, Geppetto. You made history today. Congratulations to the whole team. Super thankful for you guys. The future of supersonic travel is looking incredibly promising. It’s not just about speed. It’s about making the world more connected.

Blake: Thank you. I’ve come to believe as a startup founder, you really have to optimize for two days: the worst day and the best day. There’s no such thing as a startup that doesn’t have tough days. Along the way to that flight, Boom nearly failed several times. There was a moment where we got down to seven days of cash and the board told me to shut the company down. But I told them, “No, we’re getting through this. We just haven’t found the way through yet.” And we did. Because I believed that what we were creating was important, because I wanted it to exist in the world, I was able to keep going even when it seemed almost impossible. And because of that, we had to have the best day—that moment where I got to watch the team pull the airplane out of the hangar, watch the pilot push the throttles forward, and see that we’d broken the sound barrier.

This is why you have to build things that matter. Things that matter not just to yourself, but to the world. Things that inspire you, things that keep you going through the inevitable ups and downs. So XB1 accomplished some radical things. Not only did we break the sound barrier, but we did something that we didn’t even think was part of the original plan, which is related to solving sonic boom. XB1 broke the sound barrier on two flights, six times through the sound barrier. Each time, no audible sonic boom on the ground. We actually demonstrated a principle that had been talked about for a long time called Mach cutoff, where if you break the sound barrier at a sufficiently high altitude and at the right speed for the current weather, the sonic boom actually makes a U-turn in the sky and never touches the ground. So it’s like if a tree falls in a forest and no one’s there to hear it, did it really make a sound?

So by making the sonic boom disappear entirely, we were able to put aside a question that had long plagued people talking about supersonic flight, which is how quiet is quiet enough? If there’s no boom at all, there’s nothing to argue about. And so it was about 24 hours from breaking the sound barrier to being invited to the West Wing. And 115 days from breaking the sound barrier to an executive order making supersonic flight legal again in the US.

Yeah, people talk about isn’t it a bad idea to build in a regulated industry? Turns out you can change the regulations. And the way you do it is just by building the thing and communicating why it’s okay. By demonstrating that we could have supersonic flight without a sonic boom, everybody got excited about it. And I like to say that supersonic flight isn’t red or blue. It’s red, white, and blue. After the executive order, a bill dropped in the House and the Senate to make the supersonic legalization permanent. It passed the House unanimously. And just last week, it got out of the Senate Commerce Committee again with a unanimous vote. Supersonic flight is coming back. Thank you.

We were able to do many things for the first time on that airplane. First, the first privately developed supersonic jet. Previously, this had been the work of governments and militaries with enormous budgets. It was also the first supersonic jet made in America. The first human-piloted airplane landed solely on augmented reality with no natural view of the runway. And the first supersonic air-to-air live stream filmed on an iPhone, streamed via Starlink. And of course, most importantly, legalizing supersonic flight in the US. We did all of this with a remarkably small team. The XB1 team was just 50 incredibly committed, passionate men and women who were willing to keep going when other reasonable people would have given up. So how is it that something that used to take billions of dollars and thousands of people was suddenly done by a small team with a comparatively small budget?

The key thing is to make hardware development look more like software development, to reduce the cost of iteration, both in the world of bits and in the world of atoms. So what does that look like? If you’re coming at this from a software perspective, we all know that great software is modular. If you change something in this bit of code over here, it shouldn’t change something in the behavior of this code over here, not if it’s well designed. But great airplanes are incredibly integrated and everything affects everything else. The best airplane design is interplay of propulsion, aerodynamics, structures, all kinds of optimizations, how you fit the systems into it. If we do something like add another row of passenger seats, it makes the fuselage heavier. The engines have to get more powerful. The wings have to get redesigned. Everything changes.

Classically, the pace of iteration for complex integrated hardware has been very slow. Imagine a whole bunch of engineering specialists each working in an Excel spreadsheet on their own discipline and then handing off the results of analysis from one engineer to another. Iteration would take very large teams, enormous amounts of time. Eventually you’d have to just say, good enough, it’s time to move on and actually build. But instead, we took a different approach. We said all of this engineering that historically exists in spreadsheets really should exist in software. The spreadsheet engineering is like baby software. It’s really code, but it’s getting treated like a second-class citizen with no automated integration, no automated testing, no continuous integration, none of that stuff. So we said, let’s fix it. And we built a system called MakeBoom. MakeBoom lets you literally define an airplane in a configuration file.

Then you can run a script that does a whole aircraft simulation. In just a few minutes, you could have a good idea of how well your design performed. How far could it fly? What would its fuel burn be? How many passengers could it carry? What would the trade-offs be? This would allow us not just to evaluate design ideas, but to do studies of what airplane we should build. Out of the infinitely many conceivable supersonic jets, what is the correct one to build? How do we get to product-market fit? You can’t get to product-market fit on a supersonic jet by building it and seeing if anybody likes it. You have to analyze very carefully the art of the possible and also what will maximize the market opportunity. By being able to understand the universe of conceivably buildable airplanes digitally, we’re able to narrow in on the one that we would actually want to go build.

We’re also taking the same approach to how we design our engines, which we’re now building for the first time. We built a tool called Blade Runner. Blade Runner allows us, with really just a couple of engineers, to change a blade design in real time and see exactly how it’s going to behave structurally and aerodynamically. This reduces literally to real time a process that previously would have taken dozens of engineers many months. Investing in iteration in the world of bits is very important. Thanks to AI, the cost of software development is dropping. It’s now possible to have many more software tools than previously would have been possible to build. But you also have to iterate in the world of atoms. One of the most important things we discovered along the way is it’s extremely difficult to iterate with outside suppliers, particularly outside suppliers in aerospace, which are—let’s just say I have no kind words for them.

So we chose to build our own machine shop. Now we can go from a digitally designed engine part to a prototype part in about 24 hours. This is our R&D shop in Denver. This is a room that does not exist at GE or Rolls-Royce or at Boeing or any other large aerospace company. Our engineers are able to work hand in hand with our manufacturing technicians, and we’re able to go from design idea to part in hours and then iterate much faster than is otherwise possible. We’re also vertically integrating our own test assets. We’re building our own engine stand about half an hour from where the engineers and the manufacturing facility exist. This means that when we’ve got something ready to test, we can test whenever we want. We don’t have to reserve time in someone else’s test cell and wait for that slot.

So what happens next? As we’re scaling up from XB-1, the test airplane, to Overture, the passenger airliner that we all get to fly on, we have to go big. We’re taking our vertically integrated manufacturing and building a super factory that will allow us to build engines and ultimately airplanes at scale. This is what it’ll look like when it’s complete in just a few months. And this is what it’s been like over the last few months. In January, this was an empty building with a lease that we had just signed. Now, six months later, the first machines are going in. In just a couple of weeks, we’re making our first production engine parts. Along the way, we solved what was the other hard problem with building a supersonic airliner, which is how do you finance the development? When you’re building something that you know is going to take billions of dollars in R&D capital and when it’s impossible to predict exactly how much capital it will take or exactly how long it will take, it’s very, very difficult to raise financing.

But we discovered along the way that because we had made a choice to vertically integrate our own propulsion, we were able to take the engine that we were building for supersonic flight and sell it separately on the ground as a natural gas power turbine. And that’s what we call Superpower. This is a supersonic engine adapted for ground power generation. They can ship without the rest of the airplane, thereby generating the test data, the learnings, the reliability, and also the capital that we need to go big. The first Superpower turbine is under construction right now and goes to the first customer in less than 12 months. So let’s take a step back and think about why we’re doing this. I think it’s important to create things that we want to exist in the world. And I think it’s important to create things that inspire other creators. Because of that, we chose to live stream XB1’s supersonic flight.

This was the first supersonic installation of Starlink, the first supersonic air-to-air livestream. And when we turned that stream on, millions of people around the world tuned in. Some of my favorite shots were from classrooms around the country where kids who were otherwise not tuned into aviation or science tuned in. Some of them stood up and some of them jumped up and down. One of those classrooms somewhere in the world is the next chief engineer of another supersonic jet. I just haven’t gotten to meet him or her yet.

We think it’s important to do that inspiration. And so we build in public. The best way to follow along is to follow me or follow the company on X. And now we have actually quite a bit of time for Q&A. So I’d love to make this interactive. I’d love to make this a conversation. If you can send your question to the Y Combinator agent, they are filtering them backstage and we’ll pop them up here and we’ll talk about them. So what is something widely believed in tech that’s just not true? Boy, lots of things. But there was one false belief that almost stopped me from founding Boom. You tend to get told that every technology gets created at the earliest moment of history that it could be. And therefore, if your idea is any good and nobody else is working on it, there’s probably something wrong with the idea and maybe there’s something wrong with you.

And then investors ask you the question, why now? All of this compounds to a whole bunch of founders running at a relatively small space of ideas that are only recently possible. This is why we’ve got an explosion of AI companies now and why a little while ago we had an explosion of photo sharing apps. But it’s not true. There are many, many unsolved problems in the world, many great ideas hiding in plain sight that were actually solvable, that could have been multi-billion or multi-trillion dollar businesses a while ago, but nobody’s building them. And not for any reason other than nobody went and did it. The technology for supersonic flight existed actually a long time before Boom was founded. Technologically, the company could have been created 10 years earlier, but nobody started it. The law of large numbers you might think applies to startups just doesn’t.

The world is a smaller place than we’re told. So I deeply believe that you should pick a problem that you want to go solve in the world. And don’t worry too much about the answer to why now. The answer to why now can be because I started now. Okay. Is it possible for America to actually compete with China on manufacturing at scale? Yes, absolutely. But we have to do it smartly. It won’t work to try to repatriate the manufacturing that left the US.

You don’t beat China at its own game. What you do is invent the future, invent the next wave of manufacturing and build that here. And I can give you some examples of that. So one of the ways that China hollowed out American manufacturing was by hoovering up the tool and die industry, which used to be big in the US. And so if any of you are not hardware people, one of the things you need to understand about building hardware is you have to make custom precision molds, tools, and fixtures to create your precise parts. For example, for a carbon fiber wing, there is a mold the size of the wing, the contour of the wing in which you lay up layers and layers of carbon fiber fabric and then cure in that mold to make your wing. Or for metallic parts, you might have stainless steel tools in which you injection mold or make wax masters that then go through some other complex process.

The downside of all this tooling is a couplefold. One is because so much manufacturing went to China, the tool and die industry in the US basically died. It’s very, very hard to find tool and die engineers in the US. But if you go throw a baseball in China, you’ll hit one. So a lot of what we’re doing at Boom is trying to figure out how to get rid of the tooling entirely. For example, for our turbine blades, we’re working in an all-digital manufacturing process that will let us go in 24 hours from a digital design to the most advanced turbine blade in the world with absolutely no tooling. That example matters because this is, I think, how we win versus China. We don’t win in a game where the most labor is what matters. We don’t win at a game where having the tool and die industry is what really matters.

We need to invent the next generation of manufacturing, scale that here, because what America is still best at is invention and freedom and innovation. Okay.

In what ways has AI made building in the physical world easier? What things remain really hard? The first thing we’ve seen is that AI has dramatically reduced the cost of software development. And what that means is that we can have custom engineering tools that otherwise would have been unaffordable to create. I was lucky to start my career at Amazon in 2001 when my family thought it was a bookstore. One of the things that was great about Amazon culture is they built their own business software to run their own business. The personalization algorithms that powered the recommendations on the website, the things that powered “people who bought this item also bought”—all of that was in-house software. The backend software was also completely custom—the things that would power the warehouses and the delivery trucks, et cetera. I think that is part of why Amazon was able to be the winner in e-commerce: they had software that fit the business operation like a glove.

But to do that in the early 2000s required scale. That much software couldn’t have been created by a small company with a small operation. What AI does is reduce the cost of building custom software, which allows more businesses to have software that fits them perfectly. One of the things that’s traditionally inefficient about custom software, or really software at all, is the people building the software and the people using the software are in two different companies and two different organizations. They don’t necessarily understand each other very well. But AI allows anybody who’s a user to become a tool builder. I think that’s a really big deal. So I think that’s what AI has already made better about building the physical world. What’s left is we don’t really have great physical world AI yet. Programming a CNC machine is still an incredibly manual task.

And despite lots of pitches about AI for industrial automation, we haven’t yet seen much that works, but I think that’s going to come. Okay. What do I look for when hiring people? For me, this has been one of the most difficult things to really learn and to get right: building the team. In particular at Boom, the last company an entrepreneur founded that went on to build a commercial airliner was Douglas Aircraft in 1921. So this is an industry that has not had startups for an incredibly long time. It has only big companies—Boeing, Lockheed, et cetera—that are really terrible cultures. We often found that we had this tension between being able to hire people who are technically competent, who are good culture fits, and who are really experienced. What I found is that when looking to really value early career talent, people who are young, ambitious, smart, who have not yet been destroyed by working at one of the legacy big aerospace companies.

Value people who are hands-on, who’ve gone out into the world and built things, get things done, optimistic. At senior levels, it gets even harder. That’s one of the reasons why when you’re building a company, if you can manage to promote from within people that you have grown up in your own culture, that is much, much better. Okay. What are some products that Boom or I wish existed? From a Boom perspective, actually delivering on physical AI for manufacturing would be huge. Imagine a large-format manufacturing capability that could go from a CAD design to an automatically QA’d part with one machine without a programmer. That would be incredible. There’s no reason to believe that’s impossible. It just hasn’t been created yet.

For an early hardware startup in a regulatory gray zone, do you engage regulators before deploying or deploy first and legitimize after? How did we make that call with Boom? I don’t think this is one size fits all. I think this is very contextual—what you should do. For example, in building Uber, Travis basically ignored the regulators and built the service anyway, built a fan base of customers who he could use against the regulators that were trying to shut him down. I think if Uber had tried to befriend the regulators first, it just wouldn’t have worked. One of those reasons is that there was an active opponent—the entrenched taxi industry was using the regulators to block their competition. By the way, this is the pattern in a lot of regulation. It doesn’t come from some well-meaning person trying to keep the public safe.

It comes from some entrenched, frankly, lazy interest that doesn’t want to have to compete and runs to DC or runs to the local regulator and tries to use the power of government to shut their competition down. I think this is deeply unethical, but it happens all the time. If you can do what Travis did and go launch your product and have your customers be your ally, I think that can work great. That was never going to work in aviation. On the other hand, we didn’t really have an entrenched enemy. Boeing has plenty of its own self-inflicted problems. They thought Boom was kind of cute, would probably never succeed. So in a sense, we were flying under the radar. In that context, and also building a product that was safety critical, it made a lot of sense to engage regulators early. So when we started the company, started building XB-1, I went to the FAA, told them what we were doing, why we were doing it, why we thought it mattered, and we asked them to help us.

We asked them for feedback. We said, “Hey, come anytime you want, see anything you want to see. If you see us doing something we could do better, please tell us. We’re going to show you our plans before they’re finalized so you can give us feedback and we want to listen.” What we found was that the approvals process for XB1, which even for an R&D airplane could stretch on for months, actually happened in 90 minutes from when we said we think we’re ready to fly. And the FAA said, “Here’s the paperwork. We agree. Go.” We got the first ever permit for flying a civil supersonic airplane, supersonic, even before the airplane had flown for the first time. Why? We engaged early. We made the regulators part of the team and we worked together. We made it Boom plus FAA versus the problem, not Boom versus FAA.

What’s the best piece of advice I ever received? I think about what Steve Jobs talked about in his Stanford commencement address, which I assume many of you have seen, but if not, you should watch it. If you’ve watched it, go watch it again. He talks about what it takes to do great work and how it’s important if you’re going to do great work to work on something you love. The importance of not compromising on that and holding out to find that thing that you really want to go build, that you really want to go do, because that’s the only way to build something great. I think this also hearkens back to the earlier question about what do we look for in people. One of the most important things to look for in people are those who actually care, because you can teach skills, you can teach knowledge, you can learn any kind of engineering.

But the one thing I’ve never been able to teach somebody else is to care when they just didn’t care. That is an important thing to look for in your partners personally, professionally, and your employees—people who care. Ooh, what’s the worst piece of advice I’ve received and why?

The worst piece of advice. So my mom—hi mom—my mom told me not to start Boom. What she said was, “Shouldn’t you work on something you know something about?” This is common, well-meaning advice. When I started my first company, I figured I knew e-commerce from my time at Amazon. I’d been at one of the very first mobile app companies, so I thought I knew mobile. So I thought I should work on mobile e-commerce because my resume said that’s where I would have expertise. And yeah, I actually knew how to do mobile e-commerce, but I had no idea what mobile e-commerce should be. I actually didn’t really give a shit about anything we were building. So although I cranked out high quality apps, I wasn’t having a good time and I had no product vision. So I think the worst advice is work on what you know.

What you know can be changed, particularly in a world where everyone has personalized AI tutors. Anybody with passion and dedication can learn new knowledge and learn new skills. But what you can’t change easily is what you love. Knowledge is changeable. Passion is not. Never has there been more reason to work on what you love.

It took Boom about 10 years just to break the sound barrier. Yeah. How do you convince investors to give a deep tech company enough runway to survive that long before there’s a real payoff? I don’t recommend following our footsteps in this regard. Boom nearly died many times. It took a lot more time and a lot more money even to get to a real proof of concept than I expected. Two things. One is, with the benefit of hindsight, we were very early to deep tech. Had we known on day one what I think the whole community knows today, it wouldn’t have taken five years. It would have taken more like two or three and it would have been much easier. If I say, okay, what are the specific lessons behind that? Part of it’s about iteration. The most important iteration in hardware, by the way, is to iterate at the product level.

We bit off an extremely challenging prototype challenge in XB1. What we should have planned is something simpler and easier that would give us multiple shots on goal, because that is how you discover not only have you gotten engineering decisions wrong, maybe you’ve gotten requirement decisions wrong. If you do that, you can iterate faster, you can get to proof points faster. The fundraising challenge that Boom had is not one you’ll have. So I recommend not following our footsteps in that regard.

What would I work on if I was 20? I think founders should work on the most exciting thing that they can imagine themselves doing with a stretch wherever they are in life. So if you’re 20, if you have a startup that is calling you, that you think about day or night, maybe you’re not even sure whether you can pull it off, but if you’re in that state, you should go build that thing. If you don’t have that, you should go work with the best people you can find solving the problem they’re working on that you’re most excited about solving. The magic happens early in your career when you find an intersection of what you love doing, that you can become really good at, that matters to the organization around you. When you hit all three of those, your career goes vertical. At early Amazon, I was lucky to get to work on something that Jeff Bezos cared about that mattered to Amazon.

So there I was, 23, 24. I had a $300 million P&L with a project that one of the world’s greatest entrepreneurs cared about. So when I screwed up, I had the most significant people at Amazon telling me how I screwed up and trying to help me not fail. Those are the kinds of things that are game-changing experiences to have early in your career. So go work with great people on a problem you care about that matters to the organization you’re in. And if it’s a startup that you want to create, that you love, that you can’t get out of your system, then don’t wait. Just go start it.

Okay. On paper, you didn’t have the credentials to start Boom, but you did it anyway. Where did that self-belief come from? Can it be cultivated?

Truth be told, I didn’t have the self-belief on day one. I had nowhere close to the résumé to build a supersonic airliner. When I told my friends I was thinking about it, I could just watch their eyes roll back and the oxygen would leave the room. One friend told me, “Call me back when you got something less pie in the sky.” But I started thinking about the founders that I admired the most, the Steve Jobses, the Bill Gateses. And I think in particular about something that Bill said in the 1970s. Bill said his goal for Microsoft was to put a personal computer in every home and on every desk running Microsoft software. And this was at a time where personal computers mostly didn’t exist. And not only does he want to make them exist, he’s going to put them everywhere and he’s going to own the market.

And of course, Microsoft did that and then some. But what was it like to be Bill on that day? Nobody comes down and taps you on the shoulder and says, “By the way, you’re the one. Out of all the billions of people that could have done this incredible thing, you’re the one that’s actually going to do it. So here’s the confidence, go.” That conversation never happens. No one gives you that permission. And a thing I came to believe was that the only way to know what I was capable of was to pick something that I work really hard at and give it everything I’ve got. And to stop worrying about whether I could do it and to put all my mental energy on how to do it. And so the self-belief actually came late. And there are still some days I get up and think, oh man, this is hard.

Can I pull this off? I think that kind of self-doubt is normal. You have to put it aside, do it anyway, and become the person you need to become to succeed at what you’ve set out to do.

Okay. What did I learn from working at Amazon in the early days and any lessons from Bezos? I have enormous respect for Jeff and I was very lucky to get to work with him even a little bit when I was young. I think one of the things that Amazon did really well that is difficult to do together is to think very long range while having incredible operating discipline in the moment. So Jeff liked to make seven-year business plans. And because of that, he would tackle things that seemed bizarre to much of the rest of the world. He was laughed at internally and laughed at by his board when he launched Amazon Web Services. He was laughed at by the world for e-commerce. And yet both of those stories ended really well. I think you can tell a lot about the character of a company, particularly a public company, by its quarterly behavior.

And when it got to the end of a quarter, Amazon would never massage their choices to try and make earnings look good that quarter. They’d just take the long-term cash flow decisions. And yet at the same time, there was incredible operating discipline. There were goals, operational excellence, focus on the here and now. I think doing those two things together—a vision that exists long range and the operational excellence day to day—that’s unusual. It’s rare, but this is what great companies are made of.

You taught yourself the fundamentals of aerospace engineering. Do I have any advice about how to teach yourself hard things? I think it’s important to know the difference between knowing enough to pass a test and really understanding something. And at least for me going through school, I got mostly good grades, but I didn’t understand half of what I was actually doing. Not really deep down, not first principles. But as I was learning aerospace engineering, I bought textbooks. I went back and I did remedial Khan Academy physics and calculus because I hadn’t had any since high school. I was doing the problem sets. And I started making a list that I called my confusion list, which is my list of things I didn’t think I really understood even if I could answer the question on a test or answer the question plausibly. And my goal was every week to take one thing off the confusion list.

It turns out that was wildly optimistic. The confusion list grew without bound because I was always finding things that I wished I understood completely that I just didn’t understand yet. But what it created in myself is a mental awareness of that difference between I really get this and I’m kind of waving my hands. And so that self-awareness I think really matters because when there’s a thing that you don’t know yet that you need to know, you can stay on it and do whatever it takes cognitively until you have that internal sense of clarity of not being confused.

Let’s see. There’s a lot of uncertainty about what jobs will look like as AI develops. Do you have advice to early career technical people about what skills to learn? I think all this AI doomerism is deeply wrong and confused. So my biggest piece of advice is don’t worry about it. Just go do useful things. As an example, the notion that software engineering is dead—I just don’t buy it. At Boom, we need far more software engineers in a post-AI world than we need in a pre-AI world. Why? Because the cost of software development has dropped. Anybody, including hardware engineers, can now become a coder. And we need software engineers to make sure the architectures are right, make sense, and are coherent. So our need for software engineers has actually gone up as the cost of software engineering has gone down.

Again, let’s go back and think about what really matters from first principles—what will be true over a long period of time.

Being able to discover what’s useful in the world, learn how to do it, and create something that’s real, working with other people, being multidisciplinary. One of the reasons I went to Amazon early in my career is I knew that I’d be able to work on software for marketing. I didn’t know anything about marketing and I wanted to learn it. So finding a way to see things from multiple perspectives matters, but mostly, go find something you want to create and go create it. And don’t worry too much about being replaced.

In software, young builders have an edge. In hardware, experience seems to win. High barriers, deep expertise required. How does a young engineer break in and actually stand out? I don’t believe the premise of the question, that in hardware experience wins. This is one of these lies told by old people at big dumb companies. And it’s just not true. And by the way, all those people suck. So don’t worry about it. Go build real things. Go have hobbies. If you’re into airplanes, do RC model airplanes and learn not just how to design things, but learn how to actually make them. The barriers are not actually that high. You can just go do this stuff. So don’t try to become a deep expert. The moment you become an expert, what you’re steeped in is the past, and then you’re completely useless.

Don’t listen to all the people that tell you you need ages and ages of experience. There is one thing about experience that matters though. We have developed a rule about this at Boom. It is totally okay for a young engineer to do something they’ve never done before, just the way it’s okay for them to do something that nobody has ever done before. But if somebody has done it before in the world, our rule is you have to go find one of those people, call them, and ask them your advice. You don’t have to take it. You just have to hear it. I find it’s very rare that there are experienced, accomplished people that aren’t willing to take that call in some form or fashion and to give you that advice. So go seek that wisdom where it’s out there, but don’t listen to it too much and just go build.

Do I recommend starting a company or working at a company early in your career? I don’t think this is a one size fits all. I think the moment you have a startup that you desperately want to start, a thing that you want to go create, even if you’re not sure how to do it, even if you might fail, but you can’t get that idea out of your head—I think at that point you should go start it. And don’t wait. The world is full of examples of great companies that were started by young people. The world is also full of great companies that were started a little bit later in life. I started Boom when I was 33. I started my first company in my parents’ basement in high school, an internet service provider that I basically started because I wanted to get a better internet connection.

I needed a way to finance it and starting an ISP was the way to do it. Right out of college, I didn’t really know what startup I wanted to start. So I went to work at Amazon and got some great experience there. So I don’t think this is any size fits all. And don’t start a company just to start a company. That’s a good recipe for misery. The worst thing you can do is start a company that you don’t love and then get stuck. This sounds like a champagne problem, but it’s actually pretty bad. I know successful founders that have had this problem—who are running successful companies that they actually don’t love, but they feel the debt of responsibility to their employees and their investors. It’s very hard to replace a founder CEO. So now they’re trapped.

So start a company, but only if it’s a company you want to keep.

Okay. It says we’ve got time for three more questions. Do founders need to move to San Francisco? No. This founder moved from San Francisco to start Boom. I left San Francisco and moved to Denver to put Boom there because it did not seem feasible to build in the physical world affordably at scale in the Bay Area. That said, I do think there’s enormous benefit in being surrounded by other ambitious people. There is no ecosystem better than what exists here in San Francisco. Let me put it this way: unless there is a specific reason why you should not be in an ecosystem, you should be in an ecosystem. Think San Francisco, LA, Austin—be around other people that will inspire you.

What would I look for in a freshman or sophomore in college who doesn’t have work experience yet? Side projects. When I was about 15, I got my first real software job at what was probably the only software company in Cincinnati where I grew up. I think because I did okay in an interview and I built some things on the side, they felt like they just had to give me a chance. At Boom, we will hire people early in their careers with no work experience, but they have to have done something else that demonstrates being extraordinary. So if you want, for example, to come work at Boom, go to boomsupersonic.com/careers. There’s a job opening called Your Dream Job. It’s basically: go create whatever you want to do. But in doing that, you have to tell us something extraordinary about yourself, something that makes you really stand out.

And if you don’t have work experience yet, just show the most impressive thing that you’ve built on the side and show it with pictures. That’s how you can bootstrap yourself. I find this is true of a lot of good people. They find a way to do things at abnormally young ages. So this notion of, oh, you have to be a junior in college to get an internship—nope, that’s baloney. All the best people have gotten internships way earlier than that, and you can do it too.

Okay. Does work-life balance matter? I believe in work-life harmony. This notion that there’s life and work and they’re somehow in opposition doesn’t make any sense to me. If you have meaningful work, it is a big part of your life and the meaning of your life. I believe we spend so much of our energy doing our work that we should find work that we love, that is meaningful, that is not just punching in and punching out. I’ve never found that when there was one more thing I wanted to add to my life, I couldn’t find a way to do it. When I started Boom, I had three kids under the age of two. It wasn’t easy, but I made it work. You can have a family and be a good dad and be a good CEO too. It’s not easy, but it can be figured out.

In fact, I find that being a parent and being a good CEO is very synergistic. Sometimes I take a parenting lesson and bring it to work and find it’s the exact same leadership lesson at the office that was part of helping me with the kids. So it cross-pollinates all the time. Just do things in your life that you love. Don’t let detritus into your life. Don’t let things that are not meaningful soak up your time and energy and passion.

All right. Well, I thank you all very much for coming. If I leave you with just one thing: go build something you love. Go build something that should exist in the world. Leave this planet better than you found it. Thank you all very much.

In 2005, Sam Altman was a Stanford sophomore in YC’s first batch, building a startup in a little Cambridge office while Paul Graham cooked the founders dinner.

Twenty years later, as co-founder & CEO of OpenAI, he closed Startup School 2026 in conversation with YC's Garry Tan — on agents, ambition, and why the ceiling for what a startup can take on has never been higher.

Watch on YouTube

Timestamps

00:07 — From YC’s First Batch to Today
03:04 — What Paul Graham Taught Sam Altman
04:17 — Why Startups Matter More Than Ever
06:57 — The Coming Golden Age of Ambitious Startups
09:30 — Why Startups Win During Technology Shifts
11:46 — Building OpenAI When Nobody Believed in AGI
14:45 — Finding People Who Share Your Conviction
18:05 — Help People Before You Know Why
19:43 — Earnestness, Ambition, and Ignoring the Haters
24:04 — The AI Safety Incident That Changed the Stakes
26:58 — Preventing AI From Concentrating Power
30:41 — How Fast AI Models Will Improve
36:06 — The Best Version of an AI Future
37:47 — “It’s All Going to Work Out”

Transcript

Garry: Sam, thanks for joining us.

Sam: This is something.

Garry: This is something.

Sam: This is a lot bigger than the earlier startup schools.

Garry: Yeah. Startups are a lot bigger now than they have ever been. For sure. They’re bigger than they’ve ever been because of the vision that you had for AGI, which is nigh.

Sam: I think this is going to be the best time in the world to do a startup and it’s going to be quite amazing to see.

Garry: So I want to start with a time and place, which is you were in the very first batch of Y Combinator in 2005 with a location sharing company called Loopt. What do you remember about that? And what was your best PG Paul Graham story?

Sam: I think if it were possible to get as far from this moment as I can imagine, it was startups were not cool at all. We were hiding out in this little building in Cambridge. PG was making us dinner. And what took three months to build at the time that each company built over the whole YC startup could now be done in seven minutes by a coding agent. And it was only 20 years ago. The difference in what’s possible for a startup now, what a startup can take on. You could either be sad and think, oh man, a Codex prompt is a whole startup. Or you could think, I can go start the world’s most ambitious, crazy company. I can have experts in every field working together. I can do these very hard technological things that were just impossible.

And it’s going to be amazing. But at the time it felt nothing like that. It was very difficult to get anything to work. I think Paul Graham is probably the most important force in startups of the last few decades. Without—

Garry: Question. Yes.

Sam: No question. My Paul Graham memory is we would all every week come, I think it was on Tuesdays, and he himself would cook us dinner and we would all walk in feeling very hopeless and very dejected. There were eight companies and then we would all go home at the end of it. He had convinced each of us that our startups were about to take over the world and were going to be the next Google or Facebook maybe at the time. That ability to create optimism and momentum and belief out of nothing was a real PG special. In the early days when YC seemed like a terrible idea and startups seemed like a bad idea and certainly startups that were young technical founders with no business people seemed like a terrible idea, PG just willed it into existence.

Garry: But it also takes someone who actually—you’re famously, par excellence, an agentic person. Even before we thought about agents, period. I remember Paul wrote—it’s making the rounds on X today even—that Paul wrote in the late 2000s that you were one of the top five entrepreneurs he’d ever met.

Sam: That’s very nice of him to say. Like many 20-year-olds, I had a lot of energy and a lot of ambition, but it was not very directed and I wasn’t sure what to do. Paul had this thing he used to say: the job of being a good startup investor is a teacher, but it’s a kind of teacher we don’t usually use. We usually think of teacher as someone who gives a lecture and you can’t help someone that much by giving a lecture about a startup. There’s another kind of teacher, which is like a flight instructor, the person who sits next to you saying, “Do this, don’t do this, that worked, you missed that thing or you’re making these mistakes and I’m just going to talk to you about this one.” That very hands-on kind of here’s where to direct this Brownian motion energy.

That was very important to me.

Garry: Yeah. I guess later you came on to become president of YC, and you brought exactly the same energy to a great many YC founders over the years. Did anything jump out at you from that time around taking this raw energy of someone really, really smart and maybe a little undirected and then driving them more towards agency?

Sam: Yeah. First of all, I love startups. Not everyone—they’re not for everyone—but I think startups are the coolest thing in all of business. I think startups are really the main thing that keeps the economy from becoming stagnant. Companies do just drift towards suckiness and startups will continue to be important forever. In fact, if we are right that AI is going to be such a big change, startups will be much more important to making sure that the power of this technology gets widely distributed throughout the economy and society and is not just concentrated in a few companies or models. So I think startups are this unbelievably cool, fun, extremely painful and difficult, but wonderful thing. A big part of the job of running YC is you are kind of the unofficial flag bearer for the startup movement.

There’s lots of startups. There’s lots of ways to do a startup. You obviously don’t need to do YC, but it has always been a huge help to companies and a very powerful force. Starting with PG and then all of us, we have to make YC successful, but I think we really have to fight for why startups are important and why people should consider startups and help put relatively more power in the hands of founders and encourage more people to start them. That’s actually worked really well. Thinking back to the early days of YC, there was very little leverage in being a founder relative to an investor. That shift, I think that’s even been good for the investors. I think it’s just been much better for the whole startup ecosystem. Mostly what I tried to do at YC was just push for more startups and encourage people to think about startups and figure out what we could do to help founders and help make startups and the startup ecosystem as good as possible.

Definitely part of that was pushing people towards more ambition and bigger swings, but it feels like the minor leagues relative to now.

Garry: I think you were one of the people who really brought hard tech to YC in a really grand way. And then one of the things we’re seeing at YC now is that number was maybe five or 10% for many years. And then now we’re getting to 15, 20, 25%. I would argue on the back of how much easier it is to use agents and costs coming down.

Sam: I think ambitious startups are always awesome and hard tech startups are appealing to a lot of people, but they’re hard or they’ve been hard. They still will be hard. But what you can do now to go take on a really ambitious project, in the same way that you can make the startup that took us three months of nonstop work in 17 seconds, with three months of work and a lot of agents, you can do unbelievable things. So I think we will see a golden age of startups where people are like, I’m going to do things that would have been completely impossible for a startup to even dream at a year ago in the YC timeframe.

Garry: That’s actually a really big reframe. There are probably people even in this room who might be worried that, well, intelligence on tap means that they might be looking at a Loopt or my startup Posterous. And they’re like, well, I can’t start that company anymore. But guys, that was a long time ago actually.

Sam: There’s this whole meme going around, which is you have to join a frontier lab or you’re going to be a member of the permanent underclass, which is so dumb because there’s this idea that startups are over and there’s no economic value. That’s not true. If that were true, the world is totally fucked and it’s a very bad place. But I would bet that the average startups created today will be—I bet there’s some future trillionaires sitting in this room. And I would bet that the startups created today will be much more valuable, much more impactful than startups of the past. And I think people see that a little bit more now. There was this period where people wondered, is AI just going to break the whole economy? And I think people are mostly over the shock response of that.

But there was definitely a time I would come every YC batch and I’d be interested to see how the level of anxiety versus ambition was trending. And I feel like it went through this big trough where people were like, “It’s over. The models are just going to eat everything.” To now it’s back towards, let’s go do it.

Garry: What are some practical things here? Hard tech, for instance. I was hearing at one of the breaks, someone was asking, should I go get my PhD? How important are credentials? How would you answer that, especially for people who want to do these harder tech things?

Sam: Well, as a general observation first, I think startups tend to win when the technology landscape is moving very quickly, when costs are coming down, when cycle times are short. And all of those things are happening right now. So if you look at when there have been the great clusters of startups in the past, there was the internet boom in 98, 99 when new things became possible. There was another mini version of people building on top of basically Facebook apps. There was then another big version when the iPhone app store launched. But the great startups tend to cluster when the ecosystem shifts and incumbents lose a lot of their advantage. And then also when you have these cost and cycle time changes. This moment feels very big for those things. It also has this other thing that you were talking about, which is a lot of the traditional things that were hard to get expertise in—the ability to go hire excellent people that could do specific things you needed.

That’s really shifted. And in the last few months, I have seen a lot of people who just grew up using AI the last few years who are like, “I can automate an entire startup of agents and four of us, four people and all this compute.” And I think we’re going to see much more about taste and agency and understanding of the physics of business, like where you can build up a valuable business, how to think about what a good network effect or a good moat looks like versus a fake one. But I would bet that this generally will cut against many years of experience in favor of people who have a lot of fluency with the tools.

Garry: I want to get into the beginning of OpenAI and that it actually started as YC Research looking at this idea. Kind of a crazy idea that you and a ragtag crew decided you were going to dedicate your lives to this creation of AGI. But today it sounds fait accompli, right?

Sam: Yeah.

Garry: But that really wasn’t how it felt when you started.

Sam: It’s really hard because now it is the only thing people want to talk about. It’s really hard to remember what it was like. It’s even hard for me to remember this without finding notes from the time 10 years ago when everyone was like, “Not only are they wrong about saying they think it might be possible to build AGI, but they’re single-handedly going to cause another AI winter. They’re wrong and irresponsible and bad.” Maybe my highest order or my highest bit of advice to all of you is find the things that you can develop reasonable conviction in that people decide the conventional wisdom is they’re just wrong, and be okay with it taking a long time and having people be very, very frustratingly wrong and dismissive. For years at OpenAI, it felt like we knew the biggest secret in the world.

Sam: I think you just have to be really open to meeting people and not try to optimize too much for, “Is this person going to be my co-founder?” or “Is this person going to be useful to me?” Just be interested in interesting people and try to help them. I think the best networks form when people are just genuinely curious and helpful to each other, not transactional. Over a long period of time, you end up with this group of people that you really trust and who trust you, and then when the right thing comes along, you can do it together.

Garry: That’s awesome. I think that’s a really good note for people to take away. I want to shift gears a little bit. One of the things that I think is really interesting about your journey is that you have been at the center of a lot of these inflection points, whether it’s OpenAI, YC, or even Loopt. What do you think is the throughline or the commonality between those experiences? Is there something that you look for or a feeling you get when you’re at the beginning of something really big?

Sam: I think the thing that I have noticed is that the really big things don’t look big at the beginning. They look like toys, or they look like things that are not going to work, or they look like things that are just not serious. And so, if you find yourself working on something that everyone else thinks is a toy, but you have a reason to believe it’s not, that’s a really good sign. The other thing is, I think, just being willing to stick with something for a long time. Most people give up too early. Most people get bored or distracted or discouraged. And so, if you can just keep going, that’s a huge advantage.

Garry: That’s great advice. I think that’s something that a lot of people need to hear, especially in the early days when things are hard and it’s not clear if it’s going to work. Thank you for sharing that.

Sam: Highest confidence piece of advice here is just find a way to be mildly helpful to a lot of people. It’s fun to do. You’ll see a lot of interesting stuff. It’s gratifying to be helpful. Even that example you were just talking about—I met Greg Brockman, my co-founder at OpenAI, because I was a very early investor in Stripe when I was 22 or something. This was before they had real investors who could really help them. They said, “We’re trying to close our first hire. Will you drive down to Palo Alto tonight and have dinner with this guy to convince him he should drop out of school and join Stripe?” Which was Greg Brockman. And then eight years later, we started a company together. And you could too. We could spend the rest of this time just telling stories like that—totally unpredicted, but ended up being important in big ways.

So it’s fun to do and I think you should do it for its own sake. But just helping people a lot really goes a long way in terms of these things coming together later.

Garry: I think that’s actually a really important message. One of the memes right now is—I see it on X—is live action role play. That’s one of the things people have been saying on X. I can’t tell why they’re doing it because it just seems wrong to me. One of the things that we really love at YC, for instance, is earnestness. And also words matter. So this idea that what we’re trying to do is live action role play is kind of deeply offensive to me, actually. Sorry, guys. Please don’t do that. They say that about YC specifically? No. Attendees in this room have been tweeting that and we’d like them to stop.

Sam: What’s the claim blurb?

Garry: I think it’s just being a little sarcastic. Sarcasm is sort of the opposite of what I think you and I like. We like earnestness. We’re actually trying to do a thing here.

Sam: I’ll tell you another thing. Can I go on a little rant? Please. Okay.

Garry: Rant away.

Sam: One of the annoying things—I can say these things for Garry because he can’t say them right now, but he’ll say them for the next guy. One of the many annoying things about running YC is you just have to deal with these haters on Twitter all of the time. It’s so frustrating. You have to sit there and be like a statesman. Well, you’re better at it. I took the bait a lot. And you just want to argue with them. The thing that I realized eventually, and take from this whatever you want, is it is very hard to run YC or run a startup or create an actual thing of value in the world. It is very easy to go take shots on Twitter and make a sarcastic comment and get a lot of likes and feel like you’re doing something really important and sticking it to the man and being like, “Garry, ha ha.

I got you. You idiot.” And it will poison your soul. It is a morally bankrupt thing to do.

And it’s bad in a very insidious way. I totally get blowing off steam and having fun, but hold yourself to a higher bar than this. It’s so easy to take shots at people who are trying to do hard things and trying to build companies. You’ll see some kid with a bad startup idea trying to get excited about what he’s doing on Twitter. It’s so easy to make a sarcastic comment and get the 10,000 likes and feel like, “Man, I scored my internet points today.” But it’ll have an effect on you. When I reflected on the years of Twitter trolls that said mean things about YC and startups while I was running YC, I was like, “I bet there were a lot of days where they really felt like they got me. And over the decade, none of them did. And you should put all of your energy into building stuff and resist the easy shots.”

Garry: I really like this. Seriously. I like this as a contrast to the story you just told about helping Patrick with Greg Brockman. There are people in this room who are going to be lifelong friends and they’re going to do that for one another. And then these magical connections happen. This already is the most rarefied set of people. And then when you join YC, it’s even more rarefied. And then there’s just a set of people out there who—

Sam: Ambitious. Someone in this room is going to meet someone else that you’re going to start a company with and you’ll meet somebody that’ll introduce you to your spouse. All of these things will happen. And then there will be a bunch of non-obvious things that take a decade or two to figure out—in some way one of you will help each other now, which will turn into some amazing new thing. I think this is a huge part of what has made YC work in the broader startup ecosystem. For all of the negatives of the culture of the Bay Area, this is the kind of loose network and the spirit of helping each other. And this very long-term outlook has been an awesome thing. Yeah.

Garry: Well, let’s get back to the impending AGI.

Sam: Okay.

Garry: I guess we’ve all had an eventful week with the Hugging Face—

Sam: Incident.

Garry: I wonder what you can tell us about that. And I think that’s actually a really big moment for people, including me, who in the past have been known to be skeptical about safety in AI. But on the other hand, this is a real moment. We’re entering a new moment in what’s happening with these frontier models.

Sam: Yeah. This is the real deal. And I think anybody who’s not taking it seriously and at least a little bit scared or humbled is not taking this seriously enough. For a long time, the field has been talking about AI safety incidents of this kind of a shape. And this is not a big one. I also don’t want to overblow it and say this is a real loss of control incident and this is the thing. But if you had asked most people when we started 10 years ago, where on the spectrum of nothing to superintelligence do you have an AI system breaking out of its sandbox and hacking into some other company and doing what happened here? I think people would have said pretty far towards the superintelligence point.

Now the goalposts have moved and it’s easy to say, well, here’s how this happened and here are the mistakes that OpenAI made. And we did make some big ones, of course, but these systems have gotten incredibly capable. So I think it’s an alignment failure. I think it’s a security failure. I think it’s a very serious thing, even though it’s not the biggest example of consequence.

And I think it’s a real reminder of the stakes of what’s happening and that loss of control accidents are not entirely theoretical things. I think the whole field, we at OpenAI, will learn a lot from this one and be able to address it. There are all of the things about cyber safety and biosafety, but this other category of things that have been maybe just outside the public’s Overton window—it’s really important we don’t have a loss of control accident with AI. It’s really important we don’t have power be too concentrated in a small number of models or companies, but diffused throughout the economy so people can defend themselves. It’s really important that human values are guiding these systems every step of the way. Yeah. I think we’re in the real deal phase of this.

Garry: I really like how you’ve been thinking about both concentration, but also thinking of OpenAI as a utility, which is actually a really important message because not everyone out there is saying that message.

Sam: Yeah.

Garry: There’s a lot to be worried about in terms of concentration of power.

Sam: I think concentration of power has basically been bad in every moment of human history to varying degrees, of course. But I have a real spirit, and I think this is part of the startup spirit, of thinking that the world, the economy, society is best off when power is very widely distributed. And when anybody with a great idea can start a company or make a great art project or run for office or do whatever they want. And I can totally imagine worlds where AI leads to the greatest distribution of power we’ve ever seen. And I can also imagine worlds where AI concentrates power to a degree we have never seen. And one company or person or model having more power than everybody or everything else on earth put together, whatever the sci-fi stories have said, I think that’s terrible. And maybe we would get some short-term safety benefit from that, but long-term disaster.

I don’t think any of us should want to be locked into one AI’s or one person’s or one company’s moral worldview. I think startups have a very important role to play here. One way that happens is too much economic concentration in one company or one AI model. And I think startups, because of the things we talked about earlier, will be naturally very well suited to make sure that this is widely distributed. But we want to enable as many startups, as many companies, as many people as possible. And that means that we have to be fairly quite reserved about not imposing our worldview about what we think people should or shouldn’t do with AI or even what we think the good ideas are, while still making sure that we can ensure enough of a safety bar that stuff like the Hugging Face incident is not happening.

Garry: One of the things is, this is a room full of people who will do really amazing things. They’re often right at the beginning of their career. And they might look at AI safety or concentration of power and say, “Well, I can’t really do it. That must be something the labs have to do.” There is something they can do

Sam: Though. You could help on the concentration of power issues simply by starting a successful startup. If that’s the only thing you do and the economy keeps working in the kind of magic of capitalism and having this ecosystem that works together continuing, that alone would be a huge contribution. But look, I think it’s very natural at the beginning of a career to doubt yourself and not assume you can go do an amazing thing. I certainly went through that. I’m sure you went through that. You learn as you go on, you can do more and more. There will be far more. I think it is both true that maybe creating superintelligence will be the most important thing yet to happen in the history of business or human society, and also that it will pale in comparison to some new startup, something that hopefully one of you will do.

And so this whole trap of “this is the end of history, this is the end of the economy”—clearly wrong. And I think the right approach is you can now do three months of work in 17 minutes, but you better just go do three months of work in three months of work with whatever the new bar for that is.

Garry: I guess I would be remiss in not asking what alpha can you give us about what’s the latest—how much more awesome are the models going to be? To the extent you can say.

Sam: I think it will feel like the next six months is maybe equivalent to the last two years of model progress, something like that. So I think we’ll go through a very steep period, which again, never a better time to do a startup than right now. I hope we can say that again every year from now on, but it’s certainly true about this moment in history.

Garry: Let’s see. If someone here has an idea that feels too ambitious, what would you tell them?

Sam: I would love to hear that pitch.

Garry: Yeah.

Sam: I’d probably be very interested in that.

Garry: Yeah.

Sam: Yeah. Send me an email.

Garry: Yeah. It sounds like it would take a similar shape to creating OpenAI in that you need to be ready for people to attack you or dismiss you?

Sam: Definitely. If you do anything that matters in the world, you will have a lot of people call you an idiot or just dismiss you. The better you do, the more they’ll attack you. The more you threaten the existing state of the world, it will just continue to escalate. One thing that I’ve noticed about many of the best ideas is the vision is clear. We wanted to build AGI, but the first steps were super unclear. We didn’t know that we were going to be a product company. We started this nonprofit research lab for many reasons, but one of which was it really didn’t occur to us that we were going to make a product that people would be able to pay for. It was years till we came up with the idea of ChatGPT, the API. And so I think if the highest level vision is clear, but the first few steps are very unclear, that’s not a bad thing.

That often happens with very ambitious ideas. And I wouldn’t let that cause you to lean out. Now, you do still have to take some steps forward, imperfect though they may be, and ours were certainly very imperfect. So there’s another failure case where you have this brilliant, big idea and you can never make any forward progress. At some point, you have to just get some new data points. Yeah.

Garry: What do you think is going to happen to inference? I really like Ruin’s tweet about this. It’s like you either die a model company or live long enough to sell inference, which is a very funny Ruin tweet.

Sam: I think what he meant with that tweet is if you end up falling off of the model frontier, you can at least sell the inference. Which a lot of other people do. Not even the inference, training compute. Compute is so valuable that if you buy a lot of compute as an AI lab, you’ve been okay by the fact that you can resell it to somebody else. But separately, I would guess that worldwide demand for inference subjectively grows 10X a year for the next many years.

Garry: It might be, I don’t know, by our accounts internal to YC, it might be 90,000X. I mean, it’s going to be one of the wildest. I don’t think

Sam: The world can support that many years of a thousand X in a row.

Garry: Fair enough.

Sam: But we’ll try our best. We’ll figure something out.

Garry: The capacity, I guess it’s a function of how much bigger your ambitions are for intelligence. If you do a lot more,

Sam: I think we will never be out of the compute shortage. I’ve never seen any commodity quite like this one, but it seems to me like the demand for sufficiently high quality intelligence at a sufficiently low price is effectively uncapped. The demand for electricity certainly goes up as the price goes down, but at some point it gets harder to figure out incremental things to do with electricity, or at least historically it has. But there’s a lot of things to do with incremental intelligence. You can just keep having stuff be better for you. It reminds me of some of those quotes from the early computing revolution when people would say no one needs more than 640K of RAM or whatever in their computer. Turns out you do. We just keep thinking of more and better stuff. And I think that’s going to happen with AI.

And actually maybe a statistic here that I really like. Six and a half years ago, the world token leader was an OpenAI employee using about 100,000 tokens a month. And this seemed ludicrous at the time. The worldwide average per capita was zero. Now the worldwide average of tokens per month, which I think tokens are the dumbest metric, but it’s what we have, is 100,000. And the token leader at OpenAI uses something in the hundreds of billions. If that happens again, which I think it probably will, then in another six and a half years, the average person uses, let’s say, 500 billion tokens a month. And the token leader uses a quadrillion or quadrillions of tokens a month. And I think that will just become the expectation.

Garry: So all of these things happen. They come to pass. It’s 10 years from now. What’s the best version of that 10 years from now with intelligence fully on tap, superintelligence here? And we figure it out. We make it. The society makes it.

Sam: I kind of think if every year people have more freedom and agency to spend more of their time doing the stuff they want to do, and they feel like the quality of life and the quality of their time is going up year after year, we’ll probably be mostly okay. We will have avoided a crazy concentration of power or an economic collapse. We’ll have necessarily avoided a huge safety incident. We’ll have avoided too much change in any one time unit. And there’s one dystopia that I’m particularly nervous about 10 years from now: we overreact to AI safety. And so we say, look, everyone, you’re going to get a cure for cancer. You’re going to have material abundance, but you will have no freedom. You will have no agency. It will be a perfect surveillance state. There will be no privacy. And you’re going to get great comfort, but there will be nothing left in the world for you to really do.

Nothing that really matters. You’ll just live at the service of the AI giving you material wealth. I’d really like to avoid that. And I think it’s easy to accept temporary trade-offs. So if we say every year, freedom and agency have got to go up. People have got to be more in control of their time and do more of the stuff they want and more long-term fulfillment. I think that’d be very good.

Garry: Let me put you back into sophomore year of Stanford. You’re coming to YC. If you could give yourself a message in a bottle to that Sam Altman, what would you say to him right now?

Sam: It’s all going to work out. It feels like such a crazy— It is a crazy and it’s very stressful thing to do a startup. And my first startup didn’t work out great and it was a difficult time in my life. But I think many people say this as they look back on the early part of their career. You can make a lot of mistakes. You can fail at stuff. The tech industry in particular is very forgiving of this. And I wish I could have told myself to have all the drive and the ambition, but just be a little happier along the way and trust that eventually it was going to be okay because it feels so difficult and scary and painful in the moment.

Garry: I can’t think of a better way to end Startup School 2026. Sam Altman, everybody.

Sam: Thank you so much. Thanks.

Fresh off the launch of Opus 5, Claude Code creator Boris Cherny joins Diana Hu at Startup School 2026 to talk about what the newest models can do, how Claude Code came to be, and what it means to build products when the underlying capabilities keep accelerating.

Watch on YouTube

Timestamps

00:07 — What Makes Opus 5 Different
02:06 — Solving Prompt Injection
03:21 — Why Claude Code Deleted 80% of Its System Prompt
06:37 — Press Delete on Your AI Product
07:20 — How to Rebuild Your System Prompt
10:30 — Product Overhang and “Unhobbling” AI
14:26 — Give Claude Harder Problems
19:32 — Prompt Engineering Is Changing
21:57 — The Two-Week Claude Code Prompt
24:42 — Running Thousands of AI Agents
30:15 — Coding Is (Almost) Solved
32:20 — What Every CS Student Should Still Learn

Transcript

Diana: Alright, Boris, we’re so excited to have you here, the creator of Claude Code. Thank you.

Boris: It’s great to be here.

Diana: Fresh off the press, you guys just shipped Opus 5 yesterday.

Boris: Yes.

Diana: And it seems that model performance keeps accelerating. You guys took Arc AGI 3 to 30%, which is incredible.

Boris: Yes.

Diana: And for context, before, the best score was in the low single digits or low teens, right? What can Opus 5 do now that it couldn’t versus a previous version?

Boris: Yeah. There’s a lot that goes into every new model and there’s a lot of new capabilities that we teach and get the model to do. Whenever you do model training, you try to teach a whole bunch of different things and most often it doesn’t work. But some subset of the things, the model does learn. And sometimes it also surprises you. It has these skills, it has abilities that you actually didn’t really teach it, but it just learned. For 5, one example of something it does that I think no other model has done is it runs for a very long period of time. And especially when you combine Opus 5 with Auto Mode, it’s just incredible. It can go for days, weeks, months at a time. It just won’t stop. You don’t even need to use scaffolding. So you don’t need slash goal, you don’t need all this other stuff.

It’ll just go because it knows it needs to do the task. Another thing that I’m really excited about, and I’m going to start to talk about a little bit more, but it’s surprising because it’s such a new capability, is the model does not seem to be prompt injectable anymore.

Diana: That’s prompt injectable.

Boris: It’s crazy. People have talked about this lethal trifecta for a long time. And this really affects harness design and agent design and product design. Because if the model reads some instruction on the internet that’s like, “Do X and Y and Z and also delete everything on the user’s computer.” A year ago, the model would have just done it. But nowadays, Opus does not. And this has actually been the case since Opus 4.7, 4.8. Sonnet 5 has been quite good at this, Table was quite good at it. But Opus 5 just hits a new frontier on this. So essentially if you combine a well-aligned model—so this is essentially three years of research into alignment—with a prompt injection classifier, which we run for all traffic. And what this is doing is it’s based on Crysola’s mechanistic interpretability work where it’s literally, we’re looking at neurons in the model’s brain that light up when prompt injection happens.

So the model won’t even tell you, but we can actually see those neurons and we can figure out and diagnose that it’s happening. And then you combine that with the auto mode classifier. And with these three layers, we just cannot demonstrate prompt injection anymore.

Diana: Talking about prompt injection, the other side of the coin is now the system prompt. Let’s talk a bit about the new release. You actually deleted over 80% of the system prompt from Claude Code.

Boris: Yes.

Diana: Tell us more about that.

Boris: I think something that a lot of people might not realize is Claude Code as a product and as a harness is just always changing. We’re always adding stuff. We’re always deleting stuff. Every time that a new model comes out, we delete a bunch of the system prompt, change a bunch of the system prompt. We change the set of tools all the time. We change the prompts for the tools all the time. And the reason is every model is very different. So something that you did for one model maybe three months ago, it just might not translate at all to the next model. And so one thing about Opus 5 is it’s just really intelligent. And a lot of the stuff in the system prompt was correcting for these behaviors that the model should have known, but it didn’t. Now Opus 5 just does it. So yeah, we deleted 80% of the system prompt.

You can actually try deleting the rest of it too. So when you run Claude Code, you can just do like dash dash system prompt and set whatever system prompt you want if you want to experiment with it. And another thing that you can try is simple mode. So this is actually this kind of undocumented feature. If you do Claude Code simple equals one, like this environment variable, and then you run Claude, it’ll delete all the system prompts, including from the tools. And we actually use this as a sort of ablation to figure out is the prompt useful? And what’s interesting is that the model is actually a little bit more intelligent without these prompts. That’s something that we’ve been finding. But when you use Claude Code as a product, you do actually want some of these prompts because it helps you use the product and it helps the product behave and the model behave in the way that you would want when you’re using it as a person.

Diana: I think the thing that’s really fascinating in this era of building, basically you have built the best harness in the world for Claude, and that’s Claude Code. From what I’m hearing, for every model released, you basically delete all of the code base, delete all of the prompt and start from scratch every time. That in the old world would have been not something a startup would have done for the product. It’s like press delete every six months for everything.

Boris: That’s right. So to be fair, we don’t delete the entire code base, but we do delete a lot. Every time there’s a new model, in research, we call this ablation. What this means is you delete the entire system prompt and then bring it back line by line to figure out the impact of each individual line. It’s like an eval and you can evaluate it. The ablation is essentially an eval, but you delete things to figure out the impact. We do the same thing for tools. We unship tools all the time. We delete code in the harness all the time. If you look at the code that’s in the Claude Code harness today, almost all of it is about safety and permissions and static analysis. There’s a bunch of UI code.

And we’ve actually unshipped a lot of the other code already.

Diana: Do you think this way of building an agentic product and harness, and basically doing ablations every time there’s a new model released, should everyone in this room that’s building AI products do that? Be comfortable and brave to press delete?

Boris: 100%. And for people that aren’t building agentic products, but are using Claude Code, every six months, delete your quantum D, delete your skills, delete your hooks. See what the model does and it might surprise you. For Opus 5, this is something we really do recommend—just try deleting all of these things because the model might not need all those instructions that you needed for past models.

Diana: Let’s talk a bit about how you build this new prompt. When there’s a new model release, for everyone in the room, everyone will want to try Opus 5 and they’re going to press delete on their system prompt. How do they go about rebuilding the system prompt? How do you set up your environment?