Disposable by Design

A Velocity-First Architecture Strategy for the AI Development Era

Bottom line: In a world where foundational AI tooling reinvents itself every 12–18 months, the right target for orchestration and application-layer work is 80–90% complete, shipped in weeks — not 100% complete, shipped in quarters. The final 10–20% of "build-to-last" polish costs 3–4x the time of everything before it, and by the time it ships, the platform underneath it has often already changed.

1. The Cost Curve Has Always Existed — AI Just Made It Steeper

Long before AI, engineers had a name for this: the 90-90 rule ("the first 90% of the code accounts for the first 90% of the development time; the remaining 10% accounts for the other 90%"). It's a 40-year-old observation about software, not an AI phenomenon.

What's changed is the shape, not the existence, of the curve:

• 0–80%: AI agents collapse this phase from months to days — happy-path logic, UI scaffolding, boilerplate, initial integrations.
• 80–100%: Still mostly human work — edge cases, security hardening, compliance, the failure modes AI doesn't reliably anticipate. This phase hasn't gotten faster; if anything, reviewing AI-generated code in this zone is slower, because reviewers have to verify correctness from scratch rather than just checking style.

Net effect: the gap between "fast 80%" and "slow last mile" has widened, not narrowed. The relative cost of chasing 100% is higher today than it was five years ago, because the alternative (stopping at 85%) got so much cheaper.

2. The Second Curve: Shelf Life

Independent of effort, the ground underneath any AI-native architecture moves on its own clock — model versions, agent frameworks, and orchestration tooling now turn over roughly every 12–18 months. A system architected tightly around today's stack is competing against its own obsolescence while it's still being built. The longer the build, the more of its useful life is spent already out of date.

The crossing point: the cost of engineering the last 15% of a "complete" solution can exceed the system's remaining useful life. Spending 6 months perfecting something that's architecturally dated in 12 is a negative-ROI trade, even if every line of it works.

3. Borrow Gartner's Own Playbook

This isn't a new idea — it's an old enterprise-architecture idea applied to a faster clock. Gartner's Pace-Layered Application Strategy (introduced 2012, still standard doctrine) already splits a portfolio into three tiers by rate of change:

The mapping for an AI-native org:

• Data engineering, core APIs, business logic → Systems of Record. Capital-grade. Build to last.
• Agentic workflows, orchestration, client-facing AI tooling → Systems of Innovation. Built fast, used hard, retired without ceremony.

You're not asking leadership to accept something unprecedented — you're asking them to apply a framework Gartner has sold to enterprises for over a decade, just with a shorter clock on the innovation layer than it originally assumed.

4. The Pitch, Reframed

Capital vs. consumable. Software used to be built like real estate — a capital asset depreciated over 10–20 years. The orchestration and agent layer now behaves more like an operating consumable: built for a usage window, not a service life.

Minimize the cost of being wrong. A 3-week build to an 85% solution that captures real value beats a 6-month build to 98% that's market-relevant for less time than it took to build. If you're going to be wrong about which architecture wins next, be wrong cheaply.

The data is the moat; the orchestration is the wrapper. We're not abandoning rigor — we're relocating it. Data engineering and the API/service layer stay disciplined and durable. The agentic and interface layer is explicitly built to be regenerated as better models and frameworks arrive.

Velocity is the actual defensible position. Competitors locked into 9-month cycles to hit 100% compliance with yesterday's AI capabilities will always be shipping last generation's idea of "done." Speed-to-usable is the moat, not permanence of code.

5. What This Does Not Mean

This framing earns more trust with leadership if you pre-empt the obvious pushback:

• Not for systems of record, regulated workflows, security-critical paths, or anything with contractual SLAs — those stay in the "build to last" tier, full stop.
• Not a license to ship broken software. 85% means feature-complete enough for real usage and real feedback — not buggy or unsafe.
• Not ungoverned. The disposable layer still needs a component registry, ownership, and a deprecation policy — otherwise "disposable" becomes "unmanaged sprawl" within two quarters.

6. Recommended Next Steps

1. Classify the current roadmap into Record / Differentiation / Innovation buckets using the table above — this alone usually reframes half the debate.
2. Set a shelf-life budget per project. For anything in the Innovation tier, assume a 12–18 month rebuild and plan investment accordingly — don't over-invest in permanence you won't get to use.
3. Replace "100% spec" gates with an 85%-threshold + renew/kill checkpoint. Ship at the threshold, then explicitly decide to extend, replace, or retire — don't let projects coast into open-ended polish.
4. Protect the data layer disproportionately. Every dollar of rigor you'd have spent hardening the orchestration layer is better spent on data integrity, schemas, and APIs that every future rebuild will depend on.

7. One-Line Version

"We're not lowering our standards — we're moving them to the layer that's actually worth keeping. The data and APIs are capital; the orchestration on top of them is a consumable we expect to replace every 12–18 months, on purpose."

A note on sourcing

The crossing-curves chart is a model built for this conversation, not a published industry chart — be ready to say so if asked. What is citable: the 90-90 rule (Cargill, ~1985), Gartner's Pace-Layered Application Strategy (2012–present), and 2025 research from METR and Faros AI on AI coding velocity. Avoid leading with the term "AI Productivity Paradox" by name — current usage of that phrase in the press refers to studies showing AI slows experienced developers down, which is a different (and contrary) claim from the one you're making.