Die irrational effiziente Wirkung von LLM-Agenten-Schleifen und Tool-Nutzung

• Anhand der Entwicklungserfahrung mit dem KI-Programmierassistenten Sketch wird die einfache Implementierung einer Schleifenstruktur, die LLMs mit Tool-Nutzung kombiniert, hervorgehoben
• Mit nur 9 Zeilen Schleifencode lösen moderne LLMs wie Claude 3.7 Sonnet reale Probleme schnell und praktisch nutzbar
• Schon mit nur einem universellen Tool wie bash lässt sich ein großer Teil repetitiver und kniffliger Aufgaben von Entwicklerinnen und Entwicklern automatisieren
• Über die reine Problemlösung hinaus kann durch die Anbindung zusätzlicher Tools die Qualität und Wiederholungsgeschwindigkeit bei Textbearbeitung oder spezialisierten Aufgaben erhöht werden
• Es zeichnet sich ein Trend ab, dass immer mehr maßgeschneiderte LLM-Agenten-Schleifen in die tägliche Automatisierung von Entwicklerinnen und Entwicklern Einzug halten

---

Einleitung: Entwicklungserfahrung und das Sketch-Projekt

• Philip Zeligger und seine Kolleginnen und Kollegen waren bei der Entwicklung des KI-basierten Programmierhilfswerkzeugs Sketch überrascht, wie effizient eine einfache Agenten-Schleifenstruktur, die LLMs mit Tool-Nutzung verbindet, sein kann
• Die Kernstruktur besteht aus nur 9 Zeilen Schleifencode, die den System-Prompt, den Gesprächsverlauf und die neueste Nachricht an die LLM-API übergeben
• Das LLM erzeugt eine Ausgabe und gibt bei Bedarf tool_calls (Anfragen zum Aufruf von Tools) zurück

Integration von LLMs und Tool-Nutzung

• „Tool-Nutzung (tool use)“ bedeutet, dass ein LLM eine Ausgabe entsprechend einem vordefinierten Schema zurückgibt und über den System-Prompt sowie Tool-Beschreibungsprompts Zugriff auf universelle Tools wie bash erhält
• Moderne LLMs (z. B. Claude 3.7 Sonnet) automatisieren mit nur einem einzigen universellen Tool unterschiedlichste Probleme schnell; manche lassen sich sogar in einem einzigen Durchlauf („one shot“) lösen
• Früher musste man komplexe git-Befehle heraussuchen, einfügen und Merge-Arbeiten manuell erledigen, heute kann man Sketch einfach darum bitten und das Problem direkt lösen
• Auch zahlreiche Type-Check-Fehler nach Typänderungen wurden von Sketch erstmals automatisch behoben
• Die Agenten-Schleife arbeitet kontinuierlich und adaptiv: Fehlen Tools, werden sie automatisch installiert, und auch auf Unterschiede bei Kommandooptionen wird passend reagiert
• Während der Nutzung macht das LLM mitunter unerwartete Vorschläge wie „Tests überspringen“, wenn Tests fehlschlagen, insgesamt verbessert sich jedoch die Qualität der Arbeitsautomatisierung

Vielfalt und Spezialisierung von Tools

• Sketch hat die Erfahrung gemacht, dass zusätzliche Tools neben bash (z. B. Textbearbeitungstools) die Qualität der Arbeit erhöhen und den Entwicklungs-Workflow noch effizienter machen
• Für ein LLM ist es schwieriger als erwartet, Text mit sed und ähnlichen Werkzeugen präzise zu bearbeiten; Tools im Stil visueller Editoren sind dabei spürbar überlegen

Zukunftsausblick und Veränderungen im Workflow

• Es ist zu erwarten, dass Agenten-Schleifenstrukturen zunehmend für repetitive Aufgaben im Entwickleralltag eingesetzt werden, die mit bestehenden universellen Automatisierungstools nur schwer zu bewältigen waren
• Ein Beispiel sind lästige und wiederkehrende Aufgaben wie die Analyse von Korrelationen zwischen Stack Traces und Git-Commits, bei denen LLMs schnell eine erste Bearbeitung übernehmen können
• Künftig dürften noch mehr maßgeschneiderte, einmalige LLM-Agenten-Schleifen etwa im bin/-Verzeichnis von Entwicklerinnen und Entwicklern genutzt werden
• Nutzerinnen und Nutzer können mit einem gewünschten Bearer Token in ihrer eigenen Umgebung leicht damit experimentieren

Weiterführende Links

• Der Inhalt ist auch im philz.dev-Blog veröffentlicht
• Weitere Informationen zum Projekt finden sich unter sketch.dev, merde.ai, pi.dev

[GN⁺]

Hacker-News-Kommentare

• Ich möchte auch diesen Blogpost nachdrücklich empfehlen. Er behandelt denselben Punkt viel ausführlicher und überzeugender. Der Autor baut tatsächlich selbst von Grund auf einen Coding-Agenten. Siehe https://ampcode.com/how-to-build-an-agent. Es ist wirklich erstaunlich zu erleben, wie gut ein LLM in einer Schleife, in der es Tools aufrufen kann, eine so große Bandbreite an Aufgaben bewältigt. Natürlich ist es nicht perfekt, und es gibt Probleme wie die Tatsache, dass keine 100%ige Zuverlässigkeit erreicht wird. Trotzdem finde ich, dass daran zumindest etwas wirklich Staunenswertes ist. Wenn man so etwas selbst ausprobiert, kann man es in 30 Minuten nachbauen. Es ist etwas, bei dem man Ehrfurcht empfinden kann, ohne eine gesunde Skepsis darüber zu verlieren, ob AI für einen bestimmten Zweck wirklich effektiv ist. Diese „unnatürliche Effektivität“ davon, ein LLM in eine Schleife zu setzen, ist der Grund, warum gerade so viele Code-Generierungs-Agenten erscheinen: Claude Code, Windsurf, Cursor, Cline, Copilot, Aider, Codex und so weiter, plus sehr viele Nachbauprojekte. Deshalb gibt es auch kein besonderes Geheimrezept; 95% der Magie sind letztlich einfach das LLM selbst und die Feinabstimmung darauf, Tool-Aufrufe auszuführen. Das hat ein Hauptentwickler von Claude Code kürzlich in einem Interview auch offen eingeräumt. Natürlich steckt viel Arbeit darin, solche Tools gut funktionieren zu lassen, aber grundlegend ist es fast immer derselbe einfache Kernaufbau
  • So einen Beitrag habe ich sehr lange gesucht, daher bin ich wirklich dankbar. Viele sehen Agents und reagieren mit „Wahrscheinlich können die wirklich komplexe Probleme nicht gut lösen, oder?“ Aber aus meiner Sicht liegt der Kernpunkt bei Agenten gar nicht dort. LLMs funktionieren mit viel Kontext sehr gut, und Agenten sind eine Struktur, mit der ein LLM mehr Kontext beschaffen kann, um die Qualität seiner Antworten zu verbessern
  • Mir fallen ehrlich gesagt nicht viele Aufgaben ein, die ein LLM allein in einer Schleife über mehrere Durchläufe hinweg ohne Anweisungen gut erledigen kann. Nach ein paar Iterationen kommt fast immer ein Punkt, an dem ich eingreifen muss
  • Es gibt ein Tutorial, das etwas Ähnliches mit der Graph-Abstraktionsbibliothek pocketflow gebaut hat. Ich habe es tatsächlich ausprobiert und war sehr zufrieden, weil es ziemlich simpel ist. https://github.com/The-Pocket/PocketFlow-Tutorial-Cursor/blob/main/blog.md
  • Mir ist erst jetzt aufgefallen, dass der Autor Thorsten Ball ist. Ich erinnere mich, sein „Interpreter bauen“ mit viel Freude gelesen zu haben. Wahrscheinlich werde ich jetzt auch mal einen Agenten bauen
  • Bevor ich den Link oben öffne, überlege ich, ob ich ?utm_source=hn&utm_medium=browser anhängen sollte
• Heute habe ich zum ersten Mal selbst „Vibe-Coding“ mit GPT-4o und 4.1 ausprobiert. Es lief so, dass ich Compilerfehler, Warnungen und Vorschläge manuell über die Canvas-Oberfläche in einer Schleife eingegeben habe. Die Datei war klein, etwa 150 Zeilen. Ich begann mit 4o, das veraltete Pakete benutzte. Selbst als ich darauf hinwies, aktualisierte es nicht alle Verwendungsstellen, sodass ich selbst nacharbeiten musste. Als ich eine Logikänderung vorschlug, ging die Syntax vollständig kaputt, und es hat sich davon nie wieder erholt. Auch wenn ich immer wieder Compilerfehler eingab, verstand es die Syntaxprobleme nicht und änderte stattdessen irgendwelche zufälligen Teile des Codes. Also hoffte ich, dass 4.1 besser wäre, aber 4.1 weigerte sich, Canvas überhaupt zu benutzen, und erklärte stattdessen nur, was ich selbst ändern solle. Nachdem ich lange darauf eingeredet hatte, bekam ich schließlich Code in Canvas, aber diesmal war mitten drin etwas mit // omitted for brevity abgeschnitten, also unbrauchbar. Da habe ich aufgegeben. Ich frage mich, ob Agenten dieses Problem lösen. Im Moment habe ich den Eindruck, dass diese Erfahrung komplett kaputt ist, und in so einem Zustand Bash-Zugriff zu geben erscheint mir viel zu riskant
  • Dass „veraltete Pakete verwendet wurden“, liegt daran, dass die Trainingsdaten des Modells einen Stichtag haben. Darauf muss man bei LLMs unbedingt achten. In ChatGPT wechsle ich häufig zu o4-mini-high. Dieses Modell kann mit der Suchfunktion auch aktuelle Dokumentation finden. Wenn man etwa sagt: „Bitte prüfe die neueste Version der Bibliothek X und verwende sie“, klappt das oft gut. Kürzlich hatte ich eine Aufgabe, bei der ein Teil von JavaScript-Code auf die neuesten von Google empfohlenen Bibliotheken umgestellt werden musste. Ich habe einfach den alten Code eingefügt und gebeten, ihn auf die neue Bibliothek zu portieren, und es hat die Dokumentation nachgeschlagen und korrekt portiert. https://simonwillison.net/2025/Apr/21/ai-assisted-search/#lazily-porting-code-to-a-new-library-version-via-search
  • GPT 4.1 und 4o erzielen im Aider-Coding-Benchmark sehr niedrige Werte. Aus praktischer Erfahrung müssen es eher über 70% sein, damit die Ergebnisse wirklich brauchbar sind. Und bei komplexeren Dingen braucht man trotzdem ziemlich viel Unterstützung. Mit der Zeit bekommt man ein Gefühl dafür, was gut funktioniert und was nicht. https://aider.chat/docs/leaderboards/
  • Es klingt vielleicht unangenehm, von einem „Skill-Problem“ zu sprechen, aber LLMs zu nutzen ist eindeutig ein Bereich, der eigene Fertigkeiten erfordert. Man muss die Stärken und Schwächen verschiedener Tools verstehen, unterschiedliche Techniken ausprobieren und üben. Wenn ich Bash-Zugriff geben würde, dann nur in einer Container-Umgebung (Docker)
  • Das würde ich nicht Vibe Coding nennen. Dafür braucht man ein Tool, das Code-Änderungen automatisch anwendet. Wenn man alles manuell einzeln zurückspielt, bleibt man an Fehlern hängen und kommt nicht weiter. Der Kern von Vibe Coding ist, dass man einfach zurückrollen, neu ausführen sowie verschiedene Lösungsansätze leicht ausprobieren und verwerfen kann. Dafür braucht man Tooling
  • Vor kurzem habe ich mit dem Cline-Plugin und Claude in VSCode einen Android-App-Prototyp „von Null“ erstellt. Ich habe mit dem Standard-Template aus Android Studio begonnen, und es wurden mehrere tausend Zeilen Code erzeugt, ohne einen einzigen Compilerfehler. Die App funktionierte wie erwartet, und die wenigen gefundenen Bugs lagen nicht am LLM, sondern an seltsamen Verhaltensweisen der Android-API. Ich habe das LLM auf die Bugs hingewiesen und Debug-Ausgaben geliefert, und es hat sie selbst behoben. Anfangs waren die Korrekturen etwas holprig, aber nach ein paar Feedback-Runden war die Lösung gut. Wenn man einen Code-Schreib-Agenten und einen Code-Review-Agenten in eine Schleife setzt, könnte so etwas wohl noch allgemeiner gut funktionieren
• Ich nutze Claude Code, also die Terminal-Oberfläche von Sonnet 3.7, seit dem ersten Veröffentlichungstag. Ich habe damit recht große CLI-Apps, Full-Stack-Websysteme und unzählige Utilities geschrieben. Ähnlich wie früher, als ich Programmierteams geleitet habe, wage ich mich dadurch an noch ambitioniertere Projekte. Strukturell unterscheidet es sich vermutlich nicht stark von anderen Tools, aber es wirkt so, als habe Anthropic eine Menge enorm nützlicher Funktionen hinzugefügt. Perfekt ist nichts, und für gute Codequalität braucht es immer noch ungefähr denselben Aufwand wie früher. Selbst ziemlich komplexe Dinge funktionieren, aber oft wird das Hinzufügen des nächsten Features dann schwieriger. Je vertrauter ich im Umgang damit werde, desto weniger Refactoring und Nacharbeit ist nötig. Ganz verschwinden wird das wohl nie. Die Probleme, die kgeist erlebt hat, kann ich mir ehrlich gesagt kaum vorstellen. Claude verhält sich zwar manchmal anders, als ich es wählen würde, oder schlicht dumm, aber nie so, dass ich aufgeben wollte. Fast immer liefert es brauchbare Resultate, und das Maß, in dem es mir Denkaufwand abnimmt, ist enorm. Außerdem refaktoriert es wirklich hervorragend. Wenn ich den Code regelmäßig durchsehe und Claude erkläre, wie es besser ginge, reduziert sich die Komplexität drastisch. Dinge wie „Ändere die Datenstruktur“ löst es sofort. Das ist eine großartige Fähigkeit. Und zum Spaß habe ich auch mal ein 30 Jahre altes Archivverzeichnis voller Nicht-Code-Kram geöffnet. Fragen wie „Was ist in diesem Verzeichnis?“, „Lies meinen alten Lebenslauf und schreibe ihn neu“ oder „Wie heißen meine Kinder?“ waren wirklich verblüffend. Obwohl alles noch früh ist, bin ich wirklich glücklich damit
  • Kürzlich hatte ich eine Situation, in der ich gleichzeitig eine entfernte Datenstrukturdefinition, eine API-Spezifikation, Parsing und Speicherung sowie die Darstellung für den Nutzer bearbeiten musste. Claude hat all das parallel gut im Blick behalten, sodass ich sofort sehen konnte, wie kleine Änderungen an beiden Enden die mittlere Schicht beeinflussen. Ich konnte schnell mehrere Ideen durchiterieren und die beste Lösung finden. Es war erstaunlich, diese hochkomplexen mehreren Ebenen mit so schneller Iterationsgeschwindigkeit erkunden zu können, und das hat nicht nur die Produktivität erhöht, sondern auch mein strukturelles Verständnis des Gesamtsystems verbessert
  • Das oben erwähnte Refactoring ist wirklich eine erfreuliche Arbeit. Features, die früher kaum in einen Sprint gepasst hätten, sind in 5 Minuten erledigt. Es fühlt sich an, als stünde ein eingespieltes Team jederzeit bereit und warte nur auf meine Anforderungen. Wenn mir das Ergebnis nicht gefällt, lehne ich es einfach ab, und all die unnötigen Reviews und Terminabstimmungen scheinen verschwunden zu sein
• Es ist unglaublich frustrierend, wenn ein LLM oft sagt: „Ah, dieser Test klappt nicht … dann überspringen wir ihn einfach.“ Dazu ein Gedanke: Man könnte parallel zum Haupt-LLM ein unabhängiges, parallel laufendes Policy-Enforcement-LLM betreiben, das dafür sorgt, dass die Anweisungen eingehalten werden. Zum Beispiel könnte das Hilfs-LLM die Ausgabewahrscheinlichkeit so manipulieren, dass nach „let's just“ nicht das Wort „skip“ erscheinen kann. Wenn man also „skip“ verbietet, könnte das LLM auf einen anderen Pfad gelenkt werden, weg von unerwünschtem Verhalten. Das würde ähnlich wie ein JSON-Modus oder strukturierte Ausgabe funktionieren, aber dynamisch und in Echtzeit durch ein Hilfs-LLM gesteuert. Wenn das gut funktioniert, könnte man es weiter ausbauen und verschiedene Policy-Verstöße wie das Löschen von Testcode, um Tests zu bestehen, oder das Ausgeben nutzloser Kommentare alle in den Prompt des Hilfs-LLM aufnehmen, das dann in Echtzeit überwacht und eingreift. Mich würde interessieren, was das Outlines-Team von so einer Architektur hält
  • Wenn ein LLM die Ausgabe eines anderen LLM prüfen kann, dann könnte man in einem „mixture of experts“-LLM vielleicht einen spezialisierten Algorithmus für Überwachung und Auditierung zuweisen. Oder man trennt einen eigenen Denk-Thread ab, der die eigene Ausgabe überprüft, und fügt bei Bedarf noch einen weiteren Thread hinzu, der wiederum diesen Prüfer kontrolliert, um das System robuster zu machen
  • In diesem Zusammenhang könnte man sich auch eine Struktur vorstellen, in der ein überwachendes LLM das Modell bis zu einem bestimmten Punkt „zurückspult“, wenn das Haupt-LLM in eine falsche Richtung geht. Wenn etwa „let's just skip the test“ erkannt wird, rollt man hinter „just “ zurück und hält dann weiter einen Bias aufrecht, damit bestimmte Wörter nicht verwendet werden. Für so etwas wäre man allerdings bei der Wahl des Modellanbieters eingeschränkt, und gerade OpenAI scheint in letzter Zeit solchen Power-User-Funktionen eher feindlich gegenüberzustehen
• Heute Morgen habe ich mit cursor im Hauptloop eines Spielprototyps einen komplexeren Teil herausgelöst und dafür automatisch einen Satz von Testcode erzeugen lassen. Insgesamt decken 341 Tests die gesamte Core-Math und alle zentralen Komponenten ab. Manchmal fühlt es sich ein bisschen wie Katzenhüten an, aber je mehr Einschränkungen man vorgibt – etwa welche Funktionen konkret zu verwenden sind, an welcher Stelle, mit welchen Template-Dateien und was zu vermeiden ist –, desto besser werden die Ergebnisse. Insgesamt sind so 3500 Zeilen Testcode entstanden, die ich nicht selbst schreiben musste und die ich bei Problemen jederzeit löschen und neu generieren kann. Auch beim Tuning der Schwierigkeitskurve, bei Missionsvariationen und vielen anderen Dingen bekomme ich wirklich Hilfe
  • Nach meiner Erfahrung ist die automatische Generierung von Tests einer der besten Anwendungsfälle für LLMs. Sie beseitigt in einem Schritt stunden- oder tagelange langweilige, repetitive Arbeit. Viele Edge Cases, auf die ich selbst gar nicht kommen würde, werden automatisch abgedeckt, und die Sicherheit des Codes steigt ebenfalls. Das ist in vielerlei Hinsicht eine großartige Funktion
• Ich bin im Moment sehr begeistert von den Tool-Use-Fähigkeiten heutiger LLMs. Eigentlich ist dieser Trick nicht neu; ich bin ihm vor zwei Jahren erstmals im ReAcT-Paper begegnet. Danach wurde er in ChatGPT-Plugins, MCP usw. verwendet, und inzwischen werden die meisten Modelle mit Blick auf Tool Calls/Funktionsaufrufe trainiert. Spannend ist aktuell, wie stark sich die Leistung verbessert hat. Die hervorragende Suchleistung von o3/o4-mini basiert ebenfalls auf dieser Fähigkeit zu Tool Calls. Auch Qwen3 4B (Ollama 2.6GB, läuft auch auf dem Mac gut) beherrscht das gut. Gestern habe ich auf der PyCon US einen Workshop zum Bau LLM-basierter Software gegeben, und in diesem Zuge habe ich meinem LLM-Command-Line-Tool Tool-Use-Funktionen hinzugefügt. Siehe https://building-with-llms-pycon-2025.readthedocs.io/en/latest/tools.html. Jetzt kann ich mit meinem LLM-Paket Dinge wie „Zähle, wie oft das R in strawberry vorkommt“ zuverlässig als Shell-One-Liner erledigen
  • Ich liebe diese seltsame Kombination aus Heiterkeit und Stärke, die diese Funktion mit sich bringt
  • Wurde der Workshop aufgezeichnet?
• Ich frage mich, welcher Agent die meisten Tokens verbraucht. Cline steht weit oben auf der Liste, und Roo scheint weniger zu verbrauchen als Cline. Ich würde gern wissen, ob es Agents gibt, bei denen man die Interaktionsweise direkt einstellen kann, und wie Claude Code im Vergleich zu anderen Agents abschneidet
• Der beängstigende Punkt ist, dass „wenn das nötige Tool fehlt, es installiert wird“. LLMs sind zu gehorsam und folgen sofort, sobald jemand ihnen etwas aufträgt. Das ist ein Sicherheitsproblem, das noch ernster ist als SQL Injection
  • Ich frage mich manchmal, wann die erste agentenbasierte Katastrophe passieren wird. (Vor allem bei dieser hektischen AI-Marktstimmung.) Ich befürchte, dass mit der Zeit zwangsläufig eine irreversible Katastrophe eintreten wird
• Der Titel scheint von Eugene Wigners Aufsatz „The Unreasonable Effectiveness of Mathematics in the Natural Sciences“ inspiriert zu sein
  • Das mag der Ursprung sein, aber ich würde sagen, dass es längst eine seit langem etablierte Meme-Redewendung ist. https://scholar.google.com/scholar?q=unreasonable+effectiveness
  • Ich dachte eher, der Titel sei Karpathys „Unreasonable Effectiveness of RNNs“ von 2015 entlehnt. Natürlich kann man vermuten, dass Karpathy seinerseits wieder auf Wigner zurückgegriffen hat. https://karpathy.github.io/2015/05/21/rnn-effectiveness/
  • Immer wenn ich die Überschrift „unreasonable effectiveness“ sehe, ist es bei mir fast schon so, dass ich der Schlussfolgerung des Autors instinktiv nicht zustimme. Einschließlich bei Wigners Aufsatz. Es fühlt sich inzwischen fast wie Betteridges Gesetz an
• Wir haben Tools gebaut, um unserem eingebetteten ai-Chatbot im Produkt mehr Kontext zu geben. Dazu gehören aktuelle Aktivitätslogs, Definitionen des aktuellen Objekts, Suche sowie das Durchsuchen von Hilfeartikeln. Auch nach mehreren Monaten ist die Qualität des Chatbots immer noch erstaunlich. Wenn der Chatbot einmal etwas falsch beantwortet, aktualisieren wir die entsprechenden Hilfeartikel gezielter