Catching the Vibe: How AI is Changing Embedded Development

Agentic assistants for software development are an undeniable part of today's world. However, embedded software development presents unique challenges that require careful consideration when integrating these powerful tools into the workflow. Factors such as heightened sensitivity to inefficiencies, tight coupling with hardware, and the limitations of AI in comprehending the physical world make AI-enhanced embedded development a particularly compelling area of discussion.

In this article, we'll dive into "Vibe Coding" for embedded software: how bringing in autonomous, supervised AI agents can have a significant effect on a developer's work throughput - both the good stuff and the tricky bits of this approach. We will also outline some practical guidelines to get your team ready, covering everything from crystal-clear requirements and solid documentation to a well-structured codebase, continuous integration, and smart code reviews. Our goal? To give you a roadmap for unlocking AI's full potential in embedded software development.

What do we mean by Vibe Coding

It's important to agree on what we mean by Vibe Coding first. We are definitely not aiming for hands-off, non-technical driven activity. We are also not talking of replacing the process of creating a product.

On the other end, we are also not talking about tab completion capabilities like those vanilla copilot and cursor features. We are talking about autonomous agents that solve tasks in a supervised way. This is, in our opinion, the sweet spot in which efficiency is maximized.

Should I get into this now?

Short answer, yes. It's starting to work (and very well). With good prompting and a well-structured codebase, AI agents can definitely get you off the floor for a given change request. Less technically, and more objectively speaking, tech giants are shifting towards this model of development on markets loosely coupled with the one we're considering here.

Something that is usually overlooked is the fact that involving AI in a productive workflow involves organizational changes, from people's mindsets to the technologies used in our development process. Implementing these changes can be even more of a challenge in the embedded software organizations, as we will discuss. If an organization is to be prepared to leverage the competitive edge of Vibe Coding, it needs to start doing this groundwork while the underlying technologies mature.

Vibe Coding guidelines for embedded software

We find that AI benefits from the same things that empower a junior developer coming anew to a codebase:

• good requirements, well communicated, from the get-go
• well-documented rules for development
• good structure in the codebase
• a good CI
• sound reviewers

It's important to note that these "prerequisites" are not exclusive to companies aiming to adopt AI-enhanced development tools. Rather, they are fundamental for any organization seeking to establish a healthy and robust operational framework for delivering engineering services.

Good requirements - over communicate initially

People get frustrated when they fall into a non-progressing interchange with AI. Guess what? That happens with humans too! People tend to give more weight to their initial understanding of a problem, and then navigate on a confirmation bias boat.

AI is particularly bad at ignoring existing information. You thought hallucination was bad? Now it's stuck with you till you start all over again.

A fun example of this: I asked an AI to write some message over SPI. It hallucinated some constants. Then I directed it to the documentation that defined those constants, it stuck with the ones already in the code base. A fresh prompt pointing to the docs solved it in the first go.

More concretely:

• lay out requirements as if you are talking to a new developer that you won't see for a week
• point to documentation early on
• define architectural requirements just as you would when explaining them to a junior engineer working alongside you
• for large changes, delegate a specific submodule at a time based on your envisioned architecture
• specify how you would test the implementation, talk about expected outcomes
• get ahead by mentioning some potential pitfalls (e.g. use nanopb to generate the protobuf serialization files)
• ask for a plan of action and validate it before the agentic software starts implementing

Good and well documented rules

It is easier to mess up in embedded software. All it takes is a malloc call in a wrongly prioritized task. Also, debugging a memory leak on an embedded platform is something that AI can't do (yet!).

As with your team of humans, it is important that you agree and document rules and guidelines. This should become part of the prompt (e.g. via cursor rules).

Some examples:

• you can use dynamic allocation, but only at the setup phase
• all printfs should be wrapped in a macro to easily disable them
• asserts should only happen in non-production binaries
• you should always read the datasheet of the device you are working with

We've seen this taken one step further, aiming to make your codebase more error-proof (human or AI):

• use a FreeRTOS heap that enforces good practices (e.g. heap 1)
• wrap dangerous primitives like semaphores/mutexes in RAII objects and promote or enforce their use
• add system tests to your CI that will exercise and measure important aspects of embedded software health, such as memory and CPU consumption

Good structure

We'll say it again: AI models are no different from other newcomers to a codebase. Their main source of inspiration will be the existing code.

Develop the practice of writing platform agnostic HALs and OSALs, and unit test the code that relies on them offline. Not all embedded software is bitbanging, test your logic.

Separate prototype-y code from that which has been revised. Just keeping different folders with clear names, e.g. prototypes, is enough. You can further clarify this in your prompt.

Implement small scripts that automate, but more importantly, document how you test. It's fun to see how just adding a script called run-unit-tests.sh will let Cursor agentic software know how new code can be tested.

Wait, wait, did you say CI?

Yes. We have got to the point where most embedded software engineers will agree this is the way to go, but there's still some around that think "that's for typescript coding monkeys". At Focus, we have extensive experience developing Hardware-In-The-Loop (HIL) automated test fixtures that integrate seamlessly with CI/CD environments. These systems autonomously build, flash, and test firmware images using a comprehensive suite of predefined tests. In our experience, this approach is highly effective for keeping both project timelines and budgets on track.

It's all going back to empowering your energy-filled, big-smiled, hopeful junior developer to code without fear. And get good feedback on what they might be breaking. It's no different for AI models.

• Implement devcontainers that empower your team with tools to test part of that CI locally, regardless of their setup.
• Reuse the devcontainer to implement a quick and easy CI on GitHub/Gitlab/Bitbucket. AI is your friend here too.
• The nirvana: register a local worker in your CI, that is able to access the target hardware and execute some tests as part of the development workflow.

Good reviewers

All we talked about goes towards increasing the chance of AI generating good code. But at the end of the day, it is still up to humans to validate its quality.

Not all programmers are good reviewers. We'd argue that they are actually pretty rare. However, this will increasingly become a bigger part of their job.

As with humans, make sure critical code is guarded by at least one sound code owner.

Teach your reviewers to focus on content, rather than just form.

Reviewers should not be responsible for validating that code does what it is meant to do. That can be as hard as the coding problem itself. Reviewers are responsible, though, for ensuring that the code is well tested. Prompt your AI to generate tests for the code it writes, for which it is good at. And validate those tests in the review process.

What about intellectual property?

Privacy is always a topic of concern when sending IP to a cloud service. This is specially aggravated by the fact that providers might be using the uploaded IP to train their models.

As expected, providers are slowly adapting to this pain. Recently, for example, Cursor allowed the use of background agents with privacy mode enabled. The tendency seems to point towards that, as long as we can have a trust relationship with AI providers, we should be able to consider our IP protected with the use of these tools. The ability to trust these organizations will have to be reviewed case by case, weighting the risks with the potential gains.

Start experimenting now!

So, there you have it. Vibe Coding isn't some far-off dream; it's a tangible shift happening right now in embedded software development. By treating AI like that bright, eager junior developer – one who thrives on clear guidance and a well-structured environment – you can drastically reduce friction and accelerate development cycles. Ready to reshape your development workflow and give your team the AI superpower they deserve? The time to embrace Vibe Coding is now.