The simulation engineer's guide to not being replaced by AI
A level-headed look at which parts of CFD and FEA work are actually being automated, which parts are hype, and where the ground is genuinely shifting.
Every few weeks a paper crosses my feed claiming a neural network that runs “1000x faster than CFD.” The comment sections split into two camps: ML people announcing the end of numerical simulation, and simulation people announcing that the paper’s authors have clearly never converged a real case in their lives.
Both camps are wrong in instructive ways. I’ve spent the last several years with one foot in HPC-driven simulation and the other in scientific machine learning, and the honest answer is messier than either headline. Some parts of this job are being automated right now, quietly, without any press release. Other parts, the parts that most of the loud claims are aimed at, are much further from automation than the papers suggest. And there’s a third category that’s neither safe nor doomed, just changing shape.
If you run solvers for a living, the useful question isn’t “will AI replace me?” It’s “which specific tasks in my week are exposed, and what do I do about it?” So let’s take the workflow apart piece by piece.
First, decompose the job
“CFD engineer” is not one skill. A typical simulation workflow looks something like this:
Requirements and problem framing: deciding what question the simulation actually needs to answer, and to what fidelity
Geometry and meshing: CAD cleanup, mesh generation, boundary layer resolution decisions
Case setup: boundary conditions, solver settings, turbulence model selection, numerical schemes
Solving: the compute-heavy part everyone fixates on
Monitoring and troubleshooting: divergence, bad cells, unphysical results, the 2 a.m. residual plots
Post-processing and reporting: extracting the three numbers that matter from 40 GB of fields
Verification, validation, and judgment: is this result right, and would I sign my name under it?
The automation exposure of these steps is wildly different. Talking about “AI replacing CFD” as one thing is like talking about “AI replacing medicine” — it flattens a spectrum into a slogan.
What's actually being automated (and mostly should be)
Here’s the uncomfortable part first. A meaningful chunk of a simulation engineer’s week was never really engineering, it was glue work. And glue work is exactly what current AI tools are good at.
Scripting and boilerplate. Writing the Python that parses residual files, the bash that shuffles cases across a cluster, the boilerplate of an OpenFOAM case directory, LLMs do this well today. Not perfectly, but well enough that if writing utility scripts was a large fraction of your perceived value, that fraction has already been repriced. I use these tools daily and the honest assessment is: they’ve compressed hours of scripting into minutes of reviewing.
Case setup patterns. Setting up the fifth variant of a case family you’ve run before is pattern-matching, and pattern-matching is automatable. Commercial vendors are already shipping assistants that draft solver settings from a description. They’re not trustworthy on novel physics, but for routine configurations inside a well-trodden envelope, they’re getting decent fast.
Post-processing and first-draft reporting. Extracting standard quantities, generating standard plots, drafting the report section that describes the methodology we’ve described a hundred times. Automatable, being automated.
Notice the pattern: everything above is high-frequency, low-judgment work. If your role is 80% this, the concern is legitimate — not because a neural network will solve Navier–Stokes for you, but because a language model will write your scripts for you.
What's hyped: the 1000x speedup, annotated
Now the other side. The claims that a learned model — a PINN, a neural operator, a graph network, will replace the solver itself deserve a close, fair reading, because the papers are often technically true and practically misleading at the same time.
When a paper reports a 1000x speedup over CFD, there is almost always an asterisk chain attached:
The training data came from the solver being “replaced.” The neural surrogate is a compression of solver runs, not an alternative to them. Someone still has to generate hundreds or thousands of high-fidelity cases. The speedup is real at inference, the cost has been moved, not removed.
The test cases live inside the training distribution. Same geometry family, same Reynolds number range, same boundary condition envelope. Step outside it, a new blade shape, a different operating point, and accuracy degrades in ways the model won’t warn you about. Classical solvers degrade too, but they degrade loudly: residuals blow up, the run crashes, we know something is wrong. A surrogate hands us a smooth, confident, wrong field.
Conservation isn’t guaranteed. A finite volume scheme conserves mass and momentum by construction. Most learned models satisfy conservation only approximately, only on average, only where the training data lived. For a quick design-space sweep that may be fine. For the result we certify, it isn’t.
The verification problem is unsolved. With a classical solver I have grid convergence studies, discretization error estimates, decades of V&V methodology. With a neural surrogate, the honest error bar on an out-of-distribution prediction is an open research question. Not “hard”, but open question.
None of this means the research is bad. Some of it is excellent, and I say this as someone who builds and writes about these methods. It means the gap between “impressive benchmark result” and “tool you’d stake a turbine design on” is wide, and the people who understand exactly where that gap is are, conveniently — simulation engineers.
What's genuinely changing: the solver becomes one tool among several
The real shift isn’t replacement. It’s that the solver is losing its monopoly.
The clearest example is design optimization. If you need to evaluate ten thousand geometry variants, running full CFD on each one was always the bottleneck, which is why the field spent decades on surrogate models, response surfaces, and adjoint methods long before deep learning arrived. Neural surrogates are the newest and often best entry in a very old toolbox. Inside an optimization loop, evaluating thousands of similar cases, exactly inside the distribution you trained on, is the one place where learned models are legitimately transformative. Fewer full solver runs, faster design iterations, broader explored design spaces.
Similarly: ML-augmented turbulence closures, learned initializers that cut solver iterations, super-resolution of coarse simulations, surrogates for the expensive component inside a larger system model. The through-line is that ML is entering the workflow as an accelerant embedded in a classical framework, with the classical solver still serving as the source of truth and the final arbiter.
What does that do to the job? It means the simulation engineer of the next decade runs fewer routine cases and instead curates training data, decides where the surrogate can be trusted, and designs the hybrid loop. The solver expertise doesn’t become obsolete, it becomes the supervision signal.
The part that doesn't automate: knowing when the answer is wrong
Here’s the core of it, and it’s not a sentimental point about human intuition. It’s structural.
Every simulation result, whether classical or learned, is an answer to a question, and the value chain runs through two judgments that sit outside any model:
Framing: what question should we ask? What fidelity does this decision actually need? Is RANS good enough here, or is this a case where the separation point matters and RANS will quietly lie? No tool decides this, because it depends on consequences, budgets, and physics understanding simultaneously.
Validation: is this answer right? Not “did it converge” — right. Anyone who has done this work has a story about a beautifully converged simulation that was wrong because of a boundary condition, a mesh that under-resolved the wrong region, a turbulence model outside its validity envelope. Catching those requires a mental model of the physics strong enough to be surprised by a wrong answer. That skill was scarce before AI, and every learned model added to the pipeline makes it scarcer and more valuable, because now there are more confident, smooth, plausible-looking ways to be wrong.
The engineers who are exposed are the ones whose value was “I know which buttons to press in the GUI.” The engineers who become more valuable are the ones whose value was “I know when the answer is lying to me.” AI is aggressively automating the first group’s work while generating unprecedented demand for the second group’s.
So what do you actually do?
Concrete, in rough order of leverage:
Use the automation on yourself, now. Let LLMs write your glue scripts and boilerplate. If you refuse on principle, you’re competing against colleagues who ship the same work in a third of the time. The goal is to spend the recovered hours on the judgment work.
Learn how the learned models actually work. Not the headlines, but the mechanics. Train a small surrogate on one of your own case families. Watch where it succeeds, then push it out of distribution and watch how it fails. That failure mode knowledge is precisely what neither pure-ML people nor GUI-level simulation users have.
Own verification and validation. V&V is going from a compliance chore to the central technical problem of the field, because every hybrid ML-simulation pipeline needs someone who can answer “how wrong is this, and where?” Get good at error estimation, uncertainty quantification, and building validation cases. This is the most durable skill on the list.
Move up the framing chain. Practice translating engineering decisions into simulation questions and back. The person who decides what to simulate and why is upstream of every tool.
Become the hybrid-workflow person. Someone in your organization will be the one who knows when to deploy a surrogate, how to build the training set, and where the classical solver must remain in the loop. There is currently a shortage of people who genuinely speak both languages. That’s not a threat, that’s the opening.
The honest summary
The scripting is going. The routine case setup is going. Good riddance to most of it.
The full replacement of solvers by neural networks is, for anything safety-relevant or out-of-distribution, much further away than the benchmark papers imply, and the people best positioned to know exactly how far are the ones running the solvers today.
And in between, the job is being rebuilt around a hybrid workflow where classical simulation provides ground truth and learned models provide speed, a workflow that needs people fluent in both, and skeptical of both.
The simulation engineers who get replaced won’t be replaced by AI. They’ll be replaced by simulation engineers who learned to supervise it.
If you've seen a learned surrogate fail in an interesting way — or succeed where you didn't expect it to — I'd genuinely like to hear about it. The failure catalog is the most undervalued dataset in this field.