An AI feature can look permanent right up until the provider removes the sign from the building.
GitHub Models reached that moment on July 30. GitHub had announced that the playground, model catalog, inference API, and bring-your-own-key endpoints would all be retired for existing customers, not just closed to new ones.
I did not find a more substantial AI or developer-tool development in the previous 24 hours, so I widened the window to seven days. The shutdown happened three days ago.
GitHub pointed developers toward Microsoft Foundry for model access or GitHub Copilot for AI workflows inside GitHub. That is a reasonable migration path. But the useful beginner lesson is bigger than which replacement you choose:
An outside AI service should power a feature. It should not become the shape of your entire app.
Yesterday I wrote about choosing an AI coding model by matching it to your bottleneck. This is the next architectural question. Even a sensible model or service choice can change, become more expensive, lose a feature, move to a different product, or disappear.
You do not need an enterprise architecture team to prepare for that. You need one replaceable seam.
GitHub's retirement notice was unusually concrete. After July 30, the GitHub Models interface and API would no longer be available, including BYOK. GitHub even ran brief service interruptions before retirement so developers could see what failure would look like.
That last detail matters. A brownout is not only an inconvenience. It is an architecture test.
If one AI endpoint fails and your whole app becomes unusable, the app probably knows too much about the endpoint. The same problem appears with payments, maps, email, analytics, storage, and authentication. AI services just make it easier to ignore because the first integration can be so fast. You install a package, paste a key, call a model from a screen, and celebrate when text appears.
Then the prototype becomes the product, and the shortcut becomes structural steel.
Vendor lock-in does not mean “using a vendor.” Every useful app depends on other people's software.
The problem begins when provider-specific details spread everywhere:
Now changing providers is not one integration task. It is an archaeological dig.
The opposite extreme is also a mistake. A beginner can spend two weeks building a grand multi-provider framework before proving that one user wants the feature. That is architecture cosplay.
The goal is smaller: put the unstable dependency behind the narrowest useful contract.
If you are still turning a rough app idea into one buildable workflow, I made the AI App Builder Starter Prompts free so you can define the user, outcome, inputs, constraints, and proof before choosing an AI service. Imagine you are building a note app with a feature that turns a long note into three action items.
The user journey is simple:
That is the product contract. None of it requires the screen to know the provider, model name, SDK, or raw response format.
Here is how I would keep the integration replaceable.
Call it something like extractActionItems(noteText)
.
Do not name the main function after the vendor. The rest of the app cares about the outcome, not which company produced it.
The input might be:
The output might be:
complete
, empty
, or unavailable
Your app should validate that result before the screen sees it. A provider's response object is evidence arriving at the border, not your internal constitution.
One server route, service file, or backend function owns the provider SDK and model identifier.
The UI calls your capability. Your capability calls the adapter. The adapter translates the outside response into your output shape.
That is the seam.
Vercel's AI SDK documentation describes this same broad idea through a standardized language-model interface. Its provider-management guide goes further with a central registry, aliases, and multiple providers. You do not have to use that library. The important design lesson is centralization: switching should happen in one known place.
Do not ship provider secrets in a browser or mobile app. Keep them on the server or in a secure backend function.
Also keep the chosen provider and model in configuration rather than scattering them across feature code. A model change should not require editing five buttons and three screens.
Keep three small examples that represent the feature:
For each fixture, write the acceptable result. When you change a prompt, model, or provider, run the same fixtures again. This is not a perfect benchmark. It is a product-specific migration test.
Decide what the user sees when the provider times out, rejects the request, reaches a limit, or disappears.
For the note app, the rest of the product should still work. The user can read and edit the note. The action-item feature can say it is temporarily unavailable without corrupting data or trapping the user behind a spinner. GitHub's pre-retirement brownouts are a good reminder: test the failure while you still control the timing.
Record:
That note is enough to keep a future migration from starting with “Where is this thing even wired in?”
You can ask your AI coding tool to inspect the project and answer these questions without changing code:
Then ask for a migration plan with one constraint: preserve the user journey and change the fewest product-facing files possible.
The free AI App Builder Starter Prompts can help you define that workflow and its proof before the tool starts moving code around.
A provider boundary is not free.
Different models and services support different tools, context sizes, structured-output behavior, safety controls, latency, and pricing. If you force every provider into the lowest common denominator, you can lose the feature that made your first choice valuable.
That is why I would not pretend all providers are identical.
Keep the product contract stable, but allow provider-specific settings inside the adapter. If one provider supports a useful capability, use it deliberately and document it in the exit note. Your replacement may need a different implementation as long as it preserves the user outcome.
Routing layers can also help, but they introduce another dependency. Vercel's AI Gateway routing rules, for example, can rewrite requests from one model to another without an application code change. That can improve recovery, but it does not remove your responsibility to verify that the destination still produces an acceptable result.
The rule is not “never depend on anything.”
It is “know where the dependency ends and your product begins.”
Pick one outside service in your app. It can be AI, email, payments, maps, or storage.
Draw three boxes:
`Your screen -> Your capability -> Outside provider`
If you cannot draw those boundaries because provider details appear everywhere, do not rewrite the whole project tonight. Choose one user workflow, write its input and output, move the outside call behind one seam, and save three fixtures.
That is enough architecture for a first migration plan.
If you want the immediate guided action, start with the AI App Builder Starter Prompts, which are free. If you want the organized path from idea to publication, AI App Builder From Zero is my $19 field manual covering scope, stack, architecture, prompting, QA, deployment, and launch. You can also find me here:
Medium: [https://medium.com/@marcusykim](https://medium.com/@marcusykim)
DEV.to: [https://dev.to/marcusykim](https://dev.to/marcusykim)
Website: [https://marcusykim.com/](https://marcusykim.com/)
X: [https://x.com/marcusykim](https://x.com/marcusykim)
LinkedIn: [https://www.linkedin.com/in/marcusykim/](https://www.linkedin.com/in/marcusykim/)