Ein Wochenende + 1.100 US-Dollar, um die Arbeit von fünf Personen über sechs Monate zu erledigen: Cloudflare hat Next.js mit KI "nachgebaut" und es bereits in die Produktionsumgebung integriert.

Im rasant fortschreitenden Jahr 2026 der KI - Coding - Entwicklung wird plötzlich eine Frage, die ursprünglich fast absurd klang, zur Realität: Wenn Ingenieure nicht mehr Zeile für Zeile Code schreiben, kann ein komplexer Framework noch einmal "neu gemacht" werden?

Steve Faulkner, der Leiter des Cloudflare Workers - Projekts, gibt eine ziemlich radikale Antwort. Mit Hilfe der KI hat er in einem Wochenende das gesamte Next.js "nachgebaut" und es auf Vite übertragen, um Vinext zu schaffen. Die Token - Kosten des gesamten Projekts beliefen sich nur auf etwa 1.100 US - Dollar, aber das Ergebnis ist erstaunlich: Es kann bereits als Plug - and - Play - Alternative zu Next.js dienen und mit einem Befehl auf Cloudflare Workers deployed werden. In den ersten Benchmark - Tests hat sich die Build - Geschwindigkeit von Anwendungen in der Produktionsumgebung um bis zu 400 % verbessert, und das Paketvolumen auf der Client - Seite um bis zu 57 % verringert. Am wichtigsten ist, dass es von Kunden bereits in der Produktionsumgebung eingesetzt wird.

Deshalb hat Vinext schnell die Entwickler - Community in Aufruhr versetzt. Was wirklich erschüttert, ist nicht nur "wie viel Code die KI geschrieben hat", sondern dass sie sich einem Aufgabe nähert, die man früher nur von einem erfahrenen Ingenieurteam und langfristigen Investitionen ausgehen konnte: Die Neugestaltung eines Mainstream - Frontend - Frameworks mit Millionen von Benutzern. Noch subtiler ist, dass dieses Projekt nicht auf Rand - Anwendungen abzielt, sondern auf ein komplexes System wie Next.js, das langfristig eng mit Node.js, Vercel und einer maßgeschneiderten Build - Kette verknüpft ist. Mit anderen Worten, dies ist nicht nur eine Demonstration von KI - Coding - Fähigkeiten, sondern eine Versuch, eine realistischere Frage zu beantworten: Wenn bestehende Frameworks bei der Bereitstellung über verschiedene Laufzeiten und Plattformen immer unhandlicher werden, kann die KI es einfach "neu schreiben"?

In letzter Zeit hat Steve Faulkner in einer Podcast - Episode mit den Moderatoren Wes Bos und Scott Tolinski ausführlich über die Hintergründe dieses "slop fork" - Projekts gesprochen. Sie haben auch über den KI - Coding - Workflow, den Agent - Browser, die Code - Qualität, den Testgetriebenen Entwicklungsansatz und wie Software - Tools in einer KI - ersten Ära aussehen sollten, intensiv diskutiert. Basierend auf diesem Podcast - Video hat InfoQ den Inhalt zusammengefasst und teilweise bearbeitet.

Die Kernaussagen sind wie folgt:

• Die Menschen müssen weiterhin die Richtung bestimmen, die KI ist nur ein Werkzeug zur Ausführung und Beschleunigung;
• Das Ziel ist nicht, "eleganteren Code" zu schreiben, sondern Kompatibilität zu gewährleisten, die Tests zu bestehen und zu überprüfen, ob dieser Weg machbar ist;
• Eine ideale KI - native Programmiersprache könnte die Einschränkungsmöglichkeiten von Rust und den schlanken Stil von Go kombinieren;
• Die Entwicklererfahrung für Agenten unterscheidet sich von der für Menschen. Sie braucht keine schöne Oberfläche, aber muss eine klare Struktur haben, damit der Agent die Handlungspfade verstehen kann. Diese "Agent - orientierte DX" wird in Zukunft eine wichtige Richtung sein;
• Die Medizin wird wahrscheinlich die nächste Schlüsselbranche sein. Ihr Entwicklungspfad könnte dem der Programmierbranche ähneln: Die KI kann viele Grundaufgaben erledigen, aber es braucht immer noch erfahrene Ärzte für Entscheidungen und Führung.

"slop fork"

Wes: Bitte stellen Sie sich kurz vor und beschreiben Sie Ihre Arbeitsaufgaben.

Steve: Ich bin derzeit der Engineering - Direktor von Cloudflare Workers und bin insgesamt für die Workers - verwandten Geschäfte verantwortlich, einschließlich der Agenten - Produkte, Container und des Wrangler CLI - Projekts. Unser Team hat etwa 80 Mitglieder. Ich bin seit einigen Jahren bei Cloudflare. Es muss klar gestellt werden, dass ich in meinem täglichen Arbeitsalltag nicht Code schreibe. Viele Leute haben nach diesem Projekt und meinem Blog - Artikel mich als "100 - mal - so - guter Ingenieur" bezeichnet, aber ich denke, es wäre genauer, mich als "100 - mal - so - guter Projektmanager" zu bezeichnen.

Scott: Ist dies in der gegenwärtigen Phase der KI - Entwicklung ein Trend? Sind es tatsächlich diese "100 - mal - so - guten Projektmanager", die die "Superkräfte" haben?

Steve: Ja, das stimmt. Ich denke, die KI ist im Wesentlichen ein Verstärker. Wenn Sie wissen, was Sie tun möchten, kann sie Ihnen helfen, Ihre Aufgaben schneller und besser zu erledigen. Aber wenn die Richtung falsch ist, wird sie auch diesen Fehler verstärken. Deshalb müssen die Menschen weiterhin die Richtung bestimmen, die KI ist nur ein Werkzeug zur Ausführung und Beschleunigung.

Scott: Kürzlich wird über das Wort "slop fork" diskutiert, da diesmal der Code von der KI geschrieben wurde. Was halten Sie von dieser Bezeichnung?

Steve: Ich finde diese Bezeichnung sehr interessant und habe sie akzeptiert. Ich sage sogar jetzt: "Ich werde etwas 'slop fork'". Manche Leute scherzen sogar: "Wir sollten Kubernetes 'slop fork' und es in Rust neu schreiben". Ich betrachte solche neuen Begriffe wie "Vibe Coding" oder "Clanker eher locker und fühle mich nicht beleidigt. (Hinweis: "slop fork" kann wörtlich als "Müll - Fork" übersetzt werden, hat hier aber eine Selbstironie und Internet - Meme - Note und drückt auf humorvolle Weise aus, dass man ein bestehendes Projekt mit Hilfe der KI "kopiert" und umschreibt.)

Wes: Warum haben Sie Next.js geforkt und es auf Vite laufen lassen?

Steve: Vor einem Jahr haben wir darüber nachgedacht, wie wir Next.js besser auf Cloudflare unterstützen können. Next.js hat tatsächlich einige Probleme bei der Hosting - Lösung, insbesondere in Nicht - Vercel - oder Nicht - Node - Laufzeitumgebungen. Einige Funktionen sind stark von Node und Vercel abhängig. Obwohl es theoretisch an vielen Orten deployed werden kann, gibt es in Randfällen Kompatibilitätsprobleme.

Damals haben wir überlegt, einen eigenen Compiler zu implementieren, der die Next - API unterstützt. Aber nach der Bewertung haben wir festgestellt, dass dies etwa 5 Ingenieure 6 Monate Zeit in Anspruch nehmen würde, was zu teuer und unrealistisch war. Also haben wir uns auf das OpenNext - Projekt konzentriert und investieren bis heute weiterhin in es. PS: Wenn Sie eine stabile, produktionsgetestete Lösung benötigen, sollten Sie OpenNext bevorzugen. Später haben wir es noch einmal versucht, einen Praktikanten, den Pages - Router zu implementieren, aber es ist nicht gelungen.

Der echte Wendepunkt war zwischen Dezember letzten Jahres und Januar dieses Jahres, als die Fähigkeiten der Modelle plötzlich eine qualitative Verbesserung hatten. Damals habe ich hauptsächlich die KI für Management - Aufgaben verwendet, wie das Zusammenfassen von Meeting - Protokollen, das Verfolgen von Jira - Tickets und das Sammeln von internen Informationen. Ich habe allmählich festgestellt, dass diese Modelle stark genug sind, und habe angefangen, einige Code - Projekte zu schreiben. Ich habe bemerkt, dass Next.js ein sehr umfangreiches Testsystem hat, und dachte: Könnte man die Tests direkt nutzen, um die Implementierung anzutreiben? Also habe ich am Freitagabend mit diesem Projekt begonnen.

Ich habe zunächst einige Stunden damit verbracht, zu planen, und dann wiederholt mit dem Modell interagiert. Am nächsten Morgen habe ich festgestellt, dass die Demo des App - Routers tatsächlich lief. Obwohl es noch nicht perfekt war, war es schon genug, um zu zeigen, dass dieser Weg machbar ist.

Wes: Wenn Sie Next.js von Grund auf neu auf Vite implementieren würden, wie würden Sie den Plan erstellen? Wie stark hängt dieser Prozess von Ihrem Verständnis der Software - Ingenieurwissenschaften ab?

Steve: Ich habe tatsächlich einige Vorteile, da ich mit Next.js vertraut bin und mein Team auch in anderen Frameworks Vite verwendet. Ich kenne also die Gesamtarchitektur. Die Erstellung des ersten Plans hat etwa einige Stunden gedauert, und ich habe es mit OpenCode und dem Modell ständig weiterentwickelt.

Ich habe viel mit Sprach - zu - Text - Tools gearbeitet, um meine Gedanken zu "ausleeren". Ich habe keine komplizierten Prompt - Techniken verwendet, sondern ständig die Ausgabe des Modells korrigiert, z. B. indem ich klar gemacht habe, dass einige Vorschläge nicht im Projektumfang liegen, wie das Entfernen von React. Dieser Prozess ist eher eine kontinuierliche Zusammenarbeit zwischen Mensch und KI als ein einmaliger Befehl.

Scott: Verwenden Sie hauptsächlich Markdown, um Informationen zu organisieren? Gibt es eine besonders effektive Methode?

Steve: Ich verwende ausschließlich Markdown. Bisher ist es das effektivste Werkzeug, obwohl ich denke, dass es nur eine vorübergehende optimale Lösung ist. In den nächsten zwei bis drei Jahren werden wir möglicherweise eine Arbeitsweise sehen, die besser an LLM angepasst ist.

Ich habe ein Hauptplan - Dokument und ein spezielles Test - Dokument. Der Test - Satz von Next.js ist sehr umfangreich (etwa 8.000 Tests), und viele von ihnen sind Funktionen, die ich in der ersten Phase nicht unterstützen muss. Deshalb habe ich viel Zeit damit verbracht, die Tests auszuwählen und das Modell zu leiten, welche Tests es wählen soll. Ein wichtiger Durchbruch war: Ich habe nicht versucht, den ursprünglichen Test - Satz direkt auszuführen, sondern habe das Modell gebeten, die Tests einzeln "zu migrieren". Das bedeutet, die Tests in meine eigene Testumgebung zu übertragen und die entsprechenden Funktionen schrittweise zu implementieren, und gleichzeitig die Fortschritte jedes Tests in einem Dokument zu verfolgen.

Wes: Was verstehen Sie unter "Test - Migration"? Überträgt man die Tests auf Vitest, oder implementiert man auch die entsprechenden Funktionen?

Steve: Beide. Einerseits übertrage ich die Tests auf Vitest und Playwright, andererseits implementiere ich die entsprechenden Funktionslogiken.

Wes: Ist dieser Prozess eine kontinuierliche Interaktion, oder kann er über einen längeren Zeitraum automatisch laufen?

Steve: Ich habe OpenCode bitten lassen, den gesamten Prozess zu analysieren. Die Ergebnisse zeigen, dass mein Token - Verbrauchspik um 3 Uhr morgens war, aber ich war sicherlich in diesem Zeitpunkt schlafend. Das bedeutet, dass ich tatsächlich viele Aufgaben in der Nacht geplant habe. Meine Methode ist nicht, komplizierte automatische Schleifen zu schreiben, sondern ich gebe ihm ein Aufgaben - Dokument, z. B. "Fertige diese 10 Dinge ab", und lasse es dann kontinuierlich arbeiten. Es stößt manchmal auf Probleme, aber insgesamt funktioniert es ziemlich gut.

Die Analyse zeigt auch, dass mein Arbeitsmuster "hantelförmig" ist: Entweder sind es kurze Operationen von wenigen Minuten, oder es ist eine kontinuierliche Tiefenarbeit von ein bis zwei Stunden. Dies stimmt mit meinem tatsächlichen Rhythmus überein - ich habe zwei Kinder, und die Entwicklung erfolgt in den Pausen meines Lebens. Zum Beispiel gehe ich mit den Kindern in den Park, komme nach Hause und sitze schnell an den Computer, "kick" das Modell und gehe dann wieder zu den Kindern.

Die Suche nach einem zuverlässigen KI - Workflow

Scott: Wie haben Sie diese Daten statistisch ausgewertet?

Steve: Alle Daten stammen aus den OpenCode - Sitzungsdaten. Es speichert alle Informationen in SQLite, und ich lasse das Modell diese Daten analysieren.

Scott: Welches Modell haben Sie verwendet?

Steve: Ich habe hauptsächlich Opus 4.5 und 4.6 verwendet. Etwa 99 % des Codes wurde von diesen Modellen generiert. Später habe ich mehr Code - Reviews durchgeführt und manchmal auch Codex als Hilfsmittel verwendet.

Scott: Glauben Sie, dass es große Unterschiede zwischen verschiedenen Modellen gibt?

Steve: Viele Leute sagen: "Opus schreibt Code, Codex macht Reviews". Ich habe auch zuerst so gearbeitet, aber später habe ich festgestellt, dass der Unterschied nicht so groß ist, wie man denkt. Oft reicht es aus, dass dasselbe Modell sich selbst reviewt. Ich lasse es sogar in eine Schleife gehen: Zuerst reviewt es den Code, dann repariert es die Probleme, und dann reviewt es sich selbst erneut. So wiederhole ich das ein paar Mal, bis keine offensichtlichen Probleme mehr vorhanden sind.

Wes: Wie ist Ihre OpenCode - Konfiguration? Verwenden Sie Plugins, Agenten oder MCP? Haben Sie wie diejenigen, die den ganzen Tag mit Parameter - Einstellungen beschäftigt sind, wild konfiguriert?

Steve: Ich bin genau so ein "Parameter - Tuner". Ich habe kürzlich mit pi experimentiert und habe es richtig wild eingestellt. Aber meine Gesamtkonfiguration für dieses Projekt ist sehr einfach. Ich verwende hauptsächlich die Desktop - App und VS Code und benutze die Terminal - Oberfläche selten. Ich habe auch nicht viel von MCP oder komplexen Agenten verwendet. Aber wir haben jetzt tatsächlich einen Agenten für Vinext, der einige Prüfungen im Repository durchführt. Wir haben festgestellt, dass der Agent besser funktioniert, wenn man ihm reichhaltigen Kontext gibt. Die MD - Datei dieses Agenten wurde sogar von ihm selbst zu Beginn des Projekts generiert. Ich sage ihm immer: Denke daran, die agent.md zu aktualisieren und sicherzustellen, dass alles, was benötigt wird, drin ist.

Es gibt zwei MCP - Dienste, die besser sind, wenn man sie verwendet: Einmal Context7, das einen Index von Open - Source - Bibliotheken bietet, und Exa Search. Diese beiden verbessern die Benutzererfahrung um etwa 20 %, aber es ist keine "qualitative Veränderung".

Wes: Wird der Browser während des Testprozesses von der KI automatisch bedient?

Steve: Ja. Ich habe in meinem Blog über ein Tool namens Agent Browser geschrieben. Es ist im Wesentlichen eine Kapselung von Playwright und bietet eine sehr praktische CLI - Schnittstelle. Ich habe es in diesem Projekt sehr oft verwendet.

Ich lasse es zwei Umgebungen gleichzeitig bedienen: Eine ist der App - Router - Playground in der Produktionsumgebung, die andere ist die Vinext - Implementierung. Dann gebe ich ihm Befehle, um Probleme zu reproduzieren, Verhaltensweisen zu vergleichen und Unterschiede zu lokalisieren. Dies ist sehr hilfreich beim Debugging. Einmal habe ich beispielsweise gesagt: "Das Scrollen ist nicht glatt genug". Diese Beschreibung ist eigentlich sehr vage, aber das Modell konnte das Problem selbst erkennen und eine Lösung anbieten. Das hat mich sehr überrascht.

Scott: Ich habe beim Verwenden des Agent Browsers ein Problem: Das Opus - Modell kann oft keine Screenshots verarbeiten und sagt: "Der Screenshot ist zu groß", und dann bricht die gesamte Sitzung zusammen. Haben Sie das auch erlebt?

Steve: Ja, und es war tatsächlich sehr schlimm. In OpenCode verunreinigt diese Situation die gesamte Sitzung, und man muss sie neu starten. Das Problem ist, dass manche Sitzungen sehr wertvoll sind. Deshalb lasse ich manchmal das Modell den aktuellen Kontext in eine Markdown - Datei komprimieren und speichern, damit ich ihn später wiederherstellen oder wiederverwenden kann.

Scott: Beobachten Sie den Kontext genau? Verwenden Sie beispielsweise Sub - Agenten zur Verwaltung?

Steve: Ich mache das nicht besonders systematisch, und es ist auch nicht perfekt. Manchmal "kommt das Modell aus dem Ruder", nachdem der Kontext komprimiert wurde, und muss neu geführt werden. Aber ich habe bemerkt, dass OpenCode in dieser Hinsicht in letzter Zeit deutlich verbessert hat.

Außerdem unterhalte ich eine Datei namens discoveries.md, um alle Probleme aufzuzeichnen, die ich während des Prozesses entdeckt habe, wie etwa Kompatibilität