Agents erledigen die Engineering-Arbeit unter einem geschriebenen Plan

Geben Sie dem Agent das Repository statt eines Prompts: die Conventions-Datei, an die er sich hält, die Expert Subagents, denen je eine Domäne gehört, die Tools, die er aufrufen darf, und einen Plan, der so konkret geschrieben ist, dass eine falsche Annahme schon auf dem Papier auffällt. Er arbeitet in Ihrem Repository, unter Ihren Branch-Regeln und Ihrem Zugriffsmodell.

Was er meldet, prüfen Sie, indem Sie den Check laufen lassen: den Build, die Tests, das eingespielte Delta, den Digest auf der Box. Der Befehl und seine Ausgabe reisen mit der Arbeit mit, eine Behauptung ist nie der Beleg. Was unbeaufsichtigt läuft und was auf einen Menschen wartet, wird pro Environment vor dem ersten Lauf festgelegt.

Ein Claude Code Harness, das aus jeder Session lernt

Schließen Sie jede Session ab, indem Sie das Gelernte zurück in das Harness schreiben: Eine Korrektur wird zur Regel, ein Ablauf wird zum Skill mit seinen Failure Modes daneben, ein Incident wird zur Zeile im Lessons Log neben dem Code. Expert Subagents besitzen ihre Domänen, und Guard Hooks setzen die Grenzen durch, statt dass ein Reviewer sie im Kopf behalten muss.

Verteilen Sie es in beide Richtungen. Was zu dieser Codebase gehört, bleibt im Repository; was allgemein gilt, wandert in die Library, aus der jedes andere Projekt liest. So wird eine einmal bezahlte Falle vererbt statt neu entdeckt. Das Harness geht als reiner Text mit der Arbeit mit, den die eigenen Leute des Kunden öffnen, ausführen und ändern können.

Das günstigste Modell, das die Qualitätslatte erreicht

Fahren Sie jeden Teil der Arbeit auf dem günstigsten Modell, das seine Qualitätslatte noch erreicht, und halten Sie die teuren Modelle für die Aufgaben frei, die echtes Urteilsvermögen brauchen. Die Monatsrechnung folgt dann dem, was getan wurde, und nicht dem Namen auf dem Modell.

Halten Sie jede Entscheidung mit den Belegen dahinter fest, auch die Konfigurationen, die gescheitert sind, damit das nächste Projekt eine geprüfte Entscheidung erbt. Mehrere Anbieter decken dieselbe Arbeit zu unterschiedlichen Preisen ab, und die Aufstellung, welches Modell was macht, liegt im eigenen Repository des Kunden, wo seine Leute sie ändern können.

3 Lenses
parallele Code-Review-Agents bei jeder Änderung, aus dem Harness des Repositories selbst
12:32.5
fertig geschnittenes In-House-Promo-Video, fünf geskriptete Akte, Narration pro Segment
83
Themen in der Business-User-Class, gebaut mit demselben Harness
25h
zwei Slots healthy und trotzdem nicht erreichbar, der Incident hinter den Digest-Checks

Das Agentic SW Engineering Playbook

Analyse & Plan 3 Schritte
01

Das Estate lesen, bevor Sie Autonomie vergeben

Fahren Sie die Repository-Analyse als Skill, der festhält, was das Repository ist: seine Deployment-Form, seine Adressen pro Environment oder Slot, seine Datenbanken und seine Authentication. Einen unbekannten Wert schreiben Sie als TBD, und statt eines Secrets nennen Sie die git-ignorierte Datei, die es hält. Am Ende steht ein README, das die nächste Session liest.
02

Jede Rolle an das Modell routen, das sie braucht

Teilen Sie die Arbeit in Rollen und schneiden Sie jede auf ihren eigenen Auftrag und ihr eigenes Tool-Set zu. Das ausgelieferte Content Team fährt Writer, Reviewer, Translator, Researcher und Publisher als eigene Claude Code Subagents, und ein strukturiertes Reviewer-Verdict treibt eine Revision Loop mit höchstens zwei Durchgängen. Den vollen Context geben Sie dort aus, wo Urteilsvermögen gebraucht wird, und jede Loop bekommt eine Abbruchbedingung.
03

Planen, bevor der Agent handeln darf

Geben Sie jedem Schritt dieselbe Form: Überblick, ein offener Research- und Planning-Prompt, das Ergebnis, ein Rezept zum Kopieren, dann das erwartete Outcome. So sind die 83 Demo-Schritte der Business-User-Class geschrieben. Für das Anlegen von Issues gilt dieselbe Disziplin: zuerst ein begrenzter Scan des betroffenen Codes, damit das eingetragene Issue echte Dateien nennt.
Den Harness Layer verdrahten 3 Schritte
04

Das Harness als lauffähiges Artifact ausliefern

Liefern Sie das Harness aus, das das Material lehrt: Expert Sub-Agents, ein paralleles Code-Review-Agent-Team mit drei Lenses, Guard Hooks und Slash Commands für das Scaffolding, alles live in den Lektionen im Einsatz. Bauen Sie die AI-Konfiguration so um, dass jede Anweisung an genau einer Stelle steht, und übergeben Sie das Harness lauffähig als Teil des Repositories.
05

Die Failure Modes als Skills festschreiben

Schreiben Sie jeden Failure Mode als ausführbare Regel in den Skill. Ein Zonefile-Import ersetzt jedes Record Set: Ein Record, der in der Datei fehlt, ist ein gelöschter Record, und deshalb ist ein Snapshot der Live-Zone vor dem Schreiben Pflicht. Nennen Sie die git-ignorierte Credential-Datei statt der Credential selbst, und liefern Sie einen wiederkehrenden Betriebsablauf als Microsoft 365 Copilot Cowork Skills aus, die der Aufgabenverantwortliche ohne Terminal startet.
06

Die Hooks durchsetzen lassen

Legen Sie die Regeln des Harness in Guard Hooks: einer begrenzt die Instruction-Datei auf 90 Zeilen, einer druckt bei jedem Prompt die Skill-Liste, damit ein vorhandener Skill auch zündet, und hinter beiden sitzt ein Verification Gate. Die Variante über lange Zeiträume läuft als geplanter Workflow, der die Live-Seiten über PageSpeed Insights misst, mit Read-Only-Permissions, einer Network Allowlist und begrenztem Output.
Mit Agents bauen & sicher ausliefern 2 Schritte
07

Mit Agents auf einer Konfiguration bauen, die hält

Halten Sie fest, welche Orchestration-Konfiguration funktioniert und welche bricht. Ein Magentic Team auf Microsoft Foundry scheitert an der Responses API mit einem Manager-Ledger-Fehler; fahren Sie es auf dem Chat Completions Client, ohne Modell mit Anthropic-Protokoll in der Loop. Auf dieser Basis liefert ein Lauf aus einem freien Text-Prompt den Artikel, die deutsche Variante, die Social Atoms und ein Publish Manifest.
08

Jeder Deploy beweist sich selbst

Build und Push laufen parallel, die Arbeit auf der Box reihen Sie über ein File Lock ein, denn gleichzeitige Layer Pulls zerstören einander den containerd Ingest. Vergleichen Sie den gepushten Digest mit dem Image auf der Box, den laufenden Container mit diesem Image, und prüfen Sie, ob der öffentliche Hostname antwortet. Container Health, DNS und der Edge Proxy können jeder für sich korrekt sein, während die Site steht: Das hat einmal 25 Stunden gekostet.
Verbessern & skalieren 2 Schritte
09

Ein Lessons Log neben dem Code mitführen

Führen Sie ein Lessons Log neben dem Code und schreiben Sie jeden Incident als Regel hinein: ein LFS-Checkout, der jede Videoaufnahme durch Pointer-Dateien ersetzt hat, die Credit-Routing-Einstellung, die das Budget für die Avatar-Narration freigegeben hat, das Prompting-Rezept für das Image-Modell, das generierte Frames von verunstaltetem Text freihält. Die Konsolidierung von Repositories folgt derselben Regel: Provenienz pro Pfad festhalten und laufende Abhängigkeiten dort lassen, wo sie laufen.
10

Berichten, was live ist, verrechnen, was erfasst wurde

Lesen Sie Unit- und End-to-End-Ergebnisse aus dem Output der Test Reporter pro Anwendung, und benennen Sie die ungetesteten Flächen als Lücken. Wo es keinen Reporter-Output gibt, steht der Grund am Bildschirm. Die Verrechnung bauen Sie aus dem erfassten Time Ledger neu auf, damit hinter jeder Zahl auf der Rechnung eine Session steht.

Häufige Fragen

Entsteht dabei nur Anwendungscode?
Dasselbe Harness erzeugt Kurs- und Class-Material zu jedem Thema, über eine Factory, die Folien mit Overflow-Prüfung setzt, Narration pro Folie generiert, kommentierte Fotos zusammensetzt und Avatar-Video rendert. Multimedia entsteht über einen Media Service mit zwei Schnittstellen: über HTTP für das, was ein Mensch klickt, und über MCP für das, was ein Modell aufruft. Es entsteht auch Output für den Betrieb, darunter die Verrechnung, neu aufgebaut aus dem erfassten Time Ledger.
Wie wird das Verhalten eines Agents in einem echten Repository begrenzt?
Über Hooks und Gates. Ein Guard Hook begrenzt die Instruction-Datei auf 90 Zeilen, damit sie kurz genug bleibt, um bei jedem Turn gelesen zu werden, ein zweiter druckt bei jedem Prompt die Skill-Liste, und dahinter sitzt ein Verification Gate. Wo ein Tool nicht umkehrbar ist, kommt ein Approval Gate davor: Die Übung zum governed MCP übergibt einen laufenden Server mit sechs Tools, davon einem Destructor, und verlangt Boundary Rules plus einen Stresstest gegen adversariale Prompts.
Darf ein Modell direkt in ein laufendes Geschäftssystem schreiben?
Ein Draft Tool liefert ein interaktives Formular zurück, das im Chat Client gerendert wird, vorbefüllt mit dem, was das Modell vorgeschlagen hat. Das Modell selbst hat kein Schreib-Tool, und das Speichern läuft über einen eigenen Weg, den die Person vor dem Formular auslöst. Read-only-Integrations bleiben read-only, und ein Skill nennt die git-ignorierte Datei, die einen Wert hält, statt des Werts.
Wie beweist ein Deploy, dass tatsächlich etwas live gegangen ist?
Er vergleicht den eben gepushten Digest mit dem Image auf der Box, vergleicht die Image-Id des laufenden Containers mit diesem Image und schließt mit der Prüfung, ob der öffentliche Hostname antwortet; einen unveränderten Digest meldet er als bewusste No-op. Dieselben Prüfungen gibt es auch außerhalb eines Deploys über die Health- und Identity-Endpoints, die Frage lässt sich also jederzeit stellen.