An AI coding agent can turn a paragraph into a working web app. Getting the same kind of useful first result on a real connected product codebase is a harder problem, and a different one.
Firmware runs on specific hardware and a specific toolchain, and you only find out whether a change works by running it on the device. A prompt that lands a web form does not carry across to it.
The gap closes when the agents understand the system the way your team does and can check their work on real hardware. That understanding starts before the first task, with a written ground truth of the codebase that the agents build and maintain themselves. How much an AI agent can do on a connected product is decided by the setup you build around it.
How much an AI agent can do on a connected product is decided by the setup you build around it.
Here is how to build that ground truth, hand agents the work that plays to their strengths, and set each task up for a good result.
Build a written ground truth of the system
Before you hand the agents any task, give them an accurate picture of how the code works. On a connected product that picture is large: the firmware, the app, the cloud, the interfaces between them, and the conventions each part follows. Writing it down once is what makes every task afterward go well, and the agents can do most of the writing.
- 1Agents document the codebase. A set of agents reads the code and writes down what they learn: how each subsystem works, how firmware, app, and cloud fit together, the interfaces between them, and the conventions the code follows. The output is a set of Markdown files that become the ground truth of the system.
- 2A second set of agents reviews the files against the code. They confirm the written description matches what the code actually does, correcting anything that drifted or was missed.
- 3Code-writing agents keep the ground truth current. A change that touches behavior updates the Markdown that describes it, so the documentation stays in step with the code as the product moves.
The documentation the agents keep current becomes the ground truth of the system: later agents read it instead of the code, and people can ask it how the product works. This compounds in two directions. Reading the Markdown rather than re-deriving the system from source each time, future agents start every task with an accurate picture and get more right on the first pass. And the documentation now serves people too: an engineer can ask an agent how a subsystem works or where a constraint lives, and get an answer grounded in the files rather than a guess.
The constraints that govern the app and the cloud are the part of this ground truth an agent most needs for a change that crosses domains.
Which firmware task should you give an AI coding agent first?
With the ground truth in place, a mechanical, pattern-heavy task is a strong first thing to hand an agent. The ones that go best are where correctness is checkable and the codebase already shows the pattern: a Bluetooth Low Energy service from a GATT specification, a peripheral driver ported between two platforms with similar Hardware Abstraction Layer structures, a protocol parser from a documented packet format, or unit test scaffolding for existing modules. This is detail-heavy, repetitive work for a person, and detail-heavy work against a clear correctness criterion is where agents are strongest.
The work that still needs a hand is what only the bench can confirm: radio frequency tuning, power optimization at the microamp level, or timing that a scope measures on the bench. Those depend on feedback from the physical device that the code alone can't give, so they come once you have calibrated what the agent does well and where it needs you.
How do you set up an AI coding agent for a firmware task?
The ground truth carries most of the context. Each task needs a little more pointed at it: the specific spec to work from and two or three existing files that follow the pattern you want.
The existing files matter most. When an agent sees how your team names functions, handles error codes, structures headers, and documents register access, it follows those conventions. Point it at a couple of them and the output looks like it belongs; leave them out and it writes reasonable code that does not match your project.
For a BLE service, that means the GATT spec, one or two existing service implementations from your project, and your conventions for characteristic callbacks and error handling. With those in front of it, the agent writes code that compiles, follows your patterns, and handles the standard cases.
The constraints the code has to respect (timing assumptions, the data formats that cross into the app and the cloud, the version rules between firmware and app) already sit in the ground truth, so the agent reads them along with everything else.
The last piece is a way for the agent to check its own work. Give it in-loop validation, so it can run the change against a real device, across firmware, app, and cloud, and read what breaks.
With the patterns, the constraints, and a validation loop in place, the agent just fixes it. The agent writes the change, runs it on real hardware, sees what fails, and fixes it before you look.
The agent writes the change, runs it on real hardware, sees what fails, and fixes it before you look.
It helps to be specific about the task. "Implement the temperature service per this GATT spec. Follow the pattern in humidity_service.c. Use the error codes in ble_errors.h. The characteristic callback should match humidity_char_handler." That much detail gets you a working result instead of a rough draft.
What the agent still needs from you
Less than you would expect, once the setup is good. Most of the change is already right when it reaches you: the structure is sound, the patterns match, and the standard cases and cross-domain interactions have run on real hardware.
What the agent misses is whatever the setup did not capture, so the fix is to write it into the constraints, not to catch it by hand every time.
Usually that is a timing tweak that lived only in someone's head, or a constraint no document wrote down. Write it down once, and the gap closes for every future task instead of coming back on each one.
A concrete example. An agent asked to implement a Serial Peripheral Interface flash driver from a datasheet and an existing Inter-Integrated Circuit EEPROM driver in the same project gets the read and write command sequences right, follows your naming, and structures the initialization correctly. It will miss the 50-microsecond delay your team found is necessary after chip select on one specific flash part, because that delay lives in a comment three files away or in someone's head. Write it into the constraints the agent reads, and every future change respects it.
After the first task
Once you have one task working, try test code. Agents are excellent at generating test harnesses and scaffolding from existing production code.
Give the agent a module and ask for unit tests that cover the documented behavior: valid inputs, boundary values, expected error returns. The output covers the standard paths thoroughly and misses the edge cases that live only in your team's heads. That is still valuable, because the standard-path coverage is the part most firmware projects skip when writing tests by hand feels like a distraction from shipping.
Test scaffolding is also a good next step for letting the agent touch more of the codebase. The tests do not ship to devices, so a mistake in a generated test is a review comment, not a field failure. As the coverage grows, it builds a feedback loop: the agent's future changes can be checked against the tests it helped write.
After a few tasks, you will have a working sense of where agents save time and where they need more setup. The pattern is consistent. Well-specified tasks with clear inputs produce usable first results. Tasks that lean on knowledge that lives only in someone's head need it captured first.
Expanding from there is a matter of writing down more of the system, tightening the constraints, and widening what the validation covers. The ground truth the agents maintain grows with the product, so much of that documenting happens as they work. Most teams find their rhythm within a week or two.
Groundrun in the agents' loop
Everything above gets an agent to write a good change. The piece that confirms the change works on the real product is Groundrun.
Groundrun runs your product's flows across firmware, app, and cloud on real hardware, and exposes them so an agent can invoke them from inside its loop. The agent makes a change, runs the flows, sees where it broke, and fixes it as it works, the same steering feedback a developer gets from running a test mid-task, now covering the whole connected product.
The ground truth tells the agent how the system works; Groundrun shows whether a change works on the hardware. Together they're what a team needs to develop a connected product with AI agents and get it right.
See how Groundrun gives your agents cross-domain feedback they can act on: platform overview.