The Engineer's 89 Percent: A Take on Labor Market Impacts of AI

The Gap Worth Reading Carefully

On 5 March 2026, Anthropic published "Labor Market Impacts of AI: A New Measure and Early Evidence." The paper introduces a metric called observed exposure: not what LLMs could theoretically automate, but what they are actually being used for in real professional settings. Figure 2 stopped me mid-scroll.

The measure combines three sources: O*NET task descriptions for roughly 800 occupations, real Claude workplace usage data from Anthropic's Economic Index, and the β metric from Eloundou et al. (2023), a human-rated score of theoretical LLM feasibility. Observed exposure takes the theoretically feasible tasks, filters them down to those actually appearing in professional Claude usage, and aggregates the result to occupation level.

The chart has two bars per occupation. Blue is theoretical. Red is observed. For Architecture and Engineering, my own category, the blue sits at 84.8 percent and the red is close to zero. For Computer and Mathematical occupations, the blue reaches 94.3 percent, and that number matters here because many engineering tasks sit squarely across both categories in practice. An engineer who spends as much time writing code or running analytics straddles those two figures, landing somewhere around 89 percent theoretical coverage on average. The claim, taken at face value, is that the large majority of tasks in my profession are within the theoretical reach of today's large language models to speed up at least twofold.

I read that headline number with caution, and I say so as a heavy daily user of these tools outside the software and AI development communities that dominate the observed data.

Three reasons to read that 84.8 percent carefully.

The first: the β metric is frozen in early 2023. The Anthropic authors flag this themselves. Models have changed; so have the tasks we set them.

The second: it is a human judgment, not an empirical finding. The distance between sounds feasible and reliably works is the distance every engineer knows between a pilot study and a qualified production system.

The third: the near-zero observed bar is the most honest signal. That gap reflects model limitations, workflow integration barriers, liability exposure, and the absence of domain-specific graphical and spatial tools that general-purpose text models do not yet couple to.

A more accurate reading of the 84.8 percent is this: a significant fraction of engineering task descriptions do not obviously rule out AI assistance. That is a careful, honest claim, and it is different from the headline reading that AI is already doubling engineering productivity across the board. The Anthropic paper does not argue the latter, but casual readers will, and the distinction is worth holding onto.

One definition before we go further. When I use the word AI here, I mean large language models, the text-first probabilistic systems behind ChatGPT, Claude, Gemini, and Llama. I am not talking about deep learning surrogates for CFD, physics-informed neural networks, or 3D geometric learning stacks. Those come later.

And yes, I know the jobs question is in the room. My honest current view: in my industry, AI is not taking jobs yet. It is making those of us who have embraced it more productive. That is observation, not reassurance, and it may not hold forever.

To test Figure 2 on the ground, I ran two engineering exercises I could hold in my own hands: one fair challenge where LLMs play to their strengths, one unfair challenge where they work against their known weaknesses with graphical and spatial output.

Two Wiser Years and Two Hundred AI Years

I began experimenting with large language models soon after the release of ChatGPT. ChatGPT first, then Anthropic Claude, Google Gemini, and others along the way. Over the two years since, those tools have moved from my curiosity folder into the central working tools of my professional life and regular tools I use to manage my personal life.

That curiosity is what drove the Ferrari Roma experiment in May 2024.

My method was simple. My knowledge was more limited. I cast GPT-4 as an automotive powertrain development specialist and walked it through a progressive chain of prompts. We started with the mathematical expression of longitudinal forces on a vehicle, then moved through drag coefficient and tyre sizing for the Ferrari Roma. I asked it to size an electric motor for 0 to 100 kilometres per hour in 3 seconds and 0 to 200 in 9 seconds. Then to size the battery for a 200 kilometre range on the European urban drive cycle, by building a mathematical model and running it.

GPT-4's responses were reasonably good, with one notable exception. It lacked complex mathematical calculations, often using average energy consumption figures for energy calculations, and the battery capacity estimation was exactly the kind of shortcut that an experienced engineer would flag immediately. Even when I explicitly prompted the model to build a mathematical model with the longitudinal forces and run the cycle, the output was a simple average calculation dressed up in engineering language.

I remember feeling, as I read those responses, somehow relieved. I was quite confident that I would still have a job in the future.

GPT-4o, released shortly after, was a step change. It did not only answer the prompts, it wrote Python code for more detailed analysis, and I suspect the memory function that OpenAI had recently introduced recognised my habit of debugging personal code on ChatGPT and adapted its output accordingly.

That was the first time I saw, from the inside, a large language model do something that felt qualitatively different from autocomplete.

I repeated the Ferrari Roma exercise two years later using Claude Opus 4.6 on the Claude desktop app in Cowork mode. Before I claim the result as evidence of model progress, a structural caveat is worth making. What I ran in May 2024 was a chatbot conversation with GPT-4, turn by turn, with no tool access. What I ran in 2026 was a full desktop agent: Claude Opus 4.6 autonomously planning the analysis, writing and executing code, and iterating across my file system between prompts. Co-work mode, announced by Anthropic in January 2026, is a fundamentally different interaction paradigm from a chat interface, and the output reflects that.

The gap between the two sessions is the product of three things moving at once: genuine model capability, a shift from conversational to agent-based operation, and an orchestration layer that had no equivalent in 2024. Credit all three honestly and the combined effect is still dramatic.

I had become two years wiser. The tooling had advanced by something closer to two hundred.

The session produced four Python modules, each a coherent engineering artefact. The first defines the full longitudinal dynamics of the vehicle, with Ferrari Roma parameters estimated from transparent reasoning, the 0.29 Ferrari-published drag coefficient, a frontal area derived via the Hucho formula, the OEM staggered 245/35 and 285/35 ZR20 tyre fitment, a dynamic rolling radius of 0.343 metres, and a full mass budget that removes the ICE powertrain and adds motor, inverter, battery, and ancillaries to arrive at an estimated 1,820 kilograms.

The second module performs analytical motor sizing via the impulse-momentum theorem, cross-checked against the tyre traction limit, and correctly identifies that the 3-second target for 0 to 100 is traction-limited rather than power-limited, with the minimum achievable time on rear-wheel drive at approximately 3.8 seconds regardless of motor power. This is the exact engineering conclusion an expert dynamics engineer would have reached by hand, and it is exactly the conclusion GPT-4 missed two years ago. The third module runs a forward-Euler simulation at one-millisecond resolution using a PMSM torque-speed envelope, yielding 3.87 seconds to 100 kilometres per hour, confirming the traction limit, and 8.98 seconds to 200, meeting the original target.

The fourth module synthesises a WLTP Class 3 drive cycle from the official phase definitions and runs the full longitudinal dynamics model against it, applying a complete efficiency chain of 87.5 percent overall traction and 85.7 percent regen capturing 70 percent of braking events. The result is 14.4 kWh per 100 kilometres, a 28.7 kWh usable energy requirement for a 200 kilometre target, and a nameplate 35.9 kWh pack at a 10 to 90 percent state-of-charge window, massing 211 kilograms at 170 Wh/kg pack-level density. The module flags, in its own written observations, that this is significantly lighter than the 450 kilograms initially budgeted, and that an iterative mass-convergence loop would refine both figures simultaneously.

This is the fair challenge passing with distinction. Text, mathematics, physics, and programming. The territory on which LLMs are strongest. Every meaningful engineering decision in that study was mine, the choice of a 500 kW peak-power target, the acceptance that the 3-second target would have to be renegotiated against AWD cost and complexity, the NMC pack chemistry benchmark, the bounds on the state-of-charge window, the instinct to probe the traction limit before arguing about motor power. The AI made it possible to execute them in an afternoon rather than a week, with full code, full plots, and full documentation at the end. That is not automation. That is amplification.

I can still hear from some of my engineers the familiar pushback, well, I could have done that in Excel. Sure, it would be possible, but probably not as repeatable, not as quick, without version control, and with a great deal of fiddling with parameters each time you wanted to change a single input.

If the story ended there, I would be comfortably on the side of Figure 2's combined 89 percent.

The Second Test, and a Failure I Need to Be Honest About

The second challenge was less fair. I chose it deliberately. I set out to design a twelve-cell Cell Monitoring Unit front-end for a battery management system, based on the Analog Devices LTC6811-1, with all the automotive-grade qualifications that the application demands. I am a battery and electrification engineer by training and by trade. I have the necessary skills to draw the schematic of a circuit of this complexity in a single working day, and in the worst case a few days. I had been hoping that, with a competent AI partner, I could complete the schematic in a few hours.

I did not complete it, and the reason is instructive.

Before starting the task, I did some research on how I could use open-source software packages to design electronic circuit schematics using LLMs or Python. My research pointed me to KiCad, an open-source electronic circuit and PCB board design tool that, it sounds fair to say, has come a long distance from being the hobbyist tool I remembered from when I last drew a schematic a decade ago. KiCad is open-source, it is well integrated with Python through libraries such as SKiDL, and it sits at the centre of a growing community of engineers who are pushing programmatic circuit design forward.

I fed the session a full context pack. The LTC6811-1 datasheet as published by Analog Devices. The PDF of the DC2259A demonstration board schematic, which is the canonical reference design for this part. A group of supporting documents. The model, to its credit, correctly identified the datasheet and the demonstration board PDF as the two most relevant inputs and used them as its working reference. It then proceeded to iterate on a KiCad schematic, passing the output through SKiDL, the Python library that translates programmatic circuit descriptions into KiCad-compatible files.

By the fifth iteration, and after approximately eight hours of working through it alongside the tool, the schematic had not converged to a human-readable layout, and the electrical rules check was not clean. That is the expected outcome when a general-purpose text model is asked to drive a graphical EDA tool without a dedicated spatial-reasoning integration layer. The model was reasoning well about components, topologies, and application notes. It was reasoning poorly about the two-dimensional canvas on which a schematic lives. Those are different classes of problem, and current general-purpose LLMs are stronger on the first than on the second.

I stopped. Not because the failure was catastrophic, but because the honest accounting had tilted the wrong way. A day of my own time would have produced a cleaner result than eight hours of co-iteration with a general-purpose LLM driving an open-source EDA stack.

If I could not force this task into an hour-scale win, or at least halve the time it would have taken me unaided, which is the original definition of the doubling claim in the Anthropic article, the task sits outside the current reach of a general-purpose LLM operating on open-source circuit design tools. It is not a statement about any specific model, it is a statement about the tool category, the integration layer, and the class of problem.

This is the unfair challenge, and it fails on the central deliverable. Graphical output, spatial reasoning, and the kind of tacit knowledge that a circuit designer develops over years of drawing and laying out nets on a two-dimensional canvas, these are the territory where today's general-purpose LLMs struggle. The red area of Figure 2 for Architecture and Engineering, stubbornly close to zero, is not merely a reflection of slow adoption. It reflects the fact that a great deal of engineering work is graphical, and current general-purpose LLMs are fundamentally text-first systems for which geometry and layout remain awkward cousins.

The Silver Lining Inside the Failure

A careful reading of this result shows it is not a total loss.

Very early in the process, before the schematic iterations began, the AI produced two outputs that I found genuinely valuable. The first was an automotive-grade design guideline for the CMU circuit, articulating the qualification standards that each component class needed to meet. AEC-Q100 Grade 1 for the main integrated circuit, AEC-Q101 for discrete semiconductors, AEC-Q200 for all passives, magnetics, and connectors, along with the reasoning behind each requirement and the temperature ranges that would define acceptable parts. The second was a set of component alternatives, for the pulse transformer, the bidirectional transient voltage suppressor diodes, the cell-measurement-path capacitor dielectric, with each alternative cross-referenced against the Analog Devices application notes for the LTC681x family. If I had been starting this design manually as a human, without AI assistance, I would have greatly benefited from both of these documents. They would have saved me perhaps half a day of my own preliminary research, and they would have surfaced candidate parts I might have missed.

The honest lesson from this second use case is therefore more nuanced than a simple failure verdict. The AI did not converge on the central engineering deliverable, the readable schematic with a clean ERC, and that is significant. But the same AI succeeded on the adjacent research and selection tasks, producing documents that were useful, well-referenced, and clearly adapted to the specific problem at hand. The pattern is consistent with what Figure 2's blue and red regions would suggest if read generously. Text-heavy, knowledge-assembly engineering work is within reach. Graphically expressive design output is not, at least not yet, and certainly not through general-purpose LLMs operating on EDA tools without more specialised integration.

What Is Coming For the Graphical Problem

I do not think the schematic problem stays unsolved for long. The open-source community, and the established EDA players, are already building the scaffolding that would let an AI agent complete exactly the task I abandoned. Model Context Protocol servers and command-line-callable interfaces for many software systems are being developed to ease integration between AI systems and other software as tools. The combination of a capable LLM, a purpose-built MCP server that understands a schematic editor's native representation, and a well-curated component context library, is, in my assessment, enough to push this category of work into the green for the next generation of models. I expect the move to happen not far off for the simpler classes of schematic, and to mature across more demanding automotive and industrial contexts over the following few years. If pressed, I would bet on five years. I have already started coming across a handful of AI-first circuit design start-ups appearing.

In the three-dimensional design space the progress is further along. The industry's direction is visible across a cluster of announcements spanning late 2025 and early 2026, a trajectory that NVIDIA's GTC 2026 programme in March reflected and reinforced, without being the originating event for any of them.

Neural Concept's AI Design Copilot, launched at CES 2026 after a one hundred million dollar round led by Goldman Sachs, predicts physics simulation results directly from CAD geometry in approximately 30 milliseconds, enabling engineers to evaluate thousands of design variants in minutes rather than days. BeyondMath, a UK-based company that recently extended its seed round to 18.5 million dollars, runs full-fidelity transient physics simulations through a foundational AI model trained on first-principles physics, and is delivering on a 19 million dollar STRATA programme with Honeywell for aircraft component design. PhysicsX, also UK-based and now valued near unicorn status after a 155 million dollar Series B with NVIDIA's NVentures participation, builds Large Physics Models as high-fidelity surrogates for CFD and FEA. Luminary Cloud offers GPU-native solvers with Lumi AI acting as an engineering copilot integrated into CAD, CAE, and analysis workflows.

These are purpose-built physics AI systems, complementary to general-purpose LLMs rather than replacements for them. They address the exact class of graphical and spatial problem where today's text-first models struggle, and the two categories of tool are beginning to sit alongside each other in serious engineering workflows.

My friend Andy Fine at Fine Physics has been doing the essential work of mapping this landscape, and his Software for Hardware Market Landscape, which he updates and publishes on LinkedIn, is the best single chart I know of for understanding how the engineering software industry is reorganising itself for the new age. The incumbents, Dassault, Synopsys, Autodesk, Cadence, PTC, and Siemens, sit alongside the specialist independents like MathWorks and COMSOL, and a much larger generation of AI-native challengers organised by function, from generative CAD through physics pre-trained AI to agent-based data platforms. This is a serious and rapidly maturing landscape, and within it, the schematic and PCB layout problem is simply one of the last remaining frontiers.

The Question I Keep Being Asked

The question that comes up at almost every professional gathering now is whether AI is taking jobs. My answer, with the caveat that it is my own view shaped by my own sector and my own daily observation, is that in engineering, AI is not taking jobs yet. It is making the engineers who have embraced it materially more productive. The fair challenge with the Ferrari Roma showed me that. The unfair challenge with the CMU showed me where the productivity story runs out, which is exactly where domain judgment and specialised graphical tools become more valuable than general-purpose text generation.

The engineering deliverables described here are only one part of how we actually use AI day to day. Across my working life, AI also plays a significant role in data analytics, in programming, in mathematical model development, in strategy work, in marketing and communication, in sales, and in a range of other business contexts where the text-first, probabilistic strengths of today's models align with the task at hand. The productivity gain in those adjacent domains is, in my observation, at least as large as in engineering proper, and it arrives with far fewer of the graphical and spatial obstacles I ran into with the CMU.

I am not replacing engineers with AI today. I am asking every engineer I work with to pick up these tools.

Closing

An unexpected consequence of the electronic circuit design experiment, and one I did not anticipate when I started, was that I rediscovered skills I had forgotten I possessed. Fair to say that the last time I drew an electronic circuit was about ten years ago, and I did not remember all of the standards we would apply in component selection. Throughout the process, even though the deliverable itself did not converge, I very quickly refreshed knowledge that had settled into the back of my head. It felt, to my own surprise, like the experience of starting to code again.

That rediscovery followed me into the working week. In a leadership meeting a few days later, I told my head of electronics I was thinking of designing the next CMU circuit myself. He looked back at me, not entirely convinced, and I cannot fault him for it. But somehow, as we say in motorsports, I feel ready to get back on the spanners.

About thirty-five years ago, when I was a young teenager, I wrote my first lines of code on an Amstrad, thanks to Lord Sugar whose impact has been far reaching the boarders of the United Kingdom, drawing a round circle in the middle of the screen in BASIC. As my career moved into leadership roles within the last ten years, I stopped being hands-on. In the last few years, I have got back into coding, and the reason is almost embarrassing in its simplicity. It was because of my exploration of AI, and Python, the language of AI, is what brought me back to the keyboard. A secondary effect of working with these tools has been the quiet return of craft, and that, I think, is a consequence of AI adoption that the Anthropic paper was never going to measure.

The future is exciting, and I say so as someone who has spent enough time inside it to distinguish excitement from hype. I would like to acknowledge the work of the community around these questions, the open-source community, the AI frontier labs, the new generation of modelling and simulation companies, the engineering software businesses, and the incumbents, everyone who is trying to make the future of engineering more efficient and more precise.

The Engineer's 89 percent is not the share that AI can do without us. It is the share that becomes possible when experienced engineers pick up the tools, use them honestly, and know exactly where to make them stronger or where to walk away. At least for now.

---

Selin Aria Tur | Managing Director & CTO, Williams Grand Prix Technologies

© 2026 Selin Aria Tur. Freely quotable/republishable with credit; contact for other uses.

About the Author

Selin Aria Tur is Managing Director and Chief Technology Officer at Williams Grand Prix Technologies. She has spent twenty-five years developing battery and electrification systems across Formula 1, Formula E, passenger and commercial vehicle applications, and she now applies the same performance-first rigour to the integration of artificial intelligence tools into engineering practice. She writes From Track to Trench for engineers, technology executives, and investors who want to understand where advanced technology is actually heading.

---

References

1. Anthropic. "Labor Market Impacts of AI: A New Measure and Early Evidence." Anthropic Research, 5 March 2026. https://www.anthropic.com/research/labor-market-impacts

2. Tur, Selin. "My 'helpful' AI Powertrain Development Assistant." LinkedIn, 16 May 2024. https://www.linkedin.com/pulse/my-helpful-ai-powertrain-development-assistant-selin-tur-c6xme/

3. Eloundou, T., Manning, S., Mishkin, P., Rock, D. "GPTs are GPTs: An early look at the labor market impact potential of large language models." arXiv preprint, 2023. https://arxiv.org/abs/2303.10130

4. Neural Concept. "Neural Concept Introduces a Physics- and Geometry-Aware AI Design Copilot." January 2026. https://tinyurl.com/2s3ua8sh

5. BeyondMath. "BeyondMath completes $18.5 million Seed Round to scale world's largest foundational physics AI model." February 2026. https://beyondmath.com/news/seed-round-announcement

6. PhysicsX. Platform overview. https://www.physicsx.ai/

7. Luminary Cloud. Physics AI Platform. https://www.luminarycloud.com/

8. Fine, Andy. "Software for Hardware Market Landscape" (Fall 2025). LinkedIn. https://tinyurl.com/3hw3skn5

9. Analog Devices. LTC6811-1 Multicell Battery Monitor datasheet. https://www.analog.com/en/products/ltc6811-1.html

10. SKiDL — Python circuit design library. https://github.com/devbisme/skidl

11. KiCad Project. Open-source electronic design automation suite. https://www.kicad.org/

12. NVIDIA GTC 2026 programme. Engineering simulation sessions. https://www.nvidia.com/gtc/

---

Disclosure: Anthropic is a technology partner of Williams Racing. The views in this article are my personal views as a practising engineer and heavy daily user of these tools, and do not represent a Williams or Anthropic position. I use tools from several AI providers across my working and personal life, and I have tried to describe what I observed in each exercise without softening either the successes or the shortcomings.

On method: I am a technologically curious engineer, and that curiosity extends to every part of my working and personal life, including how I research and write. In producing this piece, I have made use of various AI tools, namely Perplexity, Anthropic Claude Desktop app, Anthropic Claude Code and VSC and Google Gemini. What those tools cannot provide, however, is the more than ten hours I spent deep-diving the subject matter, drafting, and editing, nor the two decades of engineering experience and personal memoir that I hope give this writing its texture. My aim is that the reader leaves having learnt something, thought about something, and perhaps been entertained along the way. I hold my strong views loosely and I recognise the change of opinions as part of the growth journey.

---

This article was originally published on LinkedIn on 19 April 2026.