Compositor: KI verbilligt Clean-Room-Entwicklung

Compositor ist nicht Photoshop, doch das Signal ist ernst

Ich würde Compositor nicht als nachgewiesenen Photoshop-Klon bezeichnen: Die verfügbaren Materialien belegen weder Vollständigkeit noch Kompatibilität auf diesem Niveau. Die Projektseite von Robbie Tiltons Compositor löste eine Diskussion darüber aus, wie sich mit KI schnell ein Clean-Room-Grafikeditor umsetzen lässt. Im September 2026 lautet das zentrale Signal nicht „Photoshop ist in Tagen fertig“, sondern dass der Weg von der Spezifikation zum Code drastisch billiger geworden ist.

Die stärkste quantitative Stütze für diese These kommt nicht von Compositor, sondern aus der MirrorCode-Veröffentlichung. Dort implementierte ein Frontier-Modell ein Go-Tooling mit rund 16.000 Zeilen in 14 Stunden für 251 US-Dollar neu; Epoch AI schätzte vergleichbare menschliche Arbeit auf zwei bis 17 Wochen. Die Zahlen sind beeindruckend, doch ein begrenztes Tooling und eine reife Grafik-Suite spielen in unterschiedlichen Gewichtsklassen.

Ein System der Photoshop-Klasse verlangt mehr als nachgebildete Funktionen. Architektur, Interface-Verhalten, Ressourcenverarbeitung, Performance und zahllose undokumentierte Randfälle müssen rekonstruiert werden. Deshalb bewerten ProjDevBench und Vibe Code Bench die Lieferung ganzer Projekte statt nur die Korrektur einzelner Aufgaben. Aber auch sie beweisen nicht, dass ein autonomes System einen vollständigen Ersatz für ein reifes Produkt bauen kann.

Clean Room ist ebenfalls kein Zauberwort. Die Entwicklung muss sich auf eine unabhängige Spezifikation statt auf den Originalcode stützen und eine nachweisbare Trennung bewahren. Wenn ein Modell eine geschützte Implementierung gesehen hat oder die Anfrage faktisch verlangt, markante Entscheidungen zu kopieren, wird aus dem rechtlich sauberen Raum schnell ein Raum mit Fingerabdrücken.

Der Wert wandert vom Schreiben von Code zum Produktwissen

Engineering verschwindet nicht, doch seine günstigeren Schichten werden komprimiert. KI beschleunigt Projektgerüste, Boilerplate, Tests, Refactoring und aufeinanderfolgende Korrekturen. Teuer werden eine präzise Verhaltensspezifikation, die Prüfung der Kompatibilität, Performance-Tuning und die Entscheidung, welche Ähnlichkeiten technisch nötig sind und welche rechtliche Risiken erzeugen.

Für Open Source ist das eine echte Verschiebung: Ein kleines Team kann eine Nischenalternative schneller prüfen und früher einen funktionierenden Prototyp erreichen. Für Eigentümer reifer Software verlagert sich der Schutz vom Umfang des geschriebenen Codes hin zu Produktqualität, Ökosystem und angesammelten Verhaltensdetails. Ein Prototyp ist jedoch noch immer kein verlässliches Werkzeug für die tägliche Arbeit.

Code wird zum günstigen Teil einer Kopie. Teuer bleiben zwei Dinge: eine exakte Spezifikation des Verhaltens und eine nachweisbare Grenze zwischen Kompatibilität und Aneignung.

Die neuesten Updates von Obsidian zeigen, wie erweiterbare Software über CLIs, Plugins und lokale Workflows schnell fortgeschrittene Funktionen erhalten kann. Dieselbe Dynamik erklärt, warum Open-Source-Projekte etablierte Kreativwerkzeuge zunehmend herausfordern.