Agentic Engineering — Implementierungs-Checkliste

Inhalt

Eine CLAUDE.md / AGENTS.md im Repo-Root anlegen. Mit 10 Zeilen beginnen.
Vier Punkte abdecken:
- Stack und Versionen
- Konventionen (Ordnerstruktur, Benennung, tatsächlich verwendete Muster)
- Harte Regeln, die der Agent niemals brechen darf (verbotene Pakete, Umgang mit Secrets, Schichtung)
- Workflow, der vor der Code-Generierung einzuhalten ist
Jedes Mal eine neue Regel ergänzen, wenn der Agent etwas tut, das sich nicht wiederholen soll.
Die Tools auflisten, die der Agent aufrufen darf, und wann welches zu verwenden ist (APIs, Skripte, DB-Schemata).
Architekturentscheidungen selbst treffen; den Agenten implementieren, nicht wählen lassen.

Festlegen, was statisch (immer geladen) vs. dynamisch (bei Bedarf geladen) ist:
- Statisch: Rule-Dateien, Systemanweisungen, globales Gedächtnis
- Dynamisch: Skills, Tool-Ergebnisse, abgerufene Dokumente, jüngerer Verlauf
Statischen Kontext kurz und signalreich halten. Alles streichen, was der Agent nicht bei jedem Aufruf braucht.
Wiederholbares Know-how in Skills auslagern, die nur bei passendem Task geladen werden.
Nie das gesamte Repo in den Prompt einfügen. Nur das Relevante abrufen.

Pro Task einen Modus wählen:
- Conductor (Echtzeit, im Editor) für komplexe Logik, Debugging, unbekannte Codebasen
- Orchestrator (async, delegieren und reviewen) für Bug-Fixes, Migrationen, Testgenerierung
Pro Task den Agenten-Standort wählen:
- Editor-Agent — Inline-Bearbeitungen und Vorschläge
- Terminal-Agent — dateiübergreifende Arbeit, Ausführen und Reagieren
- Hintergrund-Agent — Aufgaben mit Absatz-Spezifikation, von denen man sich abwenden kann
Code-Generierung innerhalb einer Sandbox ausführen, nur mit zugelassenen Tools.
Die letzten 20 % selbst erledigen: Randfälle, Fehlerbehandlung, Integrationspunkte, Geschäftslogik. Code, der „richtig aussieht", ist der Ort, an dem sich die Bugs verstecken.

Den Agenten als Erst-Reviewer nutzen (Bugs, Stil, Sicherheit, Performance).
Jede Zeile, die ausgeliefert wird, reviewen:
- Cleveren Code skeptisch betrachten
- Prüfen, ob importierte Pakete tatsächlich existieren
- Fehlerbehandlung auf realistische Ausfälle überprüfen
Hooks an Commit-/Edit-Punkten hinzufügen (z. B. Commits mit hartkodierten Secrets blockieren).
Observability einschalten: Traces, Eval-Ergebnisse, Token/Latenz/Kosten, Drift.
Den Agenten auf Legacy-Arbeit ansetzen, die bisher vermieden wurde: Refactorings, Migrationen, veraltete APIs.

Gesamtbetriebskosten messen, nicht nur Geschwindigkeit.
Erstversuchs-Erfolgsrate durch eine präzise Rule-Datei erhöhen, um Retry-Schleifen zu vermeiden.
Modelle nach Task routen:
- Frontier-Modelle für Architektur und schwierige Implementierungen
- Günstige Modelle für Testgenerierung, Review, CI-Monitoring
Dynamischen Kontext und Skills nutzen, damit nur die tatsächlich benötigten Tokens bezahlt werden.

Festlegen, was gebaut wird:
- Ein Skript — der Agent ist der Endpunkt
- Ein Produkt für echte Nutzer — der Agent braucht ein Substrat
Für Produkte hinzufügen: persistentes Gedächtnis, eingeschränkte Berechtigungen, Eval-Abdeckung in CI, vollständiges Tracing von Läufen.
Ein Skills-Bundle nutzen, damit der vorhandene Coding-Agent Build → Evaluieren → Deployen → Beobachten übernimmt.
Bei Multi-Agenten-Setups: Koordination über Shared State, MCP für Tools, A2A für Delegation.

Rule-Dateien, Prompts, Eval-Suites und Skills versionieren. In PRs reviewen. Eigentümer benennen.
Auslieferung an eine bestandene Eval-Suite mit klarem Rubric knüpfen, nicht an eine funktionierende Demo.
Reviewer darin schulen, wie generierter Code versagt.
Die Grenze Prototyp vs. Produktion explizit machen (welche Repos, Branches, Umgebungen).
Das Harness einmal aufbauen und kontinuierlich verfeinern.
Nach Urteilsvermögen einstellen und befördern: Spezifikation, Evaluation, Architektur.