Der Kunde sagte: Mach es gelb.

Die Nachricht war kurz. Ein Screenshot. „Kannst du das so aussehen lassen?”

Gelb. Grün. Überall.

Normalerweise ist das ein Designer-Ticket. Wireframes, Feedbackrunde, Revision, noch eine Feedbackrunde. Mindestens drei Stunden, wenn man Glück hat. Wir haben es in 20 Minuten mit AI erledigt. Dann die Arbeit verloren. Nochmal in 20 Minuten. Dann deployed. Und auf Staging keine einzige neue Farbe gesehen.

Warum Rebranding mechanische Arbeit ist

Ein Farbschema zu ersetzen klingt trivial. In der Praxis ist es mühsam: sechs bis acht verschiedene Seiten — Landing, Success, Verify Email, User Correction, Expired, Coming Soon — jede mit eigenen Komponenten, Tailwind-Klassen und Custom-CSS-Variablen. Graue Hintergründe raus. Gelb #ffd630 rein. Weiße Karten für Formulare bleiben, aber Grün #008235 für alle Buttons und Akzente.

Das ist keine kreative Arbeit. Es ist Search-and-Replace mit Kontext — jede Stelle finden, an der das alte neutrale Styling auftaucht, verstehen warum es dort ist, und es konsistent ersetzen. Genau die Art Aufgabe, die AI gut löst.

Der Prompt war im Wesentlichen der Screenshot. „Wende dieses Farbschema auf alle Unterseiten an. Gelber Hintergrund, grüne Buttons und Akzente, weiße Kartenhintergründe für Formulare.” Ein Durchlauf. Eine Review-Runde für kleine Details (Footer, Logo-Platzierung). Fertig.

Was einen Designer drei Stunden gekostet hätte — Brief, Iteration, Feedback, Revision — war in einer einzigen AI-Session erledigt. Das Ergebnis war sauber, konsistent, und hat beim ersten Durchlauf jede Seite abgedeckt.

Der Grund, warum es funktioniert, ist kein Wunder. Tailwind CSS und Custom CSS Variables machen Farbänderungen systematisch. Die AI „designt” nicht — sie erkennt Muster und wendet Ersetzungen an. Die drei Stunden des Designers enthalten Koordinationsaufwand, Kontextwechsel und Kommunikations-Overhead, die schlicht nicht existieren, wenn der Agent bereits den gesamten Kontext hat.

Wir haben es zweimal gemacht

Das erste Rebranding war sauber. Der Agent ist durch alle sechs Seiten gegangen, hat gelbe Hintergründe, grüne Buttons, weiße Formularkarten gesetzt. Konsistent. Fertig.

Dann war es weg.

Was passiert ist: Ein Schwung Anfragen war als Nachrichten reingekommen — nicht in Tickets erfasst, nur informelle Bitten. „Kannst du noch den Footer updaten?” „Kannst du auch die Demo-Umgebung auf Staging migrieren?” Unstrukturiert. Mehrere Dinge auf einmal. Zwei parallele AI-Sessions liefen.

Eine Session hatte das Rebranding gemacht. Eine zweite arbeitete an etwas, das völlig unzusammenhängend wirkte: die Migration von Demo auf Staging — dieselbe SCP-basierte Server-Infrastruktur, auf der dieses Projekt läuft. Andere Aufgabe, anderer Kontext. Die beiden sollten sich nicht berühren.

Haben sie doch.

Die Migrationssession kam an einen Punkt, an dem sie einen sauberen Zustand brauchte. Sie hat auf den letzten gepushten Commit zurückgesetzt — was genau das ist, was eine gut erzogene Session tun sollte. Das Rebranding war nie gepusht worden. Es lag nur im Working Directory.

Sauberer Reset. Weg.

Wir haben mit git fsck --unreachable gesucht. 30+ verwaiste Commits gefunden. Keiner davon war das Rebranding. Die Arbeit war nie committed, nie mit Absicht gestasht worden — nur lokale Dateiänderungen in einem Working Directory. Als das geleert wurde, hat es keine Spur hinterlassen.

Also haben wir das Rebranding nochmal gemacht. 20 Minuten, wie beim ersten Mal.

Beim zweiten Mal haben wir sofort committed.

„Warum sehen wir die neuen Farben nicht?”

Der Commit war drin. Der CI-Build war grün. Der Deployment-Schritt — dieselbe SCP-basierte Pipeline, die Docker-Images direkt auf den Server pusht — lief ohne Fehler durch.

Dann: „Warum sehen wir auf Staging noch die alten Farben?”

Ein grüner Build bedeutet nicht, dass das Deployment korrekt war. Er bedeutet, dass die Befehle durchgelaufen sind. Die Pipeline hatte keine Möglichkeit, eine visuelle Regression zu erkennen — ob die richtigen Farben auf der deployten Seite tatsächlich erscheinen. Irgendwo zwischen „Build grün” und „sichtbar im Browser” war etwas lautlos kaputt, und nichts in der CI-Chain hätte es je gefunden.

Das Debugging begann hier — und brauchte drei Iterationen.

Iteration 1: SSH Heredocs scheitern lautlos.

Das Deployment verwendete SSH Heredocs, um mehrere Befehle auf dem Remote-Server in einer Verbindung auszuführen. Funktioniert in der Theorie gut. Das Problem: Wenn ein Befehl innerhalb eines Heredocs auf stderr schreibt, kann das gesamte Heredoc mitten in der Ausführung abbrechen. Kein Fehler. Keine Warnung. Der Pipeline-Schritt meldet Erfolg. Befehle nach dem Abbruch laufen nie.

Fix: Jeden SSH-Befehl in einen separaten ssh "remote-command"-Aufruf aufteilen. Ausführlicher, aber zuverlässig.

Iteration 2: docker compose --force-recreate löst Images nicht neu auf.

Das Deployment hat ein neues Docker-Image via SCP + docker load auf den Server übertragen. Dann docker compose up --force-recreate ausgeführt, um Container mit dem neuen Image neu zu starten.

--force-recreate erstellt einen neuen Container — aber auf Basis desselben gecachten Image-Digests, den es bereits kannte. Docker Compose cached die Digest-Referenz vom vorherigen Lauf. Das neu geladene Image hat denselben Tag-Namen, aber einen anderen Digest. Compose bemerkt es nicht. Es erstellt den Container aus dem alten gecachten Image neu.

Auch docker compose stop && docker compose rm behebt das nicht. Das ist ein Compose-Verhalten beim Arbeiten mit lokal geladenen Images ohne Registry.

Iteration 3: Der einzige echte Fix.

Rohes docker stop <container> + docker rm <container>, dann docker compose up -d. Direkte Docker-CLI-Befehle umgehen das Caching von Compose vollständig. Docker muss den Tag neu auflösen — und lädt das neu übertragene Image.

Drei Iterationen, aber jede hat eine Annahme-Schicht eliminiert. Nach der dritten erschienen die Farben.

Die eigentliche Zusammenarbeit

Das Rebranding lief vollständig autonom. Screenshot rein, fertig gefärbte Seiten raus.

Das Deployment-Debugging begann mit einem anderen Input: einem Screenshot von Staging, der noch die alten Farben zeigte, und einer Frage. „Warum sehen wir die neuen Farben nicht?” Das war der Auslöser — kein Log-Eintrag, kein fehlschlagender Test, kein Monitoring-Alert. Ein Mensch hat die URL aufgerufen, gemerkt, dass das Ergebnis falsch war, und gefragt.

Was danach passierte, ist der interessante Teil der Zusammenarbeit. Die Pipeline hatte keine visuelle Regressionserkennung — nichts, das prüft, ob die richtigen Pixel auf einer deployten Seite erscheinen. Ein grüner Build ist ein grüner Build, mehr nicht. Aber der Agent hatte Browser-Zugang via MCP Chrome DevTools. Sobald die Frage gestellt war, konnte die Untersuchung autonom weiterlaufen: das SSH-Heredoc-Problem diagnostizieren, den Docker-Compose-Caching-Bug identifizieren, jeden Fix anwenden — und dann Staging direkt im Browser öffnen, prüfen, was tatsächlich gerendert wurde, und verifizieren, ob die Farben sich verändert hatten. Kein Übergeben an einen Menschen zum URL-Prüfen nach jeder Iteration. Die Schleife schloss sich innerhalb der Session.

Der Screenshot und die Frage lieferten den Einstiegspunkt. Danach haben Browser-Tools eine blinde Deploy-Pipeline in etwas Beobachtbares verwandelt.

Das ist die Arbeitsteilung, die immer wieder auftaucht: Der Mensch liefert den Kontext, den die Pipeline nicht erfassen kann — „das sieht nicht richtig aus.” Der Agent liefert die Untersuchungs- und Iterationsgeschwindigkeit, die der Mensch nicht mithalten kann. Keiner ist vollständig ohne den anderen, aber die Grenze verschiebt sich weiter in Richtung Agent, wenn er die richtigen Tools zur Verfügung hat.

Was sich überträgt

Wer lokal geladene Docker-Images verwendet (SCP-basiertes Deployment, keine Registry), dem wird das passieren. --force-recreate wird lügen. Die Container starten neu und wirken gesund. Das alte Image läuft trotzdem.

Der Fix sind zwei rohe Docker-Befehle vor dem compose up. Nicht elegant. Aber zuverlässig.

Das SSH-Heredoc-Problem ist subtiler. Wer mehrstufige Remote-Deployments hat, die gelegentlich lautlos scheitern, sollte prüfen, ob ein Schritt auf stderr schreibt. Separate SSH-Aufrufe sind ausführlicher, eliminieren aber eine ganze Klasse stiller Fehler.

Und das Rebranding: Wer ein Tailwind-basiertes Projekt hat und ein Farbschema zu ändern, ist das eine 20-Minuten-Aufgabe mit AI, kein dreiteiliger Design-Zyklus. Den Agenten mit dem Screenshot versorgen, die Zielseiten nennen, laufen lassen. Einmal reviewen, shippen.

Dann ist da noch das Session-Isolation-Problem. Wer mehrere AI-Sessions parallel betreibt — und das wird so sein, weil sie schnell sind — die brauchen echte Isolation. Derselbe Branch ist keine Isolation. Der saubere Reset einer Session ist die verlorene Arbeit einer anderen, und es passiert lautlos.

Zwei Ansätze funktionieren: Anfragen in Tickets erfassen, nicht in Nachrichten. Was kein Ticket hat, bekommt keine AI-Session. Unerfasste Anfragen erzeugen unerfasstes Risiko — parallele Sessions ohne Koordination und ohne Aufzeichnung, was gerade in Arbeit ist. Oder git Worktrees verwenden. Jede Session bekommt ihr eigenes Working Directory auf ihrem eigenen Branch. Ein Reset in einer Session kann die andere physisch nicht berühren. Zusammengeführt wird bewusst, wenn die Arbeit fertig ist. (Das tieferliegende Problem, wie Sessions Kontext und Zustand teilen, wird in autonomous workflow risk behandelt.)

Das Rebranding hat zweimal 20 Minuten gebraucht, weil keines davon vorhanden war. Eine Nachricht zu viel, ein Reset zum falschen Moment, und ein Working Directory voller nicht-getrackter Änderungen wurde zu einem leeren. Dem Agent war es egal — er hat dieselben 20 Minuten wieder gemacht, ohne Beschwerde. Wir waren diejenigen, die erklären mussten, warum auf Staging noch die Farben von gestern zu sehen waren.

Die Arbeit, die in einem traditionellen Workflow Stunden dauert, muss das oft nicht. Die Arbeit, die lautlos verschwindet, ist der Teil, den man zuerst fixen sollte.