Wie ich allein ein PrestaShop-Modulgeschäft mit einer Flotte von AI-Agenten führe

Vor ein paar Monaten stellte ich fest, dass meine AI-Agenten 154 Git-Repositorys dirty zurückgelassen hatten - und die Lösung war kein besserer Prompt, sondern ein Organigramm.

Nicht 154 Dateien. 154 Repositorys. Dutzende Modul-Codebasen, in denen uncommitted changes übereinanderlagen - manche halb fertige Experimente, manche wirklich gute Arbeit, die nur nie ausgeliefert wurde. Verschiedene Agenten hatten zu unterschiedlichen Zeiten jeweils ein Stück erledigt und waren weitergezogen. Niemand hatte committed. Niemand hatte aufgeräumt. Die Arbeit war nicht wirklich verloren. Es war schlimmer als verloren. Sie war verheddert, und ich konnte nicht mehr erkennen, wessen Hände was angefasst hatten.

Der Reflex, wenn ein AI-Agent etwas Dummes tut, ist: den Prompt reparieren. Eine Zeile hinzufügen. "Committe deine Arbeit immer, wenn du fertig bist." "Lass Repositorys nie dirty zurück." Ich habe das versucht. Es hält nicht - und sobald man versteht, warum, verändert sich die ganze Art, wie man mit diesen Werkzeugen arbeitet.

Das hier ist ein Bericht darüber, wie ich den Shop wirklich betreibe: eine Person, ein Katalog mit deutlich über hundert PrestaShop-Erweiterungen, veröffentlicht in sechs Sprachen, dazu eine Handvoll echter Onlineshops, die ich selbst mit denselben Modulen betreibe. Ein großer Teil der wiederkehrenden Entwicklungs- und Supportarbeit läuft durch eine Flotte von AI-Agenten - immer unter meiner Kontrolle; Architektur, Release-Entscheidungen und die finale Freigabe bleiben bei mir. Was folgt, ist der Teil, den niemand auf die Verkaufsseite schreibt - die konkreten Fehler, die diese Agenten gemacht haben, und die Mechanik, die ich gebaut habe, damit sie sie nicht zweimal machen können.

Der Agent ist ein brillanter Mitarbeiter mit totaler Amnesie

Das mentale Modell, das tatsächlich funktioniert, ist dieses: Ihr AI-Agent ist ein wirklich ausgezeichneter Auftragnehmer - schnell, belesen, unermüdlich - mit null Erinnerung daran, jemals zuvor für Sie gearbeitet zu haben. In jeder Sitzung kommt ein brillanter Fremder zur Tür herein. Er hat Ihre Codebasis nie gesehen. Er kennt Ihre Konventionen nicht. Er weiß nicht, dass genau das, was er gleich tun will, letzten Monat die Produktion kaputt gemacht hat, weil er nicht dabei war. Soweit sein Gedächtnis reicht, war niemand dabei.

Diese Person reparieren Sie nicht mit einem clevereren Satz Anweisungen am Eingang. Ein Prompt ist ein Gespräch. Er verdampft, wenn die Sitzung endet. Was Sie brauchen, ist das, was jede echte Organisation baut, damit sie nicht vom Gedächtnis einer einzelnen Person abhängt: dauerhaftes, schriftliches, durchgesetztes institutionelles Wissen. Onboarding-Dokumente. Runbooks. Eine Pre-Commit-Checkliste an der Wand. Leitplanken, die den falschen Schritt physisch schwer machen.

Ich schreibe keine besseren Prompts. Ich schreibe besseres Gedächtnis. Amnesie ist nur teuer, wenn man den Agenten bei jedem Betreten alles neu lernen lässt.

Das Handwerk ist also nicht Prompt Engineering. Das Handwerk ist, die Organisation um den Amnesiker herum zu bauen. Und die nützlichste Erkenntnis, die ich hatte, war diese: Jede Leitplanke in meinem Setup ist eine Narbe. Sie zeigt auf einen konkreten, datierten Moment, in dem ein Agent etwas falsch gemacht hat, ich den Schmerz gespürt habe und diesen Schmerz in eine Regel verwandelt habe, die die Umgebung für immer erzwingt. Meine Konfiguration ist keine Wunschliste. Sie ist eine Krankenakte.

Hier sind die Narben.

Narbe #1: Der Agent, der den vendor-Ordner löschte und den Shop lahmlegte

Einige meiner Module hängen von gemeinsamen internen Bibliotheken ab - Code, den ich im ganzen Katalog wiederverwende. Aus Deployment-Gründen liegen diese Bibliotheken im vendor/-Ordner jedes Moduls, werden aber von einem Sync-Skript hineinkopiert und nicht vom normalen Paketmanager verwaltet. Das ist ein ungewöhnliches Setup, und ein amnesischer Agent kann das nicht wissen.

An einem Abend im letzten Herbst musste ein Agent also eine Abhängigkeit hinzufügen, und er tat das lehrbuchmäßig Richtige: Er führte composer install aus. Der Paketmanager sah sich das Manifest an, fand einen Haufen Dateien in vendor/, die er dort nicht abgelegt hatte, und löschte sie hilfsbereit. Klassen verschwanden. Der Live-Shop begann 500er zu werfen, sobald ein Kunde eine Seite aufrief, die eines der fehlenden Traits autoloadete.

Der Agent lag nach seiner eigenen Logik nicht falsch. Er lag falsch, weil ihm mein Gedächtnis fehlte. Aus so etwas kommt man nicht zuverlässig mit einem Prompt heraus - "sei vorsichtig mit composer" ist genau die weiche Anweisung, die ein Agent unter Druck vergisst. Die Lösung ist also kein Satz. Sie ist eine Wand:

# pre-tool hook: refuse the dangerous command outright
if command matches "composer install" or "composer update":
    BLOCK
    tell the agent: "This wipes synced packages. Use
    'composer dump-autoload', then re-run the sync script."

Jetzt ist der Fehler nicht mehr verfügbar. Ein frischer Agent ohne Erinnerung an den Ausfall kann ihn trotzdem nicht reproduzieren, weil die Umgebung nein sagt, bevor Schaden entsteht. Das ist der Unterschied zwischen einem Prompt und einer Narbe: Der Prompt hofft; die Narbe erzwingt. Inzwischen habe ich eine kleine Bibliothek solcher Hooks, und jeder einzelne davon ist ein Nachmittag, den ich nicht zurückbekomme.

Narbe #2: Die 154 dirty Repositorys

Zurück zum Einstieg. Das Durcheinander entstand, weil ich ein anderes Problem gelöst hatte - viele Agenten parallel laufen zu lassen - ohne die Koordinationsschicht zu bauen, die Parallelität tatsächlich braucht.

Einen Agenten laufen zu lassen ist ein Gespräch. Eine Flotte laufen zu lassen ist Logistik, und Logistik besteht aus Problemen, die kein Prompt löst:

• Sie drosseln und hängen. Startet man fünf schwere Jobs gleichzeitig, stauen sie sich, bleiben stehen und laufen in Timeouts. Die Lösung war Infrastruktur: ein Runner, der Jobs in eine Warteschlange legt, sie über parallele Worker verteilt und jeden Lauf mit einem Watchdog überwacht, damit intensive gleichzeitige Nutzung nicht aufstaut oder einfriert. Agenten verwalten ihre eigene Kapazität nicht. Die Organisation tut es.
• Sie kollidieren. Zwei Agenten, die im selben Moment dasselbe Modul bearbeiten, beschädigen gegenseitig ihre Arbeit. Die Lösung ist ein File-Lock pro Modul - ein Agent nimmt das Modul, arbeitet daran, gibt es frei. Mit einer Wendung, die ich auf die harte Tour gelernt habe: Ein Lock, dessen besitzender Prozess tot ist, ist keine aktive Arbeit, sondern Müll. Deshalb prüft der Lock, ob sein Besitzer noch existiert, und räumt veraltete Locks automatisch weg. Ein Koordinationssystem, das an Geistern deadlockt, ist schlimmer als gar keines.
• Sie committen die Wäsche der anderen. Das war die eigentliche Wurzel der 154. Ein Agent, der seine eigene Aufgabe beendet hatte, führte sinngemäß "alles committen" aus - und fegte die unfertige Arbeit von drei anderen Agenten in denselben Commit. Also bekam der Commit-Pfad ein Gate: Ein Agent darf nur seine eigenen Dateien stagen, nie pauschal "alles hinzufügen". Er kann buchstäblich keine Arbeit committen, die er nicht gemacht hat.

Nichts davon ist clever. Es ist die langweilige Mechanik eines funktionierenden Arbeitsplatzes: einstempeln, nicht den Schreibtisch anfassen, an dem jemand mitten im Projekt sitzt, nicht für ein Paket unterschreiben, das nicht Ihnen gehört. Ich musste jedes Teil bauen, weil ein konkreter Agent an einem konkreten Tag das Gegenteil getan hat.

Koordination muss Abschluss ermöglichen, nicht einfrieren. Die Locks existieren, damit nicht zwei Agenten gleichzeitig eine Datei bearbeiten - nicht, um aus "fertiger Arbeit" "eingefrorene Arbeit" zu machen. Committen ist ein Kontrollpunkt, kein Käfig.

Dieser letzte Satz ist wichtiger, als er aussieht. Die erste Version meines Lockings war zu streng, und Agenten saßen plötzlich untätig herum und warteten auf Locks, die niemandem mehr gehörten. Ein Sicherheitssystem, das verhindert, dass Arbeit fertig wird, ist keine Sicherheit - es ist nur ein anderer Fehler. Die Regel lautet jetzt: Koordination muss Fertigwerden leichter machen als Nicht-Fertigwerden, sonst wird sie neu gebaut.

Narbe #3: Lass einen Agenten nie im Shop des Kunden lernen

Das ist die eine Regel, die ich mir nicht erst auf die harte Tour verdienen wollte. Früh hatte ein Agent "nur kurz etwas geprüft" - gegen einen Live-Shop - und die zehn Sekunden, bis ich bestätigt hatte, dass tatsächlich nichts geändert worden war, reichten aus, um das Prinzip unverhandelbar zu machen: Agenten bauen und testen zuerst auf einer Wegwerfkopie und berühren Kundenflächen erst, nachdem eine Änderung bewiesen ist.

Ein frischer Agent hat kein Gespür dafür, in welcher Umgebung er steht. Für ihn ist eine Shell eine Shell. Also trifft die Umgebung die Unterscheidung für ihn: Riskante Operationen werden standardmäßig auf disposable clones geroutet, Produktion wird als separater, geschützter Ort behandelt, und die destruktiven Gewohnheitsbefehle, die man auf einer Dev-Box ausführt (Cache-Verzeichnis leeren, Zustand zurücksetzen), werden auf allem blockiert oder umgeleitet, was echte Kunden sieht. Der Agent muss sich den Unterschied zwischen "meiner Sandbox" und "jemandes Shop" nicht merken. Die Organisation merkt ihn sich für ihn.

Das ist die eine Leitplanke, von der ich möchte, dass ein Kunde sie kennt, weil sie ihn schützt. Der Grund, warum ein Modul-Update selten mit einer Überraschung kommt, ist, dass kundenrelevante Änderungen vor dem Release eine vollständige Generalprobe durchlaufen - in einem disposable shop, wo ein Fehler nichts kostet.

Narbe #4: Lass es laut scheitern, nicht höflich

Sich selbst überlassen wird ein hilfreicher Agent ein Problem überkleben. Etwas Erwartetes ist nicht da, also ersetzt er es leise durch einen Default, wickelt den Aufruf in ein "nur für den Fall"-Fallback und geht weiter. Die Aufgabe sieht erfolgreich aus. In einem Kundenshop ist ein stiller Workaround schlimmer als ein sichtbarer Fehler - denn der sichtbare Fehler wird heute behoben, während der leise ausgeliefert wird und wartet.

Darum lautet die stehende Anweisung genau entgegen dem Reflex: Wenn etwas falsch ist, crash loud. Erfinde keinen Fallback, um ein fehlendes Teil zu verstecken. Füge keine defensive Polsterung hinzu, die einen Bug in eine subtil falsche Antwort verwandelt. Zeig es, stoppe und lass einen Menschen entscheiden. Zusammen mit der Dev-first-Regel bedeutet das: Die hässlichen Fehlschläge passieren im Proberaum, wo hässlich genau das ist, was man sehen will, und das Ziel ist, dass Kunden die Aufnahme sehen, die funktioniert hat, nicht die Takes, die es nicht getan haben.

Der Teil, der alles billig macht: Gedächtnis, absichtlich gebaut

Die Narben halten Agenten davon ab, Dinge kaputt zu machen. Aber die Gewohnheit, die den ganzen Betrieb wirtschaftlich macht, ist diejenige, die Amnesie von einer Steuer in einen Rundungsfehler verwandelt.

Die naive Art, einen Agenten für eine wiederkehrende Aufgabe zu nutzen, ist, sie jedes Mal neu zu erklären. Die Beispieldateien neu anhängen. Die Schritte neu beschreiben. Neu herausfinden, welche Pfade zählen und welche Stolperfallen beißen. Man bezahlt den vollen Preis, in Tokens und in Uhrzeit, für Wissen, das man schon letzte Woche entdeckt hat. Das ist der Amnesiker, der jeden Morgen neu die Fluchtwege des Gebäudes lernt.

Also machte ich eine Regel für die Agenten selbst: Schreib am Ende einer Aufgabe die Notiz. Kein Tagebucheintrag - ein operatives Memo. Wo die relevanten Dateien liegen. Die genaue Sequenz, die funktioniert hat. Die eine nicht offensichtliche Sache, die den nächsten Lauf stolpern lässt. Diese Notizen liegen in einem organisierten Baum, und - das ist der Teil, den viele übersehen - es gibt einen einzeiligen Index jeder Notiz, der ganz am Anfang jeder Sitzung geladen wird. Der Amnesiker kommt herein, liest das Inhaltsverzeichnis und weiß sofort, was das Unternehmen schon weiß und wo er es nachschlagen muss.

# a representative note — boring on purpose, and that's the point
task: regenerate the catalog cover images
where: assets/covers/  (source templates in build/covers/)
steps: 1) run the build script  2) QA with the check script
gotcha: never touch a confirmed-good render; only regen the broken one
last run: 2026-05 — clean; the QA script caught one bad render

Das ist die ganze These in einer Gewohnheit. Ein cleverer Prompt macht diesen Lauf besser. Eine geschriebene Notiz macht jeden zukünftigen Lauf billiger, egal welcher Agent ihn übernimmt. Institutionelles Gedächtnis verzinst sich; Prompts tun das nicht. Das erste Mal, wenn ich hier etwas tue, ist teuer. Das zehnte Mal kostet fast nichts, und es ist genau deshalb billig, weil die ersten neun aufgeschrieben haben, was sie gelernt haben.

Wie eine Aufgabe tatsächlich durch dieses System läuft

Zusammengebaut läuft ein Routinejob wie ein kleines, gut eingespieltes Team, nicht wie eine Chatbot-Sitzung:

1. Ein Agent liest den Index, holt die Notiz für diese Art Aufgabe und startet nicht bei null, sondern schon weit auf dem Weg zum Ziel.
2. Er nimmt den Lock auf dem Modul, das er gleich anfassen wird, damit nichts anderes damit kollidieren kann.
3. Er arbeitet auf einer Wegwerfkopie. Wenn etwas falsch ist, scheitert es dort laut - nicht in einem Live-Shop.
4. Wenn er fertig werden will, halten die Leitplanken: Er kann den Befehl nicht ausführen, der einmal einen vendor-Ordner gelöscht hat, und er kann nur seine eigenen Dateien committen, nicht die halb fertige Arbeit im nächsten Repo.
5. Er schreibt zurück, was er gelernt hat, damit die Notiz für den nächsten Agenten etwas schärfer ist - vielleicht für einen ganz anderen.

Auffällig ist, wie wenig davon "Prompting" ist. Der Prompt ist eine Zeile: erledige die Aufgabe. Alles, was sie sicher, schnell und wiederholbar macht, lebt in der Umgebung, nicht in der Nachricht. Das ist der ganze Trick.

Die Gut-gegen-schlecht-Bilanz, und warum jedes "Gut" nur "hat Gedächtnis" bedeutet

Leute fragen mich nach Tipps, wie man AI effizient nutzt, und erwarten Prompt-Tricks. Die echte Liste ist langweiliger und viel nützlicher, und jeder Punkt darauf ist dieselbe Idee in anderer Kleidung - gib dem Amnesiker ein Gedächtnis und eine vorbereitete Werkstatt:

• Schlecht: Code in einen kostenlosen Chatbot einfügen und die Antwort von Hand zurückkopieren. Gut: Agenten dort laufen lassen, wo die Arbeit liegt - auf der Maschine, mit echtem Zugriff auf Dateien und Werkzeuge -, damit nichts beschrieben werden muss, was einfach gelesen werden könnte.
• Schlecht: eine chaotische Platte, auf der jede Aufgabe damit beginnt, dass der Agent sucht, wo die Dinge sind. Gut: ein organisierter Materialbaum, sodass "das Ding finden" ein Nachschlagen ist, keine Expedition.
• Schlecht: Der Agent greppt die ganze Platte und liest zwanzig Dateien, um eine Funktion zu finden. Gut: Die Werkstatt vorbereiten - schnelle Suche und Connectors, mit denen er Datenbank, Browser und laufende Container direkt abfragen kann, statt zu raten.
• Schlecht: dieselbe mehrstufige Aufgabe jedes Mal von Grund auf neu herleiten. Gut: die wiederverwendbare Notiz und der Index, der sie sichtbar macht.
• Schlecht: ein Allzweck-Agent für alles. Gut: die Arbeit routen - das Modell, das bei sorgfältigem Backend-Denken besser ist, bekommt das Backend; das mit besserem Urteil für Oberfläche und Worte bekommt diese Dinge. Genau wie ein Team nach Stärken besetzt wird.

Ein Fremder mit Amnesie in einem gut geführten Gebäude - beschriftete Regale, ein klares Handbuch, scharfe Werkzeuge bereitgelegt und Leitplanken an den gefährlichen Maschinen - ist erstaunlich produktiv. Derselbe Fremde in einem vollgestellten Raum mit einem vagen mündlichen Briefing ist ein Risiko. Derselbe Arbeiter. Der Unterschied ist vollständig die Organisation.

Wo AI hilft und wo menschliche Prüfung immer noch gewinnt

Nach all dem habe ich ein ziemlich scharfes Gefühl für die Grenze.

AI gewinnt beim Mechanischen, Parallelen und klar Abgegrenzten. Eine Änderung über Dutzende Module ziehen. Die erste Version von irgendetwas entwerfen. Strukturierte Daten extrahieren und transformieren. Einen vorbereiteten Workflow wieder aus einer Notiz ausführen. Einen kniffligen Bug mit mehr Geduld untersuchen, als ich um 6pm habe. Wenn eine Aufgabe eine erkennbare richtige Antwort und einen Weg dorthin hat, ist ein gut ausgestatteter Agent schneller als ich und langweilt sich bei Wiederholung drei nicht.

Menschliche Prüfung gewinnt bei Urteil, Geschmack und Konsequenz. Alles, wofür ein Kunde bezahlt. Alles mit rechtlichem oder finanziellem Gewicht - genau deshalb bekommen die Rechnungskorrekturen oben eine menschliche Unterschrift und keinen automatischen Versand. Die Architekturentscheidungen, bei denen die "richtige" Antwort davon abhängt, wo ich das Unternehmen in einem Jahr sehen will, nicht davon, was der Code heute sagt. Und der letzte Meter Geschmack bei Text und Design, wo "technisch korrekt" und "wirklich gut" verschiedene Dinge sind, und nur eines davon einen Kunden hält.

Die Linie ist auch nicht fest. Jede Narbe in diesem Text ist ein Ort, an dem ich einem Agenten einmal etwas anvertraut habe, wofür er noch nicht bereit war, gebissen wurde und die Linie verschoben habe. Das ist die eigentliche Fähigkeit - nicht einmal zu entscheiden, wo AI aufhört, sondern zu beobachten, wo sie scheitert, und die Grenze schneller anzupassen, als sich die Fehler stapeln können.

Warum Sie das interessieren sollte, wenn Sie bei mir kaufen

Hier ist die ehrliche Version, weil die Rahmung eines solchen Textes leicht an einen Ort rutschen kann, an den ich nicht will. Die Agenten bauen meine Module nicht für mich, und das würde ich Ihnen auch nie erzählen. Sie bauen Gerüste, führen die Werkzeuge aus, die ich nicht von Hand ausführen will, entwerfen erste Fassungen und fangen gegenseitig Fehler ab - alles innerhalb von Leitplanken, die ich mir Ausfall für Ausfall verdient habe. Urteil, Architektur und Freigabe bleiben bei mir.

Was Ihnen diese Disziplin bringt, wenn Sie am anderen Ende eines Moduls oder Support-Tickets stehen, ist auf die beste Weise langweilig. Dieselbe Regel, die verhindert, dass 154 Repositorys sich verheddern, verhindert, dass ein Release halb fertig ausgeliefert wird. Dieselbe Wand, die einen Agenten davon abhält, einen vendor-Ordner zu löschen, ist der Grund, warum ein schlechtes Update meine Werkstatt viel seltener verlässt. Dieselbe Dev-first-Gewohnheit, die meine eigenen Testshops schützt, schützt Ihren. Sorgfältiger Prozess upstream fühlt sich downstream wie ruhige Zuverlässigkeit an.

Wenn es eine Sache zum Mitnehmen gibt, dann diese: Hör auf, den Prompt zu tunen, und baue das Gedächtnis. Der Agent vergisst alles in dem Moment, in dem die Sitzung endet - also lege alles, was erinnernswert ist, an einen Ort, an dem er es nicht vergessen kann, und mache die Fehler, die du nie wieder sehen willst, unmöglich, nicht nur unerwünscht. Dann hört eine Flotte brillanter Amnesiker auf, ein Risiko zu sein, und sieht plötzlich ziemlich nach einem Team aus.