Wie Next.js mit AI in nur einer Woche neu implementiert wurde

• vinext ist ein mit Next.js kompatibles Framework, das von AI und einem einzelnen Engineer in nur einer Woche entwickelt wurde. Es basiert auf Vite und kann mit einem einzigen Befehl auf Cloudflare Workers deployt werden
• Die Build-Geschwindigkeit ist bis zu 4,4-mal höher, die Größe des Client-Bundles ist 57 % kleiner, und bestehende Next.js-Projekte können dieselbe Verzeichnisstruktur und Konfiguration unverändert weiterverwenden
• Es wurde für Cloudflare Workers entworfen und unterstützt KV-basiertes ISR-Caching sowie Traffic-aware Pre-Rendering, also verkehrsbasiertes Pre-Rendering
• Der Großteil des gesamten Codes wurde von AI geschrieben; über 1.700 Tests und automatisierte Code-Reviews sichern die Qualität
• Das Projekt ist ein Beispiel dafür, dass AI inzwischen komplexe Frameworks neu implementieren kann, und zeigt das Potenzial für künftige Veränderungen in der Struktur der Softwareentwicklung

---

Die Grenzen der Bereitstellung von Next.js und die Problemwahrnehmung

• Next.js ist ein führendes React-basiertes Framework, doch für Deployments in serverlosen Umgebungen ist ein komplexer Umwandlungsprozess der Build-Ausgabe erforderlich
  • Für Deployments auf Cloudflare, Netlify, AWS Lambda usw. muss das Turbopack-Build-Ergebnis von Next.js jeweils plattformspezifisch umstrukturiert werden
• OpenNext versuchte dieses Problem zu lösen, stieß jedoch auf strukturelle Grenzen, weil die Build-Ausgabe von Next.js rückwärts erschlossen werden muss, was je nach Version zu Instabilitäten führte
• An einer Adapter-API für Next.js wird gearbeitet, aber durch die ausschließlich auf Node.js ausgelegte Struktur des Dev-Servers ist das Testen plattformspezifischer APIs erschwert

Architektur und Merkmale von vinext

• vinext ist ein alternatives Framework, das die API von Next.js direkt auf Vite neu implementiert
  • Nach npm install vinext kann ein bestehendes Projekt unverändert ausgeführt werden, wenn der Befehl next durch vinext ersetzt wird
  • Mit vinext dev, vinext build und vinext deploy werden Entwicklung, Build und Deployment vereinheitlicht
• Routing, Server-Rendering, React Server Components, Server Actions, Caching und Middleware sowie weitere zentrale Funktionen von Next.js wurden als Vite-Plugins implementiert
• Mithilfe der Vite Environment API werden plattformunabhängige Build-Ergebnisse erzeugt

Performance-Benchmarks

• Vergleich mit Next.js 16 anhand derselben App mit 33 Routen
  • Build-Zeit: vinext (Vite 8/Rolldown) 1,67 Sekunden → 4,4-mal schneller als Next.js
  • Größe des Client-Bundles: 72,9 KB → 57 % kleiner als bei Next.js
• Die Tests wurden in GitHub CI ausgeführt; gemessen wurden ausschließlich Kompilierungs- und Bündelungsgeschwindigkeit
• Der Rust-basierte Bundler Rolldown aus Vite 8 trägt zur besseren Build-Performance bei

Deployment auf Cloudflare Workers

• Mit dem Befehl vinext deploy werden Build und Deployment automatisch ausgeführt
  • Sowohl App Router als auch Pages Router werden unterstützt, einschließlich Client-Hydration und State-Management
• Über den Cloudflare-KV-Cache-Handler wird ISR (Incremental Static Regeneration) standardmäßig bereitgestellt
  • Das Cache-Backend ist austauschbar und kann auf R2 oder die Cache API erweitert werden
• Als reale Beispiele werden unter anderem ein App Router Playground und ein Hacker-News-Klon veröffentlicht

Traffic-aware Pre-Rendering (TPR)

• Die Ineffizienz des statischen Pre-Renderings auf Basis von generateStaticParams() in bisherigem Next.js wird verbessert
• Mithilfe von Traffic-Daten von Cloudflare werden nur Seiten mit vielen Besuchen in den letzten 24 Stunden vorab gerendert
  • Beispiel: Von 100.000 Seiten werden nur 184 Seiten (90 % des gesamten Traffics) innerhalb von 8,3 Sekunden gerendert
• Die übrigen Seiten werden bei Anfrage per SSR gerendert und anschließend per ISR gecacht; bei jedem Deployment erfolgt eine automatische Aktualisierung entsprechend dem Traffic-Muster

AI-gestützter Entwicklungsprozess

• Der Großteil des Projektcodes wurde von AI geschrieben, bei Gesamtkosten von rund 1.100 US-Dollar
• Mit 1.700 Vitest- und 380 Playwright-Tests wurde eine Kompatibilität von 94 % zur Next.js-API erreicht
• Entwicklungsablauf
  • AI implementiert Funktionen und schreibt Tests → Tests werden ausgeführt → bei Fehlschlägen wird Fehler-Feedback gegeben und erneut versucht
  • Ein AI-Agent führt sogar Code-Reviews und Korrekturen automatisch aus, während Menschen nur Richtung und Struktur steuern
• In OpenCode wurden mehr als 800 Sitzungen durchgeführt, unter Verwendung von Claude-Modellen

Faktoren, die dies durch AI ermöglichten

• Dank der klaren Dokumentation von Next.js und der umfangreichen Test-Suite konnte AI präzise lernen
• Die stabile Build-Struktur von Vite diente als Grundlage
• Moderne AI-Modelle haben ein Niveau erreicht, auf dem sie strukturelle Konsistenz in großen Codebasen aufrechterhalten und Interaktionen zwischen Modulen ableiten können

Implikationen für die Softwareentwicklung

• Die bisherige mehrschichtige Framework-Struktur war ein Ergebnis zur Kompensation menschlicher kognitiver Grenzen
• Da AI das Gesamtsystem im Kontext verstehen und direkt Code schreiben kann, nimmt der Bedarf an zwischengelagerten Abstraktionsschichten ab
• vinext ist ein Beleg dafür, dass AI allein mit Spezifikation und Basistools komplexe Frameworks fertigstellen kann

Open Source und Zusammenarbeit

• Rund 95 % von vinext bestehen aus nicht von Cloudflare abhängendem Vite-Code, sodass es auch auf anderen Hosting-Plattformen eingesetzt werden kann
  • Ein PoC auf Vercel wurde innerhalb von 30 Minuten erfolgreich umgesetzt
• Das Projekt ist als Open Source veröffentlicht, und PRs für andere Plattformen sowie zusätzliche Deployment-Ziele sind willkommen

Experimenteller Status und praktischer Einsatz

• vinext befindet sich noch in einer experimentellen Phase; eine Validierung unter großem Traffic steht noch aus
• National Design Studio setzt es bereits auf der Regierungswebsite CIO.gov real ein und bestätigt Verbesserungen bei Build-Zeit und Bundle-Größe
• Im README sind nicht unterstützte Funktionen und bekannte Einschränkungen aufgeführt

Verwendung

• Über Agent Skill wird in AI-Tools wie Claude Code oder Cursor eine automatische Migration unterstützt
  • npx skills add cloudflare/vinext → Umstellung mit dem Befehl „migrate this project to vinext“
• Manuell kann es mit npx vinext init, vinext dev und vinext deploy verwendet werden
• Der Quellcode ist auf GitHub unter cloudflare/vinext verfügbar

Danksagung und zugrunde liegende Technologien

• Dank der Unterstützung des Vite-Teams und @vitejs/plugin-rsc konnte die Funktionalität von React Server Components umgesetzt werden
• Die Dokumentation und Test-Suite des Next.js-Teams bildeten eine entscheidende Grundlage für den Erfolg des Projekts

[GN⁺]

Hacker-News-Kommentare

• Noch vor einem Monat hieß es: „Zeig mir nur ein einziges Beispiel dafür, dass KI produktionsreife Software gebaut hat“, und jetzt hat Cloudflare mehrere Beispiele veröffentlicht, und gestern wurde Ladybird mit KI nach Rust portiert.
  Der gemeinsame Nenner dieser Beispiele ist, dass sie über eine gut ausgebaute Test-Suite verfügen, wodurch die Arbeit deutlich einfacher wurde.
  Vielleicht erlebt testgetriebene Entwicklung (TDD) dank KI ja tatsächlich ein Comeback.

• Ich mag Next wirklich sehr, aber ich liebe auch Vite.
  Allerdings wirkt es so, als konzentriere sich das Next-Team auf Funktionen für nur 0,1 % aller Nutzer und ignoriere die übrigen 99,9 %.
  Dieser Fork von Cloudflare könnte genau diese Unzufriedenheit aufgreifen. Performance-Verbesserungen sind etwas, das sich die Next-Community schon lange wünscht, das Next-Team aber ignoriert hat, und Cloudflare versucht nun, das zu lösen.
  Mir gefällt, dass Vite eine deutlich bessere Core-Layer als Next bietet und dabei die Funktionen von Next beibehält.
  Ich hoffe, dass dieser Fork erfolgreich wird und wir ihn auch im Unternehmen einsetzen können.

  • Next war von allen Frameworks, die ich benutzt habe, nach Rails das schlimmste. Für die meisten Apps ist es unnötiger Overhead.
  • Ich frage mich, ob man von einem experimentellen Projekt, das ein einzelner Engineer in seiner Freizeit gebaut hat, langfristigen Support erwarten kann.
  • Wir haben im Unternehmen Next.js-Apps, die über 7 Jahre alt sind und noch immer gut laufen, trotzdem hat das Next-Team ohne echten Grund die Struktur verändert, und wegen auslaufendem Support mussten wir immer wieder Refactorings machen.
  • Mich würde interessieren, was genau du an Next magst. Wenn die Integration mit Vercel der zentrale Wert ist, frage ich mich, warum man sich abgesehen davon überhaupt für Next entscheiden sollte.
  • Ich hasse Next und liebe Vite. Unsere große Production-App im Unternehmen basiert auf Next.js, und die Kompilierungsgeschwindigkeit ist so langsam, dass wir auf einen M4 Pro upgraden mussten. Das Next-Team weicht immer mit „lies die Dokumentation“ aus. Das Framework selbst ist langsam.

• Dieses Beispiel zeigt die Open-Source-Anreize im KI-Zeitalter sehr gut.
  Je besser die Dokumentation ist und je klarer die Verträge definiert sind, desto leichter können andere das nachbauen.
  Ohne die Tests von Next hätte Cloudflare dieses Ergebnis wohl nicht erreichen können.
  Next ist schrittweise gewachsen und dadurch komplex geworden, aber ein neues Framework kann Server Components von Anfang an vereinfachen.
  Überraschend ist, dass es bereits auf US-Regierungsseiten eingesetzt wird.

  • Das Prinzip ist, dass eine Organisation mit APIs experimentiert und Best Practices etabliert, die eine andere Organisation dann einfach übernimmt.
    Vercel hat sich das zwar selbst eingebrockt, aber für kleine Open-Source-Projekte könnte so eine Entwicklung bedrohlich sein.
  • Ich stimme der Behauptung nicht zu, dass Cloudflare ohne die Tests von Next dazu nicht in der Lage gewesen wäre. Es gibt viele Fälle, in denen komplexe Systeme per Reverse Engineering nachgebildet wurden, und angesichts der schnellen Iterationsgeschwindigkeit von KI ist die Einstiegshürde fast null.
  • Wenn es in Richtung „Open Core + private Tests“ geht, könnte echte Open Source am Ende tatsächlich in den Tests oder Spezifikationen selbst bestehen.

• Ich frage mich, ob man bei einem Stand, bei dem nicht einmal „Hello world“ funktioniert, wirklich von einer „Neuimplementierung“ sprechen kann.
  Außerdem wurde die Test-Suite des Originals direkt übernommen, und wenn das Original Teil der Trainingsdaten war, fällt es mir schwer, das als „from scratch“ zu bezeichnen.
  (Danach wurde als Beispiel ein urheberrechtlich geschützter Satz zitiert, der hier weggelassen wurde.)

• Interessant ist, dass Cloudflare vor einem Monat Astro übernommen hat.
  Wenn man so etwas mit KI leicht ersetzen kann, warum hat man Astro dann überhaupt teuer gekauft?
  Vermutlich hat man auf Organisationsebene entschieden, dass es weiterhin wichtig ist, sich Vision und Führung eines Frameworks zu sichern.

  • Dieses Projekt wirkt eher wie ein Experiment, das einer Satire auf einen Konkurrenten nahekommt, als wie etwas ernsthaft für die Produktion Gedachtes. In ein paar Jahren wird man sehen, was daraus geworden ist.
  • Astro ist ein anderes Paradigma als Next. Cloudflare scheint sich über Astro den Markt für statische Websites sichern zu wollen.
    Next.js ist an Vercel gebunden, daher wird Cloudflare vermutlich versuchen, Kunden dazu zu bewegen, möglichst nahtlos von Next zu Astro zu migrieren.
  • Astro ist für statische Sites optimiert, während Next auch gut für dynamische Websites geeignet ist.
    Wir nutzen Astro für unser internes Dokumentationssystem, und dafür ist es wirklich hervorragend.
  • Cloudflare scheint einfach zu versuchen, Traffic auf die eigenen Produkte zu lenken. Ich bin in letzter Zeit zu Svelte gewechselt und ziemlich zufrieden damit.

• Next.js hatte in der Vergangenheit eine Schwachstelle zur Remote Code Execution (RCE).
  Deshalb werde ich eine von KI erzeugte Version erst einmal auf keinen Fall verwenden.

  • Das war für mich auch der schockierendste Punkt. Genau diese Sicherheitsbedenken waren der Grund, warum ich Next.js nie für private Projekte eingesetzt habe.
    Wenn KI Tausende Zeilen Code erzeugt, können sich solche Bugs noch leichter verstecken.
  • Aber das war keine Schwachstelle von Next.js selbst, sondern eine Schwachstelle in React.

• Dieses Projekt ist eines der interessantesten KI-Experimente, die ich bisher gesehen habe.
  Wenn man sich die Next.js-Codebasis ansieht, ist sie riesig, deshalb ist es erstaunlich, dass diese Implementierung nur ein Hundertstel des Codeumfangs hat.
  Ich frage mich, ob wirklich alle Edge Cases abgedeckt werden oder ob nur die Tests bestanden werden.
  Wenn man zum Beispiel die Form-Implementierung von Next und die
  Form-Implementierung von Vinext vergleicht, sehen sie völlig unterschiedlich aus.
  Trotzdem ist es ein ziemlich beeindruckender Versuch.

  • (Antwort eines Cloudflare-Engineers) Vollständige Funktionsgleichheit ist nicht das Ziel.
    Es ist noch ein frühes Stadium, daher könnte es Probleme geben, die nicht von den Tests erfasst werden.
    Dass der Code viel kleiner ist, liegt daran, dass es auf Vite und dem React-RSC-Plugin aufbaut.
  • Vermutlich ist der Code auch deshalb kleiner, weil Vite einen Großteil der schweren Arbeit übernimmt.
  • Ehrlich gesagt finde ich es etwas lustig, dass es so wirkt, als sei Cloudflare vom Next-Team genervt gewesen und habe nun nach dem Motto reagiert: „Das kann man auch mit KI und Praktikanten bauen.“

• Ich bin skeptisch bei Aussagen wie „Wir haben X mit KI neu implementiert und es war total einfach“.
  Wahrscheinlich fehlen dabei viele Details und die Historie der Bugfixes.
  Wenn wirklich alle Tests perfekt bestanden werden, erkenne ich das an, aber sonst fällt es mir schwer, das zu glauben.

  • Ich glaube auch nicht vollständig daran, aber laut Artikel wurden die 2.000 Unit-Tests und 400 E2E-Tests von Next übernommen und alle bestanden.

• Ich stimme der Aussage nicht zu, dass „Abstraktionen in Software nur geschaffen wurden, damit Menschen mit Komplexität umgehen können“.
  Abstraktionen sind ein Mittel, das Wesen der Realität zu erfassen und die Wiederverwendbarkeit zu erhöhen.
  Außerdem sind „Abstraktion“ und „Layer“ nicht dasselbe. Ein Layer hat eher mit Separation of Concerns zu tun und kann als eine Form von Abstraktion betrachtet werden.

• Interessant ist auch die Aussage, dass die Gesamtkosten bei etwa 1.100 US-Dollar an Tokens lagen.