Pin the model like a dependency

A while back one of my agents started handing me slightly different work, and there was nothing in the git log to explain it. Same spec, same prompt, same repo. The builder role just drifted. Cleaner in a couple of places, lazier in a couple of others. I lost half a morning hunting for the commit that changed the behavior before I accepted there wasn't one. The model version behind that role had moved upstream, quietly, and my build was riding whatever the tool decided to serve that day.

I thought about that morning again this week, when one of the most widely used AI coding tools got bought by a company that runs its own model lab. The loudest thread in every discussion was a version of the same worry: now that the tool has a parent with a stake in the model race, which model does it favor by default, and when does that switch happen. That worry only has teeth if your build treats the default model as a given. And if you've shipped production software before, you already know the move, because it's the same one you use for every other dependency you don't control.

the floating dependency you didn't know you had

The model is a dependency. In vibe coding it's the most behavior-shaping dependency in the whole stack, because the model does most of the heavy lifting, and that leverage is the entire appeal. It's also why leaving it unpinned is the riskiest default in your AI orchestration. Most people never pin it anyway. They run on the ambient default, whatever the tool ships this week.

You'd never do that with code. You don't deploy production off latest. You pin a lockfile so the build is reproducible, so the thing you tested is the thing that ships, so a transitive bump three layers down can't change your app without a diff. An unpinned model is latest for the one dependency that decides how every other line gets written.

So when the default moves, and it moves for boring reasons all the time, a routine tool update, a quiet deprecation, or an ownership change like the one this week, your build changes with it. No diff. No commit. No review. A vibe coded feature that worked yesterday subtly doesn't today, and the worst part isn't the bug. It's that there's no line to blame, because the change never went through your repo at all.

pin it in the spec

The fix is spec-first discipline pointed at the model itself. Name the model and the version in the spec, as a declared dependency, the same way you pin a package. The model stops being an ambient default the tool chose for you and becomes an input you chose on purpose.

Once the version lives in the spec, a bump is a reviewed change. You move it deliberately, in a commit, and you can roll it back when the new version gets worse at the thing you actually needed it for. Reproducible means same spec, same version, same behavior, or a diff that tells you exactly why it's different. That's the whole game.

This is the unglamorous, durable version of the news. You don't have to predict which model a tool will prefer after an acquisition, or read the tea leaves on a lab's roadmap. You just have to stop letting the tool make that call silently on your behalf. Spec before default. The contract names the version; the tool doesn't get a quiet vote.

it's a team problem, not a tool problem

I run a standing team of role-based agents: an architect, a builder, a researcher, an adversarial reviewer, a cross-check. Each role is pinned to a model lineage on purpose, because the roles do different jobs and reward different strengths. Pinning the version per role is what keeps the team reproducible. The adversarial reviewer that caught a real problem last week catches it the same way this week, because it's the same reviewer, not whatever the tool happened to promote to default overnight.

This is the cousin of a rule I've written about before, don't couple your orchestration to any one lab. That one is about staying portable across vendors so no single lab can consolidate against you. Pinning is the other half. Portability protects you from the lab; pinning protects you from the silent bump inside whatever you're running this quarter. You want both, for the same reason you want a thin orchestration layer you can move: the methodology has to outlive the news cycle, and the news cycle moved to infrastructure a while ago.

the working rule

For any vibe coder wiring up agents right now, it compresses to this. Treat the model version like a dependency. Pin it in the spec, per role. Bump it on purpose, in a commit you can revert. Do that and an acquisition headline, a deprecation notice, a default that quietly slides forward, all collapse into the same small reviewed event instead of a mystery in your output a week later.

If you're running a fleet and you're tired of behavior that drifts with no diff, and you want a sparring partner on where to pin and how to review the bumps, work with VibeKoded.

The model is going to keep changing. Whether that change shows up as a line in your repo or a ghost in your build is the part you get to decide.