Takeaway: treat provider choice as a runtime detail, not an architectural one. Everything you build on top of one model's behaviour is technical debt with a release date attached.

I run production AI on versioned prompts with dual-provider fallback, and I have swapped the model underneath a live system more than once. What breaks is never the API call. It is everything that quietly encoded one model's habits: prompts tuned to a particular refusal style, parsing built around one family's formatting, evaluation baselines that reset the moment you switch, and agent instructions that were only ever load-bearing because a specific model happened to follow them.

This session covers the layer I built to keep provider choice swappable, what it costs in abstraction overhead, and the places I deliberately left things coupled because portability was not worth the price. I will show a real migration, including the failure that made me build the layer in the first place.

Built and maintained by a non-engineer running two production products, which is the constraint that forced the structure rather than a footnote to it.