Modernisierung eines Systems mit vielen Microservices mit Agentic Coding

  Frage 1: Du arbeitest seit Dezember 2025 mit Claude Code an einem System mit
  16 Microservices. Was war der Ausgangspunkt — was hat dich dazu gebracht,
   Agentic Coding in diesem Kontext auszuprobieren, und was waren deine
  anfänglichen Erwartungen?

❯ andrena sieht in KI-native-Produktentwicklung mit Agenten die Zukunft der
Softwareentwicklung und bildet daher alle Entwickler:innen in Agentic Coding
aus. Vor diesem Hintergrund wurde ich gebeten, die Migration der CI/CD-Pipeline
 eines Systems mit vielen Microservices von Jenkins zu GitLab mit Agentic
Coding umzusetzen. Ich fand das eine interessante Herausforderung, zumal es
sich um ein System handelt, das produktiv eingesetzt wird und nicht um ein
kleines Beispielprojekt. Andererseits hatte ich anhand der Anforderungen schon
eine relativ konkrete Vorstellung, wie ich die Pipeline als GitLab CI/CD
Component umsetzen wollte. Ich fragte mich außerdem, ob die Modelle (zu Beginn
noch Claude Sonnet 4.5 und Claude Opus 4.5) schon so weit wären, dass ich sie
sinnvoll in diesem doch relativ komplexen Kontext einsetzen könnte.
Rückblickend betrachtet hätte ich mich eher fragen sollen, ob ich schon so
weit war.

Frage 2: Du sagst, rückblickend war eher die Frage, ob du schon so weit warst.
   Was meinst du damit konkret? Wo musstest du am meisten dazulernen — war es
  eher das Handwerkszeug im Umgang mit Claude Code, oder ging es um eine
  grundlegendere Veränderung in der Arbeitsweise und Denkweise?

❯ Sowohl als auch.

Anfangs habe ich noch sehr viel Code selbst geschrieben und nur vereinzelt
Fragen an Claude Code gerichtet oder mal kleinere Aufgaben delegiert. Das hat
sich fundamental geändert, als ich, anstatt Claude Code einfach machen zu
lassen, den Plan Mode für mich entdeckt habe. Im Plan Mode kann Claude Code
noch keine Code-Änderungen vornehmen, sondern schlägt zunächst einen Plan für
die Implementierung vor. Das ermöglicht es, sehr früh Einfluss darauf zu
nehmen, in welche Richtung es geht. Viele meiner Prompts starten mit "Interview
 me about...". Dann stellt Claude Code erst einmal Multiple-Choice-Fragen, um
die Anforderungen zu konkretisieren. Vor allem kann man durch Feedback an
Claude Code den vorgeschlagenen Plan auch noch iterativ nachjustieren, solange
bis er überzeugt. Meiner Erfahrung nach lohnt es sich, den Hauptaufwand in den
Plan zu stecken. Wenn der Plan passt, dann gilt das meistens auch für die
Implementierung. Der zusätzliche Aufwand bei der Verfeinerung des Plans spart
später Aufwand beim Reviewen und Korrigieren der Implementierung. Auf diese Art
 und Weise habe ich mehr und mehr von Claude Code umsetzen lassen. Tatsächlich
habe ich schon seit ungefähr Mitte Februar nichts mehr selbst committed.

Ein weiterer Paradigmenwechsel war für mich, dass ich nicht mehr mit einer IDE
und nicht mehr in einzelnen Repositories arbeite. Die Aufgaben bei der
Migration der CI/CD-Pipeline erstrecken sich meistens über mehrere
Repositories. Zu Beginn habe ich noch in jedem Repository mit einer eigenen
Instanz von Claude Code parallel gearbeitet und war viel damit beschäftigt,
diese Instanzen zu koordinieren und die Änderungen zu integrieren. Inzwischen
starte ich für jede Aufgabe eine Instanz in einem Verzeichnis, in dem ich alle
Repositories auschecke. Das ermöglicht, Claude Code in allen betroffenen
Repositories gleichzeitig entwickeln zu lassen. Außerdem kann man so
verschiedene Repositories konkret anhand ihres Verzeichnispfades referenzieren
und z.B. darum bitten, Aufgaben in Repository A analog zu Repository B
umzusetzen, worin ja eine der Stärken von LLMs liegt.

 *Claude*: Das sind zwei sehr konkrete Wendepunkte — Plan Mode als Steuerungsinstrument
  und das Arbeiten über Repository-Grenzen hinweg. Besonders spannend finde ich,
   dass du seit Mitte Februar nichts mehr selbst committet hast.
Frage 3: Wenn du nicht mehr selbst Code schreibst und nicht mehr in einer IDE
  arbeitest — wie würdest du deine heutige Rolle beschreiben? Was genau tust du,
   wenn du mit Claude Code arbeitest? Und wie hat sich das auf die Qualität und
  Geschwindigkeit deiner Arbeit ausgewirkt?

Ich sehe mich immer noch als Software Engineer bzw. DevOps Engineer. Die
Flughöhe ist zunächst eine etwas andere. Die Arbeit im Plan Mode fühlt sich ein
 bisschen wie Refinement und Task Breakdown an. Es ist dann aber trotzdem noch
technische Expertise und Erfahrung in Software-Architektur und Software
Engineering erforderlich, um den Plan und die Implementierung bewerten zu
können. Man kann mit Agentic Coding sicherlich auch schlechte Software
schneller produzieren. Zumindest momentan kann ich mir noch nicht vorstellen,
dass die Steuerung des Prozesses durch Menschen so schnell entbehrlich wird.

Der Geschwindigkeitsgewinn durch Agentic Coding kann enorm sein, ohne dass
darunter die Qualität leiden muss. Es ist für mich ganz klar, dass ein LLM Code
 mehrere Größenordnungen schneller lesen und schreiben kann als ein Mensch.
Man kann jetzt plötzlich viele Dinge tun, die man sich früher nicht leisten
konnte.
Zwei Beispiele, wo ich wirklich Zeit gespart habe։
Erstes Beispiel: Ich habe ein Bash-Skript für einen Pipeline-Job entwickeln
lassen, nur um dann festzustellen, dass das im Container Image des Jobs kein
bash installiert war. Statt bash in das Container Image zu installieren, wie
ich es früher vielleicht gemacht hätte, habe ich Claude Code das Skript
POSIX-kompatibel machen lassen. Ich hätte dafür von Hand erheblich länger
gebraucht als Claudes wenige Minuten.

Zweites Beispiel: Die Integrationstests einiger Microservices verwendeten
Testcontainers. In Jenkins wurde für jeden Test ein eigener Datenbank-Container
 gestartet, gegen den der Test lief. In unserer GitLab-Instanz sollte aus
Sicherheitsgründen kein Docker-in-Docker möglich sein, weshalb die vielen
Datenbank-Container von Testcontainers durch einen GitLab CI/CD Service für
die Datenbank ersetzt werden sollten. Leider gab es einige Integrationstests,
die Daten in der Datenbank hinterließen, was andere Tests zum Fehlschlagen
brachte. Von Hand wäre es sehr aufwändig, herauszufinden, welche Tests für die
überschüssigen Daten verantwortlich sind. Mit Claude Code konnte ich binnen
Minuten ein Skript entwickeln, das jeden Test einzeln gegen eine frische
Datenbank laufen lässt und zusammenfasst, welche Daten danach übrig bleiben.
Das Skript lief zwei Stunden, während ich an etwas anderem arbeitete. Danach
konnte ich die Tests in kürzester Zeit basierend auf der Ausgabe des Skripts
von Claude Code fixen lassen.

*Claude*: Exzellente Beispiele — sie zeigen gut, wie sich der Hebel verändert։ Statt
  selbst die POSIX-Kompatibilität nachzuschlagen oder manuell Tests zu
  isolieren, formulierst du das Problem und lässt es lösen. Dabei bleibt die
  technische Bewertung bei dir.
  Frage 4: Lass uns über ein Thema sprechen, bei dem deine Commit-Historie eine
  bemerkenswerte Entwicklung zeigt։ Sicherheit. Im /workspace/claude/-Repository
   sehe ich eine regelrechte Reise — von einem einfachen Devcontainer über
  iptables-Firewalls, Squid-Proxy, HAProxy, QEMU-VMs bis hin zu Podman Machine
  mit Capability-Dropping und DNS-Restriktionen. 12 deiner 85 Plans befassen
  sich allein mit Security-Hardening. Was hat diese Reise ausgelöst, und welche
  Bedrohungsszenarien hattest du dabei konkret im Blick?

❯ Um KI-Agenten sicher einsetzen zu können, muss man die sogenannte Lethal
Trifecta aus private data, untrusted content und external communication
verhindern. Wenn ein KI-Agent Zugriff auf sensitive Daten hat (z.B. private
SSH-Schlüssel oder die Datenbank eines Passwort-Managers), mit
nicht-vertrauenswürdigem Inhalt arbeitet (z.B. weil eine Datei oder Webseite,
die der KI-Agent in den Kontext des LLMs lädt, eine Prompt Injection enthalten
könnte, die den Agenten dazu bringt, sein Verhalten zu ändern) und Daten über
das Internet an Dritte verschicken kann, dann hat man ein großes Problem. Wenn
man den Agenten also einfach so auf dem eigenen Rechner und mit unbeschränktem
Zugriff auf das Internet laufen lässt, dann kann das nur schief gehen.

Mein aktuelles Setup ist eine Weiterentwicklung des Anthropic Claude Code
Devcontainers von github.com/anthropics/claude-code. Die Idee ist, Claude Code
in einem Container laufen zu lassen und nur das Arbeitsverzeichnis als Volume
in den Container zu mounten. Dadurch hat Claude Code, sofern er nicht aus dem
Container ausbrechen kann, keinen Zugriff auf sensitive Daten, die außerhalb
des Arbeitsverzeichnisses liegen. Der Devcontainer verwendet ein Skript, um per
 iptables den Internetzugriff von Claude Code auf eine allowlist von Hostnames
bzw. IP-Adressen zu beschränken.

Ein Container teilt sich aber den Linux-Kernel mit dem Host, auf dem er läuft,
wodurch Claude Code unter Umständen aus dem Container ausbrechen und doch
Zugriff auf den gesamten Rechner erlangen kann. Deshalb verwende ich zusätzlich
 Podman Machine, um den Devcontainer in einer QEMU virtuellen Maschine mit
rootless Podman laufen zu lassen.

Noch besser wäre es, eine virtuelle Maschine auf einem anderen Rechner, z.B.
auf einer Cloud-Instanz, zu verwenden. Dann könnte Claude Code auch
weiterlaufen, wenn der eigene Rechner zum Feierabend heruntergefahren wird. Für
 die Zukunft könnte ich mir z.B. auch vorstellen, Agenten in microVMs in einem
Kubernetes-Cluster laufen zu lassen.

*Claude*: Das ist ein sehr fundierter Sicherheitsansatz — die Lethal Trifecta als
  Denkmodell und dann die konsequente Umsetzung in Schichten։ Volume-Isolation,
  Firewall-Allowlist, VM-Kapselung. Und die Vision mit microVMs in Kubernetes
  zeigt, wohin die Reise geht.
Frage 5: Du hast erwähnt, dass du Custom Skills entwickelt hast — darunter
  einen mit 435 Zeilen für Spring Boot 4 Upgrades und einen für
  Jackson/Pact-Fixes. Wie sind diese entstanden? Hast du sie von Anfang an
  geplant, oder haben sie sich aus wiederkehrenden Mustern in deiner Arbeit
  ergeben? Und wie stark haben sie die Arbeit an den verbleibenden Microservices
  beschleunigt?

❯ Das Upgrade von Spring Boot 3.5 auf Spring Boot 4 bringt leider mehrere
Breaking Changes mit sich, u.a. durch Major-Version-Upgrades von Spring
Framework, Hibernate und Jackson. Es war klar, dass das Upgrade früher oder
später für alle Backend-Services erforderlich sein würde.

Also habe ich das Upgrade mit Claude Code in einer interaktiven Session für
einen Service durchgeführt. Entscheidend war dabei auch, Claude Code Kontext zu
Spring Boot 4 zu geben, weil diese Version nicht in den Trainingsdaten
enthalten war.

Anschließend habe ich Claude Code darum gebeten, die Erkenntnisse aus der
Session als eine Art Rezept in einen Skill zu packen, um das Wissen für
künftige Sessions zu erhalten. Für die übrigen Services habe ich dann jeweils
den Skill verwendet und den Skill dabei weiter verfeinert.

Die erste, interaktive Session hat gut vier Stunden gebraucht. Nach diversen
Verfeinerungen des Skills kam es dann immer darauf an, ob noch neue, spezielle
Probleme bei einem Backend auftraten. In einem Fall gab es keine neuen Probleme
und das Upgrade lief vollautomatisch in 15 min durch. In anderen Fällen musste
ich neue Probleme lösen (lassen) und brauchte dafür 1 bis 2 Stunden.

Frage 6 — Abschlussfrage: Von vier Stunden interaktiv auf 15 Minuten
  vollautomatisch — das ist eine eindrucksvolle Lernkurve, und zwar sowohl deine
   als auch die des Skills.. Wenn du das gesamte Projekt Revue passieren lässt։
  Was würdest du jemandem raten, der morgen anfängt, Agentic Coding in einem
  echten, produktiven Projekt einzusetzen? Was sind die ein, zwei Dinge, die du
  gerne von Anfang an gewusst hättest?

❯Achte von Anfang an auf Sicherheit.

Akzeptiere, dass Agentic Coding zu lernen ein Prozess ist, der Zeit braucht.
(Ich hatte das Glück, dass ich meine gesamte Arbeitszeit darauf verwenden
durfte, es zu versuchen.) Am Anfang wird dein Geschwindigkeitsgewinn
wahrscheinlich nur moderat sein, weil du dich erst an die neue Arbeitsweise
gewöhnen musst. Mit mehr Erfahrung im sinnvollen Einsatz von Agentic Coding
kannst du erheblich Zeit sparen, ohne Abstriche bei der Qualität machen zu
müssen.
Wenn das Ergebnis nicht deinen Erwartungen entspricht, schiebe die Schuld nicht
 vorschnell auf das LLM, sondern überlege auch, was du besser oder anders
machen könntest.

Selbst wenn du Vorbehalte gegenüber dem Einsatz von Agentic Coding hast, kannst
du vielleicht trotzdem davon profitieren, z.B. indem du Dinge, die dir keinen
Spaß machen oder die du sonst vielleicht gar nicht angehen würdest, an einen
Agenten delegierst.