Engineering is much more than just generating code quickly
An experienced firmware engineer starts leaning on AI every day. Tickets move faster. The empty-file dread is gone. “Honestly, I’m at least 30% quicker now,” they tell their manager.
Three months later, the graphs don’t share the enthusiasm. Incidents per PR are up. Review queues are sticky. QA is catching regressions in places that used to be quiet. Nobody can point to a single catastrophic failure, but the background noise level has changed. People are busier, not calmer.
That gap between “this feels faster” and “this is actually helping us deliver” is the AI productivity paradox for firmware teams.
Why “I’m faster” is a bad steering mechanism
AI does make parts of a developer’s day feel better. It’s good at blowing past small obstacles:
- “Translate this scribbled state machine into actual C.”
- “Give me a first pass at this driver API.”
- “Show me a unit test skeleton for this module.”
You go from stuck to “there’s something to run and poke at” very quickly. That’s real.
The trouble is that personal experience is a narrow lens. It doesn’t see the whole system. The engineer at the keyboard doesn’t see:
- The extra review hours logged by other engineers who had no context on what prompts produced the code and now have to reconstruct intent from scratch.
- The subtle integration drift when each AI-assisted change nudges the architecture a little bit.
- The support tickets that pop up two releases later because a race condition got past incomplete tests.
In controlled studies, this isn’t just a feeling problem. Experienced developers predict that AI will speed them up, and they still believe it did after the fact, even when the measured effect is a slowdown on real issues in mature codebases.
So, if a firmware lead hears “I’m 30% faster now,” that’s a useful data point about how the workday feels. It is not a reliable metric for whether the organization is actually better off.
What acceleration whiplash looks like
As AI usage grows, a recurring pattern shows up: coding accelerates, but delivery doesn’t automatically improve. In some organizations, stability actually gets worse. On the ground, it looks like this:
- PR counts go up, or the average diff size creeps larger.
- Review feels heavier. People either spend more time per PR or start clicking approve just to keep things moving.
- CI pipelines that were fine pre-AI now struggle to keep up with the volume.
- QA and support see more issues per release than before.
You’ve stepped on the gas in one part of the system, local coding speed, while leaving the rest of the system unchanged.
Nobody put that in the sprint goals. It just sort of happens when a rocket gets bolted onto a 2018-era delivery pipeline and everybody hopes for the best. For embedded firmware, the consequences aren’t abstract.
- Debug cycles require real hardware, not just another test container. Losing two days of bench time to track down a new intermittent bug is expensive.
- Rolling back a bad change is not just “deploy the previous build.” It’s OTA constraints, bootloaders, and sometimes field service, as well as re-certification.
- Observability is often thin. When devices lock up on a customer’s site, the team may get a vague log and a screenshot, not a full stack trace.
Multiply those costs by a higher incident rate per PR and the math stops working very quickly. If a team can comfortably absorb three medium-severity issues per release and that quietly becomes six or eight, it doesn’t matter much that one engineer feels 30% faster. The system is now underwater.
Why self-reported productivity keeps lying
If team-level decisions are being made, it helps to know why self-reports are so skewed.
One reason is that AI improves the most visible, least measured part of the job: the minutes where somebody is actively typing and seeing the program evolve. That’s what people remember at the end of the day. The long debugging session that followed a rushed change gets filed under “CI is slow” or “the hardware is being weird,” not “this new AI habit made the system harder to reason about.”
Another reason is cognitive offload. When the tool fills in a big stretch of code, the sense of effort drops. It’s easy to misread that as speed. The cost of understanding, testing, and maintaining that code is back-loaded and shared across the rest of the team.
That’s because humans are simply not good at attributing delays. When a release slips, people point at meetings, dependencies, process, maybe the compiler version. Almost nobody says, “we’ve been steadily increasing the complexity and churn of changes we’re pushing through the exact same funnel.”
That is why the metrics that matter at team level are not “how fast does this feel?” They are things like change failure rate, review load, time to diagnose device issues, and regression patterns over time.
If those aren’t improving, tuning AI usage around “it feels great” is more likely to amplify the problem than solve it.
Why firmware teams feel it harder
A lot of early AI productivity stories come from web and enterprise software. Those environments usually have short feedback loops, rich observability, cheap rollbacks, and more mature automation. They also benefit from a softer failure mode: a flaky web app is frustrating. A device that locks up or behaves unpredictably erodes trust in a way that a redeploy can’t fix. Firmware is not playing that game.
Hardware doesn’t forgive sloppiness
AI is good at generating code that compiles and passes shallow tests. It is much less trustworthy with tight timing on buses and ISRs, vendor errata buried in PDFs, power budgets, startup sequences, and safety margins that are not obvious from one source file.
When those are wrong, the result is not just another failed build. It can be a device that locks up once a week in the field, a battery that drains faster than spec, or a factory test that starts failing for reasons nobody can reproduce on the bench. The takeaway? Embedded-specific risks are sharper around memory safety, determinism, hardware-specific correctness, and certification-heavy environments.
Turn up change volume with AI without strengthening hardware-in-the-loop tests, factory tests, and field telemetry, and the roulette wheel is just spinning faster. That cuts directly against the testing and reliability emphasis in Dojo Five’s broader embedded guidance.
Review gets harder when authors don’t own the code
In embedded, reviewers carry a lot of system context. They are not just asking whether the code looks okay. They are asking whether it respects timing, power, watchdog behavior, interface contracts, and how the whole device is supposed to behave.
When a PR arrives full of AI-assisted code that the author can’t walk through line by line, reviewers are stuck. They either spend more time reconstructing intent and checking hardware interactions, or they lower the bar and hope the existing tests catch anything serious. If the engineer cannot explain the code’s behavior without the AI tool open, the code is not ready.
At team retros, that usually shows up as “reviews are slow” or “CI is underpowered,” not “we handed reviewers a pile of half-understood code and asked them to be psychic.”
Tooling is halfway modern, not fully
Many firmware organizations are still in the middle of modernizing their practice: one source of truth, tighter environment governance, better automation, testing that actually covers reality, and systems that are updateable and observable over the full product lifecycle. AI shows up in the middle of that journey, not at the end. If the testing taxonomy is thin, the automation infrastructure is partly manual, and the logging from the field is still evolving, then a sudden increase in code churn is not neutral. It pushes more risk through a pipeline that was already working hard.
Three practices that help
The paradox is not unavoidable. AI can absolutely be a power tool for embedded work, but it has to sit inside practices that protect delivery stability and make it easier, not harder, to ship reliable firmware.
- Keep changes small and explicit. Use AI to make it easier to craft tight, focused PRs, not to cram more behavior into each one. Small batch sizes make it possible to see what changed, review it properly, and roll it back cleanly when needed.
- Upgrade tests and observability first, not last. Before leaning hard on AI for implementation, invest in tests that actually run, including hardware‑in‑the‑loop where it matters, and in logging and telemetry that say something useful about device behavior in the field. If feedback from real hardware is slow or fuzzy, speeding up code generation just moves risk around instead of reducing it.
- Make ownership explicit. Whatever wrote the first draft, the engineer who opens the PR is responsible for every line. If they cannot explain how a chunk of code behaves on the device and how it could fail, it does not ship. AI tools are allowed to suggest; engineers are the ones who decide what goes into the product.
This keeps the SEO‑useful semantics (AI for embedded, PRs, small batch sizes, tests, observability, HIL, logging/telemetry, ownership) without repeatedly pointing back at your own assets.
In our forthcoming e-book, AI Power Tools for Embedded, the messy parts this post only sketches out get more attention: where the numbers actually look good, where they don’t, and what changed in teams that stopped getting burned by “AI makes us faster” stories. This post is an early look at that paradox and why firmware teams feel it so sharply.
