“Clicking in CAD by Itself Is Not Engineering” – Kyrall

We interviewed Kyrall co-founder Osama Atwi to talk about generating native parametric CAD that engineers can keep editing in Onshape, how Kyrall handles DfM checks on the generated parts, and the three concrete use cases his early pilots are getting real value from.

Manual Work Resulting in a Fragmented Flow

What’s the problem you’re solving?

It’s twofold. The way we design mechanical parts is very manual, and the whole design sector is fragmented, between design, simulation, and manufacturing. So it’s the manual labor inside each of those stages, and the disconnect between them.

What’s the disconnect?

The formats we use in each domain are completely separate. When you finish a design and export the part as a STEP or STL file, that format misses a lot of the design intent. Design intent is the series of decisions an engineer makes to build a part a certain way, and the sequence they followed to get there. It’s very hard to capture, because it’s usually not documented explicitly and it isn’t in the file format.

When you run a simulation, it’s hard to feed the results back into the design loop. When you go to manufacturing, a lot of the information you need to design for a specific process is missing, so the design has to be reworked to fit the method. A native parametric file is better than STEP or STL, it captures at least the steps that were followed to build the part, but it still doesn’t capture all of the design intent.

And the other half of the problem was manual labor.

If we focus on CAD, it’s as if you want to plow a field by hand and the tractor hasn’t been invented yet. A big part of CAD, once you separate out the design engineering, is just clicking in a piece of software. You make a sketch, draw a circle, extrude it, fillet the edges, add a hole. Those steps take time and take years to learn, but they aren’t really engineering. That’s the manual labor we think should be automated.

Engineering is me thinking up the part, and getting that vision onto the computer is just manual labor that shouldn’t be there?

If there’s a way to take all the knowledge I have and translate it directly into a 3D model, a way to automate the manual step without automating the engineering. People think the goal is to eliminate the work of engineers. It’s the opposite. It’s about freeing them from the tedious manual part so they can focus on what really matters, the function, the requirements, the part they’re designing.

We equate CAD with engineering because it’s the modality we work in, the tangible thing that represents our work. It’s like equating a whole painting with art. But the frame of the painting isn’t art. If there’s another way to represent engineering that removes the manual labor, we can consider that engineering too.

So what is engineering, then?

At a high level, problem-solving. More concretely, using the knowledge you’ve gained over years, plus the new information you’re getting and the tools you have, to solve a very specific problem within a set of constraints and requirements. In aerospace, that’s designing an aircraft that flies and is safe. The same approach applies to automotive, robotics, and classical mechanical engineering.

Where did you encounter, or notice the problem?

In my work as an engineer, we were designing a lot of small drones, and every new project meant starting more or less from zero, because not much was reusable. So I started hardcoding software tools to automate the design of a drone frame. It became a press of a button. But I had to hardcode it for one specific frame. A different configuration meant building a new configurator from scratch. The tools weren’t built for that kind of automation.

Replacing Points in Space with a Script

How is Kyrall looking to solve the issue for the industry?

At the core, we’re moving toward what we call compilability of 3D models. We want to treat 3D models very much like code. It solves the fragmentation problem, because you get a single format that flows along the engineering pipeline, and it makes generation easier.

Instead of generating points in a vacuum to build a model, we generate a script, and that script generates the 3D model. We can check it for errors, extract features, and embed metadata that gets used downstream in simulation and other tools. However, the user never interacts with the code directly, it stays in the background, edited and updated as the design matures. CAD parts are already code in essence, but that code isn’t being used to its full potential.

Does it mean you’re building your own CAD?

Not really. We’re building our own infrastructure and our own formats, but our thesis isn’t “throw away everything you have and use our tool”. It’s a standalone system that integrates with what people already use. As of now we can read and write in Onshape. We can also read CATIA, NX, SolidWorks, and Creo, and we’re working on writing to those too.

Walk me through the part generation process with Kyrall.

It depends how you work. Some people have technical drawings or sketches that describe the part. Others just describe it in text. Others have a precise description, like an Excel sheet with the exact connection points and sizes, and we design the part parametrically from that. Some use it as a reverse-engineering tool, recreating a part parametrically from drawings.

Once you have generated a part, you can keep editing through text, or highlight one part of an assembly and edit only that. When people think about AI they assume it hallucinates, or that changing one part changes everything else. We built it so you can isolate and change only one thing. And because everything is parameterized, you can just change a number. Want an L-bracket a bit longer? Change the number, press enter, and in less than a second it’s updated.

How do you create parts that actually conform to manufacturability guidelines?

We’re embedding DFM tests right now, focusing first on three-axis milling and FDM, SLA, and SLS printing, then expanding to sheet metal and other methods.. Every part can be fed into the DFM tool, the user chooses the manufacturing method, and the part is altered to meet the checks.

We split them into static and dynamic. Static requirements have to be met for the part to be made with that method at all. If I’m milling a plate, I can’t have sharp internal corners in a pocket, they have to be rounded. A dynamic requirement is more subjective, like whether a specific radius on a specific machine means buying a new tool head. The checks themselves are rule-based. The integration along the pipeline is AI-based, because it’s never fully deterministic.

When a part breaks a design rule, you see a pop-up recommendation. A simple example is the minimum distance from a hole to the edge of a plate, usually 1.5 times the hole diameter. If a hole sits too close to the edge, the tool flags it. Those rules can be fine-tuned by industry and by user.

Three Main Use-Cases

Some companies in this space market themselves with “describe a turbine engine and it pops out.” What’s the reality?

There’s a lot of noise out there. And text-to-CAD is a bad name. It gives the impression you type design me a jet engine, hit enter, and out comes a jet engine.

We saw this firsthand. We gave the tool to testers who were senior mechanical engineers, and they would prompt it that way and then be disappointed it didn’t work. We’d ask, do you really think you can design a whole fighter jet right now? Why would all the companies that design fighter jets exist if that were possible? It was partly our mistake, managing expectations the wrong way.

People who think these tools will soon design a jet engine from a prompt don’t know how jet engines are designed. Engineering isn’t just 3D modelling. It’s calculating the part, design for manufacturing, simulation, requirements, and testing.

It sounds like you learned from your mistakes. How do you work with customers now?

Rather than handing them the tool and saying go use it – because the first thing they’ll do is prompt something impossible – we go to them, understand their processes and bottlenecks, and come back with a proposal. We focus a lot on forward-deployed projects. Sometimes we realize they don’t have a problem we can solve, and we tell them that’s fine and move on. It’s dangerous to force the technology in. You simply don’t need it everywhere.

What are the clients using Kyrall for then?

One is conceptual design in aviation. When you design a new drone you want to explore different configurations, and today that’s very manual. With our tool you do that iteration in minutes instead of weeks, because you develop it once and then change any parameter.

Parametric blended wing body aircraft design

Another is asset generation. When people work with assemblies they need a servo motor, a connector, a bracket, and today they search online and usually don’t find exactly what they want. Nobody enjoys redesigning a servo motor to put it in an assembly. A simple one might take an hour and a half, and across a bigger assembly that’s many hours a month.

Custom bracket asset generation by Kyrall

Custom flange asset generation by Kyrall

The third is design for non-designers, people who are technical in a different area and need a PCB enclosure or a motor holder 3D printed quickly. Today they either learn CAD or go bother the mechanical engineer. We heard that a lot in testing, mechanical engineers asking us to give that person the tool so they’d stop coming to them.

Who’s the user really meant to be?

Those three examples cover almost everyone, from non-technical people to juniors and seniors. It’s still to be seen where the biggest value lands, but for now it seems to be delivered across the whole engineering pipeline.

What about customers from industries that can’t send design data to an external LLM provider?

That’s a big concern for many of them, and rightly so. We’re training our own small language models that run locally on the customer’s own machines, with no huge GPU infrastructure needed. The data never leaves their environment.

A byproduct is that once it’s hosted locally, we can keep fine-tuning the model on that customer’s own legacy design archive. So they don’t just get the model everyone else has, they get one with their own design practice embedded in it, running on-premise where no one else has access. We’re talking to companies that are 50 or 100 years old, and one thing they keep raising is that they have huge amounts of legacy data they aren’t really using, because it’s almost impossible to access. We can parse it, convert it, and fine-tune on it.

Tiers for Every User

What does it cost?

We have a license-based approach as this is what the industry is accustomed to. For now, it’s a normal subscription with tiers. And on top of that, we have a separate offering for enterprise customers who need extra fine-tuning, local hosting or other customization.

Say I have a 3D printer and no design skills. Is there a way in for me?

For that use case the pricing is within what people expect from consumer products, manageable for hobbyists. If it’s just about generation, it’ll be in the normal range of any subscription.

Any full integrations beyond Onshape?

As said, we already read the main CAD files. We’re working on read-and-write capabilities, but it’s still to be determined when the launch is exactly. It’s on our roadmap to integrate with the most-used CAD software.

Is Kyrall a browser-based editor only?

We also offer it as an API, not just a browser tool. With coding copilots you can build very specific applications on top of Kyrall quickly. Want an app that takes an STL file of a tool and builds a shadow box around it? Or one that generates jigs and fixtures from a part? You can build those on our API in a short time, with no need to license dedicated software for each.

A Combination of Passion and Criticism Takes Us Forward

There are already a few names in this space. How many winners will there be?

The space is huge, so there will be several, just as there are in the CAD world where there is no single CAD package that dominates today. Who wins will depend on who focuses from the beginning on solving real problems, rather than building something that just looks nice. It’s a difficult, conservative space that sees little innovation, and for good reason. These tools build cars, aircraft, and machines people use every day, so the bar for safety and reliability is very high and should stay that way.

It’s something I’ve always found amusing, that engineers innovate everything except their own workflows.

When hardware engineers go to get software, they have very high expectations. Hardware is hard, so they assume software is easy, which usually isn’t the case. That’s part of where the inflated expectations come from. This resistance isn’t new either. It happened when CAD was introduced. Back then people said it was too slow, too buggy, that they could draw faster by hand. Now no one would say CAD isn’t better than what came before.

The easy part of software is that you can test it. With hardware, you can spend a year on CAD modeling, then your parts get manufactured, then assembled into a factory, then the owners start it up, and only then do you find out if you messed up.

Exactly. We’d spend months designing a drone, building it, assembling it, and you go to the flight field and it crashes after two seconds. You’re freezing on the flight field at 8 a.m. in December, you’re behind schedule and over budget, you throw the drone, and it crashes immediately. The worst a software developer usually feels is compiling buggy code, and now an AI coding tool fixes it for you. Engineering is hard. We used to say the first flight test is always a crash. If it flies on the first test, it’s a miracle. It doesn’t mean software is easy, it means it’s just easier.

How much of the interest in AI tools is just fear of missing out?

Our experience hasn’t really been that. Most of the time people are skeptical, because it’s AI. They think it hallucinates, or they think of it as chatbots rather than an engineering tool. They’re cautious, and they ask a lot of technical questions, how it integrates, how we solved hallucination, what about their data. That’s exactly how it should be. If someone is only chasing it out of fear of missing out, they’ll probably drop it after a while.

It’s healthy to have both passion and criticism, even hate. If everyone is just clapping, you don’t get proper feedback. If everyone is just hating, you don’t move forward. We need a proper mix. More companies need to push forward with these technologies and be willing to test things even at an early stage, because if you want this to work in three or four years, you have to start now. The way we design machines will not stay the same, and the companies willing to try these tools will end up significantly ahead of the others.

Who else, beside you, should people be following in this space?

Bench AI is doing really good work on preparing models after simulation to feed back into the design process. nTop is doing a lot in design exploration. And Synera is leading on agentic workflows and integrations across different tools.