AI Dependence Risk

The risk that software built with heavy AI assistance becomes unmaintainable or too costly if AI tools become unavailable, unaffordable, or restricted — which makes good, human-legible design a hedge.

Also known as: dependence on AI, risk of dependence on AI, hedge against the risk of dependence on AI

Documents (6)

• Generative AI in the Real World: Local Voice AI with Pete Warden Ben Lorica and Pete Warden · 2026-09-10 Reader 🖥️
  Local AI is no longer a technical compromise on either text or voice: open-weight models already fit consumer hardware and track frontier quality closely, so the remaining gap is usability polish and a marketing incentive structure that rewards subscription clouds, not model capability. Voice interfaces have earned their bad reputation from bad implementations (high latency, brittle recognition), not from any inherent dislike of talking to machines; fixing latency, designing for graceful failure, and removing per-use cost thresholds unlocks a different, larger space of viable applications. Chaining specialized models through a shared text interface ('compound AI') is the honest architecture most of the field actually uses; 'end-to-end' single-model pipelines are as much a funding narrative for capital-intensive labs as a technical necessity. And the economic logic increasingly favors owning your own inference: the durable advantage in an AI product is the compounding usage loop you build around a model, not the model itself, and only self-hosting protects that loop from a vendor's unilateral pricing, deprecation, or capability changes.
• How to Respond to the Coming AI Cost Shock Stacia Garr · 2026-08-17 source ↗ Reader 🖥️
  As enterprise software vendors end subsidized AI pricing in favor of unpredictable usage-based billing, leaders must stop treating AI adoption as a software procurement decision and instead manage it as an organizational-design decision — modeling true cost elasticity, protecting core institutional capabilities against AI dependency, and integrating token budgets into workforce planning.
• Stranded in the Slow Zone Tim O'Reilly · 2026-07-24 source ↗ Reader 🖥️
  Frontier AI agents now let individual builders create personal systems with the complexity and fragility of enterprise software, so the DevOps discipline that once belonged only to large organizations — documentation that outlives any one model, and tool portability rather than model-agnostic architecture or self-hosting — has become a personal survival skill, even as the same shift turns engineers into managers of AI 'bots' and raises the same craft-versus-slop question for writing that it already raised for code.
• You Outsourced the AI—but You Still Own the Risk Harvard Business Review · 2026-07-09 source ↗ Reader 🖥️
  Because legal and reputational accountability for AI harm falls on the enterprise closest to the end user regardless of who built or trained the model, firms deploying third-party AI must proactively govern four under-managed exposures — upstream model opacity, customization liability, vendor lock-in, and regulatory fragmentation — through contractual transparency, customization governance, engineered portability, and a common standards-based (NIST AI RMF / ISO 42001) compliance foundation.
• Fragments: July 6 Martin Fowler · 2026-07-06 source ↗ Reader 🖥️
  Agentic software development has crossed from aspiration into established practice — the debate is no longer whether it changes software engineering but how — and the central live question is whether classic design and architecture fundamentals still matter, with Fowler's emerging answer being that they do, both because agents use the same constructs humans do and because good design hedges against escalating token costs and the risk of losing affordable access to AI.
• AI models can disappear overnight. Is your engineering team built to survive it? Bill Doerrfeld · 2026-06-17 source ↗ Reader 🖥️
  Because AI model and provider availability can vanish overnight (as Anthropic's Mythos and Fable models did, three days after launch, under a national-security export-control order), engineering teams should stop building their stack around any single model or provider and instead invest in a model-agnostic 'harness' (tools, memory, prompts, routing, evaluations kept independent of the model) plus open-source/open-weight models, so any given model can be swapped without rebuilding core infrastructure.

Propositions touching this concept (1)

By publication month, oldest first (extraction month when no publication date is known).

2026-03

• design implication / future workBecause extraneous load impairs not only immediate performance but schema acquisition (CLT's original prediction), self-sustaining load patterns may impair the learning that would eventually reduce dependence on AI — affecting durable skill formation. This warrants longitudinal investigation.
  Precision Proactivity: Measuring Cognitive Load in Real-World AI-Assisted Work · p28

Tensions

Open gaps (9)

• incompleteThe article never quantifies the switching cost of building and maintaining a model-agnostic harness — engineering time, ongoing maintenance across multiple provider APIs — nor whether the abstraction genuinely holds up when a task requires a capability only available from one frontier (non-open-weight) model. The hedge is treated as effectively costless.
  AI models can disappear overnight. Is your engineering team built to survive it? — read next: Total-cost-of-ownership analyses of vendor-neutral AI architecture; case studies where teams attempted multi-provider abstraction and hit real friction or capability gaps.
• incompleteThe article measures speed to a PR milestone but never addresses whether AI-accelerated onboarding produces developers who understand systems as deeply as those who onboarded more slowly. Faster PRs could mean shallower understanding, higher downstream rework, or increased dependence on AI as a crutch rather than developing genuine codebase knowledge. The article acknowledges this gap but treats it as a future research item rather than a fundamental limitation of the current finding.
  Developer ramp-up time continues to accelerate with AI — read next: Look for research on knowledge retention and long-term developer effectiveness when onboarding is AI-assisted vs. traditional. The Dreyfus skill acquisition model and research on desirable difficulties in learning suggest that compressing the 'figuring things out' phase may have hidden costs.
• incompleteThe 'Protect Core Functions' recommendation to retain expert talent or contractors as insurance against AI cost/dependency never weighs the ongoing cost of keeping that redundant capacity 'at the ready' against the AI savings it is meant to hedge.
  How to Respond to the Coming AI Cost Shock — read next: Cost-of-hedging literature, or a direct extension asking whether retained-capability cost ever exceeds the AI savings it protects.
• incompleteThe recommended negotiating tactics (usage caps, price-increase grace periods, guaranteed credit rollover) assume individual enterprise customers have meaningful leverage against dominant AI/software vendors, but the piece never addresses how vendor concentration or switching costs might make this leverage available only to the very largest buyers.
  How to Respond to the Coming AI Cost Shock — read next: The corpus's vendor-lock-in material, e.g. extract-outsourced-ai-still-own-the-risk on Jenga-like AI dependency and its SMB-vs-large-enterprise asymmetry gap.
• incompleteLorica's direct question about whether AMD or other vendors will diversify AI hardware away from NVIDIA goes essentially unanswered; Warden's response is almost entirely about Apple, leaving the 'beyond NVIDIA' hardware landscape one-sided and the original question unaddressed.
  Generative AI in the Real World: Local Voice AI with Pete Warden — read next: Would need a comparable industry voice on the AMD/alternative-accelerator side to balance Warden's Apple-centric hardware forecast.
• incompletePortability realism vs. the article's own lock-in. Trap 3 both diagnoses AI lock-in as Jenga-deep (the model woven into application logic; MCP standardizes only the connection layer) and prescribes 'design for portability' as the hedge — without showing portability is achievable enough to matter, what fraction of the stack actually migrates, or what the hedge costs. The load-bearing 'portability is a real hedge' premise is asserted against the section's own caveats.
  You Outsourced the AI—but You Still Own the Risk — read next: Switching-cost / moat analyses specific to AI stacks; total-cost-of-ownership of vendor-neutral architecture; how much of orchestration/prompts/evals actually survives a provider swap in practice.
• incompleteThe article never quantifies how often this kind of catastrophic, sudden model-loss event is likely to recur, or how many other builders have faced something similar — the case for treating this as a durable pattern rather than a one-off rests entirely on this single incident plus a historical analogy about data-center scale propagating outward.
  Stranded in the Slow Zone — read next: Read alongside a systematic count or survey of vendor-model deprecation/export-control incidents across the industry, and alongside the abstract 'model-agnostic harness' arguments this same incident has already generated elsewhere in the corpus.
• incompleteThe article doesn't examine whether Gene's specific recovery mechanism — a smart model having already, autonomously, written documentation as a side effect of its normal work, later discovered by luck — actually generalizes to other AI-built systems, or whether it depended on quirks specific to his project (a documentation-happy model, a single owner who knew where to look).
  Stranded in the Slow Zone — read next: Read alongside production-engineering literature on documentation-driven resilience and disaster recovery, or a follow-up account of whether this pattern held for a second builder in a second incident.
• uninformedThere is no discussion of whether the model vendor bears any responsibility for maintaining tool/interface compatibility across model tiers, so that a forced downgrade doesn't strand an agentic system built for the smarter model's behavior — the burden of resilience is placed entirely on the builder, not questioned as a possible vendor design/support obligation.
  Stranded in the Slow Zone — read next: Read alongside vendor deprecation and model-migration policy discussions, and alongside enterprise AI vendor-liability analyses in the corpus.