Large Language Models and Contract-Oriented Programming: A Practical Engineering Strategy

1. The Overlooked Prerequisite: Target Users and Compliance Boundaries

Before discussing any model selection criteria, we must clarify a premise often ignored by the technical community: who are you actually writing code for?

If your project is delivered to government entities or heavily regulated enterprises, the primary constraint for technology selection is not benchmark performance, but compliance. Such projects often explicitly prohibit the use of foreign large models and their accompanying intelligent programming toolchains, regardless of how well they perform in public evaluations. This means that many “god-tier tools” enthusiastically discussed in the open-source community are simply not an option in actual delivery scenarios.

Therefore, evaluating whether a model is capable enough must first consider whether it falls within the compliance track. Discussing capability comparisons detached from this premise offers limited practical value to frontline developers.

2. Fundamental Differences in Parameter Scale: Instruction Execution vs. Intent Understanding

When a project enters the actual coding phase, you will find that the work involves much more than just “getting the model to do the work.” The more critical aspect is: making the model understand your purpose.

There is a clear dividing line here:

• Small parameter models: Excel at executing explicit, closed, and well-defined instructions. Their behavior pattern is close to “literal translation”—they do exactly what you say.
• Large parameter models: Can infer “what you truly want” by combining context, project structure, and historical code style, even if your description contains some ambiguity.

This is not simply a matter of being “smart” versus “dumb,” but rather a difference in prompt fault tolerance.

Typical Dilemmas of Small Parameter Models

Small parameter models do not necessarily fail to understand the task; rather, you must write the prompt to an extremely detailed level: boundary conditions, exception branches, lock granularity, and transaction scopes must all be listed clearly. Once the instructions leave any ambiguity, the model will implement it in the most literal and conservative way—which often deviates from your true design intent.

The Advantage Zone of Large Parameter Models

Large parameter models tend to make reasonable inferences based on context. Even if their benchmark scores are close to those of small models, in actual programming experiences, large models often “understand you” better. The trade-off, naturally, is a higher inference cost.

3. A Real-World Case: Design Intent Behind Lock Granularity Selection

Consider an enterprise-level data and archive management system scenario:

• Archives depend on data to exist.
• To ensure operational safety, exclusive locks must be introduced.
• The designer’s true intent is: lock the data primary key ID, so that archive operations directly enforce exclusivity. This simplifies code logic and avoids the concurrency risk of “another user deleting the entire data record while backend operations are running.”

However, if the prompt omits the phrase “lock the data primary key ID,” a small parameter model will likely default to locking the archive’s folder ID. Is this implementation useful? Yes. Can it pass tests? Yes. But it is not the solution the designer wanted:

• The lock granularity is too fine, leading to increased code complexity.
• It fails to cover the concurrency scenario where “the entire data record is deleted.”
• Subsequent maintainers need to grasp an unnecessary layer of indirection.

Small parameter models are good at “getting the work done,” but at the “being comprehensive” level, they easily leave hidden risks. Such scenarios are exactly where large parameter models demonstrate their value.

4. Contract Programming: The Core Demand of Formal Projects

A common misconception needs clarification here: emphasizing the intent-understanding capability of large parameter models does not contradict “wishing-style programming.”

• Wishing-style programming aims to: get things built and running, regardless of how.
• Formal projects aim to: require the model to follow various explicit or implicit contracts and advance along the programmer’s own design logic.

Sometimes, even if a theoretically superior solution exists, developers might choose a sub-optimal but more maintainable approach after evaluating performance trade-offs, for the sake of project readability and team collaboration consistency. Only a model capable of understanding “design intent” can cooperate in achieving this.

A Simple Verification Method

If you want to intuitively feel this difference, you can try:

1. Write a technical comment with a clear standpoint.
2. Ask models of different scales to evaluate this comment.

You will observe that:

• Small parameter models tend to miss the point, opting to smooth things over, compromise, or even argue.
• Large parameter models can better extract the core argument, judge whether it makes sense, explain the underlying principles, and identify the boundaries.

This capability gap is further amplified in scenarios like code reviews, architectural discussions, and contract derivations.

5. High-Low Pairing: A Pragmatic Engineering Strategy

Synthesizing the above analysis, under strict compliance constraints, a more pragmatic strategy is to adopt a high-low pairing:

Role	Model Type	Responsibilities
Lead Designer	Large parameter model	Understand intent, derive contracts, generate core logic, handle ambiguous requirements
Lead Executor	Small parameter model	Execute explicit instructions, batch generate boilerplate code, complete well-defined subtasks

The core logic of this pairing is:

• Use large parameter models to solve the “thinking clearly” problem.
• Use small parameter models to solve the “writing heavily” problem.
• Strike a balance between cost, compliance, and efficiency.

6. Code Example: Two Implementations of Lock Strategies

The following schematic code illustrates the difference between the two lock strategies:

# Strategy A: Lock the archive folder ID (default tendency of small models)
def update_archive(archive_id, data):
    folder_id = get_folder_id(archive_id)
    with acquire_lock(f"folder:{folder_id}"):
        # Only protects the folder level
        do_update(archive_id, data)
# Strategy B: Lock the data primary key ID (designer's true intent)
def update_archive(archive_id, data):
    data_id = get_data_id(archive_id)
    with acquire_lock(f"data:{data_id}"):
        # Protects the entire data record, avoiding concurrent deletion
        do_update(archive_id, data)

Strategy B has a coarser lock granularity, but its logic is simpler and it covers the concurrency scenario of “the entire data record being deleted.” This choice requires the model to understand the trade-off between “operational safety” and “code readability” rather than mechanically executing literal instructions.

7. Conclusion

Evaluating a model’s capability should not rely solely on benchmark scores; it must return to real engineering scenarios:

• Is it within the allowed compliance boundaries?
• Can it understand the design intent behind ambiguous requirements?
• Can it adhere to project contracts rather than just aiming to “make it run”?

Under the strong constraints of compliance-heavy projects, using large parameter models for intent understanding and contract derivation, and small parameter models for efficient execution, is currently a pragmatic and sustainable engineering path. Model selection is never an either-or choice, but rather about placing the right model in the right position based on task boundaries.