Warum jeder AI-Coding-Agent gleich anfängt – und wie du das änderst

Ehrlich gesagt: Wer schon mal versucht hat, einen eigenen KI-Coding-Agenten zu bauen, kennt das Problem. Man rackert sich durch das Parsen von Streaming-Antworten, kämpft sich durch Provider-Authentifizierung, definiert Tool-Schemas und implementiert File Sandboxes. Und irgendwann fragt man sich: Wann beschäftige ich mich eigentlich mit dem, was meinen Agenten besonders macht?

Genau hier liegt der Punkt. Die spannenden Teile – die Logik, die deinen Agenten einzigartig macht – versinken unter einem Berg an Infrastrukturcode. Code, den jedes einzelne Projekt braucht. Aber niemand will ihn jedes Mal neu schreiben.

Genau dieses Problem greift zot an.

Das 90/10-Problem bei der KI-Entwicklung

Falls du es noch nicht bemerkt hast: Es gibt ein krasses Ungleichgewicht beim Bau von Coding-Agents. Der eigentliche Wert deines Agenten – wie er Code analysiert, welchen Workflow er umsetzt, welche Persönlichkeit er hat – macht vielleicht zehn Prozent des Codes aus, den du schreibst.

Die anderen 90 Prozent? Streaming-Protokoll-Parsing, Provider-Authentifizierung, Tool-Definitionen, Sandboxing, System-Prompts. Infrastruktur, die jedes KI-Projekt braucht, aber niemand bauen will.

zot dreht dieses Verhältnis komplett um. Das Projekt liefert battle-getestete Go-Pakete für genau diese Infrastruktur, organisiert unter sauberen Interfaces. Du importierst den Provider-Client, die Agent-Loop, das Tool-Registry – was auch immer dein Harness braucht – und legst sofort mit deiner eigentlichen Agent-Logik los.

Vier Bausteine, unendliche Möglichkeiten

Die Architektur dahinter ist überraschend simpel. Jeder zot-basierte Agent besteht aus vier Kernkomponenten:

Provider Client — Verbindet sich mit Anthropic, OpenAI, Gemini oder jedem anderen unterstützten Modell über ein einheitliches Interface. Zwischen Providern wechseln? Das ist buchstäblich eine Zeile Code. zot normalisiert alles: Streaming-Antworten, Tool-Aufrufe, Usage-Metriken. Dein Agent-Code bleibt identisch, egal ob du Claude oder GPT-4 nutzt.

Tool Registry — Hier zeigt dein Agent Charakter. zot bringt fertige Tools mit: Dateien lesen, Inhalte schreiben, Bash-Befehle ausführen, Code editieren. Aber eigene Tools hinzufügen? Kein Problem. Interface implementieren, registrieren, fertig. Das Modell sieht ein sauberes JSON-Schema und kann dein Custom-Tool aufrufen wie jedes eingebaute.

System Prompt — Die Persona. Der Kontext. Die Anweisungen, die dem Modell sagen, welche Art von Agent es sein soll. zot bietet Helfer für vernünftige Defaults, aber du hast die Freiheit, genau den System-Prompt zu gestalten, den dein Use-Case braucht.

Agent Loop — Die Orchestrierungsschicht, die alles zusammenhält. Sie kümmert sich um den Request/Response-Zyklus, parst Tool-Aufrufe, führt registrierte Tools aus, füttert Ergebnisse zurück zum Modell und looppt, bis entweder fertig oder das Step-Limit erreicht ist.

Vier Bausteine. Und dein Agent läuft.

Warum einen eigenen Harness bauen?

zot bringt eine vollständige interaktive TUI mit. Also fragst du dich vielleicht: Warum sollte ich überhaupt einen eigenen Harness schreiben? Gute Frage. Hier ein paar Szenarien, in denen Custom Sinn ergibt:

Batch- und CI-freundliche Workflows — Interaktive TUIs sind super für Exploration. Aber was ist mit automatisierten Tasks? Ein Custom-Harness kann einen Prompt entgegennehmen, bis zur Fertigstellung durchlaufen und sich beenden. Perfekt für CI-Pipelines, die bei jedem Pull Request Code-Review, Test-Generierung oder Dokumentations-Updates brauchen.

Eingebettetes Agent-Verhalten — Willst du Agent-Fähigkeiten in ein größeres Go-Programm einbauen? Ein Custom-Harness gibt dir programmatische Kontrolle. Deine Hauptanwendung ruft den Agenten auf, erhält strukturierte Ergebnisse und macht mit eigener Logik weiter.

Restriktive Tooling — Die interaktive TUI bietet ein flexibles Set an Tools. Ein spezialisierter Harness kann den Tool-Satz und Sandbox auf das exakt Notwendige einschränken – nicht mehr, nicht weniger.

Eingefrorene Personas — Manchmal willst du keine Konfiguration. Ein Custom-Harness kann System-Prompt und Toolset fest für einen bestimmten Zweck verdrahten. Dein Agent wird zur verlässlichen, wiederholbaren Maschine statt zum Allzweck-Chatbot.

Mach es zu deinem Ding

Die echte Power liegt nicht nur darin, Boilerplate zu sparen. Es geht darum, das Verhalten deines Agenten vollständig zu besitzen.

Wenn du auf zot aufbaust, bekommst du Zugang zur gleichen battle-getesteten Infrastruktur, die auch die interaktive TUI antreibt. Aber du kontrollierst jeden Aspekt des user-facing Interface. Du kannst ein CLI mit spezifischen Output-Formaten bauen, einen Webhook, der Requests empfängt und Ergebnisse zurückliefert, einen Background-Service, der Repositories überwacht, oder eine komplett eigene TUI mit deiner eigenen visuellen Sprache.

Jede Codezeile, die du schreibst, dreht sich um dein Produkt, deinen Workflow, deine Differenzierung. Nicht ums Neuschreiben von Streaming-Parsern.

Loslegen

Wenn du Go-Entwickler bist und neugierig auf KI-Agents: zot bietet den geringsten Reibungsweg zu etwas Greifbarem. Das Vier-Baustein-Skelett, das ich oben beschrieben habe, ist alles, was du zum Experimentieren brauchst. Tools registrieren, System-Prompt schreiben, Agent-Loop starten.

Du kannst einen funktionierenden Prototype haben, bevor dein Kaffee kalt wird. Und danach wird jede Erweiterung über das definiert, was deinen Agenten zu deinem macht.

Der AI-Coding-Agent-Bereich ist noch jung genug, dass die meisten Projekte dieselben fundamentalen Probleme unabhängig voneinander lösen. zot lässt dich diese Phase überspringen und direkt zum interessanten Teil springen: herausfinden, was dein Agent tun soll – nicht, wie er Responses streamen soll.

Das ist ein Tausch, der sich lohnt.

Bereit zu bauen? Schau dir das zot-Projekt an und erkunde, wie du seine Komponenten zu etwas zusammenstellen kannst, das zu deiner Vision passt. Die Infrastruktur ist erledigt – jetzt mach es interessant.