LEAP 71: Why engineering must move beyond CAD to realise the promise of AI and Additive Manufacturing

For decades, we’ve seen information technology advance at the pace of Moore’s Law of exponential progress. With the rise of generative AI and large language models, that curve now appears to be steepening – but that’s not the case in engineering.

Why does it still take months to design a heat exchanger or years to design a rocket engine? Why are some engineers stuck redesigning the same bracket over and over again, sometimes for their entire career? This is all in sharp contrast to a microchip, arguably one of the most complex ‘machines’ ever devised, which can be developed in a matter of months.

If I asked you to use a forty-year-old computer, you’d laugh, but you’d not think twice about taking a ride in a car or elevator from the 1980s – progress in engineering is painfully slow when seen through this lens.

This discrepancy has long frustrated me. Both fields are rooted in physics, logic, and manufacturability. Both ultimately produce physical hardware. So why hasn’t engineering kept pace with computer hardware? We all live in the physical world. Why can’t engineering accelerate to tackle humanity’s grand challenges and opportunities more effectively? For the past decade, I have been attempting to get to the bottom of this question.

At the core of this issue lies a fundamentally different approach to engineering. Outside of IT, we remain trapped in a visual design paradigm that hasn’t changed radically since ancient times. A Roman engineer created the blueprint for an aqueduct on a piece of paper; today, an aerospace engineer draws a spacecraft component in a Computer-Aided Design (CAD) tool. CAD only does what it says – it aids the engineer in sketching. But it doesn’t preserve the intent, nor does it encode the logic; that all stays in the engineer’s head.

I’ve said before that CAD is evil – not because it’s malicious, but because it creates the illusion that you’re using a computer for computation, when in fact you’re just using it as a sketchpad – albeit a powerful one. The real algorithm runs in the engineer’s brain, and the engineer’s hands then translate it into geometry at an excruciatingly low bit rate.

This approach holds back innovation because it makes engineering tedious. And when knowledge isn’t preserved – when the intent behind a design’s visual manifestation is undocumented – you can’t question it, improve it, or rigorously test the logic behind it. As the saying goes: ‘Never change a running system.’
And this limitation becomes completely untenable when you consider the vast design space that Additive Manufacturing opens up. AM removes many traditional production constraints, enabling the creation of highly integrated, multifunctional, and geometrically complex structures. But to fully leverage that freedom, we must move beyond drawing. We must embrace Computational Engineering.

Computational Engineering is also the required prelude to AI engineering because, without understanding the physics, logic, and intent of a design decision, there is nothing to train a neural network on. Any attempt at AI engineering without that intermediate step is smoke and mirrors.

At LEAP 71, my partner Josefine Lissner and I have been progressing down the path of building Noyron, a large Computational Engineering Model (CEM) designed to encode engineering knowledge as computational logic. Some have called it ‘the first AI that builds machines.’ In a way, it is, and this catchy phrase surely aligns well with the current hype cycle. But in this article, I want to clarify what we actually built – and why ‘AI’ in engineering, at least as it’s commonly understood, is often a dead end.

We’ll look at what it really takes to bring engineering into the computational era, what role AI should play, and how Additive Manufacturing can unlock engineering at the speed of Moore’s Law. Most importantly, we’ll show how Computational Engineering is already producing real-world hardware – and why the next generation of machines won’t be drawn: they’ll be computed.

From commands to conversations: designing machines with AI collaboration

What would be the ideal process for designing a machine? Some imagine a black-box AI that magically produces a finished blueprint at the push of a button. Just feed in the specs of a new spacecraft, and out comes a complete, ready-to-build CAD model. But that’s not how engineering works.

Engineering is exploratory. You rarely know exactly what you want, especially when you’re venturing beyond established designs. Inventing something new means testing bold ideas, iterating, and learning along the way. As you experiment, you develop new insights, refine your objectives, and reshape the solution. It’s not a spec., it’s a conversation.

That’s why J.A.R.V.I.S., the fictional AI assistant from Iron Man, is actually a far better metaphor for what we need. J.A.R.V.I.S. doesn’t just output a finished design. It listens, suggests, and fills in blanks. It redesigns as new insights are found. It flags what’s feasible and what’s not. It supports an open-ended conversation that leads to a functioning machine, grounded in first principles and sound engineering.
While J.A.R.V.I.S. is fictional, the approach is realistic. In a world with ChatGPT and generative code tools, a conversational human/AI design process is no longer far-fetched.

In our version, the output isn’t a CAD file, but a Computational Engineering Model: an algorithm that creates the design. It can be modified, iterated on, and tested – because it’s not a blueprint, but a living, logical system. Just like how, in nature, DNA encodes the algorithm that dynamically produces an organism, the computational model can create a three-dimensional shape as well as the data that directly drives the production process – slices, G-Code, and heat treatment instructions. This is because the model understands manufacturing and the constraints that come with each stage.

It’s important to emphasise the difference between a computational model and the ‘geometry tree’ that conventional CAD creates. A computational model is a rich set of instructions, where even small adjustments to the algorithm can produce vastly different objects. A computational model runs physics models, logic checks, and manufacturing validation at any point during the process and directly changes the result.

At LEAP 71, we’ve built many of the logical building blocks that such a system requires. We manually encode engineering knowledge drawn from textbooks, existing designs, first-principle thinking, and practical experience. We encode fundamental physics and embed manufacturing constraints enriched through multiple production runs. We test real-world parts (for example, hot-firing rocket engines), collect data, and feed the insights back into the model.

This large CEM, Noyron, is not a black-box neural network trained on unstructured data. It’s object-oriented source code (in our case, written in C#) that explicitly encodes everything we’ve learned. It’s deterministic: given the same parameters, it always produces the same result. It’s traceable, explainable, and cannot hallucinate. Every assumption is documented. Even the rules of thumb that engineers often employ are eventually replaced by a formula once the underlying logic becomes clear.

In this sense, Computational Engineering might be the first time engineers have truly been forced to be scientific. Traditional engineering workflows tolerate a surprising amount of folklore, trial-and-error, and undocumented best practices – what we might call ‘engineering intuition’.

In a computational model, every assumption must be explicit. Every step must be verifiable, and every design decision must be explained. The result is not just better machines, but a more robust, scientific foundation for engineering itself. A Computational Engineering Model requires a clear, algorithmic foundation for every feature it creates. It’s engineering by logic, not intuition.

Over time, Noyron has grown to encompass a significant portion of the knowledge needed to design complex machines. It’s still incomplete – knowledge is only added in the areas we actively work in – but many domains share the same logical scaffolding.

Rules we used to design capillary distributions in bioprinted vascular systems, for example, turned out to apply directly to aerospace heat exchangers. Those same principles that guide fluid routing in manifolds can be used to avoid crossing wires in electric motors.

Noyron has been used across a wide range of fields – from micromechanical systems and biological tissue to rocket engines, filtration systems, electrodes, heat exchangers, and electric motors. In every case, the design emerges from the abstract engineering DNA encoded in Noyron, not a visual concept in an engineer’s head.

Just like Tony Stark never touches a stylus in Iron Man, a computational engineer never draws geometry on a computer screen. The computational model does all the sketching. And it doesn’t take long to recompute, so the engineering process, while not yet a verbal conversation, becomes almost playful. You can test ideas freely, because a new design takes minutes, not weeks. Innovation requires iteration, and, in this paradigm, iteration is no longer expensive.

Why the future of engineering must be computational

Fundamentally, a Computational Engineering Model is an algorithm that deterministically, from the same set of inputs, produces the same result. How it arrives at this output depends on the class of objects you want to create. For a simple manifold, you may have a set of connection points in space that all need to be connected to another point, avoiding collisions. A simple CEM can generate such output in seconds, whereas a human engineer might spend hours on this task. Once you have such a computational block, you fundamentally never have to think about this problem again, unless you encounter a situation where the algorithm fails or needs to handle a new challenge. This means connecting all the complex piping in a heat exchanger is no longer a manual task; once encoded, the logic handles it automatically and consistently. Over time, you can add manufacturing constraints, preservation of mass flow, and many other aspects that are tedious for engineers to work on, given the current CAD design paradigm.

As these building blocks mature, the abstraction level increases. At some point, you can just say, ‘I need a heat exchanger here, with a heat transfer capability of X’, and the system will build one for you, fully manufacturable, and, ideally, already using the real-world testing data you established. Your heat exchanger needs to fit into a complex bounding shape? No problem, the algorithm will route or extend the pipes into this space. If this is not possible, it will tell you.

Noyron RP, our computational model for space propulsion systems, can autonomously produce fully functional rocket thrusters for completely different mission profiles. No CAD is involved; not even a visual sketch. If changes are needed because of feedback from the field, the algorithm is improved, for example, by adjusting coefficients that can only be found out in practice. Every future design generated by that CEM automatically benefits from the improvement.

Contrast that with human CAD engineering, where any insight needs to be communicated to the one person who happens to be designing that feature. It’s easy to see how much information gets lost in this traditional way of working.

Computational Engineering speeds up progress enormously. For example, we validated Noyron through real-world testing and hot-firing multiple rocket engines. In total, over the course of five months, we tested eight individual rocket engines, including an aerospike, one of the most elusive and sophisticated engines to be hot-fired. An aerospike looks entirely different from traditional bell-nozzle engines, but shares 90% of their DNA. None of the rocket engines took longer than a few weeks from spec to manufacturing handoff. Each generation run took less than an hour on a regular laptop computer – and each worked the first time it was tested because it was based on practically validated physical models.

Noyron outputs a visual model to inspect, but it also generates the manufacturable files (for example, slices), provides performance predictions, documents all assumptions, and even creates fixtures that can be additively manufactured, along with helper geometry that can be loaded into CAM systems for post-machining, all automatically and every time it runs. This goes far beyond what a typical CAD workflow provides.

The Computational Engineering Model is a single source of truth, which, every time it’s run, re-generates everything from visual model to manufacturing files and documentation.

Why most AI in engineering fails and how to fix it

As with all hype cycles, there is now a new trend to call everything ‘AI’, even when it isn’t, and apply AI to things where it is not appropriate.

Let’s get this out of the way: a Computational Engineering Model is an algorithm, not a neural net. It’s closer in spirit to an expert system. Ironically, expert systems were once called ‘AI’ before neural networks redefined the term. At LEAP 71, we do use Large Language Models (LLMs) to summarise and extract information from vast amounts of engineering information. We’ve also connected the Noyron codebase to LLMs, aiming at building a system that synthesises new machinery by combining validated computational blocks with new insights from unstructured knowledge. This hybrid approach – combining structured logic with language-based synthesis – brings us closer to the J.A.R.V.I.S. vision.

But there is no question that without the algorithmic, logical, scientific underpinnings of Computational Engineering, you will not get to AI engineering.

People have tried attaching LLMs to a CAD tool, generating 3D files using neural nets, and calling topology optimisation ‘AI.’ These approaches may look interesting, but they are dead ends. While it’s fun to talk to a CAD system, your communication bit rate is now even lower than using a mouse or stylus. Instead of pointing somewhere, you have to laboriously explain in words what you are trying to accomplish. Computational Engineering relies on the clear logic of a programming language, which was designed to communicate intent in a concise and structured manner. Natural language is ambiguous and not suitable for low-level description of geometry.

Why can’t we go from a spoken description or a sketch on a napkin to a functional 3D design using a neural network, the way we generate images with AI? Because 3D geometry, unlike images, must obey the laws of physics. A sketch doesn’t carry information about how a design functions. And even if you trained a neural net on billions of 3D shapes, the output would still be hit or miss, because a 3D mesh doesn’t understand what it’s for or how it works.

Topology optimisation is a useful tool in the CAD arsenal. You can draw something and then optimise it using underlying physics, and while it is useful, it works in reverse: starting from geometry and optimising it. In our paradigm, we start with a blank canvas and generate the object from scratch. Topology optimisation, of course, has nothing to do with AI; it’s just applied physics.

There is one area, though, where AI engineering and topology optimisation might shake hands. Most people assume LEAP 71’s tech stack involves a lot of Computational Fluid Dynamics (CFD) or other simulation tech. That is not the case. CFD requires immense computing resources, so it is very slow. What’s even more troubling is that it fundamentally only runs on the finished object. So it cannot give you an insight while you are generating a feature in your design. Noyron relies on heuristics, which are the direct evaluation of physics (for example, for heat transfer), which applies at the point of the design of a feature. During the construction of cooling channels in our rocket engines, we evaluate fluid densities, chemistry of the propellant, pressures, thermal loads, etc., all while creating the channel itself, directly influencing cross section, curvature, wall thickness, etc. We are not waiting to simulate these things after a design is complete, as it would be hard to create actionable insights.

But if you could evaluate complex CFD physics instantly, we could make more informed decisions during the design phase. The emergence of Physics Informed Neural Networks (PINNs), which attempt to predict simulation results, is quite interesting, as they essentially provide instant results.

True AI engineering will depend on a combination of computational systems (math, physics, logic) and new tools like PINNs. A J.A.R.V.I.S.-like system can interpret your intent and synthesise high-level building blocks that are pre-validated to build functional machinery. This is how true AI engineering will develop.
After all, not only do you want a working machine, you also want to understand why it works. A Computational Engineering Model, even when a J.A.R.V.I.S. conversation generates it, is always traceable and deterministic.

A new foundation for engineering

Ten years ago, I embarked on this journey with a simple question: Why does engineering in the real world not follow the exponential trend of IT? The straightforward answer is that we have not been abstracting the underlying methodology, as other fields have done.

A person from the financial world would laugh at the thought of manually processing a company’s sales projections using an old-fashioned calculator. Of course, all that data is fetched, recomputed automatically, and presented in a high-level format.

Microchips were designed using CAD until the 1970s. Then they became too complex, and the design moved to encoded rules and algorithms, rooted in physics and logic. A modern chip design is not drawn aided by a computer, but computed from high-level specs written in hardware design languages like Verilog.

Leonardo da Vinci would be baffled by the process of microchip design – but he’d be reasonably familiar with the everyday work of a CAD engineer.

Computational Engineering changes that. It moves engineering to that abstract level, to a system that can be re-run in seconds. But, like in microchip design, it forces engineers to learn how to code in order to express their intent. What we will see in the coming years is a split between engineers who will work on a much higher level, creatively interacting with an AI engineering system through accessible communication, perhaps through natural language or high-level visual interfaces. And then there will be the engineers who produce validated and robust components to create mechanisms that, today, we can only begin to imagine.

Working with my partner, Josefine Lissner, the architect of the Noyron system, for the past three years has been an eye-opener for me. How fast can we build and test complex systems? How can we finally take advantage of the awesome capabilities of Additive Manufacturing, and how can we functionally integrate machinery that would otherwise be manufactured from thousands of individual parts?
I have no doubt that it will move engineering under the exponential curve of Moore’s Law, because I am already seeing it in our daily work.

Author

Lin Kayser
Co-founder

LEAP 71
Dubai, United Arab Emirates
leap71.com