Was X beim Web-Rewrite für Coding-Agenten festgeschrieben hat
Wie ein kleines Team die Web-App von x.com mit Coding-Agenten neu gebaut hat, und welche drei Vertrauensschichten dabei den Ausschlag gegeben haben: AGENTS.md, Skills und Lint.
Bernd D.H. Martin
Am 4. November 2026 hat Yagiz Nizipli, Principal Engineer bei X, im Engineering-Blog beschrieben, wie die Web-App von x.com neu gebaut wurde. Mich interessiert weniger der proprietäre Rebuild selbst als die Art, wie ein kleines Team Coding-Agenten so eingebunden hat, dass es dem Ergebnis trauen konnte.
Fünf Ingenieure haben laut Post die erste Version mit KI-Coding-Agenten in unter sechs Monaten gebaut. Seit Ende September haben mehr als 20 Personen am Repo mitgeschrieben. Ein Server ersetzt die drei bisherigen Wege: rweb für Menschen im Browser sowie rweb SSR und Jetfuel SSR für Crawler und öffentliche Seiten. Ausgeloggte Seiten und Crawler-Traffic laufen bereits auf der neuen App, eingeloggte Nutzer werden landweise umgestellt.
Im eigenen Lab von X erscheint der erste Post eines Profils auf einer gedrosselten Leitung nach 2,7 Sekunden statt nach 23,9. Das sind Messwerte von X, kein unabhängiger Benchmark. Ich erwähne sie, weil sie die Richtung zeigen: Es geht um die Zeit bis zum ersten sinnvollen Inhalt, nicht um den First Contentful Paint einer Splash-Seite.
Drei Vertrauensschichten für Agenten
Die Ingenieure haben Architektur, Prioritäten und Review gesetzt. Agenten übernahmen einen Großteil der Umsetzung: Verhalten der alten Server portieren, Seiten konvertieren, Tests schreiben und Fundstellen aus CI und Review beheben. Das funktioniert laut Post nur, wenn man dem Ergebnis trauen kann. Dafür nennt Nizipli drei Dinge.
Gemeinsame Regeln in einer AGENTS.md. Eine Datei im Root des Repos sagt jedem Agenten, wie Code geschrieben wird: Named Exports, keine Barrel-Files, Validierung externer Daten an Trust Boundaries, welche Tests sich lohnen – und dass nichts committet wird, bevor Lint, Typecheck und die relevanten Tests grün sind. Jeder Agent und jeder neue Ingenieur startet mit denselben Regeln.
Skills neben dem Code. Wiederkehrende Abläufe liegen als schrittweise Skills direkt im Repo, mehr als 25 Stück: Commits schreiben, PRs öffnen und stapeln, Review, CI, Dependencies, Übersetzungen, Relay und Router. Ändert sich ein Ablauf, wird der Skill einmal aktualisiert, und jeder Agent zieht ihn nach.
Konventionen als Lint. Eigene oxlint-Plugins prüfen unter anderem Relay, Tailwind, Tests und Übersetzungen. Dazu kommt ein „Anti-Slop“-Plugin gegen typische Agentenmuster: verkettete Type Assertions, Parameter vom Typ unknown und Conditional Spreads leerer Objekte. Ein Pre-Commit-Hook formatiert, lintet und typecheckt jede Änderung, ein Pre-Push-Hook lintet die Pakete, die sie importieren.
Die alten Server als Spezifikation
Die Migration hat nach dem Post gut zu Agenten gepasst, weil rweb SSR und Jetfuel SSR als funktionierende Spezifikation dienten. Ein Agent konnte nachlesen, wie ein alter Server eine URL oder einen Seitentyp behandelt hat, das Verhalten übernehmen und mit einem Test festhalten. Ein Reviewer konnte das Ergebnis mit dem Original vergleichen. X hat dafür auch ein kleines Parity-Skript genutzt, das unter anderem Status, Title, Canonical und strukturierte Daten zwischen alt und neu vergleicht.
Für die Ingenieure hat sich die Rolle verschoben. Sie haben weniger Zeit mit dem Schreiben von Code verbracht und mehr damit, zu entscheiden, was das System tun soll, und im echten Browser zu prüfen, dass es das auch tut.
Der Stack, kurz
Die neue App steht auf Vite, React mit Streaming-SSR, Fastify, Platformatic Watt, Relay und GraphQL sowie der internen Komponentenbibliothek XDS. Das reicht als Einordnung. Der Code der neuen x.com-App ist nicht öffentlich; der Post beschreibt den Ansatz, nicht ein Repo zum Nachbauen. Die öffentlichen Algorithmus-Repos von Twitter und xAI sind ein anderes Thema. Der Post behandelt weder Grok-Ranking noch den For-You-Feed.
Was ich für bmline mitnehme
Bei bmline.de habe ich schon einen Teil davon, aber längst nicht in dieser Konsequenz. Die CI prüft bei jedem Push Lint, Typecheck, Tests und den Build. Es gibt Vitest-Tests, unter anderem für Frontmatter, die Notes- und Labs-Listen und ein paar technische Checks. Was fehlt, ist eine AGENTS.md: Im Repo liegt eine CLAUDE.md mit Stack und Architektur für Claude Code, aber keine gemeinsame Regeldatei, die jedem Agenten sagt, was committet werden darf und welche Konventionen gelten. Skills neben dem Code und ein Lint gegen typische Agentenmuster gibt es ebenfalls nicht. Pre-Commit- und Pre-Push-Hooks habe ich in diesem Repo nicht gefunden.
Eine Idee, kein fertiger Schritt: dieselben drei Schichten schrittweise nachzuziehen – eine AGENTS.md, ein paar Skills für wiederkehrende Abläufe und ein Guardrail, der typischen Agent-Unfug abfängt, bevor er im Commit landet. Das wäre auch die Grundlage für ein geplantes Experiment: viele Agent-Varianten derselben Aufgabe, alle gegen dieselben harten Checks. Ergebnisse dazu gibt es noch nicht.
Quellen
- Yagiz Nizipli: Rebuilding the global town square from scratch, 4.11.2026. Den Text habe ich über den Wayback-Snapshot vom 10.11.2026 gelesen, weil die Live-Seite beim Abruf mit 403 geantwortet hat.