Vibe Coding

Gestern habe ich Claude eine harmlose Frage gestellt: „Kannst du auch Game-Engines programmieren?" Heute läuft auf playground.pyground.de ein 3D-Modell meiner Heimatstadt im Browser. 40.000 Gebäude mit echten Dachformen, Brücken die nicht mehr in die Saar sacken, Saarbahnen die an Stationen halten, LKW mit Lieferaufträgen, Stimmungen die kippen wenn der Verkehr stockt. Single-File HTML, ein paar Python-Skripte für Daten-Bake, kein Build-Tooling. Alles im Browser.

Der ganze Code wurde von Claude geschrieben. Ich habe keine einzige Zeile selbst getippt. Was ich gemacht habe, hat Andrej Karpathy ein paar Monate vorher Vibe Coding getauft — ich hab dem Modell Anweisungen in natürlicher Sprache gegeben und es einfach machen lassen.

Wie sich das anfühlt, wann es funktioniert, wann nicht — darum geht's hier.

Was Vibe Coding ist

Karpathys Begriff aus Februar 2025: man gibt der KI grobe Anweisungen ("die Stadt ist mir zu grün, mach mal Asphalt wo Asphalt sein sollte"), schaut sich kurz an was rauskommt, korrigiert nach Gefühl ("nee zu dunkel, das ist Autobahn nicht Tiefgarage") und akzeptiert den Rest blind. Man liest den Code nicht zwingend, man inspiziert das Resultat. Bug-Suche heißt: Screenshot machen, Stelle einkringeln, zurück an die KI.

Das funktioniert nur deshalb, weil Modelle wie Claude inzwischen lange Codestrecken schreiben können, ohne sich selbst zu widersprechen, und weil sie genug Kontext halten um nach 50 Iterationen noch zu wissen was sie vor einer Stunde gemacht haben.

Was hier passiert ist

Stand jetzt hat das Projekt: - 40.336 Gebäude mit aus Luftbildern extrahierten echten Dachfarben und detektierten Dachformen (Sattel-, Walm-, Pyramiden-, Flachdach) - 31.663 Wege mit korrektem Brücken-Höhenprofil und Auffahrt­rampen, die per iterativer Höhenpropagation aus den OSM-Knoten-Verbindungen abgeleitet werden - Sportplätze mit echten Linien — Fußballfeld mit Mittelkreis und Strafräumen, Tennis-Court mit Aufschlaglinien, Basketball mit Zone - Verkehrssimulation mit ~150 Agenten: Autos halten Abstand (IDM-Light), Ampeln aus OSM-Daten regeln Kreuzungen, Saarbahn (gelb) hält an tram_stop, RE (rot) an Stationen, Güterzug fährt durch, LKW und Boote bekommen Aufträge zwischen Industriegebieten und Häfen - Pre-gerendertes Backdrop für die 18×18 km Außenfläche — Python rastert OSM-Daten in unsere eigene Farbpalette und backt eine 1.8 MB JPEG-Textur, die als Map-Untergrund unter dem 3D-Detailbereich liegt - Friedhöfe und Parks mit gestreuten 3D-Bäumen (~9000 Stück, alle als zwei InstancedMesh — eine für Stämme, eine für Kronen) - Stimmungssystem — wenn ein LKW im Stau steht, wird seine Farbe langsam dunkler-rot

Live ausprobieren — Klick auf einen Agenten zeigt seinen aktuellen Auftrag, ETA und Stimmung.

Wie sich das angefühlt hat

Einen Abend lang habe ich Claude mit Sachen wie diesen gefüttert:

„Friedhöfe sind als solche schwer zu erkennen. Sie werden zu grau dargestellt. Hast du Ideen, wie wir sie besser erkennbar machen. Einzelne Gräber sind zu klein. Friedhöfe sind in der Regel ja parkähnlich."

Antwort: 60 Zeilen Code für InstancedMesh-Bäume, die im Polygon verteilt werden, mit Höhen-Sampling auf dem Terrain-Mesh. Auf den ersten Klick funktionierte es nicht — die Bäume waren da, aber unsichtbar. Drei.js cullt InstancedMesh nach der Bounding-Sphere der Basis- Geometrie, nicht nach den Instanzen. Die ist klein und sitzt am Welt-Ursprung. Die Instanzen liegen kilometerweit verstreut. Frustum sieht: leer. → Cullen.

Eine frustumCulled = false-Zeile später: 914 Bäume sichtbar.

Solche Edge-Cases habe ich keine Sekunde selbst gesucht. Ich hab geschrieben „ich sehe keine Bäume" und Claude hat nach kurzem Hin- und-Her den richtigen Three.js-Bug aus dem Hut gezogen.

Ein anderes Mal hatte die Wilhelm-Heinrich-Brücke 25 OSM-Way-Segmente mit teils fehlenden Tags. Auffahrtsrampen ohne bridge=yes sackten in die Saar, weil der Höhensampler dort die Wasseroberfläche traf statt die Bank. Ich habe mehrere Versuche kommentiert („noch immer ein Sprung in der Mitte", „jetzt zu steil", „warum dreht der LKW da im Kreis") — Claude hat nach drei Iterationen eine iterative Slope-Decay-Propagation gebaut, die Höhe entlang verbundener Ways weitergibt. Funktioniert. Vorher in OSM-3D-Renderern hab ich so was noch nie sauber gesehen.

Was schief gegangen wäre, ohne Korrekturen

Der naive Versuch, alles auf einmal beschreiben zu lassen, hätte nicht funktioniert. Claude hätte sich in Annahmen verrannt, ich hätte am Ende Code gehabt der nicht das tut was ich will. Stattdessen: winzige Schritte. Sofort visuell verifizieren. Bei Abweichung zurückspielen.

Beispiele: - „Beim nahen Ranzoomen scheint da jetzt was durch." — JPEG-Artefakte aus der Backdrop-Textur. Inneren Detailbereich der Textur mit weicher Maske auf solid green setzen → weg. - „Ich sehe keine LKW mehr." — 914 LKW geriet in einen spawn-Edgecase weil meine geänderte Klassen-Whitelist sie aus dem Strom verbannt hat. - „Der Kontrast am Übergang ist sichtbar." — Innen 3D-gelitete Polygone, außen unbeleuchtete Textur. 15% Helligkeits-Anhebung im Bake angeglichen.

Ohne diese ständige Kontrollschleife gewinnt der Bullshit-Compounding- Effekt: die KI baut auf falschen Annahmen weiter, Fehler kaskadieren, am Ende ist eine Stunde Arbeit Müll.

Wann es nicht klappt

Drei Sachen, an denen ich gescheitert bin:

1. Architektur-Entscheidungen ohne klare Vorgabe. Als ich gefragt habe „soll die Simulation auf Server oder Client laufen?" hat Claude beides gleichermaßen vorgeschlagen, mit nüchterner Trade-off-Analyse. Aber die Entscheidung musste ich treffen — keine KI weiß, ob ich Multi-User-Sharing will oder nicht.
2. Wenn der Bug nicht visuell ist. Performance-Tuning, Memory- Leaks, race conditions — da hilft Vibe Coding wenig, weil ich nicht sehe was schief läuft. Ich muss Profiles lesen oder Logs filtern. Macht zwar Claude auch, aber ich muss die richtige Frage stellen.
3. Bei wirklich originellen Ideen. Sport-Linien-Erkennung mit eigener Geometrie-Heuristik (Min-Area-Bounding-Box per Rotating Calipers, weil PCA scheitert) — den Sprung dahin hat nicht Claude gemacht, sondern ein Hin-und-Her wo ich Ideen vorgeschlagen habe und Claude die schlechte verworfen hat.

Für wen lohnt sich das

Ich glaube nicht, dass Vibe Coding klassisches Coden ersetzt. Aber für Prototypen, Spielprojekte, Visualisierungen — alles wo das Ergebnis zählt und nicht der Code-Pfad — funktioniert es absurd gut. Einen Tag für ein Projekt, für das ich allein deutlich länger gebraucht hätte und das ich vermutlich vor dem ersten Zwischenresultat entnervt abgebrochen hätte.

Gleichzeitig: ich verstehe einen Großteil des Codes nicht im Detail. Wenn morgen Three.js auf v200 springt und alles bricht, weiß ich nicht spontan, was zu tun ist — ich frage Claude. Das ist eine Abhängigkeit. Ich bin damit OK; vielleicht bist du es nicht.

Code

Single-File index.html mit ~4000 Zeilen, plus eine Handvoll Python-Skripte für Daten-Bake (Dachfarben aus DOP, Backdrop-Textur, Daten-Optimierung). Keine Build-Pipeline. Browser öffnen, läuft.

→ Live-Demo: playground.pyground.de