The panel broadly converged on this core conclusion: engineers keep building on a single AI provider because it is usually the rational short-term choice. Speed to market, access to the best provider-specific capabilities, lower integration complexity, and organizational/compliance friction all outweigh the abstract future risk of lock-in for most teams. The main caveat the panel mostly agreed on is that single-provider use becomes dangerous when teams embed core product logic, orchestration, or state management too deeply into proprietary platform layers that are hard to unwind.
The 3 strongest supporting arguments were:
-
Immediate shipping incentives dominate future portability concerns. Early-stage and product-focused teams are rewarded for launching, learning, and finding product-market fit now, not for preserving hypothetical future migration options. Engineers therefore rationally choose the fastest path: one provider, one API surface, one set of prompts/evals, one compliance review, and minimal abstraction overhead.
-
Multi-provider portability is often overstated and can reduce product quality. The panel repeatedly emphasized that providers differ in meaningful ways: context windows, function/tool calling behavior, latency, prompt caching, managed retrieval/orchestration features, fine-tuning options, and safety behavior. Building to the “lowest common denominator” can prevent teams from exploiting the very features that create differentiation. In that sense, lock-in is often accepted deliberately, not accidentally.
-
The true cost of switching is not just the model API; it compounds across the stack. Even where the panel disagreed on emphasis, there was broad recognition that migration pain comes from more than changing endpoints. Prompts, evaluations, safety tuning, latency assumptions, enterprise procurement, compliance approvals, and especially proprietary orchestration/stateful platform features all increase the cost of moving later. This makes single-provider dependence sticky even when teams know the risk.
Direct actionable answer to the original question: Engineers keep doing this because, in most organizations, it is the highest-ROI decision in the moment. They are optimizing for speed, performance, and organizational simplicity, while treating lock-in as a future problem. That choice is often rational. The practical best answer is not “always go multi-provider,” but “use one provider aggressively when it gives you a clear advantage, while avoiding unnecessary dependence in the parts of the stack that are hardest to replace later.”
2-3 concrete next steps the reader should take:
- Audit your stack and separate “provider-specific advantage” from “provider-specific entanglement” — especially prompts, evals, orchestration, memory/state, and workflow logic.
- Decide explicitly which native features are worth locking into for speed or product differentiation, and document the migration cost you are accepting.
- Build a thin escape hatch: standardized internal interfaces, portable evals, and owned orchestration/state where feasible, without slowing down current shipping.