AI coding is no longer limited by whether models can write code. They can. The harder question for CEOs and CTOs is how to spend scarce high-quality reasoning wisely.
A frontier model can write routine code, generate tests, summarize requirements, review an implementation, reason about architecture, and help plan a release. But just because it can do all of those things does not mean it should do all of them.
Mature engineering organizations do not use senior engineers for every routine implementation task. They reserve senior judgment for architecture, risk, ambiguity, integration, review, and escalation.
AI development needs the same discipline.
The industry is investing enormous effort into making models more capable. My research suggests we may be underinvesting in the systems that determine how those capabilities are applied.
Different models may prove better at different roles. The goal is no longer finding the single best model. The goal is finding the best source for each class of work.
The Harness Can Carry the Long-Range Load
This observation emerged from my LocalCoding research project, which explored whether lower-cost and local models could perform useful software-development work under structured supervision.
The most important result was not that smaller models became as capable as frontier models. They did not. The important result was that smaller and lower-cost models could successfully complete bounded implementation tasks when the surrounding system supplied the engineering discipline they lacked: clear task ownership, constrained scope, executable validation, review checkpoints, escalation paths, and final authority.
In other words, quality did not come solely from the model. It emerged from the combination of the model and the organizational structure surrounding it.
That finding led to a broader question.
If smaller models can perform useful bounded work inside a well-designed supervisory system, are we optimizing the wrong thing when we focus exclusively on model capability?
Perhaps the larger opportunity is not simply building more capable models. Perhaps it is building better systems around them.
Not all tokens have the same cost structure. A local model, a smaller hosted model, a mid-tier reasoning model, a frontier model, a specialized tool, and a human reviewer differ in cost, speed, latency, privacy, rate limits, reliability, and review burden.Treating them as interchangeable is bad architecture. Treating the most expensive model as the default worker is bad economics.
The opportunity is to build a harness that carries more of the long-range load: requirements, architecture, task history, validation results, review rules, escalation policy, coding standards, and organizational priorities.
Instead of asking one monolithic model to hold the entire development process in its context window, the organization can move much of that process into an explicit, inspectable control layer.
That comes with benefits beyond token efficiency.
The organization gains control over method. Requirements, architecture, validation, review standards, escalation rules, and release discipline become durable artifacts rather than temporary model behavior.
The process becomes more consistent across projects and teams because the same development method can be applied even when the underlying model changes.
Provider changes become less disruptive. If a model vendor changes pricing, rate limits, context behavior, or model quality, the organization is not forced to rebuild its development process from scratch.
When the development process lives inside a model, changing providers means changing process. When the process lives inside the harness, changing providers becomes a staffing decision.
The system becomes more auditable. Decisions, validations, failures, escalations, and reviews can be recorded as organizational artifacts instead of disappearing into a model interaction.
It also enables better routing. Different models may prove better at different roles: UI work, database changes, test generation, documentation, refactoring, review, or architectural reasoning. The harness can learn those strengths from real outcomes and assign work accordingly.
That does not eliminate the need for frontier reasoning. It makes frontier reasoning more valuable by reserving it for the work that actually requires it.
That changes the question.
Instead of asking:
“Which model should do our AI coding?”
Organizations may increasingly ask:
“Which source should do this task, under this validation policy, with this level of review, at this level of risk?”
In that architecture, the future of AI coding is not one model doing everything. It is a managed development system where smaller models handle bounded work, stronger models supervise by review, deterministic tools validate what can be validated, and humans retain final authority where judgment matters.
Next: What does the harness actually look like, and what responsibilities should it own?