Einführung: Der Agent, den jeder will, ohne den Hype
Das Problem mit Coding-Agenten ist, dass die meisten von ihnen versuchen, dein Chef, dein Co-Pilot und dein Therapeut zu sein – und dann vergessen sie einfach, den Code zu schreiben. Das Drehbuch sieht so aus: Füge ein Dutzend Vektordatenbanken hinzu, streue etwas Orchestrierungs-Feenstaub darüber, schnall einen Browser an und nenne es dann einen Tag. Es demonstriert gut. Es fällt auch auseinander, sobald du es bittest, einen fehlerhaften Integrationstest um 16:52 Uhr an einem Freitag zu beheben.
Das Erstellen eines schlanken Coding-Agenten mit Claude 4.5 ist – Überraschung – eigentlich unkompliziert, wenn man aufhört, dem Traum eines universellen Software-Butlers nachzujagen und einfach ein Tool baut, das Code liest, plant, bearbeitet, ausführt und wiederholt. Keine Predigt darüber, dass „KI Entwickler ersetzt“. Keine Rube Goldberg-Pipelines. Nur eine enge Schleife, die die offensichtlichen Dinge gut macht.
Dies ist eine How-to-Anleitung, um dorthin zu gelangen, ohne eine ganze KI-Operationsabteilung einzubeziehen. Wir werden Claude 4.5 für das Gehirn, ein Dateisystem und eine Shell für die Hände und einen kleinen Speicher für kurzfristige Fokussierung verwenden. Das ist es. Schlank bedeutet, dass du es in einer Sitzung verstehen, es lokal ausführen und ihm vertrauen kannst, weil jeder Schritt überprüfbar ist. Was, wenn du in letzter Zeit etwas in diesem Bereich verwendet hast, fast subversiv ist.
Warum Claude 4.5 für einen minimalen Agenten funktioniert
Claude 4.5 hat das Temperament, das du tatsächlich für Code willst: sorgfältig bei der Befolgung von Anweisungen, überraschend anständig beim Lesen von Diffs und nicht übermäßig eifrig, Frameworks zu halluzinieren, die du nicht angefordert hast. Das Modell ist kompetent im schrittweisen Denken, ohne einen ganzen Prompt-Roman zu fordern. Diese Kombination – Denken plus Zurückhaltung – macht es ideal für eine Coding-Agenten-Schleife:
- Beobachten: Aktuelle Dateien, Fehlerprotokolle und Tests lesen.
- Planen: Konkrete Änderungen mit Begründung vorschlagen.
- Handeln: Dateien patchen, Befehle ausführen.
- Reflektieren: Ausgabe bewerten, iterieren oder stoppen.
Du kannst dies an jedes Repo anheften und an einem Nachmittag einen Mehrwert erzielen. Der Trick besteht darin, dem Drang zu widerstehen, es in eine „KI-Plattform“ zu verwandeln. Wenn du den Agenten schlank hältst, erledigt Claude 4.5 die schwere Arbeit, ohne dir in den Weg zu geraten.
Die schlanke Architektur: Fünf Teile, kein Drama
Hier ist der gesamte Stack, den du benötigst:
- Kernschleife: Ein Prozess, der Claude 4.5 aufruft und seine Tool-Use-Nachrichten interpretiert.
- Tools: Ein winziges Set – read_file, write_file, list_dir, run_tests (oder run_cmd), search_code.
- Kontext-Builder: Einen kurzen, pointierten Prompt mit Repo-Metadaten und aktuellen Diffs zusammenstellen.
- Kurzzeitgedächtnis: Ein rollierendes Konversationsfenster plus ein expliziter Scratchpad für Plan und Einschränkungen.
- Leitplanken: Token-, Zeit- und Dateischreibbeschränkungen; ein Dry-Run-Modus; und Rollback-Snapshots.
Das ist es. Du kannst es Headless in einem Terminal ausführen oder es in eine minimale UI einwickeln, wenn du musst. Der Grund, warum dies funktioniert, ist langweilig: Jede Aktion wird beobachtet und ist überprüfbar. Der Agent schlägt eine Änderung vor, zeigt den Diff, führt die Tests aus, liest die Ausgabe und fährt entweder fort oder stoppt. Es gibt kein Mystery Meat in der Mitte.
So baust du den Agenten (ohne den Plot zu verlieren)
Schritt 1: Definiere den Vertrag – Prompt und Tools
Dein Agent ist so gut wie sein Vertrag mit dem Modell. Halte den System-Prompt kurz, strikt und unerbittlich praktisch.
System-Prompt, destilliert:
- Du bist ein Coding-Agent. Deine Aufgabe ist es, kleine, korrekte Änderungen am Repo vorzunehmen, um eine Benutzeraufgabe zu erfüllen.
- Denke laut in einem versteckten Scratchpad; zeige dem Benutzer nur Pläne und Diffs.
- Bevorzuge minimale Diffs, funktionierende Tests und inkrementellen Fortschritt.
- Wenn du dir unsicher bist, schlage ein Experiment vor und führe es aus.
- Erfinde niemals Dateien oder Befehle – liste und lese, bevor du bearbeitest.
Tool-Schema (zerdenke es nicht):
- read_file(path, offset?, length?)
- write_file(path, content, create_if_missing=false)
- run_cmd(command, timeout=60, cwd=repo_root)
- search_code(query, path=repo_root, max_results=50)
Optionale Annehmlichkeiten: git_diff und git_revert(sha), wenn du freihändige Rollbacks möchtest. Du kannst einen Vektor-Store überspringen; die meisten nützlichen Aufgaben hängen von einer Handvoll Dateien im Arbeitsspeicher plus einer schnellen Suche ab.
Schritt 2: Halte den Kontext schlank
Context Stuffing ist der Cargo-Kult des Agenten-Designs. Schütte nicht dein gesamtes Monorepo in den Prompt. Stattdessen:
- Repo-Zusammenfassung: Ein-Absatz-README-Digest; Einstiegspunkte; Test-Runner-Befehl.
- Aktive Dateien: Nur die Dateien, die der Agent berühren will – lese sie bei Bedarf in Stücken ein.
- Aufgabe: Das Benutzerziel, prägnant formuliert: „Behebe den fehlschlagenden Test FooTest.test_bar in tests/foo_test.py.“
- Einschränkungen: Laufzeitbeschränkungen, File-Write-Whitelist, Stilregeln und semantische Versionierungserwartungen, falls zutreffend.
- Aktuelle Historie: Die letzten zwei Diffs und ihre Testergebnisse. Nichts anderes.
Claude 4.5 ist vollkommen in der Lage, mehr Kontext abzurufen, wenn er ihn über search_code und read_file benötigt. Gib ihm die Karte, nicht das Gebiet.
Schritt 3: Die Schleife (Beobachten → Planen → Handeln → Reflektieren)
- Beobachten: Beginne mit dem Auflisten von Verzeichnissen, dem Lesen des fehlschlagenden Tests, des zu testenden Codes und des Fehlerprotokolls. Bitte Claude, Fehlersymptome in zwei oder drei Stichpunkten zusammenzufassen.
- Planen: Lass Claude einen Plan vorschlagen mit:
- Zu inspizierende oder zu bearbeitende Dateien
- Minimale Diffs, die versucht werden sollen
- Ein Testbefehl zur Validierung
- Handeln: Wende den vorgeschlagenen Diff über write_file an. Zeige den Diff wortgetreu. Führe die Tests aus.
- Reflektieren: Speise stdout/stderr wieder ein. Frage Claude: fortfahren, zurückrollen oder stoppen? Wenn sich der Plan ändert, fordere eine Ein-Satz-Begründung an, die sich auf die tatsächliche Ausgabe bezieht.
- Beenden: Stoppe, wenn Tests bestanden sind, oder nach N Iterationen, je nachdem, was zuerst eintritt.
Dies ist verherrlichtes Pair Programming, bei dem du das Pairing tatsächlich ehrlich hältst.
Schritt 4: Leitplanken, die dein Wochenende retten
- Write-Whitelist: Erlaube nur Writes innerhalb von src/, lib/ oder explizit genehmigten Pfaden.
- Diff-Größenbeschränkung: Begrenze Änderungen auf 200–500 Zeilen pro Schritt. Wenn größer, teile in Teilschritte auf.
- Befehls-Allowlist: Test-Runner, Linters und ein paar Dev-Skripte. Verbiete das Netzwerk. Du willst Reproduzierbarkeit, nicht Wild-West-curl.
- Timeout und Wiederholungen: Kurze Timeouts, maximal eine Wiederholung – endlose Re-Run-Schleifen sind der Ort, an dem Agenten sterben.
- Dry-Run-Modus: Geplante Diffs drucken, aber nicht schreiben. Ideal für Code-Reviews.
Claude 4.5 hält sich an Regeln, wenn du sie explizit machst. Wenn du das nicht tust, sei nicht überrascht, wenn es versucht, zu „helfen“, indem es dein gesamtes Repo so umorganisiert, dass es einem Blog-Post aus dem Jahr 2017 entspricht.
Schritt 5: Speicher, der tatsächlich nützlich ist
Kurzzeitgedächtnis löst 80 % des Problems. Behalte:
- Einen Scratchpad für die aktuelle Hypothese und den Plan.
- Eine Liste der in dieser Sitzung berührten Dateien.
- Die letzten zwei Befehlsausgaben.
Das reicht aus, damit Claude 4.5 kohärent argumentieren kann. Langzeitgedächtnis – Aufgabenprotokolle, Embeddings – kann für wiederkehrende Codebasen hilfreich sein, aber behandle es als optionalen Zucker. Wenn dein Agent einen Test nicht ohne einen 500-MB-Vektorindex beheben kann, ist er kein Agent – er ist eine Abhängigkeit.
Der minimale Implementierungsentwurf
In Pseudocode-Begriffen kannst du diesen Agenten in ein paar hundert Zeilen implementieren:
- initialisieren: Repo-Metadaten, Einschränkungen und Modell-Client laden
- beobachten: fehlschlagende Tests, Dateien, Protokolle lesen
- plan = model.propose_plan(context)
- while not done and steps < MAX:
- diff = model.propose_patch(plan)
- show(diff); maybe approve
- out = run_cmd(plan.test_cmd)
- reflect = model.evaluate(out)
- if reflect == pass: done = true
- else if reflect == rollback: git_revert(last_commit)
- else: plan = model.revise_plan(out)
Du wirst die fehlenden Teile bemerken: keine Agenten, die Agenten verwalten, keine „Delegierten“, kein separates „Planer-Modell“ und „Executor-Modell“. Claude 4.5 kann beide Jobs gut erledigen, wenn du es nicht mit einem Rube Goldberg-Apparat sabotierst.
Prompting, das sich nicht zu sehr anstrengt
Schlechte Prompts versuchen, clever zu sein. Gute Prompts sind langweilig und spezifisch. Hier ist ein vernünftiges Skelett für deinen Kern-Instruktionsblock:
- Ziel: Gib die genaue Coding-Aufgabe und die Erfolgskriterien an.
- Kontext: Projektstruktur, Einstiegspunkte und Testbefehl.
- Einschränkungen: Write-Whitelist, Diff-Größenbeschränkung, kein Netzwerk.
- Stilpräferenzen: Sprachversion, Formatter, Linter-Regeln.
- Prozess: Beobachten → Planen → Handeln → Reflektieren; zeige Diffs; führe Tests aus; iteriere bis zu N Schritten; stoppe, wenn Tests bestanden sind.
Claude 4.5 benötigt mit dieser Struktur kein 100-zeiliges Rollenspiel-Szenario. Es funktioniert einfach.
Praktisches Beispiel: Behebe einen fehlschlagenden Test
Angenommen, ein Test schlägt in tests/time_test.py fehl, weil parse_time("09:00") 5400 anstelle von 32400 zurückgibt. Die Schleife des Agenten sollte wie folgt aussehen:
- Beobachten: Lese time.py und time_test.py; führe pytest -k parse_time aus.
- Planen: Hypothese – Sekunden- vs. Minuten-Mathefehler; schlage vor, parse_time zu bearbeiten; füge Unit Edge Case hinzu.
- Handeln: Patche parse_time, füge einen Test für Stunden mit führender Null hinzu; führe Tests aus.
- Reflektieren: Wenn Tests immer noch fehlschlagen, lese Fehler, passe Mathe oder Regex an, führe erneut aus.
Der minimale erfolgreiche Patch könnte eine Zwei-Zeilen-Änderung sein. Das ist der Punkt. Kleine Änderungen, schnelle Zyklen, echter Fortschritt.
Wo Lightweight den Kitchen Sink schlägt
- Latenz: Ein Modell, eine Schleife, kein Orchestrierungs-Overhead.
- Transparenz: Jeder Schritt ist auditierbar. Du kannst ihn diffen, du kannst ihn rückgängig machen, du kannst ihn erneut ausführen.
- Kontrolle: Leitplanken halten den Schaden lokal. Der Agent kann nicht in deine Infrastruktur abwandern.
- Kosten: Weniger Aufrufe, weniger Kontext, vorhersehbare Token.
- UX: Du verstehst es. Deine Teamkollegen verstehen es. Dein zukünftiges Selbst wird dich nicht hassen.
Und die Kompromisse:
- Breite: Ein schlanker Coding-Agent wird dein Fünf-Sprachen-Monorepo nicht in einem einzigen Durchgang refaktorieren. Sollte er auch nicht.
- Initiative: Er wird keine mehrwöchigen Roadmaps erfinden. Du gibst ihm Aufgaben.
- Zustandsbehaftung: Ohne eine große Speicherschicht vergisst er entfernte Geschichte durch Design. Das ist ein Feature, bis es ein Bug ist.
Claude 4.5’s Sweet Spot für Coding-Agenten
Claude 4.5 glänzt bei:
- Lesen und Argumentieren über Diffs und Protokolle.
- Erstellen von kohärenten, minimalen Codeänderungen.
- Befolgen von Einschränkungen und Explizitsein über Unsicherheit.
Es ist weniger gut bei:
- Erraten von API-Verhalten, das es nicht lesen kann.
- Schwerer Tool-Choreografie (hier nicht benötigt).
- Langen Refaktorierungen mit mehreren Dateien ohne menschliche Führung der Schritte.
Dieser letzte Punkt ist wichtig. Der beste Weg, um starke Ergebnisse zu erzielen, besteht nicht darin, den Agenten größer zu machen – es besteht darin, die Aufgabe kleiner zu machen. Verwende dein Gehirn für die Abgrenzung und Claude 4.5 für die Ausführung innerhalb dieses Rahmens.
Ein Wort zur IDE-Integration
Widerstehe dem Drang, dies direkt in einen IDE-Bereich mit fünfzig Umschaltern einzubauen. Eine terminalbasierte Schleife mit Klartext-Diffs ist leichter zu vertrauen und zu debuggen. Wenn du Editor-Zucker willst, halte ihn dumm:
- Befehle zum Starten/Stoppen der Schleife.
- Zeige Diffs in einer geteilten Ansicht.
- Genehmigungs-Prompt für Writes (optional, aber ratsam).
Du kannst später integrieren. Mache es zuerst funktionstüchtig.
Sider.AI, sparsam eingesetzt, hilft tatsächlich Wenn du eine pragmatische Umgebung zum Ausführen dieser Art von Schleife möchtest, ohne das Gerüst neu zu erfinden, funktioniert Sider.AISider tatsächlich – zumindest, wenn du es für das verwendest, wofür es gut ist. Es hält die Konversation und die Diffs aufgeräumt, lässt dich Befehle ausführen und zwingt dir kein grandioses „autonomes Agenten-Framework“ auf. Der Trick besteht darin, deine eigenen Regeln einzuhalten: kurze Prompts, enge Schleifen, sichtbare Diffs. Sider.AISider kommt nicht in den Weg, was seltener ist, als es sein sollte. Häufige Fallstricke (und wie man vermeidet, dumm auszusehen)
- Überfrachteter Kontext: Wenn sich dein Prompt wie eine Lösegeldforderung liest, machst du es falsch. Rufe Dateien bei Bedarf ab.
- Vorzeitige Refaktorierung: Der Agent schlägt vor, Module neu zu organisieren? Lass ihn zuerst Tests bestehen. Später refaktorieren.
- Halluzinierte Dateien: Benötige list_dir und read_file vor jedem write_file zu einem neuen Pfad.
- Endlose Re-Run-Schleifen: Begrenze Schritte. Fordere eine Begründung für jede neue Hypothese an.
- Ein riesiger Diff: Teile Änderungen auf. Kleinere Diffs schlagen schneller fehl und sind leichter zu argumentieren.
Sicherheit und Schutz ohne Paranoia
- Lokale Ausführung: In einem Sandkasten-Verzeichnis ausführen. Standardmäßig kein Netzwerk.
- Abhängigkeitsisolation: Verwende ein lokales venv oder einen Container. Fixiere Versionen.
- Geheimnisse: Der Agent benötigt sie nicht. Wenn ein Befehl ein Token verlangt, stoppe und frage.
- Auditing: Speichere jeden Plan, Diff und Befehl in einem Protokoll.
Woher weißt du, dass es funktioniert?
- Die Vorlaufzeit schrumpft: Bugfixes, die eine Stunde gedauert haben, dauern jetzt zehn Minuten.
- Weniger Fat-Finger-Fehler: Diffs werden kleiner, Tests werden grüner.
- Du vertraust ihm: Du hörst auf, über jede Aktion zu schweben, weil sie dich nicht verbrannt hat.
- Teamkollegen verwenden es: Die Definition von Erfolg ist, dass andere es ohne ein Meeting übernehmen.
Skalieren, vorsichtig
Wenn du wirklich skalieren musst, tue es mit Disziplin:
- Parallele Subtasks, nicht parallele Gehirne: Teile die Arbeit auf, führe mehrere schlanke Schleifen in separaten Verzeichnissen aus und führe sie zusammen, wenn sie grün sind.
- Episodisches Gedächtnis, kein Brain Dump: Speichere erfolgreiche Patches und Symptome-zu-Fix-Mappings. Chirurgisch abrufen.
- Regelmäßige „größere“ Durchgänge: Reserviere eine menschlich geführte Sitzung für Refaktorierungen; der Agent unterstützt, führt nicht.
Eine minimale Referenzimplementierung (Skizze)
Python-ähnlicher Pseudocode, um in Bewegung zu kommen:
- def init(self, repo_root, model):
- self.history = [] # letzte zwei Diffs und Testausgaben
- "repo": summarize_repo(self.root),
- "constraints": {"write_whitelist": ["src/", "tests/"], "max_diff_lines": 300, "no_network": True},
- "history": self.history[-2:],
- plan = self.model("propose_plan", self.context(task))
- diff = self.model("propose_patch", {"plan": plan})
- out = run_cmd(plan.test_cmd)
- eval = self.model("evaluate", {"output": out, "plan": plan})
- self.history.append({"diff": diff, "out": tail(out)})
Ein menschengerechtes Ende
Die Industrie verspricht immer wieder autonome Entwickleragenten. Was wir tatsächlich brauchen, ist ein ehrlicher Assistent, der liest, plant, bearbeitet, ausführt und stoppt. Claude 4.5 ist gut darin, vorausgesetzt, du begräbst ihn nicht unter Frameworks, die hauptsächlich dazu dienen, sich selbst zu rechtfertigen. Lightweight ist kein Kompromiss – es ist der Punkt. Baue die Schleife, füge die Leitplanken hinzu und lass das Tool das eine tun, was Tools schon immer getan haben, wenn du sie einfach hältst: die Arbeit kleiner machen.
Fazit: Die langweilige Abkürzung, die gewinnt
Hier ist deine Checkliste für einen schlanken Coding-Agenten mit Claude 4.5:
- Eine Schleife, ein Modell, kleine Tools.
- Enge Kontext: Aufgabe, ein paar Dateien, letzte Ausgaben.
- Minimale Diffs, häufige Tests, harte Caps.
- Lokale, Sandkasten-Ausführung; kein Netzwerk.
- Optionaler Editor-Zucker; niemals erforderlich.
Wenn du schielst, sieht es verdächtig nach gutem Software Engineering aus, nur schneller. Und das ist die Pointe. Das Klügste, was du hier tun kannst, ist nicht, der „Autonomie“ nachzujagen – es ist, Disziplin zu kodifizieren. Je weniger du vom Agenten verlangst, desto mehr bekommst du.
FAQ
F1: Wie beginne ich mit dem Bau eines schlanken Coding-Agenten mit Claude 4.5?
Definiere ein winziges Toolset (lesen, schreiben, suchen, ausführen), schreibe einen strengen System-Prompt und implementiere eine Beobachten → Planen → Handeln → Reflektieren-Schleife. Halte den Kontext klein und speise echte Protokolle und Diffs ein – Claude 4.5 funktioniert am besten, wenn die Aufgabe eng und das Feedback konkret ist.
F2: Benötige ich eine Vektor-Datenbank oder Speicherschicht für einen Claude 4.5 Coding-Agenten?
Nein. Für die meisten Aufgaben reichen Kurzzeitgedächtnis plus search_code aus. Füge Langzeitgedächtnis nur hinzu, wenn du dieselbe Codebasis wiederholt besuchst und beweisen kannst, dass es Token spart, ohne den Agenten dümmer zu machen.
F3: Welche Leitplanken sind für einen Claude 4.5 Coding-Agenten unerlässlich?
Whiteliste beschreibbare Pfade, begrenze Diff-Größen, beschränke Befehle und protokolliere jede Aktion. Diese einfachen Grenzen halten den Agenten vorhersehbar und machen Rollbacks langweilig – im positiven Sinne.
F4: Kann ein schlanker Agent Refaktorierungen mit mehreren Dateien handhaben?
Ja, wenn du die Arbeit in kleine Schritte aufteilst und die Schleife eng hältst. Claude 4.5 kann Refaktorierungen verwalten, aber du führst den Umfang; andernfalls erhältst du einen riesigen, spröden Diff, den du nicht überprüfen möchtest.
F5: Wo passt Sider.AI zu einem Claude 4.5 Coding-Agenten?
Sider.AI ist nützlich als aufgeräumter Arbeitsbereich: Konversationen, Diffs und Befehle an einem Ort, ohne ein schwergewichtiges Agenten-Framework zu erzwingen. Verwende es, um deine Schleife auszuführen, nicht um sie neu zu erfinden. 
