LLM‑Agents: Herausforderungen und Lösungsansätze
LLM‑Agents arbeiten bisher eher nach einem Top‑Down‑Waterfall-Modell, wodurch sie schwer zu iterieren sind, ihre Fähigkeiten nicht ausbauen können und auf sorgfältige Code‑Reviews angewiesen bleiben.
Key Takeaway
Agents arbeiten bisher eher nach einem Top‑Down‑Waterfall-Modell, wodurch sie schwer zu iterieren sind, ihre Fähigkeiten nicht ausbauen können und auf sorgfältige Code‑Reviews angewiesen bleiben.
Summary
- 2025 wird als „Jahr der Agenten“ bezeichnet; der Autor nutzt LLM‑Agents für persönliche Projekte (Ratesmovies.net) und im Unternehmen (Cursor).
Beobachtung 1 – Agents sind waterfall‑orientiert
- Agenten planen zuerst ein gesamtes Feature („Plan“ und „TODO“) und führen anschließend die Schritte sequentiell aus.
- Der letzte Schritt ist üblicherweise das Testen bzw. Ausführen des Codes, sodass Fehler erst spät erkannt werden.
- Der Versuch, Agenten zu bottom‑up‑Plänen zu zwingen, schlägt fehl; sie bleiben beständig waterfall‑orientiert.
- Beispiel: Bash‑Deploy‑Script – Agent fehlte bei der Umsetzung; bei gezielter, schrittweiser Anleitung kam die Lösung zustande.
Beobachtung 2 – Schnelle Code‑Generierung
- Agenten liefern zwar fehlerhafte, aber sehr zügige Code‑Snippets (Sekunden bis Minuten).
- Der Autor nutzt sie für kleine Features/Commits, begleitet von schnellen Reviews im selben Chat.
- Durch das „Spionieren“ in die Denk‑Schritte des Agents kann der Mensch frühzeitig Feedback geben.
Beobachtung 3 – Keine Karriereentwicklung der Agenten
- Bei jedem neuen Chat beginnt die Agentenleistung von Null.
- Das AGENTS.md‑Prompt ausweiten reicht nicht, weil essentielle Regeln, Nuancen und Kontext nicht ins Modell passen.
- Agenten sollten Zugriff auf frühere Entwicklungs‑Sessions haben, ähnlich wie Menschen Wissen aus vergangenen Projekten abrufen.
- Cursor nutzt Summarisation, wodurch Agenten anfällig für „Amnesien“ werden; die Agenten können nicht im gesamten Kontext suchen.
Beobachtung 4 – Code‑Reviews sind unverzichtbar
- Mittelmäßige Programmierfähigkeiten und fehlende Fortschrittsfähigkeit erfordern robuste Code‑Reviews.
- Der Autor betont, dass nur derjenige, der den Agenten steuert, für die Qualität verantwortlich sein sollte, um Qualitätsverlust zu vermeiden.
- Code‑Reviews verhindern, dass LLM‑generierter, schlechter Code übernommen wird.
Beobachtung 5 – Übermäßige Abhängigkeit von Code‑Analyse
- Agenten neigen zu iterativem Durchsuchen und Debug‑Logik ohne echte Feedback‑Schleifen.
- Fehlerdiagnose auf Basis von Code‑Lesen kann falsch liegen, was zu unproduktiven Refactorings führt.
- Beispiel: CSS‑Opacity‑Bug bei Ratesmovies.net, bei dem Agenten immer wieder nach falschen Ursachen suchten.
- Der Autor setzt eine „1‑Versuch‑Regel“, um die Produktivität zu schützen.
Beobachtung 6 – Menschliche Frustration über Hype‑Erwartungen
- LLM‑Agents überschreiten Erwartungen, was zu Überforderung und Frustration führt.
- Der Autor kritisiert unnötiges Rauschen von LLM‑Texterzeugung, dehumanisierte Kommunikation und die Notwendigkeit authentischer, fehlerhafter Botschaften.
Gesamtblick
Agenten bieten schnelle, aber fehleranfällige Code‑Generierung und benötigen kontinuierliche menschliche Kontrolle, um brauchbar zu bleiben.
Related queries
Wie lässt sich das „bottom‑up“ Vorgehen bei LLM‑Agents automatisieren?
Welche Techniken können die Fähigkeit von Agenten verbessern, sich aus früheren Sessions zu lernen?
Wie verhindert man, dass Code‑Reviews bei LLM‑basierten Projekten vernachlässigt werden?