LLM-Assisted Programming in Practice: From Legacy Bug Fixing to Frontend Delivery

In an era where engineering productivity is a constant topic, LLM-assisted programming has moved from the “toy” stage to the “tool” stage, where it can intervene deeply in production environments. Recently, while maintaining a self-built content distribution system, I went through a complete problem localization and repair process led by a general-purpose LLM coding assistant. From entering the instruction to reproducing the defect, modifying the code, and finally passing verification, the whole process took about nine minutes. During this period, as the developer, I did not write a single line of business code. Setting aside macro technology trends, this article strictly takes an engineering practice perspective to break down the key steps, cost accounting, and capability boundaries of large models in real projects.

1. Problem Background and Initial Diagnosis: Why Was This a “Stubborn” Defect?

The long-shelved defect had a very subtle manifestation: after a content distribution task was triggered in the frontend interface, the system occasionally pushed duplicates, with no fixed reproduction pattern. In previous troubleshooting attempts, models could only offer generic suggestions such as “check whether the message queue is consuming repeatedly” or “consider adding a unique index at the database layer,” lacking any in-depth analysis tied to the project’s actual code structure.

For this type of problem, the core difficulties are that the reproduction environment is hard to construct and the call chain is too long. If you rely on manually reading logs to localize the issue, it usually takes several hours. For a large model, its advantage lies in having learned massive code patterns, but its disadvantage is the lack of awareness of runtime state. Therefore, the primary task of this test was to verify whether a large model could, without manual intervention, identify potential race conditions or cache consistency issues by analyzing code logic.

2. Test Phase One: The Complete Chain of Localization and Repair in Nine Minutes

This section does not discuss the pros and cons of specific model brands; it only reviews the debugging process using “an intelligent coding tool.” The whole process was split into three core steps, and the instruction design at each step determined the final efficiency.

1. Efficient Human-Machine Interaction: Prompt Design from “Describing Symptoms” to “Giving a Troubleshooting Path”

The core of the first minute was how to ask the question. Simply entering “help me look at the duplicate push bug” is not enough, because the model lacks context. I adopted “structured guided questioning,” breaking the problem description into: scenario (trigger timing), expected behavior (single push), actual behavior (occasional duplicates), and tech stack (PHP + Redis queue). At the same time, I asked the model to first output a “code walkthrough plan” rather than directly giving modification suggestions. This strategy greatly reduced the model’s misjudgment rate and allowed it to focus on the conflict between the locking logic of task scheduling and the database transaction isolation level.

2. Code-Level Patch Generation: Not Just Finding Problems, but Providing Actionable Changes

After the model output initial suspicious points, I did not stop there. I further asked: “Please provide a specific fix patch for this race condition and ensure it does not affect other callers.” Within seconds, the model output a defensive code snippet based on a Redis atomic lock. Unlike manual handwriting, this patch handled compatibility with the system’s original low-version PHP syntax and automatically added a mechanism to release the lock on exceptions. This avoided the previous dilemma where “the model understands the code, but the code it writes cannot run under the current old framework.”

3. Verification and Regression: Replacing Costly Environment Setup with Static Analysis

After the fix was completed, the tool also automatically generated a set of unit test skeletons for this boundary condition. I directly integrated them into the local CI script, successfully reproduced the failing case before the fix, and confirmed that it passed after the fix. The nine minutes were roughly allocated as follows: the first minute for guidance, the middle seven minutes waiting for code walkthrough and patch generation, and the last minute executing tests.

3. In-Depth Cost Breakdown: API Call Strategy Under a Low Budget

This practice was not only about technical implementation; strict cost accounting was also necessary, which is crucial for engineering rollout. Assume the project’s codebase is around 270,000 lines; we use this to estimate large model call consumption under a strict budget.

1. Context Management: Avoid “Money-Burning” Curiosity

When calling a large model, the behavior most likely to generate high costs is indiscriminately uploading the entire project directory. The approach used here was precise retrieval: uploading only the three core files related to task scheduling (about 2,000 lines of code), supplemented by a text description of the database table structure. Under the billing models of current mainstream general-purpose large models, the cost of conversation turns is far lower than the input cost consumed by tokens.

2. Estimation Model: Feasibility Under a $17,000/Year Budget

If we consider an annual R&D tooling budget of $17,000 (this budget includes API call fees and some resource occupation in the gray environment), we calculate based on about 5,000 effective code interaction requests per month. Because most requests have short contexts (below 4K tokens), the overall cost remains at a very low level. The key is to position the large model as a “senior code consultant” rather than an “automatic coding machine”, calling it only at complex logic points rather than annotating line by line, which can reduce costs to about 30% of the original.

4. Chain Extension: Engineering Expansion from Defect Repair to Frontend Landing Pages

After solving the backend defect, I also tried using the same tool for frontend page development. It should be emphasized here that generating static pages is not the difficult part for a large model; the difficult part is making it follow the project’s existing UI design system.

1. Constraint Transfer of the Design System and Component Library

I did not ask the model to “freely create”; instead, I directly input the calling methods of the existing component library and the CSS variable definitions. In the new landing page it generated, the model accurately reused the existing button styles and spacing specifications, and the output DOM structure fully met the project’s code specification requirements, eliminating the style disorder problems that had appeared many times before. This shows that large models perform far better in “constrained creation” than in “open-ended creation.”

2. Engineering Integration and Implementation of Interaction Logic

For the landing page’s form submission logic, the model generated an asynchronous processing function that conforms to the framework specification, including loading state and error fallback logic. The generated code is based on the new business module and is isolated from the old global variables, ensuring that new and old functions in the same page template do not cause global pollution.

5. Deep Reflection: The Boundaries of AI Programming and the Reshaping of Developer Value

Although this test was highly efficient, as practitioners we still need to remain clear-headed.

• The capability boundary lies in “system-level understanding”: The model can solve bugs within a specific function, but for distributed failures involving microservice link tracing, without clear data instrumentation input, it will still give idealized answers.
• Code review remains the safety bottom line: Although the model-generated patch added a lock, the lock granularity and its performance impact still require manual review. AI shortens the “hand labor” time of coding but increases the cognitive burden of “brain review.”
• Considerations of privatization and data security: When sending code snippets to a large model for analysis, enterprise information security specifications must be strictly followed. The safest approach is to deploy a lightweight desensitization tool locally and replace variable names in core logic before transmission.

6. Summary and Recommendations

From this test in a real project, we can conclude that LLM-assisted programming has truly entered the productivity stage. It is no longer just a search engine providing “code snippets,” but a junior R&D collaborator capable of completing the “locate-modify-test” loop.

For teams that have not yet introduced AI programming at scale, my recommendation is to start from “specific targets.” Do not try to build an entire system in one conversation; instead, pick legacy modules with heavy historical debt and complex logic, and use large models for “code walkthroughs.” At the same time, be sure to establish a unified prompt template library within the team to accumulate effective questioning methods. As this practice shows, when debugging conversations can precisely control costs and outputs strictly conform to existing framework specifications, large models truly become amplifiers of R&D efficiency rather than replacements.