AI-Assisted Low-Level Systems Development: Engineering Practices and an Efficiency Retrospective

1. Background: Can AI Participate in Low-Level System Development?

In low-level system development, there has long been a conservative view: AI is considered more suitable for generating application-layer code. Once the task moves into firmware-level work, boot environments, hardware initialization, or low-level protocol interaction, AI is often assumed to struggle because of high technical barriers, limited training corpus coverage, and complex runtime environments. This view is not entirely unreasonable. Low-level development often involves strongly constrained problems such as memory layout, boot flow, input/output abstraction, character rendering, compiler toolchains, and target format conversion. A small error in any one of these areas can prevent a program from loading, displaying, or running at all.

From an engineering perspective, however, the value of AI-assisted development is not to “completely replace engineers.” It is to restructure the development workflow. In traditional development, engineers often need to manually create directory structures, write build scripts, locate compilation errors, complete interface definitions, implement basic graphics logic, handle character encoding, and debug input/output. Not all of these tasks require deep expert experience. Many are structured, templated, and verifiable. AI can contribute in exactly these areas: generating initial code, explaining error messages, providing multiple implementation paths, filling in missing interfaces, generating test cases, and assisting with code refactoring.

A more meaningful discussion, therefore, is not simply whether AI can write low-level code. It is: Under what constraints can AI reliably participate in low-level development? How should tasks be decomposed so that AI output can be compiled, executed, and verified? What context must developers provide to reduce hallucination and error rates? This article uses a graphical breakout program running in a low-level environment as a case study to review the complete process of AI-assisted low-level system development.

2. Experiment Goal: From Requirements to a Runnable Program

The goal of this practice was to implement a small graphical program in a simplified low-level environment. The program should be able to run from a boot medium and execute after entering a low-level shell. Its functionality is similar to the classic breakout game: the screen displays a paddle, a ball, and several bricks. The user controls the paddle with key presses. The ball bounces when it hits the paddle or bricks. Hit bricks disappear. The program needs basic features such as scoring, restart, exit, and support for displaying Chinese-language prompt messages.

The breakout program was chosen because it is logically simple but covers several core problems in low-level graphics development:

1. Display output: How to clear the screen, draw rectangles, and refresh the image.
2. User input: How to read key presses, map directions, and handle repeated triggers.
3. Main loop: How to continuously update the image without excessive CPU usage.
4. Collision detection: How to determine relationships between the ball, paddle, bricks, and boundaries.
5. State management: How to represent states such as game start, in progress, paused, failed, and victory.
6. Text rendering: How to display English letters, numbers, and even Chinese characters without a high-level character library.
7. Build and deployment: How to generate the target format, copy it to boot media, and verify execution.

Unlike upper-layer application development, low-level environments usually do not provide ready-made window systems, font libraries, input libraries, or high-level graphics interfaces. All functionality must be built from more fundamental capabilities. This makes it a useful scenario for testing AI-assisted programming.

3. Constraint Setup: Keeping AI Within a Controllable Scope

To make the experiment reviewable, strict constraints were applied.

First, the local codebase was kept as empty as possible. The developer did not directly write business logic. Instead, the developer provided goals, constraints, error feedback, and confirmation of results. AI was responsible for most code generation, modification, and explanation.

Second, the development environment was kept minimal. Complex plugins, graphical frameworks, and large project templates were avoided. The approach prioritized basic compiler commands, text files, and simple build scripts. This made it possible to observe whether AI could still complete low-level tasks without advanced tooling.

Third, excessive professional guidance was not provided. The developer did not specify implementation details in advance. For example, no framebuffer address was predefined, no character encoding scheme was fixed in advance, and no game state machine was designed beforehand. AI was expected to derive implementation details from functional requirements.

Fourth, every iteration had to produce a verifiable result. Verification meant checking whether the program could compile successfully, whether a target file could be generated, whether it could run, whether basic images could be displayed, and whether it could respond to input. Low-level development especially requires closed-loop verification because many errors do not appear as normal exceptions. They may appear directly as black screens, freezes, lack of response, or garbled output.

The purpose of these constraints was not to prove that AI can independently develop low-level systems without human involvement. It was to observe whether AI could become an effective development collaborator under conditions of “limited information + clear feedback + continuous iteration.”

4. Round One: From Zero to One, Building a Runnable Prototype

The core goal of the first round was to get the program running from scratch. Visual effects and Chinese display were not priorities at this stage. The goal was to establish a minimal closed loop: the program could initialize, enter the main loop, draw basic graphics, and respond to input.

4.1 Environment Recognition and Build Script Generation

For a low-level program, the first step is not writing business logic. It is confirming whether the build chain is usable. AI first needed to determine which compilers, linkers, assemblers, or basic commands were available in the environment. Since the developer did not provide a complete toolchain description, AI had to refine the build script through error feedback.

A typical workflow was as follows:

1. Check whether compiler tools exist.
2. Generate a minimal entry file.
3. Try to compile it into an object file.
4. Link the object file into a loadable format.
5. Copy the generated file to the boot medium.
6. Run it in the target environment.

During this process, AI often generated overly idealized build commands or assumed that certain tools already existed. The developer only needed to return the real errors, such as “command not found,” “format not supported,” “missing entry symbol,” or “linking failed.” AI could then continue adjusting based on those errors.

This reflects an important value of AI-assisted low-level development: reducing environment trial-and-error cost. In traditional development, engineers often need to repeatedly consult tool manuals, search for compiler options, and compare output formats. With AI assistance, error messages can be interpreted directly and converted into suggestions for the next fix.

4.2 Graphics Initialization and Minimal Drawing

In a low-level environment, graphics display is usually not achieved by calling a simple function. The program must know basic information such as the screen buffer location, color format, resolution, and refresh method. AI’s first generated version was usually abstract. For example, it might define the following interface:

void screen_init(void);
void screen_clear(uint32_t color);
void draw_rect(int x, int y, int w, int h, uint32_t color);
void screen_flush(void);

The developer did not immediately require AI to implement all details. Instead, the first goal was to verify whether a rectangle could be drawn. If the rectangle did not appear, debugging continued to determine whether the issue was initialization failure, an incorrect buffer address, an incorrect color format, or a missing refresh mechanism.

This approach of “first get a minimal runnable version, then gradually fill in details” is well suited to low-level development. Low-level problems are often strongly coupled. Generating a complete program in one shot can hide errors. By validating through minimal checkpoints, the source of problems can be located step by step.

4.3 Input Reading and Key Mapping

The breakout program requires user input. In a low-level environment, input may come from a keyboard controller, polling function, event queue, or interrupt handler. AI needed to generate an input-reading interface based on the current environment, such as:

int read_input(void);

Then key states could be defined:

#define KEY_NONE    0
#define KEY_LEFT    1
#define KEY_RIGHT   2
#define KEY_ENTER   3
#define KEY_ESC     4

In real environments, input reading often suffers from jitter, repeated triggering, and inconsistent key mapping. AI could optimize it by adding state machines, debounce logic, or key locking. For example:

if (key == KEY_LEFT && !left_pressed) {
    paddle.x -= speed;
    left_pressed = 1;
} else if (key != KEY_LEFT) {
    left_pressed = 0;
}

This logic is not complex. Without AI assistance, developers would still need time to write and debug it. The advantage of AI is that it can quickly generate multiple versions, and the developer can select a suitable approach based on feedback.

4.4 Main Loop and Basic Collision Detection

A minimal runnable prototype needs a main loop. AI usually generated a structure like this:

while (1) {
    int key = read_input();
    update_paddle(key);
    update_ball();
    check_collision();
    draw_scene();
    screen_flush();
}

The paddle, ball, and bricks all need coordinates and dimensions. AI could define a basic structure:

typedef struct {
    int x;
    int y;
    int w;
    int h;
} Rect;
Rect paddle;
Rect ball;
Rect bricks[BRICK_ROWS][BRICK_COLS];

Collision detection could be implemented using rectangle intersection:

int rect_overlap(Rect a, Rect b) {
    return a.x < b.x + b.w &&
           a.x + a.w > b.x &&
           a.y < b.y + b.h &&
           a.y + a.h > b.y;
}

When the ball hits a brick, the brick is marked as destroyed and the ball’s direction changes. When the ball hits the paddle, the horizontal speed can be adjusted based on the hit position to improve playability. When the ball falls below the bottom of the screen, the game is considered failed or a life is deducted.

At this stage, the key point is not whether the code looks elegant. It is whether the logic forms a closed loop. AI needed to continuously adjust coordinates, speed, boundary checks, and refresh frequency based on runtime results.

4.5 First Successful Run and Typical Detours

By the end of the first round, the program could display the background, paddle, ball, and bricks, and could respond to arrow keys. Although the visuals were basic, this proved that AI could complete the basic loop from requirements to an executable program in a low-level environment.

Several typical problems also appeared during the process:

1. Path copy errors: The program built successfully, but the correct file was not present on the boot medium, so the environment could not load it.
2. Output format mismatch: The compiled artifact format did not match the target environment’s requirements, so it could not be recognized.
3. Missing entry symbol: The linking stage reported that the entry point was undefined, requiring adjustment to the boot entry function.
4. Refresh too fast or too slow: The image flickered or lagged, requiring delay or dirty-rectangle refresh mechanisms.
5. Input mapping errors: Key directions were reversed, requiring adjustment to the mapping logic.

These problems show that AI does not eliminate the need for human judgment. Many errors in low-level development do not appear as syntax errors. They are hidden in runtime environments, format conventions, and hardware abstractions. The developer’s value lies in providing real feedback and judging whether AI’s proposed fixes are trustworthy.

5. Round Two: From Functional to Better Usability and Completeness

The first round solved the problem of “being able to run.” The second round focused on making the program more usable, more complete, and more like a product. This stage included feature enhancement, visual optimization, display challenges, and Chinese-language display breakthroughs.

5.1 Feature Enhancement

After basic gameplay was implemented, AI could continue adding features:

• Score tracking: award points for breaking bricks.
• Lives: deduct a life when the ball falls.
• Level progression: refresh the brick layout after clearing all bricks.
• Pause and resume: toggle pause state with the confirm key.
• Difficulty adjustment: increase ball speed as levels progress.
• Game over screen: show final score and restart prompt.

These features could be abstracted into a state machine:

typedef enum {
    STATE_READY,
    STATE_PLAYING,
    STATE_PAUSED,
    STATE_GAME_OVER,
    STATE_LEVEL_CLEAR
} GameState;

The main loop could execute different logic based on state:

switch (game_state) {
    case STATE_READY:
        wait_start();
        break;
    case STATE_PLAYING:
        update_game();
        break;
    case STATE_PAUSED:
        draw_pause();
        break;
    case STATE_GAME_OVER:
        draw_game_over();
        break;
}

AI could gradually expand state branches based on requirements. The developer only needed to specify the entry conditions, exit conditions, and interface feedback for each state, and AI could generate the corresponding code.

5.2 Visual Optimization

The goal of visual optimization was to move the program from “can display” to “easy to read.” Common issues included screen flicker, monotonous colors, unreasonable element positioning, and non-smooth ball movement.

AI could apply the following strategies:

1. Double buffering: Draw to an offscreen buffer first, then refresh the screen in one operation.
2. Dirty-rectangle refresh: Refresh only changed areas to reduce unnecessary drawing.
3. Frame-rate control: Add delays or timers to prevent the loop from running too fast.
4. Color differentiation: Use different colors for the background, bricks, paddle, and ball.
5. State prompts: Display Chinese-language instructions on the start, pause, and end screens.

For example, frame-rate control could be simplified as follows:

void delay_until_next_frame(void) {
    uint32_t start = get_tick();
    while (get_tick() - start < FRAME_TIME_MS) {
        // Input can be handled here, or a low-power wait can be used.
    }
}

This is a simplified implementation, but it is enough to help AI understand that the loop rhythm needs to be controlled instead of refreshing at unlimited speed.

5.3 Display Challenge: From Graphics to Characters

The breakout program needs to display scores, prompts, and status information. Without an existing text-rendering interface, the program must directly draw character bitmaps.

AI needed to complete the following tasks:

1. Define character width and height.
2. Build a mapping from character codes to bitmap data.
3. Provide a function to draw a single character.
4. Provide a function to draw a string.
5. Handle line breaks, spacing, and coordinate calculations.

Example code:

typedef struct {
    char code;
    uint8_t width;
    uint8_t height;
    const uint8_t *bitmap;
} Glyph;
void draw_char(int x, int y, Glyph glyph, uint32_t color) {
    for (int row = 0; row < glyph.height; row++) {
        for (int col = 0; col < glyph.width; col++) {
            int bit = (glyph.bitmap[row * glyph.width + col] & 0x01);
            if (bit) {
                draw_pixel(x + col, y + row, color);
            }
        }
    }
}

String drawing requires calling the single-character function repeatedly:

void draw_string(int x, int y, const char *text, uint32_t color) {
    while (*text) {
        Glyph glyph = find_glyph(*text);
        draw_char(x, y, glyph, color);
        x += glyph.width + 1;
        text++;
    }
}

This stage is one of the difficult parts of low-level AI programming. Character display involves not only code but also resource data. AI needs to generate or reference bitmap data, and bitmap data is often large. It usually cannot be fully described through natural language alone. Therefore, developers may need to provide font bitmap files, encoding mapping tables, or have AI generate placeholder fonts first and replace them with real data later.

5.4 Chinese Display Breakthrough

Chinese display is more complex than English display. English has a limited number of characters and is easier to maintain. Chinese commonly used characters are numerous, and their glyphs are more complex. This usually requires larger bitmap data and more complete encoding mappings.

With AI assistance, a layered strategy can be used:

1. First display a small number of fixed Chinese phrases.
2. Build a dedicated font set for these phrases.
3. Look up the corresponding bitmap by character code.
4. If a character does not exist, display a placeholder block.
5. Expand the font set later.

The structure can be abstracted as follows:

typedef struct {
    uint32_t code;
    uint8_t width;
    uint8_t height;
    const uint8_t *bitmap;
} CjkGlyph;
CjkGlyph *find_cjk_glyph(uint32_t code) {
    for (int i = 0; i < cjk_glyph_count; i++) {
        if (cjk_glyphs[i].code == code) {
            return &cjk_glyphs[i];
        }
    }
    return 0;
}

The drawing function needs to support wide characters:

void draw_text_utf8(int x, int y, const char *utf8, uint32_t color) {
    while (*utf8) {
        uint32_t code = decode_utf8(&utf8);
        CjkGlyph *glyph = find_cjk_glyph(code);
        if (glyph) {
            draw_cjk_char(x, y, glyph, color);
            x += glyph->width + 1;
        } else {
            draw_placeholder(x, y, color);
            x += PLACEHOLDER_WIDTH;
        }
    }
}

The important point here is not the specific encoding scheme. It is that AI can help developers build an extensible Chinese rendering framework. If the input constraints are clear, AI can generate a complete flow from encoding parsing and font lookup to bitmap drawing and exception handling.

6. Key Work Completed Autonomously by AI

In this practice, AI was not simply filling in a few lines of code. It handled a considerable portion of engineering work. This mainly included:

1. Generating the project skeleton: Directory structure, entry function, and main loop framework.
2. Writing build scripts: Compilation, linking, and output format conversion.
3. Explaining compilation errors: Locating missing symbols, type errors, and linking issues based on error reports.
4. Completing interface definitions: Modules for graphics, input, collision detection, and text rendering.
5. Generating testing ideas: How to verify movement, collision, scoring, and pause functionality.
6. Refactoring code structure: Gradually splitting a single file into multiple modules.
7. Writing comments and documentation: Explaining the responsibilities of each module and key interfaces.
8. Providing optimization suggestions: Refresh mechanisms, collision precision, and state machine design.

However, AI is not unconditionally reliable. It may generate nonexistent interfaces, assume incorrect memory layouts, or ignore special constraints of the target environment. Therefore, developers must retain review authority, especially for the following areas:

• Boot entry and load format.
• Video memory or framebuffer access methods.
• Input event sources.
• Character encoding and font resources.
• Build artifact copying and runtime paths.

In other words, AI is suitable for generating a large number of candidate solutions, but final selection, verification, and integration still require developer control.

7. Cost and Retrospective: Time, Expense, and Output

7.1 Time Cost

AI-assisted low-level development can significantly shorten early setup time, especially for environment configuration, template code, error explanation, and basic logic writing. However, it also introduces new time costs:

1. Context organization cost: Developers need to explain goals, constraints, and feedback to AI.
2. Verification cost: Code generated by AI must be actually compiled and run.
3. Error correction cost: Ambiguous or incorrect outputs require re-prompting.
4. Integration cost: Different code fragments must be combined into a complete project.

Overall, if the task goal is clear and feedback is timely, AI can reduce the time spent writing code from scratch. However, if requirements are vague, the environment is complex, or error messages are insufficient, AI may increase communication overhead.

7.2 Economic Cost

Using AI-assisted development usually consumes a certain amount of quota or incurs fees. The cost depends on model capability, context length, interaction frequency, and task complexity. Low-level development often involves substantial context. A single conversation may include large error logs, code snippets, and build output, so the cost is not necessarily low.

Methods to control cost include:

1. Breaking large tasks into small tasks.
2. Providing only one clearly defined problem at a time.
3. Keeping stable context and reducing repeated explanations.
4. Summarizing error logs instead of pasting all content.
5. Organizing reusable prompts.
6. Avoiding long, aimless exploration.

From an engineering perspective, AI tools are more like development resources. They need to be managed similarly to compute resources, test environments, or storage resources.

7.3 Output Summary

In this case, AI-assisted output could include:

• Build scripts.
• Graphics initialization module.
• Input-reading module.
• Collision detection module.
• Main loop framework.
• Text rendering module.
• Chinese bitmap display module.
• State machine and game logic.
• Basic testing notes.
• Error-fix records.

These outputs were not all generated at once. They were gradually improved through multiple iterations. The real value was not the final number of lines of code, but whether the development process was significantly optimized.

8. Boundaries of Low-Level AI Programming

This practice allows us to summarize the applicable boundaries of AI in low-level development.

8.1 Areas Where AI Performs Well

1. Templated code generation: Build scripts, interface declarations, state machines, and basic loops.
2. Error explanation: Turning obscure compilation errors into actionable fix suggestions.
3. Multiple solution comparisons: Providing candidate code for different implementation paths.
4. Code completion and refactoring: Module splitting, naming optimization, and comment generation.
5. Test assistance: Generating simple test cases and verification steps.
6. Knowledge supplementation: Helping developers understand low-level concepts, although conclusions still require verification.

8.2 Areas Where AI Performs Poorly

1. Implicit hardware constraints: Some platforms have undocumented limitations that AI cannot automatically know.
2. Real runtime feedback: AI cannot directly perceive physical phenomena such as screens, key presses, timing, or noise.
3. Resource correctness: Bitmap fonts, configuration tables, and binary resources cannot be guaranteed correct by natural language alone.
4. System-level security: Boot chains, permission boundaries, and access protection require strict review.
5. Complex compatibility issues: Differences between hardware and firmware versions may exceed AI’s context capability.

Therefore, AI is better suited as an “advanced assistant” and “code generator” rather than a fully autonomous low-level engineer.

9. Reusable Methods for AI-Assisted Low-Level Development

Based on the above practice, a fairly general method can be summarized.

9.1 Build the Minimal Closed Loop First

Do not ask AI to generate a complete system at once. First complete the minimal closed loop: initialization, display, input, and exit. The shorter the loop, the easier it is to locate errors.

9.2 Provide Interface Contracts

Developers should clearly define interface contracts between modules, such as:

• What value the input function returns.
• Where the screen coordinate origin is located.
• What the color format is.
• What character encoding is used.
• What format the build artifact requires.

The clearer the interface contract, the more stable AI’s output becomes.

9.3 Solve Only One Problem at a Time

Low-level problems are often interconnected. To prevent AI from jumping between multiple errors, focus on one problem at a time. For example: first fix compilation errors, then fix the black screen; first solve input, then solve collision; first solve English characters, then solve Chinese display.

9.4 Build a Local Knowledge Base

For fixed platforms or internal specifications, common interfaces, error codes, encoding tables, and build rules can be organized into a knowledge base for AI reference. This reduces repeated explanations and lowers hallucination.

9.5 Drive Iteration with Real Results

After AI generates code, the code must be actually compiled, run, and observed. Developers should feed real results back to AI instead of judging only from the surface of the code. For example:

• If compilation fails, return the error log.
• If the screen is black, return the initialization steps and known limitations.
• If output is garbled, return the character encoding and font structure.
• If the image stutters, return the refresh method and loop duration.

9.6 Manually Review Critical Paths

Parts such as boot entry, memory access, low-level input, and resource loading must be reviewed manually. AI can provide suggestions, but it cannot replace final responsibility.

10. Conclusion: AI Changes the Development Paradigm

This practice shows that AI-assisted programming is not simply turning “humans writing code” into “machines writing code.” It changes the way low-level development is carried out. In the past, developers focused mainly on line-by-line implementation and manual debugging. Increasingly, work can be transformed into requirement description, context organization, verification design, and result review.

In low-level system development, the value of AI is mainly reflected in:

1. Lowering the barrier to environment setup.
2. Accelerating template code generation.
3. Improving error-understanding efficiency.
4. Shortening the path from idea to prototype.
5. Helping developers build a more complete engineering structure.

However, AI does not eliminate the need for low-level development expertise. Instead, it raises requirements for developers: they must state goals more clearly, describe constraints more accurately, verify results more strictly, and organize knowledge more systematically. Truly efficient AI-assisted development does not depend on the performance of a single tool. It depends on building an engineering method with “clear specifications, sufficient context, closed-loop feedback, and continuous verification.”

For developers who want to try AI-assisted low-level programming, it is recommended to start with a small runnable project, such as character display, simple animation, input response, or basic collision detection. Do not pursue complex systems at the beginning. Instead, observe AI’s capability boundaries through small-step iteration. As long as task decomposition is reasonable, feedback is timely, and verification is sufficient, AI can become an effective productivity tool in low-level development.