Retouren im Online-Shop — das Paket ist der einfache Teil

Der Satz fiel nebenbei, wie diese Sätze immer fallen: „Wir brauchen eine Retourenfunktion.“ Bei epamano — einem Online-Shop für hochwertige Türbeschläge — lief die Abwicklung von Rücksendungen bis dahin über E-Mail-Pingpong. Also: Retourenfunktion. Klingt nach einem Feature.

Ist es aber nicht. Aus so einem Ein-Satz-Wunsch wird entweder ein Knopf, den keiner durchdacht hat — oder ein belastbarer Geschäftsprozess. Der Unterschied liegt nicht in der KI, die heute den Code schreibt. Er liegt in den Schranken, durch die sie dabei laufen muss. Genau dabei schaue ich dir in dieser Notiz über die Schulter — live, mitten aus einem laufenden Projekt.

Stand heute, 20. Juli 2026, auf meinem Bildschirm — kein nachgestelltes Marketing-Bild. Klick aufs Bild für die Vollansicht.

Hinter dem Paket: Widerruf, Disposition, Erstattung

Für deine Kundin ist die Retoure ein Paket mit Rücksendeetikett. Für deinen Shop ist sie ein Prozess mit Zuständen, Fristen und Entscheidungen:

• Widerruf: Die Kundin erklärt ihn — formlos, per Mail, übers Formular. Ab jetzt laufen Fristen. Und jemand muss den Eingang bestätigen.
• Prüfung und Disposition: Die Ware kommt zurück. Originalverpackt? Montagespuren? Geht sie zurück in den Bestand, wird sie B-Ware, oder ist sie ein Fall für die Entsorgung? Jemand entscheidet — und die Entscheidung muss dokumentiert sein.
• Erstattung: Wie viel, wann, auf welchem Weg. Volle Summe oder Abzug wegen Wertminderung?
• Kommunikation: Bei jedem Schritt eine Nachricht an die Kundin — Widerruf angekommen, Ware erhalten, Erstattung unterwegs. Sonst entsteht genau das E-Mail-Pingpong, das das Modul abschaffen soll.

Das Modul, das dafür gerade entsteht, begleitet den Vorgang vom Eingang bis zum Abschluss und dokumentiert ihn lückenlos — für die Kundin genauso wie für den Shopbetreiber. Die Build-Liste im Screenshot zeigt, was hinter dem harmlosen Wort „Retourenfunktion“ wirklich steckt: Datenbank-Migration, Fristen-Typen, E-Mail-Vorlagen, eine Versand-Warteschlange, Admin-Schnittstelle, drei Cron-Routen, ein Backfill-Skript, Integrationstests.

Den Code dafür schreibe allerdings nicht ich. Jedenfalls nicht Zeile für Zeile.

Zehn Agenten, ein Live-Zustand

Das Rücknahmemodul für den Shopify-Shop entsteht mit Shepherd — einer Mission Control für KI-Coding-Agenten. Shepherd wird bei der Erwins Enkel GmbH entwickelt; ich arbeite an der Entwicklung mit und setze es bei manu·fare täglich produktiv ein, obwohl es offiziell noch im Pre-Release steckt.

Der Screenshot oben ist der Live-Zustand von heute. Was drauf steht:

• HERD 10: Zehn Agenten laufen parallel, jeder in seinem eigenen, isolierten Arbeitsbereich — drei davon im Shopify-Projekt. Stell dir mehrere Gesellen an getrennten Werkbänken vor: Jeder hat seine eigene Kopie des Werkstücks und kommt den anderen nicht in die Quere. Erst was fertig geprüft ist, wandert zurück ins gemeinsame Regal.
• Task-746, „Rücknahme-Disposition“: seit 2 Tagen und 19 Stunden in Arbeit, als Pull Request #271 im Review — Runde 2 von 3, alle 14 automatischen Checks grün.
• Task-750: ein anderer Task desselben Shop-Projekts, dessen Plan gerade die fünfte Überarbeitungsrunde dreht — dazu gleich mehr.
• Task-729: ein Agent, der eine Anforderung zur automatischen Rechnung erst einmal recherchiert, statt sie zu bauen.

Ein Task ist hier nicht „ein Prompt“. Er ist ein Auftrag mit Lebenslauf: Plan, Review, Umsetzung, Pull Request, Abnahme. Und die erste Station dieses Lebenslaufs ist die wichtigste.

Plan-Gate: erst überzeugen, dann coden

Bevor ein Agent bei Shepherd eine Zeile Code schreibt, muss sein Plan durch ein eigenes Review: Ein unabhängiger Prüf-Agent liest den Plan adversarial — nur lesend, mit dem ausdrücklichen Auftrag, Schwächen zu finden. Erst wenn der Plan das übersteht, wird gebaut.

Wie ernst das gemeint ist, zeigt Task-750 im Screenshot: Der Plan für eine Mobile-Optimierung ging fünfmal zurück in die Überarbeitung — „REWORK 5/5“ —, bevor gebaut werden durfte. Fünf Runden Nacharbeit am Plan, bevor auch nur eine Zeile Code entstanden ist.

Und der Mensch sitzt mit am Gate: Den fertig geprüften Plan lese ich selbst, bevor ich ihn freigebe — oder mit Anmerkungen zurückschicke. Das kostet mich pro Task ein paar Minuten Lesezeit. Verglichen mit dem, was ein falsch verstandener Auftrag an Umbau kostet, ist das geschenkt.

Und manchmal ist das Ergebnis dieser Phase nicht „bauen“, sondern „erst mal verstehen“. Task-729 trägt das Etikett RESEARCH und den für mich schönsten Satz des ganzen Screenshots: „Ich verstehe nicht, warum die Kundin das anfordert.“ Der Agent baut nicht auf Verdacht — er will erst das Warum. Und das Warum kann ihm kein Modell liefern. Das ist meine Arbeit: erklären, welches Problem hinter der Anforderung steckt, wie der Ablauf im Laden wirklich aussieht, was die Kundin am Ende in der Hand haben soll. Anforderungen klären ist Menschenarbeit — daran ändern auch zehn Agenten nichts.

Drei Schranken bis zum Shop

Zwischen „Agent hat Code geschrieben“ und „läuft im Shop“ stehen bei diesem Projekt drei getrennte Schranken:

1. Plan-Review: Der Umsetzungsplan wird adversarial geprüft und überarbeitet, bevor Code entsteht.
2. Automatische Checks: Tests und Prüfungen, die maschinell laufen. Beim Rücknahme-Task: 14 von 14 grün. Erst dann lohnt sich der menschliche Blick überhaupt.
3. Code-Review am Pull Request: Sobald die Checks grün sind, wird der komplette Änderungsstand noch einmal geprüft. Task-746 steht dort gerade in Runde 2 von 3.

Falls dir das bekannt vorkommt: Es ist das Vier-Augen-Prinzip, das du aus der Buchhaltung kennst — niemand bucht unkontrolliert, auch nicht der Schnellste im Raum. Hier gilt es eben für Code.

Und selbst danach geht nichts von allein live: Der letzte Schritt — den Pull Request übernehmen und ausrollen — bleibt eine menschliche Entscheidung. Stand heute ist das Rücknahmemodul genau dort: im Review, noch nicht im Shop.

Weder Chat-Fenster noch Lastenheft

Es kursieren gerade zwei bequeme Erzählungen über Software und KI. Die erste: KI-Coding heißt Chat-Fenster auf, Prompt rein, Code raus, live damit. Das produziert beeindruckende Demos — und Prozesse, denen du keine Kundendaten anvertrauen willst. Ohne Plan-Review, ohne Tests, ohne Code-Review ist Agenten-Code genau das, was Code ohne diese Schranken schon immer war: ungeprüft. Nur entsteht er jetzt schneller.

Die zweite Erzählung ist die alte: Individualsoftware heißt Agentur, Lastenheft, Angebot, drei Monate Projektlaufzeit, Change Requests. Auch das stimmt so nicht mehr. Das Rücknahmemodul steht nach Tagen im Review, nicht nach Quartalen — und jede Änderung bleibt ein kleiner, geprüfter Schritt statt eines großen Wurfs. Was von der Agentur-Welt bleiben muss, ist die Disziplin. Was wegfallen darf, ist die Trägheit.

Fazit

Aus einem Satz — „Wir brauchen eine Retourenfunktion“ — wird gerade ein Geschäftsprozess: Widerruf, Disposition, Erstattung, Kommunikation, lückenlos dokumentiert. Geschrieben von Agenten, geprüft in drei Schranken, freigegeben von Menschen. Stand heute: im Review, noch nicht live. Auch das gehört zur Ehrlichkeit eines Werkstattberichts.

Meine Arbeit sieht dabei anders aus als früher: Ich tippe weniger Code und kläre mehr Warum — Anforderungen schärfen, Pläne freigeben, Reviews lesen, abnehmen. Genau das meine ich mit „Echte Transformation ist Handarbeit“. Die Werkzeuge sind neu. Die Verantwortung bleibt Handarbeit.

Und jetzt du: Welcher Ein-Satz-Wunsch liegt bei dir seit Monaten herum? „Die Rechnungsfreigabe muss digital.“ „Das Onboarding dauert zu lange.“ „Die Tickets landen im falschen Topf.“ Der Weg ist derselbe wie bei der Retourenfunktion — egal, ob dahinter Shopify, Autotask, Lexoffice, ITglue, SAP oder Microsoft 365 steckt: aus dem Satz einen Prozess machen, aus dem Prozess Aufgaben, und jede davon durch Schranken schicken. Shepherd selbst kannst du dir übrigens ansehen und einsetzen — der Code liegt offen auf GitHub.

Der Unterschied zwischen einer KI-Demo und einem Geschäftsprozess ist nämlich nicht das Modell. Es sind die Schranken — und die sind Handarbeit.