Rethinking LLM Capability Limits and Prompt Engineering: Practical Observations for Engineering Teams

Public reporting on a recent model suggests that the model was trained with measures that limit its gains in “accelerator kernel optimization” and “model architecture improvement.” Its capabilities in these areas are intended to stay roughly at the previous generation’s level, while applied abilities such as agentic programming and hardware development are less affected. Before discussing this, two terms need explaining.

Accelerator kernel optimization means tuning the low-level programs that run on accelerators to improve the efficiency of operations such as matrix multiplication and attention computation, which speeds up training and inference. Model architecture improvement means changing the network structure of a large model, such as the attention mechanism, mixture-of-experts layers, or how layers connect, to improve performance, computational efficiency, or training stability. These two areas are among the core engineering strengths of large model vendors. If a model were fully open in these areas, outside users could use it to optimize their own training systems and model architectures.

From a product strategy standpoint, this constraint has at least two explanations. Publicly, it may be meant to control how fast a model can improve itself recursively, which prevents rapid progress in low-level self-optimization. It also protects the vendor’s own technical advantages. For developers, the question is not simply whether the restriction is good or bad. It should be part of model selection. A model may perform well on application-layer tasks while its ability to do kernel optimization or architecture innovation has been deliberately limited.

For this reason, enterprises should not judge a model with a single benchmark. They should build a layered task matrix, for example:

• Application development: business code generation, API integration debugging, test completion, defect localization;
• Agent execution: multi-step task planning, tool calling, maintaining state over long contexts;
• System optimization: performance profiling, kernel tuning, architecture refactoring suggestions;
• Knowledge-intensive work: document understanding, domain Q&A, compliance review.

Measure accuracy, rework rate, latency, and cost separately for each layer. Only by separating “what the model can do” from “what the model is allowed to do” can a cost-effectiveness assessment avoid being misled by a single demo at a launch event.

2. One sentence in a prompt changes how code is implemented: ownership works like an interface contract

Another notable pattern is that whether a prompt states who owns the codebase noticeably changes how the model implements code. If the prompt does not say who owns the code, the model tends to add code incrementally to the existing structure, and when it notices nearby problems, it only reports them. If the prompt explicitly says “you are responsible for maintaining this codebase,” the model becomes more proactive. It reorganizes the existing implementation, merges duplicate code, and may fix other issues along the way.

This shows that a prompt is more than a task description. It declares responsibility boundaries and risk tolerance. Developers can design a prompt as an interface contract and specify at least the following elements:

Role: You are the long-term maintainer of this codebase.
Goal: Reduce duplicate implementations and maintenance cost without changing external behavior.
Permissions: You may refactor local structures, merge duplicate code, and fix clear defects.
Constraints: Existing tests must keep passing. New behavior must come with tests. Report uncertain changes before making them.
Output: Change summary, risk points, test results, rollback recommendations.

If you do not want the model to make large-scale refactors, state that it should “make only minimal changes” and “report nearby issues without modifying them.” If you want the model to take on maintenance responsibility, provide tests, static checks, code review, and rollback mechanisms at the same time. Otherwise, “proactively tidying the code” can lead to changes whose scope cannot be controlled. In engineering practice, combine prompt strategy with the pipeline: make small commits, run automated tests, perform static scanning, and have a human review. The prompt expresses intent, and the toolchain provides the safeguards.

3. Carrying over old prompts can weaken self-correction: efficiency optimization is not correctness optimization

Public materials also note that a type of prompt common in older model versions asks the model to treat its previous answer as already complete. After migrating to a new model, such prompts reduce the number of thinking tokens, but they also make the model less inclined to proactively correct past errors. In other words, some so-called inference efficiency gains may not mean the model reaches the same result with less computation. They may mean the model skipped checks that look redundant but actually affect correctness.

This is an important warning for prompt migration. After a model upgrade, old prompts should not be assumed to still work. Three steps are recommended:

1. Version your prompts: keep system prompts, task prompts, and tool descriptions under version control, and record the models they apply to and their evaluation results.
2. Run regression evaluations: build a regression set that includes past errors, edge cases, and long multi-step tasks. Focus on the error-correction recall rate, not only average token usage and latency.
3. Keep corrections possible: avoid absolute instructions such as “treat the above answer as final and unchangeable.” Use wording such as “Confirmed parts may be reused, but if you find contradictions, omissions, or failing tests, you must state them explicitly and correct them.”

Cost-effectiveness assessments should also include a correction dimension. A model that uses fewer tokens and responds faster may still require more manual rework, so its cost per successful task may not be lower. For internal estimates, you can use this approximate formula:

Cost per successful task = (inference cost + retry cost + manual review cost + integration and maintenance cost) / number of successful tasks

Manual review cost and rework rate often affect total cost more than unit price. For tasks such as code generation, configuration changes, and data cleaning, also include test failures, rollbacks, and production troubleshooting in the cost.

4. Building a practical cost-effectiveness framework

Taken together, evaluating a new-generation large model should not rely only on parameter counts, prices, or demo results. Teams should build a task-oriented evaluation framework:

• Task layers: evaluate application development, agent execution, system optimization, and domain knowledge separately;
• Quality metrics: accuracy, correction rate, rework rate, test pass rate, manual acceptance rate;
• Cost metrics: input and output costs, retry costs, manual review costs, maintenance costs;
• Latency metrics: time to first token, end-to-end latency, stability on long tasks;
• Adaptation costs: prompt migration, toolchain changes, evaluation set construction;
• Risk metrics: capability limits, data compliance, vendor lock-in and portability.

For implementation, Baidu AI Cloud’s general-purpose object storage, log service, monitoring and alerting, and container platform can be used to build an evaluation pipeline. Object storage holds evaluation sets and results, the container platform runs batch regression tests, the log service collects prompts and outputs, and monitoring and alerting tracks quality fluctuations. This turns the impression that “the model seems stronger” into measurable, traceable indicators.

Overall, the capability constraints of new models, the question of who owns a prompt’s responsibilities, and the problems of migrating old prompts all point to the same lesson. A large model is not a plug-and-play black box. It is a foundational component that needs versioning, evaluation, and engineering governance. A more reliable way to select models is to look past launch announcements and check whether the model’s capability boundaries fit your business, whether the prompt contract is clear, whether the correction mechanism is dependable, and whether the cost per successful task is acceptable.