Agenten in 2025: Waterfall-Modell, schnelle Code‑Generierung und die Notwendigkeit von Code‑Reviews
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.