Wie man Claude Code mit 200 Zeilen Code implementiert

 (mihaileric.com)
7 Punkte von GN⁺ 2026-01-09 | 1 Kommentare | Auf WhatsApp teilen
  • Die Kernstruktur eines KI-Coding-Assistenten besteht nicht aus komplexer Magie, sondern aus etwa 200 Zeilen einfachem Python-Code
  • Das System basiert auf einer Gesprächsschleife mit dem LLM: Fordert das LLM einen Tool-Aufruf an, führt lokaler Code diesen aus und übergibt das Ergebnis zurück
  • Die grundlegenden benötigten Tools sind drei: Datei lesen (read), Dateien auflisten (list) und Datei bearbeiten (edit); damit sind Projekterkundung und Codeänderungen möglich
  • Das LLM entscheidet auf Basis der Signaturen und Beschreibungen (Docstrings) der Tools selbst, welches Tool wann aufgerufen werden soll
  • Diese Struktur entspricht dem Kern kommerzieller Produkte wie Claude Code, und selbst mit einer einfachen Struktur lässt sich ein leistungsfähiger Coding-Agent implementieren

Grundkonzept eines Coding-Agenten

  • Ein Coding-Agent ist ein gesprächsbasiertes System mit einem LLM, das Benutzeranweisungen entgegennimmt und über Tool-Aufrufe echte Dateioperationen ausführt
    • Der Benutzer gibt etwa eine Anfrage wie „Erstelle eine neue Datei mit einer hello world-Funktion“ ein
    • Das LLM antwortet mit den erforderlichen Tool-Aufrufen im JSON-Format
    • Das Programm führt das jeweilige Tool aus und gibt das Ergebnis wieder an das LLM zurück
  • Das LLM greift nicht direkt auf das Dateisystem zu, sondern stellt nur Anfragen; die eigentliche Arbeit übernimmt lokaler Code

Die drei benötigten Tools

  • read_file: Liest den vollständigen Inhalt der angegebenen Datei und gibt ihn zurück
  • list_files: Gibt die Liste der Dateien und Ordner in einem Verzeichnis zurück
  • edit_file: Ersetzt einen vorhandenen String durch einen neuen oder erstellt eine neue Datei, wenn old_str leer ist
    • Falls der zu ersetzende String nicht vorhanden ist, wird „old_str not found“ zurückgegeben
    Anzeige
  • Schon mit diesen drei Tools sind Dateierstellung, Bearbeitung und Erkundung möglich

Tool-Registrierung und LLM-Integration

  • Alle Tools werden mit Namen und Funktion im TOOL_REGISTRY registriert, sodass das LLM sie aufrufen kann
  • Die Docstrings und Signaturen jedes Tools werden extrahiert und an das LLM übergeben
  • Der System-Prompt teilt dem LLM die „Liste der verfügbaren Tools“ und das „Aufrufformat“ klar mit
    • Tool-Aufrufe sind auf das Format 'tool: TOOL_NAME({JSON_ARGS})' beschränkt
    • Die Ergebnisse der Tool-Ausführung werden dem LLM in Form von tool_result(...) übergeben

Parsing von Tool-Aufrufen und Verarbeitung von LLM-Antworten

  • In der Antwort des LLM werden Zeilen gesucht, die mit tool: beginnen, und daraus werden Tool-Name und Argumente (JSON) extrahiert
  • Nach Ausführung jedes Tools wird das Ergebnis als JSON serialisiert und dem Gesprächsverlauf hinzugefügt
  • Die Funktion execute_llm_call ruft die LLM-API auf und gibt den Antworttext zurück
  • run_coding_agent_loop nimmt Benutzereingaben entgegen und hält die Gesprächsschleife mit dem LLM aufrecht
    • Die interne Schleife wird wiederholt, bis das LLM keine weiteren Tool-Aufrufe mehr anfordert
    Anzeige

Ausführungsbeispiele und Erweiterbarkeit

  • Beispielhafte Dialoge:
    • „Erstelle die Datei hello.py und implementiere hello world“ → Neuerstellung einer Datei per Aufruf von edit_file
    • „Füge hello.py eine Funktion hinzu, die zwei Zahlen multipliziert“ → Aufruf von read_file, gefolgt von edit_file
  • Ein vollständiger Coding-Assistent lässt sich mit rund 200 Zeilen Code umsetzen
  • Kommerzielle Produkte ergänzen darauf Fehlerbehandlung, Streaming-Antworten, Kontextverwaltung, zusätzliche Tools und Freigabeprozesse
  • Die Kernstruktur bleibt gleich und besteht aus einer einfachen Schleife, in der das LLM entscheidet und der Code ausführt

Praxis und Erweiterung

  • Der vollständige Quellcode umfasst etwa 200 Zeilen und lässt sich durch Austausch des LLM-Anbieters oder Hinzufügen weiterer Tools erweitern
  • Selbst mit einer einfachen Struktur lässt sich direkt ein leistungsfähiger Prototyp eines KI-Coding-Agenten umsetzen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-09
Hacker-News-Kommentare

  • Was ich noch hinzufügen würde, ist Planning
    Der Schlüssel zu effektivem Tool-Einsatz ist der Moment, in dem man erkennt, dass diese Systeme auf einer dynamischen TODO-Liste arbeiten
    Der Plan-Modus bootstrapped, wie diese Liste initial befüllt wird und wann die einzelnen Punkte ausgeführt werden
    Die Interaktion mit dem Nutzer funktioniert dann darüber, diese Liste neu zu ordnen
    Ich habe letzten Monat getestet, wie gut Claude Code CTF-Probleme löst, und wenn man das TodoList-Tool und Planning deaktiviert, fällt die Leistung um ein bis zwei Stufen ab
    Das zugehörige Video ist Breaking Bots: Cheating at Blue Team CTFs with AI Speed Runs
    Interessant ist, dass sich viele nur darauf konzentrieren, ob man den Plan-Modus nutzt oder nicht, während die TODO-Liste in Wirklichkeit immer aktiv ist
    Und wenn ich Beiträge sehe, die „smartes Kontextmanagement“ einfach als bloße TODO-Punkte abtun, muss ich lachen
    Viele versuchen, das selbst zu implementieren, und verlieren dann ein Jahr an Evaluierungsergebnissen, die in Produktion auseinanderfallen

    • Im Gist mit dem extrahierten System-Prompt von Claude Code gibt es viele Details zur TODO-Iteration
      Man könnte das einfach als zusätzliche Reasoning-Tokens anhängen, aber in der Praxis ist es viel vorhersehbarer und effektiver, es als explizites Single-Key-Storage-Tool umzusetzen
      Ich denke, dieser einfache Ansatz könnte auch bei anderen Tool-Ideen funktionieren, die Sprachstrukturen speichern
    • Für CLI-Agenten hat es sehr gut funktioniert, eine Datei als „working memory“ zu pflegen
      Beim Testen von Codex habe ich die Spezifikation etwa zehn Minuten lang geordnet, in Änderungsliste aufgeteilt, in einer Datei gespeichert und dann angewiesen, den Plan nach jeder Änderung zu überprüfen und anzupassen
      So kann sich das LLM auf kurze, zielorientierte Aufgaben konzentrieren, ohne dass ständig neuer Prompt-Input nötig ist
      Effektiv hat das einen ähnlichen Effekt wie ein Subagent
    • Ich füge am Ende von Prompts auch oft hinzu: „Verwende für diese Aufgabe eine sehr fein granulierte Todo-Liste“
      Als letzten Todo-Punkt lasse ich auch anweisen: „Prüfe die gesamte Arbeit erneut und kontrolliere die Qualität mit dem Linter oder Ähnlichem“
    • TODO-Listen werden oft wieder am HEAD des Kontexts eingefügt, damit das LLM sich an die Vergangenheit und die nächsten Schritte erinnert
      Bei der Kontextkomprimierung dienen sie auch als kompakte Darstellung der Sitzung
    • Gegen Jahresende gibt es vielleicht Witze wie „How to Code Claude Code in 200 Million Lines of Code“

  • Der Kern eines Coding-Agenten ist tatsächlich nur eine einfache Loop- und Tool-Call-Struktur
    Aber wenn man einen Artikel wie „The Emperor Has No Clothes: How to Code Claude Code in 200 Lines of Code“ schreiben will, sollte man unbedingt Thorsten Balls How to Build an Agent berücksichtigen
    Dieser Artikel hat die Idee, dass „die Essenz eines Agenten simpel ist“, zuerst aufgebracht
    Natürlich braucht man in der Realität TODOs und verschiedenes Scaffolding, und Claude Code selbst hat viele komplexe Konfigurationen, Plugins und UI-Funktionen
    Trotzdem kann man mit nur einer Minimal-Loop sogar bootstrappen, dass es seine Funktionen selbst erweitert
    Wenn du die internen Abläufe sehen willst, kannst du mit claude-trace die Interaktion zwischen LLM und Tool-Aufrufen nachverfolgen

    • Ich habe mir die interne Struktur angesehen, indem ich lokale Transcripts von Claude Code und Codex analysiert habe
      Neben der simplen Loop gibt es viele komplexe Elemente wie UUID-Threading, Message-Queue-Verarbeitung, Snapshots von Dateiveränderungen und Sidechains für Subagenten
      Deshalb sind „200 Zeilen“ konzeptionell richtig, aber auf echtem Produktionsniveau ist es deutlich komplexer
      Codex hat noch keine Queueing-Funktion, ist aber trotzdem stark
      Ich habe eine macOS-App namens Contextify gebaut, die CLI-Transcripts von Claude Code und Codex in Echtzeit überwacht und mit der Funktion Total Recall Abfragen über den Gesprächsverlauf ermöglicht
    • Codebearbeitung ist der wichtigste Teil
      Claude-Modelle sind auf ein eigenes str-replace-Tool-Schema trainiert
      Ganze Dateien neu zu schreiben ist ineffizient, deshalb sind partielle Änderungen entscheidend
    • Es gab auch Reaktionen wie „Ich dachte, das wäre derselbe Beitrag, der noch einmal gepostet wurde“
    • Ebenso die Bitte: „Kannst du diese einfache Core-Loop direkt zeigen?“

  • In Wirklichkeit gibt es noch mehr Bestandteile
    Zum Beispiel kommt es vor, dass ein Agent Early Stopping auslöst und die Aufgabe vorzeitig beendet
    Selbst aktuelle Reasoning-Modelle lösen das nicht
    Claude Code begegnet dem, indem es TODOs in jeden Prompt injiziert und so an die verbleibende Arbeit erinnert
    Im öffentlichen Repository von HolmesGPT gibt es verschiedene experimentelle Benchmarks

    • Es kam auch die Frage auf: „Warum tritt Early Stop überhaupt auf?“

  • Die Vorstellung „Man muss dem LLM nur die Tool-Liste und das Aufrufformat erklären“ war anfangs schockierend
    Ich dachte: Wenn ein LLM doch nur Text erzeugt, wie soll es dann Tools aufrufen? Aber als mir klar wurde, dass genau das alles ist, wirkte es magisch

  • Über die Feiertage habe ich mit Opus einen Coding-Agenten auf Basis einer Prolog-DSL gebaut (es waren mehr als 200 Zeilen)
    Überraschenderweise funktionierte er fast sofort gut
    Die aktuelle Modellgeneration scheint einen Punkt erreicht zu haben, an dem die Bedeutung des Agent-Harness abnimmt
    Siehe dazu auch diesen Beitrag

  • Vor einem Jahr war dieser Artikel ziemlich zutreffend, aber inzwischen haben sich Harnesses stark weiterentwickelt, sodass das einfache Loop-Modell das reale Verhalten von Claude Code kaum noch erklärt

    • Natürlich haben moderne Harnesses mehr Funktionen, aber das Grundkonzept bleibt weiterhin gültig
      Selbst einfache Agenten zeigen mit demselben Modell keinen riesigen Leistungsunterschied
      Das ist ähnlich wie bei einem Tutorial „Wie man seine eigene DB baut“, das zunächst einen grundlegenden B-Tree zeigt
    • Laut dem tbench.ai-Leaderboard steigert zusätzliche Komplexität die Leistung zwar etwas, aber ein einfacher loop-basierter Ansatz wie „Terminus“ ist trotzdem stark genug
    • Es gab auch den Hinweis: „Dieser Artikel wurde im Januar 2025 veröffentlicht“
    • Tatsächlich lag der Schwerpunkt der Fortschritte im letzten Jahr auf der Vereinfachung von Prompt- und Tool-Design
      Subagents, MCP und Skills sind eher Mittelklasse, und Kontextoptimierung ist nur bei Langläufern wirklich relevant
    • Mit dem codex-cli-Repository kann man Modelle besser analysieren

  • Ich baue selbst Agent-Loops für den Unternehmenseinsatz und verarbeite damit mehr als eine Milliarde Tokens pro Monat
    Die einfache Loop ist zwar der Kern, aber in realen Umgebungen lassen unzählige Details die Komplexität explodieren
    Zum Beispiel: Wie verarbeitet man die Loop, wenn Nutzer zwischendurch Nachrichten schicken, und wie synchronisiert man Webhook-Eingaben wie Slack?
    Dazu kommen Freigaben, Guardrails, asynchrone Task-Verarbeitung und vieles mehr
    Ich überlege, diese Erfahrungen einmal in einem Blogpost zusammenzufassen

  • Empfehlenswerte Beiträge sind You Should Write An Agent und How To Build An Agent

  • Unser SWE-bench-Team hat einen Open-Source-Agenten mit 100 Zeilen veröffentlicht
    Das ist mini-swe-agent, und er ist sowohl in der Forschung als auch in der Industrie beliebt
    Ein guter Einstieg, um die Welt der Agenten kennenzulernen

  • 2023 gab es einen Beitrag mit dem Titel „LangChain in 100 Zeilen nachbauen“
    Ich habe diesen Beitrag gesehen, ihn tatsächlich nachimplementiert und in mehreren Projekten genutzt

    • Es gab auch die Reaktion: „Kaum zu glauben, dass das schon drei Jahre her ist“