Introducing Agent-Driven Engineering: The Future of Hardware Design
By Cameron
Every physical product — from drones to spacecraft — advances too slowly. Not because engineers aren’t fast, but because they’re waiting: for simulations, data, and hardware.
The world can’t afford that anymore.
At Navier AI, our mission is to build autonomous hardware engineers — AI agents that help humanity build faster.
We started by trying to teach AI physics.
It worked — sort of.
Then we realized the hard part isn’t the physics.
It’s the engineering.
Here’s what we learned, and what drove us to build AI engineering agents 👇
The Physics ML Era
We started Navier AI in late 2023 with a simple idea: make engineering move faster.
Our first plan was straightforward — use Physics ML to speed up fluid dynamics simulations with “physics-foundation” models.
Before explaining why that didn’t work, it’s worth clarifying what people mean by Physics ML.
There are two dominant approaches: data-driven models and equation-driven models (PINNs).
Data-Driven
In the data-driven world, you generate large amounts of high-fidelity training data — usually from traditional solvers — and train a model on top of it. Neural Operators fall into this category, and this is where we saw the most success.
The model itself isn’t the hardest part.
The data is.
- Do you already have it?
- Do you need to generate it?
- Do you know the design space in advance?
- Do you trust the labels?
These questions quickly become the bottleneck.
PINNs
On the other side are equation-driven approaches — Physics-Informed Neural Networks (PINNs). Instead of relying on large datasets, you bake the governing equations directly into the training loss.
Elegant in theory.
Brutal in practice.
The moment you move beyond toy problems like 1D Burgers’ equations and into full Navier–Stokes systems, GPU memory usage explodes. Each additional term in the loss compounds the computational cost. What looks clean on paper becomes a training nightmare in reality.
So for about a year, we went deep — experimenting, building, and benchmarking.
We made real progress. Our models outperformed much of what we saw in the research literature.
On the surface, this was exciting.
We had built an ML model that could predict results on new geometries 100,000× faster than traditional CFD. We didn’t just make it fast — we eliminated meshing entirely. Give us a geometry, we quantize it and push it straight through the model.
For a moment, this felt like the breakthrough.
The Real Bottleneck
Any aerospace engineer will tell you: simulations that are 10,000× faster, meshless, and accurate feel revolutionary.
At first, we thought that was the answer.
But here’s the catch: these models aren’t truly general.
You can’t throw arbitrary geometries at them and expect high-quality results. Each meaningful use case requires its own carefully defined design space — along with the data generation, validation, and retraining that comes with it.
If you have to run thousands of expensive simulations just to train the Physics ML model…
…doesn’t that defeat the purpose?
As we started taking our Physics ML approach to market, this became unavoidable. It was a powerful tool — but only in narrow, high-value optimization problems where the upfront cost could be justified.
For the vast majority of engineering work, Physics ML is the wrong abstraction.
It takes longer to get meaningful results, costs more to deploy, and is harder to trust.
That realization forced us to zoom out.
If our goal was to accelerate hardware engineering, maybe the bottleneck wasn’t physics modeling at all.
Maybe it was the human loop around it.
Engineering Autonomy
That’s when we turned to AI agents.
They weren’t part of the original plan. At first, we imagined something lightweight — maybe a chatbot to help with documentation or setup questions.
But as we listened more closely to engineers, their frustrations sounded different.
When someone said, “I can never run as many simulations as I want,” we used to hear a need for faster solvers.
Now we heard something else:
A need for automation.
Demo
We watched as our agent set up and ran 40 CFD simulations overnight — and woke up to a clean Cl–Cd curve waiting for us.
Normally, this is days of tedious setup, solver babysitting, and second-guessing convergence.
I gave the agent a single prompt:
Generate a Cl–Cd curve for this new fixed-wing drone design.
Without any further input, it began planning a mesh-independence study, selecting mesh resolutions, launching a batch of simulations, checking convergence, aggregating results, and stitching together a performance curve.
No scripts.
No manual setup.
No babysitting.
Watching that loop unfold felt surreal — not like using software, but like onboarding a junior engineer who quietly did the work while we slept.
That's when it clicked.
The future of engineering wasn't faster simulations.
It was engineers that could think and act.
Teaching AI to Engineer
Teaching AI to engineer means teaching it to understand the 3D world — geometry, physics, and context.
LLMs can’t do that out of the box. They hallucinate geometry, misread meshes, and lose track of causality. So we’re building the vision, cognition, and action stacks from scratch — the same way autonomy teams did for self-driving cars.
Our first product is an engineering copilot — a step toward autonomous engineers.
Ask it to:
- run a mesh study
- run a batch of simulations
- push a CFD case to convergence
It just handles it.
Today, it’s helping our early partners run five times more design iterations per week.
But this is just the beginning.
If code copilots transformed how we build software, AfiI engineers will transform how we build everything else.
The last era of progress scaled software.
The next era will scale engineering by freeing engineers from the bottlenecks that slow them down.
We’re building that future at Navier AI — and we’re looking for the engineers, partners, and dreamers who want to build it with us.
Ready to experience Agent-Driven Engineering?
Learn more about Navier's platform or contact us to see how ADE can transform your workflows.