Artificial intelligence is getting to the point where it’s becoming routine in engineering, but most of the conversations around it start with the wrong questions, like which black-box service should we subscribe to, which coding assistant won this month’s popularity contest, or which cloud provider has the fastest GPUs, and for a small engineering firm, an independent researcher, or a consultancy still trying to find their footing, those questions just pile on pressure to shell out money before you’ve even figured out a realistic workflow. Luckily there’s a simpler question to ask first, which is how can we actually use AI to produce verifiable engineering outputs with the tools we already have, and for us at M² Engineering, part of the answer comes down to drawing a clear line between assistance and authority, where AI can help write code, translate equations, review decisions, create tests, and debug errors, but it should never be the final judge on whether a simulation, surrogate model, or scientific conclusion is correct, because that authority has to stay with executable tests, governing equations, conservation laws, dimensional analysis, and comparison to trusted numerical or experimental results, and once you’ve got that distinction nailed down you can start building a solid engineering workflow without rushing into expensive subscriptions.
One thing became pretty clear early on, throwing more AI assistants at a project doesn’t automatically make your engineering workflow better, in fact it can make things harder to maintain because each assistant brings its own little conventions, one might call a temperature field T, another might spell out temperature, and a third might quietly assume the tensor order is batch, channel, height, width instead of batch, height, width, channel, and none of that looks like a big deal when you’re working on a single file, but after twenty or thirty files those differences become the project. So we found it more practical to stick with one primary assistant that stays familiar with the full project structure and keep a secondary one only when an independent review actually adds something useful, but even then that secondary review shouldn’t get the final say. Engineering models have always needed verification through measurements, correlations, conservation laws, and comparisons with limiting cases, like in our experimental thermodynamic work where we checked measured properties against reference values, reported uncertainties, and only correlated derived quantities after assessing the measurements themselves, and the same discipline has to carry over to AI-assisted scientific computing, because AI can suggest a function but it can’t decide on its own whether an energy balance closes, whether a reaction rate has the right dimensions, or whether a neural operator actually learned the physics rather than just memorizing patterns in the training data.
For that reason, the core of your workflow needs to stay local and executable, meaning Python, Git, automated tests, static analysis, and carefully defined data contracts aren’t just some secondary housekeeping chores you get to later, they’re what actually makes your work reproducible in the first place. Before you even think about training a surrogate model, you should check your dataset for missing values, unit consistency, parameter ranges, duplicated cases, and impossible states, and before you accept a new neural operator module, you ought to verify input and output tensor shapes, confirm gradients actually propagate, test whether you can overfit a very small batch, and compare predicted fields against basic conservation requirements. None of these checks are fancy or sophisticated, but they save you from wasting an absurd amount of time, because there’s nothing more frustrating than burning hours of training only to realize one spatial axis got transposed or a normalization constant came from the wrong variable, and the AI didn’t create that problem on its own, the workflow let it slip through. That’s why you should break the project into small engineering milestones, each one producing something you can actually inspect, so verify the data loader before you develop the architecture, test the architecture before you start large-scale training, and do physical validation before you even think about preparing figures for publication. It might feel slower at the start, especially when AI can spit out piles of code in minutes, but it pays off big time once the project hits any serious scale.
The role of AI is important, sure, but it’s narrower than all the hype sometimes suggests, because it’s great for speeding up implementation, explaining unfamiliar libraries, generating repetitive tests, restructuring code, and pointing out possible mistakes, and it’s also useful for comparing alternative numerical approaches before you sink time into implementing them, but the actual engineering decision still needs a foundation outside the AI system. In our reactor studies, for example, we didn’t judge segmented versus continuous catalyst configurations by which one produced a prettier temperature contour, we compared them using methane conversion, hydrogen production, catalyst utilization, thermal gradients, effectiveness factors, and required catalyst quantity, and in some cases the distributed or segmented designs gave similar or better performance with a lot less catalyst and lower thermal gradients, but those conclusions came from a structured comparison across physically meaningful quantities, not from eyeballing plots. That same mindset should guide AI-assisted development, so don’t pick a model just because its loss function is lower, ask whether it conserves mass and energy, whether it behaves sensibly outside the center of the training domain, whether it responds reasonably to boundary-condition changes, and whether the result is actually useful for an engineering decision. Sometimes the simpler model wins, sometimes the more accurate one isn’t worth the extra computational cost, and there’s no universal answer, but that uncertainty isn’t a weakness, it’s just part of engineering.
The takeaway from our experience isn’t that expensive AI subscriptions are worthless, because some of those advanced models genuinely do handle certain tasks better and cloud computing becomes a necessity when your dataset or training requirements outgrow what you can run locally, but you should add those tools only where they solve a real, demonstrated limitation, not because a fancy toolchain makes you look more cutting edge. A disciplined workflow built around one primary assistant, local verification, version control, small milestones, and physics-based validation can actually support a whole lot of serious engineering work without breaking the bank, and more importantly it produces results that someone else can understand and reproduce. That’s where engineering and AI ought to meet, with AI cutting down the time it takes to implement ideas, explore alternatives, and set up the computational structure, but it cannot take over the responsibility of deciding whether the equations are appropriate, whether the assumptions hold up, or whether the final result deserves any real confidence. So the strongest engineering AI workflow isn’t the one with the most models, it’s the one where every computational result still has to answer to physics.