Ein Nutzer ergänzt sein Kanban-Board um Swimlanes, indem er den Wunsch eintippt. Er liest keinen Quellcode. Er forkt kein Repository. Er beschreibt, was er will, und sein LLM nimmt die Änderung an seiner eigenen Kopie der Anwendung vor. Freie Software hat vor vierzig Jahren etwas Verwandtes versprochen: das Recht, die Software zu ändern, die man nutzt, sofern man Zugang zum Quellcode hat. Nur wenige Nutzer konnten dieses Recht je ausüben. Diese Fähigkeit, die eigene Software zu ändern, kommt jetzt tatsächlich an, aber in einer anderen Form als erwartet.
Die vier Freiheiten, die die Free Software Foundation 1986 festschrieb, umfassen die Freiheit, zu untersuchen, wie ein Programm funktioniert, und die Freiheit, es zu ändern. Der Mechanismus, mit dem freie Software diese Freiheiten einlösen wollte, war veröffentlichter Quellcode. Mit Zugang zum Quellcode konnte im Prinzip jeder Nutzer das Programm lesen, die richtige Stelle finden, sie ändern, die geänderte Version bauen und ausführen. Die Freiheit war der Zugang. Den Rest musste der Nutzer selbst erledigen.
In der Praxis war dieser Rest für fast alle nicht machbar. Fremden Code zu lesen ist schwer. Ihn korrekt zu ändern ist schwerer. Ihn zu bauen verlangt Toolchains, Abhängigkeiten und Zeit. Die meisten Nutzer freier Software, auch die technisch versierten, haben nie etwas daran geändert. Sie verwendeten sie so, wie sie ausgeliefert wurde. Der politische Anspruch lautete, dass die Freiheit zur Änderung zählt. Die gelebte Realität war: Die Freiheit gab es, die Fähigkeit nicht.
Das, was diese Fähigkeit nun endlich liefert, ist selbst nicht frei. Die Frontier-LLMs, die das möglich machen, stammen von einer Handvoll kapitalstarker Labore und beruhen auf Trainingsdaten und Infrastruktur, über die kein einzelner Nutzer verfügt. Keines davon ist Open Source im Sinne der FSF: Die führenden Modelle sind vollständig proprietär, und selbst die „offenen“ veröffentlichen nur die Gewichte, nicht die Trainingsdaten oder die Pipeline. Die Nutzer haben jetzt die Freiheit, ihre Anwendungen zu ändern, aber keine Freiheit von den Werkzeugen, die das erledigen.
Die Ironie hat noch eine zweite Ebene: Open-Source-Entwickler selbst nutzen diese Werkzeuge intensiv. Die Community, deren politisches Projekt mit dieser Technologie in Erfüllung geht, ist zugleich die Community, die am schnellsten eine Technologie übernommen hat, die auf kommerziell kontrollierten Grundlagen steht. Das ist Pragmatismus, aber eine seltsame Position ist es trotzdem.
Die Prompt-Mechanik
Die Änderung per Prompt kehrt die alte Hürde um. Der Nutzer braucht keinen Zugang zum Quellcode. Er muss keinen Code lesen oder schreiben. Er beschreibt, was er will („Swimlanes hinzufügen“, „diese Spalte umbenennen“, „auf dem Handy schneller machen“), und das LLM erzeugt die geänderte Anwendung. Die Hürde sinkt vom „Entwickler mit Zeit“ auf den „Nutzer mit Worten“. Was laut freier Software möglich sein sollte, es praktisch aber nicht war, ist jetzt praktisch möglich.
Aber dafür ist freie Software nicht eingetreten. Sie trat für einen bestimmten Mechanismus ein, nämlich veröffentlichten Quellcode, als politische Garantie gegen die Abhängigkeit von Anbietern. Das Prompt-Regime garantiert politisch gar nichts. Es bietet eine funktionierende Möglichkeit, Software zu ändern. Das ist nicht dasselbe wie ein Stack aus freier Software, aber genau das verlangt die gelebte Erfahrung von „Ich will ändern, wie das hier funktioniert“.
Open-Source-Befürworter können mit gutem Grund einwenden, dass das ein anderer Sieg ist als der, für den sie gekämpft haben. Das gemeinschaftliche Entwicklungsmodell, aus dem Linux hervorging, die Sicherheitsprüfung, die durch Offenheit möglich wird, die Lizenzinfrastruktur, die Branchennormen geprägt hat: Nichts davon entsteht durch die Änderung per Prompt. Das hat allein Open Source geleistet. Die Änderung durch den Nutzer war einer der politischen Ansprüche des Projekts. In genau diesem Punkt liefert die Technologie nun, was das politische Projekt anstrebte und weitgehend nicht liefern konnte.
Das Prompt-Regime
Das ist auch ein Kategorienwechsel in dem, was Software ist. Konventionelle Software ist ein Artefakt: etwas, das gebaut, verpackt, signiert, verteilt, installiert und ausgeführt wird. Das Produkt des Anbieters ist das Binary, der Quellcode-Tarball oder das Container-Image. Die Nutzer besorgen sich eine Kopie und verwenden sie. Änderungen sind eine eigene Tätigkeit, die nebenbei stattfindet (oder auch nicht).
Im Prompt-Regime verschiebt sich, was der Anbieter als kanonisches Produkt herstellt. Es ist nicht mehr nur das Artefakt. Immer öfter ist es eine Beschreibung (ein Prompt, ein Manifest, ein Rezept), aus der das lokale Modell des Nutzers die Instanz des Artefakts erzeugt, die er tatsächlich ausführt. Der Anbieter liefert weniger als früher. Die lokale Umgebung erzeugt mehr.
Sie können sich das, mit etwas Vorsicht, wie beim Kochen vorstellen. Wenn Sie kochen, ist ein Rezept eine Beschreibung, aus der Sie als Koch mit lokalen Zutaten in einer lokalen Küche eine Mahlzeit machen. Gleiches Rezept, andere Köche, andere Mahlzeiten. Das Rezept ist kanonisch und lässt sich teilen. Die Mahlzeit ist lokal und wird einmal gegessen. Konventionelle Software war die Mahlzeit: zentral hergestellt und zum Verzehr verteilt. Immer öfter liefern wir das Rezept aus.
Die Unterscheidung zwischen Rezept und Mahlzeit entspricht der zwischen Urheber und Realisierung. Verschiedene lokale Realisierungen derselben kanonischen Beschreibung sind beim Kochen normal und bei Software aus Prompts strukturell angelegt. Allerdings verträgt Kochen Abweichungen recht gut, Software weniger. Ein leicht danebenliegendes Rezept ergibt eine etwas schlechtere Mahlzeit. Ein leicht danebenliegender Prompt kann kaputte Software ergeben. Die Verschiebung von der Mahlzeit zum Rezept ist real, aber sie bringt Anforderungen mit sich, die das Kochen nicht kennt.
Die Verschiebung in der Architektur
Die Verschiebung ist schon sichtbar: Rewritables, Artifacts, mit Vibe Coding gebaute Apps. Sie können das so beschreiben: „Die Softwareverteilung wandert von Artefakten zu Anweisungen“, denn das sagt Ihnen, was auf menschlicher Ebene tatsächlich passiert. Menschen, die ihre Software nicht ändern konnten, können es jetzt. Diese Fähigkeit wurde ihnen versprochen. Sie kam nur von unerwarteter Seite, zu Bedingungen, die niemand gewählt hat, und mit Einschränkungen, die niemand entworfen hat.
Aus dem Englischen übersetzt: zum Originalbeitrag