8. Agentic Coding

Agentic Coding

Bis hierher war das Modell eine Funktion: Text hinein, Text heraus. Es konnte nichts lesen, nichts ausführen, nichts verändern. Dieses Kapitel handelt von dem Schritt, der aus dieser Funktion einen Mitarbeiter macht, und von den drei Zutaten, die dafür nötig sind: Werkzeuge, eine Schleife und eine Abbruchbedingung.

Der Schritt ist technisch kleiner, als sein Effekt vermuten lässt. Genau deshalb lohnt es sich, ihn genau anzusehen: Wer versteht, wo die Grenze zwischen Modell und Programm verläuft, kann einschätzen, was ein Agent leisten kann und wo er zwangsläufig scheitert.

Drei Stufen

Stufe	Was das Werkzeug tut	Wer entscheidet	Aufwand für Sie
Vervollständigung	schlägt die nächsten Zeilen vor, während Sie tippen	Sie, bei jedem Vorschlag	Sie schreiben, es hilft
Chat	beantwortet Fragen, erzeugt Codeblöcke zum Kopieren	Sie, beim Einfügen	Sie übertragen von Hand
Agent	liest Dateien, ändert sie, führt Befehle aus, prüft das Ergebnis	der Agent, innerhalb der erlaubten Grenzen	Sie beauftragen und prüfen

Zwischen Chat und Agent liegt der eigentliche Bruch, und er ist nicht technischer, sondern arbeitsorganisatorischer Natur. Beim Chat bleibt jede Änderung durch Ihre Hände, weil Sie sie einfügen. Beim Agenten nicht. Ihre Kontrolle verschiebt sich vom Einfügen auf das Beauftragen davor und das Prüfen danach, und genau darum drehen sich die Kapitel 10 und 11.

Was ein Agent ist

Ein Agent ist ein Programm, das ein Sprachmodell in einer Schleife aufruft und ihm dabei erlaubt, Werkzeuge zu benutzen. Mehr nicht.

sequenceDiagram
  participant U as Sie
  participant H as Harness (das Programm)
  participant M as Modell
  participant S as System (Dateien, Shell)

  U->>H: Auftrag
  loop bis fertig oder abgebrochen
    H->>M: Kontext + Werkzeugbeschreibungen
    M->>H: "rufe grep auf mit {muster: 'validate'}"
    H->>H: erlaubt? ggf. nachfragen
    H->>S: führt grep aus
    S->>H: Ergebnis
    H->>H: Ergebnis in den Kontext
  end
  H->>U: Antwort und geänderte Dateien

An diesem Diagramm ist eine Stelle wichtiger als alles andere:

Ein Werkzeug ist dabei nichts weiter als eine Funktion mit einer Beschreibung und einem Schema für ihre Parameter, meist als JSON Schema. Das Schema geht mit in den Kontext, das Modell erzeugt einen passenden Aufruf, das Harness ruft die Funktion auf. Die Beschreibung ist dabei nicht Dokumentation für Menschen, sondern die Anweisung, nach der das Modell entscheidet, ob es das Werkzeug überhaupt in Betracht zieht. Eine Beschreibung, die sagt, wann man ein Werkzeug aufruft, wirkt deutlich besser als eine, die nur sagt, was es tut.

{
  "name": "run_tests",
  "description": "Runs the test suite. Call this after every change to source files, before you report the result.",
  "input_schema": {
    "type": "object",
    "properties": {
      "path": { "type": "string", "description": "Optional path to narrow the selection" }
    }
  }
}

Der Werkzeugkasten

Praktisch alle Coding-Agenten bringen denselben Grundstock mit. Die Namen unterscheiden sich, die Funktionen nicht.

Werkzeug	Zweck	Risiko
`read`	Datei lesen	gering, aber: liest auch Geheimnisse
`glob`	Dateien nach Muster finden	gering
`grep`	Inhalte durchsuchen	gering
`write` / `edit`	Datei anlegen oder ändern	hoch, verändert Ihr Projekt
`bash`	beliebigen Befehl ausführen	sehr hoch, kann alles
`web_search` / `web_fetch`	im Netz nachsehen	mittel, holt fremden Text in den Kontext

Die letzte Zeile wird gern übersehen und ist der Einstiegspunkt für Prompt Injection (Kapitel 12). Alles, was ein Agent von außen liest, landet als Text an derselben Stelle wie Ihre Anweisungen.

Der Unterschied zwischen bash und einem eigenen Werkzeug ist übrigens eine Entwurfsentscheidung, keine Kleinigkeit. Mit bash kann ein Agent fast alles, aber das Harness sieht nur eine undurchsichtige Zeichenkette und kann weder um Bestätigung fragen noch sinnvoll protokollieren. Ein eigenes Werkzeug deploy_staging dagegen kann man gezielt absichern, mit einer Rückfrage versehen und im Log wiederfinden. Faustregel: breit anfangen mit bash, und alles, was gefährlich oder schwer umkehrbar ist, in ein eigenes Werkzeug herausziehen.

Berechtigungen

Ein Agent, der ohne Rückfrage alles darf, ist bequem und dumm. Ein Agent, der bei jeder Kleinigkeit fragt, wird weggeklickt, und dann ist die Rückfrage wertlos. Die brauchbare Einteilung folgt der Umkehrbarkeit.

Ohne Rückfrage: alles Lesende. read, grep, glob, git status, git diff, Tests ausführen. Das ist die überwiegende Mehrheit der Aufrufe, und jede Rückfrage darauf trainiert Sie zum Wegklicken.
Mit Rückfrage: Änderungen an Dateien außerhalb des klar abgegrenzten Arbeitsbereichs, Installation von Abhängigkeiten, alles, was Geld kostet.
Nie ohne ausdrückliche Freigabe: git push, Löschen ganzer Verzeichnisse, git reset --hard, Zugriff auf Produktivsysteme, Versenden von Nachrichten, alles mit Außenwirkung.
Gar nicht: Zugriff auf Produktionsdatenbanken, Umgang mit echten Kundendaten, Rotation von Zugangsdaten.

Die technische Absicherung dazu kennen Sie aus der 4. Klasse: Container und geringste Rechte. Ein Agent, der in einem Container mit einem Bind Mount auf genau das Projektverzeichnis läuft, ohne Zugriff auf ~/.ssh und ohne die Cloud-Zugangsdaten in der Umgebung, kann im schlimmsten Fall Ihr Projekt kaputt machen. Das ist ein Zustand, aus dem Git Sie zurückholt.

Und daraus folgt die wichtigste Betriebsregel überhaupt: Ein Agent arbeitet nie auf uncommitteten Änderungen, die Ihnen wichtig sind. Vor dem Start ein sauberer Arbeitsbaum und ein eigener Branch. Dann ist jede Katastrophe ein git checkout . weit weg.

Die Rückmeldeschleife ist alles

Hier steht der Satz, der über Erfolg oder Misserfolg beim agentischen Arbeiten entscheidet, mehr als die Wahl des Modells:

Ein Agent ist so gut wie die Rückmeldung, die er bekommt.

Ein Modell ohne Werkzeuge rät (Kapitel 3). Ein Agent, der den Compiler laufen lassen, die Tests ausführen, die Fehlermeldung lesen und daraufhin korrigieren kann, rät nicht mehr, sondern probiert und misst. Das ist derselbe Unterschied wie zwischen einem Anfänger, der Code hinschreibt und hofft, und einem, der ihn ausführt.

Woraus eine gute Schleife besteht:

Compiler oder Typprüfung. Sofortiges, präzises Urteil über ganze Fehlerklassen. In einem TypeScript-Projekt ist tsc --noEmit das billigste Signal, das es gibt.
Tests. Das eigentliche Erfolgskriterium (Kapitel 11). Ohne Tests hat der Agent keine Definition von „fertig” außer seinem eigenen Eindruck.
Linter und Formatierer. Halten den Stil, ohne dass Sie darüber reden müssen.
Die Anwendung selbst. Ein Agent, der die Seite aufrufen oder den Endpunkt abfragen kann, prüft an der Realität statt an seiner Vorstellung.

Umgekehrt gilt: In einem Projekt ohne Tests, ohne Typen und ohne Linter arbeitet ein Agent blind. Der häufigste Grund für die Erfahrung „das Werkzeug taugt nichts” ist nicht das Werkzeug, sondern ein Projekt, das kein maschinelles Urteil über den eigenen Zustand fällen kann.

Rules: was immer gilt

Ohne Vorkehrung fängt jede Sitzung bei null an. Der Agent weiß nicht, mit welchem Befehl die Tests laufen, dass der Datenbankzugriff nur im Repository stehen darf und dass neue Abhängigkeiten abzusprechen sind. Man kann das in jeden Prompt schreiben, oder man schreibt es einmal auf.

Rules sind Anweisungen, die der Agent zu Beginn jeder Sitzung erhält, ohne dass Sie sie eintippen. Jedes Werkzeug hat dafür eine Datei, und die Namen unterscheiden sich:

Werkzeug	Ablage
Claude Code	`CLAUDE.md` im Projekt, `~/.claude/CLAUDE.md` für alle Projekte, dazu `.claude/rules/` für einzeln gehaltene Regeln
Werkzeugübergreifend	`AGENTS.md` im Projektwurzelverzeichnis, von mehreren Werkzeugen gelesen, aber nicht von allen (siehe unten)
Cursor	`.cursor/rules/*.mdc`, je Datei ein Regelsatz mit Frontmatter
GitHub Copilot	`.github/copilot-instructions.md`, dazu `*.instructions.md` für einzelne Pfade

# Projektkontext

Next.js 15 mit App Router, TypeScript strict, PostgreSQL über Prisma.

## Befehle
- `bun run dev` startet die Entwicklung
- `bun run test` führt die Tests aus (vor jeder Meldung "fertig" ausführen)
- `bun run typecheck` prüft die Typen

## Architektur
Drei Schichten. Datenbankzugriff ausschließlich in `src/repositories/`.
Ein `PrismaClient` in einer React-Komponente ist ein Fehler, kein Stilproblem.

## Konventionen
- Eingaben an der Schnittstelle mit Zod validieren, nie manuell
- Fehlerformat: `{ error: { code, message } }`, Statuscode passend
- Keine neuen Abhängigkeiten ohne Rückfrage

Geltungsbereiche

Regeln lassen sich gestaffelt ablegen, und diese Staffelung ist der Grund, warum das Verfahren im Team funktioniert.

Persönlich (im Benutzerverzeichnis): Ihre Arbeitsweise, gilt in allen Projekten, gehört niemandem sonst. Etwa: „Antworte knapp, keine Zusammenfassungen von Offensichtlichem.”
Projekt (im Repository): Alles, was für jeden gilt, der hier mitarbeitet. Wird versioniert und im Merge Request reviewt wie Code, weil es die Ausgabe aller Beteiligten beeinflusst.
Verzeichnis: Eine eigene Datei in einem Unterordner gilt zusätzlich für Arbeiten in diesem Ordner. Praktisch in Monorepos, wo Frontend und Backend verschiedene Konventionen haben.
Bedingt: Manche Werkzeuge laden eine Regeldatei nur, wenn die bearbeitete Datei zu einem Muster passt (etwa **/*.test.ts). Damit stehen Testkonventionen nur dann im Kontext, wenn tatsächlich Tests bearbeitet werden.

Was hineingehört und was nicht

Gehört in die Rules	Gehört woandershin
Befehle für Bauen, Testen, Typprüfung	Was aus `package.json` ohnehin hervorgeht
Architekturregeln, deren Verletzung ein Fehler ist	Allgemeine Programmierweisheiten
Fehler- und Antwortformate des Projekts	Die vollständige API-Dokumentation
Konventionen, die man dem Code nicht ansieht	Was der Linter ohnehin erzwingt
Was der Agent nicht tun soll	Tagesaktuelles („wir sind gerade bei Sprint 7”)
Verweis auf die tiefergehende Anleitung	Die Anleitung selbst (dafür gibt es Skills)

Wie man sie schreibt

Für diese Datei gilt, was für Prompts allgemein gilt: kürzer und konkreter schlägt länger und vollständiger. Vierhundert Zeilen werden verwässert; wenn alles wichtig ist, ist nichts wichtig. Konkret heißt konkret: „Datenbankzugriff ausschließlich in src/repositories/” ist eine Regel, „sauber programmieren” ist keine.

Zwei weitere Punkte. Die Datei ist Teil des cachebaren Präfixes (Kapitel 4), also der richtige Ort für Stabiles und der falsche für Tagesaktuelles. Und sie gehört gepflegt: Eine Regel, die nicht mehr stimmt, richtet mehr Schaden an als eine fehlende, weil der Agent sie befolgt.

Skills: Wissen auf Abruf

Rules haben einen Nachteil, der aus ihrer Stärke folgt: Sie stehen immer im Kontext. Eine zweihundert Zeilen lange Anleitung „wie wir in diesem Projekt Datenbankmigrationen machen” ist bei jeder Sitzung dabei, auch bei den neunzig Prozent, in denen es um etwas anderes geht. Sie kostet dann Tokens und verdünnt die übrigen Anweisungen.

Ein Skill löst das. Er ist ein Verzeichnis mit einer Datei SKILL.md, die im Frontmatter einen Namen und eine Beschreibung trägt, dazu optional weitere Dateien und ausführbare Skripte.

---
name: api-endpoint
description: Anlegen oder Ändern eines REST-Endpunkts in diesem Projekt.
  Verwenden, sobald eine Route unter src/app/api/ hinzukommt oder sich ändert.
---

# Einen API-Endpunkt anlegen

1. Zod-Schema in `src/lib/schemas/` anlegen, benannt nach der Ressource.
2. Repository-Funktion in `src/repositories/` ergänzen. Kein Prisma-Aufruf
   außerhalb dieser Schicht.
3. Route Handler in `src/app/api/<ressource>/route.ts`:
   parsen, validieren, Repository aufrufen, Antwort formen.
4. Fehler immer als `{ error: { code, message, fields } }`, Statuscode
   400 bei Validierung, 404 bei Nichtfinden, 409 bei Konflikt.
5. Test unter `tests/api/` nach dem Muster in `beispiel.post.test.ts`.

## Prüfen
`bun run typecheck && bun run test`

Progressive Disclosure

Der Kniff steckt darin, was wann im Kontext liegt. Dauerhaft steht dort nur die Beschreibung, also ein bis zwei Zeilen je Skill. Erst wenn eine Aufgabe dazu passt, liest der Agent die vollständige Datei.

flowchart TB
  A["Kontext zu Sitzungsbeginn"] --> B["Rules: vollständig"]
  A --> C["Skills: nur Name und Beschreibung"]
  C --> D{"Aufgabe passt<br/>zur Beschreibung?"}
  D -->|ja| E["SKILL.md wird gelesen,<br/>Inhalt kommt in den Kontext"]
  D -->|nein| F["bleibt ungelesen,<br/>kostet nichts"]

Damit ist auch klar, worauf es beim Schreiben ankommt: Die Beschreibung ist der Auslöser. Sie entscheidet, ob der Skill überhaupt betrachtet wird, und sie muss deshalb sagen, wann man ihn verwendet, nicht nur, was er enthält. Das ist dieselbe Regel wie bei den Werkzeugbeschreibungen weiter oben in diesem Kapitel, und sie wird aus demselben Grund oft verfehlt: Man beschreibt den Inhalt und vergisst den Anlass.

Beschreibung	Wirkung
„Informationen zu unseren API-Konventionen”	wird selten geladen, weil kein Anlass genannt ist
„Verwenden, sobald eine Route unter `src/app/api/` hinzukommt oder sich ändert”	trifft zuverlässig

Wofür sich Skills lohnen

Mehrschrittige Abläufe, die immer gleich sind: einen Endpunkt anlegen, eine Migration durchführen, ein Release schnüren.
Wissen, das zu lang für die Rules ist: das Datenmodell, der Freigabeprozess, die Regeln für Barrierefreiheit im Frontend.
Aufgaben mit beigelegten Werkzeugen: Ein Skill darf Skripte mitbringen, die der Agent ausführt, statt sich das Vorgehen jedes Mal neu auszudenken.
Wiederkehrendes über Projektgrenzen hinweg: persönlich abgelegte Skills stehen in allen Projekten zur Verfügung.

Die vier Wege, Kontext bereitzustellen

Damit ist das Bild vollständig. Ein Agent bekommt sein Wissen über vier Mechanismen, und die Wahl zwischen ihnen ist eine Kostenfrage im Sinne von Kapitel 4.

Mechanismus	Wann im Kontext	Wofür	Dauerkosten
Rules	immer	Regeln, die für jede Aufgabe gelten	die gesamte Datei, bei jeder Anfrage
Skills	bei Bedarf	Abläufe und Wissen für bestimmte Aufgaben	nur die Beschreibung
MCP	immer	Zugriff auf fremde Systeme	alle Werkzeugbeschreibungen
Subagenten	eigener Kontext	abgegrenzte Nebenaufgaben mit viel Zwischenmaterial	nur der Bericht

Als Entscheidungshilfe: Gilt es immer? Dann Rule. Gilt es manchmal, dafür ausführlich? Dann Skill. Braucht der Agent Zugriff auf ein anderes System? Dann MCP. Entsteht viel Zwischenmaterial, das niemand später braucht? Dann Subagent.

Das Retrieval aus Kapitel 7 fehlt in dieser Tabelle mit Absicht: Es ist kein fünfter Mechanismus, sondern kommt über einen der vier herein. Üblicherweise als MCP-Server, der eine Suche über die Wissensbasis als Werkzeug anbietet, gelegentlich als Skill, der beschreibt, wie man sie abfragt. Der Agent entscheidet dann je Aufgabe, ob er sucht oder greppt.

Mehrere Werkzeuge, eine Quelle

In einem Team arbeitet selten jemand mit demselben Werkzeug wie alle anderen, und jedes davon sucht seine Regeln und Skills woanders. Wer daraufhin dieselben Inhalte drei- oder viermal ablegt, hat nach zwei Monaten vier Fassungen, die auseinandergelaufen sind, und niemand weiß, welche der Agent gerade gelesen hat. Der Ausweg ist derselbe wie überall in der Softwareentwicklung: eine Quelle, der Rest verweist darauf.

Andere Dateien einlesen

Für Regeldateien gibt es dafür keinen gemeinsamen Standard, sondern je Werkzeug eine eigene Lösung.

Werkzeug	Mechanismus
Claude Code	`@pfad/zur/datei` in `CLAUDE.md`, rekursiv bis vier Ebenen tief
`AGENTS.md` (Spezifikation)	kein Import. Nur Verschachtelung: die nächstgelegene Datei im Verzeichnisbaum gilt
OpenCode	Feld `instructions` in `opencode.json`, mit Glob-Mustern und URLs
GitHub Copilot	keine Importe; stattdessen `*.instructions.md` mit `applyTo` im Frontmatter

Bei Claude Code sieht das so aus:

Siehe @README für den Überblick und @package.json für die Befehle.

- Git-Ablauf: @docs/git-workflow.md
- Persönliches über Worktrees hinweg: @~/.claude/meine-vorlieben.md

Drei Details entscheiden darüber, ob das funktioniert. Relative Pfade lösen sich relativ zur importierenden Datei auf, nicht zum Arbeitsverzeichnis. Ein @ innerhalb von Backticks oder eines Code-Blocks wird nicht als Import gelesen, was praktisch ist, wenn man einen Pfad bloß erwähnen will. Und ein Import, dessen Ziel außerhalb des Arbeitsverzeichnisses liegt, etwa aus dem Benutzerverzeichnis, löst beim ersten Mal eine Rückfrage aus: Sie sollen sehen, was jemand anderes in ein geteiltes Repository committet hat.

Damit lässt sich auch die Lücke schließen, die im Vergleich in Kapitel 9 auffällt: Claude Code liest AGENTS.md nicht. Wer beides braucht, schreibt eine CLAUDE.md, die aus einer Zeile besteht, und hängt darunter an, was nur für dieses Werkzeug gilt:

@AGENTS.md

## Claude Code
Plan Mode für Änderungen unter src/billing/.

Ein ln -s AGENTS.md CLAUDE.md tut dasselbe, solange nichts Werkzeugspezifisches dazukommt. Unter Windows braucht ein Symlink allerdings erhöhte Rechte, weshalb im Team der Import die verlässlichere Wahl ist.

Bei Skills gibt es einen Standard

Der Wildwuchs an Verzeichnissen täuscht darüber hinweg, dass das Format längst vereinheitlicht ist. Der Standard heißt Agent Skills und wird unter dem Dach der Agentic AI Foundation der Linux Foundation gepflegt, mitgegründet unter anderem von Anthropic, Block und OpenAI. Eine SKILL.md mit name und description im Frontmatter sieht überall gleich aus und läuft ohne Änderung in jedem dieser Werkzeuge.

Uneinheitlich ist nur, wo gesucht wird.

Werkzeug	Sucht in
Claude Code	`.claude/skills/`, `~/.claude/skills/` — und sonst nirgends
OpenCode	`.opencode/skills/`, `.claude/skills/`, `.agents/skills/`
GitHub Copilot	`.github/skills/`, `.claude/skills/`, `.agents/skills/`
Codex	`.agents/skills/`

Zwei Muster fallen ins Auge. .agents/skills/ ist der neutrale Ort, auf den sich die neueren Werkzeuge verständigt haben. Und .claude/skills/ ist der verbreitetste Ort, weil ihn außer Codex alle mitlesen. Claude Code ist derzeit das einzige der vier, das ausschließlich sein eigenes Verzeichnis kennt.

Daraus ergibt sich ein Vorgehen, das mit einem Befehl auskommt: den Skill einmal ablegen, die übrigen Orte per Symlink daraufzeigen lassen.

# The source, stored tool-neutrally
mkdir -p .agents/skills/api-endpoint
$EDITOR .agents/skills/api-endpoint/SKILL.md

# The bridge for Claude Code, one symlink per skill
mkdir -p .claude/skills
ln -s ../../.agents/skills/api-endpoint .claude/skills/api-endpoint

Claude Code folgt einem solchen Symlink ausdrücklich und lädt den Skill auch dann nur einmal, wenn dasselbe Ziel über mehrere Wege erreichbar ist. Wer die Windows-Frage im Team umgehen will, dreht die Richtung um: die echten Dateien nach .claude/skills/, das ohnehin von den meisten mitgelesen wird, und einen einzigen Symlink für Codex.

Was daraus folgt

Eine Quelle, der Rest verweist. Kopien driften auseinander, und der Unterschied fällt erst auf, wenn zwei Personen unterschiedliche Ergebnisse bekommen.
Die description ist auch hier der Auslöser. Sie wirkt über Werkzeuggrenzen hinweg unverändert, weil sie Teil des Standards ist.
Prüfen statt hoffen. Claude Code zeigt mit /context an, welche Regeldateien tatsächlich geladen wurden. Ein Import, der still nicht greift, weil er versehentlich in einem Code-Block steht, fällt sonst monatelang niemandem auf.

Subagenten

Wenn eine Nebenaufgabe viel Kontext erzeugt, aber wenig Ergebnis liefert, lohnt es sich, sie auszulagern. Ein Subagent ist ein eigener Agentenlauf mit eigenem Kontext, der eine abgegrenzte Aufgabe erledigt und nur das Ergebnis zurückgibt.

Das Standardbeispiel ist Recherche: „Finde heraus, wo in diesem Repository die Sitzungsverwaltung implementiert ist.” Der Subagent liest dabei dreißig Dateien; im Hauptkontext landen drei Zeilen Antwort statt dreißig Dateien.

Das lohnt sich, wenn die Aufgabe unabhängig ist und viel Zwischenmaterial produziert. Es lohnt sich nicht bei allem, was man in fünf Werkzeugaufrufen selbst erledigen kann: Jeder Subagent muss seinen Kontext neu aufbauen, berichtet zurück, und der Hauptagent liest den Bericht. Diese Kosten fallen dreimal an, bevor irgendetwas passiert ist.

MCP: Werkzeuge als Standard

Bis 2024 hat jedes Werkzeug seine Integrationen selbst gebaut. Das Model Context Protocol (MCP) standardisiert das: Ein MCP-Server stellt Werkzeuge und Ressourcen über ein definiertes Protokoll bereit, jeder MCP-fähige Agent kann sie nutzen.

flowchart LR
  A[Agent] -->|MCP| B[MCP-Server GitLab]
  A -->|MCP| C[MCP-Server Datenbank]
  A -->|MCP| D[MCP-Server Dokumentation]
  B --> E[Issues, Merge Requests]
  C --> F[Schema, Abfragen]
  D --> G[interne Wiki-Seiten]

Der praktische Nutzen liegt darin, dass ein Agent damit an Systeme herankommt, die er sonst nicht kennt: das Ticketsystem, das Datenbankschema, die interne Dokumentation. Der praktische Preis ist doppelt. Jeder angebundene Server bringt seine Werkzeugbeschreibungen in den Kontext, und zwanzig Server können mehrere zehntausend Tokens kosten, bevor die erste Frage gestellt ist. Und jeder Server ist Code von jemand anderem, der in Ihrem Namen handelt. Ein MCP-Server ist eine Abhängigkeit mit Zugriffsrechten, und er gehört mit derselben Sorgfalt geprüft wie ein npm-Paket, das Sie in die Produktion nehmen.

Wo Agenten scheitern

Auch das gehört in ein Lehrbuch. Die Muster wiederholen sich.

Sie sehen nicht, was Sie sehen. Der Agent kennt das laufende System nicht, den Screenshot nicht, den Kunden nicht, und die drei Sätze im Gespräch von gestern schon gar nicht. Was nicht im Kontext steht, existiert nicht.

Sie halten sich für fertig. Ohne maschinelles Erfolgskriterium meldet ein Agent „erledigt”, wenn der Code plausibel aussieht. Deshalb Kapitel 11.

Sie bauen zu viel. Fehlerbehandlung für unmögliche Fälle, Abstraktionen für einen einzigen Anwendungsfall, Hilfsfunktionen, die niemand braucht. Das Gegenmittel ist eine Aufgabenbeschreibung mit Nicht-Zielen (Kapitel 10).

Sie verrennen sich. Wenn ein Ansatz nicht funktioniert, versucht ein Agent Variante um Variante desselben Ansatzes, statt einen Schritt zurückzugehen. Nach zwei erfolglosen Runden ist es an Ihnen, die Sitzung abzubrechen und die Aufgabe anders zu stellen. Eine dritte Runde derselben Sache ist verlorenes Geld.

Große Umbauten in einem Zug. Ein Auftrag über zwanzig Dateien ergibt eine Änderung, die niemand reviewen kann und die niemand zurückrollen will. Kleine Schritte mit eigenen Commits sind hier kein Stilthema, sondern die Voraussetzung dafür, dass das Ergebnis überprüfbar bleibt.

Häufige Stolperfallen

Glauben, das Modell führe die Werkzeuge aus. Das tut das Harness, und dort liegt jede Sicherheitsentscheidung.
Auf einem schmutzigen Arbeitsbaum arbeiten lassen. Ohne Commit davor kann man nicht sauber zurück.
Alle Rückfragen abschalten, weil sie nerven. Die Antwort ist eine sinnvolle Abstufung, nicht das Abschalten.
Ohne Tests und ohne Typen arbeiten. Der Agent hat dann keine Rückmeldung und rät wieder.
Zwanzig MCP-Server anbinden. Zehntausende Tokens Grundlast und zwanzig fremde Abhängigkeiten mit Zugriffsrechten.
Eine Regeldatei mit vierhundert Zeilen schreiben. Sie wird verwässert; kurz und konkret wirkt besser.
Eine Regel für eine Sperre halten. Rules sagen, was erwünscht ist. Verbindlich wird etwas erst durch Berechtigungen, Hooks, Typen, Tests und CI.
Veraltete Regeln stehen lassen. Der Agent befolgt sie. Eine falsche Regel ist schlimmer als eine fehlende.
Alles in die Rules schreiben, was ein Skill sein sollte. Die lange Anleitung liegt dann in jeder Sitzung im Kontext, auch in den neun von zehn, in denen es um etwas anderes geht.
Einen Skill nach seinem Inhalt beschreiben statt nach seinem Anlass. Er wird dann nie geladen, und niemand merkt, dass er existiert.
Dieselben Regeln für jedes Werkzeug einzeln kopieren. Nach zwei Monaten gibt es vier Fassungen, und keine ist die richtige.
Einen Import für eine Kontextersparnis halten. Die importierte Datei liegt vollständig im Kontext, genau wie vorher.
Die dritte Runde am selben Fehler starten. Nach zwei Fehlversuchen liegt der Fehler in der Aufgabenstellung.
Zwanzig Dateien in einem Auftrag ändern lassen. Nicht reviewbar, also faktisch ungeprüft.

Lernergebnisse: Was Sie nach diesem Kapitel können sollten

Erklären: die drei Stufen Vervollständigung, Chat und Agent unterscheiden und benennen, wo sich die Kontrolle jeweils befindet.
Erklären: die Agentenschleife beschreiben und begründen, warum das Modell selbst keine Werkzeuge ausführt.
Anwenden: ein Werkzeug mit Beschreibung und Parameterschema so definieren, dass ein Modell es zum richtigen Zeitpunkt aufruft.
Beurteilen: Werkzeuge nach Umkehrbarkeit einstufen und eine Berechtigungsabstufung für ein Projekt festlegen.
Anwenden: eine Agentenumgebung so absichern, dass ein Fehlverhalten auf das Projektverzeichnis begrenzt bleibt.
Erklären: erklären, warum die Rückmeldeschleife über die Ergebnisqualität entscheidet, und die vier Bestandteile einer guten Schleife benennen.
Anwenden: eine Regeldatei schreiben, die Befehle, Architekturregeln und Konventionen knapp festhält, und sie im passenden Geltungsbereich ablegen.
Erklären: begründen, warum Rules keine Durchsetzung sind, und benennen, mit welchen Mitteln eine Vorgabe tatsächlich verbindlich wird.
Anwenden: einen Skill mit SKILL.md, Namen und auslösender Beschreibung anlegen und einen wiederkehrenden Ablauf darin festhalten.
Erklären: Progressive Disclosure erklären und daraus ableiten, warum die Beschreibung eines Skills über seine Verwendung entscheidet.
Beurteilen: für eine gegebene Information entscheiden, ob sie in die Rules, in einen Skill, hinter einen MCP-Server oder in einen Subagenten gehört, und die Entscheidung über die Kontextkosten begründen.
Anwenden: Regeln und Skills so ablegen, dass mehrere Werkzeuge dieselbe Quelle lesen, und begründen, warum ein Import die Kontextkosten nicht senkt.
Beurteilen: entscheiden, wann ein Subagent sinnvoll ist und wann er nur Kosten erzeugt.
Beurteilen: Nutzen und Risiko eines MCP-Servers gegeneinander abwägen und die Abwägung begründen.