[HN Gopher] How we rebuilt Next.js with AI in one week
       ___________________________________________________________________
        
       How we rebuilt Next.js with AI in one week
        
       Author : ghostwriternr
       Score  : 223 points
       Date   : 2026-02-24 20:07 UTC (2 hours ago)
        
 (HTM) web link (blog.cloudflare.com)
 (TXT) w3m dump (blog.cloudflare.com)
        
       | htch wrote:
       | In hindsight, a totally expected achievement given where models
       | are and the high quality tests available, but wildly impressive
       | all the same.
       | 
       | I don't know what this means but it feels like yet another
       | milestone moment.
        
       | verdverm wrote:
       | NextJS is bad enough, cannot imagine an Ai version
       | 
       | Cloudflare also lost my support because their support is among
       | the worst, rep evn sneered (cannot update my WHOIS, still, after
       | months of emails). Strongly recommend avoiding their platform.
       | You will find that you lose more time & money to dealing with the
       | issue of parity. God help you if you ever need support, almost
       | every question in Discord goes unanswered as well.
        
         | slig wrote:
         | The former CTO commented a lot here and said numerous times
         | about emailing him with issues that support couldn't figure
         | out. Maybe try emailing the new CTO?
        
       | switz wrote:
       | This is pretty fascinating and comes with some complicated AI-
       | world incentives that I've been ruminating on lately. The better
       | you document your work, the stronger contracts you define, the
       | easier it is for someone to clone your work. I wouldn't be
       | surprised if we end up seeing open source commercial work bend
       | towards the SQLite model (open core, private tests). There's no
       | way Cloudflare could have pulled this off without next's very own
       | tests.
       | 
       | Speaking more about the framework itself, the only real
       | conclusion I have here is that I feel server components are a
       | misunderstood and under-utilized pattern and anyone attempting to
       | simplify their DX is a win in my book.
       | 
       | Next is very complex, largely because it has incrementally grown
       | and kept somewhat backwards compatible. A framework that starts
       | from the current API surface and grows can be more malleable and
       | make some tough decisions here at the outset.
       | 
       | Crazy to see it's already being run on a .gov domain[0]. TTFGOV
       | as a new adoption metric?
       | 
       | [0] https://www.cio.gov/
        
         | anematode wrote:
         | > The better you document your work, the stronger contracts you
         | define, the easier it is for someone to clone your work.
         | 
         | Well said; this is my thinking as well. One person or
         | organization can do the hard work of testing multiple
         | approaches to the API, establishing and revising best
         | practices, and developing an ecosystem. Then once things are
         | fairly stable and well-understood, another person can just
         | yoink it.
         | 
         | I have little empathy for Vercel, and here they're kind of
         | being hoist by their own petard of inducing frustration in
         | people who don't use their hosting; but I'm concerned about how
         | smaller-scale projects (including copyleft ones) will be
         | laundered and extinguished.
        
         | falcor84 wrote:
         | > There's no way Cloudflare could have pulled this off without
         | next's very own tests.
         | 
         | I'm very uncovinced. History showed us very complex systems
         | reverse engineered without access to the source code. With
         | access to the source code, coupled with the rapid iteration of
         | AI, I don't see any real moat here; at best a slight delay.
        
           | anematode wrote:
           | Source code is one thing; tests covering the codebase are
           | another.
           | 
           | And if you just copy the source code or translate it one-to-
           | one into a new language, rather than make a behavioral copy,
           | there will be copyright issues.
        
           | root_axis wrote:
           | The tests are absolutely essential, otherwise there's no
           | signal to guide the LLM towards correct behavior and
           | hallucinations accumulate until any hope of forward progress
           | collapses.
        
       | rc1 wrote:
       | > The whole thing cost about $1,100 in tokens.
       | 
       | I like this is called out.
        
       | jdthedisciple wrote:
       | Shots fired, Vercel folks better hide!
        
       | aggregator-ios wrote:
       | Surprised this didn't get a higher placement on the HN front
       | page, only 34 points?
       | 
       | Absolutely impressive that this was done with $1100 in tokens and
       | in 1 week. I agree, and so do a lot of my peers that code has
       | quickly become nothing more than a tool to accomplish a task.
       | Code never was and never should have been the product in and of
       | itself. This is amazing news, and this is exactly where we should
       | be as a civilization. The only people that have trouble with this
       | development are the gatekeepers who think that code should be
       | sacred and revered by itself. That is a perversion of computing,
       | and we got the wrong group of people there.
       | 
       | While Vercel continues to be the #1 host for Next.js projects,
       | others seem to claim that migrating to their platform is as easy
       | as enabling the Github integration. It's not. Cloudflare even
       | mentions that you can port your Next project to run on its infra,
       | but I couldn't get it to work. Replit markets the same, and yet,
       | Next fails to on there too. You have to go through several
       | painful hacks and try-build-fail loops and eventually not worth
       | it.
       | 
       | You know what took less time and frustration? I asked Claude Code
       | with Opus 4.6 to convert the entire Next project to React+Vite.
       | And as a shameless plug, I was able to get https://jsonquery.app
       | fully up and running and the builds are lightning fast with Vite,
       | and worked with just 2-3 tries on Cloudflare pages. If you don't
       | need SSR and Next routing, I suggest you do the same.
       | 
       | Oh, and in Next.js land, Turbopack had severe edge cases, that I
       | had to revert to Webpack. Esp when dealing with WASM, as JSON
       | Query uses the jq dependency brought in as a wasm to run on the
       | web. This is not an issue with Vite.
        
         | cpursley wrote:
         | Or just skip/migrate off of the Next.js and other JS SSR rats
         | nets to Elixir and Phoenix LiveView - Claude and Codex are both
         | very good with Elixir now: https://elixirisallyouneed.dev
        
           | cpursley wrote:
           | see also: https://dashbit.co/blog/why-elixir-best-language-
           | for-ai
        
           | h4ch1 wrote:
           | I see this sort of maximalism a lot where people are just
           | turned off js and say f it I'll use HTMX or LiveView or
           | Alpine or whatever promises that you won't have to write js,
           | and that's fine; as long as you're building generic
           | dashboards and/or the same repetitive UI patterns. And even
           | then you're basically writing JS just in a worse way.
           | 
           | I use Liveview and Elixir for 2-3 home-lab related frontend
           | services; but when I have to do something _moderately_
           | complicated I have to reach out for a darn js library and
           | hooks and phx-commands. Try using native drag and drop or
           | even client-side markdown rendering. This also leads to
           | memory leaks when you can 't properly detach libraries.
           | 
           | I just say think about your goals; these frameworks/platforms
           | that promise to remove JS from your life or minimize it do so
           | by sacrificing something. There's no silver bullet for
           | building on the web.
           | 
           | But whenever I do talk to people who are debating amongst
           | frameworks SvelteKit and SolidStart are the two I recommend,
           | it's easy to host anywhere (unlike Next), you can turn off
           | SSR, just ship static files with very minor changes
           | (exporting a variable in Svelte for ex). They're really
           | quick, get the job done, actively being worked on, loads of
           | resources, discussions and thriving communities.
        
         | Hamuko wrote:
         | > _Surprised this didn 't get a higher placement on the HN
         | front page, only 34 points?_
         | 
         | The last time Cloudflare vibe-coded something, it was a
         | glorified proof-of-concept with TODOs up the wazoo.
        
         | blibble wrote:
         | > Surprised this didn't get a higher placement on the HN front
         | page, only 34 points?
         | 
         | looks like HN has finally defeated the cloudflare voting ring
        
         | ojr wrote:
         | last time I tried to use nextjs in a cloudflare worker there
         | was a lot of issues
        
         | somewhereoutth wrote:
         | > Code never was and never should have been the product in and
         | of itself
         | 
         | Except that the code completely and precisely defines the
         | actual product. Bad code => bad product.
         | 
         | > code should be sacred and revered by itself
         | 
         | As a production of the hand and mind, code _should_ be revered
         | - if only as the mark of the human or groups of humans that
         | made it.
         | 
         | > the wrong group of people
         | 
         | The group of people who care deeply about the world around
         | them.
        
       | bryanrasmussen wrote:
       | someone spent over 1000 dollars to replicate the functionality of
       | Next.JS, even 1 dollar would seem too much somehow. I suppose
       | that is me being overly retributive.
        
         | sailingparrot wrote:
         | > it builds production apps up to 4x faster and produces client
         | bundles up to 57% smaller.
         | 
         | I suppose that is you being overly retributive indeed.
        
       | thawab wrote:
       | Nextjs had remote code execution vulnerabilities because of how
       | they implemented react server side. I am not touching an AI
       | version without waiting for a while.
        
         | t-writescode wrote:
         | Thank you. This is the part that shocks me the most. I was
         | always wary of Next.js for this exact reason (in fact, I
         | refused to use it for personal projects before the RCE because
         | I was scared that _I_ would make a mistake and leak server-side
         | data to the client.
         | 
         | Bugs like this are easy to happen and even easier to miss if
         | you're generating thousands of lines of code with AI.
        
       | vercantez wrote:
       | Great to see. Could have use this last month when we migrated
       | from OpenNext on CF to React Router 7
        
       | troupo wrote:
       | Here's what is buried a bit in the text:
       | 
       | --- start quote ---
       | 
       | Something like 95% of vinext is pure Vite. The routing, the
       | module shims, the SSR pipeline, the RSC integration: none of it
       | is Cloudflare-specific.
       | 
       | --- end quote ---
       | 
       | The real achievement is human-built Vite (and it is an amazing
       | project).
       | 
       | Since Next.js's API surface and capabilities are known, this is
       | actually quite a good use of AI: re-implement some functionality
       | using a different framework/language/approach. They work rather
       | well with that.
        
       | acedTrex wrote:
       | God cloudflare's blog quality has fallen off a fuckin cliff ehh.
       | Used to be so good now its just llm slop both content and actual
       | writing.
        
         | spzb wrote:
         | The core network products seem to be having a run of downtime
         | issues too. Maybe they should focus on their homework before
         | going out to play with the AI kids.
        
         | bbkane wrote:
         | This is interesting to my on both a technical level as well as
         | a social-political level. I wonder what impact "AI-washing"
         | will have on licensing for example
        
         | thefilmore wrote:
         | Yup. This was so jarring to read. Shame.
        
       | hungryhobbit wrote:
       | Man, I love Next ... but I also love Vite ... and I _hate_ the
       | Next team, because they focus on fancy new features for 0.1% of
       | their users, at the complete expense of the other 99.9% of the
       | Next community (who they basically ignore).
       | 
       | This gives someone like me everything we want. Better performance
       | is something the Next community has been begging for for years:
       | the Next team ignored them, but not the Cloudflare team.
       | Meanwhile Vite is a better core layer than the garbage the Next
       | people use, but you still get the full Next functionality.
       | 
       | I wish Cloudflare the best of luck with this fork: I hope it
       | succeeds and gets proven so I can use it at my company!
        
         | 3rodents wrote:
         | What is it you love about Next that isn't tied to Vercel and
         | isn't available elsewhere? I love Next too but I find the value
         | is inextricably linked to Vercel. I can't imagine choosing to
         | use Next if I'm not choosing it for Vercel's fancy stuff.
        
         | thousand_nights wrote:
         | at my job we have some 7+ year old nextjs apps that don't
         | receive new features but still do their jobs perfectly fine,
         | and they keep changing random shit around for no reason, we've
         | had to waste time on multiple refactors already for major
         | nextjs version bumps once the older ones are no longer
         | supported
        
         | himata4113 wrote:
         | I mean you don't want really want to use javascript for the
         | backend anyway... What's the problem with just using vite and
         | any backend of your choosing?
        
         | qudat wrote:
         | Next is the worst framework I've ever used next to rails. It's
         | pure overhead for most apps.
        
       | keeganpoppen wrote:
       | i love how this disintermediates the next.js/vercel axis, which
       | seems to be determined to make basically everything hard except
       | for exactly what they want to do. as much as i love what vercel
       | has done for open source in general (amazing stuff!) it is hard
       | to interpret some of the stuff they do with next as anything
       | other than vendor lock-in bs... the kind that i know is not in
       | their hearts.
        
       | evilhackerdude wrote:
       | > The [next.js] developer experience is top-notch.
       | 
       | let me add my own unqualified statement to that: no.
       | 
       | > Next.js has invested heavily in Turbopack but if you want to
       | deploy it to Cloudflare, Netlify, or AWS Lambda, you have to take
       | that build output and reshape it into something the target
       | platform can actually run.
       | 
       | it's almost as if vercel had some kind of financial incentive to
       | gear this towards their own platform.
       | 
       | > reimplemented the Next.js API surface on Vite directly
       | 
       | a clown car screeches to a halt; several burnt-out-bored oracle
       | vs google lawyers climb out and, weirdly, i am there for it
       | 
       | all in all, it's definitely a good example of something we
       | couldn't have done for $1100 pre-llms, but: should we have? did
       | somebody consult the lava lamps?
        
       | jtbaker wrote:
       | All my homies hate Next.js
        
       | 2001zhaozhao wrote:
       | This is another example that good tests (e.g. Next.js's own test
       | suite) are SO incredibly important to making the AI able to work
       | on big projects autonomously with lower steering. So is a very
       | domain-knowledgeable human in charge of steering.
        
       | ratorx wrote:
       | I find it interesting that they _bought_ Astro
       | (https://blog.cloudflare.com/astro-joins-cloudflare/), which from
       | my definitely-not-a-frontend-person perspective seems to tackle a
       | similar problem to Next. A month ago.
       | 
       | If it is so cheap to make something that they recommend using
       | (rather than a proof of concept), why buy Astro (presumably it
       | was more expensive than the token cost of this clone?).
       | 
       | One conclusion is that, at the organisational level, it still
       | makes sense to hire the "vision" behind the framework, rather
       | than just clone it. Alternatively, maybe AI has improved that
       | much in 1 month!
        
         | bastardoperator wrote:
         | I think they just want steer users/developers to CF products,
         | maybe not? It is interesting to see the two platforms. I've
         | moved to svelte, never been a frontend person either but kind
         | of enjoying it actually.
        
         | 3rodents wrote:
         | Astro is a different paradigm. Acquiring Astro gives Cloudflare
         | influence over a very valuable class of website, in the same
         | way Vercel has over a different class from their ownership of
         | Next.js. Astro is a much better fit for Cloudflare. Next.js is
         | very popular and god awful to run outside of Vercel, Cloudflare
         | aren't creating a better next.js, they're just trying to make
         | it so their customers can move Next.js websites from Vercel to
         | Cloudflare. Realistically, anyone moving their next.js site to
         | Cloudflare is going to end up migrating to Astro eventually.
        
           | thierrydamiba wrote:
           | Can you talk more about this? What's wrong with cloudflare
           | pages plus Nextjs? Why do you need Astro?
           | 
           | Thanks
        
         | phpnode wrote:
         | The acquisition is just a different play - they get access to
         | the Astro user base and can steer the future direction of the
         | framework. This move here is all about nerfing a direct
         | competitors main advantage (to all of our benefit)
        
         | satvikpendem wrote:
         | > _which from my definitely-not-a-frontend-person perspective
         | seems to tackle a similar problem to Next._
         | 
         | It does not. Astro is more for static sites not dynamic web
         | apps.
        
           | pier25 wrote:
           | That used to be the case 3-4 years ago. Today Astro is very
           | much a serious contender for dynamic web apps.
        
             | satvikpendem wrote:
             | I tried it about 6 months ago for something I had to redo
             | in NextJS afterwards, it is really not built for those
             | sorts of web apps, even today.
        
         | pier25 wrote:
         | Unlike Astro, this looks more like a low effort experiment
         | while making fun of a competitor than a project intended for
         | any serious production use.
         | 
         | Maybe I'm wrong. We'll see what happens a couple of years from
         | now.
        
         | selridge wrote:
         | You buy that concern to hire the people. The stack is already
         | free.
        
         | input_sh wrote:
         | Astro has "server islands" which rely on a backend server
         | running somewhere. If 90% of the page is static but you need
         | _some_ interactivity for the remaining 10%, then Astro is a
         | good fit, as that 's what makes it different than other purely
         | static site generators. Unlike Next.js, it's also not tied to
         | React but framework-agnostic.
         | 
         | Anyways, that's why it's a good fit for Cloudflare: that
         | backend needs to be run somewhere and Astro is big enough to
         | have some sort of a userbase behind them that Cloudflare can
         | advertise its service to. Think of it more as a targeted ad
         | than a real acquisition because they're super interested in the
         | technology behind it. If that were the case, they could've just
         | forked it instead of acquiring it.
         | 
         | From Astro's perspective, they're (presumably) getting more
         | money than they ever did working on a completely open source
         | tool with zero paywalls, so it's a win-win for both sides that
         | Cloudflare couldn't get from their vibe-coded project nobody's
         | using at the moment.
        
       | carverauto wrote:
       | good job, now you have to support that mess that took 3774~
       | contributors to build.
       | 
       | have fun.
        
       | kundi wrote:
       | Next-js team is a bunch of inexperienced teens who like good
       | looking UIs and their lousy platform to upsell their services.
       | Very glad to see this
        
       | eaf7e281 wrote:
       | again?
        
       | redwood wrote:
       | I would not want to be working on Cloudflare's Vercel partner
       | team about now.. talking about a diplomacy-forward role
        
       ___________________________________________________________________
       (page generated 2026-02-24 23:00 UTC)