Dreizehn Adobe- und Office-Klone, geschrieben mit Claude: Wir haben sie alle gebaut und ausgeführt

Veröffentlicht im TEN INVENT Blog · Oktober 2026

In den ersten zwei Oktoberwochen 2026 wurde aus einer GitHub-Organisation namens storytold mit ein paar alten Unreal-Engine-Plugins das meistdiskutierte Open-Source-Projekt des Monats. Brandon Thomas, Gründer des Studios ArtCraft, veröffentlichte Rust-Neuimplementierungen von Photoshop, Illustrator, Premiere Pro, Lightroom, After Effects, InDesign und Acrobat, eine Woche später dann von Word, Excel, PowerPoint, einem CAD-Tool und einem Audio-Editor. Fast der gesamte Code wurde mit Claude Opus 5.5 geschrieben. PhotoCraft, die Photoshop-Variante, knackte in vierzehn Tagen die Marke von 59.000 Sternen.

Die Schlagzeilen gingen in zwei Richtungen: „Adobe ist tot“ auf der einen Seite, „ein Haufen KI-generierter Screenshots“ auf der anderen. Beides hilft wenig, wenn Sie entscheiden müssen, ob Sie das einsetzen, etwas Ähnliches bauen oder es einem Kunden erklären. Also haben wir das Unspektakuläre getan. Wir haben alle dreizehn Apps geklont, auf einem Mac aus dem Quellcode gebaut, ausgeführt, PhotoCraft mit einigen hundert echten PSD-Dateien gefüttert, den Speicherverbrauch gemessen und uns mit den MCP-Servern verbunden. Dieser Artikel fasst zusammen, was wir gefunden haben.

Was passiert ist, der Reihe nach

• 30. September: Die ersten Repositories erscheinen: PhotoCraft, VectorCraft (Illustrator), FilmCraft (Premiere), LightCraft (Lightroom) und PdfCraft (Acrobat). EffectCraft (After Effects) und DesignCraft (InDesign) folgen am 1. Oktober. Alle stehen unter der Doppellizenz MIT / Apache-2.0.
• 2.–3. Oktober: Die Ankündigung erscheint auf Reddit. Der Beitrag auf r/SaaS sammelt einige tausend Stimmen. Darin verspricht Thomas 100 % Funktionsparität mit Adobe innerhalb eines Monats.
• 6. Oktober: Hacker News. Thomas erklärt sein Motiv: Er habe sich einmal zu oft über Adobes „Dark-Pattern-Kündigungsgebühr“ geärgert. Außerdem korrigiert er sein Versprechen: 99 %, in Monaten statt Jahren. Der Kontext ist wichtig. Im März 2026 stimmte Adobe einem Vergleich mit dem US-Justizministerium über 150 Millionen Dollar zu, 75 Millionen Dollar an Zivilstrafen und 75 Millionen Dollar in kostenlosen Leistungen, wegen versteckter Gebühren bei vorzeitiger Kündigung und eines schwer kündbaren Abonnements. Die Klage war im Juni 2024 eingereicht worden. Adobe bestritt ein Fehlverhalten.
• 7.–9. Oktober: WordCraft, GridCraft und DeckCraft (Word, Excel, PowerPoint), CadCraft, SoundCraft und FigCraft (Figma) erscheinen.
• 9.–13. Oktober: Die Geschichte erreicht die breite Öffentlichkeit. Yahoo Tech, Gizmodo, TweakTown, t3n und andere berichten, mit Überschriften zwischen beeindruckt und skeptisch. Fabio Akita veröffentlicht am 13. Oktober eine lange Analyse, deren Kurzfassung lautet: Adobe ist nicht tot.

Stand heute, 14. Oktober, hat sich Adobe öffentlich nicht zum Projekt geäußert, und es sind weder eine Klage noch eine Abmahnung bekannt. Der „Skandal“ ist also ein virales Phänomen, kein Rechtsstreit. Zumindest vorerst.

Was tatsächlich in den Repositories steckt

Sterne sagen wenig, deshalb haben wir uns angesehen, was in Git liegt. Die folgenden Zahlen stammen aus unseren Klonen vom 14. Oktober.

Das sind rund 3,5 Millionen Zeilen Rust in zwei Wochen, mit etwa 40.000 Testfunktionen. Über die 13 Repositories hinweg gibt es 15.840 Commits, von denen 7.985 einen Co-Authored-By: Claude-Trailer tragen, meist Opus 5.5. Das ist eher eine Untergrenze als eine exakte Zahl, weil Squash-Merges externer Contributor den Trailer nicht immer behalten. Allein PhotoCraft hat rund 1.990 gemergte und 620 offene Pull Requests. Hier tippt nicht eine einzelne Person. Es sind eine Person, eine Handvoll regelmäßiger Contributor und viele parallele Agent-Sessions, mit Git als Koordinationsschicht.

Der Code ist auch kein Haufen Screenshots. PhotoCraft ist in 24 Crates aufgeteilt, wobei die Schichtung zur Build-Zeit erzwungen wird: Geometrie und Farbe ganz unten, darüber das Dokumentmodell, dann Algorithmen, Compositor, Dateiformate, die Engine und ganz oben die Benutzeroberfläche. Die Regeln in AGENTS.md sind strenger als in vielen menschlich geführten Projekten: kein unwrap und kein panic außerhalb von Tests, kein unsafe außer in einem isolierten Crate für Grafiktabletts, zu jedem Crash-Fix gehört ein Regressionstest, und Pixelcode wird mit 8, 16 und 32 Bit getestet.

Wir haben sie auf einem Mac gebaut

Die Testmaschine war ein Mac Studio mit M3 Ultra und 96 GB RAM unter Rust 1.99. Wir haben für jede App das Desktop-Binary und das CLI im Release-Build gebaut, ohne Änderungen am Code.

Alle 13 ließen sich beim ersten Versuch kompilieren, ohne Änderungen. Ein Release-Build dauert auf dieser Maschine zwischen 30 Sekunden und 3,5 Minuten pro App. Danach haben wir jeder App über die Kommandozeile eine echte Aufgabe gestellt, wo möglich mit eigenen Dateien:

Das sind Smoke-Tests, keine Bewertung jeder einzelnen App. Sie zeigen, dass die Apps existieren, starten, echte Dateien lesen und Dateien schreiben, die andere Software öffnen kann. Sie sagen nichts darüber, wie sie sich im Arbeitsalltag schlagen. Genau diese Frage beantwortet das projekteigene Paritätsdokument weiter unten.

Bei PhotoCraft sind wir weiter gegangen.

PSD-Dateien. PhotoCraft liefert ein Skript mit, das öffentliche Testkorpora bei festen Commits herunterlädt: die Testdateien von psd-tools (einer Python-Bibliothek) und ag-psd (einer JavaScript-Bibliothek), PngSuite und eine Sammlung von Affinity-Dateien. Wir haben jede darin enthaltene PSD mit photocraft-cli geöffnet, zu PNG verflacht, wieder als PSD gespeichert und das Ergebnis erneut geöffnet. 308 der 309 psd-tools-Dateien und alle 51 ag-psd-Dateien (insgesamt 360) lassen sich ohne Fehler öffnen, speichern und erneut öffnen. Die eine, die scheitert, ist ein Gruppentrenner mit ungewöhnlichem Füllmethoden-Modus. Fehlerfreies Öffnen ist nicht dasselbe wie ein Rendering, das exakt dem von Photoshop entspricht, und wir haben keine Pixel gegen Photoshop gemessen. Die README sagt „the render is kept for 307 of 309 files“, was zu dem passt, was wir gesehen haben.

Die Oberfläche. Die App startet mit Metal, die GPU-Zeichenfläche funktioniert, und Ebeneneffekte (Abgeflachte Kante, Schein, Schatten, Überlagerungen, Kontur) werden auf lebenden Textebenen gerendert. Menüs, Bedienfelder, Werkzeugleiste und Tastenkürzel sind deutlich an Photoshop angelehnt. Ein Detail, das zeigt, wie weit die Nachahmung geht: Photoshop belegt ⌘H und ⌘M mit eigenen Befehlen, obwohl macOS diese Kürzel normalerweise für Ausblenden und Minimieren reserviert. PhotoCraft übernimmt die Photoshop-Belegung und verschiebt Ausblenden und Minimieren auf ⌃⌘H und ⌃⌘M. Das meldet die App beim Start selbst im Log.

Speicher. Wir haben ein Dokument mit 12.000 × 8.000 Pixeln (96 MP) erstellt, Rauschen, einen Gaußschen Weichzeichner mit 20 px und eine Gradationskurven-Einstellungsebene hinzugefügt und es als PSD gespeichert, alles über das CLI. Das dauerte 3 Sekunden und erreichte eine Spitze von 4,5 GB RAM. Bei 4.000 × 3.000 waren es 0,5 Sekunden und 866 MB. Das funktioniert, kostet aber rund 47 Byte pro Pixel bei nur einer Ebene, was zu den offenen Issues über den Speicherverbrauch bei großen Dateien passt. Zum Vergleich: Die rohen Pixel einer 8-Bit-RGBA-Ebene mit 96 MP belegen etwa 384 MB.

Der interessante Teil: Jede Aktion ist ein Befehl

Wer nur auf Screenshots schaut, übersieht die Architektur, die zugleich die am besten wiederverwendbare Idee des Projekts ist. In PhotoCraft führt jeder Menüpunkt, jedes Werkzeug und jeder Dialog einen Befehl aus einer einzigen Registry aus. Unser Build hat 909 Befehle. Die Oberfläche ruft sie auf, ebenso das CLI, ein JSON-Steuerkanal und ein MCP-Server.

Der MCP-Server ist besonders clever gebaut. Er stellt nicht 909 Tools bereit, sondern 25: command_list, command_run, command_batch, doc_open, doc_save, doc_render_preview, ui_screenshot und einige weitere. Das gesamte Tool-Schema umfasst etwa 25 KB JSON. Der Agent fragt die Befehlsliste ab, wenn er sie braucht, und führt Befehle per ID aus. Zum Vergleich: Akita hat den Tool-Katalog eines anderen populären MCP-Servers, REA (für Reverse Engineering), mit etwa 2,3 MB JSON gemessen, für die ein Agent in jeder Session mit Token bezahlt.

Dieselbe Idee findet sich in den anderen Apps: VectorCraft, LightCraft und die übrigen haben jeweils einen eigenen mcp-Unterbefehl. Der Dateizugriff ist standardmäßig gesperrt: Der Headless-MCP-Server darf nur in den Ordnern lesen und schreiben, die Sie ihm mit --automation-read-root und --automation-write-root zuweisen. Der Steuerkanal der Desktop-App lauscht nur auf Loopback und verlangt ein Token.

Diesen Teil würden wir in ein Kundenprojekt übernehmen, unabhängig davon, was aus den Klonen wird. Wenn eine Anwendung eine einzige Befehlsschicht hat, die auch die Oberfläche aufruft, kann ein KI-Agent alles nutzen, was der Benutzer kann, ohne eine separate „KI-Integration“, die sich vom Produkt wegentwickelt. Und Sie können jede Funktion ohne Oberfläche testen.

Die Paritätszahlen, genau gelesen

PhotoCraft hat ein Dokument, das ehrlicher ist als die Schlagzeilen: docs/target-app-parity.md. Es misst die App an Photoshop 2026 und wird alle paar Tage aktualisiert. Die Version vom 10.–13. Oktober sagt:

Zwei Zahlen sind entscheidend. Der Funktionsumfang liegt bei etwa 76 %: Drei Viertel der Menüs, Werkzeuge, Bedienfelder und Formate von Photoshop gibt es in irgendeiner Form. „Bereit für echte Arbeit“ liegt bei etwa 45 %: ob ein Profi Photoshop heute damit ersetzen könnte. In der Lücke dazwischen steckt die ganze harte Arbeit eines Editors: Farbmanagement, von Photoshop geschriebene PSD-Dateien, die unversehrt zurück nach Photoshop müssen, Performance bei großen Dateien, Stabilität auf echten Rechnern, Plugins.

Das Dokument geht auch mit der eigenen Geschichte ehrlich um. Am 3. Oktober schätzte es 82 % und 140–220 Agentenstunden bis 95 %. Eine Woche später bezeichnete es diese Schätzung als „far too optimistic“: Seit dem ersten Release waren etwa 1.230 Issues eingegangen, die meisten zu Funktionen, die bereits als erledigt galten. Die neue Schätzung lautet 2.300–4.100 Agentenstunden bis zur vollen Parität. Das ist rund das 15-Fache der ursprünglichen Schätzung, nach einer Woche mit echten Nutzern.

Das ist die nützlichste Lehre für alle, die KI-gebaute Software schätzen müssen. Ein Agent bringt Sie sehr schnell zu „die Funktion existiert“. „Die Funktion funktioniert mit den Dateien der Nutzer“ ist eine andere Kurve, und wie steil sie ist, merken Sie erst, wenn die Nutzer da sind.

Clean Room oder nicht?

Thomas bezeichnet die Apps als Clean-Room-Neuimplementierung. Im klassischen Sinn bedeutet Clean Room zwei getrennte Teams: Eines untersucht das Original und schreibt eine Spezifikation, das andere schreibt Code nach dieser Spezifikation, ohne das Original je gesehen zu haben. Hier arbeitet ein einzelner Entwickler mit einem Modell, das mit enormen Mengen öffentlichen Codes und öffentlicher Dokumentation trainiert wurde. Die klassische Definition passt also nicht.

Was das Repository tatsächlich enthält, ist differenzierter. Die Contribution-Regeln verbieten das Kopieren von Code, Shadern, Icons, ICC-Profilen oder anderen Assets aus proprietärer Software und verlangen, das Verhalten „by observation and public specs“ nachzubilden. Für das PSD-Format gibt es eine Spezifikation, die Adobe selbst veröffentlicht hat. Andererseits besagt das Paritätsdokument, dass die Zielsoftware vermessen wurde, indem eine Photoshop-2026-Installation untersucht wurde, ohne sie zu starten: die Dokumenttypen in der Info.plist, die Datei mit den Standard-Tastenkürzeln, die Lese-/Schreib-Flags der Plugins und Strings im Hauptbinary. Das ist kein Quellcode, aber mehr als „public specs“, und Adobes Lizenzbedingungen schränken Reverse Engineering über das gesetzlich Erlaubte hinaus ein.

Bei den Fragen, die vor Gericht üblicherweise zählen, neigt die Rechtsprechung eher den Klonen zu. In den USA entschied Lotus v. Borland (1995), dass die Menübefehlshierarchie eines Programms eine Bedienmethode ist und kein geschützter Ausdruck, und Google v. Oracle (2021) behandelte die Neuimplementierung einer API als Fair Use. In der EU entschied der EuGH in SAS Institute v. World Programming (2012), dass die Funktionalität eines Programms, seine Programmiersprache und seine Dateiformate nicht urheberrechtlich geschützt sind. Das eigentliche Risiko liegt woanders: im Gesamterscheinungsbild („Look and Feel“), in zu ähnlich aussehenden Icons und in den Marken. Die Apps verwenden keine Namen oder Logos von Adobe oder Microsoft, was dieses Risiko verringert. Das ist keine Rechtsberatung, und die Antwort hängt von der Rechtsordnung ab, aber „Adobe klagt und gewinnt mühelos“ ist keineswegs selbstverständlich.

Sicherheit: Was wir vor dem Einsatz tun würden

Drei Dinge beunruhigen uns mehr als die Urheberrechtsfrage.

1. Das Änderungstempo. PhotoCraft hat in zwei Wochen etwa 2.000 Pull Requests gemergt, viele von neuen Contributorn, mit Agenten auf beiden Seiten. So viel Code liest niemand sorgfältig. Wenn Sie die Apps einsetzen, pinnen Sie einen Commit oder ein Release und führen Sie nicht main aus.
2. Nicht vertrauenswürdige Dateien. Ein Bild- oder PDF-Editor parst komplexe Formate aus unbekannten Quellen. Rust beseitigt eine ganze Klasse von Speicherfehlern, und dass die Projekte unsafe fast überall verbieten, hilft. Logikfehler, Dekompressionsbomben und unbegrenzte Allokationen bleiben aber möglich. Unser 96-MP-Test zeigt, wie schnell der Speicher wächst. Betreiben Sie sie nicht auf einem Server, der von Benutzern hochgeladene Dateien verarbeitet.
3. Agenten mit Dateizugriff. Die MCP-Server machen standardmäßig das Richtige (kein Dateizugriff ohne ausdrücklich freigegebene Ordner, Steuerkanal nur auf Loopback mit Token). Lassen Sie es dabei: Geben Sie dem Agenten einen Arbeitsordner, nicht Ihr Home-Verzeichnis.

Die macOS-Releases sind signiert und von Apple notarisiert, was bestätigt, wer sie gebaut hat, nicht was darin steckt. Wir haben aus dem Quellcode gebaut, bei einem von uns protokollierten Commit, und eine private Kopie der Repositories angelegt, falls diese verschwinden.

Was das bedeutet

Es bedeutet nicht, dass Adobe tot ist. Der Großteil des Werts von Creative Cloud steckt nicht in einem Binary, das man kopieren kann: Farbwissenschaft, Kameraprofile, lizenzierte Farbpaletten und Schriften, generative Cloud-Funktionen, Anbindung an Druckereien und Agenturen und zwanzig Jahre PSD-Dateien, die sich exakt gleich öffnen müssen. Akita macht denselben Punkt ausführlich.

Aber drei Dinge haben sich verändert und kehren nicht zurück:

• Die Kosten einer glaubwürdigen ersten Version sind eingebrochen. 3,5 Millionen Zeilen strukturiertes, getestetes Rust in zwei Wochen sind eine Tatsache, keine Demo. Für interne Tools und Nischenprodukte gilt „wir bräuchten ein Jahr lang ein Team“ nicht mehr automatisch.
• Die letzten 50 % sind nicht im selben Tempo billiger geworden. Die eigenen Zahlen des Projekts zeigen es: von 76 % Funktionsumfang auf 45 % Einsatzbereitschaft und eine Schätzung, die nach einer Woche mit Nutzern auf das 15-Fache gewachsen ist. Dort liegen weiterhin Engineering, Tests mit echten Dateien und Produktentscheidungen.
• „Agent-ready“ wird zur Architekturanforderung. Eine einzige Befehlsschicht, die von der Oberfläche, dem CLI und einem MCP-Server mit kleiner Tool-Oberfläche genutzt wird, ist das Muster, das wir heute für jede neue Anwendung empfehlen würden, die von Agenten genutzt werden soll.

Wenn Sie eine Zweitmeinung dazu möchten, was KI für Ihr Produkt realistisch bauen kann und was weiterhin Aufgabe Ihres Teams bleibt, nehmen Sie Kontakt auf.