Upgrade mit KI-Agent: Rector ja, der Rest nein

Upgrade mit KI-Agent: zuerst Rector, dann Schulterklopfen. Nur dumm, wenn NPM, Container und Tests einfach liegen bleiben. Ich habe es ausprobiert: ein kleineres Projekt, Upgrade per KI-Agent. Alles schön per Spec-Driven Development beschrieben, saubere Aufgabenstellung, klarer Zielzustand, definierte Qualitätskriterien. Das Ergebnis war aufschlussreich, nur anders, als ich es mir erhofft hatte.

Ich schreibe diesen Beitrag, weil ich in den letzten Wochen viele Stimmen gesehen habe, die KI-Agenten für Framework-Upgrades feiern, als hätten sie das Rad neu erfunden. Mein Eindruck nach der Praxis: Der Agent ist ein guter Junior. Ein sehr schneller Junior. Aber genau wie bei einem echten Junior ist die Frage nicht, ob er etwas kann, sondern was er von sich aus übersieht.

Was der Agent wirklich gut gemacht hat

Den Rector-Teil hat er geliefert. Er hat die entsprechenden Regelsets ausgewählt, die PHP- und TYPO3-spezifischen Transformationen angewendet, Namespaces angepasst, deprecated Aufrufe umgeschrieben und sich in einem Commit-Rhythmus durch die Klassen gearbeitet, der ordentlich war. Das ist viel wert. Wer ein TYPO3- oder PHP-Upgrade schon einmal manuell gemacht hat, weiß, wie viel Fleißarbeit in diesen Schritten steckt. Diesen Teil kann der Agent heute besser als ich an einem müden Freitagnachmittag.

Er hat auch Tests laufen lassen. Er hat auf roten Output reagiert und die Fehler lokal behoben. Die Commits waren lesbar, die Branch-Struktur sauber. In der Oberfläche sah das sehr nach „erledigt" aus.

Was der Agent eben nicht gemacht hat

Nur: das Projekt war nicht Rector. Das Projekt war ein ganzes Deployment. Und genau da fing es an, bröckelig zu werden. Der Agent hat das PHP-seitige Upgrade sauber durchgezogen, aber:

Die package.json blieb auf einer Node-Major-Version, die offiziell End of Life war. NPM-Abhängigkeiten hatten auditable Schwachstellen, an die niemand rangegangen ist. Das Frontend-Build-Setup lief danach unverändert, mit Loadern, die zur neuen TYPO3-Version eigentlich neu hätten konfiguriert werden müssen. Die Container-Basisimages haben noch ihre alten PHP-Extensions mitgeschleift, und zwei Config-Flags, die in der neuen Version ein anderes Verhalten haben, sind unverändert übernommen worden.

Und schließlich: die Testabdeckung, die er beibehalten hat, war die Testabdeckung des alten Projekts. Die neuen APIs, die durch das Upgrade hinzugekommen sind, waren untested. Der Agent hat nicht von sich aus vorgeschlagen, diese Lücke zu schließen. Er hat gemacht, was in der Spec stand: „PHP/TYPO3 upgraden, Tests grün halten". Er hat sie grün gehalten. Im alten Umfang.

Warum das kein KI-Problem, sondern ein Spec-Problem ist

Das ist der Satz, der mir beim Review immer wieder klar wurde. Der Agent hat keine Fehler gemacht. Er hat gemacht, was ich ihm gesagt habe. Das ist in der Software-Arbeit keine neue Beobachtung. Das ist dasselbe Problem wie bei Jira-Tickets, die man ohne Kontext an externe Entwickler gibt. Oder bei Ausschreibungen, in denen der Kunde genau das bekommt, was dort steht, aber nicht das, was er meinte.

Der Unterschied ist: Beim Menschen haben wir gelernt, dass gutes Handwerk auch darin besteht, die Spec zu hinterfragen. Ein erfahrener Entwickler schreibt ein Ticket nicht 1:1 ab. Er schreibt eine Nachfrage. Er sagt: „Du willst PHP upgraden, aber dann müssen wir auch Node machen, sonst bricht das Frontend." Genau diese Rückfrage habe ich beim Agenten nicht bekommen. Und ich bin nicht sicher, ob ich sie bald bekommen werde.

Meine Konsequenz

Ich nutze KI-Agenten weiter für Upgrades. Ich wäre dumm, es nicht zu tun. Der Rector-Teil eines TYPO3-Upgrades nimmt mir einen Tag weg, den ich anders gebrauchen kann. Aber ich habe meine Spec radikal erweitert. Sie heißt jetzt nicht mehr „PHP/TYPO3 auf X.Y", sondern listet explizit:

- PHP- und TYPO3-Major-Upgrade inklusive Rector-Sets
- NPM-/Node-Major-Upgrade plus Audit und Breaking-Change-Review
- Container-Basisimages inkl. PHP-Extensions und System-Libraries
- CI-Pipeline-Anpassungen und Runner-Versionen
- Konfigurations-Review gegen die Changelogs der neuen Version
- Testabdeckung für neue APIs mit Ziel-Coverage

Das ist mehr Arbeit beim Schreiben der Spec. Aber es ist die Arbeit, die ich als Senior sowieso machen müsste. Der Agent spart mir das Tippen der Änderungen, nicht das Denken.

Wer gerade mit KI-Agenten experimentiert und „Wow, das funktioniert!" auf LinkedIn schreibt, möge bitte in vier Wochen nochmal hinsehen. Ob die Site noch läuft. Ob der Build noch funktioniert. Ob die Security-Reports im Monitoring ruhiger geworden sind, oder nur der Kunde noch nichts gemerkt hat. Upgrade ist ein Zustand, nicht ein Commit. Und dieser Zustand endet nicht bei Rector.