1. Why Run This Experiment?

There is a great deal of discussion about LLM-assisted programming, but most evaluations stay in scenarios with mature support environments, such as web pages and scripting tools. The real test is different: when a programming task has almost no existing framework, no package manager, and no local reference code, can AI still complete it independently?

To answer that question, I designed an extreme validation experiment: Can an AI coding agent reshape the development paradigm in low-level firmware development and genuinely improve efficiency?

Experiment Rules

To make the results credible, I set nearly harsh constraints:

1. Extremely limited environment: The Windows system had only one mainstream C/C++ toolchain installed, with no other auxiliary tools.
2. Zero local knowledge: No reference code was placed locally, so the AI could not take shortcuts from an existing project.
3. No human intervention: I did not write a single line of code and provided almost no professional guidance, leaving the AI to make decisions autonomously throughout.

Experiment Goal

The goal was to develop a graphical Breakout game that runs under the UEFI Shell and supports Chinese character display. In practical terms, the program should be copyable to a USB drive, inserted into a computer, and run directly after entering the BIOS Shell.

Breakout has been my habitual test case for years: it has a clear structure and complete logic, while covering core programming elements such as graphics rendering, user input, and collision detection. I had previously run similar tests in web and mobile environments. This time, moving to the BIOS environment significantly raised complexity. The difficulty was not the game logic itself, but the near-total absence of supporting systems.

2. Why the UEFI Environment Is a True Touchstone

Modern application development feels “easy” because a large support system sits behind it: the operating system provides system calls, runtime libraries hide hardware details, package managers resolve dependencies, and graphics frameworks handle rendering. The UEFI Shell environment is close to running bare:

• No standard library: Many conventional C library functions cannot be used directly. Memory allocation and string handling must rely on the limited interfaces provided by firmware.
• Graphics output must be handled manually: The framebuffer must be obtained through the firmware’s graphics output protocol and drawn pixel by pixel, with no ready-made UI controls.
• Input model is special: Keyboard events are read through firmware input protocols, and a key state machine must be built manually.
• Chinese display is harder: The firmware environment has no system font rendering service, so a bitmap font must be supplied and Chinese characters converted into pixel bitmaps before drawing.
• Build chain is complex: UEFI applications have special compilation, linking, and image format requirements, and cross-compilation configuration is easy to get wrong.

This means the AI must integrate knowledge across domains: firmware specifications, graphics algorithms, font encoding, and build systems. If any one link fails, the program will not run.

3. Choosing the Tool Form: Why an Agent-Style CLI Tool?

AI-assisted programming currently has two main forms:

1. IDE plugin style: Developers request code completion or modifications file by file in an editor, with humans leading the process.
2. Agent command-line style: AI runs as an agent that can browse directories, create files, execute build commands, read errors, and iterate on fixes autonomously.

This experiment chose the Agent style because the rules required that “the human writes no code at all.” The key advantage of the Agent style is that it forms a closed loop:

Understand task → Plan structure → Generate code → Compile → Read error information → Fix → Recompile → Run verification

In this loop, compiler errors are the most valuable source of information. After receiving real error output, the AI can analyze the cause on its own, such as incorrect linker parameters or misuse of protocol interfaces, and iterate repeatedly until it passes. This is exactly what traditional “copy-and-paste” AI programming cannot do.

One caveat: Agent tools can execute commands directly. Granting open permissions carries risk, but in an isolated experimental environment, open permissions allow the agent to fully exercise autonomy. In production environments, permission controls and sandbox mechanisms should be used.

4. Model and Cost Tradeoffs

I compared several model options. Top flagship models certainly deliver an excellent experience: fast responses and clear logic, but the cost is high for daily development. There is a vivid industry analogy: a sports car is excellent, but most people need an economical family car.

For this experiment, I therefore used a more cost-effective model from a cloud provider’s coding plan as the main model. This hybrid strategy—flagship models for architecture design and cost-effective models for daily iteration—is itself a practice worth promoting. In the future, I plan to use models from different vendors to complete similar tasks and form a horizontal comparison. Today, let us first look at the performance of this experiment.

5. Experiment Process Review

The first step was to have the AI establish project context. My first instruction was to initialize a project description file, describing the task goal in Chinese: write a graphical Breakout game for the UEFI Shell in the current directory, with no sound required.

This initialization step was critical. The project description file, effectively the Agent’s “task constitution,” keeps the AI anchored to the goal during every subsequent iteration and prevents it from drifting. A qualified description file should include:

• Target platform and runtime environment: UEFI Shell, x86_64;
• Core constraints: no standard library, self-drawn graphics, bitmap font;
• Delivery criteria: bootable, operable, and capable of displaying Chinese characters.

From the subsequent process, the AI’s performance showed several noteworthy patterns:

1. Architecture first, clear modules. The AI did not immediately pile up code. Instead, it first planned module divisions: graphics layer, input layer, font layer, game logic layer, and entry layer. This layered and decoupled approach was even better than many hand-written projects.

2. Compilation errors were the biggest obstacle. The build configuration for UEFI applications involves special subsystem types, entry points, and linker options. The AI failed several initial compilations, but by reading error messages and correcting itself autonomously, it got the build chain working after a few rounds. This validated the value of the Agent loop: as long as error information is available, the AI’s repair ability is considerable.

3. Chinese display was a highlight. The AI designed a bitmap font approach on its own: it built an index for the required Chinese characters, encoded 16×16 bitmaps as binary arrays, and expanded them bit by bit into pixels during rendering. Although font coverage was limited, the approach was completely correct.

4. Game logic worked on the first pass. Core logic such as brick layout, paddle movement, and ball collision and bouncing was basically written correctly the first time, showing that this kind of “textbook-level” algorithm is within large models’ comfort zone.

6. Practical Methodology Derived from the Experiment

Combining this experiment with my observations in BIOS programming—where work broadly falls into creative development and porting to new hardware platforms—I summarize several methods for AI-assisted low-level development:

1. Use project description files well: Clearly state environment constraints, coding conventions, and goals. This is the most effective way to control Agent behavior.
2. Supplement a local knowledge base: For platform-specific protocols and interfaces, place summaries of official documentation in the project directory. This can significantly reduce the AI’s hallucination rate.
3. Maintain a compile-feedback loop: Letting the AI execute builds and read complete error output is a prerequisite for autonomous repair.
4. Refactoring the development paradigm is more valuable than code generation: AI is not just faster at writing code; it compresses the write–compile–debug cycle several times over, improving overall efficiency at the process level.
5. Adopt a cost-tiering strategy: Match model resources of different tiers to task difficulty, balancing quality and budget.

7. Conclusion

This experiment shows that even in a UEFI environment with almost no supporting system, an Agent-style AI programming tool can complete a fully functional graphical application with Chinese character display under minimal human intervention. The applicable boundary of AI programming is much wider than many people imagine. What really determines success is the design of task context, the construction of a feedback loop, and the reasonable choice of tool form. For low-level developers and enterprise users, rather than doubting whether AI is “not up to the task,” it is better to incorporate these methods into daily development workflows as early as possible.