What 30 Years of Engineering Taught Me About Where AI Actually Helps
Every technical professional knows the feeling: you have the expertise to solve a problem, but most of your day is consumed by overhead. File management. Data formatting. Debugging input decks. Building GUIs around calculations. Navigating systems designed for a different era. Report templates. Status updates.
At DeQuorum we call this the friction tax — the procedural overhead between you and the value-creating work you’re actually trained for. And across thirty years in engineering, from crash simulation to Formula 1 to autonomous vehicles, I’ve watched that tax shrink with every tool generation. What happened next was always the same: the work didn’t shrink with it. It expanded.
Hand-Meshing and Mainframes
When I started as a stress analyst at GM Holden in the early 1990s, crash simulation meant hand-meshing CAD models. You placed finite elements manually on geometry surfaces — squares and triangles, one at a time. The analysis software, LS-DYNA, used text-based keyword files where a misplaced parameter in the wrong column could silently corrupt your entire simulation. Jobs ran overnight on mainframes, sometimes for weeks on machines in America. A misplaced decimal in a contact definition could waste a fortnight of compute time.
Debugging consumed more engineering time than actual structural analysis. The friction tax was enormous — probably 70% of a crash analyst’s time went into file preparation, error-checking, and compute management. Maybe 30% went into the engineering judgment that the whole exercise was supposed to be about.
Then HyperMesh arrived and automated the meshing.
In the 3D solid modelling domain, CATIA could now auto-mesh solid models — the element quality wasn’t as good as hand-placed elements, but the volume of work you could do meant better overall insight into structural behaviour. Both domains of structural analysis programmes went from five or six configurations to hundreds.
The friction shrank. The engineering expanded. Nobody went home early.
The Pascal-to-Visual-Basic Moment
I saw the same pattern in programming. In the Pascal era, building an engineering tool meant spending 80% of your time on the GUI and 20% on the actual calculations. Every button, every input field, every display widget had to be hand-coded. The engineering logic — the bit that actually mattered — was almost an afterthought squeezed into the remaining time.
When I moved to Visual Basic — which purists considered a Mickey Mouse language — that ratio flipped. Suddenly, 80% of my time went into the engineering logic, 20% into the interface. The compute speed wasn’t dramatically different. What changed was where I spent my time.
This is the point that most discussions about AI tools miss entirely. People focus on raw compute power — how fast the processor is, how many cores you have, how quickly the solver converges. But for most engineering work, the binding constraint has never been the computer. It’s been the human. Specifically, it’s been the friction between the human and the valuable work.
A faster processor that still requires three hours of manual file setup is worth less than a slower processor with an intelligent pre-processor that gets you running in twenty minutes. The bottleneck moves from compute to cognition — and then from cognition to friction around cognition.
The Oxford Laboratory
I recently visited a laboratory at University of Oxford conducting medical research. They had a million-dollar machine for analysing test compounds. The bottleneck wasn’t the machine — it was deciding which tests to run and setting up the Excel files to drive it. The machine sat idle while researchers wrangled data formats. AI attacking that friction could push utilisation from 40% to 90%, making experiments that weren’t previously worth the setup cost suddenly viable.
The total research output expands because the friction between having a hypothesis and testing it collapses. Not because the machine got faster. Not because the researcher got smarter. Because the tax on their time shrank.
The Race Car: Where Friction Meets Complexity
In racecar engineering, the design space is enormous and highly non-linear. Aerodynamics are non-linear. Tyres are non-linear. The interactions between them — downforce affecting tyre loading, which affects temperature, which affects grip, which changes the aero platform, which changes downforce — create a coupled system that defies simple optimisation. Add fuel load, track evolution, weather, strategy, and regulatory constraints, and you have a design space so large that no team can explore more than a fraction of it. In fact, we rely on the rules to constrain the total problem space to a degree!
AI does two things here. First, the familiar friction reduction: build parametric models faster, automate iteration, and generate report templates. Second, something qualitatively different — surrogate modelling, where neural networks approximate the non-linear physics relationships trained on CFD and tyre data, enabling exploration of the full design space at viable speed.
But surrogate models are interpolators, not extrapolators. They work within the training envelope. Outside it — novel concepts, new tyre compounds, regulation changes — they produce confidently wrong answers. The engineer who understands what the model can’t tell them wins the race.
This is the expert advantage in practice: domain knowledge doesn’t just help you use AI better. It tells you when to stop trusting it.
The Pattern
Today, with AI assistance, I can rebuild engineering tools that took months in days, and add optimisation layers that weren’t previously worth the development effort. The pattern is identical across three decades and multiple tool generations:
The tool arrives. The friction shrinks. The expert’s output expands. The job changes shape rather than disappearing.
In economics, this pattern has a name. William Stanley Jevons identified it in 1865, watching British coal consumption rise as steam engines became more efficient. Make something cheaper to use, and people use more of it. The Jevons paradox.
Make crash analysis cheaper, and engineers do more crash analysis. Make experimentation faster, and researchers run more experiments. Make design iteration cheaper, and teams explore more of the design space. The demand for the output is elastic — there’s always more crash safety to improve, more compounds to test, more lap time to find. Efficiency creates expansion, not contraction.
But There’s a Question
Every previous friction reduction in my career led to more work, not less. Hand-meshing to HyperMesh. Pascal GUIs to Visual Basic. Overnight mainframe runs to desktop clusters. The Jevons paradox has held true for 30 years.
But I’ve also watched the administrative infrastructure around engineering teams shrink continuously — and I watched it happen so gradually that nobody remarked on it at the time.
When I first worked at General Motors , every memo was printed out, and everyone on the CC list received a physical copy, stapled and placed in their pigeonhole. Someone’s job was to print, collate, and distribute those memos. The BCC — blind carbon copy — existed because in the days of actual carbon copy paper, you could add extra recipients to the copy list without the primary recipients knowing. Someone had to manage that distribution. Email didn’t just speed up that work. It made the entire role vanish. And the economy didn’t need more memo distribution then. It needed zero.
When I arrived at McLaren Racing in the early 2000s, we still had the last remnants of having a tea lady — a very British institution. I’d seen something similar when I finished university in Australia in the 1990s. The role existed because keeping engineers productive meant having someone bring tea to their desks rather than losing 15 minutes in the canteen queue. Better kitchen facilities and cultural shifts eliminated the role entirely. Nobody’s job expanded to absorb the freed capacity. The friction just disappeared.
The drawing office. The print room. The filing department. The data entry team. The pool of secretaries. All progressively automated away over decades.
Here’s what’s different about this moment: AI is attacking all the remaining friction layers simultaneously. Setup automation, code generation, file debugging, iteration management, report writing, data formatting — every layer of overhead that previously shrank one at a time is collapsing at once.
For the engineers, that’s the Jevons paradox in overdrive — more output, more exploration, more ambition. But for the roles that existed to manage the friction itself? That’s a different story entirely. And it leads to an uncomfortable question about whether the economic optimism that applies so reliably to expert technical work extends to everyone else.
This is the first in a three-part series on AI, friction, and the future of work. Part 2 explores a fundamental limit on AI’s economic impact — the \”speed of light\” problem. Part 3 examines what happens to workers whose entire job is the friction AI eliminates.
DeQuorum http://www.dequorum.tech/insights
Mark Preston is a mechanical engineer and motorsport executive with 30+ years in Formula 1 , Formula E (five Championships in the FIA – Fédération Internationale de l’Automobile Formula E World Championship as Team Principal of DS Automobiles TECHEETAH Formula E Team ), and autonomous vehicles. He writes about engineering leadership, AI strategy, and the lessons motorsport teaches about decision-making under uncertainty.
Mike Potts is an entrepreneur and technology leader working at the intersection of data, AI, and autonomous systems. He founded StreetDrone , a UK pioneer in autonomous delivery vehicles (acquired by Oxa in 2024), and earlier built and exited Elisa Interactive, a digital data and analytics consultancy acquired by Havas Media Network , where he later served as Chief Data Officer. He writes about AI-native systems, decision intelligence, and how data-driven technology is transforming mobility and infrastructure at DeQuorum .
