I’ve lost count of how many conversations I’ve had in the last few months that start the same way. Someone brings up AI, someone else brings up automation, and within a few minutes the conversation has quietly drifted into a discussion about AI replacing engineers altogether.
It happens in client meetings, at conferences, even in casual chats over coffee between sessions. The typical questions:
“Can AI design products?”
“Can AI replace engineers?”
“Can AI automate engineering?”
And every time, I find myself pushing back a little. After twenty-five years working with engineering organizations across PLM, embedded systems, and digital engineering, my answer is usually the same. We are asking the wrong questions.
Not because I don’t believe in AI. I do. But we’ve let the hype get ahead of what AI can realistically do in engineering today, and more importantly, what it should be doing.
A conversation that has been running for months
I’ve been in an ongoing discussion with a passenger car OEM for the better part of a year now on how they should approach AI in engineering. It has become the clearest illustration I have of why the hype and the reality keep talking past each other.
Their engineering head is convinced that design validation should be completely AI driven. He had seen a demo from a startup, it was impressive, and he came away believing the problem was essentially solved. In a boardroom, that demo made a very compelling case.
His engineering team saw it differently. They were not willing to bet product decisions on unproven technology, and they said so. Their position was not that AI is useless. It was that they were being handed an instructor when what they needed was an assistant.
That gap sat there for months. The leadership wanted automation. The team wanted help. Neither side was wrong, and the discussion went nowhere because both were answering a different question.
What eventually moved it was something far less ambitious than the demo. We showed them a simple assistance scenario: an engineer looking for relevant existing parts, with AI doing the searching and surfacing across their part data instead of the engineer working through it manually. No autonomy, no decisions made on the engineer’s behalf, nothing that had to be trusted blindly. The team adopted it without resistance, because it made their day easier without asking them to hand over judgment.
Same technology. Same organization. Completely different reception. The only thing that changed was the framing.
Engineers need an assistant, not an instructor
Here’s the thing about engineers that doesn’t get said enough: they don’t want to be told what to do. They want help getting to the answer faster. There’s a real difference between those two things, and a lot of AI conversations miss it entirely.
An instructor tells you the answer. An assistant helps you get there. Engineers, by training and temperament, trust their own judgment on complex problems, and rightly so that judgment is built on years of experience, physics, materials knowledge, and an understanding of how things fail in the real world. What they don’t want, and don’t have time for, is redoing routine work that a good assistant could have handled while they focused on the actual engineering problem in front of them.
In practicality, AI can’t own a complex engineering task end to end. Not because the models aren’t capable they get better every few months but because someone still has to be accountable for the outcome. It can, however, work alongside an engineer and augment what they’re already doing. That distinction is the whole argument of this piece.
Automation, Augmentation, and Mechanization three very different things
When people talk about “using AI,” they usually mean one of three fairly different things, even if they don’t realize it. There’s automation, where AI takes over a task end to end and runs it without a human in the loop. There’s mechanization, where AI takes over the repetitive, mechanical parts of a task while leaving the judgment calls to a person. And there’s augmentation, where AI works alongside a human, making them faster and more capable, without ever fully taking the wheel.
Most of the AI hype in engineering circles is really hype about automation. That’s where the conversation goes wrong, and it is exactly what happened in that boardroom.
Why full automation runs into a wall in engineering
The engineering space has a real limitation on how much automation it can absorb, and it has less to do with the maturity of the AI than most people assume.
The first constraint is data. Product designs, simulation results, test data, firmware code this is some of the most sensitive intellectual property an organization owns, and most organizations are careful about where it goes and who can see it. This one is being solved. Private deployments, in-tenant models, zero-retention configurations, and smaller domain-tuned models running inside the firewall are already addressing it. I expect this constraint to keep shrinking.
The second constraint is not going anywhere, and it is the one that matters more.
Engineering decisions carry accountability. Someone signs off on the design. Someone is answerable when a part fails in the field. Someone has to defend that decision to a certification body, a regulator, or a customer’s quality audit, sometimes years later. In automotive, that exposure can run to a recall. That responsibility sits with a named person, and no model absorbs it no matter how good the model gets. You cannot put an AI system in front of an auditor and ask it to justify a design decision.
This is why the automation ceiling in engineering is not a temporary technology problem waiting for the next model release. It is structural. And it is exactly why the right frame for AI in engineering isn’t automation at all. It’s assistance.
Where augmentation actually earns its keep
Once you stop chasing automation and start thinking in terms of augmentation, a lot of useful applications show up. They are less flashy than the demos, which is probably why they get talked about less.
Finding relevant parts is the one I described above, and it remains one of the highest-value, lowest-risk places to start. Engineers routinely redesign what already exists somewhere in the system, simply because finding it was harder than recreating it.
Design validation the very thing that OEM’s engineering head wanted fully automated works well when it is scoped as assistance. AI reviews design documentation against known standards and flags inconsistencies for an engineer to look at, rather than making the call itself. Firmware code is similar: AI can write portions of code or validate specific pieces of it, working in tandem with a developer who reviews and integrates the output, rather than shipping code on its own.
Design standards are often long, dense, and scattered across documents that engineers only reference when they need to. AI is good at summarizing these and surfacing the relevant clause quickly, saving an engineer from working through a two-hundred-page document to find one paragraph.
Simulation is another area where I’ve seen real value. Formulating results from simulation analysis faster, instead of an engineer manually interpreting output data, is exactly the kind of task where augmentation shines. And test data is perhaps the most underrated use case of all. Engineering teams generate enormous volumes of test data, and AI can go through it, identify patterns, and help reduce the number of physical tests needed going forward. That’s not automation replacing testing. That’s augmentation making testing smarter.
What’s common across all of these is that the engineer stays in the decision seat. AI does the reading, the sorting, the drafting, and the first pass. The judgment, and the accountability that comes with it, stays where it belongs.
Where I would start
Clients ask me where to point their first AI budget, so let me be direct about it.
Start where the volume is high, the risk is low, and the engineer stays in control. Part and design reuse, standards and specification summarization, test data analysis. These share three properties: the engineer verifies the output immediately, a wrong answer costs seconds rather than a recall, and the value is visible in the first week. Adoption follows on its own, because the team wants the tool rather than being told to use it.
Wait on anything where AI output would flow into a decision without a human reviewing it, and on anything touching certification or regulatory sign-off. Not forever but not first. Those need governance, traceability, and an audit trail that most organizations have not built yet.
And be sceptical of the demo. A demo is built to work. Your engineering environment is built to survive twenty years of change orders, legacy data, and supplier variation.
The distance between those two is where most AI initiatives quietly stall.
Conclusion
So where does that leave us? AI in engineering has to move beyond the hype of automation and settle into what it’s actually good at: assistance. Not an instructor standing over an engineer’s shoulder, but a capable assistant working alongside one. That OEM is now running AI in engineering. Not the way it was pitched in the demo, and not the way their engineering head first imagined it. But it is in use, engineers asked for more of it, and it is delivering value which is more than can be said for most of the ambitious pilots I have watched stall over the past two years.
Augmentation, not automation, is where AI earns its place in the engineering world. It keeps engineering judgment where it belongs with the engineer while letting AI take on the volume, the repetition, and the grind that was never a good use of engineering talent in the first place.
Engineering has always been about solving complex problems. AI doesn’t change that!
Rahul Deshpande
He is the CEO & Founder of BrainWave Consulting with over 30+ years of industry experience in PLM, digital engineering, and digital transformation.
We provide custom software development, cloud solutions, IT infrastructure setup, system integration, and ongoing tech support.
It depends on the scope. Small projects may take 2–4 weeks, while larger systems can take 2–3 months or more.
Yes, we offer maintenance and support packages to keep your system secure, updated, and running smoothly.
Absolutely. Every solution we deliver is tailored specifically to each client’s business goals and operations.
We’ve worked with clients in retail, healthcare, logistics, finance, and more.
Simply contact us through our website or email, and we’ll schedule a free consultation to understand your needs.
At BrainWave (BWC), our mission is to empower businesses with cutting-edge technology solutions. We believe in the transformative power of innovation and are committed to helping our clients achieve their goals.
Information Security Management System
