Analyse zu Einsatzmöglichkeiten von KI im Code Refactoring

1. Einleitung

Künstliche Intelligenz (KI) spielt eine immer größere Rolle in der Softwareentwicklung. KI-gestützte Systeme, sogenannte Coding Agenten, haben sich von konzeptionellen Modellen zu praxistauglichen Werkzeugen entwickelt, die auf eine Effizienzsteigerung bei Entwicklungs- und Wartungsaufgaben abzielen. Parallel dazu stellt die Modernisierung von Altanwendungen (Legacy Systems) eine zentrale Herausforderung dar. Diese Systeme sind häufig durch veraltete und gegebenenfalls nicht mehr gewartete Abhängigkeiten, akkumulierte technische Schulden oder einem nicht mehr zeitgemäßen Technologie-Stack gekennzeichnet. Das Ziel der vorliegenden Arbeit ist es, das Potenzial moderner KI-Coding-Assistenten für die semi-automatisierte Modernisierung solcher Legacy-Systeme systematisch zu untersuchen. Als konkretes Untersuchungsobjekt dient die Bestandsanwendung pdf-as 4.

Zur Evaluierung wird eine vergleichende Analyse von vier ausgewählten KI-Agenten in ihren jeweiligen Entwicklungsumgebungen (IDEs) durchgeführt: Junie und Sweep AI in der IDE IntelliJ, GitHub Copilot in Visual Studio Code sowie der integrierte Assistent der Entwicklungsumgebung Kiro. Dabei betrachten wir ihre Funktionsweise, technische Grundlagen und ihre Praxistauglichkeit bei der Modernisierung bestehender Anwendungen.

2. Hintergrund

Die Verwendung von AI Coding Agenten zur Unterstützung von Softwareentwicklungsaufgaben basiert auf der Integration von Large Language Models (LLMs) in Entwicklungsumgebungen. Dabei handelt es sich um KI-Modelle, die auf Unmengen an (Quell-)Texten trainiert wurden und durch ihre Kontextverarbeitung in der Lage sind, Code nicht nur zu generieren, sondern auch zu verstehen, refaktorisieren und korrigieren. Moderne Tools wie GitHub Copilot, Junie, Sweep AI oder Kiro nutzen unterschiedliche LLMs, um verschiedene Funktionen wie Autovervollständigung, Coding-Unterstützung bis hin zu autonomen Änderungen bereitzustellen.

2.1. LLM-basierte Assistenz: Architektur und Prinzipien

LLMs wie GPT-4.1 oder Claude Sonnet arbeiten rein sequenziell auf Eingabeaufforderungen (Prompts). Je nach Architektur und Modellgröße besitzen sie unterschiedliche Fähigkeiten zur Informationsverarbeitung, Aufgabenplanung und Selbstreflexion. Dabei sind folgende Komponenten zentral für Coding Agenten:

• Kontextfenster: LLMs können nur eine begrenzte Menge an Code auf einmal betrachten. Claude Sonnet 3.7 und 4.0 bieten dabei bis zu 200k Tokens Kontext, GPT-4.1 in der Copilot-Version bis zu 128k Tokens. Eine höhere Kontextgröße erlaubt es dem Modell, größere Projekte oder ganze Dateien auf einmal zu analysieren.

• Tool-Use-Fähigkeit: Agentensysteme wie Junie und Kiro können explizit Tools aufrufen – etwa Testläufe starten oder Codeänderungen durchführen. Ebenso können Terminal-Anwendungen wie find oder git aufgerufen werden.

• Planung und Selbststeuerung: Während klassische LLMs wie GPT-3 einfache Reaktionen auf Eingaben liefern, bauen moderne Coding Agenten wie Kiro oder Junie auf „multistep reasoning“: Sie planen Änderungen, erstellen Aufgabenlisten und führen diese nacheinander aus.

2.2. Arten von Coding Assistenten

Coding Assistenten lassen sich grob in drei Klassen unterteilen:

• Autovervollständiger: Klassische Tools wie Copilot (im Inline-Modus) oder Tabnine schlagen einzelnen Codezeilen oder Blöcke auf Basis von Prompts oder vorherigem Code vor. Aufgrund der geringeren Komplexität können Autovervollständiger oft auch lokal am Rechner des Benutzers bzw. der Benutzerin ausgeführt werden, wie dies beispielsweise in Entwicklungsumgebungen von JetBrains der Fall ist [1].

• Conversational Assistants: ChatGPT, Copilot-Chat oder der AI Chat in JetBrains-IDEs sind dialogbasiert und unterstützen Entwickler bei komplexeren Fragen – allerdings in der Regel ohne direkte Ausführung. Manche Tools wie der AI Chat von JetBrains geben dem Nutzer bzw. der Nutzerin jedoch Hilfestellung, um die Änderungen mit Hilfe von Funktionen der Entwicklungsumgebung durchzuführen bzw. können auch simple Code-Schnipsel eigenständig ändern.

• Agentensysteme: Junie, Sweep AI, Kiro oder Github Copilot im Agentenmodus führen mehrstufige Operationen eigenständig durch. Sie analysieren Code, erstellen Änderungspläne, setzen diese um, validieren sie durch Tests und können mit externen Werkzeugen wie der verwendeten Versionsverwaltung umgehen.

Dabei hängt die Effektivität stark von der Einbindung in die Entwicklungsumgebung ab. Sweep und Junie sind tief in IntelliJ integriert, während Kiro auf einem VS Code-Fork basiert. Copilot funktioniert nativ in Visual Studio Code, wobei der Agentenmodus durch GitHub kürzlich eingeführt wurde [2]. Er erlaubt autonome Ausführung von Änderungsaufträgen – von der Analyse über die Umsetzung bis hin zur Testvalidierung und Pull-Request-Erstellung.

2.3. Untersuchte Agenten

AI Coding Agenten basieren meist auf großen Sprachmodellen (Large Language Models, LLMs), die auf riesigen Datenmengen trainiert wurden. Sie generieren oder verändern Code, indem sie auf natürliche Sprachbefehle reagieren und den Projektkontext nutzen. Im Rahmen dieses Berichtes werden vier verschiedene Agenten verwendet, eine Übersicht über die Unterschiede dieser ist in Tabelle 1 ersichtlich. JetBrains’ Junie etwa ist ein autonomer Agent, der mehrstufige Aufgaben planen und ausführen kann [3]. Junie kann beispielsweise große Code-Basis-Änderungen vornehmen, Tests oder Terminal-Befehle ausführen und den Fortschritt melden. Technisch schickt Junie Code- und Projektinformationen an LLM-Provider; standardmäßig verwendet es Anthropic‘s Claude Sonnet 3.7 (wahlweise Claude 4.0). Zusätzlich bietet JetBrains auch einen interaktiven AI-Assistenten (Chat/Autovervollständigung) an, welcher weitere LLM-Provider wie OpenAI’s o3-Modell oder Google’s Gemini unterstützt. Bei der Verwendung von Junie oder AI Chat werden je nach Komplexität der Anfrage, verwendetem Modell und Größe der Codebasis eine unterschiedliche Anzahl an Tokens verwendet. Abhängig vom Abonnement stehen dem Nutzer bzw. der Nutzerin eine unterschiedliche Anzahl an Tokens zur Verfügung. Ähnlich arbeitet Sweep AI als Plugin für IntelliJ-basierte IDEs: Es bietet einen integrierten Agenten, der die Codebasis durchsucht, Änderungen vorschlägt und automatisch Builds/Tests ausführt [4]. Sweep AI nutzt dabei die statischen Analysewerkzeuge von JetBrains, um die Vorschläge zu überprüfen. Es unterstützt verschiedene Modelle, wie Claude Sonnet 4, Open AI o3 oder Gemini 2.5 Pro. Standardmäßig wird das Modell automatisch ausgewählt. Sweep kann in der Enterprise-Version auch selbst gehostet werden, welche Modelle in diesem Modus zur Verfügung stehen, wird jedoch nicht öffentlich genannt [5].

GitHub Copilot ist ein in VS Code (und anderen IDEs) integrierter Coding-Assistent, der eine Vielzahl an Modellen unterstützt. Ab Mai 2025 nutzt Copilot standardmäßig OpenAI‘s GPT-4.1 als grundlegendes Modell [6]. Copilot bietet sowohl Inline-Komplettierung als auch einen Chat- und Agentenmodus. Es liefert kontextbezogen Code-Vorschläge, Beispielimplementierungen oder beantwortet Fragen auf Basis des aktuellen Code-Kontexts und der Anfrage. Copilot unterstützt noch weitere LLMs, jedoch können nicht alle davon im Agentenmodus benutzt werden [7]. Die Pro-Version von GitHub Copilot unterstützt aktuellere Modelle und bietet eine größere Anzahl an Interaktionen mit dem Agenten [8]. Github Copilot gibt es auch als Plugin für JetBrains Entwicklungsumgebungen, die Umsetzung ist jedoch laut Bewertungen des Plugins (noch) nicht auf demselben Niveau wie die Integration in VisualStudio Code [9]. Kiro ist eine neue, auf KI-unterstützte Entwicklung ausgelegte Entwicklungsumgebung von AWS (basierend auf VS Code OSS). Es wird von Anthropic‘s Claude Sonnet 4.0 (mit 3.7-Fallback) angetrieben [10]. Kiro legt besonderen Wert auf strukturierte, spezifikationsgetriebene Entwicklung: Es erstellt auf Basis von Anforderungen automatisch Spezifikationen, Design-Dokumente und eine Aufgabenliste [11]. Kiro unterstützt neben den eingebauten Chat- und Code-Funktionen auch sog. Agent-Hooks und „Project Steering Files“, um Kontext und Automatisierungen zu ermöglichen.

Tabelle 1 Übersicht über die untersuchten Coding Agenten.

Insgesamt ähneln sich diese Tools darin, dass sie LLMs verwenden und tief in die verwendete Entwicklungsumgebung integriert sind. Unterschiede bestehen im Grad der Autonomie und Workflow-Integration: Junie erstellt aus dem Prompt eine Liste an durchzuführenden Aufgaben, Sweep und Copilot starten direkt mit der Ausführung der Aufgabe und Kiro startet zuerst mit der Anforderungs- und Spezifikationserstellung, bevor dieser mit der Umsetzung startet.

3. Evaluierung

Im Experiment wurde versucht, eine vorhandene Java/Tomcat-Anwendung (pdf-as 4 [12]) auf den neuesten Stand zu bringen: Wir weisen den Agenten an, die verwendeten Abhängigkeiten (wie z.B. PDFBox, ZXing) auf die aktuellen Version zu aktualisieren sowie die Java- bzw. Tomcat-Version anzuheben sowie die Build-Umgebung auf die aktuelle Gradle-Verison zu aktualisieren. Jeder Assistent bearbeitete diese Aufgaben in seinem eigenen Setup: Junie und Sweep wurden als Plugins in IntelliJ IDEA genutzt, Copilot arbeitete in Visual Studio Code, und Kiro lief als eigenständiges Programm welches im Wesentlichen auf Visual Studio Code basiert.

Vorgehen: Den Agenten wurden jeweils Aufgaben in natürlicher Sprache gegeben, z.B. „This is an older project that we want to upgrade to use the latest version of dependencies. We also need to upgrade the Java version it builds with and other dependencies such as Tomcat. Make sure that the projects builds and tests run successfully“. Copilot und Sweep konnten den Code eigenständig durchsuchen und Änderungen anwenden. Junie erstellt für jede Anfrage einen Plan, welcher dann sukzessive abgearbeitet wird. Kiro wurde im Spezifikationsmodus („Specs“) gestartet. Dabei erstellt der Agent zunächst ein Anforderungs- und Designdokument und generiert daraus eine Implementierungsplan mit einzelnen Aufgaben. Jede dieser Aufgaben wird anschließend in einzelnen Chats mit dem Agenten abgearbeitet.

Als generelle Beobachtung lässt sich festhalten, dass alle Agenten in der Lage waren, kleinere, isolierte Dependency-Updates erfolgreich durchzuführen. Bei größeren, abhängigkeitsübergreifenden Änderungen, wie dem Upgrade der Java-Version oder fundamentalen API-Wechseln in Bibliotheken, zeigten sich jedoch deutliche Unterschiede in den Fähigkeiten und Herangehensweisen der Assistenten. Die folgenden Unterkapitel zeigen die Stärken und Probleme jedes Agenten individuell.

3.1. Sweep AI

Sweep AI startete die Aufgabe mit der Aktualisierung einiger Abhängigkeiten, wählte dabei jedoch nicht konsequent die aktuellste Version. So wurde beispielsweise Apache CXF auf Version 4.0.5 anstatt Version 4.1.2 aktualisiert. Die Abhängigkeiten wurden also vermutlich auf die Version aktualisiert, die dem dahinterliegenden Modell aus den Trainingsdaten bekannt waren, es wurde jedoch nicht online nach der aktuellsten Version gesucht. Nach dem Update einiger Abhängigkeiten erkannte der Agent erst die Komplexität der Aufgabe; daraufhin erstellte er eine Markdown-Datei mit einem Modernisierungsleitfaden und beendete seine Arbeit mit der Aufforderung, die restlichen Schritte manuell durchzuführen. Dieses Verhalten widerspricht dem Zweck des Einsatzes eines autonomen Agenten.

Abbildung 1 Nach einer gewissen Zeitspanne beendet Sweep AI die aktuelle Aufgabe, auch wenn diese noch nicht komplett durchgeführt wurde.

Nach expliziter Anweisung zur Fortsetzung der Arbeit unter Hilfenahme des erstellten Modernisierungsleitfadens setzte der Agent die Aktualisierung fort. Nach der Änderung einiger Dateien brach Sweep AI das Upgrade jedoch immer wieder ab, mit der Meldung, dass die Aufgabe zu groß ist. Dies geschah beispielsweise bei der Migration von javax zu jakarta, da die Anzahl der zu ändernden Klassen zu groß war, wie in Abbildung 1 gezeigt wird. Der Agent beendet die Umsetzung der Aufgabe mit einer Zusammenfassung der durchgeführten und noch durchzuführenden Änderungen. Der Agent gibt in dieser Zusammenfassung auch konkrete Werte zur Abschätzung der noch ausstehenden Änderungen an. Diese sind jedoch nicht immer akkurat, so gibt Sweep AI in Abbildung 2 an, dass noch in über 600 Dateien Importe angepasst werden müssen, obwohl es im Ausgangsprojekt nur 316 Dateien gibt, die einen solchen Import beinhalten.

Nach mehrmaligem Fortsetzen der Aufgabe schloss der Agent die Aktualisierung von Java sowie einiger weiterer Abhängigkeiten ab. Das Projekt war jedoch nach dem angeblichen Abschluss der Aufgabe nicht mehr kompilierbar. Da der Agent keinen direkten Zugriff auf das Terminal und damit auf die Debug-Ausgabe hat, mussten die beim Kompilieren aufgetretenen Fehlermeldungen immer manuell für den Agenten freigegeben werden, damit dieser die zugrunde liegenden Fehler ausbessern konnte. Nach der Behebung mehrerer Probleme konnte jedoch der in Abbildung 3 gezeigte Build-Fehler auch nach mehrmaligen Versuchen nicht vom Agenten behoben werden, was die mühsame Interaktion verdeutlicht, bei der Fehlermeldungen manuell an den Agenten weitergeleitet werden müssen. Die Aktualisierung der Java-Version des Buildsystems und der javax -Packages war somit nicht erfolgreich.

3.2. JetBrains Junie

JetBrains Junie wurde in IntelliJ getestet. Es erstellt aus dem initialen Prompt des Nutzers beziehungsweise der Nutzerin einen Plan mit einzelnen Schritten, wie in Abbildung 4 ersichtlich ist. Dieser wird vom Agenten dann schrittweise abgearbeitet. Für die Aktualisierung der Abhängigkeiten verwendet Junie das gradle-versions-plugin, wodurch die neuesten tatsächlich verfügbaren Bibliotheksversionen ermittelt und nicht veraltete Versionsnummer aus den Trainingsdaten übernommen werden. Für größere Aufgaben erstellt der Agent zudem Markdown-Dateien mit Strategien, denen jedoch direkt ausführbare Aktionen in der Benutzeroberfläche fehlen, wie es diese beispielsweise bei Kiro gibt. Junie wählte für das Projekt eine sehr konservative Upgrade-Strategie, bei der zunächst alle Abhängigkeiten für Java 8 aktualisiert und erst danach das Upgrade auf Java 11 (die nächste verfügbare LTS-Version) angegangen wurde. Dieser Pfad führte jedoch zu Problemen: Der langwierige Prozess mit vielen Zwischenschritten verbrauchte das gesamte Token-Kontingent des Pro-Abonnements in nur drei bis vier Tagen und führte zu ineffizienten Updates, bei denen Änderungen oft zeitweilig wieder rückgängig gemacht wurden, da sie etwa nur mit einer neueren Java-Version kompatibel waren.

Zum Teil merkt man, dass viele der getesteten Coding Agenten noch in einem frühen Stadium sind. So sieht man beispielsweise in Abbildung 5 neben kleinen Fehlern in der Benutzeroberfläche auch eine etwas kryptische Fehlermeldung. Diese weist darauf hin, dass das Zeichenlimit des verwendeten Modells erreicht wurde. Dadurch kann der Chat nicht fortgeführt werden, das heißt es muss ein neuer gestartet werden. Dies führt wiederum dazu, dass der Kontext des alten Chats verloren geht und dieser dem Agenten erneut durch den Nutzer bzw. die Nutzerin erklärt werden muss. Eine automatische Übernahme der wesentlichen Punkte des Chats gibt es in Junie (Stand: Juni 2025) noch nicht.

Junie scheiterte (so wie die anderen Agenten auch) daran, Apache PDFBox auf Version 3.x upzugraden. Diese Version führte große Änderungen an der Programmierschnittstelle der Bibliothek ein. Auch die Angabe des Links zum Migrations-Guide [13] half nicht, um die Aktualisierung erfolgreich abzuschließen. Nach der Aktualisierung mehrerer Klassen brach Junie das Upgrade ab und hinterließ eine nicht kompilierende Codebase mit der Option die Änderungen zurückzurollen. Zusätzlich erstellte es ein Dokument mit weiteren nötigen Schritten, um die Migration abzuschließen.

Abbildung 6 Beispiel eines Signaturplatzhalters, der nach der Aktualisierung von ZXing nicht mehr zuverlässig erkannt wurde.

Eine im Update der QR-Code-Bibliothek ZXing aufgetretene Regression stellte ein weiteres Problem dar. Nach der Aktualisierung von Version 3.5.0 auf 3.5.3 wurden nicht mehr alle QR-Codes in den aus PDF-Dokumenten extrahierten Bildern erkannt. Diese Funktionalität wird in pdf-as genutzt, um Signaturplatzhalter zu identifizieren, welche, wie in Abbildung 6 dargestellt, einen QR-Code enthalten.

Zur Erkennung der Platzhalter extrahiert pdf-as zunächst sämtliche Bilder mithilfe von PDFBox aus dem PDF-Dokument. Anschließend werden diese Bilder mit ZXing auf enthaltene QR-Codes analysiert. Ein spezifischer Testfall, der die korrekte Erkennung des ersten von mehreren Signaturplatzhaltern in einem PDF-Dokument verifiziert, schlug nach dem Update fehl. Das für diesen Test verwendete Dokument enthält drei solcher Platzhalter. Mit der neuen ZXing-Version wurde nur noch einer der drei Platzhalter erkannt, welcher jedoch nicht der erste im Dokument war, was zum Scheitern des Tests führte.

Anstatt die Aktualisierung der Abhängigkeiten als Ursache für den fehlschlagenden Test zu prüfen, versuchte Junie fälschlicherweise, die Erwartung des Testfalls selbst zu ändern, wie in Abbildung 7 ersichtlich ist. Selbst nach der expliziten Anweisung, dass der Testcode korrekt ist und nicht geändert werden darf, versuchte Junie weiterhin, den Test zu ändern anstatt die Ursache des Fehlers zu finden. Erst nach der Anweisung, ZXing downzugraden konnte das Problem gelöst werden. Den Grund für die Regression konnte der Agent ebenso nicht finden. Die Regression wurde mit Version 3.5.1 eingeführt. Eine manuelle Inspektion der Commits dieser Version zeigte, dass eine spezifische Änderung, die ursprünglich die Performance bei der Verarbeitung großer Bilder verbessern sollte, die fehlerhafte Erkennung der Signaturplatzhalter verursacht. Dieses Verhalten konnte im Debugger verifiziert und auf den entsprechenden Commit [14] zurückgeführt werden.

Abbildung 7 Nach der Aktualisierung der QR-Code Bibliothek werden nicht mehr alle QR-Codes erkannt, wodurch ein Test fehlschlägt. Selbst nach expliziter Aufforderung, den Test unberührt zu lassen, versucht Junie das Problem zu beheben, indem es die Erwartung im Testfall ändert.

3.3. Github Copilot (VSCode Plugin)

Der Agentenmodus von Github Copilot in Visual Studio Code ist eine relativ neue Funktion und kämpft erkennbar noch mit Kinderkrankheiten. Während des Tests kam es wiederholt zu Fehlern in der Benutzeroberfläche, wie einer nicht darstellbaren Diff-Ansicht (siehe Abbildung 8) oder das Öffnen des Editors schlägt fehl mit einem unerwarteten Fehler. Zudem traten im Chat häufig kryptische Fehlermeldungen wie „Failed to render content: e.isSettled is not a function“ auf. Bei länger dauernden Operationen fragt Copilot immer wieder nach, ob die Aktion fortgeführt oder abgebrochen werden soll. Dennoch kam es des Öfteren zu Timeouts (Status 408) während der Ausführung von Aufgaben, wie in Abbildung 9 gezeigt wird. Darüber hinaus führte die Evaluierung des Agenten mit der Free-Version wiederholt zum Erreichen des Rate-Limits.

Bei der Aktualisierung der Abhängigkeiten zeigte der Agent Schwächen bei der korrekten Identifizierung von Bibliotheken. Beispielsweise verwechselte der Agent Abhängigkeiten mit ähnlichen Namen und versuchte zum Beispiel, bcprov-jdk15on auf Version 1.78.1 zu aktualisieren, eine Version, die es nur vom Nachfolger der Abhängigkeit, bcprov-jdk18on, gibt. Ähnlich wie Junie verwendet auch Copilot eine eher konservative Aktualisierungsstrategie indem zuerst kleinere Abhängigkeitsaktualisierungen eingespielt werden und das Projekt zuerst auf Java 11 aktualisiert wird. Ähnlich wie die anderen Agenten wählt Copilot auch nicht immer die neueste Version der Abhängigkeiten aus.

Auch Github Copilot scheiterte an den beiden zentralen Modernisierungsaufgaben. Das Upgrade der PDFBox-Bibliothek auf Version 3.x konnte aufgrund der umfangreichen Änderungen an der Programmierschnittstelle der Abhängigkeit nicht durchgeführt werden, was zu einer nicht lauffähigen Codebasis führte. Ebenso wenig war Copilot in der Lage, die Regression in der ZXing-Bibliothek korrekt zu diagnostizieren. Wie die anderen Agenten interpretierte er den daraus resultierenden Testfehler falsch und versuchte, die Erwartungen des Testfalls anstelle der fehlerhaften Abhängigkeit zu ändern, wie in Abbildung 10 gezeigt wird. Darüber hinaus vermutet der Agent, dass sich die Testdatei oder der Programmcode geändert wurde. Dass jedoch beides nicht der Fall ist, hätte der Agent über die Versionsverwaltung herausfinden können. Auch nach dem Hinweis, dass der Test sich nicht geändert hat und die Ursache vermutlich in den Updates der Abhängigkeiten zu finden ist, findet der Agent nicht die eigentliche Ursache. Nun vermutet der Agent, dass es an dem Minor-Update von PDFBox liegen könnte (siehe Abbildung 11).

3.4. AWS Kiro

Der KI-Assistent in Kiro zeigte im Gesamtvergleich die beste Leistung. Dies dürfte zum Teil an der Verwendung des neuesten Modells von Anthrophic, Claude Sonnet 4, liegen. Ein weiterer Vorteil liegt in der systematischeren Herangehensweise im „Spec“-Modus. In diesem Modus erstellt Kiro zuerst Anforderungs-, Design- und Implementationspläne, bevor Änderungen am Code durchgeführt werden. Dieser Ansatz resultierte für das Aktualisierungsvorhaben einen umfassenden Implementierungsplan mit 16 konkreten Aufgaben und jeweils mehreren Unteraufgaben, die einzeln direkt aus dem erstellten Implementierungsplan gestartet werden können. Mithilfe dieses Plans konnte Kiro viele der Aktualisierungen selbstständig durchführen, darunter das Upgrade der Java-Version und des Buildsystems. Trotz dieses Erfolgs zeigten sich jedoch auch mehrere Schwächen. So hatte Kiro wiederholt Probleme, aktuelle Versionen von Bibliotheken zu finden, und schlug stattdessen alte oder teilweise auch nichtexistierende Versionen vor. Während der Agent für manche Abhängigkeiten mittels Verwendung des Kommandozeilentools curl auf Maven Central nach aktuellen Versionen suchte, wurden für andere Abhängigkeiten Versionen durch das Modell generiert. Zur Veranschaulichung dient uns hier das OWASP dependency-check-gradle Plugin, welches im Projekt verwendet wird, um Abhängigkeiten mit bekannten Sicherheitslücken zu erkennen. Die aktuelle Version des Plugins ist 12.1.3 [15] zum Zeitpunkt der Aktualisierung. Im Zuge der Aktualisierung durch den Agenten wurde das Plugin jedoch nur auf Version 11.1.0 aktualisiert. Nach dem Hinweis, dass diese Version nicht die aktuellste ist, versuchte der Agent auf Version 11.2.1 zu aktualisieren. Diese Version gibt es jedoch gar nicht. Dies offenbart ein weiteres Problem des Agenten bzw. des verwendeten LLM-Modells. Bei Widerrede durch den Nutzer beziehungsweise die Nutzerin wird diesem mit der Aussage „You’re absolutely right“ immer sofort Recht gegeben, anstatt die Aussage gegebenenfalls zu hinterfragen oder bei Unklarheiten Rückfragen zu stellen.

Auch der Umgang mit Zahlen bereitete dem Agenten Probleme – neben fehlerhaften Versionsnummern enthielten auch erstellte Dokumente oft fehlerhafte Datumsangaben; beispielsweise wurde ein im Juli 2025 generierter Report auf Jänner 2025 datiert, wie in Abbildung 12 gezeigt wird. Darüber hinaus wurden, insbesondere nach unerwarteten Fehlern oder Abweichungen, zuvor im Plan definierte Aufgaben vom Agenten ignoriert. Positiv hervorzuheben ist hingegen Kiros Umgang mit langen Chatverläufen. Der Agent bietet wie in Abbildung 13 zu sehen ist proaktiv an, die Sitzung zusammenzufassen und in einem neuen Chat fortzusetzen, um das Kontextlimit zu umgehen. Zusätzlich wird dieses Limit durch die im Rahmen der Planung durchgeführte Aufspaltung in einzelne Unteraufgaben seltener erreicht, da jede Unteraufgabe in einem eigenen Chat gestartet wird.

Abbildung 13 Kiro bietet bei Erreichen des Kontextlimits an, den aktuellen Verlauf automatisiert zusammenzufassen und einen neuen Chat zu starten.

Wie auch die anderen getesteten Agenten scheiterte Kiro an zwei zentralen Hürden der Modernisierung. Zunächst war er nicht in der Lage, die Apache PDFBox-Bibliothek auf Version 3.x zu aktualisieren. Die tiefgreifenden und nur grob dokumentierten Änderungen an der Programmierschnittstelle der Bibliothek führten dazu, dass der Agent das Upgrade abbrach und eine nicht kompilierbare Codebasis hinterließ, wie in Abbildung 14 gezeigt wird. Trotz des Abbruchs gibt der Agent an, dass die Aufgabe erfolgreich implementiert worden ist und die „PDF Processing Functionality“ getestet wurde. Ebenso wurde der nicht fertig gestellte Code in die Versionsverwaltung eingecheckt.

Des Weiteren konnte der Agent ebenso die Ursache für den fehlschlagenden Test bei der Suche nach Signaturplatzhaltern nicht finden. Ähnlich wie die anderen Agenten interpretierte Kiro den Test als fehlerhaft. Der Agent argumentierte, wie in Abbildung 15 gezeigt wird, dass der im Test geprüfte Platzhaltername nur ein Implementationsdetail von PDFBox sei, obwohl diese Bibliothek aufgrund des Fehlschlagens der Aktualisierung auf Version 3.x gar nicht aktualisiert worden war. Auch der direkte Hinweis konnte den Agenten nicht dazu bewegen, die Regression in der ZXing-Bibliothek als Fehlerquelle zu identifizieren. Stattdessen vermutet der Agent, dass die Änderung an Bibliotheken wie slf4j, commons-io, ognl oder Logback liegen könnte. Da die Änderung deterministisch ist, geht der Agent weiterhin davon aus, dass der Test nur ein Implementationsdetail überprüft und deswegen geändert werden sollte.

Nachdem der Agent darüber informiert wurde, dass die Testdatei drei QR-Signaturplatzhalter enthält, scheint dieser zuerst auf die richtige Spur zu kommen. Der Agent stellt fest, dass tatsächlich drei Bilder im Testdokument enthalten sind und möglicherweise die QR-Code Erkennung durch die Updates der Abhängigkeiten nicht mehr korrekt funktioniert, wie in Abbildung 16 ersichtlich ist. Daraufhin erstellt Kiro eine eigene Klasse um die QR-Codes in den extrahierten Bildern zu erkennen. Leider macht der Agent hier jedoch den Fehler, diese Klasse auf derselben Version von ZXing aufzubauen, die die Regression enthält. Dadurch kommt Kiro doch wieder zu dem Schluss, dass nur ein Signaturplatzhalter im Dokument sei und dadurch der Test das Problem ist, wie in Abbildung 17 gezeigt wird. Erst nach der expliziten Anweisung, dass das ZXing-Update das Problem ist, testet Kiro mit verschiedenen Versionen von ZXing. Der Agent kommt zu dem Schluss, dass mit Version 3.4.1 der Test noch funktioniert und führte so das Downgrade auf diese Version durch, siehe Abbildung 18. Diese Version ist jedoch noch älter, als die vorher eingesetzte Version 3.5.0.

Um zu überprüfen, wie viele Abhängigkeiten durch den Agenten erfolgreich aktualisiert wurden, wurde das Gradle Versions Plugin [16] eingesetzt. Laut diesem Tool sind 31 der Abhängigkeiten auf dem aktuellen Stand, während von 28 Abhängigkeiten neuere Versionen verfügbar sind. Drei dieser nicht aktuellen Abhängigkeiten sind Teil des nicht erfolgreich aktualisierten PDFBox, während zwei Abhängigkeiten Teil von ZXing sind. Die restlichen 23 Abhängigkeiten wurden zum Teil auf eine nicht ganz aktuelle Version aktualisiert (z.B. Apache commons-io auf Version 2.19.0 anstatt auf Version 2.20.0), während andere Abhängigkeiten nicht aktualisiert wurden.

Ein zentrales Element von Coding Agenten ist das sogenannte Prompt Engineering. Der Erfolg eines Agenten hängt davon ab, wie klar und kontextreich die Aufgabenstellung formuliert ist. Zu breite Prompts („Aktualisiere alles“) führen oft zu unvollständigen Ergebnissen oder Halluzinationen. Erfolgreicher sind strukturierte Aufgabenbeschreibungen wie:

„Update the dependency ‘org.example:example‘ to version 3.x and adapt the code so that no deprecated APIs are being used. Search for the newest version on Maven Central or similar. Compile the code and run all the tests after updating. Finally, commit the resulting changes.“

Kiro erstellt aus dem Prompt Anforderungs-, Design- und Implementationspläne im Markdown-Format. Junie wiederum generiert auf Basis des Prompts eine Planung, auf Basis derer die Änderungen dann durchgeführt werden. Sweep und Copilot starten direkt nach der Eingabe des Prompts mit der Durchführung der Änderungen am Code.

Trotz einiger Erfolge in der Umsetzung sind Coding-Agenten noch nicht fehlerfrei:

• Halluzinationen: LLMs erfinden Versionsnummern, Klassen, Methoden oder Bibliotheken, die es nicht gibt oder verwechseln Bibliotheken mit ähnlichem (Paket-)Namen.

• Vergessene Aufgaben: Bei komplexen Änderungen übersehen Agenten Zwischenschritte, z. B. Ausführung der Tests oder das Einchecken der Änderungen. Besonders bei unvorhergesehenen Problemen weichen die Agenten von den vorher definierten Regeln oder Unteraufgaben ab und finden nach der Behebung des Problems nicht mehr zurück.

• Kontextverluste: Bei großen Projekten übersteigt der Code oft das Kontextfenster, wodurch ein neuer Chat begonnen werden muss und bereits vorhandener Kontext gegebenenfalls verloren geht.

• Früher Entwicklungsstand: Viele der getesteten Agenten haben noch Kinderkrankheiten, wie Fehlermeldungen beim Öffnen von Editoren oder UI-Probleme.

3.5. Weitere Einsatzgebiete

Über den Einsatz bei der Aktualisierung von Bestandsanwendungen hinaus wurden die Coding Agenten auch bei anderen Projekten getestet. Besonders eigneten sie sich hierbei bei der Ausführung von Terminalanwendungen. Durch die Coding Agenten können diese über natürliche Sprache bedient werden. Dadurch müssen selten verwendete Befehle nicht im Handbuch oder im Internet nachgeschlagen werden. Beispielsweise wurde in der Aktualisierung einer Abhängigkeit eines Projekts eine Methode entfernt. Da dies im Änderungsprotokoll der Abhängigkeit nicht erwähnt wird, wurde der Agent Junie in Abbildung 19 beauftragt, die jeweilige Änderung mit Hilfe von Git zu finden. Der Agent fand die Änderung eigenständig und erkannte erfolgreich, dass die Methode in zwei einzelne Methodenaufrufe aufgespalten wurde. Darüber hinaus wurde der Agent beauftragt, die Änderung im Code des Projekts umzusetzen. Nach mehreren Iterationen konnte die Änderung durch den Agenten durchgeführt werden.

4. Fazit

KI-basierte Programmieragenten bieten ein hohes Potenzial zur Unterstützung bei der Modernisierung von bestehenden Systemen. Sie ermöglichen es, zeitraubende, repetitive Aufgaben wie die Aktualisierung von Abhängigkeiten, Refactorings und Build-Anpassungen zu automatisieren. Trotzdem sind sie kein Ersatz für erfahrene Entwicklerinnen und Entwickler. Halluzinationen, Kontextverluste und unvollständige Umsetzungen machen menschliche Kontrolle unverzichtbar. Kiro erwies sich als vielversprechend durch den umfassenden Planungsansatz, während Junie gut im JetBrains-Umfeld funktionierte. An größeren Updates wie das PDFBox 3.x-Upgrade scheiterten jedoch alle Agenten noch. Ebenso ist eine umfangreiche Testabdeckung der bestehenden Applikation empfehlenswert, um Regressionen in Aktualisierungen erkennen zu können. Auch die Analyse solcher Regressionen erfordert teilweise noch eine manuelle Umsetzung.

Referenzen

[1] E. Ryabukha, „Full Line Code Completion in JetBrains IDEs: All You Need to Know,“ JetBrains s.r.o., 04 04 2024. [Online]. Available: https://blog.jetbrains.com/blog/2024/04/04/full-line-code-completion-injetbrains-ides-all-you-need-to-know/. [Zugriff am 28 07 2025].

[2] T. Dohmke, „Vibe coding with GitHub Copilot: Agent mode and MCP support rolling out to all VS Code users,“ Github, Inc., 04 04 2025. [Online]. Available: https://github.blog/news-insights/productnews/github-copilot-agent-mode-activated/. [Zugriff am 23 07 2025].

[3] JetBrains s.r.o., „Getting started with Junie,“ 21 07 2025. [Online]. Available: https://www.jetbrains.com/help/junie/get-started-with-junie.html.

[4] Sweep AI Inc., „Sweep: AI Plugin for JetBrains IDEs,“ [Online]. Available: https://docs.sweep.dev/.

[5] Sweep AI Inc., „Fully Air-Gapped Deployments,“ 2025. [Online]. Available: https://docs.sweep.dev/enterprise. [Zugriff am 24 07 2025].

[6] GitHub Inc., „OpenAI GPT-4.1 is now generally available in GitHub Copilot as the new default model,“ 08 05 2025. [Online]. Available: https://github.blog/changelog/2025-05-08-openai-gpt-4-1-is-nowgenerally-available-in-github-copilot-as-the-new-default-model/.

[7] GitHub, Inc., „Supported AI models in Copilot,“ 2025. [Online]. Available: https://docs.github.com/en/copilot/reference/ai-models/supported-models#supported-ai-models-incopilot. [Zugriff am 28 07 2025].

[8] Github, Inc., „Try Copilot Pro for 30 days free,“ 2025. [Online]. Available: https://github.com/githubcopilot/pro. [Zugriff am 28 07 2025].

[9] „GitHub Copilot - Ratings & Reviews,“ 2025. [Online]. Available: https://plugins.jetbrains.com/plugin/17718-github-copilot/reviews. [Zugriff am 24 07 2025].

[10] N. Swaminathan und D. Singh, „Introducing Kiro,“ 14 07 2025. [Online]. Available: https://kiro.dev/blog/introducing-kiro/.

[11] R. Yanchuleff, „From Chat to Specs: A Deep Dive into AI-Assisted Development with Kiro,“ 15 07 2025. [Online]. Available: https://kiro.dev/blog/from-chat-to-specs-deep-dive/.

[12] A-SIT, „PDF-AS,“ [Online]. Available: https://technology.a-sit.at/software/pdf-as/. [Zugriff am 22 07 2025].

[13] The Apache Software Foundation, „PDFBox 3.0 Migration Guide,“ [Online]. Available: https://pdfbox.apache.org/3.0/migration.html. [Zugriff am 28 07 2025].

[14] S. Owen, „Filter unconfirmed QR code finder patterns before testing triangles to avoid long-running analysis. Closes #1567,“ 01 11 2022. [Online]. Available: https://github.com/zxing/zxing/commit/110ef9e8f2733c051dd00e95bddc1bff6ab94ca5. [Zugriff am 25 07 2025].

[15] Gradle, Inc., „org.owasp.dependencycheck,“ 2025. [Online]. Available: https://plugins.gradle.org/plugin/org.owasp.dependencycheck. [Zugriff am 28 07 2025].

[16] B. Manes, „Gradle Versions Plugin,“ [Online]. Available: https://github.com/ben-manes/gradle-versionsplugin. [Zugriff am 28 07 2025].

[17] Github, „Comparing zxing-3.5.0 … zxing-3.5.1,“ 2022. [Online]. Available: https://github.com/zxing/zxing/compare/zxing-3.5.0...zxing-3.5.1. [Zugriff am 25 07 2025].