How AI Has Changed Firmware Development Over the Past Two Years
The biggest change in my firmware development workflow over the past two years has been the advancement of AI tools. When I started experimenting with ChatGPT toward the end of 2024, I primarily used it to find information. Instead of trying several search queries and working through various Stack Overflow discussions, I could describe the problem, explain the constraints, and ask follow-up questions. It did not always find the answer, but it often helped me narrow down what I needed to investigate.
For processor-specific questions, I found it useful as a sounding board. I could discuss a peripheral configuration or an implementation approach and get suggestions about what to look for in the documentation. The answers still needed verification, but having an entity to bounce ideas off of was valuable.
Early Code Generation Worked Best on Bounded Tasks
Early code generation worked best when I gave ChatGPT a well-defined, smaller task. General-purpose functions and scripts — Python, MATLAB, batch files, and shell scripts — were particularly useful applications. Larger requests were less predictable. If I included too many requirements in one prompt, parts of the request could be misunderstood or overlooked. I also used it for WPF interface work, where it could produce useful XAML but sometimes missed layout or behavior requirements.
Over time, I noticed the responses becoming more organized and the technical guidance becoming more useful. Even the basic chatbots began to handle larger asks more gracefully. At times, the AI would even ask for clarification on portions of the prompt and might suggest omitting or altering portions for a cleaner implementation.
GitHub Copilot and a Secure, IP-Protected Enclave
The larger change for me, though, came with our DE Design Works secure, IP-enclave, enterprise version of GitHub Copilot integration in the development environment. Instead of discussing a change in a separate conversation and implementing it manually, I could ask for changes within the project. Creating files, making repetitive edits, and assisting with refactoring became much faster. Suggestions could also follow the surrounding naming conventions and coding style, which reduced some of the effort of fitting new code into an existing codebase. Any requests for assistance in structuring or troubleshooting issues were more reliable and required less information in the prompts compared to a separate chat web UI. I didn’t need to thoroughly explain the codebase. It could see the codebase.
Key Takeaways
- AI shifted from a search tool to a coding collaborator: General chatbots are useful for research and as a sounding board, but an IDE-integrated assistant like GitHub Copilot — one that can see the codebase — changes the kind of work AI can help with.
- AI performs best on bounded, well-defined tasks: General-purpose scripts, driver adaptations, and repetitive refactoring are reliable use cases; open-ended, multi-requirement prompts are not.
- The real benefit is reduced cognitive load, not just speed: Offloading repetitive implementation work frees an engineer’s attention for hardware constraints, error handling, and system-level judgment.
- AI-generated code is a first draft, not a deliverable: Treat it the way you would a bounded task handed to a junior engineer — explain what’s needed, review the result, and verify on real hardware.
- AI doesn’t know what was never written down: It can’t connect to a scope and confirm SPI timing, and it has no visibility into constraints discussed in customer meetings, design reviews, or internal calls.
The Benefit Is Not Only Speed
When architecting firmware, I am keeping track of hardware constraints, application behavior, interfaces, error handling, and project deadlines. Repetitive implementation tasks still require attention, even when they are not particularly difficult. AI can take on some of that work and give me a first implementation to review.
A Concrete Example: Adapting a Driver for a Replacement Part
For example, suppose an EEPROM we regularly use becomes unavailable, and the replacement uses a different command sequence. Adapting the driver is something an experienced engineer can easily do, but it is still another task requiring time and concentration. With the relevant documentation and clear instructions, AI can help draft the changes. I can then concentrate on checking the assumptions, reviewing the implementation, and testing the behavior.
I consider that interaction tantamount to delegating a bounded task to a junior engineer: explain what is needed, review the result, and request revisions. That analogy describes the review responsibility — not a reason to assume the generated code is correct.
Faster Implementation Does Not Remove Engineering Responsibility
Verification Still Belongs to the Engineer
An AI assistant can help write a driver, but I still need to verify that the device behaves correctly on the actual hardware. It cannot physically connect to my scope and confirm that the SPI bus is communicating correctly with an EEPROM.
Context the AI Doesn’t Have
There is also a difference between access to the codebase and understanding the product. Even when an assistant can inspect project files, it does not automatically know every constraint discussed in customer meetings, internal calls, emails, or design reviews. A change can look reasonable in the code and still conflict with the intended system behavior.
That is why I treat AI-generated code as a starting point, not a finished deliverable. I still need to understand the implementation, check its assumptions against the product requirements, and validate it in the system. AI can help carry out the work, but the responsibility for deciding whether that work is correct remains with the engineering team.
Why DE Design Works
Since 2002, we have built embedded firmware and electronics for industrial, medical, military, and IoT products. AI has changed how our engineers work day to day, but it has not changed the standard a product has to meet before it ships. We still verify on real hardware, still validate against the product requirements, and still take responsibility for the engineering decisions — whether the first draft of a line of code came from a teammate or a model.
If you have a firmware or embedded software program where you want engineers who treat AI as a tool and not a shortcut, that is the conversation worth having.
Frequently Asked Questions
Can AI tools like ChatGPT or GitHub Copilot write production firmware code?
They can draft bounded, well-defined pieces of code — a driver adaptation, a utility script, a repetitive refactor — that an engineer then reviews, tests, and verifies against the actual hardware. They are not reliable for open-ended architecture decisions or for anything that has not been checked against real device behavior. Treat AI output as a first draft from a junior engineer, not a finished deliverable.
Is AI reliable for processor-specific or peripheral configuration questions?
It is useful as a sounding board. You can describe a peripheral configuration or an implementation approach and get suggestions about what to look for in the datasheet or reference manual. The suggestions still need to be verified against the actual documentation and confirmed on hardware, but having something to work through the problem with narrows down the investigation faster than searching alone.
What’s the difference between a general AI chatbot and an IDE-integrated assistant for firmware development?
A general chatbot requires you to explain the codebase and context in every conversation, which limits it to smaller, self-contained requests. An IDE-integrated assistant, such as an enterprise GitHub Copilot deployment running inside a secure, IP-protected development environment, can see the existing codebase directly. That means it can follow existing naming conventions and coding style, make repetitive edits across files, and assist with refactoring with far less prompting — while the generated code still goes through the same review process.
Does using AI in firmware development reduce the need for hardware testing?
No. AI can help draft a change, but it cannot connect to a scope or logic analyzer and confirm that a bus is communicating correctly, that timing constraints are met, or that the device behaves correctly under real operating conditions. Faster implementation does not remove the engineering responsibility to verify behavior on actual hardware before it ships.
What’s the biggest risk of relying on AI-generated firmware code?
Treating generated code as a finished deliverable instead of a draft that requires the same review as work from any engineer. AI has no visibility into constraints discussed in customer meetings, internal calls, emails, or design reviews, so a change can look reasonable in the code and still conflict with the intended system behavior. The team, not the assistant, remains responsible for deciding whether the implementation is correct.