AI-assisted code generation is redefining how we write embedded software and program embedded devices. AI agents can write a code snippet, prepare a test, or explain how a library works. For someone just starting out with embedded software development, it sounds great. 

In fact, according to the State of Embedded Software Quality and Safety Report by Black Duck, 89.3% of embedded software organizations now use AI coding assistants. However, over 21% of these organizations admit they lack confidence in their ability to prevent AI from introducing security vulnerabilities into target firmware. It shows that in AI software development, there are a few catches that might not be noticed at first but pose a real problem.

In a regular application, an error often ends with a message on the screen or the need to deploy a fix. In embedded, the code controls a real device that cannot be easily updated. These can include unpredictable reboots, faster battery drain, data loss, and in the worst case, even bricking the hardware. In the case of medical devices, this is absolutely unacceptable.

Writing embedded software with artificial intelligence may be challenging but it does not mean that AI should not be used. Rather, one needs to know in which tasks it can help, and where it is better to be more cautious.

Understanding AI in embedded software

Embedded code runs on specific hardware. What matters is the microcontroller model, the amount of RAM and flash memory, the SDK version, the RTOS used, and how the device is powered. Added to this are interrupts, watchdog, communication with sensors, and various power-saving modes.

The AI model does not know these details unless we provide them in the question. When we ask it to write embedded software for MQTT handling, we will receive a generic example. Such code may look sensible but may not take into account the modem used, memory limitations, or other tasks running in the system.

In the beginning, it is easy to assume that since the code compiles, it is correct. However, in embedded development, compilation is only the first step. It is still necessary to check the program’s behavior on the board and see what happens, for example, after a loss of connection or power.

Research on LLM usage in microcontroller programming (such as studies published by MDPI) frequently points to the problem of hardware or API hallucination. Due to a lack of full hardware context, an AI model may invent non-existent library functions or incorrect register addresses – producing code that looks syntactically sound but fails on actual hardware.

Code to be careful with

Greater risk appears in custom-created embedded software responsible for device startup, OTA updates, security, and direct hardware handling.

A good example is firmware update. If power is lost during writing, the device should still be able to run the previous version. An error in the bootloader or memory handling can make the hardware stop working. A sample made with AI-assisted code generation alone is not enough as confirmation that the solution is safe.

A similar problem applies to reconnecting to the network. The simplest code may try to connect every second. On a single test board, this will work. However, with a large number of deployed edge devices, this behavior can vastly increase energy consumption and in some cases overload server. Delays, a retry limit and handling of situations when there is no connection for a long time are needed.

Interrupts, flash memory operations, buffers in C and C++, certificates, and keys also require special control. AI may skip checking data size or make an assumption that does not fit the given hardware.

How to use AI in embedded software development?

When integrating AI into your development workflow, it is best to start with things that can be easily checked. Artificial intelligence can prepare a test draft, a simple script for log analysis, or a sample project configuration. It is also useful for translating code and documentation, especially when just learning a given API.

Another important use is searching for our system’s vulnerabilities, with an important emphasis: this must be done if and only if we use a model that does not further process our data. In addition, any findings must be very thoroughly manually verified. Advanced AI Agents may be able to, for example, find a potential vulnerability through which a person with bad intentions could break into the network of a person possessing a smart IoT device that has network access.

Searching for edge cases to improve automated test generation is also in use. For example, for a data parser, one can ask about empty messages, incorrect format, too long data, or missing some fields. AI can create the first list of tests, and the developer later checks and completes it.

Organizing requirements can also provide smart debugging assistance. A simple requirement: ‘the device sends data to the cloud’ does not yet specify:

  • how often the sensor data is to be sent,
  • how to process sensor data,
  • what to do after losing the connection,
  • where to store unsent data,
  • how long to retry the connection,
  • what to do with a repeated message.

AI can draw attention to such questions. However, it does not know the entire project, so it should not independently choose the final solution.

Research

Another practical example is researching libraries that might be useful in your software development pipelines. For example, in one of our projects, we managed to find a public library, imgui_test_engine, which none of us in the team knew because it is a total niche. Ultimately, it turned out to be crucial for interacting with our system and allowed us to cover the entire system with automated tests that realistically reflected real scenarios.

However, library versions are a problem. AI can combine code from several versions of Zephyr, ESP-IDF, or STM32 HAL. Sometimes such an example will not compile, and the error will be immediately visible. It is worse if it compiles but uses the API in an incorrect way.

Therefore, it is worth providing at least the microcontroller used, SDK version, operating system and basic device limitations in the question. The answer must later be compared with the documentation of the correct version.

Data security

When using AI-assisted code generation, there is one more thing that concerns us: the security of the data we feed into these tools.

During debugging, it is easier to paste the entire log or a larger fragment of the project. There may be customer data, device identifiers, server addresses, certificates, or information about a product that has not yet been released.

Passwords, private keys, or confidential code should not be sent to public tools. The company should also determine which tools are permitted and what information can be transferred to them.

How to approach code from AI

I would treat code generated by AI similarly to code found on an online forum. It can be a good starting point, but you need to understand what it does and test it in your project. Blindly pasting unverified code into a commercial product is actually one of the key mistakes businesses make when evolving their IoT device.

Before use, it is worth answering a few simple questions:

  • Does the code match our hardware and SDK version?
  • What will it do after a loss of power or connection?
  • Does it check incorrect input data?
  • How much memory does it use and how long does it take to execute? Has it been tested on a real device?
  • Does anyone on the team understand it well enough to fix it later?

If we cannot explain the operation of a code fragment, we should not add it to production firmware just because it was prepared by AI.

A proper prompt is key

A good prompt is important because AI does not know our project. It is worth providing it with as much context as possible, but only that which is relevant to the given task. The question should be precise. A larger problem is best divided into several smaller steps to streamline your development workflows. Too much unorganized information can make the model skip important constraints or start guessing.

When checking the answer, you can also open a separate chat with an empty context and ask the model to find errors. A model developing its own solution sometimes sticks to earlier assumptions and ignores their weaknesses. A fresh context can help notice them, but it still does not replace documentation, tests, or human review.

Generative AI can facilitate learning embedded software development and speed up simpler tasks. It is also useful for planning tests, analyzing device logs, documentation, and looking for ideas – in short, managing areas where we are able to easily check it measurably.

However, it does not replace checking the documentation and physical testing on the target hardware. The closer to critical areas, whose failure can be irreversible or very difficult to repair, the more cautiously one must approach generated code.

At this moment, I see artificial intelligence mainly as an assistant for the developer, not a full replacement. It can suggest a solution, but the responsibility for checking it still remains with the programmer. To see how these two worlds merge on a larger scale, read about how AI-powered embedded systems are redefining the Internet of Things landscape.

Conclusion

Integrating artificial intelligence into embedded software development offers clear efficiency advantages, particularly during early prototyping and testing phases. However, in safety-critical environments – where code errors lead to bricked hardware – AI cannot replace rigorous human review. By approaching AI as a supportive assistant rather than an independent engineer, development teams can safely accelerate their delivery pipelines while maintaining absolute control over product.

Frequently asked questions

What is AI code generation?

AI code generation is the automated process of using artificial intelligence models and developer agents to write code snippets, draft unit tests, prepare project configurations, and explain complex API documentation. In embedded systems engineering, this workflow, known as AI-assisted software development, refers to leveraging large language models to streamline routine programming tasks and accelerate prototyping.

How to write a proper prompt to get reliable embedded code?

A proper prompt is defined as a context-rich instruction that specifies the MCU model, SDK version (e.g., Zephyr, ESP-IDF), memory limits, and hardware constraints. Prompting in embedded development refers to breaking complex software tasks into modular steps to prevent model confusion.

How to approach generated code from AI?

Approaching AI-generated code refers to treating any model output as an unverified draft requiring rigorous code review. In firmware development, AI code should be perceived as a initial starting point rather than production-ready logic.