KI-Agenten und das Refactoring, das nie stattfindet
AI Agents and the Refactoring That Never Happens
Der Autor beobachtet, dass Teams mit KI-Agenten zunehmend auf Refactoring verzichten, weil die Agenten sich nie in komplexem Code verlieren. Früher war das menschliche Gefühl, den Überblick zu verlieren, ein wichtiges Signal für notwendige Umstrukturierungen. Jetzt fehlt dieses Signal, wodurch Systeme unkontrolliert wachsen und Menschen die Fähigkeit verlieren, ihren eigenen Code zu verstehen. Der Artikel argumentiert, dass saubere, modulare Strukturen nicht nur für Menschen, sondern auch für die Effizienz und Genauigkeit von KI-Agenten entscheidend sind. Er plädiert dafür, die Refactoring-Entscheidung bewusst wieder in den Entwicklungsprozess zu integrieren.
Das Bequeme an einem Agenten, der sich nie verirrt, ist real – aber ‚der Agent kann noch Sinn daraus machen‘ ist nicht dasselbe wie ‚das System ist gesund‘.
- bunderbunder
Ich bin nicht einverstanden mit der Behauptung, dass "KI-Agenten nicht die Orientierung verlieren". Was ich stattdessen beobachtet habe, ist, dass sie nicht das Gefühl haben, sich verloren zu fühlen. Das ist ein großer Unterschied.
Diesen Sommer habe ich viel Zeit damit verbracht, einen Coding-Agenten zu nutzen, um mir bei der Entwirrung einer tiefen und komplizierten Datenverarbeitungspipeline zu helfen. Sie war selbst von Agenten in bemerkenswert kurzer Zeit gebaut worden. Aber es war auch klar geworden, dass sie voller Fehler steckte und viele schlechte Daten produzierte.
Was ich schnell entdeckte, war, dass über die Hälfte meiner Fragen sehr selbstbewusst falsche Antworten erhielten. Und selbst wenn ich das jeweilige Problem endlich diagnostiziert hatte, war es schwierig, dem Agenten bei Fehlerbehebungen zu vertrauen. Da es ihm noch schwerer fiel, Datenflüsse zu verfolgen als mir (ich nutze diese Gelegenheit, um zur Diskussion zu stellen, dass schneller nicht unbedingt besser ist), erwies es sich als eine Art Affenpfote. Ja, es würde den genauen Bug beheben, den ich zu beheben bat, aber typischerweise neue Fehler in den Prozess einführte. Und ja, ich hatte diesen Kampf mit allen neuesten und besten Modellen.
Letztendlich kam ich zu dem Schluss, dass der Agent in dieser Codebasis tatsächlich tief und hoffnungslos verloren war. (Anmerkung: Und wahrscheinlich wurde dieser Code überhaupt erst so schlecht, weil die Agenten, die ihn gebaut haben, eine Weile verloren waren, aber nicht in der Lage, dieses Problem zu erkennen und die Aufmerksamkeit ihrer Betreiber darauf zu lenken.)
- joshstrange
Währenddessen bin ich hier und refaktoriere so viel wie möglich aus Jahren (oder Jahrzehnten) von menschengeschriebenem Code. Das Chaos, das ich entweder geerbt habe, mitgeschaffen habe oder auf dem ich aufgebaut habe, in etwas Sauberes und Makelloses zu verwandeln, ist vielleicht meine liebste LLM-Anwendung. Gleiches gilt für persönliche Projekte, Codebasen, die sich über viele Jahre entwickelt haben, als ich zufällig Zeit hatte, die nicht so "sauber" gehalten wurden, wie ich es mir wünschte, und die endlich aufgeräumt wurden.
Ich wollte schon immer, dass mein Code sauber und leicht verständlich ist, aber das Leben, Deadlines, sich ändernde Prioritäten usw. haben dem im Weg gestanden. Jetzt kann ich endlich mein persönliches Nirwana verwirklichen.
Allerdings musste ich Modelle von zu starker Abstraktion oder Ähnlichem abbringen, weil es den Code zu schwer verständlich machte.
- simonw
Ich habe festgestellt, dass der Zugang zu Coding-Agenten mir geholfen hat, viel weniger tolerant gegenüber schlechten Codemustern zu sein, die refaktoriert werden können.
Refactoring hatte früher echte Kosten – es war eine beträchtliche Menge an Zeit, die von der Arbeit an neuen Funktionen abgezogen werden musste.
Jetzt kann ich eine potenzielle Refaktorisierung erkennen, einen Prompt in einem asynchronen Coding-Agenten (oder in einem Worktree oder was auch immer) abfeuern und 20 Minuten später zurückkommen und entweder akzeptieren, ein wenig daran herumstochern oder es verwerfen. Kostet mich fast nichts.
- joshka
Einiges davon fühlt sich an, als ob es darauf zurückzuführen ist, dass die Agenten darauf trainiert sind, Code zu produzieren, der die verschiedenen Benchmarks erfüllt, kombiniert mit Reaktionen auf Dinge, die zuvor maladaptiv waren. D.h. Dinge, die im Post-Training explizit aus dem Modell herausgezüchtet wurden. Ich denke, es fehlen viele langfristige Software-Engineering-Prinzipien, die nicht in die Art und Weise eingebacken zu sein scheinen, wie die Modelle standardmäßig Code schreiben.
Ich habe die Vermutung, dass die Leute, die das Post-Training der Modelle machen, tendenziell jüngere Forscher sind, die nicht an großen komplexen Softwaresystemen gearbeitet haben, sodass ihr Geschmack in dieser Hinsicht nicht so entwickelt ist, was hier wichtig ist.
Aber das ist ein Bereich, der mit geeigneten frühen Anweisungen gesteuert werden kann ("Wenn du Implementierungskompromisse wählst, baue auf langfristige Wartbarkeit und Verständlichkeit des Codes, anstatt nur den exakten Code zu implementieren, der notwendig ist, um die Probleme zu lösen. usw. Chain of Thought enthält oft Informationen, die in einer zukünftigen Agentensitzung wiederholt werden müssten; stelle sicher, dass du sie im Code oder in externen Dokumenten persistierst, damit zukünftige Sitzungen und das Verständnis des Benutzers respektiert werden.")
Es kann auch als Schritt nach der Änderung mit ähnlichen Effekten durchgeführt werden. Und du kannst deine Agenten nutzen, um diese Schicht in deine allgemeine Vorgehensweise für den Umgang mit den Verbrechen generierten Codes einzubauen. Aber eines der Dinge, die alle KI-Labore tun sollten, ist, AGENTS.md in echten Projekten als harte Ausdrücke dessen zu betrachten, welche Fehlermodi echte Projekte [...]
- moezd
KI-Agenten verlieren ständig die Orientierung, besonders wenn die Codebasis bereits außer Kontrolle geraten ist.
Deine Disziplin zahlt sich nur aus, wenn du deinen Code bereits verstehst und/oder eine klare Baseline für deine Standards festgelegt hast, bevor du in einen Feature-Entwicklungsrausch startest. Und sie muss bei jeder Runde durchgesetzt werden, sonst reißt der Feuerwehrschlauch der Codegenerierung leicht die Haustür ein.