7 Punkte von GN⁺ 2026-01-29 | 4 Kommentare | Auf WhatsApp teilen
  • Ein Browser, der HTML und CSS rendern kann, wurde in nur 3 Tagen von einer Person und einem LLM-Agenten direkt in Rust implementiert
  • Das Projekt wurde mit rund 20.150 Zeilen Code fertiggestellt und enthält grundlegende Funktionen wie Scrollen, Zurück-Navigation und Headless-Modus
  • Es wurde so konzipiert, dass es ohne externe Rust-Bibliotheken unter Windows, macOS und Linux läuft
  • Der Entwicklungsprozess erfolgte in Zusammenarbeit mit dem Codex-Agenten: Der Mensch übernahm Koordination und Verifikation, der Agent das Schreiben des Codes
  • Das Ergebnis zeigt, dass die Kombination „eine Person + ein Agent“ effizienter ist als eine Vielzahl von Agenten

Projektüberblick

  • Das Ziel war, einen grundlegenden Browser, der HTML und CSS rendern kann, vollständig von Grund auf neu zu bauen
    • JavaScript wird nicht unterstützt
    • Der Entwickler begann „zum Spaß“ und setzte das Projekt in Zusammenarbeit mit dem LLM-Agenten (Codex) um
  • Es wurden Rahmenbedingungen wie Fertigstellung innerhalb von 3 Tagen, Verbot externer Rust-Abhängigkeiten und Unterstützung für die drei großen Betriebssysteme gesetzt
  • Der Browser verfügt über eine eigene Rendering-Engine und enthält Screenshot-Funktion, Link-Klicks und Regressionstests

Tag 1 – Erste Implementierung

  • Gestartet wurde mit dem Rendern von „Hello World“, danach kamen die Verarbeitung verschachtelter Tags und eine Screenshot-Funktion hinzu
  • Die HTML/CSS-Spezifikation wurde definiert, und für E2E-Tests wurde eine Bildvergleichsfunktion eingeführt
  • Schon nach einem Tag war der Stand erreicht, Websites per X11 und cURL abzurufen und zu rendern
    • Die Codebasis umfasste etwa 7.500 Zeilen, alle Dateien blieben unter 1.000 Zeilen

Tag 2 – Funktionsausbau

  • Um das Problem sich während der Tests öffnender Fenster zu lösen, wurde ein --headless-Modus hinzugefügt
  • Fenstergrößenanpassung, Kompatibilität, Performance und Schrift-Rendering wurden verbessert
  • Der Workflow bestand darin, Screenshots von Websites zu teilen und Codex diese nachbilden zu lassen
    • Den Großteil des Codes schrieb der Agent, der Mensch war für Prüfung und Freigabe zuständig

Tag 3–4 – Fertigstellung und plattformübergreifende Unterstützung

  • Wesentliche Browserfunktionen wie Scrollen, Debug-Logs und Zurück-Button wurden ergänzt
  • Unterstützung für macOS und Windows wurde implementiert und die Tests bestanden
  • CI-Integration und Release-Builds wurden abgeschlossen, die gesamte Entwicklungszeit betrug rund 72 Stunden

Ergebnis und Code-Statistiken

  • Die finale Codebasis besteht aus rund 20.150 Zeilen in 72 Dateien
  • Zu den zentralen Dateien gehören Module wie layout, style, platform und browser
  • Cargo.lock ist leer, das heißt: vollständig eigenständig lauffähig ohne externe Rust-Pakete
  • Auf GitHub können CI-gebaute Binärdateien und der Quellcode direkt heruntergeladen werden

Zentrale Erkenntnisse

  • Die Kombination „eine Person + ein Agent“ ist effizienter als der Einsatz von Tausenden Agenten
  • Ein einzelner Agent kann über längere Zeit an einer Codebasis arbeiten und dabei echte Fortschritte erzielen
  • Es gibt Potenzial zur Skalierung in einer Form, bei der mehrere Menschen jeweils ihren eigenen Agenten haben
  • Langsamer zu werden kann paradoxerweise zu schnelleren und besseren Ergebnissen führen
  • Die Rolle des Menschen, der den Agenten steuert, könnte wichtiger sein als das Systemdesign
  • Insgesamt ist dies ein Beispiel dafür, dass auf die Frage „Beschleunigt sich Entwicklung, wenn man mehrere Agenten einsetzt?“
    die Zusammenarbeit zwischen einem einzelnen Menschen und einem einzelnen Agenten realistischer und effizienter sein könnte

4 Kommentare

 
pkj3186 2026-01-29

Ich kenne mich damit nicht so gut aus, aber was für ein Blog ist der in den Hacker-News-Kommentaren erwähnte Simons Blog, dass er ständig zur Sprache kommt ...?

 
laeyoung 2026-01-29

Der Grund, warum der von Simon Willison veröffentlichte Blogbeitrag auf Hacker News wahrscheinlich so oft erwähnt wird, ist wohl,

  1. dass es Gründe dafür gibt, warum er viele KI-bezogene Texte gut und schnell schreibt. Auch das beim Testen von KI-Leistung oft genutzte Zeichnen eines „Pelikan auf einem Fahrrad“ scheint dieser Herr als Erster gemacht zu haben (https://simonwillison.net/search/?q=pelican)
  2. dass er der Schöpfer von Django ist und daher auch einen gewissen Bekanntheitsgrad hat.
 
qyurila 2026-01-29

Das ist wohl der Blog, der in den 2025 auf Hacker News beliebtesten Blogs auf Platz 1 lag. Sein Ruf spielt sicher eine Rolle, aber auch die große Zahl veröffentlichter Artikel – für normale Hacker-News-Nutzer ist er vermutlich der Blog, den sie am häufigsten besuchen, und wird dadurch ganz natürlich als eine Art Maßstab wahrgenommen.

 
GN⁺ 2026-01-29
Hacker-News-Kommentare
  • Ich denke, das ist eine deutlich bessere Demo für einen codegenerierenden Browser als Cursors FastRender
    Mit rund 20.000 Zeilen Rust ist er viel kleiner, nutzt für Bild- und Textrendering nur Systembibliotheken, und der Code ist gut lesbar
    Zum Beispiel ist der Code für die Flexbox-Implementierung sehr klar
    Ich habe auch einen Screenshot gepostet, auf dem mein Blog gerendert wird; CSS-Verläufe und SVG-Icons funktionieren gut, PNGs jedoch nicht
    Ich dachte, ein Browser für HTML+CSS-Rendering wäre die perfekte Aufgabe für eine Demo mit parallelen Agenten, aber es überrascht mich, dass es sogar mit nur einem Coding-Agenten möglich war

    • Aus Engineering-Sicht halte ich das für ein deutlich ausgereifteres Design als Cursors Browser
      Entscheidend ist nicht einfach, viele Token zu verbrauchen, sondern Agenten effektiv einzusetzen
      Ich habe selbst schon oft Projekte erzeugt, die nach ein paar Tagen liegen geblieben sind. Agenten tun ohne Feedback nur das, was man ihnen sagt; wenn die Richtung falsch ist, graben sie das Loch eher noch tiefer
    • Ich denke, die Zusammenarbeit zwischen Mensch und Agent macht den entscheidenden Unterschied
      Selbst wenn Claude in eine falsche Richtung läuft, kann man sich mit der richtigen Agentenstruktur wieder erholen
      Ich experimentiere derzeit damit, Evaluator-, Researcher- und Implementer-Agenten zu trennen
      Sie erweitern Tests auf Basis von Bewertungen oder untersuchen Ursachen für Fehlschläge, und wenn es keine Verbesserung gibt, wird der Commit verworfen
      So eine Struktur ist für das Management der Codequalität viel vorteilhafter
      In einer Zeit, in der Code billig und wegwerfbar geworden ist, muss sich der Workflow selbst ändern
    • Beeindruckend ist, dass embedding-shapes das direkt eigenhändig gebaut hat
      Es wirkt wie eine „David gegen Goliath“-Geschichte, in der 1 Mensch + 1 Agent einen Browser im Wert von 5 Millionen Dollar und mit 1,6 Millionen LOC schlägt
      AI ist weiterhin eine Black Box, und alle experimentieren noch, um die Richtung zu finden
      2026 ist jetzt erst einen Monat alt, und ich finde spannend, welche Experimente noch kommen werden
      Es wäre interessant, wenn Simon den HN-Thread zu den Vorhersagen für 2026 regelmäßig reviewen würde
  • Man setzte die Regel, ein Limit von 3 Tagen einzuhalten und ohne Rust-Third-Party-Crates nur mit den Standardbibliotheken des OS X11/Windows/macOS zu unterstützen
    Fertiggestellt wurde es mit etwa 20.000 LOC, davon 14.000 Zeilen für die Engine und 6.000 Zeilen für den Plattform-Support
    Der Source Code und die Binärdateien wurden veröffentlicht

    • Als ich vor 20 Jahren zu KHTML/konqueror beigetragen habe, dauerte schon die Implementierung des grundlegenden Renderings mehrere Monate
      Heute ist das dank maschinenlesbarer Test-Suites viel effizienter
      Früher war das Verhalten des IE de facto der Standard, aber jetzt ist es durch Beiträge von Google, Apple usw. zur Standardisierung viel besser geworden
    • Ich frage mich, welches Modell verwendet wurde und wie hoch die Token-Kosten waren
    • Hervorragende Einschränkungen
  • Unabhängig von der Funktionalität interessiert mich ein Sicherheitsaudit für so eine Codebasis
    Rust hilft sicher, aber ich frage mich, ob Sprachgarantien allein ausreichen

    • Sicherheit wurde überhaupt nicht berücksichtigt. Ohne Sandbox ist es riskant, beliebige Websites zu öffnen
      Rust verhindert nur grundlegende Speicherfehler, blockiert aber nichts wie den Zugriff auf lokale Dateien
      Da es keine JS-Engine gibt, ist Datenexfiltration schwierig, aber bei einem Audit würden wohl mehrere schwerwiegende Schwachstellen auftauchen
  • Die Community hat auf browserBench gewartet, und ich freue mich, dass es nun endlich losgeht
    Browser gehören zu den komplexesten Softwarearten überhaupt, daher werden solche Versuche ein Referenzpunkt zur Bewertung von Grenzen sein

  • Einen Browser mit 20.000 Zeilen zu bauen, kann ich mir kaum vorstellen
    Allein zlib hat schon 12.000 Zeilen, daher wirkt es, als würde etwas fehlen
    Ich frage mich, ob einfach nur OS-Rendering-Aufrufe gemacht werden

    • Unter Linux werden 78 dynamische Bibliotheken für X11, glib, Grafikformate, Kryptografie usw. gelinkt
    • Es gibt keine Rust-Abhängigkeiten, stattdessen werden die Standard-Frameworks des OS verwendet
      Welche Bibliotheken genutzt werden, steht im README
  • Als ich es ausgeführt habe, wirkte das Rendering ziemlich chaotisch
    Linkfarben und Unterstreichungen sind inkonsistent, und unter Windows funktioniert der Zurück-Button nicht
    Trotzdem rendert es die HN-Startseite oder Simons Blog ziemlich gut

    • Dieser Browser ist weniger ein eigenständiges Produkt als vielmehr ein Antwortprojekt auf Cursors Beitrag scaling-agents
      Das Ziel war, mit weniger LOC ähnliche Funktionen zu implementieren
      Es gibt kein Standard-Stylesheet, deshalb sind die Linkfarben nicht einheitlich
      Unter Windows 11 funktioniert der Zurück-Button. Falls du Windows 10 nutzt, könnte das die Ursache sein
  • Das Rendern von Simons Blog wird wohl zum repräsentativen Ziel für AI-Browser
    Aber bislang ist das eher ein Renderer als ein echter Browser
    Eindrucksvoller wäre es, wenn AI in Projekten wie Servo die Implementierung von APIs ergänzen würde

    • Stimme zu. Für einen Browser reicht das nicht, er kann nicht einmal einfaches HTML richtig rendern und crasht oft
      Trotzdem ist es besser als Cursors Versuch, und dass es kompiliert, ist immerhin ein minimaler Fortschritt
  • Ich frage mich, wie lange es gedauert hätte, wenn er es allein gemacht hätte
    Um die Hilfe des Agenten zu verstehen, würde ich gern wissen, wie tief die Expertise war, die in diese Anleitung eingeflossen ist

    • Allein wäre es wahrscheinlich unmöglich gewesen
      Ich kenne Rust, aber nicht X11 oder die APIs von macOS und Windows, daher wäre schon der Einstieg schwer gewesen
      Allerdings haben meine Erfahrungen mit Tests, Infrastruktur und Design bei der Zusammenarbeit mit dem Agenten geholfen
    • Mit dem sloccount-Tool nachgerechnet
      wird dieses Projekt für das Jahr 2000 auf 4,58 Personenjahre und 610.000 Dollar geschätzt,
      für 2025 dagegen auf 5,6 Jahre und 1,38 Millionen Dollar
  • Interessant an diesem Beitrag ist nicht das Ergebnis, sondern der Fokus auf Entstehungsprozess und Rahmenbedingungen
    Die meisten Beiträge konzentrieren sich auf das Resultat oder den Autor, aber dieser liefert prozessorientierte Einsichten

    • Als jemand, der selbst über Cursor geschrieben hat, habe ich immer weniger verstanden, was sie eigentlich unter „Erfolg“ verstehen
      Deshalb erschien es mir sinnvoller zu untersuchen, was wirklich der schwierige Teil ist und an welchem Prozess etwas falsch läuft
  • Beeindruckende Arbeit
    Ich frage mich, wie man Barrierefreiheit (Accessibility) ohne Rust-Abhängigkeiten umsetzen würde
    Unter Windows/macOS wäre das mit UI Automation und NSAccessibility möglich, aber unter X11 gibt es

    1. die Möglichkeit, AT-SPI per D-Bus neu zu implementieren, oder
    2. eine bestehende D-Bus-C-Bibliothek zu verwenden, oder
    3. GTK oder Qt zu nutzen