The Honeymoon Phase Won’t Last: Preparing for AI’s Platform Shift
I am old enough to remember the early days of the internet. It was a time when blogs were everywhere and information felt decentralized. Before the giant platforms and their algorithms, the web felt like a collection of independent voices. We had chronological feeds we controlled, not algorithmic ones controlled by someone else.
AI is still in the honeymoon phase, when platforms over-deliver to build adoption. Internet history tells us what typically follows. Right now there’s a mad rush to lock users into a specific model, a specific app, a specific workflow. I get why companies are doing it. But the best models today are often comparable for real workloads, and open-weight options are close enough that tying yourself to one vendor’s roadmap is a choice, not a necessity. I’ve always preferred to keep my options open: use open tools when I can, swap components when I need to, and avoid building around the assumption that any one platform will always treat me well.
What follows is a set of early warning signs. Think of them as “don’t repeat the internet” signals for teams building AI products.
Support our work by becoming a paid subscriber.
Designing for Exit While It’s Still Cheap
The first warning sign is when access to the core capability narrows over time. In AI, that can mean fewer technical details, fewer deployment options, and fewer ways to inspect or control behavior. You start by experimenting freely. Six months later, you can’t run anything locally, can’t audit what changed, can’t fork a model, and can’t make your own latency and cost tradeoffs. The vendor becomes your runtime, your roadmap, and your risk profile. You also inherit their update schedule. Many of us have noticed providers tweak models behind stable API names. Production applications need version-locking, regression test suites, and dashboards tracking output distributions to catch when behavior shifts overnight.
A second warning sign is policy volatility, often justified as safety measures. Terms of service and acceptable use policies can shift quickly, and enforcement can be inconsistent. The failure mode is not a clean error like traditional software. It’s silent refusals, degraded answers, or a workflow that works Monday and breaks Thursday with no code changes on your side. The model switches from verbose to terse, breaking parsing logic, or shifts output formats, breaking structured extraction.
When a vendor becomes your roadmap, you inherit their risk profile.
A more awkward version of policy volatility is geopolitics. Providers can decide they cannot serve certain regions or certain industries, and suddenly your product stops working for those customers through no fault of your own.
Even legitimate use cases can fall into territory that makes providers nervous. Security analysis, healthcare applications, legal research can all trigger unpredictable restrictions, creating reliability problems that have nothing to do with your code quality. The internet version of this was “the algorithm changed.” The AI version is “the model decided it can’t help,” or the platform decided your use case is now out of bounds.
The practical move is to treat multi-provider support like an insurance premium, not a nice-to-have. Keep at least one viable fallback path. Avoid letting vendor-specific features, proprietary formats, or tool calling conventions become the spine of your product. Assume switching costs will be measured in months if you wait until you’re forced.
Keep Your Moat on Your Side
Another early warning sign is asymmetric data flow. Many providers use consumer chat data for model training or improvement unless you opt out. Enterprise and API data is often excluded unless you opt in. The risk is that teams still do real work in consumer chat surfaces, and their proprietary domain knowledge can end up improving a system their competitors can also access. For teams with deep specialized knowledge, repeated corrections and detailed examples can become a high-value signal that you are giving away for free, which can dilute your advantage over time.
Privacy raises a separate concern because context windows often contain sensitive information. When you paste code or customer details into an AI assistant, that data persists in the provider’s logs with specific retention policies. For developers using IDE integrations, the assistant might be seeing every file you open, not just the file you’re actively editing.
My rule of thumb is simple: treat AI input like you’re sending it to an external service you don’t control, because you are. Build guardrails into your code, not just your policy docs. Scan outbound prompts for secrets. Limit context to the minimum. For high-sensitivity workloads, the “right” architecture might include running an open model in your environment, even if you still use a hosted model for general tasks.
Build Like You’ll Switch, Because You Will
A subtler warning sign is the assumption that switching will be easy when you need to. Prompts that work cleanly on one model break on another. Tool calling formats differ. Output that’s reliable in one system gets flaky in another. Teams assume they can swap providers later, then discover that “later” means rewriting prompts, rerunning evaluations, rebuilding tool adapters, and retraining your team to work with a new model.
Embeddings and fine-tuning make this worse. If you build retrieval around one embedding model, moving means re-embedding your entire knowledge base and retuning your pipeline. If you fine-tune on a provider’s platform, you get an artifact that only works there. These techniques aren’t mistakes, but you need to price in the switching costs before you commit.
Build like you’ll switch providers—because you will.
The practical move is to separate what your product does from which model you’re currently using. Put prompts, tool definitions, and routing logic behind a layer you control. Store conversation state in your own database, not in a vendor’s memory feature. Treat portability the same way you treat observability or backups: as a continuous discipline, not something you retrofit later.
Treat Token Costs as a Product Risk
Token-based pricing makes costs volatile. A prompt change, a longer context window, or a retry loop can spike your bill unexpectedly. Teams have seen cases where adding “explain your reasoning” to prompts doubled costs, or where a misconfigured chain-of-thought prompt made requests 50 times more expensive. You need real-time monitoring, rate limits, and circuit breakers from the start.
Beyond the bill spikes, there’s a longer-term pricing risk that should look familiar. Twitter’s API went from free and open to restricted and expensive. Google Maps had a cutover that forced billing and new keys, and many sites and apps saw maps fail until they reconfigured. Today’s AI API prices are likely below the true cost of inference, subsidized like Uber’s early rides. Amazon’s marketplace fees climbed from under 20% to over 50% once sellers were locked in. Token pricing could follow the same curve.
Rate limits and pricing tiers create different capability classes. Providers have strong incentives to degrade cheaper tiers over time while maintaining quality for premium customers. The economic logic is straightforward: inference is expensive, and the profit-maximizing move is to make lower tiers barely usable, pushing heavy users upward. Assume that whatever tier you’re on today will become worse unless you’re paying enterprise rates. Monitor model quality continuously, not just at launch.
Assume your current model tier will eventually be degraded; the profit-maximizing move is to force you upward to enterprise rates.
There’s also a strategic risk that mirrors the platform era. Your provider can see your prompts and usage patterns, which tells them exactly where the valuable opportunities are. If they ship a competing feature, they start with your playbook. Meanwhile, advantages from clever prompting decay fast as models improve and competitors copy your patterns. The durable path requires something deeper: proprietary data, workflow integration, evaluation discipline, or distribution you control.
A final warning sign is relying on a model’s internal knowledge as the sole truth for your application. Waiting for a provider to solve hallucination or complex reasoning is a trap that guarantees vendor lock-in. A recent example I found compelling is a tool called RealAI. They moved beyond simple document retrieval by fusing millions of disparate data points into standardized, queryable structured data. They also understood that foundation models still struggle with reliable math, so they wired their AI directly to dedicated financial calculators. When you move the actual intelligence into your own data pipelines and specialized external tools, you drastically reduce your dependency on any single provider. Your competitive advantage becomes your proprietary data fusion and business logic, which allows you to swap out the underlying language model whenever a better option appears.
These are early observations, not settled conclusions. The AI market is still taking shape. But the internet’s history suggests we should pay close attention to where incentives lead. We watched a handful of companies acquire their way to dominance the last time around. If we want a different outcome this time, we need early pressure for portability, transparency, user control, and actual antitrust enforcement before the defaults harden into something harder to change.
Some of that starts with the tools we pick. A concrete example from my own work: there’s real excitement around Claude Code right now, and I understand why. But I keep pointing people toward open tools that make model swapping normal. The setup I’ve been using is OpenCode paired with OpenRouter, which gives you access to different model providers without forcing you to rewrite everything when you want to try a different model. Internet platforms eventually moved to restrict the third-party tools that gave users more control. I’d rather adopt open tools now, while the window is open.
To be completely transparent, I still rely on proprietary models from Anthropic, Google, and OpenAI. A real performance gap remains between those systems and open-weights models. But that gap is narrowing quickly. You should actively explore offloading more workloads to smaller open-weights models that you can customize and augment with your own data and tools. While a startup can adopt this approach immediately, large organizations will naturally need to add layers for governance and compliance. The underlying goal is exactly the same for both. You must maintain optionality and keep control over your product.
Ethics.dev is our new sister site that tracks the practical impact of AI across fields like safety, labor markets, government regulation, and the economy. Bookmark this page for daily updates on how these rapid developments will reshape your industry. It is designed as a practical resource to help you keep up with the complex rules and economic forces shaping the future of AI.
