Der ROI agentischer Webentwicklung: Wie Claude Code die E-Commerce-Ökonomie verändert

In jedem E-Commerce-Team, mit dem ich gearbeitet habe, gibt es irgendwo dasselbe Dokument: eine Liste von Funktionen, die dem Unternehmen offensichtlich helfen würden, grob nach Priorität sortiert – und vielleicht zwei davon sind für dieses Quartal eingeplant.

Die Liste ist nicht kurz, weil es an Ideen mangelt. Sie ist kurz, weil es an Rechenzeit fehlt. Eine Funktion benötigt eine bestimmte Anzahl an Entwicklungstagen, Tage kosten Geld – also wartet der Großteil der Liste.

Was sich in den letzten zwei Jahren verändert hat, ist diese zweite Zahl. Und zwar deutlich.

Was „agentisch“ hier tatsächlich bedeutet

Viele Teams haben bereits AI-Code-Completion ausprobiert, also Tools, die beim Tippen die nächste Zeile vorschlagen. Das ist für die Tippgeschwindigkeit nützlich. Am Budget ändert es nichts, denn das Tippen war nie der teure Teil.

Claude Code arbeitet anders. Es ist ein agentisches Tool, das praktisch Zugriff auf den gesamten Codebestand hat und eigenständig handelt. Beschreiben Sie einen Bug, verfolgt es die Ursache im Code und behebt das Problem. Beschreiben Sie ein Feature, plant es den Ansatz, bearbeitet alle nötigen Dateien, führt die Testsuite aus, behebt Fehler und liefert einen Branch zur Prüfung ab.

Sie können es im Terminal, über eine native VS Code Extension oder JetBrains-Plugin, als Desktop-App oder im Browser ausführen. Es läuft auch headless in CI per Print-Modus (claude -p), was wichtiger ist, als es zunächst klingt – dazu später mehr.

Ein Praxisbeispiel: Aus fünfzehn Tagen werden zwei

Prozentuale Produktivitätsangaben helfen bei Budgetfreigaben wenig, daher ein konkretes und alltägliches Beispiel: ein „Frequently Bought Together“-Bundle-Modul auf der Produktseite, mit automatischer Bundle-Preisberechnung, bestandsabhängiger Logik und One-Click-In-den-Warenkorb.

Nichts Kompliziertes. Die meisten Shops wollen das. Viele haben es nicht – aus bekannten Gründen.

Der klassische Ansatz – rund 15 Arbeitstage

• Tage 1–2 · Discovery. Jemand liest den bestehenden Katalog-, Warenkorb- und Preiscodes, um zu verstehen, wie Varianten, Steuern und Rabatte aktuell zusammenspielen.
• Tage 3–4 · Spezifikation. Technische Spezifikation, Datenmodell-Entscheidungen, Designübergabe, Aufwandsschätzung.
• Tage 5–9 · Backend. Die Empfehlungsabfrage, ein neues Endpoint, Bundle-Preisregeln und deren Zusammenspiel mit bestehenden Aktionen.
• Tage 10–12 · Frontend. Komponente, Responsive States, Lade- und Fehlerbehandlung, Warenkorb-Integration.
• Tag 13 · Tests. Wird meist als Erstes gestrichen, wenn der Zeitplan rutscht.
• Tag 14 · QA und Bugfixes. Ausverkaufte Varianten, Mehrwährungen, Bruttopreise.
• Tag 15 · Deploy. Überwachen und dokumentieren.

Zwei bis drei Personen sind über drei Kalenderwochen beteiligt. Bei den meisten Agentur- oder internen Mischsätzen ist das ein fünfstelliges Feature – genau deshalb steht es noch auf der Liste.

Dasselbe mit einem Agenten — etwa 2 Tage.

Tag eins, Vormittag. Jemand erstellt eine saubere Spezifikation: Geschäftsregeln, Preislogik, relevante Sonderfälle. Claude Code liest den Codebestand und liefert einen Plan zurück — welche Dateien betroffen sind, wie die Anbindung an die bestehende Warenkorb-Logik erfolgt, wo Risiken gesehen werden. Sie korrigieren den Plan, bevor Code entsteht. Diese neunzig Minuten sind der wirkungsvollste Teil des Projekts und beruhen vollständig auf menschlicher Einschätzung.

Tag eins, Nachmittag. Die Arbeit läuft parallel. Claude Code bietet dazu mehrere eingebaute Möglichkeiten: Subagenten für abgegrenzte Aufgaben, Agent-Ansicht zur Steuerung von Hintergrund-Sessions, dynamische Workflows für größere Aufgaben und Worktrees, die jeder Session ein eigenes Git-Checkout geben, damit parallele Arbeiten sich nicht überschneiden. Es gibt außerdem einen experimentellen Agenten-Team-Modus mit gemeinsamer Aufgabenliste, der standardmäßig deaktiviert ist und als frühes Stadium zu betrachten ist.

Ein Arbeitsstrang für Endpoint und Preislogik, einer für das Frontend-Element, einer für Tests. Die Discovery, die manuell zwei Tage dauerte, war in etwa zwanzig Minuten erledigt, weil der Agent den Codebestand gelesen hat, statt ihn erst zu erlernen.

Tag zwei, Vormittag. Review. Hier fließt jetzt die Zeit Ihrer Senior Engineers: Preislogik gegen reale Aktionsregeln prüfen, klären, was passiert, wenn ein Bundle-Artikel während einer Session ausverkauft ist, Steuerbehandlung verifizieren. Korrekturen gehen zurück und kommen in Minuten wieder.

Tag zwei, Nachmittag. QA, Staging, Deployment. Tests und Dokumentation liegen bereits vor, da deren Erstellung kaum Aufwand verursacht hat.

Wohin die dreizehn Tage gingen

Es lohnt sich, das anzusehen, denn es erklärt die gesamte Verschiebung:

• Codebase-Archaeologie. Ein Agent liest Code deutlich schneller, als ein Mensch ihn versteht.
• Boilerplate — Endpunkte, Grundgerüst, Statusverwaltung, Fehlerzustände.
• Testschreiben, jetzt so günstig, dass es nicht mehr zur Verhandlung steht.
• Dokumentation, die zum Nebenprodukt wird statt zur Aufgabe.
• Die Debugging-Phase am Ende, da der Agent die Tests selbst ausführt und Fehler behebt, bevor jemand anderes den Branch sieht.

Und was sich nicht verkürzen ließ: Entscheiden, was gebaut wird, Regeln definieren und das Ergebnis prüfen. Diese Aufgaben blieben menschlich — und machen nun einen deutlich größeren Anteil der Arbeit aus.

Das ist kein Gedankenexperiment.

Rakuten — mit über 70 Unternehmen in E-Commerce, Travel, Fintech und Kommunikation — hat seine Zahlen mit Anthropic veröffentlicht.

Time to market

24 Tage → 5

Reduktion

79%

Autonomes Programmieren

7 Stunden am Stück

Code-Genauigkeit

99.9%

Die Angabe von sieben Stunden stammt aus einem umfangreichen Open-Source-Refactoring-Projekt, das vollständig durchgeführt wurde. Die Änderungen am Code waren dabei zu 99,9 % korrekt. Das oben gezeigte Verhältnis von 15 zu 2 ist also bereits in größerem Umfang Realität.

Andere veröffentlichte Ergebnisse fallen moderater aus, was man wissen sollte. Die Entwicklungsagentur Boldare meldete eine Sprint-Velocity-Steigerung um bis zu 31 % in einem Quartal, mit KI-Anteil an geschätzten 75–85 % des neuen Codes und der Tests. HubSpot berichtet, dass komplexe technische Fehlerbehebung von drei bis fünf Tagen auf unter eine Stunde sank und Claude Code eine Frontend-Migration bei einem Rebranding beschleunigte, die sonst Monate gedauert hätte. HubSpot weist darauf hin, dass diese Zahlen aus interner Analyse ausgewählter Umsetzungen stammen und als Beispiele zu verstehen sind.

Die Menge ist entscheidend, nicht die Einsparung

Das wird in Kostendiskussionen oft übersehen.

Ein Entwickler arbeitet an Features dieser Größenordnung. Bei fünfzehn Tagen pro Feature entstehen etwa sechzehn pro Jahr. Bei durchschnittlich drei Tagen pro Feature — manche schneller, manche langsamer — liegt die Zahl bei rund achtzig.

Lesen Sie das als Verhältnis, nicht als Kapazitätsprognose. Kein Entwickler arbeitet 240 Tage im Jahr ausschließlich an neuen Features — es gibt Wartung, Vorfälle, Meetings, Urlaub. Beide Zeilen sind durch die gleiche Annahme aufgebläht, das Verhältnis bleibt aber bestehen, auch wenn keine der Zahlen einem echten Sprint-Board standhält. Und achtzig Features pro Jahr übersteigen die Review-Kapazität der meisten Teams, was eine Einschränkung ist, auf die ich zurückkomme.

Die Teamgröße blieb gleich. Das Budget blieb gleich. Was sich geändert hat, ist die Zahl der Versuche, die Sie unternehmen können.

Das ist entscheidend, weil Conversion-Optimierung im Kern ein Suchproblem ist. Niemand weiß im Voraus, welche Änderung die Kennzahl bewegt. Sie finden es heraus, indem Sie ausliefern und messen – und das Team, das sich mehr Versuche leisten kann, findet die bessere Lösung schneller.

Überlegen Sie, was ein Shop plötzlich umsetzen kann:

• Benachrichtigungen bei Wiederverfügbarkeit für jede ausverkaufte Variante
• Ein Bundle-Builder oder ein Modul „Look vervollständigen“
• Selbstbedienungs-Retouren und -Umtausch, wodurch Support-Tickets entfallen
• Größentabellen mit echten Passformdaten, die die Retourenquote senken
• Strukturierte Daten für den gesamten Katalog, um Suchergebnisse aufzuwerten
• Eine Wunschliste, die bei Preisnachlässen per E-Mail informiert
• Page-Speed-Optimierung bei den Templates mit dem größten Bedarf
• Verbesserungen beim Gast-Checkout und gezielte Wiedergewinnung abgebrochener Warenkörbe
• Interne Preistools, damit das Merchandising keine Tickets mehr für Regeländerungen anlegen muss

Für sich genommen sind das kleine Hebel, jeder bringt einen Bruchteil eines Prozents. Über ein Jahr hinweg summieren sie sich – und genau das hat die alte Kostenstruktur verhindert. Mit jeweils fünfzehn Tagen pro Punkt ist das eine mehrjährige Roadmap. Mit drei Tagen pro Punkt sind es ein paar Quartale.

Ein Gedanke dazu: Ein Wettbewerber, der pro Quartal vier Experimente fährt, während Sie zwölf schaffen, ist nicht dreimal langsamer. Er lernt dreimal langsamer – und diese Lücke schließt man nicht durch Neueinstellungen.

Drei Dinge jenseits der reinen Geschwindigkeit

Architektur-Kontext bleibt im Unternehmen

Wenn ein erfahrener Entwickler geht, ist der eigentliche Verlust meist Kontext, nicht Code – also warum Dinge so gebaut wurden. Claude Code hilft hier mit einer CLAUDE.md-Datei im Projektstamm, in der Architekturentscheidungen, bevorzugte Bibliotheken, Konventionen und Sicherheitsstandards dokumentiert sind. Jede Sitzung liest diese Datei, sodass generierter Code Ihre Hausregeln befolgt und nicht generische Muster.

So bleibt die Erfahrung von Senior-Entwicklern erhalten. Das verkürzt auch das Onboarding deutlich, weil neue Teammitglieder die Codebasis direkt befragen können, statt wochenlang Absichten zu rekonstruieren.

Es löst auch serverseitige Komplexität, nicht nur Oberflächen

Die berechtigte Skepsis vieler CTOs: Komponenten rendern ist das eine – aber was ist mit den Teilen, die nachts wachhalten? Tatsächlich ist der Agent gerade dort am nützlichsten, weil das Lesen von fremdem Code hier am meisten Zeit kostet. Zum Beispiel beim Abbilden von Order-Routing-Regeln über mehrere Regionen, beim Aufsetzen einer Hintergrund-Queue für einen Massenimport oder beim Nachvollziehen, warum eine Promotion über drei Services hinweg falsch gestapelt wird. Das sind Kontextprobleme, keine Tipp-Probleme.

Arbeit, die ohne direkte Zuweisung läuft

Da es headless mit claude -p läuft, können Sie es in GitHub Actions oder jede CI-Pipeline einbinden und an bestehende Events koppeln – etwa bei jedem Pull Request für einen automatischen Erst-Review, bevor ein Mensch prüft, oder bei fehlgeschlagenen Builds, damit Fehler bereits voranalysiert sind. Darüber hinaus: wöchentliche Abhängigkeits- und Sicherheitsprüfungen, Dokumentationsabgleich nach Merges. Geplante Routinen laufen in der Cloud, unabhängig davon, ob jemand am Rechner sitzt.

Das ist eine ganze Kategorie von Aufgaben, für die bisher entweder eine eigene Person nötig war – oder die schlicht niemand erledigt hat.

Was Sie ehrlich einplanen sollten

Drei Faktoren entscheiden, ob Sie die oben beschriebenen Ergebnisse erreichen oder nur einen enttäuschenden Piloten.

Review wird zum Engpass. Generierung ist günstiger geworden, Review nicht. Ein häufiges Muster: In den ersten Wochen steigt die Produktivität stark, dann sinkt sie, sobald Code schneller ausgeliefert wird, als das Team ihn prüfen kann – was zu Nacharbeit an denselben Features führt. Wenn Sie den Output steigern, ohne den Review-Prozess anzupassen, verschieben Sie den Engpass nur. Stärken Sie CI-Gates und automatisierte Erst-Reviews bevor das Volumen steigt, nicht danach – wir haben unsere Review-Policy für Agent-Code und die wichtigsten Security-Patterns für generiertes PHP dokumentiert.

Unverbindliche Nutzung verpufft. Teams, die ihre Arbeitsweise festlegen – eine gepflegte CLAUDE.md, Planung vor dem Coden, klare Regeln, was ein Agent unbeaufsichtigt ändern darf – behalten die Effizienzgewinne. Teams, die es den Engagierten überlassen, sehen einen Peak und dann einen schleichenden Rückgang. Es ist eher eine Prozessumstellung als ein Toolkauf.

Die Qualität der Spezifikation wird zum Limit. Der Zwei-Tage-Build funktioniert nur, weil jemand eine gute Spezifikation geschrieben hat. Unklare Vorgaben führen schnell zu überzeugend falschen Ergebnissen. Die knappe Fähigkeit verschiebt sich vom Coden hin zum präzisen Definieren, was gebaut werden soll – das sollten Sie bei Einstellung und Entwicklung im Blick haben.

Was das für Sie bedeutet

Die sinnvolle interne Perspektive ist nicht: „Wir können das gleiche mit weniger Budget umsetzen.“ Sondern: Eine Roadmap, die Sie bisher als unrealistisch abgetan hätten, lohnt jetzt eine echte Kalkulation.

Beide Sichtweisen sind vertretbar. Die zweite schlägt sich meist im Umsatz nieder.

Eine Roadmap kalkulieren, die bisher als unrealistisch galt?

So arbeiten wir. Wenn Sie einen Backlog haben, der an der Kalkulation scheitert, sagen wir Ihnen, welche Teile mit den neuen Zahlen erreichbar sind – das ist AI- und ML-Entwicklung sowie E-Commerce-Entwicklung für uns; die Seite Applied-AI-Leistungen beschreibt den Rest unseres Produktionsbetriebs. Sprechen Sie uns an.