Physical AI that Moves the World — Qasar Younis & Peter Ludwig, Applied Intuition
Latent Space: The AI Engineer PodcastEpisode Description
Summary
This episode features Qasar Younis and Peter Ludwig, co-founders of Applied Intuition, discussing their company's mission to build physical AI for various moving systems like cars, trucks, and mining equipment. They delve into the evolution of their technology stack, focusing on simulation, operating systems for safety-critical machines, and fundamental AI models, emphasizing the unique challenges of deploying intelligence in physical, safety-critical environments.
Chapters
Topics
People
Key Concepts (15)
References (29)
Transcript (110 segments)
Hey, everyone. Welcome to the Laid in Space podcast. This is Alastio, founder of Kernel Labs, I'm joined by Swiggs, editor of Laid in Space.
Kassar and Peter. Welcome. You guys really know how to turn it on to podcast mode.
That was that was you guys are real real pros at this. They were just joking around right before this, and then they flipped it pretty quick.
Oh, yeah. It's good to have you guys. Maybe you just wanna introduce yourself so people know the voice on the mic and then we can take look.
Yeah. I'm Peter Ludwig. I'm the co founder and CTO of Applied Intuition.
And my name is Kassar Yunus. I am the CEO and co founder with Peter. Nice.
Can you guys give the high level of a view of what Applied Intuition is? And I I was reading through some of the congress files when you went out there, Peter. And 18 of the top 20 global non Chinese automakers, you two guys, You have customers in agriculture, defense, construction.
I think most people have heard of Applied Intuition tied to YC when it was first started, and then you were kinda in stealth for a long time. So maybe just give people the high level overview of what it is today, then we'll dive into the different pieces. Yeah.
So Applied Intuition, our mission is to build physical AI for a safer, more prosperous world.
to construction and mining equipment, to defense technologies. And and we're a true technology company. So we we build and sell the technology, and we sell it to the companies that make the machines.
We we sell it to to the government, really anyone that wants to to buy a technology to make machines smart. Yeah.
the broader AI landscape, a lot of the focus rightfully so in the last three years has been on large language models and so everything that fits in a screen, you know, like, whether it's code complete products or or or things like that. And what's different about us is we're deploying intelligence onto a lot of things that don't have screens. You know, they're physical machines.
There are sometimes screens within the cabin or for for example, of a car or a truck or something like that. But most of the value we provide is putting intelligence that is in safety critical environments. So that the the those two words are really important because learned systems can make mistakes if you're asking for, like, you know, some, you know, something like, tell me about these podcast hosts that I'm I'm about to go meet.
But you can't do that, obviously, when you're you know, we run, like, as an example, we run driverless trucks in Japan right now, like, as we speak.
We can't have errors that those are l four trucks. Yeah. Yeah.
Was that always the mission? I remember initially, I think people put you and Scale AI very similarly for some things about being kinda like on the data infrastructure side of things. What was the evolution of the company?
that helped generally push forward the industrial sector. And so we started off working in autonomy. Our our very first customers were robotaxi companies.
And and we started off doing a lot of work in simulation and and data infrastructure. And then over the years, we've expanded our portfolios. Now we have over 30 products, and it's a pretty broad technology play within the the landscape of physical AI.
Yeah.
you know, and so but it was a very, very different company. You know, scale was is more of a services company, data labeling company fundamentally. We started and still are, you know, do a lot of tooling.
So, like, you think, you know, developer tooling is now in vogue again. Thanks to thanks to, you know, thanks to the AI boom. But honestly, ten years ago, it was out of vogue.
It it would like, doing a tooling company in twenty sixteen, twenty seventeen was not, like, the thing to do because I don't if you remember that the VCs generally, their views was that the toolings are they're they're just workflows, and workflows ultimately are not really interesting. And we've gone to come, you know, full full circle of that. But when we started the company, our our kind of you know, it's kinda like in the periphery of what the company wants to be.
It was like from our earliest days, like, wanna deploy software on physical machines, like on cars and on trucks and things like that. And, obviously, we didn't know that the transformer boom was gonna happen. We didn't know that autonomy systems would become end to end.
Those things we didn't know. And why that's important with autonomy systems begin end to end, it is just now you can those models can be generalized to, you know, multiple form factors. And so back nine, ten years ago, tooling was a great way and still is a great way to, you know, build the technology and sell technology to our end customers.
A lot of them who wanna build the stuff themselves. And so we just offer like a spectrum of solutions from you can just use like one part of of a development suite of tools all the way to buying the full thing. The way to think about the company or at least the way we think about the company is, as Peter said, a technology provider.
It's kinda like, you know, what NVIDIA does or what an AMD, but we just don't do chips. We don't do silicon. But we're a technology provider fundamentally.
And I think even, know, we used to joke when we started the company, like, you know, we're not the guys to build, like, Instagram. Like, that was just towards this is not our well, that's just not us in a more most fundamental way. I mean, I You have thoughts.
Yeah. Yeah. Well, it's it's I mean, I think it's just like what and and and, I mean, we worked on maps and stuff, Google Maps.
Consumer products are extremely difficult for a lot of different reasons. It just, I think, doesn't scratch the itch. I think we're like Michigan guys who are kind of more of in that traditional engineering kind of a realm or lineage.
What you said, Joe? I I gotta say that what what was clear ten years ago was that there was so much more that was possible with software and AI in vehicles, and that was generally the space that we started in ten years ago. Yeah.
And the precise path that we've taken over the years, I think we've been strategic, and we we've adjusted to to make sure that we're actually building stuff that's valuable to the market. And, like, the technology has changed so much. Like, our our own technology stack has has completely changed, I would say, roughly every two years.
And so now we've probably done, let's say, four complete evolutions of our own technology stack. And I sort of see that cadence roughly keeping up. Mhmm.
And and so the way we even we think about engineering is almost on this two year horizon, we're preparing ourselves that, hey, like, we wanna invest the appropriate amount, but then also be very dynamic as the research gets published and as our research team figures out new advancements and adapting to that. Yeah.
is the type of people we've frankly speaking. It's engineers who are fall into the, you know, sometimes very traditional, like, you know, Google, Gen Zui, but way different from, you know, other companies. We are hiring folks who really know the intersection of hardware and software, who know really low level systems.
Obviously, ML researchers and folks who've actually, you know, put ML systems into production. That's been pretty consistent.
of the company is engineering. So it's like a giant list. A lot of engineers.
Which, by the way, a thousand engineers Yeah. And these I mean, that's on your website, so I imagine it's out of date. Yeah.
It is it is up to date. Yes. Yes.
Okay. And then 40 plus founders.
Yeah. I know you would tend to also this was more luck than than strategy. We've recruited a lot of ex founders.
It's been a great place for founders, YC and non, because obviously, I know a lot the YC folks. It's kinda like we recruit a lot of Google people for it for them to exercise both their technical and nontechnical skills. Because, you know, we're we're we're on the applied side.
We have a research team that we do fundamental research, we publish, and we've we've had great traction there. But fundamentally, the business wants to take this intelligence and deploy it into production.
And and there's like a certain type of person that's more interested in that. Yeah. You mentioned the tech stack, Peter.
So I just wanted to give you some rein to just go into it. I'm interested in where Applied Nutrition starts and ends in some sense. What won't you do?
What do you do that's common among all the verticals that you cover? There's a few buckets of of work that we do, and and we've been at this for almost ten years now, so the technology is pretty broad. But we got started with a thousand engineers, like, could work on lots and lots of stuff.
Yeah. Especially with AI tools now. But Yeah.
So we got our start in in simulation and simulation tooling and infrastructure. And so, generally, if you're trying to build a very complex software system that involves moving machines, you need to test that. And the best way to test it is it's a combination of virtual developments, a simulation, and then also, obviously, real world testing.
Mhmm. And then there's a very careful process of that correlation between the simulation results and the real world results and ensuring that the simulator is in fact accurate to that. Simulation's a a very deep topic.
We have a whole whole suite of products in that, and we can talk for many, many hours about that specifically. But that that is one part of what we do as a company. Reinforcement learning as a subpart of that is also super critical.
I think a lot of the a lot of the best advancements happening in in a lot of these AI systems right now in some way relate to reinforcement learning. And with now, we have lots of compute, and you can do tons of interesting things in reinforcement learning. The second bucket of work that we do is operating systems technology.
True operating systems. Like, think about schedulers and memory management and middleware and message passing and highly reliable networking and data links. Like, the reality is if you want to deploy AI onto vehicles, you need a really good operating system.
And when when we were getting deeper into that space, there wasn't really anything that we were happy with. Like, things existed absolutely, and we were using what was available in the market. And as an engineering organization, we roughly realized these things aren't great.
We think we could do this better, and so let's let's build something. And that was then the that was the to the moment of inspiration that started our operating systems business, which is now a very real business for us. And in order to write and run great AI, you need a great operating system.
And so that that's what got us into that. And then the third bucket that we work on, it's it's true fundamental AI technology. Models, we do a lot of work in, as mentioned, the foundational research, but then the also the the world models and the actual autonomy models that are running on on these physical machines, as that's across cars, trucks, mining, construction, agriculture, and and defense.
And and so that's both land, air, and and sea.
And, also, a smaller subsector of that third bucket is the interaction of humans with those machines. So that's a multimodal experience. Historically, if you're moving a dirt mover or any of these machines, there are, like, you know, buttons you press, whether they're actual physical tactile buttons or or something like a touchscreen.
That's just that fundamentally is changing to where you're just talking to the machine and the machine, and you're teaming with the machine. Voice. Yeah.
Voice. Absolutely. Yeah.
And also the machine just being aware of who's in the cabin, what their state is. You can think from a safety systems perspective, the most simple version of this is like, the driver is tired. Right?
And they're they're you know, if you get those alerts when you're driving your car, it says maybe take a coffee break, that take that times, you know, a couple of order of magnitudes up. But this concept of teaming, man and machine, is important. When you think about running agents or just running, you know, different instances of, you know, Claude and doing work for you in the background, you can take that analogy out, almost copy and paste, and put it into like a farm.
We have a farmer who's running a number of machines. So where they interact with the machine is where there's maybe a critical decision or a disengagement or something. But generally speaking, the agent on the physical machine is running and making decisions on the behalf of the farmer until there's something maybe, you know, critical.
And that that that's also what we work on. So that's not pure autonomy. It's a little bit of a mix, but it falls under autonomy.
In the automotive sense, that's typically defined in SAE levels as an l two plus plus system. Mhmm. We have a human in the loop.
But just take that idea, you know, to to other verticals. Yeah. You've not mentioned hardware at all, like sensors or, you know, obviously, we you mentioned you don't do chips.
I think even in AV, there's like a big, you know, cameras versus LiDARs. Like, what what are like in your space, maybe some of those design decisions that you made?
driven by the OEM's ability to put things on the machinery? Like, how much influence do you guys have on codesigning those? Yeah.
So so we don't make sensors. Like, we're we're not a manufacturer. Obviously, we use a lot of sensors in our autonomy products.
In terms of what actually goes on the vehicles, we have a preferred set of sensors that that we, let's say, fully support. And then our customers, they can sort of choose from those. And obviously, if there's a a very strong opinion on supporting something else, we will add that to the platform as well.
And the the LiDAR question is, at this point, sort of the age old topic in in autonomy. And the the state of the industry right now is LiDAR is hands down a useful sensor specifically for data collection and the r and d phase of autonomy development. If you see, for example, a Tesla r and d vehicle, it actually has LiDAR on it Mhmm.
To this day. Right? In in the Bay Area, we see these you'll see, like, Model Ys or CyberCab that have have have LiDARs on them just driving around.
So it's it's useful because it gives you per pixel depth information. So if you compare a Lidar with a camera, and you can say, well, this camera's looking this direction. This Lidar's looking this direction.
And and now for each each pixel of the camera, I can see how far away is that pixel. You can actually then use that as a part of your model training, and then the that depth information then becomes a learned a learned state of the camera data. And then when you when you're doing the production system, you can now remove the LIDAR, and and now you can actually get depth with just the camera.
And so that that difference between, like, a highly censored r and d vehicle and then the down costed production vehicle, we use that across our whole portfolio of products. And, of course, the end goal is you want super low cost and super reliable. And and then in certain use cases, you have some more bespoke things.
Like in in defense, as an example, you do things at night oftentimes. And so you care about sensors like infrared more so than and you don't you don't wanna be putting energy out, so you don't wanna use LIDAR or radar, but you still need to be able to see at nighttime. So, yeah, we we work the whole gamut.
Cool. So that's kinda like on the hardware level.
Then on the OS level, how does that look like? What is like unique? I mean, my drive a Tesla.
Whenever I drive some other car that has a screen, it always sucks. It's on, like, cheap Android tablet. It's, like, it's laggy and all of that.
What does the OS of, like, the autonomy future look like?
it's really what you just described. When you think about operating system in a vehicle, you're thinking about the HMI. Right?
The human machine interface. And absolutely, that's an important part of it, but that's actually only one thin layer on top. So when we talk about operating systems for AI in vehicles, there's many, many layers that go deep into the safety critical realm and embedded systems, and you're talking about the the real time control of, let's say, the electric motors or the the engine and the actuators, and you have different redundancies for for different, let's say, the steering actuation in in the vehicle.
And all of these things need very core support in the in the operating system. And then, course, for autonomy, you have real time sensor data that's streaming in, and the latencies there are really important. Right?
If you try to imagine trying to run Microsoft Windows Right. Like, streaming your sensor data in controlling the vehicle. Like, the latencies are gonna be absurd.
Like, you can never do that. And so what's special about what we do is we really have this system level thinking. Right?
So we're looking at we care about every performance characteristics of the entire system, and then we also because we're doing a lot of the software or all of that software, we can fine tune and control all of those things. So we can very, very carefully tune in the latencies for every aspect of the system. We can carefully tune in the memory management.
We can have the right fail safes and fallbacks for for different things because you have to account for what if what if there is a critical failure? What if there's a cosmic ray that flip out a bit in the middle of the processor that causes some malfunction? And you have to have a fail safe to all of that.
And so the the core operating system is a part of that. And then the the one last thing, which is a lot less exciting, but is actually a very big topic, is reliability of updates. Right.
So the I have a Tesla, and you get updates fairly frequently, right, once a month. Most companies that are making vehicles Right. Are basically never doing updates.
And they're and even if they are doing updates, they're usually only updating maybe one module. Maybe they're updating the the HMI module, but they're not able to update, let's say, the the c two critical parts of the system. You have to go into the dealer for that.
And so with our operating system, now we can actually enable highly reliable updates of any system in the vehicle, and that's way easier said than done. Like, there there's lots of technical technically deep stuff in the tech stack to to do that in a way that you're not going to accidentally brick a vehicle. And right?
If imagine you're No repad. Yeah. Bricking a car is a very expensive yeah.
And honestly, like, across the industry, maybe one of the most just pure impactful things that we've done is we've just we're we're now enabling industry to actually do software updates.
Just to clarify also, well, who is the customer for this? Like, I assume a lot of hardware manufacturers have their own firmware and I'm sure some of them would just have you write it for them because you're experts, and others would have their own. Like, who pays for this?
Who who invites you into the the house? Is it is it the end user or is it is it the manufacturer? Yeah.
Yeah. So let me make an analogy firstly, on the on the fragmentation of software.
the state of the phone market before Android and iOS existed. Right? So I worked on Android at Google, by the way, many, many years ago.
And and part of the the reason that that Lariat Google decided to get into Android was they they wanted to run Google products on a bunch of phones. And they they bought all of these phones from the industry, and it turned out they had like 50 different operating systems on these phones. And it was virtually impossible for for Google to to make their app run on all 50 devices equally well.
And so the solution was, well, actually, what if what if they created a really great operating system and and made it attractive to all of these phone makers? And that was sort of the genesis for what Android was and and and why Android existed. It was a way for Google to get their products onto really wide diversity of devices.
The state of of the physical industry right now, it's a little bit like that. Like, there's yes. These companies have firmware, but they they have so many different operating systems.
It's so fragmented. And to actually get a modern AI application to run on these vehicles, you actually you first have to consolidate the operating system. And so that's that's why we've done that.
And then your specific question was who are our customers? It's it's generally, it's the companies that are making these machines. And, you know, we're we're we're selling our technology to them to really simplify the architecture and then enable these applications to run on them.
across?
is there some more customization that need that's needed? Yeah. Highly reusable.
So the the the fundamental technology is is quite universal. Right? So things that we do to think about though are like chipset support.
And so if you're if you're coding, let's say, an LLM and you have start with an assumption that, hey. Oh, I'm gonna I'm gonna use CUDA, I'm gonna run this on an NVIDIA chip, then you don't really have to think about the hardware in that sense. Like, you you're just okay.
I'm just I'm in the CUDA NVIDIA ecosystem, and I'm I'm going to to use that. But the the hardware, especially in safety critical systems, it it's a lot more diverse. There there's not one or one or two players.
There's a a bunch of different chipsets that we have to support. So And our operating system doesn't just run on, like, the equivalent of x 86. It has it has to run on a number of different architectures from chips from a a bunch of different companies.
But, again, we've been working on this for a long time now, so we have we have support for all of those those chipsets. And then when you want one of them run the AI applications, we can then do that reliably across now a variety of providers. And I think that is, like, heavily inspired by Android.
Right?
and I think it's a reliable operating system that runs on thousands of devices. And, you know, we think we can we can do the same in in all these physical moving machines where the difference that we're really in a safety critical realm, Android isn't.
So on Android, I don't need to use Gmail. I can use Superhuman. Like, what about your machinery?
Like, can people bring somebody else's automation to it, or is it kinda like all in one? You have to use us. No.
Yeah.
It's totally open. Yeah. Yeah.
philosophy is that we are a technology company, and so we we license our technology to customers to use how they want. And so if a customer wants to if they wanna license our autonomy tech and our operating system, then great. We'll license those.
If they just wanna license the operating system and then use different autonomy tech, that's fine also. And we have great documentation. Portion.
We wanna use developer tooling. Yeah. Exactly.
Yeah. It's like a better together if obviously, if you if they work together. Is it all c plus plus I assume?
Is it with different compile targets? We use a lot of c plus plus I mean, Rust is is sort of a hot the new hot kit on the block for our for a bunch of things as well. But, yeah, when when you the the lower level you get, especially when you when you get to real time constraints, you hit c plus plus at some point, and at some point, maybe you work your work your way into assembly when needed.
Oh, damn.
I'm curious about the
coding agent adoption just like since you're mentioning more esoteric languages. Like, what's the adoption internally? What have you learned?
Yeah. We we use everything. I mean, so Cursor was, I think, the the hottest tool in the company for a good while.
Now Claude Code, I think, has has taken the the rein on that. We have a internal leader leaderboard that we use just to sort of encourage adoption with within the company. And, yeah, they're phenomenally useful.
I mean, it's honestly, we we take inspiration from from some of those tools also in how we're adapting some of that mindset of thinking to the physical realm. Like, oh, it was it was so easy to to build an app for this or that thing that lives just on a screen, we can we we're taking out a lot of those same ideas and and applying that to, okay.
how easy can we make that using our own tooling and platform as well?
friendly? Or Yep. Absolutely.
The in the early days of our tools infrastructure work, it was a lot about you had engineers that were experts in certain topics, but the things that you're dealing with, they're oftentimes more mathematical or more abstract, where actually GUI tools are very, very useful for certain things. Like, as an example, we have a a product we call Sensor Studio, which is it helps you design the sensor suite for for your autonomous vehicle, whether, again, it could be a car, it could be a drone, it could be a mining mining equipment, could be a robot. And and you you place sensors in different places.
You there's different there's a library. You can understand what are the trade offs that you're making in in the design of that system. And that was, like, a very a very gooey intensive thing because it's little bit more like a CAD tool in that sense.
Yep. If you've seen CAD tools. Nowadays, though, right, we we expose all of the underlying APIs for that.
And and now using AI agents, you can actually configure a sensor suite with just text and and likely reach a better result than you could have through the GUI in the past. And we're taking that thinking now through the whole product portfolio.
adoption. Does that change your hiring at least a little bit, or how do you how do you sort of manage engineers differently?
Yeah. Absolutely, it does. We I think, like, every company in in the Valley right now are evolving our our hiring practices Yeah.
Because the the skills required to be effective are changing so fast. Right? I mean, you you used to really select for just rote implementation ability, and and now it it is more the AI engineer skill set, right, where it's like, yeah, you know how to implement, but actually just banging out code is is no longer the core job.
Right? It's it's actually knowing what questions to ask, knowing how to tie how to tie together these different AI tools. And so the the interviews that we give now, I think, are way harder than they've ever been, but but we also allow, right, selective use of AI tools to solve the problems.
And I think in that, you you start to see more of a bimodal distribution of engineers. Right? You you start to see like, wow, there's there's this subset of of people that they they really get it.
Like, they're they're all in, and they've they've clearly invested the the hours needed to learn these tools and and how to be effective. Mhmm.
gap is just enormous. And so we're we're trying to obviously select for the people that are are really really into this. I first wrote the my AI engineer piece three years ago.
And when I first wrote about it, I was like, actually, not everyone should be an AI engineer. Because I think there's a there's an extremist stance where, well, every software is an AI engineer is an AI engineer. And my actual example of people who should not be adopting AI was embedded systems and operating systems and database people.
Are they adopting AI?
I think it's the classic bitter lesson topic, which is the six months ago, I would have said the same thing, but it's it's becoming super useful for every domain. I'm sure. Right?
Like, was I think six months ago or maybe maybe a year ago, if you tried to use, let's say, the latest Claude model for writing shaders, GPU shaders, the results were probably underwhelming. And if you use the latest model now to do that kind of task, you're a little bit blown away. Like, wow.
That actually worked. That's amazing. And we see the same thing in in the embedded realm.
The no question, though, especially when you get into safety critical systems, the the human validation is is a 100% key. Like, I I you're not gonna trust your life to, like, AI written software that's that's not been very carefully checked by humans.
really, the challenge is about that appropriate level of of human validation for for these safety critical systems. How do you think about yeah. Touching on the simulation side, I think verifiable reward and reinforcement learning is, like, the hottest thing.
What have you done internally to build around that? And like, what what gives you what makes you sleep at night? Like, if somebody is like, you know, just vibe coding something or like wants to try something new, you have like a good enough system.
Because I think the opposite is also true. It's like, if it's super easy to write anything Mhmm. Then it puts a lot of work on like the verifiable side of it.
Like, what does that look like for people? Yeah.
a broader bucket of like evaluations. Right? Like, how do you evaluate the the results that you're you're getting?
I think this this is probably the hardest problem right now because the as the models get better, it can be harder harder to find the faults on the system. And so, like, the the problem of doing proper eval to find those faults, like, that problem also keeps getting harder as and as the models get better. But it's no less important than it's ever been.
Right? If you you still there there are still going to be edge cases that are not met and and whatnot. And so it's it's a big area of of investment for us.
The on the reinforcement learning topic, I mean, the the key thing is there's all of these new requirements that that come to be in in the latest generation of these technologies. So for example, end to end is the big thing right now in in autonomy and physical AI, which is you can now train these models that can effectively take sensor data in and then put control signals out and get really good results out of that. But the way that you train and improve those models is really different from from the previous generations.
And so to do reinforcement learning on an end to end model, you now need to actually simulate all the sensor data. Right? So then this becomes we we call our our work in this neural simulation, but it's think of it like a hybrid of Gaussian splatting and and diffusion methods and where you really care about performance.
Like, performance is is everything. If you can't do enough simulation fast enough and cheap enough, you actually can't get results that are are worthwhile in the end. It also gets gets to a lot of our work in embedded systems, which is, like, performance critical work, and that that performance optimization, performance criticality, it carries over to a lot of the the the model training work because, like, the only way to make it affordable is it has to be really fast.
evolving thoughts on verification and validation within kind of traditional simulators, which are, you know, you can think of, like, vehicle dynamics or something like that, which is taking textbooks and taking those formulas and putting them into software to, like, now this neural sim slash world model universe. I think that's an interesting topic. Yeah.
Yeah.
in more traditional development, right, you you oftentimes would have more black and white answers to questions. Mhmm. And so the in in Europe, an example, there's a regulatory system.
It's called Euro NCAP. It's the European New Car Assessment Program. And as part of that, the vehicles have to pass a bunch of tests.
And those those tests actually include safety systems. So automatic emergency braking for a child that runs in front of a car or let's say an occluded child that runs out and and you hit it. And and so you have you end up with sort of these binary answers of like, well, did did the car under test pass this specific test?
And there's a very, very well known set of of test cases that the vehicle has to pass. And that was how the industry worked, let's say, until ten ish years ago. But what's changed now is with these models, everything is statistics.
Right? You no longer have a black and white answer, but it's like, well, how many orders of hangitude or how many nines of reliability can I get in the system, and how can I prove that to be true? And and and the big unlock, honestly, for physical AI as as an industry is that these models are just becoming much more reliable.
Right? Things like things actually work a lot better. It's like the number of nines you can get out of these systems are are now good enough that it actually becomes cost effective to to really deploy these things.
And so the the big shift in in so verification and validation has been from a little bit more of a again, in the past, it was strictly requirements and are you meeting or not? And and now it's more of a statistical verification and validation case where it's all about how many nines are reliability and and mean time between failures, that sort of thing.
or even the customers are could be yeah. I feel I imagine the customers are bought in and it's mostly regulators that need to be satisfied.
We do work with the US government. We do work, of course, with the European governments and and the government of Japan. And the government is not, like, an AI lab by any means.
So They just care about the outcome. They care about the outcome. And and so we we do education in in that regard and, like, sort of teaching about, hey.
This is how we think validation should be done, and this is an approach that that we think is is reasonable and how to think about, like, when is a a driverless system actually safe enough to to to go on the roads and that that sort of thing. But I wouldn't say that the government is asking for it. It's like we're more teaching the government in that in that sense.
It's honestly, it's more so for our own our own comfort. Right? Like, we want to build very safe systems.
And then of course, our customers care deeply about that as well. But in that context, we're also typically educating our customers. Yeah.
Yeah.
our first core value is on around safety. So I think we can't underline enough that us also verifying and validating that the systems that we're deploying are safe to to us is probably as important as, like, some regulator or a customer saying, you know Of course. Okay.
Yeah. You have to set it by yourselves. Yeah.
As I say, as as a whole, across the world, regulation oftentimes, it's like a almost lowest common denominator, but, like, you really have to substantially exceed what the regulators are expecting to make good products.
One thing I often talk talk about, I think, and I try to make this relatable to the audience also is Cruise, where they had an accident that basically ended the company. I wonder if people overreact to single incidents because incidents are going to happen regardless. Right?
Because it's a statistical thing.
I mean, a consumer driving. Yeah. Think the the the cruise example wasn't a technology failure.
There was the the real compounding issue there was just how did the company talk to the regulators and and what was their kind of behavior? And I think that became more of the issue. If you look, you know It is an it definitely was technology failure, but it was made much worse by a little bit.
Yeah. Yeah. Yeah.
And let let me put it another way. There is a version where crew still exists. Right.
Right. Right. Was like the last straw.
It's like a long chain of Yeah. Like, so she was Like, ATG had that horrific accident or someone actually dying because, you know, that was a homeless person crossing the street. So, yeah, I think I think we can't understate enough that ultimately, like, statistical validation of something, that's one part of it, but it's not the only part of it.
Like, consumer and, let's say, mainstream adoption of these technologies is also gonna be part of that conversation. I think companies like Waymo are doing a lot of, you know, service positively to the industry in the sense of they're they're setting a high benchmark and they're showing, you know, kind of in a very responsible way how to how to deal with these. There have been Waymo incidences as well.
They've just not been as significant as as the cruise one that you mentioned. But, yeah. So I think I think you'll just continue to see that.
I think for probably the long term question is really gonna be, again, around, like, it is very clear humans are way worse drivers statistically. Yeah. Like, there's there's no there's no debate.
animals? Yeah. So my thing is, like, we have to get to a point as a society where we accept horrific accidents that would never happen by a human because statistically, we understand that it is safer overall.
they're safer than I think they're the safest motor transport that we have. Yeah. I mean, it's more dangerous to drive to the airport than it is to get a flight.
So So if you're ever Yeah. If you're ever getting nervous about getting on a plane, just think I just gotta get to airport.
I get to the airport, it'll be good. But then planes planes also concentrate a tail risk if if planes just yeah. I was I I I don't think we honestly have to worry about there ever being accidents from these systems that are much, like, much worse than what humans would cause, because humans do do terrible things.
People fall asleep at the wheel all the time. I have. I've been a drowsy driver.
Kinda like drunk drivers, and that's that's the extreme end of the example. But, I mean, these AI systems, you have redundancies, you have fallbacks.
fallbacks that these systems have. Yeah. I mean, your simulation is, like, so vast because there's so many use cases.
What are, like, maybe things that worked in a simulation, then you put it out and it's like, fuck. This just this just did not work at all. Yes.
maybe a bit of a misconception about simulation there. So let let me go a little bit more more technical on this. So at first go, no simulation is is going to represent the real world.
There's always a process of this sim to real matching where you actually you need the real world feedback to basically feed into the parameters that are being used in the simulator, and you have to do that it's like this validation flow a number of times until you can get some confidence that, oh, I I think the simulator is now accurately representing what's gonna happen in the real world. Now if if you have a situation where you've done that full validation and and you thought that it was accurate and then there's something different, those are much trickier cases. And that that's that absolutely can happen.
But, really, I think the validation process is a really important part. You can never skip the simulation validation process, like, where you're actually ensuring that, hey. Actually, my Syntreal gap here is is small enough that I can trust these these simulation results.
And and there's there's so many fun things that you can do when you get into it. Like, I'll give one one fun example that came up recently is, like, in these these humanoid robotics systems, overheating actuators is a real problem. Right?
So, obviously, phenomenal demos. I had Right. The most amazing most amazing I can get.
I I love I love watching robots do acrobatics, like everybody. But the the systems actually overheat. Right?
If if like and one of ways you can use simulation, though, is you can actually have that the temperature of those actuators be one of the parameters that's represented in the simulation. And and if you're doing reinforcement learning over a certain task, then the robot can actually adjust its motions in the simulation to account for the fact that, oh, it knows that as it's moving, it's actually beginning to overheat this this motor. But if you didn't have that parameter of, let's say, the heat of that motor represented in the simulation initially, then your RL policy might it will disregard that.
And now you run that on the robot, and the robot will overheat and and fail.
how do you have all of these parameters taken care of while also understanding the deployment? And bar like, temperature is, like, a great example. Right?
Well, why did you make my robot worse when it runs in, like, a freezer so it actually shouldn't worry about that? You know? It's like, yeah.
How do you design these simulations?
This is honestly the the this is what makes simulation so hard. Right? It's because you simulation is is fundamentally about you're trying to optimize the development of a system.
Right? How can I build a system faster and better and cheaper? And and what are all the levers that I have to actually accomplish that?
And and because simulation's just a software program, you can you can change it a lot more easily than you can hardware systems. And then what's particularly awesome about the, let's say, world models and using that as a part of simulation is now the simulation doesn't just scale with, let's say, adding new math equations in, but we can actually scale the simulation environment now with with additional real world data. And and that that also unlocks a, I would say, a whole new field of robotics.
There is a meniscus line where you cross where still doing real world testing is better. There there's a in this central real gap, you can reproduce reality at exceedingly expensive costs. And this nothing is free.
So really, you yet you're finding that line where you're getting great performance, you're getting great feedback, whether it's on the training side or on the eval side, but it's way cheaper than doing in in the real world. At some point, it it that doesn't make sense. And so even, you know, from our earliest days in autonomy, our view was you're still going to do real world testing.
There's not this, you know, magical land where you're not going to do that. And maybe even like a more nuanced version of this in like traditional software development is, you know, most of your testing for software in a vehicle, 95% of that can be like traditional CICD kind of flows that you'd have in traditional web development. But once you have now, let's say you have a truck, Then you can do like 4% of those in like a rig, which has all the components, the electrical electronics of a truck, but doesn't have it doesn't have the the tires and it doesn't have the and then you have the 1%, which is actually the vehicle.
There's something sim there there's a similar analogy in terms of using simulation for intelligence systems. You do a lot in a simulator, but and and using world models, but ultimately, it's it's physical AI.
So you're gonna deploy it on physical machines and the freezer example comes to comes to light. The world model thing has been to me the hardest thing to wrap my head around. Like, we have Faith Hilli on on the podcast.
We've been doing a small series of like another intuition company, GenoIntuition as well. Yeah. And I mean, lots of lots of coverage on nerfs and Yes.
It it feels like like we talk about about the heliocentric system. Right? It's like in a world model, if you just feed visual data, the model might learn that the sun spins around the earth.
It makes sense. Right? And it's like, well, not really.
And I think what are like some of these other things that like like hydroplaning is one thing I think about. It's like, can a world model understand hydroplaning and like what amount of water, like, causes it to happen? And it's like, yeah.
To me, it's like, I don't understand how you guys do it. I guess it's like the the real thing is like when you're doing both cars and the highway in Japan versus the, you know, excavator in a mine in Air wherever you're Arizona, wherever you're deploying them. Yeah.
How much of it are you relying on the world models to, generate the simulations for you and then try and close the gap after versus, like, giving the world models as a tool to your engineers to, like, curate the simulations, if if that makes sense? Yeah. Totally.
I can say at a pure engineering level, I think if if you're hoping to do real world deploys and you're purely relying on a world model approach, you probably won't get to something that works before you go bankrupt. So there there is just a very practical mindset of, like, world models are are amazing, and they're extremely useful for a lot of use cases. But there are a lot of other things that you need to do to actually get something started and something deployed and working.
Most fundamentally, role models are all about it's understanding the world, but also understanding what's going to happen. It's like the cause effect relationship. Right?
And so, like, it right? If you have a take some sort of construction tool, and that construction tool is gonna be doing some work on the earth in in some way. It's gonna be move moving earth.
The world model needs to understand that cause effect relationship. Like, okay. When I take this material over from here and put it over there, and now I have things that are over here and not over there anymore, and that cause effect relationship.
Data obviously is a big problem. The hydroplaning one is actually a really great example because it's actually quite non obvious sometimes. Right?
It's like, well, it's it's raining, and and, well, this this road has, let's say, the the appropriate curvature into it so that the water is running off the road, and cars are driving faster here. And then you approach a road that's very flat, and water is now puddling on that road, and all of a sudden, cars are driving slower because when they're driving faster, they were starting to to lose control. And there are a lot of visual very nuanced visual cues in the scene.
these kinds of models where they just they learn these non obvious things. It doesn't need to know about hydroplaning to know that it needs to drive slower. I guess it's yeah.
Yeah.
also the deploying models. Presume, like, you you use a lot of these world models for training data and simulation, but what about deploying it onto the systems in in production? Presumably, you have you have like GPUs on device, but they're I keep saying on device.
What's the what's the right term for the On the machine. Or embedded. Yeah.
Yeah. Yeah. What what is the embedded world like?
Because for for for people who are not used to that world, this is very alien.
Yeah. Yeah. So it's actually we we call it onboard and offboard.
It's like onboard software and offboard software. And the the great thing about offboard software is you don't have to care about time and you can run really large models. Right?
So you can can say, well, this this model, I don't care if it takes one second for it to give me a result or ten seconds for it to give me a result because we have time. And the models can be really big, and they can run-in data center or on a on a huge GPU, and and you can obviously have distributed compute, etcetera. But onboard, you don't have have any of those benefits.
So like, well, I need I have this many milliseconds where I need an answer from this model. And so a lot more of the energy then is about think of it more like distillation, and and it's, like, truly efficiency. And, like, literally every every fraction of a millisecond counts.
And and and you you you can't have a situation where the model takes too long because then the vehicle can't actually function. Yeah. And so you can you can still use a lot of the same techniques.
And and the models themselves, can think of as like a derivative of of larger models that you can run offline. And then you're you're trying to just get a model that is still performs really well, but it's it's a it's smaller smaller version that you can then run on this embedded system where you care about latency and power. Yeah.
Yeah.
maybe is not obvious, but it's worth saying is, in physical AI world, we're not really constrained right now by, like, intelligence of the models. It's actually what Peter's talking about. It's actually deploying them in The hardware they give you.
Yeah. On the hardware they give you. And and so and there's just a reality is of safety critical systems.
So those end up being the other your your limiting factors rather than, let's say, a limiting factor for, you know, a foundation model company is gonna be just capital they pay, you know, or or or researchers. Yeah. So we're we're in that way dealing with, you know, for us as people who kind of come in that realm of like a very interesting those constraints force creativity.
And I imagine, you know, nobody was deploying or giving you the hardware for transformers back in 2018, whatever, but now they are. What's the evolution like?
Peel back the currents a little bit. Yeah. Transformers first off.
Think the paper was originally published in 2017.
There's no time. And I I But I'm just saying I guess I'm saying, like, you know, embedded ML systems usually, like, a lot less parameters, a lot less compute, and now, like, orders of magnitude more. Yeah.
Yeah. Absolutely.
What I was gonna say though was I think in the in the original paper in 2017, maybe it's in the last paragraph, somewhere in the paper, they talk about, like, oh, by the way, this this technique might might be useful for, like, images and videos as well. Yeah. It's a lattice.
Perfect. Yeah. And it took a few years for that impact to really hit.
But, like, now, I mean, we're seeing transformers are everywhere. Yeah. There's just transformers.
Yeah. Cool. And the yeah.
And then the compute just keeps getting better and better. But you do have this fundamental trade off, right? It's like you have power, you have cost, and and performance, and and, like, getting the right getting the right mix of those things in an embedded package that can also be, like, shaken and and baked and all of the conditions that these things have to have to operate in.
But, yeah, I think that they're only going to keep getting better.
understanding that we know the rate of improvements of these systems. Yeah. So it's like Google just released the Gemma two b model, like the effective two b model.
Is that useful to you guys, or is that too big? You can run that model on an embedded system, definitely. Yeah.
The so so, yes, it's it's useful in in that regard. The bigger question is, like, what do you use it for in an embedded system? Like, you actually need to customize it quite a bit to make it useful for for something.
But but, yeah, you you could run a 2,000,000,000 parameter model, definitely.
Yeah. Which probably is not that useful actually for your context.
Like You can imagine different use cases. Right? So the The voice stuff.
Yes. The voice stuff. Totally.
So for the the actual autonomy elements, I mean, that's 100% in house. We do every bit of that, the the data simulation, the model, everything. But when you get into the more generic use cases like voice or voice assistant kind of thing, that's where these these more generalist models like GEMMA actually can be quite be quite useful.
Yeah.
versus just call home. Yeah. It's all about latency.
It's all about latency. Yeah. Yeah.
Well, like, know, I think actually in a lot of context, especially in The US, you can just have a connection to to the web.
Yeah. I think I think though most of our universe is everything has to be fairly, you know, embedded and local because just the nature of even in The US, there's a lot of, like, Yeah. Lines that don't have have coverage.
Right? And if you look at, like, the old world of autonomy within mining, which is, like, long before transformers and and and kind of neural networks in the like CNN and a kind of a universe. They were really just hand coded, you know, systems.
They were just like, this machine is gonna run to that place with this. That was an RTK. He's like, accurate GPS.
Yeah. So that worked, and that worked for twenty years. So why would we actually need to use transformers or kind of more modern end to end systems?
Mainly because you can only really run a path and run backwards. That provided a lot of value, but not as much as you get when the machine is actually intelligent. It's it's seeing, it's perceiving, it's acting in a dynamic world.
Mhmm.
one to two centimeter accuracy. Yeah. Yep.
Fantastic.
But the you know, and and fantastic in faraway lands where there's not gonna be cell phone coverage. Yeah. So I think it's widely used on the legacy mining and agricultural autonomy systems today.
So, like, for example, a combine that can be precise within one or two centimeters as it's driving down the the field, they use RTK.
Yes. It's expensive. Yeah.
And it's it's it's autonomy, but it's not intelligent in the way that I think all of us, if in 2026, we'd be talking about intelligence.
that are similar to those doing modern generative AI. What are, like, the big differences other than, you're absolutely right. I should steer the car.
So I don't you probably wanna remove that.
We have a diversified bet strategy internally. And and the reason we we've done that is because we operate in now a bunch of industries, a bunch of geographies, and and each of the approaches has honestly a different risk to them. And so, like, we're not going to put all of our eggs in in a single in a single basket for a a single approach because that approach may not work out.
Mhmm. And so that's that's one of the bets that we have, and it has certain advantages in in certain scenarios. And then but the way that these things play out in practice is that it's certain benefits that also has certain drawbacks.
And and then and then the research team tries to then work on the the situations where that's actually worse than than these other approaches and to ultimately arrive at at a really great solution for all these things. Is there a plan mode for physical autonomy? Like, do have a planning step and then action step?
Or So short answer is yes. Right? So just like you can use Claude code to to plan out some complex coding task and and you get some almost specification written out, those similar similar approaches absolutely can be applied to physical systems because imagine you're trying to accomplish some task.
you actually do have to think about many steps in advance. Mhmm. It's it's not just this one thing, but to accomplish the goal, there's a 100 steps.
And then the this concept of plan mode, it's, yeah, very applicable in this. Yeah. I I was gonna say, to me, driving feels like a great next token prediction thing because you're kinda like on a path and, like, it doesn't really matter what you've done before.
You know, you can always turn around. Blending. Yeah.
Yeah. Versus like mining, it's like, oh, man, I took a, you know, I took a scoop out of this thing. It's like, now we can't really, you know, I can't really go there anymore.
You know, it's like, is there like a huge difference? Like, I I would you I guess, like, do you have like a taxonomy of like these different types that are just kinda like driving, excavating, like, flying?
How how So the interesting thing is, I think probably everything in the world can actually be boiled down to, a next token prediction problem. And in any workflow, anything can be thought of almost as like there's this the sequence of steps or the sequence of trajectories or whatever you wanna call it, and it can be boiled down actually to to that sort of thing. And in the mining case, you can imagine, like, taking that scoop.
Okay. That was that set of of tokens. And and now that's the model is now understanding that, okay, that the state space is different, and and now the next time I do token predictions, it's going to going to be modified by that.
But, yeah, these but the remarkable thing about these techniques is just how how universally applicable they are. Right? I mean, it's it's truly is incredible.
What else is underrated about what you guys are building on the physical side? I think there I mean, we were talking about it before the episode. There's a lot of humanoid companies that do these great demos, and then I can buy it.
So obviously, it can all be there. In your case, you're like in production on real streets with like a lot of customers. What what I like to think people are underestimating, the same way the Waymo demos seven years ago were great and then took seven years to actually get them on the street.
Can you share about maybe, like, the last 1% that was really hard to to get done technically? Yeah. So certainly, productionizing stuff is really challenging no matter what.
So I I maybe would I would split the answer maybe into research and then also in into production.
First, on the production side, there's just so many problems that you find when you actually get the stuff to to go in the real world. And so and the classic problem in in humanoids right now is these systems are actually pretty brittle. Mhmm.
And so I'm not talking about any one company, but just as an industry, these systems are are pretty brittle. And interestingly, I saw this thing the other day that I think China is doing a a marathon with humanoids. Uh-huh.
Right? Yeah. Yeah.
So so in in government, and not China specifically, in any government, there is a there's a concept called prize policy, which is so that there's there's different ways of of influencing an industry to go certain direction. Like, you can you can regulate it. Right?
You can do mandates, or you can actually just do these competitions. So The US version of this was the DARPA grand challenge. That worked.
Well, it really worked. It really worked. Industry.
But I think China is literally doing this marathon because they know that reliability of of humanoids is a problem. And so what cooler way to solve that than to have a competition where humanoids need to run 26 miles. Right?
Are we there? Can can can robots run a marathon? I think it's happening any day now.
Yeah. So it's So we're there. By the way, also, you know, automotive, there's a version of this, which is like twenty four hours a lament.
Right? It's like Porsche wins twenty four hours a lament. Literally puts those, you know, products into production.
I would actually break it down. You you talk about research and you talk about production. There's actually a step in the middle, which is, like, advanced engineering.
And I think a lot of the industry is moving into advanced engineering where it's like, it's not fundamental research. Like, we're coming with novel techniques. It really is advanced engineering for production.
So what are the the subcomponents that are gonna limit to getting into production? Once you're in production, you're dealing with another set of problems, which is, like, the deployment maintenance, of those machines that that that exist. So I would say, at least in our field, we're mostly in advanced engineering in the, like, automotive pilots.
Honestly, every every step is hard though.
Paul, this way, you're worth $15,000,000,000.
So go ahead. You you bleed every step.
Yeah. I think fun. I mean, think I mean, it's like, I don't know.
I I find it really enjoyable. Yeah. But what it was also fun is I so we've we've been doing this now for almost ten years and, like, we we've just seen we've seen so much bad time.
And so right now, we we can look at any company in the space and, like, get a demo, and, I can I can write down a list of I know exactly the next 20 problems they're gonna hit? Yeah. And, like, I I can guess also what they're going to try to solve each of those, and I can guess which one's gonna actually work.
Yeah. It's not because we're, like, particularly, like, geniuses. We've seen this stuff.
Yeah. We've seen enough of this stuff. We lived a little enough of this stuff.
we've tried so many things in the many we're talking about the wins here. Like Right. There are plenty losses among that many people doing that many different things.
And and so that kinda like get baked into your, like Yeah. Mental model of the world. Yeah.
But I would say, in general, like, we're excited about robotics for sure.
Massive opportunity. Massive opportunity. And what's happening now in the industry is like, none of these concepts are new, right?
What's new is like, this stuff is actually working now. Yeah. Right?
People have wanted to use neural nets for robotics for a long time, but but now, like and we now have the datasets. We have the simulation technologies where stuff is actually starting to really work. And, yeah, we we wanna be part people we're gonna be part of that for sure.
Do you have requests for startups or, like, advice against starting certain startups?
new companies. It's like, what what do you think are things A lot of a lot of applied intuitions for other things. I think you you hit a you hit a certain, what is it, you know, badge when y x for y.
X for Right. You become like a, you know or or literally the same similar names, like, you know. I I mean, I think my biggest advice, you know, in this like, almost like commercialization of technology is I think often the that constraint.
So we talked about like hardware constraints, we talked about there's also, like, on the commercial side, there's constraints, which is we're gonna only do things that fit in this box. That is, I think, very good for founders. The reason I think it's not often focused on is because you have plenty of access to capital, and the technical problems are so hard.
You're like, I already have a constraint, which is just getting this, Nina, this technical problem solved. And I think the venture community, generally speaking, tends to be not very technical. For them, if you just say, if we solve this thing, it's gonna be a lot of money.
That's kind of enough for them. But you as a founder, I'm not giving you advice on how to pitch VCs. That'll work for VCs.
You still gotta run a sustainable business. Then I think we're really in in in that question you asked earlier about kind of, you know, what's maybe not obvious about our company. It's like, this is truly compounding technology.
A lot of the work that we do just compounds it. We don't throw it away. It gets better.
The operating system work gets better. The dev dev tooling gets better. The models get better.
And so we're really gonna get a I I think you see it in Waymo as an example. Like, Waymo is a company that is, I would say, very interesting for a long time, but not worth a $126,000,000,000. Right?
So what happens, like, is that the human brain just doesn't emotionally understand the compounding effects. So that's gonna happen in our universe. So now if you're a founder, you're at the beginning of that, you know, that long, you know, walk.
If you can put a little constraint on on commercials that has a small ability for you to more likely see the other end of that that walk. Because you can get the other end, you will get the big return from compounding technology. Just a lot of people just don't make it.
So yeah. So summarize, like, think a little bit about the equation of how you use money and where you use the limited resources and limited engineers that you have. I think sometimes founders falsely kind of take very mature companies' strategies and then apply it to their, like, nascent.
They're like, oh, well, Steve Jobs says be complete vertical. Well, yeah, in 2007, Apple is very different than 1978 and 1982. Those companies were different.
They they were literally just taking electronics from other manufacturers and putting it in a closure. And so I'd just be a bit more, like, I don't know, a bit a bit more nuanced in your in your commercial approach as it informs your technical approach.
Do you feel differently today? Like, I mean, you just joined X. Right?
You've been building this company. Yeah. Yeah.
Yeah. You've been building this company in stealth and now you're like, well, I should probably be talking about what I'm doing. I think a lot of founders are in a similar way where they wanna raise a lot of money to signal they're strong and you raise a lot of money without spending Into hire.
Into hire. Yeah. You obviously like that.
Do you think that's still possible to like have a very narrow approach of like, hey, we're kinda like building a compounding thing without a grand vision right away versus It's very difficult to answer very general questions.
That I I so maybe, like, maybe I reframe it as in, is it possible to build a product that has a small, let's say, problem space and hope that the problem space will grow? Maybe like a different way of asking the same question, but more answerable. I think always yes.
That is the old y c, like, really deep and then, you know, rather than very broad and shallow. Very broad and shallow, unfortunately, there's just too many tech especially in hard tech companies, there's just too many problems, and you can't you're gonna do all of them in a very mediocre way. And so this the the the the the full product is actually fairly mediocre.
So, yeah, I I I I still in I'm still in the camp of find a small problem space. The other question you're asking is tangential is, like, should you, like, build in in stealth and anonymity? Well, yeah, if you're a YCCOO.
Yeah. I mean, you can because Oh, Travis. Yeah.
We work we work, you know, together at Google. We have a long history, and we don't then which mean which is another way of saying we have big networks. I mean, our first of 400 people, majority were Googlers.
Like, a majority of the company came from, you know, this giant company we worked at, and that's just very different. You're a founder who is doesn't have that experience. You have to do these things.
And I think it's co that's co so it's like, just don't take my version of the world or whatever other founder, Jensen's version of the world. They are different time and space, and most importantly, their companies are in a different phase. Yep.
And so then if you wanna take inspiration from other really young companies, that's also bad because most of are gonna fail. Right. So the only the only solution you really have is use first principle thinking, and say, based on my skills, my co founder skills, the skills of my early team members, and what I'm hearing from customers, what's the product space that I should I should build in you.
Yeah. Does it make sense? Yeah.
Yeah. I I mean, Sam, Sam Allman, he said he regressed a lot of the advice that he's given at YT. So I'm always curious to ask, you know, founders like you who have not been.
Just so why is that? If you learn who the YT, like, does the opposite.
know, we you know, well, Sam was president. Was COO. Yeah.
Yeah. Right. So and we'd have a CEO.
So we work together, you know, extremely closely would be an understatement because the firm was also small. But, know, YC wasn't that it wasn't as big as, like, an OpenAI is. I I directionally agree with that, but I would say that's not more of a YC function.
It's more of the market It is a different world. The AI industry is different is the the AI companies, I should say more specifically, and how they relate to the other y c companies and market just so fundamentally different. The amount of money raised is different.
The amount of investors, the sheer number of seed funds. One of our early investors is Floodgate, and they did some analysis in the late two thousand, like double o's, where they were like there's, like, single digit number of funds that were like floodgate, which were like writing sub $1,000,000 checks, first checks, and they were not accelerating incubator. Anne, who's who's one of cofounders there with with Mike, they they said that today they try to do or, like, today as in, like, three, four years ago, they they they tried to do this analysis and they like lost count at like 350 funds or something like that.
So we're just in a different environment. So the YC advice from 2014 just would not apply in 2026. But Sam is, like, way better at saying these things than me.
Like, he's not gonna make some money. He says it in the shorter, most more interesting, and than than me. I I can just give you, like, the like, already like, if you ask me, like, you know, what is the purpose of a car?
Like, open the owner's manual. I say, number one, look, there's a stair and wheel and, you know, instead of like, it can change your life and be there. Yeah.
It gets you autonomy and free. Yeah. Exactly.
Yeah. Yeah.
And then for Peter, I was just kinda curious if there's any particular tech or research problem that you would call out as very meaningful for you guys if it was solved and unsolved, and if anyone is working on it, they should get in touch with you. Yeah.
generally, the the making models very efficient. Right? So it because we have to run on actual vehicles.
Like, physical AI is literally it's taking, like, very large AI and now making it very small and very efficient. And and so we're constantly just at that boundary of these limitations of, like, well, you have a great model, but now we need to make it faster and smaller. And and so that that in general as a as a field.
And then I would say also folks that are just really passionate about evaluating this technology, as in, like, model evals is a it's a hugely difficult topic, especially in safety critical systems. And, I mean, we we have a, I think, a really great engineering team that works on this now and and and researchers, but it's it's a big area of investment. And so, yeah, folks that are passionate about, yeah, performance.
I I say model performance, both in terms of capability and and literally latency, and then and then evaluation of models. Awesome. Yes.
specific engineering roles that you're hiring for? And especially, like, who are people that succeed at your company as engineers? I think that's always the most important thing.
Yeah. I mean, fly.
I think there's there's literally hundreds of roles. We're looking at all the topics we talked about from, you know, dev tooling and physical AI to operating systems to autonomy and and and and within physical machines. The types of engineers that's a great question.
That's actually more interesting than than the roles because we're, you know, we're large company where We ring everything. Yeah. Ring everything.
Yeah. I think, you know, we're a Sunnyvale company. And I think just from this conversation and kind of our backgrounds, you can kind of predict a little bit of what that means.
You know, we tend to hire fairly serious people who are who understand low level systems, not just just like a a superficial understanding of technology. Like engineers engineers almost. We definitely hire folks who are like, have some diverse skill sets.
We hire tons of specialists as well, to be very, very clear. But they've seen production, and I think that because that really informs how you how you build technology. Yeah.
People that really appreciate the hardware software boundary. Yeah. Exactly.
Definitely in the vibe coding era, there there are a a crop of engineers that they don't think about hardware at all. Mhmm. And we don't have that luxury.
And so people that are a little more passionate about going a little bit Yeah.
lab or something, that's where you're gonna get the biggest contrast, which is like we're just dealing with with reality. I mean, what other things? I don't know the classic stuff.
You know, you want you want folks who work hard and who are who love the technology and like like a podcast like this. Like, if you made it to this part of the podcast, you probably qualify for you're interested in this. Yeah.
And Peter said that he likes the podcast as well, which is like Yeah. I'm cool. I'm in man.
Yeah. Specifically on the hardware software boundary part, it's it's something I think about of our education system in The States, but also maybe just in generally. I feel like there is that retreat away from that classical computer science or EE education.
Computer engineering or yeah. Yeah. Yeah.
And I is there a point where you just do it yourself? Like, you know, because at this point, you guys are the world experts on this. And actually, you shouldn't wait for some college system to spit them out for you.
Oh, you mean that in terms of education and upskilling kind of Yeah.
Just just grab, like, young General Motors already did it. Yeah. Smart GMI.
The most.
Yeah. They were out of university? Yeah.
That's where I went for undergrad. I went to the General Motors Institute.
Okay. I did. That did not come by.
I saw HBS. Yeah. Yeah.
Yeah.
sees HBS.
the the Harvard brand at Lewis is is high. What's General Motors Institute like? It started a hundred years to answer this exact question.
Literally, the question you just said, which is Okay. Like, not enough engineers in Michigan. You know, you're talking about the early days of the modern corporation.
Yeah. General Motors being there's a great book, Alfred P. Sloan's My Years With General Motors that is highly recommended, which basically talks about what becomes a modern corporation.
But a part of that is they're like, we are we're basically buffering on engineers. So they started a school. And, actually, even Google as as as most as recent as probably ten years ago was thinking of starting a university internally versus discussions on it.
So, yeah, it was I would say, we we definitely up I mean, we definitely upscale folks as well. The amount of training we do in term is actually surprising. Yeah.
But it's a luxury you have when you're at our size. When you're like 25 engineers No. You just gotta survive.
So again, take advice that's relevant for your company rather than like immediately start trying to take high schoolers and make a big difference. But I still I know that I I I didn't go to a class that that you taught because, like, it sounds like you can teach a lot. Yeah.
the one of the most amazing use cases of these large models now is education. Right? Like, I I've I've taken an engineer who very good engineer, aerospace engineering background.
And in a relatively short time time span, like, he's doing very confident front end work, very confident back end work, like, with the help of these models. Yeah. And, like, not only can you do implementation with them, but you can also just learn.
Right? It's like you ask questions, and you don't feel embarrassed because the model's not gonna model's not gonna call you out on anything.
Yeah. I think the I think the thing you probably need more than an engineering degree, though engineering degrees are, like, very important. Like, I I I don't know if there's a way to shortcut, like, fluid dynamics or heat transfer.
The fundamental stuff. The fundamental stuff, at least on the mechanical side, is you need an engineering mindset. And that sometimes is actually not everybody actually has that.
Some people are emotionally drawn towards the arts or something else, and it's completely fine. There's no judgment there. But I think the engineering mindset maybe in a more usable way is like wanting to understand a lower level and a lower level and a lower like like, how do photons move?
Extreme curiosity. Extreme curiosity. Like, what is light?
What is a radio wave? Like, these really fundamental questions. Right.
And if you get curious enough about software, you ultimately end up in hardware. Right? Yeah.
And so that's the Alan Kay quote. Yeah. Yeah.
Exactly.
division for everyone else. I mean, you know, we were in all these other fields. I think if you talk to our trucking customers, they wouldn't even think perceive for, you know they like some sense, like, you guys did some automotive stuff, but you're you're really helping us.
So Automotive is not trucking? No. No.
I know. That's the It's like the whole Yeah. Yeah.
It's it's it's separate. There's different problems. The mass and you have you have the general categories of on road and off road.
I think that's what you're thinking. So there's on road and off road, but within on road, there's all these sub subclass of machines, especially when you talk about, you know, you know, you look at a delivery robot that doesn't have a human in it.
that you have when you're in a self driving because you don't to account for that. You can just break You'd break hard. And you don't care about jerk and all of these metrics that are be become become insane.
The way to think about it honestly is a little bit like any system that you as an as a human would need special training to operate. You can think of it little bit differently. So, like, the license to operate a truck is different from the license to operate a car.
Mhmm. It's different from the license to fly a plane. It's different from the you get it.
Right? Awesome, guys. Thank you for taking the time.
Yeah. Thanks for having us. Thanks for having us.
Yeah. Thank you.
Shared via Hopper