Blog...
A blog posts...
The content for a blog post is loading...
A blog posts...
The content for a blog post is loading...
On timing your tech stack and framework bets in the middle of an accelerating AI curve.
Dec 2, 2025
When you start a company, you’re not just picking a problem, a market, or a co‑founder. You’re also picking a slope on a technology S‑curve that you’ll be stuck with for a long, long time.
Facebook picked PHP and is still living with its descendants. Shopify picked Rails and still stewards it. Once you commit, your stack is sedimentary rock — painful to rip out later.
In my head, it looks something like this:
At any given moment, a technology — or an ecosystem of frameworks built on top of it — sits somewhere along this S‑curve:
When you found a company or pick a core stack, you’re choosing a point on that curve and drawing your own line from it.
Pick at t₁ and you’re early: you’re hand‑rolling tools and inventing a framework as you go. Pick at t₃ and you’re late: frameworks are great, conventions are clear, and upside is bounded by maturity.
There’s a tempting misread in 2025: AI capabilities are in the steep part of the curve, so the frameworks on top of AI must be too. Not yet. Real production apps are few, opinions aren’t battle‑tested, and most agent frameworks still feel initiation‑era — exciting but raw.
So the question is:
In the middle of this AI curve, where do you want to lock in your stack and frameworks?
Sam Altman’s OpenAI Dev Day 2024 advice: build for tasks models can almost do today so the next model makes them great. (transcript) Pair that with METR’s time‑horizon curve: GPT‑5.1‑Codex‑Max sits around 2–3 hours of human work per run; a conservative read suggests a 10× jump in the next 12–18 months. By the time you want to refactor, one well‑shaped prompt may buy you a mini‑project. The risk shifts: you’re choosing both a slope and how movable future agents will find you.
Vercel AI SDK feels like modern jQuery: thin, sane defaults, no pretense of being a framework. It makes the obvious thing easy, but doesn’t trap you in a worldview.
Above it sit agent frameworks like Mastra and other “all‑in‑one” stacks with RAG, routing, middleware, and workflow graphs. They’re the Ember/Angular moment for agents: buy in and you move fast, but you also inherit their opinions about orchestration, state, and I/O.
Picking a framework in the initiation phase is a bigger bet than it looks.
If the community moves on, you unwind assumptions baked into every file and workflow, not just a dependency. That’s why AI SDK–style primitives feel like the safer center: they unlock progress now while keeping the door open to whatever “React-equivalent” primitive emerges for agents.
The last time the tooling felt this unsettled was the front‑end framework wars. jQuery was the thin “just let me ship” wrapper over gnarly browser APIs. It didn’t tell you how to structure anything; it just made the DOM usable so you could get a product out.
Then came Backbone, Knockout, Ember, Angular — routers, data layers, templating, conventions. Ember especially felt like Rails for the front‑end: stay inside the lines and you get a whole stack for free. Teams standardized on them, and ripping one out later was a root canal.
React showed up and refused to be a full framework. It nailed a single primitive (components as a function of state) and let the community backfill routing, data, and patterns. That primitive won because it was flexible enough to survive multiple waves of best practices.
Today’s AI stack rhymes with that history: thin primitives that just work, early frameworks promising speed, and a looming question about which primitives will endure once the ecosystem hardens.
Models learn from the code they see most. Pre‑training and post‑training pipelines are stuffed with mainstream stacks and design systems, not your bespoke architecture. So they write safer, more idiomatic Next.js than your custom thing, spot familiar folder conventions, and trip on the weird edges. Two founders building the same product on different stacks will get different agent help: one gets better autocomplete, refactors, and migrations; the other stays off‑distribution.
Because model horizons stretch every release, the advantage compounds on familiar stacks: on‑distribution teams get near‑exponential capability bumps, while off‑distribution teams get slower, wobblier gains and spend more time translating — whether that’s translating from mainstream patterns into a bespoke language, or from an aging, abandoned framework back into something the models still know well. That same stretching horizon will make migrations cheaper by late 2026, but only if your codebase stays legible enough for agents to chew through larger chunks without constant translation.
If you’re building agents or AI‑heavy products, you’re choosing:
Your strategies:
Most teams will land on a primitives‑first hybrid: mainstream, model‑friendly primitives (the “Next.js and friends” of your domain, plus AI SDK), thin glue, and selective framework use only where it clearly de‑risks a surface area. That’s where I am today.
Pick too early and you’re writing your own PHP in 2004 or a bespoke agent runtime in 2025. Pick too late and the upside is bounded by maturity. The sweet spot is early growth: primitives stabilizing, community converging, models trained heavily on the winners. Agent frameworks aren’t there yet, so treat them like initiation bets and keep your stack movable. The METR curve shrinks your lock‑in half‑life; if you keep things mainstream and legible, future agents should move you in days, not quarters.
Rule of thumb for 2025: default to growth‑phase primitives the models already know, and design your code so a future agent can migrate you in a weekend.