At least the way we use it

Recently, when I tested our internally developed TCAE AI assistant, something went wrong, so I closed the TCAE graphical interface and let Codex (OpenAI’s standard AI agent) work directly on a simulation project from the outside.

I explained what I wanted. The agent worked with the files, prepared settings, launched calculations, and helped investigate problems. Then we discussed what to do next. It even recommended new settings, new physics, and code implementation. Wow.

I was surprised by how efficient the agent was. So, I started adding more and more complexity, and still, it did extremely well. Geometry operations, cleaning, sealing, transforming, complex physics, boundary conditions, inventive settings, execution, and professional, engineering-minded reporting. 

I alarmed my colleagues. We reopened the most challenging projects we did for clients over the last 17 years. The agent solved them with just a little help. And it was brilliant. Impressive. And shocking.

We were stunned. 

We knew it was excellent at coding. But the project execution (and its level) is a total game-changer.

We develop simulation software for a living. We know how much work is usually needed. Watching an agent take over substantial parts of that work makes you reconsider quite a few things.

Including the software you sell. The way you develop it. The way you work with it. The services you provide.

And your own role.

Something fundamental has changed

For decades, engineers have learned how to operate software.

Where to find the settings. File formats. Which files to edit. Which commands to run. How to connect one application to another. How to recover when something breaks.

Being effective meant knowing the engineering (math, physics, IT) and knowing the tools. A substantial part of the day went into operating those tools.

Now we can describe a task and let an agent perform a significant part of that work, if not all of it.

The software still runs. The solver still solves. But the engineer no longer needs to perform every operation personally.

We are moving from operating software to directing work. From engineers to engineering managers.

It is difficult to predict how far this will go. Honestly, predicting anything in this field has become a rather uncomfortable exercise. What seemed impossible a few months ago may already be routine.

Now I am sure we have seen enough to take the change very seriously.

Try it this evening

If you have not tried working with an agent on an engineering project yet, here is my suggestion.

One evening, instead of watching Netflix, try ChatGPT Codex (or Claude Code). 

Install a local desktop application. Give it a project in a separate working folder. Tell it what you want to achieve. Ask it to inspect the available tools, or directly ask it to install standard OpenFOAM. Talk to it. Let it work.

If you have OpenFOAM installed, ask it to help you prepare a new case and run it. Change something. Ask it to explain the settings and plot the results.

You may be stunned too.

You can get a surprisingly long way with OpenFOAM without prior experience operating it. Tasks that once required searching forums, reading documentation, and learning command-line conventions can become part of a conversation. Or not at all. It solves problems for you.

That does not make you an experienced CFD engineer overnight. Getting a case to run and knowing whether its results are credible remain different skills.

But please try it before deciding what agents can or cannot do.

Hands-on experience changes the discussion completely. Believe me, I went through this first myself and later with my colleagues.

What happens to the software business?

Let’s be honest. This change will not be comfortable for everyone.

Some software products will lose their reason to exist. Some business models will become difficult to defend. Expensive commercial codes and Software as a Service platforms should think twice.

Some engineering skills that took years to develop will become less valuable too.

Not everyone will make this transition successfully.

If your main advantage is a fancy interface around a few open-source functions, what happens when an agent performs those operations directly?

If your product is an automation script that connects a few tools, what happens when a customer can generate a similar script themselves?

If creating a custom application becomes cheap, what exactly are you selling?

These questions apply to us too.

We all have to reconsider our roles and purpose. Developers, engineers, consultants, managers. What do we contribute when execution becomes much easier?

I do not think anyone has a complete answer yet. I certainly do not. 

I only know that such a tremendous change carries a huge opportunity in it.

We have all seen the CFD AI slop

Another solver announcement. Another impressive animation. Another claim that CFD (wheel) has been reinvented.

Some days, my newsfeed makes me feel as though five new CFD codes have appeared before lunch.

Some of this work may be valuable. Some is an interesting experiment. Some is CFD AI slop: easy-made, convincing-looking output with very little value behind it, if any.

It is becoming easier to generate code, produce a result, and write a confident explanation of what it means. Eye-catching images are never missed.

Establishing whether that explanation is correct remains hard.

Does the implementation solve the intended equations? Does it conserve what it should? How does it behave outside the demonstration case? Has anyone compared it with measurements or an established reference?

And can somebody maintain it next year?

A successful demonstration answers only a small part of these questions.

The spaghetti monster is easy to create

AI-assisted development is extremely productive. It can also produce an impressive mess.

Add a feature. Patch a failure. Generate another helper. Fix the helper with a special case. Repeat until nobody understands how the whole thing works.

You now have a spaghetti monster that passes today’s demonstration.

But wait, who will maintain it?

Engineering software needs long-term sustainability. Customers build workflows around it. Projects must remain understandable. Changes must be traceable. A new feature must not quietly break an old one.

That requires architecture, coding rules, clear interfaces, version control, meaningful tests, code review, and documentation.

Agents need guardrails. Someone has to own the design and understand the changes being accepted.

The faster we can generate code, the more important this discipline becomes. Otherwise, we simply accumulate technical debt faster than ever before.

The good news is that we have become much more capable

I do not want this to sound too pessimistic. My own experience is actually the opposite.

We have become so much more powerful as an engineering team.

This goes far beyond preparing simulation projects. Agents help us investigate code, explore new physical models, implement features, connect tools, automate workflows, and process results.

We can try ideas that previously would have waited months for available development capacity.

We can investigate more alternatives. Build more useful tools. Spend less time on repetitive implementation work.

At CFDSUPPORT, we are developing a new family of solvers, exploring new meshing strategies for turbomachinery, adding more automation, and much more. 

The time between an idea and a testable implementation is shrinking. Benchmarks are running day and night. I estimate that we’re 5x faster now than we were only two years ago. 

Verification still takes work. Understanding still takes work. But we can do much more with the expertise we already have. 

That is an enormous opportunity.

I expect a huge rise of engineering consultancy

This may sound strange coming from someone who has just argued that software is becoming easier to use.

If customers can do more themselves, why would consultancy grow?

Because many customers want an engineering problem solved. They have limited time to learn CFD, investigate numerical problems, or establish whether a result is trustworthy.

An experienced team using agents can potentially deliver more work, explore more alternatives, and respond faster. Projects that previously required too much manual effort may become practical. It makes perfect sense to get things done by professionals.

That could expand the market considerably.

I expect a huge opportunity for consultancy businesses that combine deep engineering experience with effective automation.

The work itself will change. The value of manually preparing files will fall. The value of choosing a sound approach, diagnosing a difficult problem, and taking responsibility for the conclusions will remain.

Our customers still need better products and useful decisions.

We now have more capacity to help them get there.

Where does that leave TCAE?

It makes us think much harder about what TCAE.

The graphical interface is one part of it. Behind it is an engineering system built through years of development and hundreds of projects. Experience is built in. Methods, defaults, checks, fixes, and workflows. Experience accumulated through things that worked, and things that did not.

An agent needs access to that capability. It benefits from a system that behaves consistently and handles the difficult details.

We are developing TCAE to be operated by both humans and agents.

Our longer-term direction brings TCAE, TOPT, and TBASE into one connected process: simulation (TCAE), design exploration (TOPT), and accumulated engineering knowledge (TBASE). Aligned with agents that can help operate and connect these tools under smooth engineering supervision.

We want to make that experience easier to use, while continuing to improve the engineering underneath it.

Let’s be honest: We all have to redefine our roles

I expect to spend less time telling software which operation to perform and more time deciding what is worth doing.

What is the actual goal? Which assumptions are acceptable? What evidence is missing? Is the result good enough? Should we investigate further, or start again?

These decisions require attention, experience, and judgment.

They also require us to learn a new way of working. Delegation is a skill. Explaining a problem clearly is a skill. Recognizing when an agent is confidently going in the wrong direction is a skill.

We cannot assume that yesterday’s working habits will remain competitive.

That includes those of us who develop the software.

So, is CFD software dead?

Yes. Some of it surely is. Agents are unstoppable.

Software is becoming a commodity. A common tool. Some of it may become infrastructure that users rarely interact with directly.

I would not bet on the survival of every interface, product, or business model. Sorry for the very polite talk here. I really expect a lot of disappointment in the field. 

I would bet on the continuing need for solid engineering, and people who can judge the results. Once again, I expect the rise of open-source in the software field and consultancy business in the service field.

The change has already begun, and you can experience it yourself.

Try it this evening. Give an agent a real task – something big. … When they wake you up, let me know what you think about it.