Vibe Code Bench: Evaluating AI Models on End-to-End Web Application Development

Die Studie stellt mit „Vibe Code Bench" einen neuen Benchmark für die End-to-End-Entwicklung von Webanwendungen vor, der zeigt, dass selbst die besten aktuellen KI-Modelle bei der vollständigen Erstellung funktionsfähiger Apps noch erhebliche Schwierigkeiten haben und dabei die Bedeutung von Selbsttests sowie die Auswirkungen der Evaluatoren-Auswahl auf die Ergebnisse aufdeckt.

Das Wesentliche

Stellen Sie sich vor, Sie geben einem hochintelligenten, aber noch etwas unerfahrenen Koch eine einzige, knappe Zutat: eine Idee für ein Gericht. Ihre Aufgabe ist es nicht, ihm nur zu sagen, wie man Eier kocht (ein isolierter Schritt), sondern ihn zu bitten, das gesamte Restaurant zu eröffnen – vom Kauf der Zutaten über das Kochen, das Servieren bis hin zum ersten zufriedenen Gast, der die Rechnung bezahlt.

Genau das ist die Herausforderung, die das Papier "Vibe Code Bench" untersucht. Hier ist eine einfache Erklärung der wichtigsten Punkte:

1. Das Problem: Der "Einzel-Test" reicht nicht

Bisher haben wir KI-Modelle getestet, indem wir ihnen kleine Aufgaben stellten, wie "Schreibe eine Funktion, die zwei Zahlen addiert". Das ist wie ein Koch, der nur weiß, wie man Eier brät.
Aber die wahre Magie der KI ("Vibe Coding") verspricht, dass man ihr einfach sagt: "Baue mir eine App, mit der ich meine Ausgaben tracken kann", und sie baut alles selbst.
Das Problem: Bisher gab es keinen Test, der prüfen konnte, ob die KI das ganze Restaurant eröffnen kann. Konnte sie die Website bauen? Konnte sie die Datenbank einrichten? Konnte sie sicherstellen, dass der Benutzer sich anmelden kann? Die alten Tests sagten uns das nicht.

2. Die Lösung: Vibe Code Bench (Der "Koch-Wettbewerb")

Die Autoren haben einen neuen Wettbewerb namens Vibe Code Bench erfunden.

• Die Aufgabe: 100 verschiedene Ideen für Web-Apps (z. B. "Eine App, um Parkplätze zu finden" oder "Ein Tool für kleine Unternehmen").
• Die Prüfung: Die KI muss die App von Grund auf neu programmieren, in einer sicheren Umgebung (einem "Sandkasten"), und sie muss so funktionieren, als wäre sie für echte Menschen gemacht.
• Der Prüfer: Hier kommt das Geniale: Die App wird nicht von einem Menschen geprüft, sondern von einem autonomen Roboter-Browser. Dieser Roboter klickt sich durch die App, genau wie ein echter Nutzer. Er meldet sich an, kauft etwas, schreibt Kommentare und prüft, ob alles klappt. Wenn der Roboter hängen bleibt, ist die App gescheitert.

3. Die Ergebnisse: Die KI ist gut, aber noch nicht perfekt

Der Wettbewerb wurde mit 16 der fortschrittlichsten KI-Modelle der Welt durchgeführt.

• Der Gewinner: Das beste Modell (GPT-5.3-Codex) hat es geschafft, etwa 62 % der Aufgaben fehlerfrei zu lösen. Das klingt gut, bedeutet aber auch, dass fast jede zweite App nicht richtig funktioniert.
• Die Erkenntnis: Die KI kann Code schreiben, aber sie kann noch nicht zuverlässig ein komplettes, funktionierendes Produkt bauen. Es ist immer noch ein "Frontier"-Problem (ein Grenzgebiet), das viel Forschung erfordert.

4. Der geheime Erfolgsfaktor: "Selbst-Testen"

Eine der spannendsten Entdeckungen des Papiers ist, wie die erfolgreichen KIs gearbeitet haben.

• Die "Besserwisser"-KI: Die Modelle, die gut abgeschnitten haben, haben nicht nur geschrieben und fertig. Sie haben sich selbst getestet! Sie haben die App im Browser geöffnet, haben Fehler gefunden, haben sie behoben und es nochmal probiert.
• Die "Schnelle" KI: Modelle, die nur schnell Code geschrieben haben, ohne ihn zu prüfen, haben oft versagt.
• Die Analogie: Es ist wie beim Lernen für eine Prüfung. Der Schüler, der nur die Antworten auswendig lernt (Code schreiben), macht Fehler. Der Schüler, der Probeklausuren schreibt, prüft, wo er hakt, und lernt daraus (Selbst-Testen), besteht die Prüfung viel besser.

5. Das Problem mit den Prüfern

Das Papier zeigt auch, dass es darauf ankommt, wer die Prüfung macht.

• Wenn man verschiedene KI-Modelle als Prüfer nimmt, bewerten sie die Arbeit manchmal völlig unterschiedlich. Ein Modell sagt "Perfekt", ein anderes sagt "Müll".
• Das ist wie bei einem Kunstwettbewerb, bei dem ein Juror "Modern" mag und ein anderer "Klassisch". Die Autoren haben gezeigt, dass man sehr vorsichtig sein muss, welche KI man als Richter einsetzt, da dies das Ergebnis massiv verändert.

Zusammenfassung

Das Papier sagt uns im Grunde: KI kann bereits erstaunlich gut Code schreiben, aber sie ist noch nicht bereit, als alleiniger Software-Ingenieur ein komplettes Geschäft zu eröffnen.

Es braucht noch viel Übung, vor allem die Fähigkeit, die eigene Arbeit kritisch zu prüfen und zu korrigieren ("Selbst-Testen"). Der "Vibe Code Bench" ist nun der neue Maßstab, um zu messen, wie weit wir auf dem Weg zu einer KI gekommen sind, die uns wirklich den ganzen Tag lang das Programmieren abnimmt.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Vibe Code Bench: Evaluating AI Models on End-to-End Web Application Development" auf Deutsch:

1. Problemstellung

Das Paper adressiert eine kritische Lücke in der aktuellen Bewertung von KI-Modellen im Bereich der Code-Generierung.

• Aktueller Stand: Bestehende Benchmarks (wie HumanEval, SWE-Bench oder LiveCodeBench) testen meist isolierte Aufgaben (z. B. das Erstellen einzelner Funktionen, das Beheben von Bugs in existierenden Codebasen oder das Lösen von Algorithmus-Problemen).
• Die Lücke: Es fehlt ein Standard-Benchmark, der die Fähigkeit von Modellen misst, eine komplette, einsatzbereite Webanwendung („Zero-to-One") ausschließlich aus einer natürlichen Sprachbeschreibung zu erstellen. Dies umfasst Multi-File-Code, Konfiguration, Deployment, Integration externer Dienste (z. B. Zahlung, E-Mail) und funktionierende Benutzer-Workflows.
• Motivation: Das Ziel des „Vibe Coding" ist es, nicht-technischen Nutzern zu ermöglichen, ganze Anwendungen aus Textanweisungen zu bauen. Bisherige Tests messen nicht, ob diese Vision zuverlässig funktioniert.

2. Methodik: Vibe Code Bench (VCB)

Die Autoren stellen Vibe Code Bench vor, ein umfassendes Evaluierungsframework, das aus drei Hauptkomponenten besteht:

A. Datensatz und Aufgabenstellung

• Umfang: 100 realistische Spezifikationen für Webanwendungen, aufgeteilt in einen öffentlichen Validierungsdatensatz (50 Aufgaben) und einen zurückgehaltenen Testdatensatz (50 Aufgaben).
• Kategorien: Die Aufgaben decken drei Domänen ab:
  1. Individual: Persönliche Apps (z. B. Habit-Tracker).
  2. Solo Founder: Apps für Startups (oft mit einfacher Authentifizierung).
  3. Enterprise Tool: Interne Business-Tools (mit komplexen Rollen und Hierarchien).
• Komplexität: 28 % der Aufgaben erfordern die Integration externer Dienste (Stripe für Zahlungen, MailHog für E-Mails), um reale Produktionsanforderungen zu simulieren.
• Tests: Jede Spezifikation ist mit 6 bis 23 automatisierten Browser-Workflows verknüpft (insgesamt 964 Workflows, 10.131 Einzelschritte).

B. Generierungs-Harness (Umgebung)

• Infrastruktur: Basierend auf einer modifizierten Version von OpenHands.
• Sandbox: Jedes Modell erhält einen isolierten Container mit Zugriff auf Terminal, Browser und vorkonfigurierte Dienste (Supabase als Backend, Stripe, MailHog).
• Rahmenbedingungen:
  • Zeitlimit: Bis zu 5 Stunden pro Anwendung.
  • Tech-Stack: Erzwingt einen konsistenten Stack (React + Vite, Tailwind CSS, Supabase), um Vergleichbarkeit zu gewährleisten.
  • Deployment: Die Anwendung muss per Docker Compose lauffähig sein.
  • System-Prompt: Enthält detaillierte Anweisungen zu Best Practices, Sicherheit und dem Verbot von Mocks (echte API-Aufrufe sind erforderlich).

C. Automatisierte Evaluierungspipeline

• Agent: Ein autonomer Browser-Agent (Browser Use) führt die Tests durch.
• Ansatz: Im Gegensatz zu Unit-Tests oder DOM-Checks bewertet der Agent die Anwendung aus Nutzerperspektive (Klicken, Navigieren, Eingabe). Dies ist technologieagnostisch und robust gegenüber UI-Änderungen.
• Bewertungskriterium: Ein Workflow gilt als bestanden, wenn ≥ 90 % der Einzelschritte (Substeps) erfolgreich abgeschlossen werden. Die Genauigkeit einer Anwendung ist der Prozentsatz der bestandenen Workflows.

3. Wichtige Beiträge

1. Neuer Benchmark-Datensatz: Der erste Benchmark, der den gesamten Prozess von der Text-Spezifikation bis zum deployten Web-App-Artifakt testet.
2. Umfassende Evaluation: Testung von 16 führenden Modellen (sowohl Closed- als auch Open-Weight) mit Analyse von Kosten, Latenz und Fehlern.
3. Evaluierungs-Alignment: Eine Studie zur Übereinstimmung zwischen KI-Evaluatoren und menschlichen Bewertern, die zeigt, dass die Wahl des Evaluators die Ergebnisse massiv beeinflusst.
4. Reproduzierbarkeit: Bereitstellung aller Artefakte, Trajektorien und Skripte.

4. Ergebnisse und Erkenntnisse

Leistung der Modelle

• Top-Ergebnis: Das beste Modell (GPT-5.3-Codex) erreicht eine Genauigkeit von 61,8 % auf dem Testset.
• Spannweite: Die Leistung variiert stark. Während Top-Modelle über 50 % liegen, erreichen einige Modelle (z. B. Grok 4.1, DeepSeek V3.2) Werte unter 5–10 %.
• Vergleich zu SWE-Bench: VCB ist deutlich diskriminierender. Während die Lücke zwischen Top-Modellen auf SWE-Bench nur 2,8 % beträgt, beträgt sie auf VCB 42,7 %.

Kosten und Latenz

• Es gibt einen Trade-off zwischen Kosten/Latenz und Genauigkeit, jedoch mit abnehmenden Grenznutzen.
• Beispiel: Claude Opus 4.6 erreicht fast die gleiche Genauigkeit wie GPT-5.3-Codex, aber zu deutlich niedrigeren Kosten und geringerer Latenz.

Tool-Nutzung und Verhalten

• Selbst-Testing ist entscheidend: Es besteht eine starke positive Korrelation (Pearson r = 0,72) zwischen der Nutzung des Browser-Tools zur Selbsttestung während der Generierung und dem Endergebnis.
• Edit-Volumen irrelevant: Die reine Anzahl der Code-Änderungen korreliert kaum mit dem Erfolg (r = 0,09). Es kommt auf die Qualität des iterativen Testens und Reparierens an.
• Fehlermuster: Die häufigsten Fehler sind fehlende Features (46,7 %) und Authentifizierungsprobleme (20,4%). Vollständige Startfehler sind bei Top-Modellen selten.

Evaluierungs-Alignment

• Die Wahl des Evaluators ist kritisch. Menschliche Bewerter stimmen untereinander zu 88–93 % überein.
• KI-Evaluatoren zeigen jedoch große Diskrepanzen: Claude Sonnet 4.5/4.6 stimmen stark mit Menschen überein, während GPT-5.2 als Evaluierer nur eine Übereinstimmung von ca. 36 % aufweist.

5. Bedeutung und Fazit

Das Paper zeigt, dass zuverlässige End-to-End-Entwicklung von Software durch KI noch ein offenes Forschungsproblem ist. Auch die besten Modelle scheitern in fast 40 % der Fälle daran, eine vollständig funktionierende App zu liefern.

• Paradigmenwechsel: Der Fokus muss sich von der Generierung einzelner Code-Schnipsel hin zu agenticem Verhalten (Planung, Selbsttest, Iteration, Deployment) verschieben.
• Praxisrelevanz: Der Benchmark liefert einen realistischen Maßstab für den Einsatz von KI in der Softwareentwicklung, insbesondere für den Aufbau neuer Anwendungen aus dem Nichts.
• Zukunft: Die Autoren betonen, dass die Frage nicht mehr lautet „Kann KI Code schreiben?", sondern „Kann KI Software bauen?". VCB dient als Referenzpunkt für den Fortschritt in diesem Bereich.

Einschränkungen: Der Benchmark konzentriert sich ausschließlich auf Webanwendungen (React/Supabase) und bewertet nicht Code-Qualität, Sicherheit oder Wartbarkeit, sondern nur die funktionale Korrektheit aus Nutzersicht.