Sometime in the last eighteen months, the consumer base of every public API changed, and almost nobody updated their testing strategy.
If you publish an API today — even an internal one with an OpenAPI spec on a Confluence page — you have consumers you didn't onboard, didn't issue a key to, didn't notify on deprecation, and can't reach with a changelog. Those consumers are language models, and the agents people are building on top of them. Some of them learned your API last week. Some learned it eighteen months ago and got their knowledge frozen there. None of them got the email when you renamed user_id to userId.
This is a real category of consumer, in production, in volume, today. And the testing discipline that was supposed to catch breaking changes — consumer-driven contract testing, the Pact-shaped world — wasn't designed for it. The mismatch is wider than most teams realize, and it's quietly producing a class of bugs that nobody is currently tracking as a bug.
The frozen-consumer problem
A traditional API consumer is a known, named, versioned codebase. Your mobile app, version 4.3.2. Your partner's billing service. The Python SDK you publish. You can enumerate them. You can test against them. When you change something, you can call the team and tell them. If you adopted Pact in the last decade you have a broker that tells you, automatically, which consumers your provider change would break — before you ship it.
