⏩ TL;DR
It depends on the task, and most teams are not measuring it. A 2025 trial by METR found experienced developers took 19% longer with AI while believing they were faster, and the researchers now call that result out of date. In our 2026 survey of 281 UK electronics professionals, 40% say AI is cutting repetitive work and 33% say it is adding verification work. Time the whole job, including checking, before you decide.
Table of Contents
Ask an embedded systems engineer whether AI makes them faster and most will say yes. I took on that question in my talk at the Electronics Design Show, because the studies that put a stopwatch on it give a more mixed answer.
![Dunstan Power speaking at EDS [Engineering Design Show] 2026](https://www.bytesnap.com/wp-content/uploads/2026/10/Dunstan-EDS-13.jpg)
Most of the controlled evidence so far comes from software developers, and I will say where that matters for hardware work. This article sets out what I think we know, what we don’t, and what our own survey found.
What the studies tell us
The best known result is a 2025 randomised trial by METR, which timed 16 experienced open source developers on 246 real issues in repositories they knew well, with and without AI tools. Tasks took 19% longer with AI. Before the trial the developers expected AI to speed them up by 24%, and afterwards they still believed it had sped them up by about 20%.
Treat that number as history. METR’s own page now says the results are out of date, and its February 2026 update says developers are likely more sped up now. It calls its newer data “very weak evidence for the size of this increase”, because many developers would no longer work without AI and so would not join the no AI half of the study.
A second study looked at learning, not everyday work. Anthropic, the company behind Claude, ran a randomised trial in January 2026 with 52 mostly junior software engineers learning an unfamiliar Python library.
The AI group finished about 2 minutes faster, a difference too small to be statistically significant, and scored 50% on a comprehension quiz against 67% for the group coding by hand. The researchers expect AI to help most on “repetitive or familiar tasks”.
What the evidence says about speed
Three sources, and what each can and cannot tell you
| Evidence | Who and when | What was measured | Headline | Read it with care |
|---|---|---|---|---|
| METR trial and updateRandomised controlled trial, July 2025. Update, February 2026 | 2025: 16 experienced open source developers, 246 real issues, early 2025 tools. 2026: 57 developers, 800+ tasks, newer tools. | Time to finish real tasks, with and without AI. | 2025: 19% longer with AI. Developers expected 24% faster and afterwards believed about 20% faster. 2026: no reliable figure. METR thinks developers are likely more sped up now. | METR now says the 2025 result is out of date. It calls the 2026 data very weak evidence for the size of the gain. |
| Anthropic trialRandomised controlled trial, January 2026 | 52 mostly junior software engineers learning a new Python library. | Speed, and comprehension on a quiz straight afterwards. | About 2 minutes faster, not statistically significant. Quiz scores 50% with AI against 67% coding by hand. | Learning something new, not everyday work. Anthropic is the company behind Claude. |
| ByteSnap Design surveySurvey, 2026 | 281 UK electronics and embedded professionals. | What respondents report about their teams. | 40% say AI is cutting repetitive work. 33% say it is adding verification and governance work. | Self reported. It says nothing about measured time, and cannot show whether the same people report both. |
Sources: METR (July 2025 and February 2026), Anthropic (January 2026), ByteSnap Design (2026, n = 281). None of the trials involved hardware design.
ByteSnap Design | bytesnap.com
What our survey shows
In our 2026 survey we asked 281 UK electronics and embedded professionals how AI is changing their engineering team’s work. 40% said it is reducing repetitive analysis, documentation or test effort. 33% said it is increasing verification, assurance or governance work. 56% said it is improving analysis of field, test or operational data. You can read our published survey findings and download the full AI in electronics report.
Both effects are common, so budgeting for the saving alone would be budgeting for half a cost. What the survey cannot tell us is whether the same engineers report both. 113 respondents reported the saving, 94 reported the extra checking and 43 reported both. If the two answers were unrelated, about 38 would have said both, so the overlap is no more than chance would produce. The question was also about the team, not the individual.
Self reported figures are not measured time, and the 2025 trial above is the reason I am cautious about them.
Why the answer depends on the task
In my talk I argued that AI is faster on the right type of task and can slow you down on the wrong one. My example of the wrong one was a complex codebase you know well, where AI can slow you down while convincing you it is helping. AI does work. Whether it helps depends on how and where you use it. My reading of the METR result is that the time saved at the front end got pushed back into verification.
The right type of task is well bounded and easy to check afterwards: a first pass at component search, boilerplate code for embedded firmware, simulation summaries and first drafts of test scripts. The wrong type has an unclear brief and no easy independent check.
I tested the idea on myself. I built my talk with Claude, backwards and forwards. It read beautifully but had no through line, so I rewrote it from scratch, and it probably took me longer than writing it myself would have. In effect I had let the tool do the thinking and then spent the time repairing the result.
Find out for your own team
Most teams won’t find an answer in a study. They’ll find it in their own work. The simplest approach is to time the whole job and to compare like with like.
How to measure it in your own team
A simple worksheet. Record these before deciding whether AI is saving time
| Step | What to record | Why it matters |
|---|---|---|
| Pick comparable tasks | Tasks of the same type, size and risk. Start with bounded tasks you can check. | Mixing task types hides the effect. |
| Time the whole job | Prompting, generating, reviewing, reworking and sign off, not only the time to produce a draft. | The saving often turns into checking. |
| Compare like with like | The same task type done with and without AI, ideally by the same people. | Otherwise fast engineers look like fast tools. |
| Count what comes back later | Defects found at review, in test or in the field, against the version made with AI. | A quick draft with late defects can cost more. |
| Ask for a guess, then compare | Ask engineers to predict the time saved, then compare with the measured figure. | In the METR trial, developers believed they were about 20% faster while tasks took 19% longer. |
| Repeat after tool changes | Re measure when the tools or the task mix change. | Tools move quickly, and a 2025 result is already dated. |
Source: ByteSnap Design working guidance. The perception gap is from METR (2025).
ByteSnap Design | bytesnap.com
What I would do
Plan for the checking. If AI is cutting your analysis time, decide who verifies the output and how long that takes, and put it in the project plan.
If you are planning a design programme and want to test the plan before you commit, our feasibility study and the Project Success Calculator are quick places to start. Start with tasks that are bounded and checkable, where a saving is likeliest and an error is easiest to catch.
Don’t rely on how it feels. Tools change quickly, so repeat the measurement when they do. I covered the jobs question separately in Will AI take all the engineering jobs or boost productivity?
And if you want a second opinion on where AI could safely speed up a design programme, our engineers offer outsourced electronic product design and can talk it through with you.
Put a stopwatch on AI in your own design process
If you want to know whether AI is saving time or adding checking in your own electronic design work, speak to me or one of our engineering consultants about how to measure it on a real project.
FAQs
Does AI make embedded systems engineers faster?
ByteSnap Design currently knows of no controlled trial of AI in embedded systems engineering, and the software evidence is mixed. METR found experienced developers took 19% longer with AI in 2025, a result it now calls out of date, while Anthropic’s 2026 trial found a speed gain too small to be significant. In ByteSnap Design’s survey of 281 UK electronics and embedded professionals, 40% say AI cuts repetitive analysis and 33% say it adds verification work, both self reported.
Which embedded systems tasks does AI speed up most?
The evidence is thin, but the sources point the same way: repetitive, well bounded tasks that are easy to check. Anthropic’s authors expect gains on repetitive or familiar tasks, and 40% of respondents in ByteSnap Design’s 2026 survey say AI is cutting repetitive analysis and documentation. Dunstan Power’s view is that AI can slow you down while convincing you it is helping, for example on a complex codebase you know well.
Can you trust engineers' own estimates of time saved by AI?
Not on their own. In a 2025 trial, developers believed AI had sped them up by about 20% when their tasks took 19% longer. METR’s May 2026 survey of 349 technical workers found a median self reported change of 1.4 to 2 times in the value of their work, which METR says there are reasons to doubt. Use estimates to decide where to look, then time the work.
How do you measure AI productivity in an embedded systems team?
Time the whole job, including prompting, review, rework and sign off, on comparable tasks with and without AI. The 2025 trial randomly assigned each task to allow or forbid AI, which is the cleanest design a team can copy. Count defects found later, ask engineers to predict savings before comparing them with the measured figure, and repeat when the tools change.
Dunstan is a chartered electronics engineer who has been providing embedded systems design, production and consultancy to businesses around the world for over 30 years.
Dunstan graduated from Cambridge University with a degree in electronics engineering in 1992. After working in the industry for several years, he co-founded multi-award-winning electronics engineering consultancy ByteSnap Design in 2008. He then went on to launch international EV charging design consultancy Versinetic during the 2020 global lockdown.
An experienced conference speaker domestically and internationally, Dunstan covers several areas of electronics product development, including IoT, integrated software design and complex project management.
In his spare time, Dunstan enjoys hiking and astronomy.
Expand your knowledge
- Measuring the Impact of Early 2025 AI on Experienced Open Source Developer Productivity, METR, July 2025, and its February 2026 update. The trial, and why the newer data is unreliable.
- How AI assistance impacts the formation of coding skills, Anthropic, January 2026. The learning trial, written up by its authors.
- Measuring the Self Reported Impact of Early 2026 AI on Technical Worker Productivity, METR, May 2026. A survey of 349 technical workers, with the caveats on self reporting.
- AI in electronics: what makes the cut?, ByteSnap Design, 2026. The survey behind the figures above.
