One engineer rebuilt 94% of Next.js on Vite for $1,100 in AI tokens
One Cloudflare engineer, one AI coding agent, one week, and about $1,100 in tokens produced a working reimplementation of 94% of the Next.js API surface. It's called vinext, it's built on Vite instead of Vercel's Turbopack, and it deploys to Cloudflare Workers with a single command. This isn't breaking news, Cloudflare shipped it back in late February or early March 2026, and I'm revisiting it now because the current wave of "AI agents can build real infrastructure" chatter keeps circling back to this exact case study without anyone checking what actually happened after launch week.
What actually got built
The numbers, as reported by Cloudflare itself and confirmed independently by Gergely Orosz at The Pragmatic Engineer: one engineer, using the open source coding agent OpenCode paired with Opus 4.5, spent roughly one engineering week and about $1,100 in tokens to reimplement the public Next.js API on top of Vite. Next.js's core sits around 194,000 lines of code after a decade of development. Vinext does the equivalent job in about 67,000 lines, largely because it skips legacy API support and leans on Vite's Rolldown bundler instead of writing a bundler from scratch.
The performance claims are Cloudflare's own, and worth repeating with the caveat attached: production builds up to 4x faster (an independent 33-route benchmark from InfoQ put it at 1.67 seconds versus 7.38 seconds for Next.js 16 with Turbopack, a 4.4x gap), and client bundles up to 57% smaller. Deployment is genuinely one command, npx @vinext/cloudflare deploy, which builds the app and ships it straight to Workers. That's the part that makes this more than a curiosity: Next.js has always technically been open source, but its build output is a proprietary, undocumented format tuned for Vercel's own infrastructure. Vinext routes around that by targeting a standard toolchain, which is exactly why Cloudflare, not some random contributor, funded the project.
I use agentic coding tools daily, this blog's own content pipeline runs on one, and even I did a double take at "one engineer, one week." That part is real. What gets lost in the recap is what happened in the two weeks after.
The 94% number, and the part nobody screenshots
"94% of the Next.js API surface" sounds like a rounding error until you ask what's actually in the other 6%. Cloudflare's own README and multiple compatibility trackers point to specific, non-trivial gaps: next-auth and @auth/nextjs don't work because they depend on internal Next.js route-handler APIs vinext doesn't expose. The next/image shim has gaps against the Next.js 16 API, missing fields like blurWidth and blurHeight on StaticImageData. Styled-components and Emotion only get partial support because useServerInsertedHTML isn't implemented yet. And static pre-rendering at build time is missing entirely, vinext only supports ISR, meaning pages get cached and revalidated after the first request rather than baked at build time.
None of that is cosmetic. Auth, image optimization, and static generation are exactly the load-bearing pieces most production Next.js apps depend on, which is precisely why the 6% matters more than the 94% headline suggests.
Then came the harder problem: security. Two days after launch, Vercel's CEO Guillermo Rauch published that his team had responsibly disclosed seven vulnerabilities in vinext, two critical, two high, two medium, one low, including race conditions and cross-request state pollution that could leak data between users. A separate security researcher running an AI-assisted audit through Hacktron reported dozens more candidate issues. Cloudflare's launch post did mention, more than a thousand words in, that the only real "production" deployment was a beta government site with no meaningful traffic at scale, not the battle-tested claim the opening paragraph implied. Rauch has an obvious competitive incentive to pile on here, Vercel and Cloudflare have been publicly sniping at each other for years, but the vulnerabilities were real and confirmed, not manufactured.
Why this matters more than "Next.js is dead"
The clickbait read is that frameworks are obsolete because an AI agent can clone one in a week. That's not the useful takeaway, and honestly it's not even true yet given the vulnerability count above. The actual shift is in the economics: building infrastructure-grade tooling that used to require a small team and a year of engineering time now costs low four figures and a week of one person's attention, directed carefully. Orosz's estimate of roughly 100x cheaper matches what I've seen in my own work: agents are dramatically better at "no-brainer" tasks you can verify against a comprehensive test suite (which Next.js has, and which is exactly why vinext was replicable), and much weaker at open-ended judgment calls with no test to check against.
For a solo operator, that changes the buy-versus-build math specifically for internal tooling with a test-able, well-documented spec: a custom admin dashboard cloned off a SaaS you're paying for, an internal API wrapper, a CLI that automates a workflow you currently pay a subscription for. It does not change the math for anything that touches auth, payments, or user data at the edges, which is exactly where vinext's missing 6% and its seven disclosed vulnerabilities happened to land.
What I'd actually do
If I were deciding whether to build something myself with an agent instead of paying for a vendor, I'd draw the line at test coverage and blast radius. Something with a comprehensive spec I can verify against (a script, an internal tool, a reporting dashboard, even a whole app if I control both ends) is fair game to build cheaply now, and I'd genuinely consider it before reaching for another SaaS subscription. Anything touching authentication, payment handling, or multi-tenant data isolation still needs either a mature framework with years of accumulated hardening or a real security review before it sees production traffic, agent-written or not. I wouldn't migrate a live Next.js app to vinext today, not because the idea is bad, but because "94% coverage" is a marketing number until you've mapped which 6% your app actually depends on, and Vercel's own security team just proved that mapping the remaining risk takes more than a launch week. Cheap to build and safe to ship are two different bars, and right now vinext has only cleared the first one.
Author
Lukas
@lukcombinator