一天设计1000个：Neural Concept 的 Thomas von Tschammer 谈 AI 原生工程

Hello, and welcome back to The Cognitive Revolution. Today, my guest is Thomas von Tschammer, co-founder and US managing director of Neural Concept, a Swiss company that uses specialist models for domains like aerodynamics, heat dissipation, and collision safety to help automotive manufacturers and other clients accelerate their product design and engineering processes.

As a Detroit, Michigan native, this topic is of particular interest because my father actually started his career at General Motors in the drafting department, back when designs and assembly instructions were hand-drawn on paper. I have vivid memories of watching him use early computer-aided design platforms on Take Your Kid to Work Day, back when I was a young boy. The work at the time was still highly manual and often quite intuitive, but as in so many fields, it has become far more computerized over time. By the time my dad retired, designs were routinely tested via physics-based digital simulations before the physical manufacturing process began.

This increased iteration velocity by an order of magnitude. But still, as we've seen in biological structure and binding prediction, materials science, and robotics controls, the compute required to run these simulations often becomes a bottleneck in and of itself. Today, as you'll hear, Neural Concept's models can deliver similar results to expensive physics-based solvers in minutes. They now also offer an engineering copilot product, which can both call these domain-specific prediction models as tools and actually use the core CAD platforms to make design changes as required.

This tick-tock combination of agentic optimization and domain-specific validation is the perfect recipe for reinforcement learning. Already today, it allows manufacturers like Jaguar Land Rover to conduct aerodynamic testing on more than 1,000 designs per day. It also frees human engineers to explore much larger regions of design space and focus their attention on navigating higher-level trade-offs that involve other parts of the organization. Plus, it occasionally produces surprising, Move 37-like designs that alert human engineers to new possibilities.

Neural Concept has even found a niche in Formula 1 racing, which I was surprised to learn actually limits the amount of compute that teams can use for aerodynamic optimization from one race week to the next. The bottom line is that we can add engineering to a long list of domains where essentially the same pattern of AI development is working over and over again. What once could only be done manually in the physical world was first digitized and then dramatically accelerated with specialist models. Today, agentic workflows are accelerating things further, and Neural Concept is beginning to evolve from training models on a per-customer basis toward a future of more general-purpose foundation models for engineering.

All of which makes it pretty easy for me to imagine a future engineering superintelligence that combines general-purpose design skills with these superhuman intuitions, all in the same set of weights. As we reach that point, and probably even before, we can expect faster and faster product cycles and an explosion of new form factors, all with higher quality and better resource efficiency than we've ever experienced before. If you've ever felt that promises of AI abundance were a bit too hand-wavy or detached from physical reality, I think this episode should serve to inspire you.

Thomas von Tschammer, co-founder and US managing director of Neural Concept, welcome to The Cognitive Revolution.

Thanks very much. Thanks for hosting.

I'm excited for this. We have not done much on AI for engineering on this feed, and with 350 episodes under our belts, that's probably a bit of a miss, especially because I'm sitting here in Detroit, Michigan, where I know you have some customers and where there is a long tradition of engineering physical products for the physical world.

My dad actually—fun fact—worked at GM. He started back when drafting was still done with pencil and paper, on big tables, with slide rules and stuff like that. Then he moved into the CAD era, and now he's retired, so he's not going to be working through the AI-assisted, increasingly AI-automated era. But I'm still very excited to pick up the thread where I left off with him on Take Your Kid to Work Day years ago and fast-forward to where we are now.

With that in mind, folks who listen to this feed are very into AI, and there are certain concepts that we don't need to introduce. But I think we probably can't assume common knowledge in terms of what the life of an engineer—or the life of a Neural Concept user—looks like. If you go watch over their shoulder and see them at work for a representative sampling of their working life, maybe you could give us a brief sense of how things get designed, who's doing that, and what the key skills and iteration loops look like before AI. Then we'll obviously add that AI layer to our understanding.

I can start with the example of the automotive industry. GM is a good example. We've been designing cars essentially the same way for the past 40 years.

Forty years ago, before CAD, which is computer-aided design, when you wanted to design a new car, you were essentially building a prototype and crashing that prototype against a wall, making sure that the pedestrian or the passengers were safe inside the car. If not, you'd have to change the design and then build a new prototype. This was a very lengthy process, which means that, ultimately, you couldn't explore 5 or 10 prototypes a year if you wanted one to go to production.

Then, about 30 or 40 years ago—as I said, 40 years ago now—we moved into computer-aided design. This meant that we could build new designs directly on the computer. Instead of crashing the car in real life against a wall, we could simulate, through what's called numerical simulations, the effect of that car crashing against the wall directly on the computer.

We use FEA software—finite-element analysis software—that predicts and simulates the effect of the crash. Since you don't have to build as many prototypes, you could explore 50 or 100 different car designs a year, which is a substantial increase in speed. However, these tools remain very complex to use and very expensive.

A single crash simulation can take days to run because we're solving the equations of physics on the computer. You typically need very large clusters, and then you need to wait as an engineer for several days, maybe 1 or 2 days, to get that result out. That is still the main bottleneck today when you want to iterate on your design.

There have been improvements, of course, in the algorithms and compute that we have, so we can speed that up. But essentially, for the past 30 years, we've been using the same CAD tools and the same FEA numerical-simulation solvers. That's true for crash testing, but it's the same for aerodynamics, thermal management, and every single physics simulation that you need when you build a car.

Now, using AI, we're seeing that same revolution. It went from paper to CAD and now from numerical solvers to AI. Thanks to AI, you don't get results in days; you get them in minutes. If you get results in minutes, it means that you don't explore 60 or 100 designs a year, but thousands of different options. That drastically accelerates your development cycles. It also means that you, as an engineer, can innovate much further because you have more options to explore thanks to these AIs.

That is a real echo of a pattern that I see across all kinds of different spaces right now, where there's this ability for models to learn a sort of intuitive physics, as I sometimes call it. Maybe most famously in protein folding, where you've had a similarly hard time in the past either doing crystallography to eventually get to a protein structure or doing really compute-intensive simulation to get there.

And now, somehow, with enough data and the magic of learning, we can take a couple of orders of magnitude out of the compute that's required. That just changes the game in terms of how many designs we can explore.

That pattern, I think, is fairly familiar. What I realize I don't have a great intuition for is: What are the different flavors of intuitive physics that we need to get models to learn in order to accelerate the different subdomains of engineering? You alluded to one a little bit with aerodynamics, and I know that'll be prominent on the list. But how many different things are there like this, and what are the unlocks? What are the fields to which they apply? What are the unlocks associated with them, and what has Neural Concept's role been in building these models?

Yeah, great question. There are many different domains, as you can imagine. Think about the complexity of a car. Today, in the industry, GM or another OEM is simulating the entire car when developing it, which means that every single component or subassembly within the car is being simulated, evaluated, and iterated on.

That means that, as engineers, we are evaluating many different physics on the car. Aerodynamics is one. It's specifically critical for EVs, for the range and improving the range on your next EV. Crash safety for pedestrians and passengers is another big one. Then you also have thermal management when you want to cool the batteries, cool the engine, and also for ventilation systems inside the car. Electromagnetism is important when you want to build the next generation of electric motors. There is a big electromagnetism aspect to it, and then structural dynamics, generally speaking, for the car: durability of the chassis on different road profiles, and so on and so forth.

Those are the big domains, essentially. Then, as you can imagine, this is divided into components and subassemblies. Ultimately, with a company like GM, you have thousands and thousands of engineers who are domain experts in these physics and these components, so that they can iterate on and improve each of these specific simulators.

Are all those different domains that you laid out now powered by a domain-specialist model that has learned, for example, the intuitive physics of heat dissipation through a ventilation system? If we just take that one example, if the old version was actually having a simulation down to the level of molecules of air blowing through a space, how they bounce off of each other, and what ultimately happens, what level of abstraction—or sort of intuitive physics—are we now able to get?

How do we say to this specialized model, “Here's a new design for a ventilation system. Tell us what you predict is going to happen”? What kind of inputs and outputs do those models look like? Are they trained on simulation data, too? That's another thing that I've noticed is a real pattern.

To your last question, these models can be trained both on simulation data and on test data—experimental data. Today, there are some phenomena that we are not able to simulate very accurately with traditional solvers. In that case, if we cannot simulate them, we can measure them in a wind tunnel or in test loops, and we can gather data and then train the corresponding models.

20% of the positive 0% of the negative. Hybrid training, essentially, is where you combine numerical simulation—which can be low-fidelity because we're not capturing the physics very well—with measurements.

Now, to your question before, how far have we gone into that space? To be very clear, today we are not fully replacing numerical simulation, in the same way that we never fully replaced prototypes. We are still doing prototypes today in the industry, but we're doing much fewer prototypes and much later in the process.

It's going to be the same for numerical simulation. We are not going to fully replace numerical simulations, but we're going to make much smarter use of them for the most mature stages of development. It's going to be exactly the same with AI. AI's role in the development process is to enable you, as an engineer, to explore a much richer space, explore the right candidates, and then narrow down the ones that you actually want to simulate to validate the winning prototype.

What we're saying today is that there is not yet one specific, accurate foundational model that can be used to solve the aerodynamics on every car. There is research going in that direction, and we are at the forefront of it at Neural Concept. However, it is not yet able to capture the level of fidelity that every car OEM would need to be able to deploy it off the shelf.

What does that mean? That means that we are retraining and training the models on company-specific data and numerical simulations.

So, the way that you interact with customers, if I understand that correctly, is that models are typically trained from scratch on a per-customer basis because they're sitting on top of a bunch of the simulation data and some real-world test data. It's like, “It would be great to take a couple of orders of magnitude out of this as we explore the optimization space around the core decisions that we've already made.”

We can't jump from a sedan to a Cybertruck, perhaps, with the models that we have available. But once we're in the zone and we kind of know where we're going to end up, we can refine dramatically faster because we're able to train these models on all this existing data. This is sort of the iterative development; it's really dialing things in at the end.

Think about data as knowledge. You can—and we also provide, for some specific applications, pretrained models that were trained from existing data elsewhere. But today, we need to fine-tune these models with the company-specific data because they have their own know-how and best practices, and you want them all to match exactly their requirements.

What's very interesting as well is that these models are always evolving over time. Every time you feed them new data, they are retrained and improved so that they can cover a broader and better space, and they become more and more accurate.

It's also a way for the company to retain knowledge and know-how. Every single data point that they generate is knowledge that's being captured by the model and reused, so that the next development cycle can be even faster and better.

So now, the other sort of complementary AI that's starting to get introduced at the same time is—I think everything we've said so far is more around the validation side. You could imagine a human sitting there, and maybe you can tell me some of the shortcuts that already exist before we get to the sort of AI copilot or engineer.

You can imagine a person sitting there. I have this vision of my dad doing this years ago, drawing these little shapes in three-dimensional space and manipulating points in the point cloud. It was that human intelligence that would say, “Okay, here's the test result I just got. Here's the spot where we're having some aerodynamic problems. Let me go back in there and tweak the design a little bit, sand that rough edge down a little bit.”

Now, of course, I've got these other constraints, too, that I've got to keep in mind. I've developed a certain intuition for how I can make these changes without breaking other constraints that are really binding on me. As I develop this system, now I'll make those changes. How manual those changes were—they were quite manual, and I watched my dad do it.

Again, you can tell me some of the shortcuts, but then they go back into the solver, right? The new big thing, of course, is that the AIs are also coming to full iteration cycles. I want to hear, too, about how the experience is changing for engineers with the AI copilot. How automated is it starting to get, and how automated is it likely to get in the not-so-distant future?

Yeah, very good points. On the metrics, I can give you a few examples. The first one is Jaguar Land Rover, or JLR, an automotive OEM based in the UK. They published their work with us at the latest NVIDIA GTC conference, which was back in March this year.

They’re using AI for all their external-aerodynamics workflows. As I was mentioning earlier, a couple of years ago, they were using computational solvers, and for every new design, they were going through this very expensive solver, which is time-consuming. They had already highly parallelized and highly optimized this stream, and they got to about 50 designs evaluated every day.

So, that was 50 designs and iterations between the studio teams, which are responsible for the aesthetics and design of the car, and the aerodynamicists. At the end of the day, it is a trade-off between the best-looking car and the most aerodynamic car, because you want to improve range.

With AI—and that was what the company did a couple of months ago—they went from 50 designs evaluated per day to 1,500, every single day in production. So, you can imagine the level of speedup that it brought to them. We have other suppliers as well that are designing metal pieces to cool the battery, and they were able to reduce their development cycles by 80%. They can develop a new metal piece 80% faster.

On top of shorter design cycles, they could get better performance. If you can explore many more designs, it also means that you can innovate. You can find new options that you could not think of before as an engineer because you just rely on intuition. We see examples where the component is cooling 20% better on the battery and is 15% lighter. If you think about aerodynamics, I’m pretty sure it also helped engineers find designs that are 2%, 3%, or 5% more aerodynamic, which is game-changing for them.

Yeah, so let’s dig into that last point. How is that happening? Again, to map this onto a space I’ve studied in a little more depth, there are protein-generation models now, right? They allow us to go beyond a biologist’s ability to say, “There are a couple of other proteins in the protein bank that are similar to this that I can pull in,” or, “I have a little intuition of my own.”

Now we’ve got models just throwing out new designs, which can then be evaluated. Where are we on this sort of language-assistant-with-tool-calling paradigm for intuition-driven design? You could imagine a language framework. You could imagine a version that’s just, “Here are your constraints. Here’s the point cloud. Here’s the feedback that we got. Generate a new point cloud,” and you could just go point cloud to point cloud. Where are we on those relative paradigms, and how are they starting to converge?

Yes. Today, what we’ve seen is that these AI-driven engineering workflows are not a black box. They are an assistant to the engineer, so that the engineer can take the right data and form design decisions. We are not in a world where we’re just sending a spec sheet to the AI and expecting the AI to get back to us as a black box with the best-in-class car.

We are rather in workflows where the AI ingests the spec sheet, understands the requirements, and we set up the base model. But this is done in interaction with the engineer, who will validate steps along the way and will also guide the model. Why is that? Because engineering is a very complex space where you never have one single answer. It’s always trade-offs between disciplines, between costs, between design, and between performance. You want to have these domain experts in the loop who can ultimately make the right trade-off decisions.

Essentially, we’re moving from the world where, as you were saying with your dad, in the past you were relying on intuition: “My design doesn’t work, but I think if I tweak it that way manually, it will work out.” Now we’re moving to a world where the AI is providing a space of solutions and options to the engineer. The engineer will explore that space and decide which design they want to move forward with.

What is very interesting in that process is that the AI is able to interact with the different tools. We talked about CAD, so now the AI is able to interact with CAD and send new geometries. It’s able to interact with numerical-simulation solvers: “I want to validate this design I came up with,” and send that directly to the high-fidelity simulation solvers. All of that becomes automated.

So, what models are you serving as the copilots for engineers today? We’re talking on Fable+1, and we’re seeing all these incredible projects that people are just vibe-coding their way to, where 3D landscapes are becoming extremely elaborate. The models are just generating them.

It sure seems like there have been some important thresholds crossed in terms of the models’ ability to reason physically and use physics engines and things like that. I would expect, on some level, that Mythos-class models are pretty good at just sitting down, so to speak, and using a CAD product. That sort of performance is probably pretty hard to find aside from one other provider.

But I also think the loop that you want to create is probably one where you can start to train based on the feedback of these validators, which have been the crown jewels of the system so far, and which, as you pointed out, embody the company’s know-how. What does that look like? How much are we going to be relying on a few frontier models to assist our engineers? How much do you think you’re going to start to see this loop get closed and create other specialist models that play that role instead?

Yeah, they’re great questions. If you think about what’s happening, Jensen mentioned that at GTC: You see AI today as a five-layer cake, from the foundation to the top, and the very top layer is the application layer, which he explains as being the most important one.

Today, in the industry, there are many, many companies specializing in building that application layer for a specific application. Essentially, they’re taking generic LLMs and turning them into application models, then bringing in the right domain-specific skills and capabilities so that these models can have value in very complex environments.

This is exactly what we’re doing in engineering. We leverage the standard, generic models that are out there, but we give them the right set of tools. They can work with CAD and geometry, and they can generate geometries. They have a set of skills so that they have the context about what it really means to generate a geometry, what the injection-molding design requirements are if I want to do a mold, and what I need to optimize for the right context.

If you just take a plain LLM today, you will not be able to go very far because it doesn’t have very accurate 3D-modeling capabilities. These models are becoming more and more realistic for video rendering, for example, but they are nowhere close to solving actual fluid-dynamics equations for external aerodynamics. There is a big gap to bridge here, and that’s what we’re doing at Neural Concept.

But it sounds like you’re expecting reasoning to be mostly provided by frontier models for the foreseeable future. The paradigm you think is winning is increasingly capable general-purpose reasoners equipped with the right tools.

Exactly. Equipped with the right tools, I think, is the important part, where these models are able to interact again with CAD and numerical-simulation solvers.

But we also have other kinds of models. If you take a step back and look at how, historically, we started at Neural Concept, we started in 2019 by building the first AI model architecture based originally on computer vision that could directly ingest 3D geometries and learn from physics. That’s how we started. It was not an LLM back then; it was a different kind of architecture.

These models could learn and directly take a CAD geometry as input, then predict aerodynamics, deformation, temperature, and so on and so forth. These are also models that you want as part of your workflow. You want the agents to be able to call these specialized, physics-aware models so that you can actually speed up the overall design process.

It would be helpful to do a comparison to software. I think the audience is super diverse, but one common profile is the AI engineer or software engineer who’s now doing increasingly everything with AI, both in terms of writing the code and in terms of the products they’re building, which are increasingly AI-ified.

It seems like we’re hitting this point where, if you can specify what you want in a clear and accurate way, for an astonishingly large set of things that people might want, the AIs can just deliver that for you now. They’re also getting pretty good at flagging the areas where you were ambiguous and might need to help them make a decision.

It’s putting the premium, of course, on the spec and on clear thinking about what it is that we actually want. I guess I don’t really know. My intuition in engineering would be that these specs are typically better than they are in software.

I would imagine that there’s a more disciplined process culture around saying exactly what we really need, because we know that there are, first of all, hard realities around things like heat dissipation and strength that we literally have to have. Whereas in software, we figure we’ll patch that on the fly later if it’s not scaling the way it needs to, or something is literally breaking. We have the ability to reach in and fix that even if we’re in production. Obviously, not so with a car.

Am I right that there are much better specs, and does that put models in a really disadvantaged position? Or are there ways in which specs are still not so well specified as the naïve person might think, and we’re relying on a sort of human fuzziness to unpack them such that they remain difficult for AIs in some ways?

Good question again. If you’re an automotive supplier or OEM today, it’s more than that, right? There are specific RFQs, as they call them—requests for quotation and specifications—and they’re still not fully streamlined, automated, or defined. There are standards and specs that OEMs are trying to impose, but there is always human interpretation, especially when, for example, we speak about a car, which is such a complex problem with an infinite number of dimensions and constraints.

Imagine that if you change the thickness of a single component somewhere under the hood, this might impact the overall engine load. You have a lot of constraints that are tied together, which means that ultimately it’s not as deterministic as one might think. That’s why the total problem is also extremely complex to solve.

Starting from a set of specs that the model can read and then translate into 3D, this is exactly what’s happening today already. However, the reason it’s not yet as black-boxed as it can be for software engineering is because the dimension of the problem is much, much richer. You have many more trade-offs you need to make, and there’s never one way to get to a solution.

That’s why it’s not going to replace engineers anytime soon, but it’s going to empower them to be faster. It’s going to remove the low-value-added tasks. That’s for sure; that’s already happening, right? The engineer needs to manually set up a new simulation, manually run the CAD, and draw a new design. This is being eliminated as we speak, but it’s never going to replace the engineer making those design decisions.

Are you sure? What does that look like there when it comes to sitting down and thinking about what would be a good product in the market, even if it’s something as high-level as that? Models are getting pretty good. Then there are all these steps from the sort of initial ideation to breaking things out into subsystems, thinking about the constraints that each of those has to have, and then throwing these things into actual 3D representations in these systems and setting up all the simulations.

I’m increasingly struggling to find the place in that whole sequence of events where I’m saying, “Here are the ones that the AIs can’t do.” I think there are some things we may not want them to do, or we may want to hold on to final judgment and final calls, all that kind of stuff. But leaving aside what we want to hold on to, it doesn’t feel like it’s so far off that you could have a little society of Fables pick up where the humans left off and literally get to the next model year of a car.

If that’s crazy, why do you think that’s crazy? What is the part that we’re so far off on?

I don’t know. You have a good point. All of these tasks today, I strongly believe, can and should be automated with the models and capabilities that we have. These models have the capability to translate any specification into a design and then simulate that design automatically using numerical solvers. All of that can already be automated today through agents, and that’s what we’re doing as a company.

Where I believe there is another level of complexity is in the dimension of the problem. This is being done today for specific products: battery cold plates, e-motors, aerodynamics, crash, and so on. Where I don’t believe this will become a black box is when you add all the dimensions you want to have for a car.

Because then that’s where you really want engineers to weigh in, and engineers need to hold on to that. I believe you will always want engineers to hold on to the final trade-offs and the final decisions, because that’s where you need the domain expertise deeply ingrained. That’s also where the differentiators happen between you and a competitor.

How will differentiation happen tomorrow between OEM 1 and OEM 2? It’s going to be the companies that are able to deeply ingrain their engineering know-how into these AI workflows. That’s going to be key. That’s what I think companies are realizing.

Yeah, that’s fascinating. I’ll start with the question about the alignment of your business model with the role of the human. I assume that over time you’ve probably had some sort of seat-based pricing there, and potentially also a sort of compute-based pricing for simulation execution. I’d be interested to know where you’ve been on that historically. As we go forward, do you think you can sustain a seat-based model, or is the model going to have to move in another direction?

I think, essentially, we’d have to be based on value, right? What’s the value we’re providing? That’s really your price, essentially—the price for the value, right? The question is, how do you monitor value? I think it depends on the industry and the applications, but ultimately we’re going to move to a world where pricing is based purely on the value you’re able to deliver for companies.

I think that’s actually very healthy. That’s what you want to have. The value is not going to be tied to an individual or a seat anymore, but potentially to agents. Pricing will evolve accordingly, and I think it’s going to be the same for every company.

How much disruption do you expect to see in these 100-year-old industries like auto, where obviously companies have changed a lot, but it’s largely companies that were formed 80–100 years ago that have consolidated? There’s certainly been an only-the-strong-survive dynamic, but there haven’t been too many new entrants recently, right? A couple.

When you think about what matters most being figuring out a distinctive way to encode your know-how into an AI flywheel process, especially one that might even enter into its own kind of recursive self-improvement loop, I just talked to some OpenAI forward-deployed engineers last week who are doing this for tax. The pace with which they’re able to convert feedback from a tax professional on something the AI did wrong into an improved scaffold that prevents that error from happening next time is so fast right now that they’re really rapidly climbing the hill in their case of accuracy of tax-preparation documents.

Do you think there’s something fundamentally different about manufacturing that would make those hills really hard to climb? Or if you’re good at climbing those hills, is this a moment where you actually think we could see new entrants come into the market and rival the incumbents?

For sure. I think it’s going to be a massive disruption in the market, and I think it’s going to create exponential gaps between the companies that are able to adopt these AI-driven engines and the ones that are not. The gap is going to widen over the next few years, for sure. There’s going to be a lot of disruption.

What is difficult for companies, if you think about traditional OEMs, is that they’ve been building cars essentially the same way for the past 20 years: same teams, same tools, same know-how. You’re asking engineers who have worked the same way for a long time to change their way of thinking and even the governance of the whole company. Some are embracing it faster than others, and our role is to make sure that we can support them in that journey—show them how others are doing it, what the best practices are, and walk them through the process.

I also believe that there is an opportunity today for a company that is building hardware to come in and move fast. We talk a lot about these digital-native companies, and we work with many of those outside of automotive. They’re building electric products and consumer-electronics products. Those companies have been building hardware for at most 10 years, and you feel that they’re able to pick up these new workflows much faster.

What do I mean by that? I mean that in a year, they’ve had a massive impact in scaling up their product-development process across many applications. We’re seeing this happen at a slower pace in the larger, older engineering companies out there.

Yeah, that’s been the story of Detroit for quite a while. Companies came up, got so big and so powerful, and had such market dominance that they forgot they might need to evolve. They’ve come a long way since then, but that’s a 50-year-old phenomenon. They’re now going to be faced, I think, with their most profound challenge ever.

Competing with Japanese companies in the 1970s and 1980s is potentially going to be easy mode compared to competing with AI-native companies if things go a certain way.

So, it’s going to be really interesting to watch the organizational dynamics and challenges of that.

And if you think about it, to develop a car for a Western European or U.S. OEM, it takes between 48 and 60 months. From the moment they want to launch it to the actual moment it hits the plant and is being manufactured, right? In China, it’s 18 to 24 months. Everything those companies in the U.S. and Europe care about is: How do we get from 48 to 24 months? Because that’s what’s going to create the next competitive advantage for them.

Yeah, that’s a sobering stat. I’m not quite sure how to phrase this question, but one thing I wonder about is whether, if we really super-optimize the design process, we might end up making things really hard on manufacturing, at least in a naive way.

Going back to the start of my dad’s career, there was literally pencil on paper and annotation of, “It should be this much,” right? And the tolerances that existed on the machining side were just a lot more generous than I think they are today. I think maybe you can imagine, again, if the design gets so optimized and we’re really satisfying these constraints down to the absolute maximum in our designs, it sounds like that would create really super-tight tolerances and really super-difficult manufacturing challenges.

So how do you think about—I guess maybe one answer is this is the role for the human engineer, but let’s not satisfy ourselves with that answer—how should we be thinking about just how far we want to push design optimization and when we need to meet manufacturing a little bit more in the middle?

It’s a good question. So, when we’re saying that we want to optimize designs, we also want to optimize them for manufacturing, right? What do you mean by that? That means that when I’m saying that building a car is a multidisciplinary and multi-objective optimization, I also mean that you want to incorporate design rules and manufacturing constraints as early as possible into your design iterations, right?

Because that was the promise of additive manufacturing 15 years ago, right? That you could design freely, but then you could print anything, right? But then we quickly realized that this would not work out because it’s expensive and it doesn’t scale in production.

So now, let’s say you have a manufacturing plant and you have your stamping process. You know what the manufacturing constraints are; you know what you can and cannot do with stamping. So what you want to make sure of is that those design rules and manufacturing rules are embedded and available for the AI model to consider as soon as possible.

So whenever the model evaluates and explores the design, it explores it knowing that it can be manufactured, right? And that’s a lot of the work that we’re doing as well. We are embedding within the model this know-how to make sure that every single design we explore and generate is valid for manufacturing at no extra cost. So embedding the physics and also the cost along the way is what you want to bring earlier into the design process.

If you had to break down the dynamics or realities that give the Chinese companies such an advantage in iteration time, how much of it would you say is on the design side, and how much is on the manufacturing speed side? Obviously, those things can’t be fully decoupled. Hopefully, you get a sense of what I’m getting at.

Are they doing their design a lot faster in China, or are they getting from the point where they have a design that they like to actually rolling a line dramatically faster? My sense is it’s a little bit more of the latter, probably, but I’m not really sure how to think about what is contributing to that huge advantage.

Yeah. So, I agree with you. I tend to think it’s more the latter, right? They are much more agile when it comes to rolling out the new plants. Also, the way the plant is being operated, right? It is highly, highly automated there.

I mean, now you have engineering executives from Europe and the U.S. traveling to China to understand how they are operating the plants, taking lessons from them, and then going back and applying those best practices in their countries. This is happening already today, right? So, that’s a fact, for sure.

On the design side, I think the benefit that they have is that they can take more risks because, again, they don’t have that legacy to work with, right? Legacy processes or tools. They can just pick what’s best out there today, not what was best yesterday. That’s a big differentiator, right?

So, I do believe they work with best-in-class tools, for sure. They’re able to take more risks, again, because they don’t have that industrial history of developments, and they have fewer processes that aren’t deeply ingrained, right? If you don’t have processes that were built in the 2000s, it’s much easier to work in a much more agile way today. And then we’re going back to the digital-native type of companies that are able to pick up new standards much more quickly.

We, the quote-unquote West, have our work cut out for us, it sounds like. How big of a deal is it going to be for Neural Concept to move from the one-model-per-company, based-on-their-data paradigm to a more foundation-model-type paradigm?

Foundation models obviously could come with varying breadth, right? But simply going from one aerodynamic model per company to a general-purpose aerodynamic model that would allow you to be like, “What if we did a Cybertruck?” I could move from your historical product line to something quite different. It seems like it would be a huge value unlock.

Then you could also imagine going even more multimodal, right? I say this all the time, so I apologize to listeners, but the integration that we see between language and pixels coming out of the Nano Banana–Omni sort of line really does show me that integrating quite different data modalities into the same model is a superpowerful thing to do.

And then there’s another version of the foundation model, which is: All these constraints—generate me the design in the first place, as opposed to the validation side, which I was speaking about before. How would you describe your strategy on that? How big of a deal is that? How soon do you think we will get there? I assume it’s got to be inevitable on some level. What’s your strategy to bootstrap into those things?

Yeah, yeah. So, you’re right, it’s going to happen, right? It’s moving extremely fast already. We are going to have a foundational model for aerodynamics. I think it’s going to start with aerodynamics, right? This is the low-hanging fruit today because, even though the physics are complex, they’re relatively similar across companies, right? It can be relatively easily replicated. So, it’s going to happen very quickly, right?

Of course, it’s a very big deal for us, right? So, we’re actually doing research in that direction. However, we may not be the first ones to have that foundational model, right? But then, as I’m going back to Jensen’s 5 million use cases of AI, our role and our sole focus is to make sure that, whatever the foundational model is, we provide the right domain-specific capabilities so that it can be fully integrated into a complex engineering environment in a 100,000-person organization, right?

So that you can visualize your designs, tweak the geometry as well, leveraging those foundational models, and so on and so forth. So this is also our role and what we are already building toward, so that when the foundational capabilities arrive, everyone will be ready for it as a team.

One thing I learned in researching Neural Concept that I thought was super interesting is that you guys are serving, in addition to a bunch of enterprise customers, a number of Formula 1 teams. I’ve honestly never really been super into motorsports or engineering sports. But it does strike me that, in the run-up to a country of geniuses in a data center, we really do stand to learn a lot from highly competitive and performance-oriented organizations like Formula 1 teams that are under just this incredible pressure to turn things around quickly, right?

What does that look like right now? And another interesting detail was that, apparently, Formula 1 teams have an explicit rule—it’s one of the big rules that they work under—that they can only spend so much compute on aerodynamic simulation. That was a real surprise to learn. Is that just to prevent an arms race?

There might be something for our AI governance listeners to learn from Formula 1 as well, but what do you think we should be learning from the Formula 1 users? What have we seen? What should we be learning from them?

Yeah, I mean, that’s super interesting, right? So, indeed, today Formula 1 teams are capped, to be more specific, in the CPU hours that they can run. CPU hours are the compute required to run external aerodynamic simulations, right?

And what’s even more interesting is that, depending on your ranking from the previous year, you don’t get the same number of hours for the next season. The idea is that you want to try and make it more equal across teams, right? And you don’t want to make it a race as to, “Okay, the biggest budget, the biggest compute, so I just win,” essentially.

So then they’re trying to equalize that in some way.

Wow.

A race as to, “Okay, the biggest budget, the biggest compute, so I just win,” essentially. So then they’re trying to equalize that in some way.

So they handicap, essentially. If you win, you get less compute and you have a harder schedule.

Basically.

Yeah.

And because you cannot compute—

The NFL does this: if you’re in first place, you have to play a first-place schedule. The NBA does this. They’re now changing it because people have been tanking to try to get better draft picks. But I’d never heard of this level of actually changing not just the talent-acquisition process or who the opponents are going to be, but the fundamental rules of the game itself in terms of how you’re allowed to prepare from one race to the next. That’s really interesting.

Is it technology that can tie the compute simulations being run to performance? Because if you can run more simulations, as an engineer, you can explore more designs and improve your car further. That’s what you want in Formula 1, right? You want to get the best car out there for the next race. So that’s the way to balance the development between different teams, actually. That’s super interesting.

So what are we seeing in terms of their cultures and practices that you think will diffuse into broader engineering and, ultimately, manufacturing culture?

If you think about it, Formula 1 engineers are the state of the art of engineering—the most agile teams you can think of. The design of the car is changing between every single race, right? From one week to another, you don’t see it because it’s very fine details, but the car is actually different. They’re improving it week over week.

That means that they have to reach an extreme level of automation of the design-iteration process in this industry. We’ve seen Formula 1 teams embody what every single OEM is trying to tend toward, trying to emulate the way they work, the way they iterate, and the way they make design decisions. It’s a good way for us, essentially, to put our models, our workflows, and our platform to the test and stress-test them.

If it works for an F1 team, we can benefit from that, and then it can work for the more traditional OEMs out there, essentially. That’s really the way we see it, and we’re asking those teams to really push the limits of the models and the workflows to break things, essentially, because that’s where we see the breakpoints, and that shows us where we have to focus and what we have to do there.

Maybe we can make a little bit of an analogy to software, where we have the token maxers who are trying to really push the limits of what their agents can do for them and are increasingly not writing code anymore. Of course, there are a lot of places where we haven’t quite caught up, so we’re maybe still writing code the old-fashioned way or doing a little autocomplete or whatever that’s useful and gives us a little speedup. But it’s still in the old paradigm versus a genuinely new, higher level of abstraction as the base place where a human spends their time and operates.

Could you paint a little bit of a picture for the analogue in engineering? What does the F1 person do when they’re token maxing? What are these moments of key decision or judgment on particular trade-offs that actually rise to their level? I think we kind of know what the old-school one looks like. So what does the token-maxing F1 engineer’s life look like today?

They would get the key list and look at the next race profile, right? If it has more turns than the previous one, they would associate that with a list of requirements for what needs to improve on the car. They might say, “Hey, we need to make the car better in straight lines for the next race. We have many more straight lines, and we know we’re going to have to overtake this one.” That’s the baseline.

Then they translate that into engineering requirements, decide how the car can improve, and analyze the car. They would write these AI-driven workflows that take those aerodynamic requirements and have information about the geometry and the scene. Overnight, the AI-driven workflow will generate 100,000 configurations of design options, and we evaluate them. We evaluate the corresponding aerodynamic performance.

The following morning, the engineer and the aerodynamicist will have an interactive dashboard and report. They’ll see thousands of data points on the dashboard, look at the different trade-offs and the corresponding designs, and pick the one they want to move forward with for the next race, which is next Saturday. So token maxing is essentially thousands or tens of thousands of designs being explored and evaluated overnight, fully automated by these AIs.

Have we seen any surprises come out of that process? Of course, there’s the legendary Move 37. It seems like, increasingly, with the Mythos-class Fable models, we’re starting to see Move 37s, which might be strange, but they’re definitely stepping outside.

I had a really interesting experience yesterday when I ran a skill that’s a very familiar workflow. Fable stepped outside of the workflow and proactively asked me a bunch of questions. It actually presented a web page to me to collect information. I hadn’t instructed it to do that, and it had never been part of the process before.

Opus never did anything like that, but Fable took it upon itself to say, “I’ve got all these inputs, but I think I could use some more inputs to really do a great job, and here’s what I need from you, the human, to really knock this out of the park.” It was like a little mini Move 37. I’ve probably done this workflow 50 times over the last few months, and nothing like that had ever happened. What’s the most Move 37-like thing that we’re seeing in engineering?

We have very similar analogies, and I think, to be fair, it’s one of the favorite parts of the job. That’s where it becomes very exciting. We have engineers who are using these workflows—using AI to explore and asking the AI to explore 100,000 configurations overnight.

When they come in the morning, they look at the results, and then they get back to us and tell us, “Hey, very impressive. The AI model came up with a design that I would never have thought would be good. If you had shown me this design, I would have said, ‘Hey, scrap this. This is not going to work.’” But actually, those designs are better than anything we could come up with.

Then I need to get back to the dashboard to understand why it’s so much better. I need to rethink my intuition because I didn’t think it could be that good as a design. You learn as well from these models. Again, because they explore this much richer space, they go out of bounds and beyond your intuition.

You may notice it, too, I think. That’s where it becomes super interesting, because something really clicks with engineers. They become very excited because they understand that they can also learn from the model. “I didn’t get it. How can I learn from it?” It explored new physics or new phenomena that I wasn’t aware of when I was only working with intuition, essentially. So there’s also that.

Is it possible that even trying to reverse-engineer the designs themselves from the AI—

Learning from the AI’s advances and its occasional leapfrogs over us is definitely a really exciting, thrilling, slightly scary part of this new future.

Could you give us a little more intuition for just how radical these moments are? It may be a little hard for somebody not in the domain to really grok it, but I’d love to try to get a better sense. Are they really good optimizations, or are they really stepping out and exploring different regions of the design space that people haven’t explored?

I think what made Move 37 qualitatively so compelling was that no human would have made that move. Initially, I think the live-stream commentators thought it was a blunder, right? When we see these surprises in engineering, how big of a surprise are they?

Are we seeing, “That’s kind of interesting. I wonder if that could work”? Or is it, “That looks kind of crazy, but in defiance of all my intuitions, it actually does work”? Just help me calibrate how big those surprises are.

You remain grounded in physics, right? You will not bend the physics. That’s for sure. You will not get completely insane designs that break the physics, because everything is guided by physics.

However, we’ve seen scenarios where the engineer tells us, “Hey, there’s no way in the world that I would have done that design, because I didn’t think it could work.” But now that I know it works, I need to go back to the dashboard and understand why it does.

We have physics as a baseline, and we cannot break the physics. That’s going to be there. But we’ve seen occasions where engineers thought it was a mistake, thought it was a blunder, like Move 37. But it actually wasn’t, and it led them to rethink the way they were approaching the problem and their intuition around it.

Maybe another way to think about this is: how much is it worth? You talked about value pricing earlier, and there’s so much discourse right now around whether people are going to be willing to pay for Mythos-class models. Notably, the price originally previewed with Mythos has already come down a lot, with Fable being significantly less than that original Mythos preview price.

I’m not sure how often it’s the case that these insights are readily quantifiable in terms of money. It could be a little more efficient, which moves the needle on my range. I can say that now my car gets this many miles on a charge where it used to get only this many.

How much is that worth in the market? Obviously, that's a whole other question. So how are people assessing the value of this? Please speak to all aspects of it, including the smaller optimizations, but I'm really interested in these sort of move-the-needle or Move 37–like moments. How much value do people perceive in it? Are they able to measure it? Are they willing to pay?

Are we going to see people continue to run the Neural Concept engineering copilot with anything less than a Fable model, or is it going to be like, “No, you’ve got to pay for the best, because that’s where all the insights come from, and the bill is going through the roof, but we have no choice but to do that to stay competitive”? Where do you think we’re going to land in the short term on this willingness-to-pay question?

It’s a very good question. Again, it’s good to think about value. Value is key, and it’s a discussion we always have with the companies we work with.

Typically, when you think about a design breakthrough—much better performance than what you could get before—we have discussions with suppliers that sell to the big OEMs, the big car OEMs. There are some small aspects: if you can get a better design, it probably means that you’re much more competitive in the market. It probably means that you will win more projects and more programs with OEMs.

With such a small contract, if today, let’s assume you’re building cold plates to cool batteries, if you can win one more program per year, that’s millions, tens of millions of dollars. Just one more program in the B2B business that you’re winning every year—that’s a very tangible dollar value.

The other way to see it is, if I can get much faster to a good design—instead of taking me 6 months, it might take me 3 months—I can spend the other 3 months optimizing my manufacturing process to reduce the cost as much as possible, and I become even more competitive for my clients. This has indirect dollar value as well.

If your part is 10% cheaper than the competition because you spent 3 months working on the manufacturing process, tuning the details, then you win 1, 2, or 3 more programs that are then hundreds of millions of dollars. And then, if you go to the OEM side, if you can shrink your development times from 48 to 24 months, that’s also millions of dollars in savings for every car.

A car is typically $1 billion to develop from scratch. But if you can save even 20% of that, the math is pretty quick.

Yeah, there’s a lot of opportunity for savings in there. What do you think American car companies, to take one very salient example—or you could broaden it as well—should set as their critical milestones, their must-hit accomplishments with AI over the next 1 to 2 years?

We know that, on that timescale, OpenAI is planning to have a very large chunk of ML research itself automated. We know that we’re already iterating at half the speed of the Chinese companies. We see some hardware-manufacturing spaces where the product cycle has accelerated. Look no further than Nvidia for probably the most dramatic example of this.

Forget about what would initially get you a coffee spit-take and get you laughed out of the room if you said it. What do you think is the actual achievable speedup that you would, in your heart of hearts, tell the CEO of GM, “This is what you really need to be able to do in terms of speedup if you want to be meaningfully and durably competitive in the AI era”?

There are different ways, of course, to do this. In year one, they should be looking at some core departments and core areas: crash safety and dynamics, and powertrain, let’s say. You’d want to make sure that every single iteration is AI-enabled.

By AI-enabled, I mean there is an AI workflow that can handle all these trades in different tools. That’s the baseline, and that can already lead to a 20%, 30%, or 40% speedup in those flagship disciplines. That’s for year one.

Then, in year two and beyond, what you should be looking at is optimization across disciplines. You break the silos between crash, aerodynamics, and thermal, so that the engine can not only optimize the aerodynamics, but can optimize it while taking into consideration the safety aspects, the manufacturing aspects, and the ultimate design constraints, as we talked about before.

Once you do that, the gains really compound. The benefits really compound, and that’s where you can really break down and reduce the iteration cycles by 50% to 60%. That’s what we’re seeing already. Today, there isn’t an OEM that has done it at scale for an entire car, but we’re seeing these multidisciplinary, automated, AI-driven workflows happening already for some specific disciplines, and we’re seeing 60% speedup. That’s massive.

Yeah, interesting. How do people respond to it? My sense is that you probably won’t have a hard time convincing CEOs of these companies that this is really important. They can look again at the iteration speed of the Chinese companies, and they can look at Tesla’s ability to update its manufacturing processes much more dynamically than they’re accustomed to doing. I think increasingly they’re going to feel the heat.

Now, another question is translating that through a legacy organization, where probably a lot of people have a lot of different feelings about how they want it to go or whether they want it to happen at all. Many of those feelings are very understandable, by the way. I don’t mean to dismiss them, but they’re an obstacle, in many cases, to the company actually transforming in the way it probably needs to in order to be competitive.

How would you characterize the kinds of roles engineers have in that space? I’m thinking, for whatever reason, ML researchers are the most keen to automate their own labor. Then we see a lot of artists who are hostile to the technology—not all of them, certainly, but that’s a pretty common point of view. Especially if it’s, “I love doing this. Why do we want to automate something that I love doing?”

Where are engineers in that space?

It’s a good question. I think we do see both ends of the spectrum. Engineers are artists in a way. They have the intuition for how to build a car, and they really enjoy that aspect of manual iteration, leveraging intuition, and thinking about the physics of the problem.

There are many engineers who have been doing it the same way for the past 20 years, and they enjoy that. It’s understandable that when they see these types of new workflows, they’re sometimes a bit resistant to what we bring.

They also believe, rightly so, that they need to be in the loop, because ultimately they’re the domain experts and they’re the brains of the company. Otherwise, a GM car would be similar to a Ford, which would be similar to a Buick. You need to have that human aspect as well.

But we also see the other end of the spectrum. There are actually teams within those organizations that are at the forefront of these workflows. Those are the first ones to adopt them, and they’re the first ones who want to explore and try new AI models, benchmark them, and experiment.

So we really have both extremes within the same organization. How do you bring them together? That’s also part of the complexity of very large organizations.

The thing we’ve seen a lot, though, is that once you manage to break that barrier and actually have those engineers hands-on and working with the AI models, you see a totally different response. They understand how powerful it can be and how much it can empower them to make their jobs even better and more fun.

They don’t have to spend time on low-value-added work, setting up simulations and waiting for the simulation to load or compute. They can actually interactively query the AI model, get results, try different options, and try many more what-if scenarios. That’s the fun part when you’re an engineer. You want to try these things out. You want to test scenarios and test engines. That’s what AI enables you to do today.

You mentioned this idea of brands becoming the same and that they need to avoid that happening. This may be sacrilegious to say as a longtime native Detroiter, but I feel like there’s an awful lot of sameness out there in today’s world—manufactured products in general, and certainly cars. I’m always thinking, “Really? They look a lot alike.” Let’s be honest with ourselves: there’s been tremendous convergence.

Do you think we’re going to see—or is this maybe even a way to think about a success criterion for AI at a societal level—a new trend toward more meaningful differentiation?

I think what happened, and what I think is continuing to happen in the automotive industry, is also largely due to autonomous driving. There’s this big push toward autonomous cars, because essentially, once you’ve solved autonomous driving, a car becomes a commodity.

You don’t need to own a car anymore. If it can just drive you home and drop you anywhere you want, and you don’t need a driver, a car becoming a commodity means that, ultimately, cars would tend to look more the same—by definition, by pure definition.

However, before we get there, I do believe, in that sense, as I was saying before, that the winning companies are the ones that are going to be able to create the best product and brand within this AI world first. I’m convinced of that. That can lead to a widening of the gap between the companies that did not adopt AI quickly enough and the ones that did. Here, we will see massive differences.

People might be surprised by how taking the driver out of the car, so to speak, in a very literal way opens up all kinds of new form factors. It could be the small delivery car that doesn’t have any people at all. It could be sleepers that we get to overnight in on our way to grandmother’s house, whatever. Even though people have talked about that and imagined it for a while when they think about the self-driving-car world, it has felt like that is a long way off, even once the technology works, because we just haven’t seen much change.

Why would we expect to see all these form factors pop up from a bunch of car companies that have given us strikingly point-for-point similar product lines in recent decades? But this could be very different in a world where a tremendous amount of stuff becomes automated. Is there a bootstrap there that you think is interesting? One that does strike me is the idea of vehicles without passengers. It wouldn’t take much to perhaps create some slightly different regulations for those types of devices, and the next thing you know, you could really get a crazy flywheel going that then leaks out into the rest of the broader industry. How fast do you think that kind of stuff could happen?

I think the main reason for the phenomenon you’re mentioning is that today, most autonomous-driving cars are cars that you could drive, but they’re not meant to be autonomous. Because you need to drive them, they look like the ones we’re used to. That’s actually what’s happening with the Detroit companies: They use a standard car and then make it autonomous. If you’re given a standard car, you need to be able to drive it by regulation if you have an issue.

But there are still companies that are built as autonomous-first vehicles. If you think about Zoox, I guess you know about this company on the West Coast. I think their first tagline is that it’s not a car; it’s a robotaxi designed around you, if you could call it that correctly. They’ve built it with full autonomy in mind first, let’s say, and it doesn’t look like a car. Even if you think about it, it’s a different type of thing from anything we’ve seen. So, the more that the technology becomes mature, the bigger the shift is going to be to new types of concepts as well.

How far does this go? Is there any limit to it? I kind of imagine everything as an RL loop as the end state. You can imagine putting agents into every seat in the company. Keep in mind, we’re going to need some oversight for this, but in terms of thinking through a first-principles limit paradigm, you could have product strategies and virtual market testing.

There are increasingly capable models that, in the same general spirit as models that will validate the aerodynamics of your design, can act as virtual customer panels. You could imagine, from even the highest level, getting into a fast loop that’s fed by RL, where you have at least a sufficiently good reward model to steer it in the right direction. That can cascade all the way back, perhaps, to the designs themselves, where you can imagine a not-too-distant future in which I can speak a rather complicated mechanical-electromechanical product into existence in a way that I can now speak a video into existence. Do you see any fundamental gaps in that vision? What, if anything, would prevent that from happening in 5 years’ time?

No, no. I think the capability is out there. The main questions for big companies to implement that are infrastructure, governance, mostly, and data understanding. If you can get the data flows to the right locations, then in terms of capability, we have the right pieces of the puzzle. I strongly believe so, and it’s going to go even faster.

I would say that, with the latest foundation models that have been developed, I don’t see any reason for this not to happen. Again, you won’t break the physics; the physics will be there. That’s why we need to build tools that are grounded in physics. You talk to numerical simulation solvers, and they will be there and will remain there. They will be the source, essentially, for these models in engineering. But I don’t see any fundamental reasons not to, as long as you are quick and efficient.

Do you think humanoid robotics, or robotics more generally, is critical to this, especially for unlocking speed on the manufacturing side? I think there are a lot of different ways you could imagine unlocking more agility on the manufacturing side. How much do you think things like humanoids matter versus just general intelligence that will also design the machine tools and bring all the same engineering paradigms to them?

You can imagine a version built on this: If humanoid robots are the analogs of LLMs, that’s one way we get crazy responsiveness for manufacturing. But maybe another is that, again, the reasoning models bring all these same engineering paradigms to the machine tools themselves, and that is enough to speed things up.

I do believe that robots will actually be critical when we think about the manufacturing aspects in plants. Now, do I believe those need to be humanoid? I think that’s a different story. As humans, we’re optimized to do a lot of things. Are we optimized to be in plants? I’m not sure we’re the right form factor.

However, I think there are still some breakthroughs to be made for robots and humanoids to be actively useful at scale within plants. The first one is the AI models themselves. I do believe that we need much more advancement in the AI models so that those robots can actively interact with the physical world and be efficient. We are far from being there right now in the industry.

Then there is another question on the hardware side: the autonomy of these robots. How do you make sure they don’t overheat? Building a hand—I don’t know if you know it, but there’s a lot of research in universities on how to actually build a hand that is as agile as ours, that is not going to break, and that is durable. You need a lot of breakthroughs on the hardware side if we want them to be efficient at scale. It’s going to happen, but I think there is some work to be done in that area.

To try to put a little bit finer point on it, do you think that we will be fundamentally bottlenecked if we don’t have highly generalizable physical intelligence that can walk into a room, troubleshoot some random thing, and apply a wrench to something that, for a human mechanic, wouldn’t be so difficult? Obviously, robots really can’t do that very well yet. Do we have to solve that part, or can we, through sufficient intelligence, take a more top-down route to highly efficient automation that doesn’t require this general-purpose physical intelligence to be able to patch things?

Yeah, yeah, I think I agree. This is a second-order issue, and I would say that, with first principles, we can solve around these bottlenecks through more general automation and intelligence up front. The next frontier will be those robots in the plants, but I think, to your point, this is definitely the case.

The future of physical abundance—I think I’m feeling more bullish than perhaps I ever have. I really appreciate you taking the time to walk me through all this, and the contribution you guys are making at Neural Concept is definitely a fascinating one. Is there anything else that we haven’t talked about that you think I should have asked about? What blind spots would you detect in me that you could help me patch up before I let you get back to work today?

I think we’ve covered a good number of topics. Definitely, thanks a lot. One thing I can add is that, from the outside, I don’t think we realize how close we are and how it’s actually already happening in the engineering industry today. You have engineers and products that are being designed AI-first, and it’s true—it’s already there. The acceleration is just starting.

Look closely at the industries—automotive, aerospace and defense, and consumer electronics—for the next few years. Most likely, all the next breakthroughs in terms of designs, performance, and products will be led by, or will have an element of, AI-driven workflow innovations in them.