100 Future Fortnights
TL;DR: 100 fortnights is about 3.8 years. That’s roughly how far out anyone can credibly plan in AI right now. But here’s what I’ve learned building through this chaos: your implementations should burn like phoenixes — daily, hourly, who cares — but your interfaces need to live at least 100 days. The things behind the wall are disposable. The things on the wall are promises. And your brands? They’re the fastest-evolving layer of all, because AI just handed us the ultimate promote/demote machine.
The Math That Changed How I Think
100 fortnights. That’s 1,400 days. About 3 years, 10 months.
In AI time, that’s an eternity. GPT-3 to GPT-4 to Claude 3 to Gemini Ultra to open-weight models that would’ve been state-of-the-art 18 months ago — all in less than 100 fortnights. We went from “AI can write a limerick” to “AI can build your entire application” in roughly that window.
But here’s the thing nobody talks about: within that insane rate of change, there’s a stable meta-pattern. And if you see it, you can build on top of the chaos instead of drowning in it.
The pattern is this: implementations die fast; interfaces must live slow.
Implementations Are Kindling
Martin Fowler gave us the concept of the Phoenix Server years ago — the idea that instead of patching a server, you burn it down and rebuild from scratch. Immutable infrastructure. Disposable by design.
AI makes this philosophy trivially cheap to execute. Not just for servers — for everything.
Your backend service? Rewrite it Tuesday. Your data pipeline? Let Claude rebuild it from the spec. Your ML model? Retrain it tonight. The implementation is the part that should change. It’s the kindling. Let it burn.
“A building is not something you finish. A building is something you start.” — Stewart Brand, How Buildings Learn
Brand was talking about physical architecture, but he nailed the software insight decades early. His concept of “shearing layers” — the idea that buildings have components that change at radically different rates (the site lasts centuries, the structure decades, the skin years, the services months, the space plan weekly) — maps perfectly to software systems.
Implementations are the space plan. Rearrange them constantly.
Interfaces Are Contracts
Most (people, companies) see the speed of AI-assisted development and think everything should move fast. Change the API! Rename the CLI flags! Redesign the UI every sprint!
No. Interfaces are contracts. They’re the points of trust between humans and software, between components and components, between your system and the world.
And I mean all interfaces:
- APIs — the endpoints your customers build against
- CLIs — the commands your DevOps team memorizes
- TUIs — the terminal interfaces your power users love
- UIs — the screens your customers navigate by muscle memory
- PIs — Protocol Interfaces — the wire interfaces that everything else rides on
That last one deserves its own moment. I made up the acronym, but the concept is deadly serious.
PIs: The Wire Interfaces
A Protocol Interface is what happens when two systems agree on how to talk to each other across a wire. HTTP. gRPC. WebSocket. MQTT. TCP itself. These aren’t just “protocols” — they’re interfaces at the transport layer. They’re the handshake agreements that make everything above them possible.
Think about it: every API is really just a set of conventions on top of a protocol interface. REST is a style guide for HTTP. GraphQL is a query language over HTTP. gRPC is a contract framework over HTTP/2. The protocol interface is the foundation — change it, and every API, SDK, and integration built on top of it shatters.
This is why protocol interfaces are the most sacred of all. HTTP/1.1 was standardized in 1997. It’s still running most of the internet nearly 30 years later. HTTP/2 and HTTP/3 were designed as compatible upgrades, not replacements. The IETF understood: you don’t break wire interfaces. Ever.
The same principle applies at every layer: JSON schemas, Protobuf definitions, CSV headers, plugin systems, webhook contracts — these are all protocol interfaces in disguise. They’re the agreements between systems about what bytes mean. They’re the lingua franca. And they must be honored.
Every single one of these interfaces is a promise. And promises have a minimum viable lifespan.
Jeff Bezos understood this in 2002 when he issued his famous API mandate at Amazon:
“All teams will henceforth expose their data and functionality through service interfaces… Anyone who doesn’t do this will be fired.” — Jeff Bezos
The mandate wasn’t about implementation. It was about interface. Bezos was saying: I don’t care what’s behind the wall — but the wall itself is sacred.
You can’t change your API every week without destroying trust. You can’t rename your CLI flags every month without breaking every script that depends on them. You can’t redesign your UI every quarter without alienating your users.
Interfaces must live at least 100 days. That’s the minimum. Many should live much longer.
┌─────────────────────────────────────────────────────────┐
│ IMPLEMENTATION vs INTERFACE LIFECYCLE │
├─────────────────────────────────────────────────────────┤
│ │
│ IMPLEMENTATIONS (burn fast) │
│ ■■■ ■■ ■■■■ ■■ ■■■ ■■■■ ■■ ■■■ ■■■■ ■■ ■■■ ■■■■ │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ birth die birth die birth die birth die │
│ ←─── days ───→←── days ──→←── days ──→←── days ──→ │
│ │
│ INTERFACES (live slow) │
│ ████████████████████████████████████████████████████ │
│ │ │ │
│ v1.0 introduced v2.0 (maybe) │
│ ←──────────── 100+ days (months/years) ───────────→ │
│ │
│ BRANDS (experiment fast, winners live forever) │
│ ▲▲▲ ▲▲▲ ▲▲▲ ████████████████████████████████████ │
│ ↑↑↑ ↑↑↑ ↑↑↑ ↑ │
│ test test WIN ──→ PROMOTED (lives for years) │
│ │
└─────────────────────────────────────────────────────────┘
Interfaces Become Brands
Here’s the insight that ties it all together: interfaces are brands.
Marshall McLuhan told us decades ago:
“The medium is the message.” — Marshall McLuhan, Understanding Media (1964)
He was right. The interface is the product in the user’s mind. Nobody thinks about your microservices architecture. They think about your API. Your CLI. Your UI. The interface is the brand surface.
When developers say “I love the Stripe API,” they’re not commenting on Stripe’s implementation. They’re praising the interface — its consistency, its predictability, its documentation. That interface is Stripe’s brand promise, as much as the logo.
When someone says “I’m a vim user,” they’re identifying with an interface that hasn’t fundamentally changed in decades. The implementation has been rewritten multiple times (vim → neovim), but the interface endures.
This is why interface stability matters so much. Every interface change is a brand change. And brand changes are expensive.
AI Changes the Brand Game Too
Marc Andreessen famously said software is eating the world. Now AI is eating software. And one of the things AI eats for breakfast is the cost of brand experimentation.
Think about what happened with SEO/SEM 20 years ago. Before Google AdWords, testing a new brand positioning meant focus groups, market research, months of planning. After AdWords? You could test 10 new headlines per day. Real data, real users, real signal — for pennies.
AI does the same thing for entire brands.
Want to test a new DBA (doing-business-as) for a product line? AI can generate the name, the logo, the landing page, the ad copy, and the analytics dashboard in an afternoon. Spin up 10 of them. Follow the data. Promote the winners. Demote the losers.
This isn’t theoretical. Companies are doing this right now:
- Procter & Gamble has always run a multi-brand strategy, but AI accelerates the experimentation cycle by 10x
- YC startups routinely A/B test entirely different brand identities in their first months
- Amazon’s private labels spin up and retire brand names based on marketplace data
The cost of brand experimentation just collapsed. And that changes everything.
The Meta-Pattern: Promote/Demote
This promote/demote pattern isn’t just a business strategy. It’s the fundamental pattern of intelligence itself.
┌──────────────────────────────────────────────────────┐
│ THE UNIVERSAL PROMOTE / DEMOTE PATTERN │
├──────────────────────────────────────────────────────┤
│ │
│ EVOLUTION MARKETS AI TRAINING │
│ ────────── ────────── ────────── │
│ Mutation → New entrant → Random weight → │
│ Selection → Competition → Loss function → │
│ Fitness ↑ → Revenue ↑ → Reward ↑ → │
│ PROMOTE ✓ PROMOTE ✓ PROMOTE ✓ │
│ │
│ Fitness ↓ → Revenue ↓ → Reward ↓ → │
│ DEMOTE ✗ DEMOTE ✗ DEMOTE ✗ │
│ │
│ ───────────────────────────────────────────────── │
│ │
│ LLMs (RLHF) CNNs (Backprop) BRANDS │
│ ────────── ────────── ────────── │
│ Generate → Forward pass → Launch brand → │
│ Human rank → Compute loss → Measure data → │
│ Preferred ↑ → Gradient ↑ → Traction ↑ → │
│ PROMOTE ✓ PROMOTE ✓ PROMOTE ✓ │
│ │
│ Rejected ↓ → Gradient ↓ → Traction ↓ → │
│ DEMOTE ✗ DEMOTE ✗ DEMOTE ✗ │
│ │
│ Same pattern. Every domain. Every scale. │
└──────────────────────────────────────────────────────┘
- LLMs learn via RLHF: generate responses, humans rank them, promote the good ones, demote the bad ones
- CNNs learn via backpropagation: forward pass, compute loss, adjust weights — promote features that reduce error, demote features that don’t
- Evolution works the same way: mutation, selection, fitness — promote what survives, demote what doesn’t
- Markets work the same way: new entrants, competition, revenue — promote winners, bankrupt losers
We haven’t just found a business strategy. We’ve found a pattern that recurs at every level of complex adaptive systems. And we’re going to be learning from it for decades.
This is the deepest lesson of the AI era: intelligence — biological, artificial, economic — converges on the same architecture. Generate variants. Measure fitness. Promote winners. Demote losers. Repeat.
The 10 Ways to Let Implementations Burn, Interfaces Thrive, and Brands Arrive
Here’s how to actually execute on this in your company, your team, your product:
1. Treat every implementation as a draft. Write code knowing it will be rewritten. AI makes rewrites cheap. Don’t gold-plate internals — gold-plate interfaces.
2. Version your interfaces religiously. Semantic versioning isn’t optional. Every API, CLI, SDK, and data format gets a version. Breaking changes get a major bump and a migration path. No exceptions.
3. Write interface specs before implementations. The OpenAPI spec, the CLI help text, the SDK type definitions — write these first. They’re the contract. The implementation is just the current fulfillment of that contract.
4. Measure interface stability as a KPI. Track how often your interfaces change. If your API is breaking monthly, you have a trust problem. If your CLI flags change every release, you have a brand problem.
5. Build Phoenix-style: burn and rebuild. Embrace immutable deployments, infrastructure-as-code, and AI-assisted rewrites. Your CI/CD pipeline should be able to rebuild everything from scratch in minutes.
6. Run brand experiments like ad campaigns. Spin up new brand identities for product lines. A/B test them. Use AI to generate the collateral. Follow the data. Kill the losers fast.
7. Separate interface teams from implementation teams. The people who design and maintain your API surface should not be the same people churning through implementation sprints. Interface design requires long-term thinking.
8. Invest in interface documentation like it’s marketing. Because it is. Your API docs, your CLI man pages, your SDK examples — these are your brand’s front door. AI can help you keep them immaculate.
9. Apply promote/demote to everything. Features, products, brands, team structures, processes — run them all through the promote/demote lens. What’s working? Amplify it. What’s not? Cut it. Be ruthless and data-driven.
10. Plan in fortnights, not quarters. 100 fortnights is your horizon. But plan in 1-fortnight sprints with 10-fortnight interface commitments. This gives you speed without chaos.
The Next 100 Fortnights
We’re standing at the beginning of something unprecedented. AI is compressing the implementation cycle to near-zero cost. That means the only things that matter are the layers that change slowly: your interfaces, your data models, your brand promises.
The companies that win the next 100 fortnights will be the ones that master this duality: burn the implementations, honor the interfaces, experiment with the brands.
It’s not about moving fast and breaking things. It’s about moving fast on the right layers and keeping the wrong layers sacred.
If you need help navigating this — figuring out which layers to burn, which to protect, and how to run the promote/demote playbook at scale — talk to us at Cambiar. This is what we do.
The next 100 fortnights start now. Let’s build something that lasts — by designing it to burn.
