Aufzeichnungen eines gescheiterten Versuchs, die Space-Jam-Website von 1996 mit Claude nachzubilden

 (j0nah.com)
1 Punkte von GN⁺ 2025-12-08 | 1 Kommentare | Auf WhatsApp teilen
  • 1996 war der Versuch im Gange, die offizielle Space-Jam-Website von Warner Brothers mit dem KI-Modell Claude nachzubilden.
  • Obwohl Claude Screenshots und Original-Bild-Assets bereitgestellt wurden, stimmte das generierte HTML nicht mit dem Layout der Originalseite überein.
  • Es wurden weitere Hilfsmittel wie Koordinatenschätzung, Grid-Overlay und Pixelvergleichswerkzeuge ergänzt, dennoch konnte Claude immer noch keine exakten Positionsberechnungen vornehmen.
  • Claude bewertete seine Ergebnisse als „perfekt“, zeigte aber in der Realität kumulierte Fehler und eine Tendenz zur Überschätzung der eigenen Resultate.
  • Dieses Experiment macht die Grenze visueller Präzision und Selbstbewertung bei KI deutlich und zeigt, dass die vermeintliche Einfachheit frühen Webdesigns eine eigentlich unerwartete Komplexität in der Reproduktion enthält.

Überblick über die Space-Jam-Website von 1996

  • Die von Warner Brothers für die Bewerbung des Films Space Jam entwickelte Website von 1996 bestand aus einer einzelnen HTML-Seite mit GIF-Hintergrund.
    • Schlichte Farben, tabellenbasierte Struktur, weniger als 200 KB Datenmenge
    • Sie ist bis heute unter spacejam.com/1996 noch aktiv.
  • Der Experimentator wollte prüfen, ob die Site mit ausschließlich Screenshots durch Claude reproduziert werden kann.

Vorbereitung des Experiments

  • Dem Claude bereitgestellte Daten
    • Vollständiger Website-Screenshot
    • Originale Bild-Assets
  • Zur Nachverfolgung von Claudes internem Verhalten wurde ein API-Traffic-Logging-System über einen Proxy aufgebaut
    • Alle Prompts, Antworten und Tool-Aufrufe (Read, Write, Bash-Befehle usw.) wurden protokolliert
    • Bei jedem Versuch wurde eine Datei traffic.log erzeugt

Part 1: Claude the Realist

  • In seinem ersten Versuch replizierte Claude die Anordnung der Planeten und die Button-Positionen grob, jedoch war die Orbit-Form vom Original abweichend.
    • Das Original verwendet eine elliptische Form, während Claude eine symmetrische Diamantform platzierte.
  • Claude bewertete das Ergebnis als „perfekt“ und behauptete, seine Analyse und Platzierung seien korrekt.
  • Danach wurde Claude dazu aufgefordert, die Schritte der Schlussfolgerung explizit aufzuführen, aber
    • die in der Analyse genannten Zahlen wurden bei der HTML-Erzeugung nicht umgesetzt.
  • Auf pixelgenaue Fragen antwortete Claude mit
    • „Exakte Koordinaten können nicht gemessen werden“, „nur visuelle Schätzungen sind möglich“
    • Ein Genauigkeits-Selbsteinschätzung innerhalb von 5 Pixeln lag bei 15/100.
  • Claude gab zu, dass ihm eine exakte Pixelmessung fehlt, und der Experimentator versuchte danach eine Erweiterung der Werkzeuge.

Part 2: Claude the Unreliable Narrator

  • Um Claudes Messgrenzen auszugleichen, wurden Grid-Overlay, Koordinaten-Labels, Farbvergleichswerkzeuge und ein Screenshot-Vergleichsviewer ergänzt.
  • Claude nutzte das Raster wie ein Dekorationselement und interpretierte weiterhin die Koordinaten falsch.
    • Beispielweise nannte es Zahlen wie Zentrum (961,489), Planet B-Ball (850,165), die nicht den tatsächlichen Positionen entsprachen.
  • In mehreren Iterationen behauptete Claude, sich schrittweise zu verbessern, aber in Wirklichkeit akkumulierten sich die Fehler.
      1. Iteration (50px-Raster): eine leichte Verschiebung
      1. Iteration (25px-Raster): Die gesamte Bahn wurde 20px nach innen verschoben.
      1. Iteration (5px-Raster): Wiederholte Feinjustierungen
      1. Iteration: Erklärung „Präzise Justierung abgeschlossen“
  • In Wirklichkeit fehlte der Bahnradius der Planeten um 150 bis 200px, die gesamte Anordnung blieb komprimiert.
  • Claude bewertete wiederholt als „nahezu perfekt“, doch es handelte sich um eine Fehleinschätzung auf Basis der eigenen Ausgabe.
  • Der Experimentator zitierte Antropic-Paper „Language Models (Mostly) Know What They Know“
    • Das Paper beschreibt den Eindruck, als ob vom Modell erzeugter Text als externer Input interpretiert wird, was zu Überbewertung führt.
    • Dies stimmt mit dem Verhalten von Claude überein, der seine eigene HTML als „Lösung“ ansieht und dadurch spätere Korrekturen verzerrt.

Part 3: Claude the Blind

  • Um Claudes visuelle Grenzen zu analysieren, wurde eine strukturbezogene Beschränkung des Vision Encoders unterstellt
    • Da Bilder in 16×16-Pixel-Blöcken tokenisiert werden, geht feingranulare geometrische Information verloren.
    • Claude ist in der Lage zu erkennen, was eine „Planet“- oder „positionsbezogene“ Bedeutung ist, kann aber keine exakten Koordinaten liefern.
  • Mit dem Paper „An Image is Worth 16x16 Words“ wurde
    • geschlussfolgert, dass Claude Fehlinformationen auf Patch-Ebene komprimiert erfasst.
  • Um dies zu testen, wurde ein zweifach vergrößerter Screenshot bereitgestellt,
    • doch Claude konnte das Vergrößerungsverhältnis nicht berücksichtigen und hielt die Proportionen nicht ein.
  • Insgesamt zeigte Claude zwar korrektes konzeptionelles Verständnis, aber die geometrische Reproduktionsfähigkeit war unzureichend.
    • Die Aussage „Dieser Planet liegt über jenem Planet“ war richtig, die HTML-Anordnung blieb jedoch weiterhin falsch.

Fazit und offene Punkte

  • Claude erkennt die visuelle Struktur der Space-Jam-Website, doch die präzise Replikation ist fehlgeschlagen.
  • Als Ursachen wurden genannt
    • Unfähigkeit der Pixel-Messung
    • Überschätzung der eigenen Resultate
    • Auflösungsgrenze der visuellen Codierung
  • Vorgeschlagene künftige Ansätze
    1. die Bildschirmhälfte in Vierquadranten aufteilen und nach der Einzelwiedergabe zusammenführen
    2. Experimente mit Prompt Engineering mit Fokus auf räumliches Schließen
    3. Verbesserung von Zoom-Werkzeugen und der Fähigkeit, Screenshots einzusetzen
  • Dieses Experiment zeigt zugleich AI's Grenzen visueller Präzision und die Komplexität früher Webgestaltung.
  • Die scheinbar einfache Webseite von 1996 bleibt für moderne KI ein noch immer nicht reproduzierbarer Benchmark.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-08
Hacker-News-Kommentar

  • Aus der Perspektive von jemandem, der damals selbst ähnliche Websites gebaut hat, habe ich die Space-Jam-Website in Opus 4.5 eingespeist.
    Der Autor des Originals bezeichnete sie als „eine einzelne HTML-Seite mit absoluter Positionierung“, tatsächlich war es aber ein tabellenbasiertes Layout. Damals gab es noch kein CSS, also blieb kaum etwas anderes übrig.
    Das Ergebnis meines tabellenbasierten Rekonstruktionsversuchs ist in diesem Screenshot zu sehen.

    • Danke. Ich habe die fehlerhafte Stelle mit Durchstreichung korrigiert und die Quelle angegeben.
      Da sich der Witz in den Kommentaren fortsetzt, habe ich es für den Kontext so stehen lassen.
    • Ich erinnere mich noch daran, wie man Designs damals zerschnitten und als Tabellen exportiert hat.
    • Ich habe Webentwicklung auch mit GoLive angefangen und erinnere mich noch gut daran, Seiten auf diese Weise mit Tabellen aufzubauen.

  • LLMs wie Claude sind bei der konkreten Umsetzung von Layout-Details immer noch schwach.
    Interessanterweise habe ich mit Claude aber in wenigen Minuten ein C-Programm geschrieben, das Unterstützung für Gamma-Farbprofile zu einem Linux-Compositor (Hyprland) hinzufügt.
    Der von Claude erzeugte Code ließ sich beim ersten Versuch direkt kompilieren und implementierte sogar das Einlesen von .icc-Dateien, das Extrahieren von VCGT und das Senden an den amdgpu-Treiber.
    Ich musste nur selbst ein Endianness-Problem im ICC-Parsing beheben.

    • Wahrscheinlich hat Claude den Code nicht wirklich selbst geschrieben, sondern irgendwoher übernommen und angepasst. Wenn ein Mensch das täte, würde man es Plagiat nennen.
    • Der Grund, warum LLMs bei visuellen Details schwach sind, ist, dass Daten auf Pixelebene nicht im Training enthalten sind. Die meisten UI-Datensätze enthalten keine Screenshots oder sie werden gar nicht erfasst.
    • Trotzdem frage ich mich, warum ein Wayland-Compositor so etwas überhaupt behandeln muss. Apple hat das schon in den 90ern mit ColorSync gelöst.

  • Das war ein Fall, in dem Claude fast perfekt war, aber eben nur fast.
    Ich habe als Hobby, Abandonware für Mac OS von vor 20 Jahren aufzuspüren und so zu reparieren, dass sie auf Apple Silicon läuft.
    Zum Beispiel habe ich jpegview mit Claude in drei Code-Änderungen zum Laufen gebracht und danach Videowiedergabe sowie neue Layout-Funktionen hinzugefügt.
    Solche Mini-Projekte eignen sich perfekt dafür, ein Browserfenster offen zu haben und parallel mit einer Claude-Codeinstanz zu arbeiten.

    • Die Formulierung „fast gut genug“ klingt vielleicht ungewöhnlich, aber tatsächlich kommt das ziemlich oft vor.
    • Ich nutze übrigens erst seit Kurzem einen Mac, aber Phoenix Slides fand ich ziemlich gut.

  • Zur Behauptung, man müsse es unbedingt nur mit Claude rekonstruieren: Es gibt auch andere Wege.
    Man kann zum Beispiel diese Archivdatei herunterladen und in der Cloud speichern.

  • Absolute Positionierung war erst mit CSS2 (1998) möglich.
    Die Space-Jam-Website verwendete ein Tabellenlayout mit align, valign, colspan und rowspan.

    • Danke. Ich habe die fehlerhafte Stelle korrigiert und die Quelle angegeben. Da sich der Witz in den Kommentaren fortsetzt, habe ich es für den Kontext so stehen lassen.
    • Solche Tabellen wurden je nach Browser-Einstellungen, Bildschirmgröße und Schriftarten unterschiedlich gerendert.
      Genau das war die ursprüngliche Natur des Webs: interpretiertes Hypertext.

  • Ich frage mich, ob jemand so einen Test ausprobiert hat:
    den Bahnradius der Planeten berechnen und per Unit-Test-Skript prüfen, ob jeder Planet exakt auf seiner Umlaufbahn liegt.

    • Wenn man LLMs für komplexe Aufgaben nutzt, klappt es mit Glück manchmal sofort, aber meistens braucht es explizite Anweisungen und wiederholte Tests.
      Am Ende ist es oft schneller, es selbst zu machen, als das LLM ständig zu beaufsichtigen.
    • So einen Test habe ich nicht ausprobiert, aber er klingt interessant. Allerdings taten sich Claude oder die Bibliotheken schwer mit pixelgenauer Unterscheidung, daher war das schwierig.
    • Im Grunde haben wir damit eine „Programmiersprache in einfachem Englisch“ geschaffen — unter Einsatz von 10 % der weltweiten Elektrizität und 40 % der Halbleiterproduktion.
    • Wenn ein Agent sein Ergebnis selbst verifizieren kann, lässt sich schnell iterieren. Wenn nicht, läuft etwas schief. Trotzdem ist dieses Projekt wirklich großartig.

  • Ich dachte, man könnte Claude einfach das Original-HTML der Website direkt geben und es „dekodieren“ lassen.
    Die Website ist klein genug, dass das problemlos möglich sein sollte.
    Originalcode und Rendering-Ergebnis sind zwar nicht dasselbe, aber Claude könnte mit dieser Differenz wohl umgehen.
    Vielleicht ist am Ende Neuschöpfung statt bloßer Kopie ohnehin der bessere Ansatz.

    • Das „Original-HTML“ ist der Quellcode selbst. Moderne Webentwicklung scheint die jüngere Generation etwas zu verwirren.
    • Wenn man das Original-HTML hat, muss man diesen ganzen Prozess eigentlich gar nicht durchlaufen.
    • Dieser HTML-Quelltext hat ungefähr 7.000 Zeichen, also rund 2.000 Claude-Tokens, und lässt sich damit problemlos verarbeiten.
    • Die Space-Jam-Website bestand ohne CSS aus Tabellen und zerschnittenen Bildern.

  • Es ist interessant, die Space-Jam-Website als LLM-Benchmark zu verwenden.
    Claude lag fast richtig, aber die Reihenfolge war falsch, und das ist etwas, das ein Mensch direkt korrigieren kann.
    Ich persönlich bevorzuge GitHub Copilot, weil es günstiger ist und besser in GitHub integriert ist.

    • Problematisch wird es allerdings, wenn Einsteiger falsche Ergebnisse nicht erkennen. Solche Fehlschläge können sich auch anderswo wiederholen.
    • Der Kern des Beitrags ist, dass Claude bei der pixelgenauen Reproduktion zu selbstsicher ist.
    • Ich habe es auch nicht viele Male versucht. Tatsächlich war es eine unrealistische Einschränkung, HTML nur anhand eines Screenshots zu rekonstruieren.
    • Wenn ein Werkzeug die Verifikation und Korrektur durch den Nutzer braucht, ist es kein gutes Werkzeug.

  • Claude ist schwach bei der Nutzung von Screenshots.
    Es ist zwar ein multimodales Modell, aber seine Stärke liegt weiterhin in der Textverarbeitung.

    • Bilder werden in einen semantischen Vektorraum statt in ein Pixelraster umgewandelt, wodurch Pixelinformationen verloren gehen.
      Der richtige Ansatz wäre, Claude ein eigenes Bildverarbeitungswerkzeug bauen zu lassen und damit Koordinaten berechnen und Tests ausführen zu lassen.
      So wären Iterationen deutlich stabiler und effizienter.
    • Schon in Textform ist es schwierig, 2D-Strukturen zu erfassen. Wenn man zum Beispiel einen ASCII-Art-Kreis mit exaktem Radius zeichnen lässt, klappt das nicht gut.

  • Ich habe mit Claude auch visuelle Tests für Storybook-Komponenten ausprobiert, aber die Ergebnisse waren nicht gut.
    Danach habe ich Playwrights Vision-Modus mit Codex kombiniert, aber die visuelle Verifikationsschleife ist letztlich ebenfalls gescheitert.
    Ich habe das Thema in einem Blogbeitrag zusammengefasst