Wie ein Coding-Agent arbeitet.

2.1 Anatomie eines Agentenaufrufs

Moderne Coding-Agenten wie Claude Code, OpenAI Codex, Gemini CLI, Aider oder die Kimi-CLI sind Kommandozeilenprogramme. Sie verbinden ein Sprachmodell (meist über das Netz beim Anbieter, manchmal lokal) mit Werkzeugen auf deinem Rechner. Wenn du einen solchen Agenten startest, passiert grob Folgendes:

1. Das Programm stellt einen Startkontext zusammen: eine eingebaute Systemanweisung des Herstellers („Du bist ein Coding-Assistent, du hast diese Werkzeuge…“), gegebenenfalls Konfigurationsdateien aus deinem Home-Verzeichnis und aus dem Projekt, und deine Aufgabe.
2. Es schickt den Kontext an das Modell und bekommt entweder Text oder einen Werkzeugaufruf zurück.
3. Es prüft, ob der Werkzeugaufruf erlaubt ist (Permissions), führt ihn aus und hängt das Ergebnis an den Kontext an.
4. Es wiederholt die Schritte 2 und 3, bis das Modell die Aufgabe für erledigt hält, ein Limit greift oder ein Fehler auftritt.
5. Es gibt eine Abschlussmeldung aus — je nach Modus als Text oder als strukturiertes JSON mit Ergebnis, Token-Verbrauch und gegebenenfalls einer Kostenschätzung.

Grafik in voller Größe öffnenGrafik in voller Größe öffnen

Der Prompt ist mehr als deine Aufgabe

Wenn man von „dem Prompt“ spricht, meint man oft nur den Satz, den man eintippt. Tatsächlich besteht der Kontext eines Agenten aus mehreren Schichten:

Die zweite Schicht ist tückisch: Viele Agenten laden Konfiguration automatisch — aus deinem Home-Verzeichnis (persönliche Einstellungen, Plugins, angebundene Dienste) und aus dem Projektverzeichnis. Was praktisch ist, wenn du allein an deinem eigenen Code arbeitest, wird zum Problem, wenn ein Agent in einem fremden Repository oder auf einem gemeinsam genutzten Rechner läuft: Dann bestimmt jemand anderes mit, was der Agent weiß und darf. Wie die Fabrik damit umgeht, siehst du unten im Praxis-Kasten „Ephemeres HOME“ und ausführlich in Kapitel 8.

2.2 Werkzeuge und Permissions

In Kapitel 1 hast du gelernt: Ein Agent kann alles, was seine Werkzeuge können. Permissions (Berechtigungen) sind die Schicht, die festlegt, welche Werkzeugaufrufe tatsächlich ausgeführt werden. Sie sind die wichtigste Stellschraube zwischen Nützlichkeit und Risiko.

Typische Permission-Modelle

• Fragen bei jeder Aktion: Der Agent zeigt jeden Schreib- oder Ausführungsschritt an und wartet auf deine Bestätigung. Sicher, aber im Alltag mühsam — und ohne Mensch am Terminal unbrauchbar.
• Erlaubnislisten (Allowlists): Bestimmte Werkzeuge oder Befehlsmuster sind vorab erlaubt, etwa „Dateien bearbeiten“ oder „mvn mit beliebigen Argumenten“. Alles andere wird abgelehnt oder erfordert Rückfrage.
• Verbotslisten (Denylists): Bestimmte Werkzeuge sind ausdrücklich gesperrt, etwa Schreiben für einen reinen Prüfagenten.
• Alles erlauben: Viele Agenten haben einen Modus, der sämtliche Prüfungen abschaltet. Er ist für Wegwerf-Umgebungen gedacht (eine virtuelle Maschine, die danach gelöscht wird) — nicht für einen Rechner mit Zugangsdaten, SSH-Schlüsseln und Firmennetz.

Das Prinzip der geringsten Rechte

Ein Agent sollte genau die Rechte bekommen, die seine Aufgabe erfordert, und nicht mehr. Für einen Agenten, der Code schreibt und testet, heißt das etwa: Dateien im Projekt lesen und schreiben, Build- und Testwerkzeuge ausführen, lesende Git-Befehle. Nicht nötig sind dagegen: beliebige Netzwerkzugriffe (curl, wget), Löschen außerhalb des Projekts, git push. Commit und Push übernimmt besser das umgebende System — dann sind sie kontrolliert und nachvollziehbar.

Ein Prüfagent (Reviewer) braucht noch weniger: Er soll lesen und urteilen, aber nichts verändern. Genau hier ist eine harte technische Sperre wertvoller als eine freundliche Bitte im Prompt: „Bitte ändere nichts“ ist eine Anweisung, die ein Modell missverstehen kann; ein gesperrtes Schreibwerkzeug ist eine Tatsache.

2.3 Headless: Agenten ohne Mensch am Terminal

Im Alltag nutzen viele Entwickler:innen Agenten interaktiv: Man öffnet eine Sitzung im Terminal, gibt eine Aufgabe ein, beobachtet, beantwortet Rückfragen, bestätigt Aktionen. Für automatisierte Abläufe — CI-Pipelines, Skripte, eine Control Plane wie die Fabrik — braucht man den headless-Betrieb: Der Agent bekommt seine Aufgabe als Argument, arbeitet sie ab und beendet sich mit einem Ergebnis.

Bei Claude Code heißt der Schalter dafür --print (kurz -p); andere CLIs haben Entsprechungen wie codex exec, gemini -p oder bei Aider --message zusammen mit --yes. Gemeinsam ist allen:

• Keine Rückfragen möglich. Niemand antwortet. Der Agent muss mit Unklarheiten selbst umgehen — gute Anweisungen sagen ihm, wie (Annahmen festhalten, die konservativste Auslegung wählen, Abweichungen deutlich markieren).
• Permissions müssen vorab feststehen. Ein Agent, der auf eine Bestätigung wartet, die nie kommt, tut entweder nichts oder bittet in seiner Textausgabe um Erlaubnis.
• Strukturierte Ausgabe. Mit einem Ausgabeformat wie JSON lässt sich das Ergebnis maschinell auswerten: Erfolg oder Fehler, Token-Verbrauch, gegebenenfalls die Kostenschätzung der CLI.
• Zeitlimits. Ein headless-Lauf braucht eine Obergrenze, damit ein hängender Agent nicht ewig läuft.

claude --print --output-format json \
       --permission-mode acceptEdits \
       --allowedTools "Read,Glob,Grep,Bash(mvn *)" \
       "Lies PROJECT.md und INSTRUCTIONS.md und beginne mit der Umsetzung. ..."

2.4 Sitzungen und Gedächtnis

Eine Sitzung ist der zusammenhängende Arbeitsverlauf eines Agenten — alles, was in einem Kontextfenster zusammengehört. Viele Agenten können Sitzungen speichern und später fortsetzen. Für reproduzierbare, nachvollziehbare Arbeit ist das aber nur bedingt hilfreich: Der Inhalt einer Sitzung ist schwer einsehbar, hängt an einem Rechner und einem Werkzeug und wächst mit jedem Schritt.

Robuster ist es, dauerhaftes Wissen in Dateien zu halten, die im Repository liegen und bei jedem Lauf neu gelesen werden:

• Projektbeschreibung — was gebaut wird und warum.
• Arbeitsanweisungen — Konventionen, Build-Befehle, Verbote.
• Gedächtnis — Entscheidungen und Erkenntnisse aus früheren Läufen.
• Der Code selbst und seine Git-Historie — die zuverlässigste Quelle dafür, was bisher passiert ist.

So startet jeder Lauf mit einem frischen, definierten Kontext, und das „Gedächtnis“ ist für Menschen lesbar, versioniert und reviewbar. Diese Strategie verfolgt auch die Fabrik: Jeder Run ist ein neuer headless-Aufruf; was zwischen Runs erhalten bleiben soll, steht im Workspace (Artefakte, MEMORY.md, Code). Details dazu in Kapitel 3.

2.5 Modelle: welches Gehirn für welche Aufgabe?

Hinter jedem Agenten steht ein Modell, und die meisten Agenten lassen dich zwischen mehreren Modellen wählen. Ohne konkrete Produktnamen — die sich ständig ändern — lassen sich einige dauerhafte Kriterien nennen:

• Fähigkeit: Größere Modelle sind meist besser bei Planung, Architekturfragen und schwierigen Fehlern.
• Kosten: Sie sind auch teurer pro Token und oft langsamer.
• Geschwindigkeit: Kleinere Modelle eignen sich für mechanische Arbeit und schnelle Prüfungen.
• Kontextfenster: Wie viel passt in einen Aufruf?
• Datenhaltung und Ort: Wo läuft das Modell? Darf der Code die Firma verlassen? Für manche Umgebungen kommt nur ein lokal betriebenes Modell in Frage.

Eine bewährte Faustregel lautet: stark planen, günstig umsetzen, schnell prüfen. Die Planung eines Vorhabens ist selten, aber folgenreich — hier lohnt ein starkes Modell. Die mechanische Umsetzung eines klaren Plans gelingt auch mit einem mittleren Modell. Für Reviews mit klarer Fragestellung reicht oft ein kleines, schnelles Modell. Wie die Fabrik diese Rangfolge abbildet (Routing, Team-Präferenz, Rollen-Default), behandelt Kapitel 10.

2.6 Warum ein Agentenlauf einen Lebenszyklus braucht

Ruft man einen Agenten einfach im Terminal auf, gibt es genau zwei Zustände: läuft oder fertig. Für kontrollierte Softwareentwicklung reicht das nicht. Man möchte wissen: Ist die Arbeitsumgebung vorbereitet? Wartet der Lauf auf eine Freigabe? Läuft gerade die Prüfung? Ist er gescheitert, abgebrochen, in einer Zeitüberschreitung hängen geblieben? Und man möchte an bestimmten Punkten eingreifen können: pausieren, abbrechen, freigeben.

Ein expliziter Lebenszyklus mit Phasen und Status macht einen Agentenlauf zu einem steuerbaren Prozess. Jede Phase hat eine klare Aufgabe; jeder Statuswechsel ist ein Ereignis, das man protokollieren, auswerten und absichern kann. Das ist die Voraussetzung für alles, was in späteren Kapiteln folgt: Freigaben, Quality Gates, Korrekturschleifen, Nachweise.

2.7 Planen und Bauen trennen

Ein häufiger Fehler beim Arbeiten mit Agenten ist, Planung und Umsetzung in einem einzigen Lauf zu vermischen: „Überleg dir, was als Nächstes sinnvoll ist, und setz es gleich um.“ Der Agent trifft dann folgenreiche Entscheidungen, ohne dass du sie vorher sehen konntest, und das Ergebnis ist schwer zu prüfen, weil Absicht und Ausführung verschmelzen.

Besser ist eine Trennung: Ein Planungslauf analysiert den Stand und schlägt Schritte vor, ohne Produktivcode zu ändern. Ein Mensch prüft die Vorschläge, wählt aus, priorisiert. Erst dann setzt ein Umsetzungslauf einen ausgewählten Schritt um. Der Plan wird so zu einem prüfbaren Zwischenergebnis — und zum Maßstab, an dem man die Umsetzung messen kann.

2.8 Zugang zum Modell: Abo oder API-Key

Ein Coding-Agent braucht Zugang zu seinem Modell. Grundsätzlich gibt es zwei Wege:

• API-Key: Du bekommst vom Anbieter einen Schlüssel und zahlst nach Verbrauch, typischerweise je Million Input- und Output-Tokens. Transparent, gut für Teams und Automatisierung, aber die Kosten wachsen mit der Nutzung.
• Abonnement: Viele Anbieter erlauben, ihren Coding-Agenten mit einem persönlichen Abo zu nutzen. Man meldet sich einmal interaktiv an; die CLI speichert die Anmeldedaten lokal. Abgerechnet wird über das Abo und dessen Nutzungsgrenzen, nicht pro Token.

Welche Bedingungen für die Abo-Nutzung gelten — insbesondere für automatisierte, headless Nutzung und für die Nutzung durch mehrere Personen — legt der jeweilige Anbieter fest, und sie ändern sich. Prüfe sie vor dem Einsatz in deinem konkreten Fall. Eine wichtige technische Falle gilt aber allgemein: Ist in der Umgebung zusätzlich ein API-Key gesetzt, kann die CLI stillschweigend den kostenpflichtigen API-Pfad wählen, obwohl du das Abo nutzen wolltest.

Zusammenfassung

• Ein Coding-Agent ist ein CLI-Programm: Kontext (System-Prompt, Konfiguration, Aufgabe, Verlauf) + Werkzeuge + Permissions + Modell.
• Geringste Rechte: Schreib- und Ausführungsrechte eng fassen, Prüfagenten technisch read-only machen, „alles erlauben“ nur in Wegwerf-Umgebungen.
• Headless heißt: keine Rückfragen, Permissions vorab, strukturierte Ausgabe, Zeitlimit.
• Dauerhaftes Wissen gehört in Dateien im Repository, nicht in Sitzungen.
• Die Fabrik ruft Agenten über Execution-Adapter auf und führt jeden Run durch sieben Phasen mit klaren Status, Freigabe-Gate und Inline-Diff.
• PLAN-Runs schlagen vor, BUILD-Runs setzen um.
• Im Abo-Modus strippt die Fabrik API-Keys, weist Kosten als Schätzung aus und isoliert jeden Lauf mit einem ephemeren HOME.

Kapitelfragen

1. Aus welchen Schichten besteht der Kontext eines Coding-Agenten, und welche davon ist für die Sicherheit besonders heikel?

   Musterantwort

   System-Prompt des Herstellers, automatisch geladene Konfiguration und Gedächtnisdateien (Home-Verzeichnis, Projekt), die Aufgabe und der Arbeitsverlauf. Heikel ist die automatisch geladene Konfiguration: Sie kann aus fremden Quellen stammen (persönliche Plugins, angebundene Dienste, Einstellungen eines importierten Repositorys) und bestimmt dann mit, was der Agent weiß und darf.

2. Warum reicht es nicht, einem Review-Agenten im Prompt zu sagen, dass er nichts ändern soll? Wie löst die Fabrik das?

   Musterantwort

   Eine Anweisung im Prompt kann missverstanden oder übergangen werden; eine technische Sperre nicht. Die Fabrik startet Claude-Code-Reviews mit --permission-mode dontAsk und --disallowedTools für Edit, Write und Bash — die Reviewer sind damit technisch read-only.

3. Was ändert sich, wenn ein Agent headless statt interaktiv läuft? Nenne mindestens drei Punkte.

   Musterantwort

   Niemand beantwortet Rückfragen, also muss der Agent mit Unklarheiten selbst umgehen (Annahmen festhalten). Permissions müssen vorab feststehen, sonst schreibt der Agent nichts oder bittet nur im Text um Erlaubnis. Die Ausgabe sollte strukturiert (etwa JSON) sein, damit sie maschinell auswertbar ist. Und es braucht ein Zeitlimit.

4. Warum lehnt die Fabrik --dangerously-skip-permissions ab, obwohl das den Agenten produktiver machen könnte?

   Musterantwort

   Weil die Agent-CLI auf dem Host läuft und nicht in einer Wegwerf-VM. Ohne Permission-Prüfung könnte der Agent beliebige Befehle ausführen — Dateien löschen, Netzwerkzugriffe, Zugangsdaten lesen. Stattdessen nutzt die Fabrik acceptEdits mit einer engen Allowlist.

5. Nenne die sieben Phasen eines Runs in der richtigen Reihenfolge und erkläre, in welcher Phase das Build-Gate läuft.

   Musterantwort

   INTAKE, PROMPT_ASSEMBLY, WORKSPACE_PREPARATION, EXECUTION, VALIDATION, CORRECTION, COMPLETION. Das Build-Gate (mvn verify) läuft in VALIDATION; scheitert es, folgt CORRECTION mit automatischem Feedback (bis zu zwei Versuche).

6. Du nutzt den Claude-Abo-Modus, hast aber vergessen, dass in deiner Shell noch ANTHROPIC_API_KEY gesetzt ist. Was passiert in einem Fabrik-Run, und was würde ohne die Fabrik passieren?

   Musterantwort

   Im Abo-Modus entfernt die Fabrik den Key aktiv aus dem Subprozess; der Run läuft über das Abo. Ohne diese Maßnahme könnte die CLI den Key bevorzugen und stillschweigend über die kostenpflichtige API abrechnen. Sauberer bleibt es trotzdem, den Key gar nicht erst in der Umgebung zu haben.

7. Wozu dient die Trennung von PLAN- und BUILD-Runs?

   Musterantwort

   Der PLAN-Run erzeugt prüfbare Vorschläge (plans/NNNN-*.md mit Scope und Akzeptanzkriterien), ohne Produktivcode zu ändern. Ein Mensch wählt aus und priorisiert; erst der BUILD-Run setzt um. So werden folgenreiche Entscheidungen sichtbar, bevor sie Code werden, und die Umsetzung hat einen Maßstab.

8. Ein Kollege wundert sich, dass sein persönlich eingerichteter MCP-Server in Fabrik-Runs nicht verfügbar ist. Ist das ein Fehler?

   Musterantwort

   Nein, das ist Absicht. Jeder Agentenaufruf bekommt ein frisches, leeres HOME; übernommen werden nur die Anmeldedaten. Persönliche MCP-Server, Plugins, Hooks und Einstellungen wirken nicht (MCP-Nullzustand, ADR-0017). Freigegebene, lesende MCP-Werkzeuge lassen sich gezielt über den MCP-Gateway bereitstellen (Kapitel 8).

9. Transfer: Dein Team will künftig ein lokales Modell statt eines Cloud-Anbieters nutzen. Was ändert sich am Prozess in der Fabrik, was bleibt gleich?

   Musterantwort

   Es ändert sich vor allem die Adapter-Konfiguration (local-llm mit einem OpenAI-kompatiblen Backend wie Ollama oder vLLM) und gegebenenfalls die erwartbare Qualität und Geschwindigkeit des Modells. Gleich bleiben Projektartefakte, Guardrails, Run-Lebenszyklus, Branch je Run, Build-Gate, Quality Gate, Freigaben und Audit — genau das ist der Sinn der Adapter-Schicht.