Kommentar: Photoshop per KI nachgebaut – Kopieren ist billig, Entscheiden nicht

Anfang Oktober hat der Entwickler Brandon Thomas unter dem Projektnamen ArtCraft sieben Programme veröffentlicht, die Adobes bekannteste Werkzeuge nachbilden, darunter Photoshop, Lightroom und Premiere Pro.

Mittlerweile sind es 13 Anwendungen. Geschrieben sind sie in Rust, den Code hat im Wesentlichen Claude Opus 5.5 erzeugt, das aktuelle Spitzenmodell von Anthropic. Allein der Photoshop-Nachbau PhotoCraft sammelte auf GitHub binnen weniger Tage Zehntausende Sterne, und Thomas selbst brachte das Projekt auf Reddit auf eine Formel, die seitdem durch die Fachpresse wandert: „Software is over“.

Damit bekommt ein Abgesang neue Nahrung, der seit dem Aufkommen von Coding-Agenten ohnehin in schöner Regelmäßigkeit angestimmt wird. Wenn eine einzelne Person mit einem Sprachmodell Photoshop nachbauen kann, so die Logik, wozu braucht es dann noch Entwicklerinnen und Entwickler? Ich halte diesen Schluss für falsch, und ich halte das Vorgehen dahinter für verkehrt. Nicht die KI beendet die Softwareentwicklung. Das erledigen wir selbst, indem wir ihre Arbeit entwerten.

Was tatsächlich entstanden ist

Zunächst lohnt ein nüchterner Blick darauf, was PhotoCraft eigentlich ist. Das Projekt beschreibt sich in seiner README als quelloffene Clean-Room-Neuimplementierung von Photoshop, also als Nachbau, der ohne Zugriff auf den Originalcode entstanden sein soll. Grundlage seien öffentliche Spezifikationen und das beobachtete Verhalten des Originals. Mehr als 1700 Tests sichern das Ergebnis ab, und ein Teil davon vergleicht das, was PhotoCraft rendert, unmittelbar mit dem Bild, das Photoshop selbst aus derselben Datei erzeugt. Dieser Punkt wird gleich noch wichtig.

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Neben dem Ende der Software kündigte Thomas auf Reddit auch an, binnen eines Monats vollständige Funktionsgleichheit mit Adobe zu erreichen. Auf Hacker News korrigierte er das später: 99 Prozent würden eine Weile dauern, sich aber in Monaten messen lassen, nicht in Jahren. Das Bildbearbeitungsmagazin DOCMA hat diese Aussagen neben den Fahrplan des Projekts gelegt und das Ergebnis in einer Überschrift zusammengefasst: Ein Monat, sagt der Entwickler, viele Monate, sagt sein eigener Fahrplan.

Aufschlussreicher als alle Ankündigungen ist ohnehin, was das Projekt über sich selbst sagt. Die README stellt ausdrücklich klar, dass PhotoCraft noch kein Ersatz für Photoshop im professionellen Alltag ist. Dass jeder Menüpunkt von Photoshop mit einem Befehl verbunden sei, messe lediglich die Verdrahtung, nicht das Verhalten.

Die Paritätsbewertung des Projekts schätzt Mitte Oktober, dass PhotoCraft zu etwa 45 Prozent für echte Arbeit taugt, und veranschlagt bis zur vollen Gleichwertigkeit weitere 2300 bis 4100 Stunden Agentenarbeit. Bis Mitte Oktober waren in dem Repository bereits rund 2400 Commits zusammengekommen. Diese Zahlen stammen nicht von Kritikerinnen und Kritikern, sondern aus dem Projekt selbst, und mit „Software is over“ haben sie wenig zu tun.

Den Anlass für das Ganze hat Thomas übrigens ebenfalls genannt: Er sei zu oft über Adobes Kündigungsgebühr gestolpert. Diesen Ärger können vermutlich viele nachvollziehen. An der Bewertung ändert er allerdings nichts.

Der Idealfall für Agenten

Bevor ich zu meiner Kritik komme, will ich einräumen, was das Projekt tatsächlich belegt. In Werkzeugwahl, Teil 1 habe ich vor wenigen Wochen geschrieben, dass Agenten dort stark sind, wo sich ihr Ergebnis deterministisch prüfen lässt: durch Tests und, wo Tests an Grenzen stoßen, durch den Compiler. PhotoCraft bestätigt das, und zwar in Rust, also in genau der Kombination aus strengem Compiler und umfangreicher Testsuite, um die es damals ging.

Allerdings hat der Fall eine Besonderheit, die ihn zum Idealfall macht. Das Beste, was es zum Prüfen geben kann, ist ein Ziel, das bereits exakt vorliegt. Photoshop ist seit 1990 auf dem Markt. Sein Verhalten lässt sich in jeder Situation beobachten, sein Dateiformat ist öffentlich spezifiziert, und für jede Frage, wie ein Bild nach einem bestimmten Arbeitsschritt aussehen muss, liefert das Original die richtige Antwort gleich mit.

Wer unter diesen Bedingungen arbeitet, muss an keiner Stelle entscheiden, was richtig ist. Er muss nur feststellen, ob das Ergebnis dem Original entspricht, und diese Aufgabe lässt sich hervorragend automatisieren. Genau deshalb kommen Agenten mit ihr so gut zurecht, und genau deshalb ist sie so wenig repräsentativ. Was sagt dieser Idealfall also über den Normalfall aus? Meine Antwort darauf: fast nichts.

Abgeschaut ist nicht entschieden

Software besteht nicht nur aus Code. In einem Programm wie Photoshop stecken mehr als drei Jahrzehnte an Entscheidungen. Wie sind die Arbeitsabläufe aufgebaut? Welche Werkzeuge gibt es und wie verhalten sie sich? Wie wird ein Problem aus Sicht derjenigen gelöst, die täglich damit arbeiten? Über all das haben Menschen nachgedacht, sie haben Varianten ausprobiert, verworfen und verbessert. Ein Nachbau übernimmt diese Entscheidungen, ohne eine einzige davon selbst treffen zu müssen.

Wie viel Arbeit in solchen Entscheidungen steckt, zeigt schon ein unscheinbares Beispiel. Dashboards gibt es zu Tausenden, das Prinzip ist hinlänglich bekannt. Trotzdem müssen Entwicklerinnen und Entwickler für jedes konkrete Produkt neu entscheiden, welche Daten ein Dashboard anzeigt und in welcher Form, wie sich auf einen Blick erkennen lässt, was gerade relevant ist, und wie möglichst viele Informationen sichtbar bleiben, ohne dass das Ganze überladen wirkt.

Eine allgemeingültige Antwort auf diese Fragen gibt es nicht, nur eine, die zum jeweiligen Produkt passt. Sie zu finden ist Arbeit, auch wenn das fertige Ergebnis sie später nicht mehr verrät. Und wer ein gelungenes Dashboard nachbaut, übernimmt genau diese Arbeit, ohne sie je geleistet zu haben.

Noch deutlicher wird das in Bereichen, die von außen kaum jemand wahrnimmt. Wir arbeiten seit mehr als zehn Jahren mit Druckereien zusammen, für Bücher, Broschüren, T-Shirts und manches andere. Allein bei Farben und Schriften kann dabei so viel schiefgehen, dass es sich niemand vorstellen kann, der es nie selbst erlebt hat. Die Programme von Adobe bieten für den Austausch mit Druckereien eine Fülle von Optionen, von denen viele andere Grafikprogramme nicht einmal ansatzweise etwas wissen.

PhotoCraft gibt an, CMYK-Dokumente und ICC-Farbmanagement zu unterstützen, einschließlich Softproof, also einer Vorschau darauf, wie ein Bild später im Druck aussehen wird. Ob das im Austausch mit einer echten Druckerei trägt, sei dahingestellt. Die README nennt die Tiefe bei Typografie und bei professionellen Arbeitsabläufen selbst als eine der größten Lücken, und laut der Lückenliste des Projekts weicht das Ergebnis bei gut einem Viertel der Referenzdateien, die Photoshop erzeugt hat, noch vom Original ab. Und selbst wenn eines Tages alles funktionieren sollte, wäre es das Ergebnis von Entscheidungen, die bei Adobe getroffen wurden.

Und wo es keine Vorlage gibt?

Der eigentliche Denkfehler hinter „Software is over“ liegt aber an anderer Stelle. Photoshop ist Standardsoftware: ein Produkt, das in identischer Form an Millionen Kundinnen und Kunden geht und dessen Verhalten alle beobachten können. Der größte Teil der Software, die tagtäglich entwickelt wird, sieht anders aus. Sie entsteht für eine bestimmte Branche, für eine Behörde oder für ein einzelnes Unternehmen, und es gibt sie nirgendwo, bevor jemand sie baut.

Ein Beispiel aus unserer eigenen Arbeit: In den vergangenen zweieinhalb Jahren haben wir für einen großen Energieversorger Software mit entworfen und mitentwickelt. Wo hätten wir die abschauen sollen? Bei einem anderen Energieversorger? Für die Versorgungswirtschaft gibt es zwar Standardsoftware, doch sie bildet gerade das nicht ab, was dieses Projekt ausgemacht hat, nämlich wie die Fachabteilung tatsächlich arbeitet, welche internen Prozesse über die Jahre gewachsen sind und welche UI- und UX-Standards das Unternehmen für alles vorgibt, was nach außen sichtbar ist.

Nichts davon lag als Vorlage bereit, gegen die sich ein Agent hätte testen lassen. All das musste erst verstanden werden, bevor sich auch nur eine Zeile Code sinnvoll schreiben ließ. Es gab kein Original, das für jeden Testfall die richtige Antwort liefert, sondern nur Menschen, die ihre Arbeit erklären, und Entscheidungen, die jemand treffen musste. Für die Fachanwendung einer Versicherung, das Fachverfahren einer Kommune oder die Steuerung einer Produktionslinie gilt nichts anderes.

In Der wahre Engpass habe ich beschrieben, dass der Flaschenhals in der Softwareentwicklung nie das Programmieren war, sondern das Verstehen des Problems. Bei einem Nachbau ist dieses Verstehen bereits erledigt, und zwar von jemand anderem. „Software is over“ verallgemeinert also ausgerechnet von dem einen Fall, in dem der schwierigste Teil der Arbeit längst getan war, auf all die anderen, in denen er noch bevorsteht. KI hat das Kopieren billig gemacht, nicht das Erfinden.