The Skill of Not Building in the AI Agent Era (2) — Implementations at the Platform's Mercy

Part 1 presented cases where many of the early-boom services were absorbed into the platform’s flagship features, and briefly noted how, each time an API they relied on changed or was retired, the implementation built on it became a liability. This part covers that implementation side in more detail, explaining through concrete mechanisms why what you build on AI does not last.

Does It Get Old, or Does It Vanish?

In ordinary application development, an old API or library usually takes years to go from incompatible or deprecated to retired. A new web framework appears, but apps built on the old one don’t stop immediately. With databases, the lifecycle of the products and APIs is extremely long: SQL languages and designs written decades ago are still in production today.

AI is different. When the API underneath you changes, you are forced to keep patching to keep things running; when it is retired, you rebuild or discard. When the model gets a notch smarter, it’s not just the prompt itself — the surrounding pipeline of preprocessing, postprocessing, correction, splitting, retries, and selection logic all changes at once. And beyond that, the very problem you set out to solve disappears, and the whole layer becomes unnecessary. This is a different order of thing from a new library replacing an old one. It happens in at least three forms.

An API Can Vanish Wholesale, Overnight

An end of service is not unique to AI. Cloud services like AWS also have API-retirement schedules — but those play out over years, and rarely. AI models are different: about a year after release, the next generation takes over and the model is retired. Release and retirement keep swapping on a short cycle.

Anthropic’s case makes it plain. Claude 3 Opus (March 2024) ended in January 2026, and Claude 3.5 Sonnet (June 2024) in October 2025 — the early models still lasted a year and a half to two years. But the newer the generation, the shorter the gap. Claude 3.7 Sonnet (February 2025) ended in February 2026, Sonnet 4 and Opus 4 (May 2025) in June 2026, and Opus 4.1 (August 2025) is scheduled to end in August 2026 — each about a year after release. Google likewise publishes deprecation and shutdown dates per Gemini model, after which the endpoint itself becomes unavailable.

The premise that you can pick a model and use it as-is for years no longer holds. Sometimes you can migrate by just rewriting the model ID, but if the model’s response tendencies, thinking mode, tool use, or supported parameters change, you end up revisiting prompts, evaluations, tests, and even error handling.

Generational changes do shift the premises of parameters. On Anthropic’s current models, adaptive thinking became the standard, and the former manual specification budget_tokens now errors if sent. Sampling parameters like temperature also error if you send a non-default value. Yesterday’s fine-grained optimization becomes a rejected setting in the next generation. In AI development, it’s safest to assume that the moment you start using an API, you already need a migration plan.

A Smarter Model Deletes the Surrounding Code

Earlier LLMs couldn’t reliably return a fixed JSON format. So developers wrote code to extract the JSON with regexes, strip Markdown code fences, repair broken JSON, re-ask when required fields were missing, correct invalid enum values, and re-run with a different prompt when parsing failed.

But the providers began offering structured outputs. OpenAI’s Structured Outputs is provided as a feature that guarantees adherence to a JSON Schema, and in evaluation with strict mode it reported 100% schema conformance. Of course, correctness of the content itself is not guaranteed. Even so, much of the parser, repairer, and retry logic built on the assumption that “the model returns broken JSON” lost its value to a model-side feature.

The same happened to tool calling. Previously you told the model “output the tool name and arguments to use in the following format,” parsed the string, and called the function. Now each provider offers structured tool calling as a basic API feature. Your homegrown tool-selection syntax and parser become unnecessary without being broken.

Wider Context, Less Long-Context Work

To pass long documents or codebases to an LLM, many systems implemented complex processing: fixed-length chunking, semantic splitting, hierarchical summarization, summaries of summaries, vector search, reranking, conversation-history compression, dynamic selection of relevant parts, deletion of old history.

None of this became entirely unnecessary. It’s still needed when handling large data, retrieval precision, cost, and access permissions. But once a model’s context length expands to hundreds of thousands or millions of tokens, the need to build complex RAG up front for a small document set or a single repository thins out.

Anthropic advertises Claude Opus 4.8 in 2026 with 1 million tokens of context and up to 128,000 tokens of output as standard. The Gemini API likewise presents million-token-scale long input as a primary feature. While you spend six months building a hierarchical summarization system, feeding the whole text in as-is may turn out cheaper, simpler, and more accurate.

That said, this isn’t a call to throw RAG away. The order is simply backwards: evaluate with full-text input first, then add the RAG you actually need only where you can measure a problem in precision or cost. Starting from heavy RAG infrastructure up front is what wastes most of the work.

A Technical “Stranded Asset”

Technical debt is usually described as sacrificing design quality for short-term convenience and paying the fix-up cost later. What happens in AI is a little different. Even if you design carefully, write enough tests, and follow the official recommended approach, a shift in the API underneath or in the model can leave your implementation broken or unnecessary.

This happens on a different axis from the quality of your design. External progress erases the very economic and practical value of the technology you invested in. Less technical debt than a “technical stranded asset” (a finance term for an asset that loses value ahead of its expected life due to external changes in regulation, technology, or the market).

• The summarization hierarchy you built because the model couldn’t read long text becomes unnecessary once the model can read the whole thing.
• The repairer you built because JSON wasn’t returned correctly becomes unnecessary once structured output is stable.
• The rule engine you built because tools couldn’t be selected becomes unnecessary as the model’s tool-use ability improves.
• The router and cache you built because the model was expensive can’t recoup their investment once an equally capable model’s price drops.

Prices fall fast, too. The inference price per unit of capability keeps dropping sharply year over year, with some analyses estimating a several-fold drop per year. Sometimes the optimization infrastructure built to shave a modest API bill sees the price it was targeting disappear before the work is even finished.

The code runs and the tests pass. Yet the value of using it vanishes. This is the stranded asset of the AI era.

The Lifespan AI Can’t Extend

The several years of grace from deprecation to removal now shrink to months, or a year. With AI writing the code, building has become fast and cheap. But cheaper generation only means taking on more short-lived implementations. What makes the difference is not how fast you can build, but the judgment of what to leave unbuilt.

Part 3 turns to the act of building itself: increasingly, the throwaway code is written not by a person but by a coding agent inside a loop.

References

• Anthropic — Model deprecations
• OpenAI — Introducing Structured Outputs in the API
• Anthropic — Tool use overview
• Gemini API — Long context
• Epoch AI — Trends in the cost of AI capabilities