Exploring AI Agent Programming in Low-Level Firmware Development

1. Background: Is Low-Level Development an AI-Free Zone?

Recently, AI-assisted programming has sparked widespread discussion, with some developers even jokingly referring to traditional hand-coding as “artisan programming.” However, in the firmware and BIOS development community, a popular view is that while AI is fine for writing web applications and scripts, it falls short in “niche” domains like hardware programming, register manipulation, and UEFI protocol stacks. The argument is that AI lacks sufficient training data and professional understanding, requiring senior engineers to step in.

This view has some merit—low-level development materials are scattered, debugging chains are long, and the supporting ecosystem is weak. However, it overlooks two points. First, AI’s professional knowledge can be supplemented through local knowledge bases and specification document injection. Second, low-level development is divided into two main categories: creative development (new features, new modules) and porting (adapting to new hardware and platforms). The latter is highly pattern-based and perfectly suited for AI to assist in refactoring the entire development workflow.

Rather than just theorizing, it is better to design a strict practical challenge to verify this.

2. Challenge Setup: A Strictly Constrained Environment

To make the test results convincing, I deliberately set near-harsh rules:

• Environment Limits: The Windows environment only has one mainstream C compiler toolchain installed, with no auxiliary tools prepared.
• Code Limits: The local codebase is zero. I, the human, will not write a single line of code.
• Guidance Limits: No professional directional guidance is provided. The AI agent must complete the entire process autonomously.

Goal: Develop a GUI Breakout game that can run under the UEFI Shell and supports Chinese display. In other words, compile an executable file, copy it to a USB drive, plug it into a computer, enter the firmware Shell environment, and run it.

Choosing Breakout as a test case is a standard industry benchmark. It has a clear structure, covering core elements like graphics rendering, user input, and collision detection, while remaining small enough to observe the AI’s complete working process within a limited time. Compared to a web environment, the biggest difficulty in a firmware environment is the lack of a supporting system—there is no ready-made windowing system, graphics library, font rendering, or input framework. Everything must be built from the protocol layer.

3. Working Paradigm Differences Between Two Types of Agent Tools

Before diving in, let’s clarify the differences between the two mainstream types of agent programming tools available today, as this directly impacts the low-level development experience:

IDE Plugin Tools: Primarily focused on conversational completion and embedded chat. The developer leads file editing, and the AI provides suggestions. The advantage is high controllability, but the downside is that cross-file, multi-round complex engineering tasks require heavy manual intervention for context organization and task orchestration.

Terminal Agent Tools: Run as command-line agents capable of autonomously browsing codebases, planning tasks, batch-modifying files, executing compilations, and reading errors for self-correction. The core value of these tools lies in their closed-loop capability—after a compilation failure, they can read the logs themselves, locate the problem, and modify the code again, forming an automated “code -> compile -> error -> fix” loop. This is particularly critical for low-level development because firmware build systems are complex and error messages are obscure, making the cost of manual back-and-forth troubleshooting extremely high.

For a task like this, built from scratch, the autonomous closed-loop capability of terminal agents is clearly more suitable.

4. Process Review

Phase 1: The Breakthrough from Zero to One

The agent first autonomously completed the scaffolding of the project: initializing the build environment, organizing the directory structure, and writing the build description files. During the process, a few typical “detours” occurred, which are quite representative:

First, it proactively tried to copy components from a non-existent local source tree, introducing many irrelevant dependencies and slowing down the build. This is a common “over-imitation” tendency in agents; most of the training data they have seen is based on complete codebases, whereas our environment was a zero-start point.

Second, when writing the Shell application entry point, it initially followed conventional thinking and compiled directly, encountering an entry convention mismatch with the build configuration. However, thanks to its closed-loop capability, it read the error, adjusted the module type definition and linker options, and after a few iterations, achieved its first successful compilation and execution, displaying interactive block graphics on the screen.

Phase 2: Iteration from Good to Great

Once it was running, I drove four iterations through minimal natural language commands:

1. Feature Enhancement: Added game logic such as scoring, level progression, and ball speed changes.
2. Visual Optimization: Used block characters to draw borders and bricks, improving interface layout.
3. Display Tackling: This was the hardest part. Graphics output in firmware depends on specific output protocols, and resolution and pixel formats are constrained by the runtime environment. The agent queried the graphics output interface provided by the system and dynamically adapted to the resolution, ultimately solving the rendering problem.
4. Chinese Breakthrough: The default font library in the firmware environment does not contain Chinese glyphs. The agent’s solution was to bring its own font library—embedding dot-matrix font data into the program and implementing font rendering itself, bypassing the dependency on system fonts.

One detail worth mentioning: introducing Chinese comments temporarily caused a compilation failure (an encoding issue). The agent autonomously located the compatibility issue between the source file encoding and the build tool and fixed it. This ability to self-repair engineering details is a qualitative change of the Agent paradigm compared to the traditional completion model.

5. Cost and Efficiency Trade-offs

Time Cost: The entire project, from zero to playable with Chinese support, was completed in a few hours. If done manually using traditional methods to build a UEFI graphics program from scratch, just exploring protocols and debugging the environment would take far longer.

Economic Cost: Top-tier models are undoubtedly the most capable, but their costs are high for daily development. As a common industry analogy goes: a Ferrari is great, but most people need an economical family car. A reasonable strategy in practice is: use high-capability models for architecture design and critical breakthroughs, and use cost-effective models for routine iterations and bulk modifications. Coding packages provided by some cloud vendors also reduce the pressure of pay-as-you-go billing.

Output Statistics: The final delivery includes a complete runnable program with source code, build scripts, and font data. 100% of the code was generated by AI; humans only provided the requirement descriptions and acceptance testing.

6. Conclusions and Practical Recommendations

This case proves that AI is not only usable in low-level firmware development but can also reshape the development paradigm. Here are a few reusable experiences:

1. Choose the right task type: Pattern-heavy porting tasks and small, well-structured creative tasks are best suited for autonomous agent completion.
2. Leverage closed loops: Prioritize tool forms that can autonomously execute compilations, read errors, and self-correct, freeing humans from the role of “error translator.”
3. Knowledge injection: For niche domains, preparing specification documents or local knowledge bases can significantly improve the first-pass success rate.
4. Tiered costs: Dynamically select model tiers based on task difficulty to balance quality and budget.
5. Human role shift: The engineer’s value shifts upward from “writing code” to “defining goals, verifying quality, and controlling architecture.”

Low-level development is not an AI-free zone; it is the next main battleground for agent-based programming.