Was ist Agentic Engineering?

Die Definition

Agentic Engineering ist die Disziplin, Software-Entwicklungs-Workflows zu gestalten, in denen KI-Agenten eigenständig umfangreiche Aufgaben erledigen: vom Lesen eines Tickets bis zum Erstellen eines CI-grünen Pull Requests, ohne dass ein Mensch jeden Schritt steuert.

Das Wort "Engineering" ist bewusst gewählt. Es ist kein kreativer Trick. Es ist keine Chat-basierte Abkürzung. Es ist ein Satz wiederholbarer Praktiken: strukturierte Kontextdateien, spezialisierte Agenten, Memory-Architektur, Review-Pipelines und Orchestrierungsmuster. Du gestaltest es, du pflegst es, und es skaliert über Zeit.

Ich begann damit, das im Jahr 2026 bei Kleinanzeigen aufzubauen, wo ich als Staff Engineer arbeite. Die erste Session, die einen echten autonomen PR produzierte, brauchte acht Sessions Infrastrukturarbeit. Danach hat sich das Return on Investment dauerhaft verändert. Diese Reise ist dokumentiert in The Spark, dem Post, der das alles gestartet hat.

Unterschied zu KI-gestütztem Coding

KI-gestütztes Coding bedeutet: du schreibst Code, und eine KI hilft. Tab-Completion. Inline-Vorschläge. Die gelegentliche "Schreib diese Funktion um." Du sitzt an der Tastatur. Die KI beschleunigt deine Hände.

Agentic Engineering kehrt dieses Modell um. Der Agent sitzt an der Tastatur. Du setzt das Ziel, definierst die Rahmenbedingungen, reviewst den Output und korrigierst die Richtung. Der Agent liest die Codebase, plant die Implementierung, schreibt den Code, führt Tests aus, behandelt Fehler und erstellt den PR.

Das ist kein Stilunterschied. Es ist ein struktureller. In KI-gestütztem Coding ist deine Ausgaberate durch deine Tipp- und Denkgeschwindigkeit begrenzt. In Agentic Engineering ist sie durch deine Fähigkeit begrenzt, zu spezifizieren, zu reviewen und zu orchestrieren. Diese Grenze ist anders. Sie skaliert anders. Sie erfordert andere Fähigkeiten.

Drei Wochen verbrachte ich damit, mit Copilot Features durchzutab-completen, bevor ich merkte, dass ich jede Zeile Logik selbst schrieb. Die KI füllte Syntax aus. Ich machte das gesamte Denken. Der Post From Beta Tester to Agentic Engineer beschreibt diese Erkenntnis genau.

Versus Prompt Engineering

Prompt Engineering ist die Kunst, Eingaben zu schreiben, die bessere Ausgaben aus einem Sprachmodell erzeugen. Das ist wichtig. Eine schlecht formulierte Spezifikation produziert schlechten Agent-Output. Aber es ist nicht das Unterscheidungsmerkmal.

Ein Kollege bat mich einmal um meinen Prompt. Ich teilte ihn. Drei Sätze. Er war enttäuscht. Der Prompt war nie die Fähigkeit. Der Post Your Prompt Is Not the Point erklärt warum.

Die Fähigkeit liegt in allem rund um den Prompt: die CLAUDE.md-Kontextdateien, die dem Agenten dauerhaftes Wissen über deine Codebase geben, die Memory-Architektur, die Entscheidungen über Sessions hinweg speichert, die Review-Pipelines, die Fehler abfangen, die Orchestrierungslogik.

Die Kernpraktiken

1. Spezialisierte Agenten statt Generalisten

Ein Generalist kann alles. Er kann auch alles gleichzeitig schlecht machen. Wenn ein Agent Instruktionen für jede Domäne lädt, die er möglicherweise berühren wird, füllt sich das Kontextfenster auf, bevor die eigentliche Arbeit beginnt.

Die Lösung ist Spezialisierung. Ein Kotlin-Implementer, der nur Spring Boot-Konventionen kennt. Ein Git-Agent, der nur Commit-Muster kennt. Ein PR-Handler, der nur weiß, wie man eine kohärente Beschreibung schreibt und Reviewer zuweist.

Ich bin von einem Generalisten zu 18 Spezialisten in fünf Tagen gegangen. Siehe From 1 to 18: Building an Agent Army.

2. CLAUDE.md-Kontextdateien

Die wichtigste Datei in jeder agentischen Codebase ist CLAUDE.md. Es ist eine persistente Kontextdatei, die der Agent zu Beginn jeder Session liest. Sie enthält das, was du einem neuen Teammitglied am ersten Tag erklären würdest: Namenskonventionen, Testmuster, benötigte Build-Flags, wo Konfigurationsdateien liegen, welche Entscheidungen bereits getroffen wurden.

Ohne CLAUDE.md beginnt jede Session kalt. Mit ihr kommt der Agent bereits orientiert an.

3. Drei-Tier-Memory-Architektur

Sessions enden. Kontext wird zurückgesetzt. Das Wissen, das der Agent über deine Codebase aufgebaut hat, die Entscheidungen, die ihr zusammen getroffen habt: alles weg, wenn du kein System zum Bewahren designst.

Das Muster, das ich verwende, hat drei Ebenen: eine STATUS.md-Datei als Arbeitsgedächtnis, tägliche Journals als Append-only-Archiv und destillierte Fakten, die Muster aus mehreren Sessions erfassen. Volle Kontextwiederherstellung in unter 60 Sekunden. Vollständiges Design: Three-Tier Memory.

4. Skills statt Agenten (die aktuelle Frontier)

Als Claude Code Skills mit geforkten Ausführungskontexten ausgeliefert hat, wurde die 18-Agenten-Architektur, die ich aufgebaut hatte, teilweise obsolet. Skills können das meiste, was benutzerdefinierte Agenten taten, mit weniger Overhead und mehr Komposierbarkeit.

Der ehrliche technische Kassensturz: Skills Ate My Agents (And I'm Okay With That). Das Fazit: Agenten sind nicht tot, sie sind degradiert. Skills sind das Was. Agenten sind das Wie.

5. Review-Pipelines

Autonome Agenten brauchen Review-Gates. Nicht weil sie unzuverlässig sind, sondern weil die Einsätze real sind. Meine Pipeline umfasst: einen Code-Reviewer-Agenten, einen KI-Code-Review-Schritt in GitHub Actions und ein menschliches finales Genehmigungsgate vor jedem Merge.

Der GitHub-Actions-Reviewer ist besonders interessant, weil er seinen eigenen Deployment-PR automatisch reviewed hat. Er fand eine echte Sicherheitslücke: The Reviewer That Reviewed Itself.

6. Orchestrierung und autonome Pipelines

Mein aktuelles System verarbeitet den vollen Ticket-Lebenszyklus: Jira-Ticket-Analyse, Implementierungsplanung, Code-Änderungen, Test-Ausführung, Code-Review, PR-Erstellung, CI-Monitoring und Slack-Benachrichtigung.

Der Auslöser: eine Slack-Nachricht. Das Ergebnis: ein CI-grüner PR, bereit für Human Review, 21 Minuten später. Siehe One Slack Message. Two Hours of Work..

7. Sandboxing und harte Grenzen

Jede Grenze in einer CLAUDE.md ist ein Vorschlag. Weiche Einschränkungen. Die Post From Soft Trust to Hard Walls erklärt, warum weiche Einschränkungen nicht ausreichen und wie Docker-Sandboxing aussieht.

8. Token- und Kontextkostenmanagement

Kontextqualität verschlechtert sich mit zunehmender Kontextlänge. Ich habe meinen Atlassian-MCP-Server deaktiviert, nachdem ich festgestellt hatte, dass er vor meinem ersten Prompt 22.000 Token pro Session verbrannte. Sieben Shell-Skripte ersetzten ihn mit null Startup-Kosten. Die Analyse: The 22,000 Token Tax.

Was sich für dein Team ändert

Die erste Änderung ist das, was Entwickler tun. Weniger Hände-an-der-Tastatur, mehr Spezifikationen schreiben, reviewen und Richtung vorgeben. Senior Engineers, die gut im klaren Denken sind, werden wertvoller, nicht weniger wertvoll.

Die zweite Änderung ist das Wesen von Fortschritt. Du verbringst mehrere Wochen damit, Infrastruktur aufzubauen, bevor du ein einziges autonomes Ticket auslieferst. Die meisten Teams geben auf, bevor sie die Schwelle erreichen, wo sich die Investition auszahlt.

Die dritte Änderung ist Geschwindigkeit. Nach der Schwelle steigt die Produktivität nicht um 10 oder 20 Prozent. Sie wechselt die Kategorie. Mein Repository hat in einer Woche 110 Pull Requests gemerged. Fast keinen Code davon habe ich selbst geschrieben. Der Post Stop Micromanaging Your Agents erklärt, wie das in der Praxis aussieht.

Wie du anfängst

Die Versuchung ist, sofort die komplette Pipeline aufzubauen. Tu das nicht.

Beginne mit einer Sache: Schreibe ein CLAUDE.md für dein Projekt. Füge deine Build-Befehle hinzu. Füge deine Namenskonventionen hinzu. Füge die drei Dinge hinzu, die du neuen Teammitgliedern immer erklären musst. Führe eine Session damit durch. Iteriere.

Schritt zwei: Lass den Agenten eine vollständige Aufgabe abschließen, ohne ihn zu unterbrechen. Wähle etwas Konkretes und Eingegrenztes. Ein Bug-Fix. Ein kleines Feature. Beobachte den Output. Korrigiere keine Fehler des Agenten, indem du übernimmst. Korrigiere sie, indem du den Kontext verbesserst, den er hatte.

Der Rest folgt aus diesen Schritten. Skills. Review-Pipelines. Orchestrierung. Sandboxing. Jedes davon wird offensichtlich, wenn du das Problem erreichst, das es löst.

Der schwierigste Teil ist nicht technisch. Es ist, lange genug in der Investitionsphase zu bleiben. Der Post The Walls That Taught Me More Than the Breakthroughs handelt von den unsichtbaren Decken auf jeder Ebene und wie man durch sie hindurchbricht.