Where Does Firmware Development Actually Spend Its Time?

• AI-generated code produces roughly 1.7x more issues than human-written code, according to CodeRabbit’s analysis of 470 real-world GitHub pull requests — not toy benchmarks, production repositories. Logic and correctness errors were about 75% more common in AI-generated pull requests.
• Developers using AI coding tools were measurably slower, not faster, in a controlled 2025 study. METR ran a randomized controlled trial with 16 experienced open-source developers completing 246 real tasks in codebases they already knew well. Developers using AI tools were 19% slower on average — even though they felt 20% faster and had predicted a 24% time savings going in.
• Trust in AI-generated code output is low and getting lower. Sonar’s 2026 State of Code survey of more than 1,100 professional developers found that 96% say they don’t fully trust AI-generated code, and only 48% always check it before committing. Stack Overflow’s developer survey found trust in AI tool accuracy fell to 33%, down from 43% the year before.
• Security is a specific weak point. A NYU Tandon study analyzing 1,689 Copilot-generated code samples across 89 security-sensitive scenarios found that roughly 40% of the suggestions contained vulnerabilities mapped to the MITRE CWE Top 25 list.

The pattern across all of these studies is the same: AI shifts effort from writing to reviewing. And reviewing code has never been cheap. Even before AI-generated code entered the picture, developers were already spending somewhere between 12% and 20% of a typical work week on code review, depending on the study.

For firmware, this problem is sharper than in general software — because the review step can’t stop at “does this look correct.” It has to stop at “does this behave correctly on the actual silicon.”

Why firmware makes this worse

In most software domains, an AI-generated function can be validated with a unit test in a CI pipeline within seconds. Firmware doesn’t get that shortcut.

A successful build only proves the code compiles and links. It says nothing about whether a register write actually happens at the right point in a boot sequence, whether an interrupt handler behaves correctly under real timing pressure, or whether a peripheral driver matches a specific silicon revision’s Errata.

So when AI-generated firmware code carries a higher defect rate — as the studies above suggest — that defect doesn’t surface at compile time. It surfaces later, on real hardware, in the Build, Flash, Log, Fix loop. That’s a far more expensive place to catch a bug than a code review comment.

This is the gap between “the AI wrote it in ten seconds” and “the team can trust it in production.”

Where the calendar time actually goes

Ask a firmware engineer how long a feature will take, and the estimate is still often built around one activity: writing code. A GPIO driver looks like a day. A sensor integration looks like three. A bootloader update looks like a week.

Then the project runs long — not because the code was hard to generate, whether by a human or an AI, but because of everything required to trust and verify it.

1. Finding the right information

Before a single register gets written — or a single AI-generated suggestion gets accepted — someone has to check it against the source of truth: Datasheets, reference manuals, SDK documentation, and Errata. This information is rarely in one place, and it has to be cross-referenced repeatedly, not just once at the start.

2. Getting the development environment to work

Firmware toolchains are assembled, not installed. A project depends on a specific compiler version, linker script, memory map, flashing tool, and debugger working together. Moving to a new board or silicon revision often means fixing the environment before any code — human-written or AI-generated — can even be tested.

3. Closing the gap between “builds” and “works”

This is where estimates slip hardest, and where the studies above matter most. The firmware compiles, but the peripheral doesn’t behave as expected. The board boots, but timing is wrong. The interrupt works but conflicts with another part of the system.

Now the engineer enters the Build, Flash, Log, Fix loop: flash the firmware, inspect logs, connect a debugger, check the Datasheet again, compare behavior against Errata, make a change, repeat. A task estimated at one day can quietly become a week — and if the original code came from an AI model with a 1.7x higher defect rate, this loop is where that extra defect burden actually gets paid.

4. Switching between disconnected tools

CMake. OpenOCD. Flashing utilities. Debuggers. Serial consoles. Logic analyzers. Datasheet PDFs. None of these tools were designed as one connected system. The engineer becomes the integration layer, carrying context — which board revision, which register, which Errata, which build configuration — from one tool to the next. No single switch feels expensive. Across a project, they add up.

5. Verifying on real hardware

Even firmware that passes simulation still has to be verified on the actual target hardware, because real silicon introduces variables that software alone can’t fully represent. This verification loop is essential — and it remains one of the most manual parts of the entire workflow, whether the underlying code was written by a person or generated by AI.

The pattern underneath the pattern

Across every stage above, the same pattern holds: the biggest time costs are not in producing code. They’re in

• Finding the right information
• Coordinating disconnected tools
• Debugging the gap between software and hardware
• Verifying the result on real silicon

This is also why faster code generation alone doesn’t solve firmware development’s core problem — and, per the data above, can make the verification burden larger rather than smaller. An AI model can generate a driver in seconds, but the Datasheet still needs to be checked, the SDK and Errata still need to be correlated, and the project still needs to build, flash, run, and be verified on real hardware. Generation speed and trustworthiness are two different problems, and right now the data shows a widening gap between them.

A different way to think about firmware development

The next time a firmware estimate feels wrong in hindsight, ask a different question: how much of the time was actually spent writing code — versus verifying that the code, human- or AI-written, actually does what it’s supposed to do on real hardware?

Firmware development is not just a coding task. It’s a workflow that connects documentation, code, toolchains, physical hardware, and verification. The industry has gotten very good at generating code quickly. The harder, unsolved problem is making the workflow around that code — the checking, the correlating, the flashing, the debugging — less fragmented and less manual.

That is the gap FWAuto is built to address: not simply generating code, but orchestrating the workflow around it and helping move from code to a verified result on real hardware.