Evidence receipt / observation
Published · transcript-backedNathan Labenz: observation
1 Jul 2026 The Cognitive Revolution 1000 Designs a Day: Neural Concept's Thomas von Tschammer on AI-Native Engineering
“I think audience is super diverse, but one common profile is the sort of AI engineer, software engineer who's now doing increasingly everything with AI, both in terms of writing the code, but also the products that they're building are increasingly AI-ified.”
Source trail
Everything needed to verify it.
- Speaker
- Nathan Labenz
- Attribution
- Verified speaker
- Claim type
- observation
- Recorded
- 1 Jul 2026
- Publisher
- The Cognitive Revolution
Transcript context
…Exactly. Equipped with the right tools, I think, is the important part where these models are able, again, to interact with CAD, but with also other class of models, right? If we take a step back and we look at our history, how did we start? We started in 2019 by building the first AI model architecture. based originally on computer vision that could directly ingest really geometries and learn from physics. This is how we started. It was not LLMs back then, it was a different type of architecture, but these models could learn and directly take as inputs a CAD geometry and then predicts aerodynamics, deformation, temperature, and so on and so forth, right? But these are also models that you want as part of your workflow, right? And you want the agents to be able to call the specialized physics-aware models so that you can actually speed up overall design process. So it would be helpful to do a little kind of comparison to software. I think audience is super diverse, but one common profile is the sort of AI engineer, software engineer who's now doing increasingly everything with AI, both in terms of writing the code, but also the products that they're building are increasingly AI-ified. And it seems like we're hitting this point where if you can specify what you want in a clear and accurate way for a really astonishingly large set of things that people might want, the AIs can just deliver that for you now. And they're also getting obviously pretty good at even flagging the areas where you were ambiguous and they might need your help to make a decision. So it's Putting the premium, of course, on the spec and the clear thinking about what it is that we actually want. I guess I don't really know. Intuition in engineering would be that these specs are like better typically 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 first of all are hard realities around things like heat dissipation and strength that we just literally have to have. Whereas in software, we kind of figure we'll patch that on the fly later if it's not scaling the way that it needs to. Something like literally breaking, we have the ability to kind of reach in and fix that, even if we're in production. Obviously not so with a car. So am I right that there is much better specs? And does that put models in a really just position, or are there ways in which specs are actually still not so well specified as the naive person might think, and we're relying on a sort of human fuzziness to unpack those such that it remains difficult for AIs in some ways? Good question again. Unfortunately, if you are an automotive super OEN today, it's more than matter, right? Specific RSQ, as they call it, so request for quotation and specification, and they is still not fully streamlined, not fully automated, not fully defined. There are standards that OEMs are trying to impose and sets, right? But there is always human interpretation, especially when, for example, we think about a car, which is such a complex problem with an infinite number of dimensions and constraints, right? Imagine that if you change the thickness of a single component somewhere under the hood, this might impact the overall engine block, right? And you have a lot of constraints that are tied together, which means that ultimately it's not as deterministic as one might think, which is why those problems are also extremely complex to solve, right? Yes, starting from a set of specs that the model can read and translate that into 3D, this is exactly what's happening today, right, already. However, why it is not yet as black boxy as it can be for software engineer, it's because the dimension of the problem is much, much broader, much richer, right? You have many more trade-offs you need to make. And there's never one way to get to a solution, right? Which why it's not going to replace engineers anytime soon, but it's going to empower them to be faster, actually. It's going to remove or eliminate the low added value tasks That's for sure, that's already happening, right? Where the engineer needs to manually set up a new simulation, needs to manually go on the CAD and roll a new design. This is going to, this is being eliminated as we speak, right? But it's never going to replace the engineer taking those design decisions, even the demonstrator.…
Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.