AI Coding Agents in Practice: Developing a Graphics Game in Firmware with a Command-Line Agent

Background: AI Programming Is Reaching the Hardest Layers

AI-assisted programming is being adopted faster than many expected — so fast that in hardware circles, traditional hand-written coding without AI has earned the tongue-in-cheek label of “old-school programming.”

In firmware development (such as BIOS/UEFI), a long-standing belief holds that AI is fine for high-level applications but falls short for low-level work. Engineers with this view argue that hardware programming, register manipulation, and protocol stack implementation lack sufficient public training data and domain understanding, so AI can’t produce correct answers and experienced engineers must do the work manually.

This concern is legitimate but not insurmountable. In practice, at least two approaches can close the gap:

1. Local knowledge bases: Build private resources — chip manuals, specification documents, internal coding standards — into a retrieval library so the AI generates code with the correct context;
2. Restructuring the development workflow: Instead of just “having AI complete code,” hand the entire loop — requirement decomposition, code generation, compilation and debugging, error fixing — to an AI agent, amplifying efficiency gains at the process level.

Firmware development falls roughly into two categories: creative programming (new features, new algorithms) and porting (adapting existing code to new hardware or platforms). AI provides clear value in both, but especially in porting — the repetitive adaptation work is exactly what agents excel at.

A “Hell-Difficulty” Verification Experiment

To test what a command-line AI agent can really do in low-level development, I designed a challenge with strict rules:

• Environment constraints: A Windows machine with only one standard build environment installed — no other tools;
• Knowledge constraints: Zero local code base, and I would not write a single line of code myself;
• Intervention constraints: No professional guidance — the AI handles everything autonomously.

Goal: Build a graphical Breakout game with Chinese text support that runs under the UEFI Shell. In plain terms: copy the build output to a USB drive, plug it into a computer, boot into the firmware Shell, and run it.

Breakout has long been my go-to test project. It has a clean structure and complete logic, covering graphics rendering, user input, collision detection, and game state machines — a classic benchmark for programming capability. I’ve run similar tests on the web and on HarmonyOS; the firmware environment raises the difficulty significantly. The core challenge, as those in the field know, is the absence of supporting infrastructure: no graphics library, no standard input/output, none of the runtime services a normal operating system provides. Everything must be built from the protocol level up.

Why the Command-Line Agent Paradigm

There are currently two mainstream AI coding tool paradigms:

1. IDE plugins: Provide completion, chat, and local refactoring inside the editor, with the human driving every step;
2. Command-line agents: Run as a CLI, where the AI can autonomously read and write files, execute build commands, inspect errors, and iterate on fixes. The developer only sets goals and accepts results.

The key difference lies in task loop closure. In the IDE plugin mode, after a build failure you must manually copy the error and paste it back into the conversation. In agent mode, the AI can directly execute the build, read the error output, locate and fix the problem, forming an automated loop of “code → build → error → fix → build again.” For firmware — a domain with complex build configurations and cryptic error messages — this closed-loop capability delivers order-of-magnitude efficiency gains.

That said, letting an AI execute commands autonomously carries risk. In real usage, work in an isolated directory, and make sure you understand what the autonomous mode’s risk warnings mean before enabling it.

The Build: From Zero to a Working Game

4.1 Initializing Project Context

After starting the command-line agent, my first instruction was project initialization — generating a project description file in Chinese that states the goal:

Initialize the project documentation, declaring that this directory
will contain a graphical application running under UEFI Shell —
specifically, a Breakout game, with no audio requirements.

The value of this step is anchoring the context. The project document continuously shapes all of the agent’s subsequent decisions — choice of build framework, directory structure, graphics implementation approach. In a domain lacking supporting infrastructure, writing domain constraints into the project document early and clearly is the single most important way to keep the AI on track.

4.2 Autonomous Evolution of Key Technical Decisions

With almost no human intervention, the agent followed a sensible decision path:

• Graphics approach: In a UEFI environment, the most viable graphics output is direct manipulation of the graphics output protocol — acquiring the framebuffer and drawing pixel rectangles via Blt operations. The agent correctly abandoned “higher-level” approaches that no library support exists for, and chose a protocol-level implementation;
• Font rendering: Chinese text requires a bitmap font. The agent took the pragmatic route of embedding bitmap arrays, generating glyph data only for the characters that needed to be displayed, avoiding a full font rendering engine;
• Input handling: Paddle control via key input events, mapping scan codes to left/right movement;
• Game logic: Brick arrays, ball motion vectors, rectangle collision detection, lives, and win/lose conditions — all implemented with clean module separation.

4.3 The Build-Debug Loop

Firmware build configuration (package description files, build rules) is where newcomers most often stumble. After the first build failed, the agent read the errors, corrected the module declarations and dependencies in the build configuration itself, and after several automated iterations produced an EFI executable ready to copy to a USB drive.

Engineering Thoughts on Cost and Model Selection

On model choice, one widely shared experience applies: flagship models deliver an excellent experience, but pay-as-you-go costs run high for daily development. There’s a fitting industry analogy: a Ferrari is great, but most people need an economical family car.

For ordinary developers, a more sensible strategy is to subscribe to a cloud provider’s AI coding plan for a fixed monthly cost and predictable allowance, and to prioritize experimenting across multiple mid-tier models to build your own evaluation matrix. Different models have different strengths across task types — architecture design, code generation, debugging and fixing. Establishing a personal evaluation baseline is more valuable in the long run than blindly chasing the latest flagship model.

Summary and Best Practices

From this experiment, several key lessons for using AI agents in low-level development:

1. Context first: A clear project document stating domain constraints is the primary lever for steering agent behavior;
2. Closed loops win: Prefer agent paradigms with an automated “build — error — fix” loop over pure completion modes;
3. Fill knowledge gaps with a knowledge base: Build private specifications and hardware documents into local retrieval knowledge to compensate for scarce public training data;
4. Manage intervention density: When your goal description is clear, reduce mid-course intervention and let the agent run complete iteration cycles — the results are often better;
5. Be rational about cost: Use cost-effective plans with mid-tier models for daily work, and escalate to flagship models for complex tasks.

The conclusion is optimistic: the boundary of “AI can’t do low-level development” is steadily being pushed back by the combination of agent paradigms and local knowledge bases. For domains like firmware — where supporting infrastructure is missing and repetitive adaptation work is heavy — AI’s contribution isn’t a nice-to-have enhancement; it’s a fundamental restructuring of the development workflow.