Production is already becoming multi-model

The interwebs are busy arguing about which AI is going to win. I keep thinking about where all the code goes.

One developer uses OpenAI. Another uses Anthropic. Someone else prefers Google. Put those developers on the same project and their changes can end up in the same repository, behind the same release, serving the same customer.

That was the observation behind my original post. It is not a census of enterprise adoption. It is a very ordinary consequence of allowing people to use different coding tools.

Production inherits the output. Somebody still owns the whole thing.

Multi-model development is not a multi-model runtime

These two conversations get mixed together.

Multi-model development means different models participate in producing the software: proposing a change, writing tests, reviewing a diff, or helping with an investigation. The deployed application might make no model calls at all.

A multi-model runtime means the application itself calls more than one model in operation. Now routing, fallback behavior, evaluation, latency, provider availability, and inference cost are part of the live system.

You can have either without the other. You can also have both.

If three models helped write your checkout integration, the integration does not need a model router. It needs correct checkout behavior, maintainable code, and a delivery process that can detect a bad change. Buying runtime orchestration to solve an authorship problem would be quite a detour.

The approved-tool list only covers part of the risk

An approved-tool list matters. So do data handling, retention terms, access controls, licensing, and the permissions given to an agent. A clean diff does not make it acceptable to send customer data to an unauthorized service.

But selecting a vendor does not establish that its output belongs in your system.

An approved assistant can still duplicate an existing capability, bypass a business rule, expose a secret, or write a test that confirms the wrong behavior. Permission to use the tool and permission to merge its work are separate decisions.

The controls need to cover the whole path:

• Before generation: which context can leave the environment, and which systems can the tool access?
• Before merge: what changed, what evidence supports it, and who is accountable for reviewing it?
• Before deployment: which environment can be changed, under whose authority, and with what recovery plan?

Those are specific enforcement points. “We use the enterprise version” does not answer all three.

Give every contributor the same system context

A model can produce a reasonable local answer and still make the system worse.

Consider a hypothetical pricing change. One assistant sees the product page and creates a rounding helper. Another sees the cart and creates a slightly different helper. Both pass tests written against their own assumptions. The integration failure appears when the customer moves between those surfaces.

Switching both developers to the same model would not establish which pricing rule was authoritative. The missing context would still be missing.

Put the durable knowledge where contributors can retrieve it: repository instructions, business contracts, architecture decisions, examples, and tests around the rules that matter. Explain the odd constraint that looks unnecessary until someone learns why it exists.

For AI-assisted code review, system context is part of the review input. A diff alone cannot reveal every dependency or operating consequence.

That context has to survive the next model, the next developer, and the end of a very long chat.

Make repository controls real

The repository is a useful place to enforce common standards because different tools eventually produce the same kind of artifact: a proposed change.

For example, GitHub’s protected-branch controls can require reviews and status checks before merge. Their settings also determine who can bypass restrictions. The important work is choosing checks that test your system and making sure the route around them is intentional.

A green check that only proves the generated code agrees with its generated test is weak evidence. For consequential changes, test against an independently specified outcome: the known promotion rule, an existing contract, a failure case, or a real regression.

Record the task, relevant context, diff, test results, reviewer, and deployment reference. Retain tool and model details where they help investigate behavior or meet policy. Do not turn traceability into an excuse to store private prompts and sensitive data forever.

Measure the work that remains

I have preferences about these tools. Strong ones. I still do not want the delivery method trapped inside a relationship with one model.

Compare tools on representative work: a small bug fix, a cross-cutting change, an unfamiliar integration, a failed test that needs diagnosis. Look at review effort, rework, escaped defects, intervention, elapsed time, and cost. Faster first output can still mean a slower accepted change.

That is why I keep coming back to where the bottleneck moves when AI writes the code. Generating the change and owning the result are different amounts of work.

Pick the tools that earn their place. Keep the system knowledge and release authority somewhere the company can actually own them.

The customer is not buying your model preference.