Physical AI Has to Survive the Machine

A driverless truck makes errors a physical problem

A conversational model can get a description of a podcast host wrong. A model controlling a driverless truck faces different consequences. Qasar Younis says Applied Intuition was operating driverless trucks in Japan at the time of the conversation. His central constraint is safety-critical deployment: learned behavior must work inside machines whose failures can cause harm. Operating those trucks is a deployment claim, not a claim of measured error-free operation.

Peter Ludwig describes Applied Intuition as a technology supplier to machine manufacturers and government customers across cars, trucks, construction, mining and defense. Its first customers were robotaxi companies; its initial work focused on simulation and data infrastructure. By this conversation, Ludwig says, the portfolio had grown to more than 30 products.

Younis recalls investor skepticism toward developer tooling around 2016–2017. Tools nevertheless gave the founders a practical starting point for deploying software on physical machines. They had not anticipated the transformer boom or end-to-end autonomy—models that map sensor inputs to control outputs. Younis argues that these models enable generalization across machine form factors. Customers can buy individual tools or a complete solution; chip manufacturing remains outside the company’s scope.

Ludwig estimates that the stack had undergone roughly four complete evolutions, changing about every two years. A roughly two-year investment horizon leaves room to adapt to research. The hiring requirement has been steadier: engineers who understand low-level systems and the hardware–software boundary, alongside researchers and engineers who have put machine learning into production.

The platform connects testing, control and human supervision

Applied Intuition’s platform spans three connected responsibilities: - Simulation and development infrastructure: test moving machines virtually and correlate the results with physical tests. - Operating systems: provide scheduling, memory management, middleware, message passing and reliable data links for vehicle software. - Autonomy and world models: develop models that control machines and predict the consequences of actions across automotive, agriculture, construction, mining and defense.

Human interaction extends beyond buttons and touchscreens toward voice and awareness of the person inside a cabin. A driver-fatigue warning is a simple precursor. The more ambitious example is a farmer supervising several autonomous machines: agents make routine decisions, and the farmer intervenes at critical decisions or disengagements. Supervision could span several machines, with people still involved where the operation requires them.

Training sensors need not become production sensors

Applied Intuition does not manufacture sensors. Customers generally choose from a supported set, with additional integrations possible for strong requirements. But selecting the production hardware is only part of the decision: a sensor can teach a model even if it never ships on the production machine.

During data collection, camera imagery can be paired with depth measurements from LiDAR. Those pairs supply training supervision: examples connecting image appearance to distance. The trained model can then infer depth from camera data, potentially allowing the production configuration to omit LiDAR. Applied Intuition describes using heavily instrumented research vehicles and lower-cost production configurations across its portfolio, with cost and reliability as the goals.

The mission can impose different sensor requirements. Some defense applications need nighttime sensing while avoiding emitted energy, making infrared useful and LiDAR or radar undesirable. Sensor choice follows operating constraints, rather than a universal preference for cameras or depth sensors.

The operating system controls timing, faults and updates

The human–machine interface, or HMI—the dashboard controls and displays—is a thin layer of vehicle software. Underneath it, the operating system supports real-time control of motors, engines and actuators, redundant steering actuation, and latency-sensitive processing of live sensor streams.

Applied Intuition argues that control over much or all of this software enables system-wide tuning of latency, memory and failure behavior. The team can coordinate timing across the processing path and provide fallbacks for critical faults. A cosmic ray flipping a processor bit illustrates the requirement: the system must accommodate failures in the computation beneath the model, as well as errors in the model’s decisions.

Reliable updates are a core platform capability. One respondent contrasts frequent updates on their Tesla with an industry pattern of infrequent updates, sometimes limited to the HMI, while safety-critical changes require a dealer visit. Applied Intuition claims its operating system enables updates across vehicle systems without rendering the machine unusable. No update failure rates accompany that claim.

The platform strategy takes inspiration from Android: consolidate fragmented software so applications can run across manufacturers. Reusable operating-system technology still needs support for diverse chipsets and architectures, extensive testing, and the additional demands of safety-critical operation.

Customers can choose how much of the platform to adopt: - Operating system plus autonomy: license both from Applied Intuition. - Operating system with another autonomy stack: use its platform beneath a different provider’s technology. - Developer tooling alone: buy tools for systems they are building themselves.

Agents change design workflows; humans still validate critical code

The implementation relies substantially on C++, with assembly when needed for lower-level work. Rust is mentioned as an emerging option without a specific account of adoption. Coding assistants are also part of the workflow: a respondent describes Cursor as having led internal usage for a period, with Claude Code believed to have since taken the lead. An internal leaderboard encourages adoption.

Sensor Studio turns sensor placement into an agent-accessible design task. Its original graphical interface let users select sensors from a library, place them on a machine and examine tradeoffs. Applied Intuition says it now exposes the underlying APIs so agents can configure a sensor suite from text, and is extending this approach across its products. Better configurations are an expectation, not a reported comparative result.

Hiring is shifting toward asking useful questions and combining AI tools, with selective tool use permitted in interviews the company considers harder than before. A respondent perceives a large productivity gap between engineers who have invested in these workflows and those who have not; the assessment is qualitative.

The reported benefits extend into embedded work. Improved shader generation with successive, unspecified Claude models supplies one anecdote. Yet AI-written safety-critical software still needs careful human validation. As generation improves, deciding how much checking is appropriate becomes a central engineering problem.

Better models make the remaining faults harder to find

Better behavior does not make evaluation straightforward. As models improve, their remaining faults become harder to discover, while unresolved edge cases still matter. Evaluation gets harder without becoming less necessary. Applied Intuition identifies fault discovery as a major investment area.

End-to-end autonomy also changes the training infrastructure. Because the model consumes sensor inputs and produces control outputs, reinforcement learning requires the simulator to generate sensor data. Applied Intuition describes its neural simulation as a hybrid of Gaussian splatting and diffusion methods, without detailing their implementation. The governing requirement is enough simulated experience, generated fast and cheaply enough, to make training worthwhile. Performance optimization matters both on the vehicle and in the infrastructure that trains its models.

The validation discussion distinguishes two kinds of evidence: - A known scenario produces a pass or fail. Emergency-braking tests from the European New Car Assessment Program, or Euro NCAP, supply the example: can the vehicle respond to a child emerging from an obscured area? - Operational reliability requires statistical support. The respondent emphasizes mean time between failures and how convincingly the system’s reliability can be substantiated.

The company presents improved model reliability as an economic unlock for deployment, but gives no numerical reliability threshold, operating conditions or cost comparison. The consequential claim is that reliability affects whether deployment is economically practical, as well as whether the machine completes a task.

Public acceptance introduces another responsibility. In the Cruise exchange, one voice initially emphasizes company conduct and communication over technical failure; another insists that a technical failure occurred and the response worsened its consequences. The first position is then narrowed to the argument that the company could have survived. Technical failure and institutional response are distinct problems. Waymo is offered as a positive example of responsible conduct.

One participant argues that society may need to accept unfamiliar severe accidents if autonomous systems are safer overall. Another emphasizes redundancies and fallbacks intended to prevent catastrophes. These remain arguments about safety and acceptance: the human-driving comparison has no specified dataset or exposure measure, and the redundancy argument supplies no architecture or failure probabilities.

Simulation must represent the constraints that cause failure

Sim-to-real validation means repeatedly using physical-world feedback to adjust simulator parameters until the difference is small enough to trust the results. A simulator does not acquire that trust automatically, and unexpected discrepancies can still emerge after validation.

Actuator temperature makes the mechanism concrete. A robot’s learned policy—its choice of actions—may accomplish a task while overheating a motor. Representing temperature in simulation allows reinforcement learning to account for that heating and adjust the motion. Omitting motor temperature can produce a policy that overheats the real robot. A failure of deployed behavior can therefore originate in an incomplete training environment.

The interviewer tests that explanation with a robot operating in a freezer: could a thermal constraint appropriate elsewhere unnecessarily restrict this machine? The exchange leaves the example unresolved, but identifies a further requirement. Adding a physical constraint is only useful if it represents the deployment conditions appropriately.

World models can expand simulation using real-world data alongside explicitly programmed equations. But simulation fidelity has an economic limit: reproducing reality can become more expensive than testing the physical system. The objective is useful training and evaluation feedback at lower cost, with real-world testing retained.

An illustrative vehicle-software testing split shows the layers; these percentages are neither a measured allocation nor a universal prescription: - 95% in conventional automated software testing: the continuous integration and delivery workflow familiar from web development. - 4% on an electrical and electronic rig: the truck’s components without the complete physical vehicle. - 1% on the actual vehicle: tests that require the machine itself.

A world model predicts how actions change the environment. For an earthmoving machine, taking material from one place and depositing it elsewhere changes the state from which subsequent actions begin. A respondent argues that relying exclusively on world models would be economically impractical; other engineering remains necessary to reach deployment.

Hydroplaning illustrates a possible learned connection. Road shape affects runoff; water can pool on a flat stretch, and vehicles may slow there. The respondent suggests that a model could learn to reduce speed from subtle visual cues. This is a proposed learning mechanism, not a demonstrated hydroplaning result.

Onboard models must fit the clock, power budget and connection

Deployment separates two compute environments: - Offboard software runs away from the machine. It can use large models, data-center GPUs and distributed compute when the task permits response times of one or ten seconds. - Onboard software runs on the machine. It must meet millisecond-scale response budgets; even fractions of a millisecond matter when excessive latency prevents the vehicle from functioning.

Smaller derivatives of large models must retain useful capability. This motivates distillation and efficiency work: fit inference within latency and power constraints. The hardware must also balance cost and performance while tolerating vibration, heat and other operating conditions. Applied Intuition frames available hardware and safety-critical requirements as more immediate limits than model intelligence alone.

A respondent considers a two-billion-parameter model feasible to run on an embedded system, while emphasizing substantial customization for a useful task. No hardware, latency or power measurements turn that statement into a deployment recipe. Generalist models such as Gemma are candidates for voice assistants; Applied Intuition describes its autonomy models, simulation and data work as entirely in-house.

Remote inference needs both acceptable latency and reliable coverage. Much of the company’s operating environment requires local execution because coverage is unavailable, including in parts of the United States. A cloud call is therefore not an assumed substitute for onboard computation.

Mining supplies a useful baseline: valuable, hand-coded route following supported by precise positioning. Real-time kinematic positioning, or RTK, is cited in mining and agriculture, with a combine maintaining one-to-two-centimeter precision down a field as an example, though the technology is described as expensive. The proposed advance from end-to-end systems is perception and action beyond a prescribed path, in an environment that changes.

Applied Intuition pursues several technical approaches because industries and geographies expose different weaknesses. Large-scale transformers are one bet; research also targets situations where an approach underperforms alternatives.

Planning matters when actions change later possibilities. Mining and defense tasks can require many steps toward a goal. An interviewer raises excavation that makes an area inaccessible; a respondent frames a scoop as a sequence of tokens that changes the state used for subsequent prediction. This is a conceptual account of actions and consequences, not a demonstrated universal model or measured planning horizon.

Advanced engineering bridges the demo and the business

The discussion of brittle humanoid systems separates three stages: - Research develops fundamental techniques. - Advanced engineering fixes the subcomponents blocking deployment. - Production handles deployment, maintenance and the problems of operating machines. One respondent places much of the field’s current work in advanced engineering. Impressive demonstrations still leave substantial work in that middle stage.

The speakers attribute deployment judgment to accumulated failures. After almost a decade, one says a demo suggests the next twenty problems a company will encounter and which fixes might work. They describe experience, including failed approaches, as shaping those expectations. Their optimism about robotics rests on longstanding neural-network ideas becoming practical through available datasets and simulation technologies.

Commercial constraints should inform technical scope. Hard engineering and abundant capital can make technical feasibility feel like the only constraint, but an attractive fundraising story does not produce a sustainable business. Applied Intuition describes its operating systems, tools and models as compounding investments. Commercial discipline gives a company time to benefit from that accumulated work.

That leads to two related choices: - Match integration to company stage. A startup with limited money and engineers should be cautious about copying a mature company’s vertically integrated strategy. - Start with a small problem space that can grow. In hard tech, tackling too many difficult components at once risks an overall product assembled from mediocre parts.

Building quietly also depends on existing networks. One speaker says a majority of Applied Intuition’s first 400 employees came from Google, where the founders had worked together. Founders without those connections face a different recruiting problem. The proposed alternative to copying successful companies is choose a product space from the team’s capabilities and customer feedback.

Advice must also fit its historical context. The discussion argues that startup guidance from 2014 cannot carry over unchanged into the AI financing environment of 2026: available capital and the investor market have changed.

The closing test: what does this particular machine require?

Asked where researchers and engineers could contribute most, Peter returns to model efficiency and rigorous evaluation. Models must become smaller and faster while retaining useful capability; performance includes execution latency. Evaluating safety-critical behavior remains a substantial investment involving both engineers and researchers.

At the time of the conversation, Applied Intuition reports hundreds of openings across developer tooling, physical AI, operating systems and autonomy. Its preferred profile combines deep systems understanding with production experience, whether the engineer is a specialist or has broader skills. Understanding the hardware–software boundary remains essential.

The training discussion invokes General Motors Institute as a precedent for responding to an engineering shortage, and recommends Alfred P. Sloan’s My Years with General Motors for understanding the modern corporation. Applied Intuition describes substantial internal training, but emphasizes that the capacity depends on scale. A team of roughly 25 engineers should prioritize survival rather than imitate a large company’s training investment.

Large models can help engineers learn across disciplines. One respondent describes an aerospace engineer becoming confident in frontend and backend work with model assistance. The benefit is educational as well as practical: learners can ask questions without embarrassment. The speakers nevertheless offer no easy shortcut through fluid dynamics or heat transfer. They emphasize curiosity about progressively lower-level mechanisms.

The final exchange clarifies the limits of generalization. Trucking and passenger automotive work remain distinct autonomy domains; on-road versus off-road is only a broad division. An unoccupied delivery robot makes the distinction concrete: without a passenger, ride comfort constrains behavior differently, allowing harder braking and changing the relevance of comfort metrics. The machine changes the objective, even when technology is reusable.

The closing heuristic is practical: different operator training suggests a different autonomy domain. Cars, trucks and aircraft require different human qualifications. Those distinctions are a starting point for deciding which behaviors and operating requirements a machine’s autonomy system must handle.