Tech Teardown 022｜wordcraft: Eine Person plus ein Agenten-Schwarm hat Word in fünf Tagen „rekonstruiert"

Am 7. Oktober wurde eine Repository-Erstellung durchgeführt, und innerhalb von fünf Tagen wurden über 6000 Sterne gesammelt – das ist der Erfolg von storytold/wordcraft auf GitHub. Aber es ist kein Einzelfall: Eine gleiche Organisation hat innerhalb von zwei Wochen Photoshop, Lightroom, Premiere, Acrobat, Illustrator, Excel, PowerPoint und AutoCAD einzeln „rein gesäubert“ umgesetzt. Das Projekt photocraft erreichte 48.000 Sterne, alle mit Rust geschrieben und alle als „rein gesäuberte Umsetzung“ bezeichnet. Wordcraft ist ein Mitglied der Gruppe Word, dessen README-Zweizeilensatz lautet: „Eine open-source, rein gesäuberte Umsetzung von Microsoft Word, erstellt in reinem Rust.“ Was wirklich zu analysieren ist seine Produktionsweise: Der Hauptbeitragende hat innerhalb von drei Tagen 57.353 neue Codezeilen hinzugefügt, und die verbleibenden Arbeitsstunden im Projektplan werden direkt mit „Opus 5.5 agent wall-clock hours“ beziffert. Innerhalb einer Woche stieg die Anzahl der PRs auf 581. Dies ist ein lebendiges Beispiel für die Massenproduktion von Software durch AI-Agenten. In diesem Artikel wird nach alter Sitte sechs Abschnitte analysiert.

1. Was ist es?

wordcraft ist ein Dokumentenverarbeitungsprogramm der ArtCraft-Familie, dessen Ziel es ist, funktional Microsoft Word zu entsprechen, aber dennoch vollständig neu geschrieben zu werden. Die Größe ist beträchtlich: Das Repository umfasst 428 Dateien, 280 Rust-Quellcode-Dateien, insgesamt 156.273 Zeilen (inklusive Tests). Sein eigenes Projektplan gibt eine andere Angabe: 433 Befehle, 855 Tests sowie 10 property blocks, etwa 88.700 Zeilen Rust. Die selbstgemachten Zahlen und die tatsächlichen Statistiken stimmen nicht überein – das ist bereits ein Merkmal solcher Projekte, wie im vierten Abschnitt näher erläutert.

Das System besteht aus sieben Schichten: Die Grundlage bilden geometrische Berechnungen und Schriftarten, darüber liegt der Layout-Engine, weiter oben die Lesung und Schreibung von Dateiformaten wie DOCX (unterstützt OOXML/ECMA-376), die auch ODT, RTF, HTML, Markdown, LaTeX und reinen Text lesen können, sogar .doc-Dateien von Word 97-2003. Danach kommen die Rendering- und PDF-Export-Funktionen, weiter oben der Engine-Schicht (Sitzungen, Rückgängigmachen, Befehlsregister), und außerhalb davon der MCP-Server und die egui-Grundseitenansicht. Es gibt drei Veröffentlichungsformen: Desktop-Anwendung, Kommandozeilen-Tools und WASM-Webanwendung.

„Reinigungsraum“ ist die Grundlage seiner Existenz. Die Regeln sind in AGENTS.md festgelegt – sehr restriktiv und streng: Auf der Entwicklungsplattform wird das Original-Word-Spielzeug verwendet, es ist erlaubt, mit einem schwarzen Boxen-Observer zu beobachten und Screenshots anzulegen, doch das Lesen des Inhalts der Word-Installationspakete sowie das Einreichen jeglicher Word-Produkte ist verboten. Die Dateiformate werden nur nach den offiziellen Standards umgesetzt (ECMA-376, OASIS ODF 1.3, RTF-Standard). Bei der Nennung von Quellen darf man keine Codequellen wie LibreOffice, AbiWord oder pandoc aus dem GPL-System übernehmen. Die Disziplin bezüglich der Assets ist ebenfalls streng: INTRIBUTION.md verlangt die Registrierung des Autors, der Herkunft und der Lizenz jedes nicht-kodierenden Assets. Ein Fehler bei der Überprüfung der assets durch cargo xtask führt zum Scheitern; alle Icons müssen mit Code erstellt werden, kein Microsoft-Icon darf auftauchen. Die Schriftarten kommen aus dem OFL-1.1-Open-Schriftarten-Lager. Die Codelizenzen lauten MIT oder Apache-2.0, die Markenlizenzen sind separat gesichert.

2. Warum es jetzt wert ist, gesehen zu werden

Der Reinigungsraum versucht, Office neu zu implementieren – ein Weg, den bisher nur LibreOffice beschritten hat, mit der Konsequenz, dass viele Menschen jahrelang mit dieser historischen Last leben mussten. Jetzt gibt es den AI-Agenten: Die Arbeit an der Umsetzung eines Word-Programms nach offiziellen Standards wird von „einer gesamten Teamarbeit“ auf „eine Person plus einige Wochen mit Agenten“ reduziert. Die Roadmap von wordcraft zeigt dies direkt: Alle verbleibenden Arbeiten werden nach der Arbeitszeit der Agenten berechnet. Bis zur Beta-Phase benötigen 150 bis 230 Agentenstunden, bei 95% Fertigstellung 650 bis 1100 Agentenstunden. Beispiele für die Zeitaufwendung sind: „PR #191 mit etwa 9.700 Zeilen in 5 Stunden“ oder „Ein Dokument Reader mit etwa 4.500 Zeilen in 10 Stunden“. Menschen können nicht so schnell arbeiten, und das Projekt funktioniert nach dem Modell der Massengenerierung durch AI-Agenten – das geben die Autoren selbst nicht zu verbergen. In Diskussionen auf HN wird diese Familie oft mit „vibe-coded“ beschrieben.

Ein weiterer Hintergrund ist die emotionale Belastung. Die monatlichen Abonnements von Adobe und Microsoft haben jahrelang dazu geführt, dass viele Menschen unzufrieden sind. In den Diskussionsforen auf HN sagt man oft: „Adobes Marktstellung ist zu schwach, früher oder später wird jemand aus Unzufriedenheit mit den Preisen das gesamte Creative Suite neu aufbauen.“ Einige Kommentatoren behaupten sogar, dass sie nach dem Erhalt des Projekts sofort ADOBE ins Minus taten (das ist eine persönliche Handlung, die nicht ernst genommen werden sollte). Der Autor selbst war offen in HN: „Ich war noch nicht bereit, dies auf HN zu posten. Es ist noch nicht einmal annähernd fertig.“ In der frühen Alpha-Phase wurden offen Förderer gesucht, mit dem Versprechen von Stipendien und Bug-Bounties.

3. Kerntechnologiemodelle

Wertvoll sind die vier Komponenten, die hierher übernommen werden sollten.

Erstens: Alles ist eine Anweisung. Jede Aktion ist ein CommandSpec mit einem ID. Derselbe Satz von Anweisungen (in dem README 422 angegeben werden, in der Roadmap 433, die Anzahl variiert je nach Iteration) steuert gleichzeitig sechs Eingänge: das Ribbon-Menü, Tastenkombinationen, Suchfunktionen für Anweisungen, Befehlszeilentools, JSON-Steuerkanäle, der MCP Server. Eine weitere Funktion bedeutet die Registrierung einer Anweisung, und die sechs Eingänge gelten automatisch. Im README wird „Built for agents“ als offizielles Merkmal dargestellt, sodass Agenten das gesamte System über den MCP Server ohne Hintergrundbetrieb steuern können.

Zweitens: Die Disziplin „never crash“. Nicht für Tests vorgesehenes Code sollte vermeiden, panik zu zeigen, unwrap zu verwenden oder unsafe_code direkt zu verbieten. Es gibt ein Test mit hostile_params_never_panic, bei dem gesamte Anweisungen mit schlechten Parametern ausgeführt werden, um einen Zusammenbruch zu vermeiden. In Session::run wird der abgeflossene panik in ein Error umgewandelt und der Dokumentstatus wiederhergestellt. In AGENTS.md steht, dass die Klausel „never crash“ über den Funktionen steht. Für große Mengen von von AI generiertem Code ist eine solche globale Überwachung unerlässlich, es handelt sich dabei nicht um eine Sauberkeitsforderung.

Drittens: Die Methode des reinen Raumsbeobachtens. Wie bereits erwähnt, folgen hier die Details der Umsetzung: Nur offizielle Standards gelten für die Formatierung, Beobachtungen erfolgen nur mit schwarzen Boxen (Ausführung, Screenshots). In der CI gibt es Layer-Überprüfungen, um überlappende Verweise zu verhindern. Die „grauen Bereiche“ werden selbst nicht berührt, aber ob die Praxis „UI entsprechend den Screenshots auszurichten“ als Erschleichung des Aussehens betrachtet werden kann, wurde bereits auf HN gefragt: „Wird Microsoft wegen dieses Verhaltens verklagt werden?“ Das ist eine Frage, die über dem Projekt schwebt.

Viertens: Die Testbarkeit von Parity. cargo xtask parity erstellt eine Liste der Funktionen, die mit den Screenshots übereinstimmen. In der Roadmap deckt das Ribbon-Verzeichnis 481/496 (97,0%) dieser Anweisungen ab, es handelt sich dabei nicht um spontane Entscheidungen. Der minimale Anteil an Tests darf weder erhöht noch gesenkt werden. Alle Qualitätskontrollen werden in einem cargo xtask ci zusammengefasst: fmt, clippy mit -D Warnungen, Tests, Asset-Registrierung, Hierarchieprüfungen, WASM-Bau. Vor dem Einreichen müssen alle Punkte als gültig eingestuft werden.

Auch die dazugehörigen Komponenten sind erwähnenswert. Unterhalb der Hauptversion der crates-Verzeichnisse gibt es Integrationen mit Zotero für akademische Zwecke, Offline-Sprachkorrektionsfunktionen (ohne Internetverbindung, nicht öffentlich zugänglich), sowie eine Satzmodell-Leselösung. Diese Komponenten zeigen, dass der Autor ein Bewusstsein für den „vollständigen Ökosystem des Dokumentprocessors“ hat und nicht nur die Kernfunktionen berücksichtigt. Die Roadmap enthält noch eine weitere Disziplin, die es wert ist, übernommen zu werden: Die letzte Überprüfungs- und Aktualisierungsdatum wird am Anfang des Dokuments angegeben (Last reviewed 10-10, Last updated 10-11). Neben jeder Zahl steht angegeben, ob die Werte gemessen oder geschätzt sind. Die Selbstberichte über die Datenqualität sind wichtig, was in einer Zeit, in der von AI generierte Dokumente überschwemmt sind, eher eine Rarität ist.

Vier, Zahlen und Grenzen

Drei Angaben über die eigenen Daten zusammengefasst, ergibt das einen Unterschied: Die Katalogabdeckung beträgt 97% (gemessen mit Tools), die Featurebreite etwa 80% (schätzung), und „Ready for real work“ liegt bei etwa 60% (Schätzungsbereich 55-63%). Die Angaben von den Nutzern sind jedoch kühler: Der Roadmap gibt an, dass es 120 externe Benutzeranfragen, 4 positive Bewertungen, 0 Nutzer, die vom Word-Format übernommen wurden, sowie etwa 21 Kernpfade mit Fehlern gibt. Der Unterschied zwischen 97% Katalogabdeckung und 0 Migrationsnutzern entspricht der Distanz zwischen Alpha und dem Produkt.

Die Leistungsangaben sind alle selbstgemachte Angaben: „Beim Schreiben in einem 188-seitigen Dokument dauert die Formatierung etwa 1,4 Millisekunden“, ohne Drittanalysen. Die beiden Werte für die Anzahl der Zeilen (selbstgemachte Angabe 88.700 vs. gemessene 156.273 inklusive Tests) zeigen, dass die Dokumentaktualisierung nicht mit der Codegenerierungsgeschwindigkeit Schritt halten kann – dies ist in Projekten mit großem Agentcode-Massenproduktion normal. Auch die Struktur der Mitwirkenden ist bemerkenswert: contributors.json zeigt 45 Commits, wobei eine Person drei Tage lang 57.353 Zeilen hinzufügte, während die restlichen kleinere PRs waren; das Repository zeigt eine „Fertigproduktlager“-Struktur, bei der die Geschichte abgeschnitten ist und der Prozess nicht nachvollziehbar ist. Die lange Unterstützung durch eine einzelne Hauptmitwirkende und Agenten zur Codegenerierung ist eine große Frage.

Die Kommentarsammlung auf HN bietet beide Ansichten. Skeptiker: Einige sagen direkt skeptisch, andere sind unzufrieden mit der Registrierungs- und Login-Anforderung für die Desktop-Version, wieder andere beschweren sich über das Scrollrad-Erlebnis als „nicht gut genug für eine bessere UX-Aufmerksamkeit“, und einige bemerken, dass das Hauptlager der Familie Fair Source-Lizenzen verwendet (anders als das Wordcraft-Lager selbst mit MIT/Apache-Lizenzen), und stellen die Urheberrechtsfrage auf, dass „AI-Slop von Anfang an im Public Domain ist“. Juristische Fragen sind: Wird der „designtechnische Vater“ Risiken mit sich bringen? Einige fragen sogar direkt, ob Microsoft Wordcraft wegen der GUI klagen könnte. Nur 3 Stimmen unterstützen diese Frage, aber sie bleibt unbeantwortet. Beeindruckende Meinungen: Einige loben das Design der Seite, andere sagen: „Vor drei Jahren wäre man von so etwas schockiert gewesen, jetzt sind wir gegenüber AI abgestumpft“, und wieder andere finden, dass die Größe dieses Projekts „genau die verschiedenen Aussagen von Vibe Coding prüft“. Wenn man beide Ansichten zusammen betrachtet, zeigt die Struktur der Meinungsverschiedenheiten im Kommentarbereich und die durch die Karpathy-Konsenslücke in der Diskussionsreihe dieser Woche dasselbe Muster: Menschen, die bereits Kontakt hatten, und solche, die noch nicht kontaktiert wurden, treffen ihre Schlussfolgerungen mit ihren eigenen Beispielen.

Fünf, Wie läuft es, wer kann spielen?

v0.4.0 (veröffentlicht am 10. Oktober) hat eine Installationspaket für alle Plattformen bereitgestellt: macOS-Signatur DMG, Windows MSI, Linux AppImage sowie deb, rpm und Flatpak, FreeBSD-Paket, Web-WASM-Version. Innerhalb einer Woche sollen alle Versionen für die sieben Plattformen verbreitet werden – diese Aktion selbst ist auch ein Beweis für die Produktivität des Agents: Ein traditionelles Projekt erreicht dieses Stadium normalerweise nur mit der Arbeit eines Entwicklers, der mehrere Wochen damit verbringt. Wer den Code lesen oder beitragen möchte, kann ihn klonen und alle Qualitätskontrollen mit einem einzigen Befehl durchführen; das Dokument AGENTS.md ist ausreichend detailliert, von den Regeln im „Clean Room“ bis hin zu Verbotsregeln für Panikfälle und der Registrierung von Assets – es kann als Vorlage für Agent-Entwicklungsstandards verwendet werden. Wer möchte, dass ein AI-Agent Dokumente schreibt, sollte einfach einen MCP-Server erstellen. Anwender empfehlen, nur zuzusehen: Die Roadmap weist laut Angaben noch etwa 21 grundlegende Fehler auf – es ist noch zu früh, damit seriöse Dokumentationen zu erstellen.

Sechstes Kapitel: Werturteil und Anwendungsbereich

Zuerst beantwortet man die Titelfrage: Es kann den Word nicht ersetzen – 0 Migrationsnutzer sind die Antwort. Aber als Beispiel für das Projekt, „konforme Software in großen Mengen mit AI-Agenten zu entwickeln“, hat es hohe Werte. Das Vierfachset kann direkt übernommen werden: Disziplin im „Clean Room“ (Schwarze Box-Beobachtung, nur offizielle Standards akzeptieren, Asset-Trace-Registrierung), never crash – globale Sicherstellung, Parity-Messbarkeit (Überprüfung mit Listenwerkzeugen, Testgrenzen, die nur steigen und nicht sinken), alle Qualitätskontrollen mit einem Befehl. Diese vier Punkte haben nichts mit konkreten Projekten zu tun – jede Team, die mit Agenten code schreibt, kann sie übernehmen.

Es eignet sich für drei Arten von Menschen: Ingenieure, die mit AI-Agenten code schreiben und deren Projektdisziplin übernommen werden; Personen, die auf die steigende Produktivität im Bereich AI achten – dies ist ein „Fünftausend Zeilen in drei Tagen“-Szenario; sowie Personen, die die Aussagen von Vibe Coding überprüfen wollen. Die Roadmap fasst „Katalogüberdeckung“, „Funktionsbreite“ und „Anwendbarkeit im echten Arbeitsalltag“ in drei getrennte Punkte zusammen und markiert, welche Daten aus Tests stammen und welche nur geschätzt wurden – diese Ehrlichkeit selbst ist Teil des Beispiels.

Risikobetrachtung: Gesetzeslücken bleiben offen (Wird die UI-Kopie rechtlich angefochten werden? Niemand gibt eine Antwort), die Kontinuität der Wartung von Code durch Einzelpersonen und Agenten ist fraglich, und der Unterschied zwischen den gemeldeten Daten und den tatsächlichen Messungen wird immer bestehen bleiben. Es ähnelt am meisten einem offenen Experimentierprotokoll: Wie sollte die Softwareentwicklung in der Ära der AI-Agenten aussehen? Dieser Repository hat einen Teil der Antwort bereits geschrieben. Der andere Teil der Antwort muss erst nach dem Überleben des Alphas gefunden werden – und die meisten ähnlichen Projekte überstehen diese Phase nicht. Das ist auch der Grund, warum dieses Beispiel besonders beobachtenswert ist.

Quelleninformationen

• Repository und Dokumentation: README, ROADMAP, AGENTS.md, NOTICE, ATTRIBUTION.md, contributors.json von github.com/storytold/wordcraft (lokaler Shallow-Cclone-Besuch, Anzahl der Codezeilen berechnet mit wc -l)
• Anzahl der Starred Posts und Familienlisten: GitHub Search API, Snapshot vom 12.10.2026
• HN Diskussionen: vier Beiträge unter news.ycombinator.com/item?id=49958850 usw., Ergebnisse mit Algolia API, alle Kommentare sind Zusammenfassungen
• Zahlen zu Leistung, Abdeckungsgrad und Fertigstellung: Selbstanzeige des Projekts, der Text ist an verschiedenen Stellen markiert