After vibe coding: model routing makes AI coding governable

For many teams, the first cycle of AI coding was simple: open Claude Code, Cursor or Copilot, ask for more output and see what happens. Sometimes it worked immediately. More prototypes, more fixes, more branches, and less waiting between idea and demo.

The second cycle is less spectacular, but more important. If every task can use a different model, with different cost, latency, capability and policy, choosing “AI” is no longer enough. Teams have to decide which model to use, when, for which work and with which level of control.

On July 2, 2026, The Pragmatic Engineer published an analysis of smart model routing: routers that choose the right model for a task based on cost, quality or availability. It sounds like an infrastructure topic, but for people building products it is very practical. Once AI enters daily delivery, routing becomes part of the team’s operating system.

Cost is not only tokens

The first reading of model routing is economic. Some tasks do not need a frontier model. If the work is simple, repetitive or already well specified, a cheaper model can be enough. If the task touches architecture, data, security or product decisions, spending more can make sense.

That distinction is useful, but incomplete. The real cost is not only token price. It is review time, the risk of correcting wrong output, the noise created by a plausible solution, and the effort needed to understand why a model took a certain direction.

A router can reduce compute cost. It does not decide organizational cost on its own. If a team sends vague tasks to a cheaper model and then spends hours cleaning up the result, the saving is fake. If it always uses the strongest model for trivial changes, it may be buying psychological safety more than quality.

This is why routing belongs beside AI-assisted delivery and agent autonomy governance. The model choice is only one control. Task class, review depth, permissions and fallback decide whether the output can safely enter the product.

Routing needs a taxonomy of work

For model routing to work, teams need something unglamorous: a classification of work. It is not enough to say “bugfix”, “feature” or “refactor”. The team has to understand the kind of risk carried by the change.

An isolated visual fix can stay in a fast lane. A change to permissions, billing, compensation, authentication or sensitive data needs a different level of review. A spike can use different models because it does not enter production immediately. A migration or shared refactor needs clearer criteria because a model can produce a lot of plausible code while leaving distributed implications across the system.

This is where the technical PM and the engineering lead need to work together. Routing is not a purely infrastructural decision. It is a decision about how the team protects the product while increasing speed.

The model does not replace review

A natural temptation is to use routing to automate trust too: simple task, cheaper model, faster merge. The risk is confusing model choice with result quality.

A stronger model does not remove the need for review. A cheaper model does not make the task less risky. Review remains the point where the team decides whether the output can become product. What changes is what review needs to know: which model generated the output, what prompt or context it had, which constraints were explicit and whether any fallback was used.

If those elements stay invisible, routing becomes a black box. The team sees only a pull request and has to guess how much to trust it. That is the opposite of governance: more automation, less explainability.

What to decide before the router

Model routing will probably become normal inside AI coding tools. That makes sense: there are too many models, costs vary, performance changes and no team wants to choose manually every time.

But before the router, there is a simpler question: which tasks need close human control even when the model looks good enough?

That question does not slow the team down. It protects the team from a new kind of debt: output generated quickly, accepted too early, understood too late. The interesting part of AI coding is not only writing more code. It is building a system where the team still knows why that code was written, how risky it is and who decides whether it can enter the product.

Routing can help a lot. It works only if the team has already defined what it is trying to protect.