Offener Code wird Arbeitsmaterial für Agenten

Warum sich die Rechnung für Individualität verändert

Über Jahre waren Standardfunktionen bezahlbar, während jede Besonderheit Konzeption, Entwicklung, Integration und Wartung nach sich zog. Viele Händler wählten deshalb dieselben Bausteine, obwohl ihr eigenes Geschäft mehr brauchte. Selbst ein wirtschaftlich sinnvoller Bedarf konnte unter der Schwelle bleiben, ab der sich eine individuelle Umsetzung lohnte.

Meine These: Agentische Entwicklung verschiebt diese Schwelle. Wenn Software Werkzeuge, Datenmodelle und vorhandenen Quellcode bearbeiten kann, lassen sich mehr Anpassungen mit demselben Team untersuchen und umsetzen. Open Source verstärkt diesen Effekt, weil das Team nicht nur beschreiben muss, was ein geschlossenes System können sollte. Es kann die relevante Stelle lesen, ändern, prüfen und weiterverwenden. Die Kombination kann Individualität erschwinglich machen, die bisher an Entwicklungskosten gescheitert ist.

Agenten machen mehr Ideen baubar. Ob sich eine Anpassung lohnt, entscheidet die Rechnung über ihre ganze Lebensdauer: Entwurf, Anbindung, Betreuung und spätere Änderungen.

Der Agent kann bis zur Ursache lesen

Meine Erwartung an einen offenen Kern beruht auf einem einfachen Mechanismus: Ein Coding-Agent kann die Preisberechnung vollständig lesen, den Shop lokal starten und seine Änderung am tatsächlichen Bestellweg erproben. Er muss den Zusammenhang zwischen einem Datenfeld, einer Rabattregel und der Bestellung nicht aus einer kurzen API-Beschreibung erraten. Menschen können denselben Weg nachvollziehen.

Das erleichtert eine bestimmte Art von Arbeit: Ein Händler beschreibt eine Branchenregel, der Agent sucht die betroffenen Stellen und baut eine Erweiterung. Die Agentur sieht früh, wo der Vorschlag in vorhandene Logik eingreift. Meine These ist, dass dieser Zugriff die Zahl wirtschaftlich erreichbarer Anpassungen erhöht. Der Vorteil wird umso größer, je stärker eine Aufgabe vom Inneren des Systems abhängt.

In „When Code Writes Code“ habe ich 2025 beschrieben, wie sich meine Arbeit vom Schreiben zur Gestaltung und Prüfung verschiebt. Anforderungen, Architektur und Abnahme bekommen mehr Gewicht, wenn der erste Entwurf schneller vorliegt. [S77, S78]

Drei Arten von Offenheit

Offenheit hilft an unterschiedlichen Stellen. Ein offenes Protokoll gibt Systemen gemeinsame Regeln für den Austausch. Open-Source-Software lässt sich unter ihrer Lizenz lesen, nutzen, verändern und weitergeben. Offene Modellgewichte machen trainierte Parameter zugänglich und eröffnen damit weitere Betriebs- und Anpassungsmöglichkeiten.

Für KI beschreibt die Open Source Initiative in ihrer Definition 1.0, welche Freiheiten und Informationen dazugehören. Neben Parametern zählen Code und die nötigen Informationen zu Trainingsdaten. Damit haben Unternehmen einen Bezugspunkt, um verschiedene Veröffentlichungen und ihre Nutzungsrechte einzuordnen. [S86]

Ein Händler kann diese Möglichkeiten passend kombinieren: einen offenen Commerce-Kern, eine eigene Agentenumgebung und einen kommerziellen Modellservice. Ein anderes Team betreibt offene Gewichte auf eigener Hardware. Die Wahl richtet sich nach Aufgabe, Schutzbedarf, vorhandener Kompetenz und Gesamtkosten.

Beim Selbstbetrieb gehören Hardware, Energie, Auslastung und Betreuung in die Rechnung. Beim Modellservice zählen Preis, Datenverarbeitung und Wechselmöglichkeiten. Eine bewusste Kombination gibt dem Unternehmen Freiheit dort, wo sie für sein Geschäft wichtig ist.

Offener Commerce hat bereits eine Basis

Open Source ist im Handel längst Infrastruktur. Shopwares öffentliches Repository enthält den Commerce-Kern unter MIT-Lizenz und verweist auf mehr als 3.100 Erweiterungen im Ökosystem. Die Shopware CLI stellt Werkzeuge für lokale Entwicklungsumgebungen und die Prüfung von Erweiterungen bereit. Damit existiert das Arbeitsmaterial, an dem Händler, Agenturen und ihre Coding-Agenten ansetzen können. [S150, S151]

Die neue Dynamik entsteht aus der Verbindung mit Coding-Agenten. In meinen Beiträgen von 2026 untersuche ich offene Modelle an Commerce-Aufgaben und in lokalen Entwicklungsumgebungen. Die beiden Händlerfälle im nächsten Kapitel zeigen den wirtschaftlichen Anlass: Ein neues ERP soll ein Altsystem ablösen, ein zuvor zu teurer Systemwechsel bekommt einen Umsetzungsweg. [S76, S91]

Auch die verfügbaren Werkzeuge werden breiter. Mozillas Bericht vom September 2026 beschreibt offene Modelle mit unterschiedlichen Stärken. GitHubs Octoverse 2025 zählt mehr als 4,3 Millionen KI-bezogene Repositories. Für den Händler entsteht daraus eine Auswahl an Modellen und Entwicklungswerkzeugen. Was davon eine Erweiterung beschleunigt, entscheidet sich an seinem eigenen Code und seiner Aufgabe. [S92, S93]

Architektur im Experiment: VEYNDO

VEYNDO ist ein selbst betreibbares Projekt mit einsehbarem Code (source available). Dort probiere ich aus, wie weit sich anpassbarer Commerce treiben lässt, wenn bestehende Erweiterungen den Entwurf nicht begrenzen. Im App Studio arbeiten Menschen und Coding-Agenten an einem ausführbaren Manifest. Speichern, private Vorschau und ein unveränderliches Release sind getrennte Schritte. Die Architektur macht Änderungen besprechbar, bevor sie öffentlich wirksam werden. [S112]

In beiden Projekten entsteht dadurch ein Arbeitsplatz, an dem ein Agent Quellen lesen, Vorschläge vorbereiten und Menschen die Wirkung einer Änderung zeigen kann. [S111, S124, S125]

Wo sich der Engpass hinbewegt

Bei einer neuen Ersatzteilsuche kann der erste Entwurf schnell vorliegen. Danach muss die Fachberatung die Zuordnung zu Maschinenrevisionen beurteilen, die Agentur den Anschluss an den Kundenpreis und die Shop-Betreuung das spätere Update. Diese Arbeit bestimmt, wie viel der schnellere Entwurf im Betrieb wert ist.

Die Forschung zeigt, wie stark der Kontext zählt. METRs Studie mit 16 erfahrenen Open-Source-Entwicklern und 246 Aufgaben fand für Werkzeuge aus dem frühen Jahr 2025 eine um 19 Prozent längere Bearbeitungszeit. Die Folgestudie von 2026 konnte wegen Auswahlverzerrungen keine verlässliche aktuelle Beschleunigung ermitteln. Für Teams lohnt sich deshalb die eigene Messung an vertrauten Aufgaben. [S87, S88]

Demirer, Musolff und Yang untersuchen in ihrem im September 2026 überarbeiteten NBER-Arbeitspapier Daten von über 500.000 GitHub-Entwicklern. Ihre beobachtungsbasierte Event-Studie schätzt kumulierte Effekte von bis zu 240 Prozent mehr Commits, 80 Prozent mehr Projekten und 30 Prozent mehr Releases. Zwischen mehr geschriebenem Code und mehr ausgelieferter Software liegt also weiterhin erhebliche Arbeit. [S118]

Rechnen Sie deshalb vom Kundenproblem bis zur gepflegten Lösung: Idee, Umsetzung, Anbindung, Abnahme und Updates. Genau dort liegt die Chance für offene Plattformen und gute Agenturen. Sie können aus einem schnell gebauten Entwurf eine Besonderheit machen, die sich für den Händler dauerhaft lohnt.

Gemeinsame Infrastruktur, eigener Wert

Wenn ein Team eine allgemein nützliche Schnittstelle verbessert oder einen Fehler behebt, kann die Änderung in den gemeinsamen Kern zurückfließen. Andere Unternehmen bauen darauf auf und tragen ihrerseits Verbesserungen bei. So wird weniger Grundlagenarbeit wiederholt, und mehr Zeit bleibt für die Besonderheiten des eigenen Geschäfts.

Menschen pflegen den gemeinsamen Kern. Unternehmen stärken ihn durch Wartung, Finanzierung und gut beschriebene Beiträge. Darauf bauen ihre eigenen Angebote auf: mit besonderem Produktwissen, passender Beratung und einer Experience mit eigener Handschrift.

Zwei Händler aus meinem Umfeld nutzen diese Freiheit bereits für sehr unterschiedliche Vorhaben. Ihre Beispiele führen von der Architektur zur Arbeit im eigenen Unternehmen.