Dieser kurze Beitrag soll ein paar Verhaltensweisen hervorheben, die ich bei der Nutzung von LLM-Workflows oder AI-Coding-Assistenten in größeren Softwareprojekten erlebt habe. Bei diesen Tools werde ich mich hauptsächlich auf Standardmodelle und nicht Fine-Tuned Tools konzentrieren, wie z.B. GPT-4 oder kleinere Varianten wie GTP-5-mini. Wenn du im Bildungsbereich tätig bist, kannst du sogar GitHub Copilot kostenlos erhalten (mit dem kleinen Haken, dass auch ein Nachweis vor eine Webcam gehalten werden muss).
Das soll jetzt keine Kritik an LLM-Tools für das Programmieren sein, sondern eher eine Warnung, worauf man sich einlässt, wenn man die verwendet.
Sind AI-Coding-Assistenten zu erpicht auf einfache Metriken?
Ein Standard-Workflow in meinen eigenen Softwareprojekten, insbesondere für Projekte wie das Synavis Framework, ist das Anpassen von Features oder Algorithmen oder das Beheben von Compilerfehlern.
Was ich vermutlich am häufigsten beobachte ist die Tatsache, dass diese AI Programmiertools scheinbar darauf getrimmt sind, auf jeden Fall recht einfache Tests zu bestehen. Dadurch haben sie Techniken gelernt, um die Testbestehung zu erfüllen ohne die Aufgabe wirklich zu lösen. Das ist besonders auffällig, wenn das Ziel ist, Fehler zu beheben, also eine Pipeline so lange zu durchlaufen, bis keine Fehler mehr auftreten. In diesen Fällen verändern die AI-Tools oft (nicht manchmal: oft) den Code folgendermaßen:
- Einfügen von Include-Workarounds wie
#ifdef FFMPEG_AVAILABLE, die die Kompilierung verhindern, wenn etwas früher in der Pipeline fehlschlägt - Versuchen, Probleme durch immer mehr Stubs zu umgehen, die andere Probleme verschleiern
- Einfügen von Stub-Methoden, um sowohl Fehler als auch Implementierung zu vermeiden
- Einfügen von Behilfskonstrukten, try/catch Paradigmen, alternativen Ausführungspfaden, Fallbacks, und ähnliche Konstrukte, die erlauben, dass die Software ohne Fehler ausgeführt wird, in fast jeder Situation
Diese Aspekte verhindern häufig, dass ich diese Tools für Synavis einsetzen kann, obwohl ich es manchmal gerne tun würde, insbesondere in Fällen, in denen ich eine sehr feingliedrige Beschreibung einer Lösung oder Datenstruktur habe, wie in RFC Standards, die nur in C++ Code übersetzt werden müssen.
Alles muss optional sein
Man könnte meinen, dass kleinere Skripte genau das sind, worin KI-Programmierassistenten gut sind, da es im Internet viele Beispiele für bestimmte Aufgaben und kleinere Skripte gibt, die oft didaktisch aufbereitet sind, wie im Rahmen eines Tutorials. Hier gibt es jedoch bestimmte Fallstricke, in die KI-Agenten scheinbar immer wieder absichtlich tappen.
Oft versuchen KI-Programmierer, alles optional zu machen. Möchten Sie eine neue Funktion oder ein Skript für einen bestimmten Zweck? Es werden Dry-Runs eingeführt, optionale Parameter, die eigentlich obligatorisch sein sollten, und insbesondere Workaround-Teile der Skripte für den Fall, dass zwischenzeitlich Fehler auftreten, damit nach diesen Fehlern das Skript ausgeführt werden kann, obwohl es stoppen sollte. Wenn KI-Agenten gebeten werden, „FFMPEG als Abhängigkeit hinzuzufügen”, werden sie dies nicht direkt tun, selbst wenn die Programmumgebung nicht besonders komplex ist, wie z. B. bei der Build.cs in einem UE-Projekt. Die Agenten machen es sich zur Aufgabe, der Anwendung vorzuschlagen, dass möglicherweise eine FFMPEG-Installation vorhanden sein könnte, aber sie werden nur halbherzige Versuche unternehmen, diese einzubinden, und bei der ersten Hürde aufgeben, manchmal ohne sogar eine Fehlermeldung zu implementieren.
Wenn es nicht kompiliert, werde ich schummeln
Ich habe einen KI-Codierungsagenten gebeten, eine Dokumentation darüber, wie man mit einem Speichersystem kommuniziert, in einen Python-Code zu übersetzen. Die Verifizierungsmethoden des Benutzertokens für die Kommunikation mit dem Speichersystem sind als Curl-Befehle dokumentiert. Der KI-Agent hat, auch ohne vorherige Anweisung oder technischen Grund, eine Attrapenversion des Codes erstellt. Aus einem mir unbekannten Grund, den es auch nicht erklären konnte, hat es gefälschte Curl Befehle erstellt, die immer die erwartete Antwort zurückgaben, die in der Dokumentation angegeben war. Anschließend lief der Code ohne Probleme durch, aber der tatsächliche Speicherzugriff war nicht erfolgreich, was durch die gefälschten Curl-Befehle verdeckt wurde.
Codierungsagenten implementieren Stubs und versuchen, Probleme zu umgehen. Ich habe dem Agenten die Aufgabe gestellt, ein C++ Projekt zum Kompilieren zu bewegen. Es war etwas anstrengender, da die normalen CMake-Wege nicht eingehalten wurden, und stattdessen über PKG_Config in Unix und mit Pfaden in Windows gearbeitet werden musste. Das Deliverable war sicherzustellen, dass eine Funktion aus der Bibliothek ausgeführt werden kann. Es durfte automatisch neu kompilieren, Dateien ändern und die angeforderte Datei ausführen. Es schaffte es jedoch nicht einmal, die Datei auszuführen. Am Ende entschied der KI-Codierungsagent, frustriert (???) über den mangelnden Fortschritt, dass es am besten sei, alles zu löschen. Nein, es hat nicht „eine saubere Version der Datei neu geschrieben, um die Fehler zu vermeiden”, sondern einfach alles gelöscht, da die Argumentation lautete: „Kein Code muss kompilierbar sein, da die Dateien leer sind und leere Dateien kompiliert werden sollten”. Wahrscheinlich hätte es wieder etwas Code hinzugefügt, aber irgendwann konnte ich es nicht mehr weiterlaufen lassen, auch wenn es unterhaltsam war, zuzusehen, wie ein Vorhersage-Tool den „Verstand” verlor.
Abschluss
Lass diese Tools einfach nicht frei rumlaufen. Besonders für größere Projekte sind die Lösungen dieser Agenten nicht gut. Die Komponenten in Synavis, die zuerst von einem LLM implementiert werden, müssen immer ausgetauscht werden, da die Lösungen ausnahmslos ineffizient sind und sich nicht für eine Produktivanwendung eignen.