LLM Selection Strategy: From Task Execution to Intent Understanding

1. The Overlooked Premise: Compliance Boundaries Dictate Model Choice

In many technical discussions, developers tend to rely on AI model leaderboards as their primary selection metric. However, in enterprise and public sector projects, there is a hard constraint that is often emphasized but frequently ignored: strict compliance and data sovereignty regulations. In many jurisdictions, projects involving critical information infrastructure or government data are explicitly prohibited from using foreign models and their associated development toolchains. This means that no matter how well a closed-source international model performs in code generation or natural language understanding, it cannot be included in the delivery list for these projects.

Compliance requirements restrict model selection to domestically developed alternatives. Yet, “domestic” is not a monolith—models with different parameter scales and architectural designs perform vastly differently in real-world engineering scenarios than what benchmark scores suggest. Therefore, the first step in selection is not comparing scores, but defining the available pool of compliant models, and then finding the combination that best fits the project’s characteristics.

2. The Core Dilemma: Small Models Pass Tests but Miss Intent

When models are integrated into the project development workflow, the first major challenge developers face is: how to make the model understand your complete intent, rather than merely executing the written instructions.

Lightweight models (typically those with fewer than 10 billion parameters) perform stably on “explicit instruction” tasks such as code completion, unit test generation, and formatted output. They even outperform larger models in response speed and cost control. However, once a task involves implicit constraints, business context, or design trade-offs, they often expose a critical shortcoming: a lack of reasoning ability regarding “unstated premises.”

Consider a recent real-world example from an enterprise data and archive management system. The system involved two entity links: data master records and affiliated archives. Archive records depend on data rows. To ensure operational safety in concurrent scenarios, an exclusive lock mechanism was necessary. The core design concept was to lock the data primary key ID. During archive operations, the system would check the primary key lock status, thereby avoiding the race condition of “a background process deleting data while another user is operating on the archive” with the simplest possible logic.

During implementation, however, the lightweight model generated code that “locked the archive folder ID.” This code passed the tests—it functioned correctly in single-user, non-concurrent scenarios and even passed basic API test cases. The problem was that it deviated from the original design intent: a folder lock only prevents write operations on the archive directory; it does not prevent the master data row from being deleted. This meant that if two users operated concurrently—one deleting the master data record and the other editing the affiliated archive—unpredictable data anomalies would occur. Fixing this hidden defect often requires additional compensation transactions or secondary validation logic, inadvertently increasing system complexity rather than reducing it.

This case reveals an essential principle: small models excel at “execution” but lack the ability to “complete the contract.” When the prompt omits the constraint “lock the data primary key ID,” the model fills in the gap with a seemingly reasonable solution that does not align with the design intent. Conversely, a large-parameter model can use contextual clues such as business descriptions, class names, and variable naming conventions to infer that “the user actually wants exclusive control over the data primary key,” thereby generating code that closely matches the architectural design intent.

3. The Limits of “Wishful Programming”: Intent Alignment vs. “Optimal Solutions”

Some developers argue that the currently popular “wishful programming” (using natural language to describe requirements and leveraging AI to generate runnable code directly) inherently does not require the model to deeply understand the business; it only needs to produce functional code. This view has clear limitations in practice.

Wishful programming is suitable for the “zero-to-one” prototype validation phase, where the goal is to see a runnable result as quickly as possible. But in formal project delivery, code maintainability, team consistency, and contract adherence are far more important than “writing a solution that simply runs.” For example, a module might have a “more advanced” solution utilizing distributed locks and message queues. However, if the team’s current tech stack does not include message queue components, introducing them means additional infrastructure maintenance costs, operational monitoring overhead, and learning curve for the team.

After evaluating performance trade-offs and architectural consistency, experienced developers often opt for a more straightforward implementation. At this point, whether the model “understands the profession” is reflected in: whether it can understand “why the fancier solution should not be used,” and whether it can follow the team’s established contracts and styles, rather than obsessing over providing the theoretical optimal solution.

Large-parameter models have a distinct advantage here. They can perceive tech stack boundaries, historical code styles, and implicit design constraints from the project context, automatically adhering to these implicit contracts when generating code. Lightweight models, on the other hand, tend to “miss the forest for the trees”—they only see the inputs and outputs of the current function while ignoring the architectural context of the entire module.

4. Comment Comprehension: A Litmus Test for “Semantic Extraction”

There is also a very intuitive but often overlooked testing method: asking the model to evaluate a biased comment. Send a comment containing explicit viewpoints, implicit logic, and potential biases to models of different scales and observe their responses.

Lightweight models often tend to be fence-sitters. They will list both sides’ viewpoints, offer a middle-ground conclusion like “both have a point,” or fixate on a non-core detail for contrarian rebuttals. This happens because the attention mechanism of small-parameter models has limited coverage, making it difficult to track causal chains and implicit premises in long texts simultaneously.

Large-parameter models, however, demonstrate a stronger “key information extraction” capability. They can locate the core argument in a verbose comment, determine whether the evidence holds up, point out logical boundaries, and even add the prerequisites for which the argument applies and counterexamples where it does not. This capability is critical in scenarios like code reviews, requirements analysis, and document audits—because the essence of these tasks is not “generating content” but “judging content quality.”

5. Engineering Practice: A High-Low Hybrid Approach

Based on the analysis above, under the premise of compliance, a pragmatic engineering strategy is to adopt a hybrid approach combining “large-parameter models + lightweight models.”

During the project’s early architecture design, core module logic coding, and complex business rule definition phases, prioritize large-parameter models. The input at this stage is fuzzy, high-level business intent, requiring the model to have context-based inference and completion capabilities. Large models may have slightly slower response times and higher per-call costs, but compared to the time lost to rework and the cost of fixing hidden defects, this investment is worthwhile.

In the mid-to-late stages of the project—such as template code generation, unit test writing, simple CRUD API implementation, and format standardization—switch to lightweight models. These tasks have clear input and output definitions and do not rely on deep semantic understanding, allowing the high throughput and low-cost advantages of small models to be fully utilized.

This hybrid approach essentially matches “model capability” with “task complexity,” rather than uniformly choosing the “most expensive” or “fastest” option. In actual projects, this strategy can significantly reduce overall development costs while ensuring that delivery quality meets auditing and maintenance requirements.

6. Conclusion: Selection is Essentially About Evaluating “Intent Density”

Returning to the original question: within compliant model options, how should one choose to truly support the delivery quality of enterprise-grade projects?

The answer is neither “choose the one with the largest parameters” nor “choose the one with the highest benchmark score.” Instead, it is about evaluating how much “unstated intent” your task contains. If the task definition is extremely clear, boundary conditions are complete, and the context is unambiguous, a lightweight model is sufficient. But if the task involves architectural trade-offs, concurrency control, business rule reasoning, or implicit contract completion, the value of a large-parameter model is irreplaceable.

Under compliance constraints, building an engineering pipeline where “large models set the direction and small models ensure efficiency” is the pragmatic path forward.