Agenten und ihre Grenzen: Warum LLM‑Agents noch nicht die ideale Lösung sind
Agenten 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?