Choosing Model Sizes for Multi-LLM Development: From Intent Understanding to Contract Design

1. The Starting Point: Model Selection Is Not Just About Leaderboards

In many real-world projects, leaderboard scores only reflect how a model performs on standard evaluation sets. They rarely reveal how the model behaves inside an enterprise system full of implicit constraints. This is especially true in regulated environments such as government, state-owned enterprises, finance, and energy, where external models often cannot be used directly due to compliance requirements. In these cases, engineering teams must choose from a limited set of available models and revisit a key question: does parameter size affect how well a model understands developer intent?

The answer is clearly yes.

Parameter size affects not only knowledge capacity and reasoning depth, but also how the model handles ambiguous instructions, multi-level constraints, and context-based inference. For developers, this means two models with similar leaderboard scores can feel completely different in real engineering work.

2. Small Models: Strong Executors, Weak Design Collaborators

Small-parameter models have improved significantly in recent years, particularly in code generation, text summarization, and structured extraction. They offer low inference cost and fast response times, making them suitable as high-frequency, lightweight execution units for well-defined tasks.

However, small models have a clear boundary: they are better at solving problems that have already been precisely specified.

Consider a data and archive management scenario in an enterprise system. The system needs to associate data records with archive folders, while ensuring safe concurrent operations through an exclusive lock mechanism. The developer did not explicitly state which level the lock should apply to—the data primary key or the archive folder. As a result, the small model defaulted to locking the archive folder.

This solution is not entirely wrong and may even pass basic functional tests. But in a real business context, it creates a hidden risk: while a background process is writing to a data record, another user could delete the entire record because the lock was not applied to the critical data primary key. In other words, without explicit boundary instructions, a small model struggles to infer the developer’s deeper design intent.

This illustrates a common pattern: small models are excellent executors but unreliable design collaborators. If the developer’s prompt is not precise enough and boundary conditions are not spelled out one by one, a small model may produce an implementation that runs but does not match the intended architecture.

3. Large Models: From Following Instructions to Understanding Intent

In contrast, large-parameter models tend to align more closely with the developer’s actual goals in complex contexts. They can synthesize multiple signals from the surrounding context—such as data model structure, business terminology, operational workflows, and conversation history—to infer the most reasonable design decision.

Using the same example, when the developer mentions that “archives are attached to data,” “operational safety is required,” and “deletion of the entire data record must be considered,” a large model is more likely to infer that the lock should be placed at the data primary key level rather than on the archive folder. The data record is the root node of the relationship, so locking the primary key prevents concurrent archive operations attached to that data, eliminating conflicts at the source.

This capability does not depend on a single high-quality prompt. It relies on the model’s ability to grasp the full context. Large models are better at filling in constraints that the developer did not explicitly state. This is critical in real projects because many business rules are not documented in requirement specifications. They are scattered across developer experience, system evolution history, and organizational conventions.

4. The Difference Between Real Development and “Wishful Programming”

One might ask: if large models can guess intent, how is that different from “wishful programming”?

“Wishful programming” typically means the developer describes only the desired outcome without caring about the implementation path, hoping the model happens to get it right. Real engineering collaboration with large models is the opposite: the developer describes a goal system with implicit constraints, and the model must find a balance among those constraints rather than improvise freely.

The key difference is that serious projects emphasize contracts.

Contracts may include coding standards, interface definitions, exception handling policies, concurrency control strategies, and log field conventions. Often, a more “optimized” solution exists, but developers choose a relatively conservative implementation for team readability, operational consistency, or backward compatibility. Large models are more likely to demonstrate “restrained intelligence” in these situations—understanding why the goal is not to pursue the optimal solution, but the most appropriate one.

Small models tend to deviate in these scenarios. They follow the logic of the task itself rather than the logic of the overall project. This can lead to code that is “cleverer but not aligned with team conventions,” or a design that responds literally to the prompt while ignoring the broader goal.

5. A Practical Collaboration Strategy: High-Low Pairing

In regulated project environments, relying entirely on a single model size is rarely optimal. A more realistic approach is to establish a “high-low pairing” collaboration system.

Specifically:

1. Use large models for design and boundary inference.
   This includes system architecture design, module decomposition, data modeling, complex business logic analysis, and exception path analysis. These tasks require synthesizing context, understanding implicit constraints, and making trade-offs among alternatives.

2. Use small models for deterministic execution tasks.
   For example, generating specific functions based on an already finalized design, completing test cases, generating interface documentation, or performing code style checks. These tasks have clear goals and boundaries, and small models handle them more efficiently.

3. Developers maintain the “contract context.”
   When communicating with large models, developers do not need to spell out every constraint, but they must ensure the context contains sufficient contract information—such as code style preferences, locking policies, and exception handling conventions. This allows the large model to infer and design within the correct framework.

4. Use small models to verify design outputs.
   After a large model produces a design, specific implementation details can be decomposed and assigned to small models. If small models frequently deviate from expectations during execution, it often indicates that the design-level contract is not clear enough, and the developer should supplement the context.

The core of this approach is not “which model is stronger,” but “which model is more appropriate in which scenario.”

6. Further Consideration: Dialogue Understanding Across Model Sizes

The difference between model sizes is also visible in general technical discussions, not just code generation.

For example, ask a model to review a comment about whether “overly abstract interface design is justified.” A small model tends to produce a balanced response: it acknowledges that excessive abstraction can increase maintenance costs, but also emphasizes the value of moderate abstraction, concluding with “it depends on the situation.” This answer appears comprehensive but usually fails to extract the core argument or identify its applicable boundaries.

A large model is more likely to first point out that the comment’s central claim is “abstraction should serve current real needs rather than hypothetical extensions,” then analyze the merit of this claim, its preconditions, counterexamples, and the challenges it may face at different project stages.

This difference is crucial in technical reviews, design discussions, and code walkthroughs. Teams need a collaborator who can clearly judge “whether this argument holds, and under what conditions,” not a peacemaker who avoids judgment.

7. Conclusion: Reassessing Model Capability Under Compliance Constraints

Regulated industries impose strict compliance requirements on model sources. Many teams cannot use external models by default and must build their development workflow within the available model ecosystem. In this context, the significance of “top of the leaderboard” diminishes. What really matters is how to combine the models you can actually use into the most reliable engineering capability.

Based on observations from real projects, several conclusions emerge:

• Small models execute well but struggle with design inference under ambiguous instructions.
• Large models have stronger intent recognition and constraint completion capabilities, making them suitable as the design collaboration layer.
• A stable engineering workflow requires developers to maintain clear contract context and let models of different sizes play their respective roles.
• In regulated projects, high-low pairing of large and small models is a pragmatic and reusable strategy.

Ultimately, the choice of model size must serve the project’s dual requirements: intent understanding capability and execution determinism. Understanding this is what enables better decisions in real engineering work.