# Physical AI Strategy: Platform Consolidation & Engineering Shifts

**Podcast:** Latent Space: The AI Engineer Podcast
**Published:** 2026-04-28

## Transcript

Hey everyone, welcome to the Latent Space podcast.
This is Alastio, founder of Kernel Labs, and I'm joined by Swix, editor of Latent Space.
And today we have, we're very honored to have the founders of Applied Intuition, 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.
They were just joking around right before this and then they flipped it pretty quick.
Yeah, it's good to have you guys.
Maybe you just want to introduce yourself so people know the voice on the mic.
Oh, sure.
Yeah, I'm Peter Ludwig.
I'm the co-founder and CTO of Applied Intuition.
And my name is Kasser Yunus.
I am the CEO and co-founder with Peter.
Nice.
Can you guys give the high level of view of what Applied Intuition is?
And 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 kind of in stealth for a long time.
So maybe just give people the high-level overview of what it is today and 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.
And so we work on physical AI for all different types of moving systems, everything from cars to trucks to construction and mining equipment to defense technologies.
And we're a true technology company.
So we build and sell the technology and we sell it to the companies that make the machines.
We sell it to the government, really anyone that wants to buy a technology to make machines smart.
Yeah.
And I think in 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 fits in a screen, you know, like.
whether it's code complete products 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 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 those two words are really important because learned systems.
can make mistakes if you're asking for like you know some you know so something like tell me about these podcast hosts that i'm about to go meet but uh 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 l4 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 kind of like on the data infrastructure side of things.
What was the evolution of the company?
Well, from the very beginning, we always wanted to really be a technology company that helped generally push forward the industrial sector.
And so we started off working in autonomy.
Our very first customers were robotaxi companies.
And we started off doing a lot of work in simulation 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 landscape of physical AI.
Yeah, I think the scale reason is because we're all YC universe companies, 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, you know, thanks to the AI boom.
But honestly, 10 years ago, it was out of vogue.
Like doing a tooling company in 2016, 2017 was not like the thing to do because I don't know if you remember the VCs generally.
their views was that the toolings are just, they're just workflows and workflows ultimately are not really interesting.
Uh, and we're going to come, you know, full, full circle of that.
But when we started the company, our, our kind of, you know, it's kind of like in the periphery of what the company wants to be.
It was like, from our earliest days, like we want to 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 going to 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 and 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 want to build the stuff themselves.
And so we just offer like a spectrum of solutions from, you can just use like one part 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 kind of 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, you 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 not our, that's just not us in a more post-fundamental way.
I mean, I- You have thoughts.
Yeah.
Well, it's, I mean, I think it's just like what, 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- scratched the itch.
I think we're like Michigan guys who are kind of more of that traditional engineering kind of a realm or lineage.
I used to joke.
I just say that what was clear 10 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 10 years ago.
And the precise path that we've taken over the years, I think we've been strategic and we've adjusted to make sure that we're actually building stuff that's valuable to the market.
Like the technology has changed so much.
Like our own technology stack 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.
And so the way even we think about engineering is almost on this two-year horizon, we're preparing ourselves that, hey, we want to 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, one thing that has been consistent is the type of people we've recruited, frankly speaking.
It's engineers who are fall into the, you know, sometimes very traditional, like, you know, Google, GenSui, 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 traditional ML researchers and folks who actually you know, put ML systems into production.
That's been pretty consistent.
I think that like, you look at the mix of our engineering, 83% of the company is engineering.
So it's like a giant lease, a lot of engineers.
Which by the way, a thousand engineers.
I mean, that's on your website.
So I imagine it's out of date.
It is up to date.
Yes.
Okay.
And then 40 plus founders.
Yeah.
We 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 a lot of the YC folks, it's kind of like we recruit a lot of Google people, for them to exercise both their technical and non-technical skills.
Because, you know, we're on the applied side.
We have a research team that we do fundamental research, we publish, and we've had great traction there.
But fundamentally, the business wants to take this intelligence and deploy it into production.
And there's like a certain type of person that's more interested in that.
Yeah.
You mentioned the tick stack, Peter.
So I just wanted to give you some reign to just go into it.
I'm interested in where bio-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 work that we do.
And we've been at this for almost 10 years now, so the technology is pretty broad.
But we got started with a thousand engineers, like you could work on lots and lots of stuff.
Especially with AI tools now.
So we got our start in 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.
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 is a very deep topic.
We have a whole suite of products in that, and we can talk for many, many hours about that specifically.
But 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 a lot of these AI systems right now in some way relate to reinforcement learning.
And 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 on operating systems technology.
True operating systems.
Think about schedulers and memory management and middleware and message passing and highly reliable networking and data links.
The reality is if you want to deploy AI onto vehicles, you need a really good operating system.
And when we were getting deeper into that space, there wasn't really anything that we were happy with.
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 can do this better.
And so let's build something.
And that was then 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's what got us into that.
And then the third bucket that we work on, it's true fundamental AI technology.
Models, we do a lot of work in, as I mentioned, the foundational research, but then also the world models and the actual autonomy models that are running on these physical machines, as that's across cars, trucks, mining, construction, agriculture, and defense.
And so that's both land, air and sea.
And also a smaller subset 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 touch screen 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 um you can think from a safety systems perspective the most simple version of this is like the driver is tired right and they're there you know if you get those alerts when you're driving your cars that we 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's also what we work on so that's not pure autonomy it's a little bit of a mix but it falls under uh autonomy in the automotive sense, that's typically defined in SAE levels as an L2++ system, where you're human in the loop.
But just take that idea, you know, to other verticals.
Yeah.
You have not mentioned hardware at all, like sensors or, you know, obviously you mentioned you don't do chips.
I think even in AV, there's like a big, you know, cameras versus sliders.
Like, what are like in your space, maybe some of those design decisions that you made and are they...
Driven by the OEM's ability to put things on the machinery?
How much influence do you guys have on co-designing those?
Yeah, so we don't make sensors.
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 we, let's say, fully support.
And then our customers, they can sort of choose from those.
And obviously, if there's a very strong opinion on supporting something else, we will add that to the platform as well.
And the LiDAR question is at this point sort of the age-old topic in autonomy.
And the state of the industry right now is LiDAR is hands down a useful sensor specifically for data collection and the R&D phase of autonomy development.
If you see, for example, a Tesla R&D vehicle, it actually has LiDAR on it to this day, right?
In the Bay Area, we see these, you'll see like Model Ys or CyberCab that have LiDARs on them just driving around.
So 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 is looking this direction, this LiDAR is looking this direction.
And now for 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 that depth information then becomes a learned state of the camera data.
And then when you're doing the production system, you can now remove the LiDAR and now you can actually...
get depth with just the camera.
And so that difference between like a highly censored R&D vehicle and then the down-costed production vehicle, we use that across our whole portfolio products.
And of course, the end goal is you want super low cost and super reliable.
And then in certain use cases, you have some more bespoke things.
Like 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 want to be...
putting energy out.
So you don't want to use LIDAR or radar, but you still need to be able to see at nighttime.
So yeah, we work with the whole gamut.
Cool.
So that's kind of like on the hardware level.
Then on the OS level, how does that look like?
What is like unique?
I mean, my grip, I 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 the autonomy future look like?
When most people, it's really what you just described.
When you think about operating system in a vehicle, you're thinking about the HMI, 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 uh for different let's say the steering actuation in the vehicle and all of these things need very core support in the in the operating system and then of 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 try to run microsoft windows streaming your sensor data and or controlling the vehicle like the latencies are going to 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 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 there is a critical failure what if there's a cosmic ray that flip it 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 core operating system is a part of that.
And then the one last thing, which is a lot less exciting, but is actually a very big topic, is reliability of updates.
So 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 even if they are doing updates, they're usually only updating maybe one module.
Maybe they're updating the HMI module, but they're not able to update, let's say, the see-through 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.
There's lots of technically deep stuff in the tech stack to do that in a way that you're not going to...
accidentally brick a vehicle.
And imagine you're...
That would be bad.
Yeah, bricking a car is very expensive.
Yeah.
And honestly, across the industry, maybe one of the most just sheer impactful things that we've done is we're now enabling the industry to actually do software updates.
Just to clarify as well, who is the customer for this?
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.
Who pays for this?
Who invites you into the house?
Is it the end user or is it the manufacturer?
Yeah, so let me make an analogy firstly on the fragmentation of software.
Physical machines today are more akin to 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 part of the reason that Larry at Google decided to get into Android was they wanted to run Google products on a bunch of phones.
And 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 Google to make their app run on all 50 devices equally well.
And so the solution was, well, actually, what if they created a really great operating system and made it attractive to all of these phone makers?
And that was sort of the genesis for what Android was and why Android existed.
It was a way for Google to get their products onto really wide diversity of devices.
The state of the physical industry right now, it's a little bit like that.
Like there's, yes, these companies have firmware, but 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 why we've done that.
And then your specific question was, who are our customers?
Generally, it's the companies that are making these machines.
And so we're selling our technology to them to really simplify the architecture and enable these applications to run on them.
How much is reusable across?
Do you have one OS that is just configured for everything?
Or is there some more customization that's needed?
Yeah, highly reusable.
So the fundamental technology is...
quite universal right so things that we do have to think about though are like chipset support and so um if you're if you're coding uh let's say uh an llm and you have a start with an assumption that hey i'm gonna i'm gonna use cuda and i'm gonna run this uh 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 going to use that But the hardware, especially in safety critical systems, it's a lot more diverse.
There's not one or two players.
There's a bunch of different ship sets that we have to support.
And so our operating system doesn't just run on like the equivalent of x86.
It has to run on a number of different architectures.
from chips from a bunch of different companies.
But again, we've been working on this for a long time now.
So we have support for all of those chipsets.
And then when you want to then 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?
Android has a huge suite of testing and 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 all these physical moving machines with 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 kind of like all in one?
You have to use us.
Yeah, it's totally open.
Yeah, our philosophy is that we are a technology company, and so we license our technology to customers to use how they want.
And so if a customer wants to, if they want to license our autonomy tech and our operating system, then great, we'll license those.
If they just want to license the operating system and then use different autonomy tech, that's fine also.
And we have great documentation.
Or just want to use developer tooling.
Yeah, exactly.
It's like a better together, obviously, if they were together.
Is it all C++, I assume?
Is it different to compile targets?
We use a lot of C++.
I mean, Rust is sort of the new hot kid on the block for a bunch of things as well.
But yeah, the lower level you get, especially when you get to real-time constraints, you hit C++ at some point, and at some point, maybe you 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 use everything.
I mean, so Cursor was, I think, the hottest tool in the company for a good while.
Now Cloud Code, I think, has taken the reign on that.
We have an internal leaderboard that we use just to sort of encourage adoption within the company.
And yeah, they're phenomenally useful.
I mean, it's...
Honestly, we take inspiration from some of those tools also and how we're adapting some of that mindset of thinking to the physical realm.
Like if it's so easy to build an app for this or that thing that lives just on a screen, we're taking out a lot of the same ideas and applying that to, okay, well, if you wanted a physical machine to do something, how easy can we make that using our own tooling and platform as well?
Are you changing any of like the OS architecture kind of like?
the way you expose services to like be more AI friendly or?
Yeah, absolutely.
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.
As an example, we have a, product we call sensor studio, which is it helps you design the sensor suite for for your autonomous vehicle, whether it could be a car could be a drone could be a mining mining equipment could be a robot.
And you place sensors in different places.
There's a library.
You can understand what are the trade-offs that you're making in the design of that system.
And that was like a very gooey, intensive thing because it's a little bit more like a CAD tool in that sense.
If you've seen CAD tools.
Nowadays, though, we expose all of the underlying APIs for that.
And now using AI agents, you can actually...
configure a sensor suite with just text 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.
The other thing I was thinking about is just in terms of like AI adoption, does that change your hiring at least a little bit?
Or how do you sort of manage engineers differently?
Yeah, absolutely it does.
We, I think like every company in the Valley right now, are evolving our hiring practices because the skills required to be effective are changing so fast, right?
I mean, you used to really select for just rote implementation ability.
And now 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 no longer the core job, right?
It's actually knowing what questions to ask, knowing how to tie together these different AI tools.
And so the interviews that we give now, I think are...
way harder than they've ever been, but we also allow selective use of AI tools to solve the problems.
And I think in that, you start to see more of a bimodal distribution of engineers, right?
You start to see like, wow, there's this subset of people that they really get it.
Like they're all in and they've clearly invested the hours needed to learn these tools and how to be effective.
And then there's sort of the group of people that haven't done that and that the productivity gap is just enormous.
And so we're trying to obviously select for the people that are really, really into this.
I first wrote 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 an extremist stance where, well, every software 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 six months ago, I would have said the same thing, but it's becoming super useful for every domain.
I'm sure.
I think six months ago, or 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 the embedded realm.
No question, though, especially when you get into safety-critical systems, the human validation is 100% key.
you're not going to trust your life to an AI-written software that's not been very carefully checked by humans.
And so I think now really the challenge is about that appropriate level of human validation 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 gives you...
what makes you sleep at night?
Like if somebody is like, you know, just web 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, then it puts a lot of work on like the verifiable side of it.
Like what does that look like for people?
Yeah, yeah.
So verifiability, a broader bucket of like evaluations, right?
How do you evaluate the results that you're getting?
I think this is probably the hardest problem right now.
Because as the models get better, it can be harder and harder to find the faults in the system.
And so the problem of doing proper eval to find those faults, that problem also keeps getting harder as the models get better.
But it's no less important than it's ever been.
There are still going to be edge cases that are not met and whatnot.
And so it's a big area of investment for us.
On the reinforcement learning topic, the key thing is...
there's all 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 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 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 call our work in this neural simulation, but it's, think of it like a hybrid of Gaussian splatting and diffusion methods, and where you really care about performance.
Performance is everything.
If you can't do enough simulation fast enough and cheap enough, you actually can't.
get results that are worthwhile in the end.
It also gets to a lot of our work in embedded systems, which is like performance critical work.
And that performance optimization, performance criticality, it carries over to a lot of the model training work because the only way to make it affordable is it has to be really fast.
I think it's worth a few minutes talking about our own evolving thoughts on verification and validation within kind of traditional simulators, which are you know, uh, 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.
Uh, I think that's an interesting topic.
Yeah.
Yeah.
So in, um, in more traditional development, right.
You, you oftentimes would have, uh, more black and white answers to questions.
And so the.
In Europe, as 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 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 you hit it.
You end up with sort of these binary answers of like, well, did the car under test pass this specific test?
And there's a very, very well-known set of test cases that the vehicle has to pass.
And that was how the industry worked, let's say, until 10-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 magnitude or how many nines of reliability?
can I get in the system and how can I prove that to be true?
And the big unlock honestly for physical AI 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 now good enough that it actually becomes cost-effective to really deploy these things.
And so the big shift in sort of 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 now it's more of a statistical verification and validation case where it's all about how many nines are reliability and meantime between failures, that sort of thing.
And is the target audience regulators or even the customers?
I imagine the customers are bought in and it's mostly regulators that need to be satisfied.
We do work with...
The U.S.
government, we do work, of course, with the European governments 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 so we do education 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 we think is reasonable and how to think about like when is a driverless system actually safe enough to go on the roads and that sort of thing.
I wouldn't say that the government is asking for it.
It's like we're more teaching the government in that sense.
It's honestly, it's more so for our own comfort, right?
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, should we educate our customers?
Yeah, first, I mean, our first core value is on round 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 us is probably as important as like some regulator or a customer saying, you know.
Of course.
Yeah, you have to satisfy yourselves.
Yeah.
As a whole across the world, regulation oftentimes, it's like a almost lowest common denominator, but you really have to substantially exceed what the regulators are expecting to make good products.
One thing I often talk about, I think, and I try to make this relatable to the audience also, is crews.
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.
But I don't know if regulators understand that you cannot extrapolate from a single incident.
But we do, because that's all we have to go on.
And your sample sizes aren't necessarily going to be lower than, I don't know, consumer driving.
Yeah, I think the cruise example wasn't a technology failure.
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 definitely was a technology failure, but it was made much worse.
Yeah.
Yeah.
Yeah.
And let me put it another way.
There is a version where crew still exists.
Right, right.
It was like the last straw.
It's like a long chain of issues.
ATG had that horrific accident of someone actually dying because, you know, that was a homeless person crossing the street.
So, yeah, 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.
Consumer and, let's say, mainstream adoption of these technologies is also going to be part of that conversation.
I think companies like Waymo are doing a lot of service positively to the industry in the sense of they're setting a high benchmark and they're showing, you know, kind of in a very responsible way how to deal with these.
There have been Waymo incidences as well.
They've just not been as significant as the Cruise one that you mentioned.
But yeah, so I think, I think you'll just continue to see that.
I think probably the long-term question is really going to be, again, around like, it is very clear humans are way worse drivers statistically.
Yeah.
Like there's no, there's no debate.
And so at what point, but we're emotional 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.
In the same way that planes, 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 on the flight.
So if you're ever getting nervous about getting on a plane, just think, I just got to get to the airport.
If I get to the airport, I'll be good.
But then planes also concentrate at tail risk.
I don't think we honestly have to worry about there ever being...
accidents from these systems that are much worse than what humans would cause?
Because humans do terrible things.
People fall asleep at the wheel all the time.
I have.
I've been a drowsy driver.
Drunk drivers.
And that's the extreme end of the example.
But I mean, these AI systems, you have redundancies, you have fallbacks.
Like there's many, many things have to go wrong for there to actually be something catastrophic because there's so many 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 and 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 uh about simulation there so let me go a little bit more technical on this so um at first go no simulation is going to represent the real world there's always a process of this uh 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 uh a number of times until you can get some confidence that oh i i think the simulator is now accurately representing what's going to happen in the real world now if you have a situation where you've done that full validation and you thought that it was accurate and then there's something different, those are much trickier cases.
And that absolutely can happen.
But really, the validation process is a really important part.
You can never skip the simulation validation process where you're actually ensuring that, hey, my central gap here is small enough that I can trust these simulation results.
And there's so many fun things that you can do when you get into it.
I'll give one fun example that came up recently.
In these humanoid robotics systems, overheating actuators is a real problem, right?
So, obviously, phenomenal demos.
The most amazing I can get.
I love watching robots do acrobatics like everybody.
But these systems actually overheat, right?
And one of the ways you can do simulation, though, is you can actually have the temperature of those actuators be one of the parameters that's represented in the simulation.
And then 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 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 will disregard that.
And now you run that on the robot, and the robot will overheat and fail.
I guess the question is, like, how do you have...
all of these parameters taken care of while also understanding the deployment environment like temperatures 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 fundamentally about you're trying to optimize the development of a system, right?
How can I build the system faster and better and cheaper?
And what are all the levers that I have to actually accomplish that?
And because simulation's just a software program, 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 additional real-world data.
And that also unlocks a whole new field of robotics.
There is a meniscus line where you cross where still doing real-world testing is better.
In the center real gap, you can reproduce reality at exceedingly expensive costs.
they said nothing is free so really 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 the real world at some point 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 there's not this you know magical land where you're not going to do that And, uh, maybe even like a more nuanced version of this and 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 a flows that you'd have in traditional web development.
But once you have now you, let's say you have a truck, we 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 physical and then you have the one percent which is actually the vehicle there's something there there's a similar analogy in terms of using simulation for intelligent systems you do a lot in a simulator but um in in using world models uh but ultimately it's it's physical ai so you're going to deploy it on physical machines and the freezer example comes to it comes to light The world model thing has been, to me, the hardest thing to wrap my head around.
We have Faye Faye Lee on the podcast.
We've been doing a small series of another intuition company, Genual Intuition, as well.
Yeah, I mean, lots of coverage on NERFs.
Yeah, it feels like we talk 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 real thing is like when you're doing both cars and the highway in Japan versus the, you know, excavator and a mine in Arizona, wherever you're deploying them.
How much of it are you relying on the world models to generate the simulations for you and then try to close the gap after versus giving the world models as a tool to your engineers to curate the simulations, if that makes sense?
Yeah, totally.
So I can say at a pure engineering level, I think 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 is just a very practical mindset of like, role models 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 if you take some sort of construction tool and that construction tool is going to be doing some work on the earth in some way, it's going to be moving earth.
the world model needs to understand that cause-effect relationship.
Like, okay, when I take this material from here and put it over there, 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 hydroplane one is actually a really great example because It's actually quite non-obvious sometimes.
It's like, well, it's raining, and well, this road has, let's say, the appropriate curvature to it, so 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 were driving faster, they were starting to lose control.
There are a lot of very nuanced visual cues in the scene.
And so I do think in the world model concept, there's a good chance the model actually would learn that you should just drive slower when these visual cues exist.
And that's obviously the beauty of these kinds of models, where 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...
I want to ask questions about also the deploying models.
I presume you use a lot of these world models for training data and simulation, but what about deploying it onto the systems in production?
Presumably, you have GPUs on device, but they're...
I keep saying on device.
What's the right term for this?
On machine.
Or embedded, yeah.
Yeah, yeah, yeah.
What is the embedded world like?
Because for people who are not used to that world, this is very alien.
Yeah, yeah.
So actually, we call it onboard and offboard.
So onboard software and offboard software.
And 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 say, well, this model, I don't care if it takes one second for it to give me a result or 10 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 on a huge GPU and you can obviously have distributed compute, et cetera.
But onboard, you don't have any of those benefits.
You're like, well, I have this many milliseconds where I need an answer from this model.
And so a lot more of the energy then is about, I think of it more like distillation and it's like truly efficiency and like literally every fraction of a millisecond counts.
And you can't have a situation where the model takes too long because then the vehicle can't actually function.
And so you can still use a lot of the same techniques and the models themselves you can think of as...
like a derivative of larger models that you can run offline.
And then you're trying to just get a model that still performs really well, but it's a small enough version that you can then run on this embedded system where you care about latency and power.
Yeah, and I think like the broader point, I think, which maybe is not obvious, but it's worth saying is, in the physical AI world, we're not really constrained right now by like the intelligence of the models.
it's actually what peter's talking about is actually deploying them in the hardware to give you yeah on the hardware you give you and right and so and there's just a reality is of safety critical systems so those end up being your your limiting factors rather than let's say a limiting factor for you know a foundation model company is going to be just capital maybe you know or or researchers so we're in that way dealing with you know for us as people who kind of come in that realm 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?
Just peel back the curtains a little bit.
Yeah, transformers first off, I think the paper was originally published in 2017.
So there's no time.
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, absolutely.
What I was going to say, though, was I think in the original paper in 2017, maybe it's in the last paragraph, somewhere in the paper, they talk about, by the way, this technique might be useful for images and videos as well.
And it took a few years for that impact to really hit.
But now we're seeing...
Transformers are everywhere.
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 performance and getting the right mix of those things in an embedded package that can also be shaken and baked and all the conditions that these things have to operate in.
But yeah, I think that they're only going to keep getting better.
And so we also try to plan our strategy understanding that we know the rate of improvements of these systems.
Yeah, so it's like Google just released the Gemma 2B model, the effective 2B model.
Is that useful to you guys, or is that too big?
You can run that model on an embedded system, definitely.
So yes, it's useful in that regard.
The bigger question is, what do you use it for in an embedded system?
You actually need to customize it quite a bit to make it useful for something.
But yeah, you could run a 2 billion parameter model, definitely.
It's also interesting, like, what percent is a custom ML model that only does that thing versus a generalist LLM, which probably is not that useful, actually, for your context.
You can imagine different use cases, right?
The voice stuff, yes.
Yeah, the voice stuff, totally, yes.
So for the actual autonomy elements, I mean, that's...
hundred percent in-house we do every bit of that 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 gamma actually can be quite useful yeah and then there's also obviously a trade-off between like what percent must you do on machine uh versus just call home Yeah, it's all about latency.
It's all about latency, yeah.
Yeah, well, like, you know, I think actually in a lot of contexts, especially in the U.S., you can just have a connection to the web.
Yeah, 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 U.S., there's a lot of plugins that have coverage, right?
And if you look at, like, uh the old world of autonomy within mining which is like long before transformers and and and kind of uh neural networks uh in the lexina and uh a kind of a universe they were really just hand-coded you know systems they were just like this machine is going to run to that place with this that was rg has a great accurate gps yeah and so that worked and that works for 20 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 seeing, it's perceiving, it's acting in a dynamic world.
I looked up RTK, real-time kinematic, one to two centimeter accuracy.
Yeah, yeah.
Fantastic.
But, you know, and fantastic in...
faraway lands where there's not going to be cell phone coverage.
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 field, they use RTK.
It's expensive.
Yeah, and it's autonomy, but it's not intelligent in the way that I think all of us, in 2026, we'd be talking about intelligence.
In one of your blog posts, you mentioned research on large-scale transformers that are similar to those doing modern generative AI.
What are the big differences?
Other than, you're absolutely right, I should steer the car, so you probably want to remove that.
We have a diversified bet strategy internally.
And the reason 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 we're not going to put all of our eggs in a single basket for a single approach because that approach may not work out.
And so that's one of the bets that we have.
And it has certain advantages in certain scenarios.
But the way that these things play out in practice is it has certain benefits and also certain drawbacks.
And then the research team tries to...
then work on the situations where that's actually worse than these other approaches and to ultimately arrive at a really great solution for all these things.
Is there a plan mode for physical autonomy, an idea of a planning step and then action step?
So short answer is yes, right?
So just like you can use cloud code to plan out some complex coding task and you get some almost specification written out, those similar approaches absolutely can be applied to physical systems because Imagine you're trying to accomplish some task.
The easiest to think about is RoboTaxi, but I think things get more interesting, let's say, in the defense context or in the mining context.
You actually do have to think about many steps in advance.
It's not just this one thing, but to accomplish the goal, there's 100 steps.
And then this concept of the plan mode, it's, yeah, very applicable.
Yeah, I was going to say, to me, driving feels like a great next token prediction, because you're kind of like on a pad.
And like, it doesn't really matter what you've done before, you know, you can always turn around.
Planting, 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, how would you, I guess, like, do you have like a taxonomy of like these different types of just kind of like driving, excavating, like flying?
So the interesting thing is, I think probably everything in the world can actually be boiled down to like a next token prediction problem.
And in any workflow, anything can be thought of almost as like there's this sequence of steps or the sequence of trajectories or whatever you want to call it.
And it can be boiled down actually to that sort of thing.
And in the mining case, you can imagine like taking that scoop, okay, that was that set of tokens.
And now that's, the model is now understanding that, okay, that the state space is different.
And now the next time I do token predictions, it's going to be modified by that.
But yeah, the remarkable thing about these techniques is just how universally applicable they are, right?
I mean, it 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 human owned companies.
that do these great demos um and then i can't buy it so obviously it can't all be there in your case you're like in production on real streets with like a lot of customers what are like the things 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 get done technically?
Yeah, so certainly productionizing stuff is really challenging no matter what.
So I would split the answer maybe into research and then also into production.
First, on the production side, there's just so many problems that you find when you actually get the stuff to go in the real world.
And so the classic problem in humanoids right now is these systems are actually pretty brittle.
I'm not talking about any one company, but just as an industry, the systems are pretty brittle.
Interestingly, I saw this thing the other day that I think China is doing a marathon with humanoids.
In government, not China specifically, but in any government, there's a concept called prize policy, which is so that there's different ways of influencing an industry to go a certain direction.
You can regulate it, you can do mandates, or you can actually just do these competitions.
The U.S.
version of this was the DARPA Grand Challenge.
That worked.
It really worked.
But I think China is literally doing this marathon because they know that reliability of humanoids is a problem.
And so what cooler way to solve that than to have a competition where humans seem to run 26 miles, right?
Are we there?
Can robots run a marathon?
I think it's happening any day now.
So we're there.
By the way, also automotive, there's a version of this, which is like 24 hours a little more.
Right.
It's like Porsche wins 24 hours.
Literally puts those products into production.
I would actually break it down.
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.
that are going to limit to getting into production.
Once you have production, you deal with another set of problems, which is like the deployment maintenance of those machines that exist.
So I would say, at least in our field, we're mostly in advanced engineering, in the automotive parlance.
Honestly, every step is hard, though.
Paul, at this point, you're worth $15 billion.
You bleed every step.
It's fun.
I mean, it's like, I don't know.
i i find it really enjoyable yeah but what it was also fun is like so we've we've been doing this now for almost 10 years and like we've just seen we've seen so much bad time and so right now we can look at any company in this space and get a demo, and I can write down a list of, I know exactly the next 20 problems they're going to hit.
I can guess also what they're going to try to solve each of those, and I can guess which one's going to actually work.
Yeah, it's not because we're particularly geniuses.
We've seen enough of this stuff.
We've lived enough of this stuff.
Our own kind of mental models of the world as leads in the company, we've tried so many things.
We're talking about the wins here.
There are plenty of losses among that many people doing that many different things.
And does that kind of like get baked into your like mental model of the world?
Yeah.
But I would say in general, we're excited about robotics for sure.
And like the- Massive opportunity.
Massive opportunity.
And what's happening now in the industry is like- None of these concepts are new.
What's new is the stuff is actually working now.
People have wanted to use neural nets for robotics for a long time.
But now, we now have the data sets, we have the simulation technologies where stuff is actually starting to really work.
And we're going to be part of that for sure.
Do you have requests for startups or advice against starting certain startups?
There's a lot of scale app robotics, new companies.
What do you think are...
A lot of, a lot of applied intuitions for other things.
I think you, you hit a, you hit a certain, uh, what is it?
Uh, you know, badge when Y- X for Y.
You become like a, you know, or, or literally the same similar names, like, you know, um, 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 or we talked about uh there's also like on the commercial side there's constraints which is we're going to 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 you know 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 going to 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 got to run a sustainable business.
And I think we're really 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 tooling gets better.
The models get better.
And so we're really going to get a, 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 $126 billion.
Right.
So what happens like is that the human brain just doesn't emotionally understand the compounding effects.
So that's going to 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 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 the 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 completely vertical.
Well, yeah, in 2007, Apple is very different than 1978.
In 1982, those companies were different.
They were literally just taking electronics from other manufacturers and putting it in an enclosure.
And so just be a bit more like, I don't know, be a bit more nuanced 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.
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 want to raise a lot of money to signal they're strong and you raise a lot of money without spending it.
Into higher, yeah.
You obviously like that.
Do you think that's still possible to like have a very narrow approach of like, hey, we're kind of like building a compounding thing without a grand vision right away versus...
It's very difficult to answer very general questions like that.
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 that's like a different way of asking the same question, but more answerable.
I think always, yes, that is the old YC, like go 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 going to do all of them in a very mediocre way.
And so the, the, the, the, the full product is actually fairly mediocre.
So yeah, I, I, I still in, I'm still in the camp of find a small problem space.
The other question you're asking is a tangential is like, should you like build in, in stealth and anonymity?
Well, yeah, if you're a YCCO, yeah, I mean, you can.
We worked, you know, together at Google, we have a long history and we don't, and which means, 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, that's a couple.
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.
And so then if you want to take inspiration from other really young companies, that's also bad because most of them are going to fail.
So 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 build in you.
Yeah.
Does it make sense?
Yeah.
Yeah.
I mean, Sam Allman, he said he regressed a lot of the advice that he's given at YC.
So I'm always curious to ask, you know, founders like you who nodded in.
At least YC does the opposite.
You know, Sam was president, I was COO.
And we'd have a CEO.
So we worked together, you know, extremely closely would be an understatement because the firm was also small.
But, you know, YC wasn't as big as like an open AI 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 at the the ai companies i should say more specifically and how they relate to the other yc companies and mark it's just so fundamentally different the amount of money raises 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 2000, 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 million checks, first checks, and they were not accelerating incubator.
And Ann, who's one of the co-founders there with Mike, they said that today they try to do, or like today, as in like three, four years ago, 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.
He says it in the shorter, more interesting than me.
I can just give you like, if you ask me, what is the purpose of a car?
Like open the owner's main and I say, number one, there's a steering wheel.
And you know, instead of like, it can change your life and we'll be there.
Yeah, I guess you're autonomy.
Yeah, exactly.
And then for Peter, I was just kind of 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, I think generally the making models very efficient.
Right?
So 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 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 so that in general as a field.
And then I would say also folks that are just really passionate about evaluating this technology, as in like model evals.
It's a hugely difficult topic, especially in safety virtual systems.
And we have a really great engineering team that works on this now and researchers, but it's a big area of investment.
And so, yeah, folks that are passionate about, yeah, performance, I guess, model performance, both in terms of capability and literally latency, and then evaluation of models.
Awesome, guys.
Any 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.co slash careers, I think 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 AI within physical machines.
The types of engineers, that's a great question.
That's actually more interesting than the roles because we're, you know, we're a large enough company.
We're hiring everything.
Yeah, we are 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 understand low-level systems, not just like a superficial understanding of technology, like engineers, engineers almost.
We definitely hire folks who are like...
have some diverse skill sets.
We hired 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 build technology.
Yeah, people that really appreciate the hardware-software boundaries.
Yeah, exactly.
Definitely in the vibe-coding era, there are a crop of engineers that they don't think about hardware at all, and we don't have that luxury.
And so people that are a little more passionate about going a little bit deeper.
Yeah, if you're to contrast us versus like an AI lab or something, that's where you're going to get the biggest contrast, which is like we're just dealing with reality.
I mean, what other things?
All the other classic stuff.
You want folks who work hard and who love the technology and like a podcast like this.
Like if you made it.
to this part of the podcast.
You probably qualified for you're interested in this.
And Peter said that he likes the podcast as well, which is like, yeah, yeah.
Specifically on the hardware software boundary part is 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.
And like, is there a point where you just do it yourself?
Like, you know, cause 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.
You mean in terms of education and upskilling kind of thing?
Yeah, just grab like- General Motors already did it.
Yeah, GMI.
Because they were out of university?
Yeah, that's where I went for undergrad.
I went to the General Motors Institute.
Okay, that did not come out.
I saw HBS.
Yeah, yeah.
Everyone sees HBS.
The Harvard brand Lewis is high.
What's General Motors Institute like?
It started 100 years to answer this exact question.
Literally the question you just said, which is not enough engineers in Michigan.
You know, you're talking about the early days of the modern corporation.
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 10 years ago was thinking of starting a university in terms of discussions on it.
So yeah, it was absolutely, we, we definitely, I mean, we definitely upscale folks as well.
The amount of training we do in terms is actually surprising.
Yeah.
But it's a luxury you have when you're at our size, when you're like.
25 engineers.
No.
He's got to survive.
So, again, take advice that's relevant for your company rather than, like, immediately start trying to take high schoolers and make a...
I didn't go to a class that you taught because, like, it sounds like you can teach a lot.
Yeah, well, I think, honestly, one of the most amazing use cases of these large models now is education, right?
Like, I've taken an engineer who...
Very good engineer, aerospace engineering background.
And in a relatively short time span, he's doing very confident front-end work, very confident back-end work with the help of these models.
And not only can you do implementation with them, but you can also just learn, right?
So you ask questions and you don't feel embarrassed because the model's not going to call you out on anything.
Yeah, I think the thing you probably need more than an engineering degree, though engineering degrees are very important.
I don't know if there's a way to shortcut.
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 starts or something else.
And it's just 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 the lower level and the 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.
That's the Alan Kay quote, yeah?
Yeah, exactly.
So I'm trying to make analogies and then do all these things.
Like, you know, you're kind of a blend between new General Motors and Tesla autonomy division for everyone else.
I mean, you know, we're in all these other fields.
I think if you talk to our trucking customers, they wouldn't even perceive, you know, they like some sense like, oh, you guys did some automotive stuff, but you're really helping us.
Automotive is not trucking?
No, no.
It's separate.
There's different problems.
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 subclasses of machines, especially when you talk about, you know, you look at, a delivery robot that doesn't have a human in it.
That's actually very different because now you're not concerned with like the actual feeling that you have when you're in a self-driving system.
You don't have to account for that.
You can, you can, you'd break hard and you don't care about jerk and all of these metrics are become, become.
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 a little bit differently.
So like the license to operate a truck is different from the license to operate a car.
It's different from the license to fly a plane.
It's different from, you get it, right?
Awesome, guys.
Thank you for taking the time.
Yeah, thanks for having us.
Thanks for having us.
Thank you.