Seneca wrote that every new beginning comes from some other beginning’s end. He was writing about time — how we live in a continuous flow of transitions, each new phase emerging from the completion of the last. Product leaders building AI systems are working through exactly this dynamic, whether they’ve named it or not.
Every AI model update creates a new beginning by ending the previous version’s assumptions. Every infrastructure upgrade rewrites the operational playbook. Every significant capability improvement from a frontier provider makes yesterday’s integration architecture obsolete. The question for product leaders isn’t whether your AI systems will become obsolete — it’s whether you’ve designed for that obsolescence or against it.
The Paradox of AI Infrastructure
Here’s the tension: we want the reliability of traditional software — predictable, testable, maintainable — but we’re building with components that evolve continuously through training updates, capability improvements, and API changes. The mental model of “build it, test it, ship it, maintain it” breaks down when the underlying model your product depends on updates monthly and the new version behaves differently than the version you tested.
Traditional software has a stable lifespan. A well-built accounting system can run for a decade with minimal changes. AI systems don’t work that way. The capability floor keeps rising. A system that uses GPT-3.5 for a task that GPT-4 now handles better isn’t just suboptimal — it’s a competitive disadvantage, and the gap between the current capability and your deployed system grows every month you maintain the old architecture.
This creates a design challenge that has no equivalent in traditional software: you need to build systems that are robust enough to operate reliably at scale AND modular enough to be replaced component by component as better capabilities become available. These two requirements pull in opposite directions, and resolving the tension is one of the defining architectural challenges of AI product development right now.
Designing for Obsolescence
The practical answer is designing for obsolescence rather than designing for permanence. This means:
Modular AI architecture. Build so that individual AI components can be upgraded or replaced without rewriting the product around them. The abstraction layer between your product logic and your AI provider isn’t just a technical nicety — it’s what makes planned obsolescence economically viable. Without it, every major model upgrade is a replatforming project.
Shorter depreciation cycles. AI infrastructure doesn’t depreciate on the same timeline as traditional software infrastructure. Planning for 6-12 month cycles on AI-specific components — rather than the 3-5 year cycles that traditional software justifies — is a more honest accounting of how quickly the capability landscape moves. Finance teams that don’t understand this will consistently underfund the migration work required to stay competitive.
Evaluation frameworks that survive component changes. If your AI system doesn’t have an automated evaluation suite that runs against new model versions before deployment, you have no safe migration path. Every model update becomes a manual testing project, and the cost of that manual work is what prevents organizations from adopting capability improvements on a competitive timeline. Build the evals first. They outlast every model generation.
The Economics of Planned Obsolescence
There’s a counterintuitive economic argument here that takes time to internalize: the goal isn’t to build AI systems that last forever. It’s to build AI systems that create enough value before their obsolescence to fund their own replacement.
This is different from how most organizations think about infrastructure investment. The traditional framing is: invest once, amortize over years, minimize ongoing costs. The AI infrastructure framing is: invest in modularity, accept component replacement as a regular operational cost, and measure success by how quickly you can upgrade — not by how long you can avoid upgrading.
Organizations that accept this economic reality build faster. They ship AI improvements on the timeline of capability improvements rather than on the timeline of their budget cycle. The ones that treat AI infrastructure like traditional software infrastructure spend their engineering budget on maintaining increasingly outdated components rather than on adopting the capability improvements that would actually serve users better. Andreessen Horowitz’s AI Canon has useful framing on the infrastructure investment thesis that informs this economic argument.
The Human Side of Technological Obsolescence
There’s a team-level version of this design-for-obsolescence principle that’s equally important: the skills required to build AI products are themselves subject to rapid obsolescence.
Prompt engineering techniques that were genuinely valuable 18 months ago have been partially automated. Fine-tuning approaches that required deep ML expertise are now accessible with far less specialization. The skill set that makes a great AI product team today is different from the skill set that will matter in two years — not completely different, but different enough that teams that don’t continuously build learning into their culture will find themselves behind.
When I’m building an AI product team, I prioritize adaptability and learning velocity alongside current expertise. Current tool knowledge matters. The capacity to acquire new tool knowledge matters more over a multi-year horizon. This is the team-level version of Seneca’s principle: build organizations that benefit from change rather than organizations that resist it.
Your Turn: Apply This Today
Design for obsolescence before the next obsolescence cycle forces you to:
- Audit your AI architecture for replaceability. For each AI component in your product, ask: if we needed to swap this model or provider in 60 days, what would it take? If the answer is “months of reengineering,” you have a design-for-permanence problem that will cost you competitively every time the capability landscape shifts.
- Build your evaluation framework before you need to migrate. Create an automated suite that tests your AI system’s behavior against defined quality criteria. Run it against new model versions before deployment. This is the single most important investment for making planned obsolescence operationally viable.
- Restructure your infrastructure budget cycle for AI components. Present a 12-month replacement plan for AI-specific components to your finance stakeholders — not as a failure to build durable systems, but as a realistic amortization of infrastructure that improves faster than traditional software. Make the economic argument explicitly.
- Map your team’s “obsolescence risk” skills. Identify the skills in your team that are most likely to be automated or made obsolete in the next 18 months. Build a plan for transitioning those team members to higher-leverage work before the transition is forced. This is better for your team and better for your product.
- Build abstraction layers into every new AI integration. Make it a team norm: no direct AI provider dependency in product logic. Every AI integration goes through an abstraction layer that can be retargeted without rewriting the product. This is the architectural equivalent of designing for obsolescence.
- Run a “what if this model becomes unavailable?” exercise quarterly. For your primary AI capabilities, simulate a scenario where the current provider or model is unavailable in 90 days. How long does migration take? What breaks? The exercise will reveal architectural dependencies you’ve accepted without explicitly deciding to.
Seneca’s discipline about time connects directly to the hidden cost of real-time AI decisions — Seneca’s email rule and the cost of always-on AI explores the other dimension of this Stoic lens on AI product decisions.
Building AI systems and trying to make architecture decisions that hold up as capabilities evolve? I consult with product teams on AI architecture strategy, planned obsolescence frameworks, and building organizations that adapt rather than resist when the capability landscape shifts. Let’s talk.