There's a quiet category of bug that has plagued teams shipping LLM-powered features since 2023: someone bumps the model name in a config file from claude-sonnet-4-5 to claude-sonnet-4-6, the diff is one line, the PR gets a thumbs-up, and a week later customer support is fielding tickets about output formats that no longer parse, tool calls that fire in a different order, or refusals on prompts that used to work fine. This post argues that the framing is wrong from the start — a model swap isn't a config tweak, it's a dependency upgrade with the blast radius of swapping out a database engine.

The piece likely walks through why teams keep making this mistake:

• The interface is identical. Same API endpoint, same SDK, same request shape. Nothing in the type system tells you the substrate underneath changed.
• The "improvement" framing. Vendors market upgrades as strict wins, which discourages the regression testing you'd apply to any other dependency.
• Eval coverage is usually thin. Most teams have unit tests for their wrapper code but no golden-output suite for the prompts themselves.

What makes this worth reading for a technical audience isn't the diagnosis — most senior engineers have been bitten by this — it's the implied prescription. If a model upgrade is a release, then it needs release infrastructure: pinned versions in production, a staging cohort, an eval suite that runs on the new model before any traffic shifts, a rollback plan, and a changelog of behavioral deltas you actually observed rather than what the vendor advertised. That's a meaningful operational shift from "let's just point at the latest" — and it has staffing and tooling implications most companies haven't budgeted for.

The broader point cuts against an industry instinct to treat foundation models as commodity utilities. They aren't. They're tightly coupled to your prompt-engineering, your tool schemas, your output parsers, and your users' learned expectations. Treating that coupling casually is how you ship outages.

Worth a read for anyone running LLM features in production — especially if your deployment story still involves an environment variable and a prayer.