The next generation of embedded coding agents need to be able to see into the real world and to remember what they’ve seen.
Imagine asking a coding agent to do something simple like blink an LED on your dev board. When do you think the agent should consider the job done? When the code appears on your screen? When it builds? When it flashes to your board? All of those are significant signs of progress, but none of them tell you if the LED is actually blinking exactly the way you want it to. For that, you need to literally look at the piece of hardware in front of you and see for yourself.
This is something we’ve been thinking about a lot at Temboo as coding agents become more capable and take on more and more of the embedded development workflow. The more work an agent can do independently, the more important the definition of “done” becomes.
For embedded development, the unit of work that really matters is a verified outcome (as opposed to a collection of code changes). It’s not that interesting or useful if a coding agent thinks the LED is blinking based on the code it wrote, or from looking at some log entries. We want it to be as certain as possible that the LED is blinking exactly the way it should be in the real world.
From Code Changes to Outcomes
The way people interact with coding agents today is very software-centric i.e., agents are designed based on conventions and assumptions taken from the desktop, web, and mobile development worlds. We’re used to interacting with agents by giving commands to write functions, fix errors, refactor files, and so on. This makes perfect sense when the end goal is to produce software, but it makes less sense when the end goal is to make something happen in a physical system.
Let’s say you want to move an actuator to a certain position, or to reach a ready state within 2 seconds of boot. The code is an essential piece of the puzzle, but it’s really means to an end, since what you ultimately care about is the real-world behavior. If we start from the outcome, it changes how we think about the job that agents are doing for us. Instead of asking an agent to write some code that toggles a GPIO every 500ms, we can ask it to blink the LED once a second, within X% tolerance, and to prove to us that it works on the real device.
This approach gives the agent space to take responsibility the specifics of each step in the dev workflow, while staying fully focused on the outcome. It can tackle everything from understanding the project, writing or modifying the code, building, and flashing, to then observing runtime, comparing against requirements, and iterating until the original requirement has been satisfied. That’s the idea behind what we’re calling Device Loops.
Closing the Loop on the Real Device
A Device Loop begins with a requirement and an expectation. For a simple LED example, the intent might be to get the LED blinking at a regular interval, and the expectation will be something more specific and measurable like “the LED should complete one on/off cycle every second, within ±10%”.
From there, the agent can figure out the best implementation based on the context (workspace, SDK, target, and so on), and then get the firmware running. Instead of stopping there, the workflow then continues onto the physical device.
We can use a phone camera to observe the LED over several cycles, measure the actual timing, and compare what’s happening on the device with what was expected before the code got written. If the observed blink period is within the expected bounds, then the agent has the real-world evidence it needs to confidently suggest concluding the task. If the observation is out of bounds, the agent knows it needs to keep working until it gets a positive observation.
This real-world feedback is crucial to advancing the state of the art in agent-driven embedded development. A successful build tells us that the firmware is acceptable to the toolchain, but a verified Device Loop outcome tells us something about what the system actually did in practice.
Giving Coding Agents Eyes on the Real World
To become genuinely useful in the embedded space, coding agents need to know far more about the environments the code they generate is running in. Ideally, they’d have the ability to literally see into the real world and watch their code in action.
Sometimes the “eyes” might be a phone camera, but they could also be things like runtime logs, debugger output, logic analyzers, oscilloscopes, network activity, timing measurements, sensor readings, and lots more.
What matters is that the agent knows the outcome it is shooting for, and that it has some appropriate way to observe the actual system in practice. On top of that, agents need the ability to reason about the differences between the two, and to keep working until they match up. This approach lets us quickly move beyond just getting the code to build, and onto asking if the code actually works the way we want it to. It’s still early days in exploring this idea across different types of embedded systems, but the idea of giving coding agents access to the physical world to help them write better quality code feels like an important step forward.
Loop Records
There’s something else about this approach that’s potentially even more useful than the idea of giving coding agents eyes.
When a coding agent has a hand in everything from requirements formulation all the way through to real-world verification, there’s an opportunity to gather and preserve so much more useful info about its work (as opposed to the status quo of just using the resulting code as evidence of what the agent has done).
A Device Loop can record:
- What the developer was trying to achieve
- The implementation changes that were made
- Which build ran on the target
- What system observation methods were used
- What evidence was collected
- Whether the requirements were satisfied or not
- What failed along the way
- What changed between iterations
- Which result was ultimately accepted as satisfying the requirements
This means that Device Loops, besides being an end-to-end workflow mechanism, also serve as a record of the engineering progress and process. While source control does a great job of preserving code change history, we tend to lose things like why someone ever believed a given requirement had been satisfied, or how exactly a given build was running a few weeks ago. That info often exists somewhere (maybe in someone’s head, in a chat app, in a ticket) or maybe it doesn’t exist at all. If we can capture that as part of a modern embedded development workflow, we can put that history to good use.
Dev History as an Engineering Asset
We see several key ways in which Device Loop records can improve the embedded development process.
Better context for future development
Any engineer or coding agent returning to a project will have far more useful info to start with than just the source code. This includes a complete record of expectations, implementation decisions, runtime behavior on real hardware, and the evidence used to motivate previous decisions.
Better team communication
A colleague reviewing a change can see far more than a code diff. They can see the original requirement, what happened at runtime, the evidence that led to the implementation being accepted, the method(s) used to collect the evidence, and who signed off on it. This creates a much richer handoff for people working on the same system, whether in parallel or in sequence.
Better regression analysis
If a requirement has been verified as working, a Device Loop can compare new observations with earlier ones. After every new change, the system can check if the old findings have been invalidated, and it can raise the appropriate flags. This makes it easier to spot regressions as they happen, and to take steps to address them in the moment rather than leaving them lingering in the system to cause trouble at a later date.
Reusable engineering knowledge
Many embedded requirements end up being repeated across projects and platforms. If those development goals can be expressed in a reusable way (including how they should be implemented, observed, and evaluated), then they start to look like patterns. This is another area that we’re actively exploring i.e., whether common embedded dev outcomes can be packaged so that developers can start from a proven workflow rather than a blank file or a blank prompt every time. The history generated by each successive Device Loop execution can be used to make those patterns even better over time.
A New Definition of “Done”
The most interesting future for AI-driven embedded development isn’t the one in which agents gradually produce more of the code that gets out into the world. We’d much rather have a reality in which people can describe what they want a system to do, and the agent can take increasing responsibility for proving that things are actually working correctly in practice. The code remains crucial of course, but giving the agent the ability to compare requirements with reality, to iterate autonomously based on that, and to be able to preserve and make future use of the evidence is very compelling.
We’re still figuring out the best way to turn these ideas into usable embedded development workflows, but the direction is becoming increasingly clear. The boundary at which coding agents hand off is shifting, and “Done” can now mean that actual evidence of a working system has been produced (as opposed to just some code that you’re left on your own to test). “Done” can now mean a verified outcome, backed by evidence from a real device, that can be carried forward to inform what you’re building next.
That’s what we’re working towards with Device Loops, and we’re excited to see where it takes us. The first manifestation of this vision is available to try in the Temboo agent right now.