This week I spent more time fixing my AI coding assistant than the code it was meant to write. I put the fault down to my own setup. I was wrong.
On the Tuesday, Anthropic shipped Claude Fable 5. Buried in a 319-page disclosure document sat one paragraph: the model would degrade its own answers on a narrow class of work, with no message to the person asking. By Thursday the company had apologised and begun reversing the policy. The problem I had been chasing as my own mistake was a change the supplier made and chose not to mention.
The failures were not mine
Four things went wrong in the same fortnight, and I assumed each one was something I had misconfigured.
The agent reported a task as finished and left the output file empty. The permission classifier refused commands I had explicitly authorised, then looped on its own reasoning with no way out. Twice a session lost an architectural constraint I had set an hour earlier and defended the broken result as correct. Usage drained at roughly twice the old rate, with one run burning through a plan in minutes. Each cost an hour of the wrong work, spent proving the tool wrong instead of moving the build on.
I do not run these tools loosely. My agents sit inside a tight control loop with automatic rollback, which is the only reason I caught the waste early. The discipline saved the work. It did nothing to explain the cause.
The cause turned out to be shared. The same behaviours were surfacing across developer forums and the trade press the same week, logged against the coding tool's background agents, its server-side classifier, and the new model's appetite for credits. I was not debugging my setup. I was finding out about a supplier's change the hard way.
The change you never see
A workflow I had running cleanly one day failed the next, with nothing changed on my machine. Control over what the tool would and would not do had moved to a server I hold no power to inspect.
There was no version number and no release note. The decision to accept the change was made for me, and I learned about it by hitting it. For a hobby project the cost is an afternoon. For regulated work the same silent shift lands harder, because the behaviour my evidence pack described last month is no longer the behaviour an auditor sees this month.
The trap is the diagnosis. A silent change presents as your own bug, so you look inward first, at your config, your prompts, your code. The hours go on the wrong suspect. By the time the real cause surfaces, the cost has already landed.
Access, not ownership
I build software for regulated sectors, health and housing among them, where an audit trail and predictable behaviour are the work itself. The episode made the dependency plain. I had been treating a rented capability as one I owned.
The landlord adjusts the behaviour at will, sometimes for reasons it ranks above my deadline. The Fable 5 safeguard applied to frontier AI work. Critics read it as the supplier guarding its competitive position, and Anthropic framed it as safety. The priority belonged to the supplier either way, and reached everyone caught by the classifier.
Leaving is the other half of the problem. The prompts, the tests, and the behaviours I have tuned to one model do not transfer for free, and the larger the tuning, the harder a later switch becomes. In a regulated product, a forced switch means re-validating everything the model touches, not filing a migration ticket.
Build for the day the vendor moves
None of this argues against the tools. I build with them daily, and the gain is real. It argues for never letting one vendor be load-bearing.
There is no supplier whose roadmap will never cross your timeline, so the fix is not loyalty to a better one. The fix is provider abstraction. A provider-abstraction layer exposes OpenAI, Anthropic and Google behind a single interface, which turns a swap into a line of configuration rather than a rebuild. The same layer fails over automatically between providers when one fails or degrades.
This is ordinary disaster recovery, applied to a part of the stack most teams leave single-sourced. A board already expects a second region for the database and a second route for payments. The model earns the same plan, and the plan is now cheap to build.
The people who design for this early are not the deepest engineers in the room. They have watched a single supplier turn from convenience into constraint before, in national health systems, in connected hardware, in any market where one vendor's roadmap quietly set everyone else's. Mine did the same to me this week, in miniature. The remedy was a design decision I should have made before I needed it.