One Engineer, One AI, One Week: Cloudflare Just Rebuilt Next.js
And it only cost $1,100
Hey everyone,
This one feels funny to write because last time I was talking about how AI can’t help you when a government decides to block your database provider. And now here I am, covering a story where AI literally built an entire framework from scratch in seven days.
I’ve been building software for a decade now, and I never recalibrated my sense of ‘what’s possible’ as often as I have this year.
Things that used to take a team and a quarter now take a weekend and a credit card. Every week something ships and I find myself questioning - ‘there’s no way that was built this fast!’
Cloudflare rebuilding Next.js in under a week is one of the loudest answers to my question yet.
Cloudflare took one engineer, pointed an AI model at the problem and rebuilt Next.js from scratch on Vite in under a week.
They called it vinext and claim the builds are 4x faster, the bundles are 57% smaller, and it covers 94% of the Next.js API.
But the real story isn’t the tech but what happened after they shipped it. There’s a lot to unpack in this article, so let me lay out what we’re going to cover:
The deployment problem nobody could solve → Why hosting Next.js outside Vercel has been painful for years.
One engineer, one AI, $1,100 → How Cloudflare built a working framework in seven days.
4x faster builds, 57% smaller bundles → The numbers, and what to actually make of them.
Not a wrapper, not a fork → How vinext reimplements Next.js from scratch on Vite.
The smartest thing only Cloudflare could build → Traffic-aware Pre-Rendering, explained.
When AI writes production code → 2,000+ tests, 800 sessions, and the question nobody wants to ask.
Vercel fires back → Security disclosures, public callouts, and the ecosystem takes sides.
Bigger than two companies fighting → What this means for open source, AI-built software, and you.
The tax you pay to run multiple agents.
If you’ve spent any time with coding agents, you know the feeling. You start the morning with a clean plan. Spin up a few agents. One is refactoring the auth module. Another is writing tests. A third is scaffolding a new API endpoint. You’re flying.
Then around 10:30 AM, you look up and realize you have 20 terminal windows open. One agent is blocked waiting for a decision you forgot to make. Another finished 40 minutes ago and you never noticed. A third went sideways three commits back. You’re no longer flying. You’re drowning.
You’ve shifted from human as driver to human as director. When running coding agents in parallel,the bottleneck isn’t just context. It’s your own attention trying to manage 10 agents across 10 terminals. You’re losing your mind to terminal chaos.
Meet Cline Kanban, a CLI-agnostic visual orchestration layer that makes multi-agent workflows usable across providers. Multiple agents, one UI. It’s the air traffic controller for the agents you’re already running, regardless of where they live.
Interoperable: Claude Code and Codex compatible, with more coming soon.
Full Visibility: Confidently run multiple agents and work through your backlog faster.
Smart Triage: See which agents are blocked or in review and jump in to unblock them.
Chain Tasks: Set dependencies so Agent B won’t start until Agent A is complete.
Familiar UI: Everything in a single Kanban view.
Stop tracking agents and start directing them. Get a meaningful edge with the beta release.
Install Cline Kanban Today: npm i -g cline(Thanks, Cline team for partnering on this post.)
1. The Deployment Problem Nobody Could Solve
To understand why Cloudflare built vinext, you need to understand the problem it was trying to solve. If you’re a Web or React developer, you probably already know Next.js as millions of people use it.
The developer experience on Vercel is good but the problem is what happens when you try to deploy a Next.js app anywhere else.
Next.js invested heavily in Turbopack, their own custom bundler, so the entire build pipeline is tightly coupled to their tooling.
If you want to run your app on Cloudflare, Netlify, or AWS Lambda, you have to take that build output and transform it into something the target platform can actually execute making the complete process messy and error-prone. The coupling extends to development too, next dev runs in Node.js only, so if your app uses platform-specific APIs like Durable Objects or KV, you need workarounds like getPlatformProxy just to test locally.
To solve the above problem there are tools like OpenNext. Multiple hosting providers, including Cloudflare, put real engineering effort into it. But OpenNext works by reverse-engineering Next.js’s build output, which means every time Next.js ships a new version, something can break in unpredictable ways.
It’s a constant game of catch-up. Next.js has been working on a first-class adapters API with Cloudflare’s collaboration, but it’s still early and only covers build and deploy, not the dev experience.
Cloudflare and others had tried to go further and fully reimplement the Next.js surface before, but the scope always killed the effort.
2. One Engineer, One AI, $1,100
Steve Faulkner, a Director of Engineering for Workers at Cloudflare, led the vinext effort. Instead of adapting Next.js output or building another wrapper, he reimplemented the entire Next.js API surface directly on Vite using AI (Claude via OpenCode) to write most of the code.
Within a week of vinext release, it had both routers working with Server-Side Rendering (SSR), middleware, server actions, streaming, and full client hydration, all for about $1,100 in API tokens.
Even a couple of years ago above timeline would have been dismissed as completely unrealistic. A full framework reimplementation covering two routers, 33 module shims, RSC streaming, middleware, and caching, all done in seven days.
Whatever your take on AI-assisted coding, this is a data point worth paying attention to, Faulkner posted on X about how fast the project evolved:
That kind of rapid iteration, going from Cloudflare-only to deploying everywhere via Nitro within days of release tells how far the project got in a very short time.
3. 4x Faster Builds, 57% Smaller Bundles
Cloudflare compared vinext against Next.js using a shared 33-route App Router application that covers server components, client components, dynamic routes, nested layouts, and API routes.
To keep the comparison fair they disabled TypeScript type checking and ESLint in the Next.js build since Vite doesn’t run these during builds, and used force-dynamic so Next.js doesn’t spend extra time pre-rendering static routes.
Both frameworks were doing the exact same work in these tests, compiling, bundling, and preparing server-rendered routes. Cloudflare is upfront about the limitations of these numbers and specifically states "Take them as directional, not definitive."
The full methodology and historical results are public and run on GitHub CI on every merge to main, which is the kind of transparency that earns trust regardless of where you land on the numbers.
4. Not a Wrapper, Not a Fork
vinext is not a wrapper around Next.js and it’s not a fork either. It’s a Vite plugin that reimplements the Next.js API surface from scratch. In practice that means you install it, replace next with vinext in your scripts, and everything else stays the same. Your existing app/, pages/, and next.config.js work as-is.
The only change is swapping out the CLI so instead of running next dev, next build, and next start, you run the vinext equivalents:
npm install vinextvinext dev # Development server with HMR (Hot Module Replacement)
vinext build # Production build
vinext deploy # Build and deploy to Cloudflare WorkersThat’s it. No config rewrites, no new file structure, no learning a different routing convention. Your Next.js project stays the same, it just builds and runs on Vite instead of Turbopack.
Under the hood vinext resolves all next/* imports to local shim modules, scans your pages/ and app/ directories to build a file-system router, generates virtual entry modules for the RSC, SSR, and browser environments, and integrates with @vitejs/plugin-rsc for React Server Components.
It supports App Router, Pages Router, React Server Components, Server Actions, Streaming SSR, Incremental Static Regeneration (ISR) and Caching, Middleware, Static Export, and all 33 next/* module shims.
What gets interesting is the caching layer 👇🏻
In Next.js, ISR caching is handled internally by the framework and optimized for Vercel’s infrastructure. If you self-host, you’re left configuring custom cache handlers yourself, and the interface for doing so has historically been underdocumented and tightly coupled to Next.js internals.
Which means most teams deploying outside Vercel either accept the default filesystem cache (which doesn’t work well in serverless environments) or spend significant effort wiring up their own solution.
vinext takes a different approach. It ships with a pluggable cache backend, and for Cloudflare that means ISR backed by KV (Cloudflare’s Key-Value store) out of the box. You can do the change or setup by just three lines:
import { KVCacheHandler } from "vinext/cloudflare";
import { setCacheHandler } from "next/cache";
setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));The setCacheHandler call is the key design choice here. The caching backend is completely swappable, you could use KV as the default, plug in R2 for large payloads, or write your own adapter for Redis, DynamoDB, or any other backend that fits your access patterns. Because the interface is explicit and documented, switching providers doesn’t require reverse-engineering framework internals.
That said, this is still a new abstraction. Whether the setCacheHandler API remains stable, handles edge cases like cache invalidation across regions reliably, and performs well under real production traffic are all open questions. The architecture is sound in principle, but it hasn’t been battle-tested at scale yet.
5. The Smartest Thing Only Cloudflare Could Build
This is the part that impressed me the most because it’s something that only a company already sitting on traffic data could pull off.
Most frameworks that support static generation need to know upfront which pages to pre-render. In Next.js you do this by defining a function called generateStaticParams() that returns every possible route, like every product page, every blog post, every category.
The framework then renders all of them during the build. For a site with 10,000 product pages, that means 10,000 renders at build time even though 99% of those pages may never receive a single request. This is why large Next.js sites end up with 30-minute builds.
Cloudflare had a unique insight here. They’re already the reverse proxy for your site, which means they already have your traffic data and know which pages actually get visited.
So they built Traffic-aware Pre-Rendering (TPR). Instead of pre-rendering everything or nothing, vinext queries Cloudflare’s zone analytics at deploy time and only pre-renders the pages that actually matter.
For a store with 100,000 product pages, the power law means 90% of traffic usually goes to 50 to 200 pages. Those get pre-rendered in seconds. Everything else falls back to on-demand SSR and gets cached via ISR after the first request, and pages that go viral get picked up automatically on the next deploy. No generateStaticParams(), no coupling your build to your production database.
6. When AI Writes Production Code
I have already talked a lot about process of AI writing code, Almost every line of code in vinext was written by AI, specifically Claude via OpenCode, but every line passes the same quality gates you’d expect from human-written code.
The project has over 1,700 Vitest unit tests, 380 Playwright end-to-end (E2E) tests including tests ported directly from the Next.js test suite, full TypeScript type checking via tsgo, linting via oxlint, and CI running all of it on every pull request.
Faulkner mentioned that:
“Most abstractions in software exist because humans need help. We couldn’t hold the whole system in our heads, so we built layers to manage the complexity for us. AI doesn’t have the same limitation. It can hold the whole system in context and just write the code.”
I was reading an article from Boris around working of Claude Code and the above statement made me connect on how he covered about how the Claude Code team at Anthropic works.
He described a similar pattern where with every new model release they actually “delete” production code because the model can now handle what the code used to do. Around 90% of Claude Code is written by Claude Code itself.
The team has shifted more toward Test-Driven Development (TDD) because writing tests first gives the model a clear target to iterate against. Anthropic saw a 67% increase in PR throughput as their team size doubled, not down but “up”, thanks to AI agents.
The pattern is clear whether it’s Cloudflare building a framework in a week or Anthropic shipping 5 PRs per engineer per day. AI-assisted engineering is already producing production code at a pace that makes traditional timelines look outdated.
But that raises a question worth sitting with. How many of the layers we’ve built up over the years are truly foundational, and how many were just crutches for human cognition?
7. Vercel Fires Back
Within days of vinext’s release the competitive response started.
Guillermo Rauch, CEO of Vercel, came out swinging. His team identified and responsibly disclosed seven security vulnerabilities in vinext, two critical, two high-severity, two medium, and one low.
But Rauch didn't stop at the disclosure. He went further on X and publicly called out Cloudflare's intentions in the kind of language you rarely see from a CEO:
"Cloudflare's mission is to fork the entire developer ecosystem and destroy open source. Vinext was an excuse to swindle developers into using their proprietary runtimes instead of Nodejs. It shipped with 10 vulnerabilities that they cheerfully handed to a .gov website."
That last part about the “.gov website” is particularly sharp because vinext is already running in production for CIO.gov through the National Design Studio.
A framework built by AI in one week, powering government infrastructure, with critical security holes found within days. Hours before the vulnerability disclosure went public, Rauch also posted a “Migrate to Vercel from Cloudflare” guide on the Vercel docs.
Independent researchers added to the pressure. Hacktron, an AI-powered vulnerability hunting platform, published a report titled detailing four critical vulnerabilities including race conditions, cross-request state pollution, and unsafe global fallbacks that could lead to data leaks. Their tool reportedly found 45 vulnerabilities in total with 24 manually validated.
The framing was deliberate, if AI can build it then AI can break it too.
The developer community’s reaction was split down the middle, on HN some were calling it:
“the most impressive AI-assisted project I’ve seen, not a toy, not a demo, a full framework.”
Others saw it differently and pointed out that:
“finding 7 security vulns in week-old AI code isn’t surprising, it would be surprising if they didn’t find any.”
One GitHub comment captured the tension well:
“The fact that Vercel found these bugs so quickly tells you two things. They’re very good at what they do, and vinext is important enough for them to look.”
Cloudflare’s response was measured. Faulkner himself tweeted the morning after the disclosures:
“What a day! vinext is barely a week old! Its alpha. Are there problems? Of course there are. That’s what early looks like. The whole point is community. Send Issues/PRs for performance and feature gaps, HackerOne for security issues.”
The tone was deliberately low-key with no corporate posturing and no firing back at Rauch.
Cloudflare was upfront from day one that vinext is experimental and the blog post itself states:
“We want to be clear: vinext is experimental. It’s not even one week old, and it has not yet been battle-tested with any meaningful traffic at scale.”
They have been patching the reported vulnerabilities and the GitHub README is honest about what’s not supported.
But the security situation raises a question the entire industry needs to deal with.
If AI can build a framework in a week, what does the security review process look like?
Who is accountable when AI-generated code has critical vulnerabilities?
We don’t have good answers yet, and the fact that 2,000+ tests didn’t catch these issues tells us something important about where the gaps still are.
Bigger Than Two Companies Fighting
The competitive back-and-forth is interesting but there’s a bigger picture worth zooming out on.
From an ecosystem perspective, vinext is mostly just Vite. About 95% of its codebase is pure Vite, meaning none of the routing, module shims, SSR pipeline, or RSC integration is Cloudflare-specific.
The current deployment target is Cloudflare Workers but Cloudflare got a proof-of-concept working on Vercel in less than 30 minutes and is actively inviting other hosting platforms to adopt the toolchain.
This isn’t just Cloudflare trying to take Vercel’s market share, it’s an attempt to open up the Next.js ecosystem.
From an AI perspective, this is probably the highest-profile example of a production-grade open-source project being built almost entirely by AI.
The $1,100 price tag for what would normally be a multi-month, multi-engineer effort is a number that will make every engineering leader pay attention. It connects back to the Anthropic pattern where the Claude Code team builds and tests 20 prototypes in two days, ships five releases per engineer per day, and automates first-pass code reviews with AI.
The velocity gap between teams that have embraced AI tooling and those that haven’t is getting wider every month.
For open source, vinext is MIT licensed and designed for community contribution. It already has about 7,000+ GitHub stars and Cloudflare is actively partnering with CIO.gov through the National Design Studio where vinext is already running in production.
My Take
I have mixed feelings about this one.
The technical achievement is impressive regardless of how you feel about the Cloudflare vs. Vercel dynamics. But the security vulnerabilities that surfaced almost immediately are a real concern, not just for vinext but for every piece of software built with this approach going forward.
‘Vibe-coded’ is a catchy label but when it comes to security-critical infrastructure, catchy isn’t enough.
Cloudflare had over 1,700 tests and still missed critical security issues, which tells us that functional correctness and security hardening are two very different problems. Our testing and review processes need to evolve at the same pace as our ability to generate code.
Whether vinext replaces Next.js or simply pushes the ecosystem toward better and more open tooling, the fact that it exists changes the conversation. Vercel built something incredible with Next.js and now they have a real reason to make it even better.
That’s a wrap for this edition.
What’s your take? Would you use vinext in production today?
I’d love to hear your thoughts.
Thanks so much for taking a few minutes to read.
If you liked the post, consider sharing with a friend or community that may enjoy it too.