“Let’s just use AI to do it.”
We hear this line nearly every day. But where one person sees a tool, another sees a panacea. So, where does AI integration make sense in embedded?
In our recent post The AI Productivity Paradox in Firmware Teams, we talked about the trap a lot of teams fall into with AI: individual engineers feel faster, but the organization does not necessarily get faster. In fact, reviews get heavier. Regressions creep up. And delivery starts to feel noisier, not calmer.
That leads to a very practical question for engineering and product leaders. If you are going to use AI, where do you start without creating a clean-up project for yourself three sprints from now?
For embedded teams, that question matters. Hardware narrows the margin for error. Feedback loops are slower, and rollbacks are not always simple. And when observability is thin, a bad change can persist for longer than anybody wants to admit.
So this is not a philosophical post about whether AI is good or bad (we will let you decide). It is a starter checklist for where to use it first, where to be careful, and where not to get cute.
Green-light areas
Start where the upside is real and the blast radius is limited. This usually means work that helps the team understand, test, or support the system rather than work buried in the most sensitive parts of the device.
A good place to begin: logs, tests, onboarding, internal tools, and documentation drafts. These are high-value, easier-to-review uses where bad output is less likely to turn into a device problem in the field.
A few examples:
- Let AI help sort through ugly log streams, summarize test runs, or point out patterns worth chasing.
- Use it to draft unit-test skeletons, mocks, fixtures, or edge cases after a human has already defined what the code is supposed to do.
- Use it to help new people get oriented in a big codebase, especially when the alternative is “good luck, see you in two weeks.”
- Use it for convenience tooling, like parsers, provisioning helpers, dashboards, lab scripts, or internal utilities that do not ship on the device.
If you are choosing a first pilot, these are the boring answers, but they are good answers.
Yellow-light areas
Yellow-light work is where AI can help, but only if the team already has some habits worth trusting. Review discipline and ownership matter here. So does the ability to tell when a change that seems small is about to spread its problems around.
Be mindful of infrastructure, build systems, client communications, integration code, and AI-assisted code review. There is real value here, but mistakes can ripple outward through builds, architecture, or client expectations.
Some examples are more slippery than they look:
- Infrastructure and CI work are well represented in training data, which helps, but reproducibility problems have a way of showing up later and uglier.
- AI is fine for drafting client updates or status summaries, but that draft still needs a human who understands the engagement and knows what the team actually committed to.
- Integration code and UI/UX code are both classic examples of “looks fine at first” zone. It is also where architectural drift can sneak in a little bit at a time.
- AI can help pre-review a pull request. It cannot replace human review.
If a team is already strong on review and fairly honest about its own process gaps, yellow-light areas may be reasonable. If not, green is still the smarter place to begin.
Red-light areas
Then there is the stuff that should not be your first pilot unless your definition of “pilot” includes “needlessly stressful.”
Do not start with safety-critical code, cryptography, authentication, bare-metal drivers, or regulatory-certification artifacts. These are high-consequence areas with tighter assurance requirements and much less tolerance for plausible-but-wrong output.
This part is not subtle, and it should not be.
- Bare-metal and driver work depend on timing, errata, interrupt behavior, DMA interactions, and hardware details that AI often cannot reliably infer from code alone.
- Safety-critical paths need traceability, deterministic behavior, and design decisions a human can explain to future engineers, auditors, or both.
- Cryptographic and authentication code deserve extra scrutiny even before AI enters the picture, which makes them poor candidates for casual experimentation.
- Regulatory artifacts and confidential client materials bring policy and compliance questions that should be handled deliberately, not opportunistically.
Could AI still play a supporting role around some of that work, like documentation help or test ideas? Sure. But that is separate from making those areas your first big experiment.
Team checklist
Before you green-light a pilot, ask a few plain questions. You do not need a maturity model and a twelve-tab spreadsheet to do this. You need honest answers.
- Is this work easy to review and easy to replace if the output is wrong?
- Does it stay clear of safety-critical logic, cryptography, and low-level hardware control?
- Do we have tests, feedback loops, and enough observability to catch bad changes before they turn into a field problem?
- Can the engineer opening the PR explain the code without treating the model like a co-signer?
- Are we cutting drudgery and speeding up understanding, or are we just generating more code than the team can absorb?
- Do client policy, confidentiality rules, or regulatory expectations limit what can go into the tool at all?
If the answers are solid, you probably have a workable pilot. If they are fuzzy, that is useful information too. Dojo Five’s position is not “never use AI.”Instead, use it where it helps, and do not pretend the hard parts of embedded got easier just because the first draft showed up faster.
Start where the gains are real, keep humans accountable, and resist the urge to prove how modern you are by using AI in bad places.
Ready to chat about your embedded project? You can book a call with our embedded subject matter experts to get your questions answered.
