Agentic Engineering bezeichnet den systematischen Ansatz, Software mit KI-Agenten zu entwickeln, wobei Architektur, Qualitätsprinzipien und Umgebungsgestaltung wichtiger sind als das Schreiben einzelner Prompts. Gute Prinzipien beschleunigen den Fortschritt, schlechte Prinzipien beschleunigen den Rückschritt. Spezialisierte Cleanup-Agenten übernehmen kontinuierlich Aufgaben wie Deduplizierung, Refactoring und Testabdeckung.
Das Wichtigste in Kürze
- Wenn du schlechte Prinzipien hast und KI anwendest, wirst du schneller schlechter; wenn du gute Prinzipien hast, wirst du schneller besser, weil KI den vorhandenen Kurs einfach beschleunigt.
- Agentic Engineering ersetzt Prompt-Engineering als zentrales Skill: Der eigene Prompt macht nur etwa 20 von 20.000 Tokens im Kontext aus, entscheidend ist die Konfiguration der Agentenumgebung.
- Ein dauerhaft laufender Cleanup-Agent, der nach jedem Change auf Deduplizierung, fehlende Tests und Qualitätsmerkmale prüft, ersetzt das manuelle Refactoring nach dem ersten Wurf.
- Fünf Entwickler, die alle gleichzeitig agentisch arbeiten, stehen sich auf den Füßen, weil Agenten sofort den gesamten Stack anfassen; kleinere, cross-funktionale Teams mit klar getrennter Architektur sind die Konsequenz.
- Beim Wechsel auf ein neues Modell lohnt es sich, alle bisherigen Skills und Konfigurationen wegzuwerfen, weil veraltete Einstellungen das neue Standardverhalten des Modells verschlechtern statt verbessern.
Vibecoding oder Agentic Engineering: warum der Begriff den Unterschied macht
Agentic Engineering beschreibt KI-gestützte Softwareentwicklung präziser als der populäre Begriff Vibecoding. Andrej Karpathy, der Vibecoding vor gut einem Jahr auf X geprägt hat, korrigierte sich später und bevorzugt nun selbst die Bezeichnung Agentic Engineering.
Der Unterschied steckt im Wort. Engineering bringt Architektur, Qualitätssicherung und Ingenieurswesen zurück in die Diskussion. Es geht nicht ums reine Erzeugen von Code, sondern um eine ingenieursmäßige Tätigkeit mit Prinzipien und Methode.
Das bestehende Wissen über Architektur, Paradigmen und Qualität verliert dadurch nicht an Wert. Es wird im Gegenteil wertvoller. Die Aufgabe verschiebt sich darauf, dieses Wissen zu systematisieren und in Agenten und ihre Konfiguration zu überführen, statt es nur in den Köpfen der Entwickler zu halten.
Warum der Prompt heute weniger entscheidet als gedacht
In agentischen Umgebungen macht die Formulierung des Prompts kaum noch den großen Unterschied. Klassisches Prompt-Engineering, das vor einem Jahr im Fokus stand, ist für die direkte Modellinteraktion noch relevant, in agentischen Setups verliert es an Gewicht.
Der Grund liegt im Kontext. Ein Agent verschickt über seinen System-Prompt bereits rund 20.000 Tokens, in denen er sich dem Modell vorstellt und seine Tools beschreibt: welche Dateien er lesen und bearbeiten kann. Ein eigener Prompt von 20 Tokens fällt dagegen kaum ins Gewicht.
Die eigentliche Aufgabe des Prompts ist es, dem Agenten zu ermöglichen, sich die nötige Information selbst zu beschaffen. Je besser die Umgebung konfiguriert ist, desto weniger muss im Prompt stehen. Bekannte Schwierigkeiten schreibt man in den Prompt, gelöste Schwierigkeiten gehören in die Konfiguration.
Reverse Engineering statt besserer Prompts
Der bessere Hebel ist nicht der optimierte Prompt, sondern die Beobachtung des Default-Verhaltens. Man startet bewusst mit einem schlechten Prompt ohne Konfiguration und schaut, wie sich das Modell verhält.
Aus dieser Beobachtung leitet sich die Korrektur ab. Statt zu fragen, wie ein besserer Prompt aussehen müsste, fragt man, was dem Agenten in seiner Kontextdatei oder seinen Tools gefehlt hat, damit er die Aufgabe auch mit dem schlechten Prompt allein gelöst hätte.
Das funktioniert über eine geführte Unterhaltung. Du steuerst den Agenten manuell nach, korrigierst seine Richtung, und wenn das Ergebnis am Ende stimmt, lässt du ihn die Unterhaltung auswerten: Wo lag er richtig, wo musste er nacharbeiten, wo hast du eingegriffen. Diese Erkenntnisse landen in der Konfigurationsdatei, damit dieselben Korrekturen beim nächsten Mal nicht erneut nötig sind.
Das Vorgehen ähnelt einer Retrospektive aus dem agilen Arbeiten. Man fragt, was gut lief und was schlecht, und hält die Kernessenz fest. Die Hersteller haben dieses Muster mittlerweile als Best Practice erkannt und in ihre Tools eingebaut, etwa als Kommando in Claude Code, das die Unterhaltung auswertet und die Erkenntnisse wegschreibt.
Eine Cleanup-Crew räumt auf, was der erste Wurf liegen lässt
Statt den Code beim ersten Wurf perfekt zu machen, übernehmen separate Agenten das Aufräumen im Hintergrund. Ein solcher Agent loopt durchgehend über alle Changes und sucht nach Konsolidierung und Vereinfachung.
Diese Arbeitsteilung lässt sich spezialisieren. Ein Agent prüft auf Security, ein anderer auf Qualitätsmerkmale, ein dritter macht ausschließlich Deduplizierung. Erkennt er, dass jemand ein neues Modalfenster gebaut hat, obwohl bereits eine Komponente existiert, baut er das zu einer Komponente um. Fehlt ein Test für eine neue Funktion, ergänzt er ihn.
Damit verschiebt sich der Anspruch. Es bleibt besser, von vornherein sauber zu bauen, aber das Feature muss beim ersten Durchgang nicht perfekt sein, wenn ein anderer Agent danach aufräumt. Das ähnelt dem üblichen Vorgehen vieler Entwickler, die erst etwas herausgehen lassen und danach refactorn, nur dass das Refactoring jetzt nicht mehr selbst erledigt wird.
Warum die Wahl des Modells zur Architekturentscheidung wird
Der Wechsel des Modells entwertet die mühsam erarbeitete Konfiguration, weil jedes Modell andere Defaults und andere System-Prompts mitbringt. Die Intuition, die man über Reverse Engineering gewinnt, ist immer an ein bestimmtes Modell und an einen bestimmten Harness gebunden.
Empfohlen wird, auf den jeweils aktuellen State-of-the-Art-Modellen zu arbeiten und sich grundsätzlich auf ein Modell zu fixieren. Sinnvoll ist eine Aufteilung nach Aufgabe: den Plan mit einem teuren Modell erstellen, die Implementierung mit einem günstigeren, schnelleren Modell, weil der Plan den nötigen Kontext bereits gefunden hat.
Wenn ein neues Modell erscheint, lohnt es sich, die eigenen Skills und Konfigurationen wegzuwerfen und neu anzufangen. Alte Skills leiten das neue Modell sonst in die falsche Richtung und schränken es ein. Das wäre der schlimmste Fall: ein neues, fähigeres Modell, das durch alte Konfiguration auf das Niveau des Vorgängers gedrückt wird.
Wichtig dabei: Neue Modelle werden meist nicht klüger im Sinne von mehr Wissen. Sie haben oft denselben Trainings-Cutoff wie ihr Vorgänger. Sie agieren näher an dem, was man als Mensch für die Aufgabe erwarten würde.
Die Produktionsstraße ersetzt das einzelne Feature
Die nächste Stufe baut nicht mehr das Feature, sondern die Straße, die Features produziert. Statt eine Suche selbst zu implementieren, entsteht eine Produktionsstraße, die im Kontext des konkreten Systems und Unternehmens aus den eingehenden Feature-Wünschen die Umsetzung erzeugt.
Dieser Ansatz löst zugleich die Modellfrage sauberer. In eine Produktionsstraße lässt sich für jeden Schritt das passende Modell fest verdrahten und gezielt erproben. Manuelle Arbeit verläuft weniger prozesslastig, eine Straße erlaubt die explizite Zuordnung von Modell zu Schritt.
Eine andere Abstraktion, kein neuer Compiler
KI ist nicht einfach die nächste Abstraktionsebene wie Java über Assembler. Der Vergleich hinkt, weil es keinen Compiler gibt, der ein deterministisches Ergebnis garantiert.
Bei Assembler interessiert der erzeugte Code nicht, weil der Compiler verlässlich übersetzt. Bei KI entfällt diese Garantie. Wer sich nicht mehr um den Code kümmern will, braucht andere Absicherungen, etwa den aufräumenden Agenten, statt sich auf eine deterministische Übersetzung verlassen zu können.
Daraus folgt eine Verschiebung der Skills. Der Code rückt in den Hintergrund, die Prinzipien und Herangehensweisen, unter denen guter Code entsteht, rücken nach vorn. Das ist Architekturarbeit, und es ist mehr Architekturarbeit als zuvor.
Wer KI einsetzt, beschleunigt seine vorhandenen Prinzipien
Schlechte Prinzipien plus KI führen schneller zu schlechteren Ergebnissen, gute Prinzipien plus KI schneller zu besseren. Aktuelle Studien aus dem DORA-Umfeld haben die KI-Effekte bereits eingerechnet und zeigen genau diesen Mechanismus.
Die Konsequenz hat zwei Seiten. Teams, die jetzt blind auf KI setzen, können damit beschleunigt gegen die Wand fahren. Und die Schere zwischen leistungsfähigen und schwachen Organisationen wird breiter, nicht kleiner.
Die Gegenmittel sind nicht neu. Unit-Testing, Integration-Testing, Shift-Left und eine funktionierende Pipeline sind Hausaufgaben, die ohnehin gemacht werden müssen. Wer ohne sie 500-mal so schnell Pull-Requests produziert und dann eine zentrale QA-Abteilung davorsetzt, verliert die gewonnene Produktivität sofort wieder.
Wenn du schlechte Prinzipien hast und KI anwendest, dann wirst du schneller schlechter. Und wenn du gute Prinzipien hast, wirst du schneller besser. — Benedikt Stemmildt
Warum Teams sich beim agentischen Arbeiten auf die Füße treten
Die meisten Erfahrungsberichte stammen von Einzelpersonen, kaum jemand hat das Arbeiten als Team gelöst. Genau dort entstehen die größten Probleme.
Fünf Entwickler, alle agentisch arbeitend, stehen sich massiv im Weg. Im klassischen Planning teilt man die Arbeit auf, jeder nimmt einen Ausschnitt. Mit Agenten entwickelt dagegen jeder sofort den ganzen Stack. Merge-Konflikte sind dabei das kleinere Problem, das die KI selbst auflöst. Schwieriger ist, die Entwicklung des Produkts überhaupt noch zu überblicken.
Die Antwort sind kleinere Einheiten. Aus Produktmanager, Product Owner und Entwickler wird zunehmend eine Rolle, der Product Engineer. Drei solcher Leute plus ein Agent ergeben ein Team, das gut im Ensemble programmieren kann.
Organisation und Architektur müssen zusammen passen
Ein cross-funktionaler Zuschnitt der Teams ist die Voraussetzung, getrennte Backend- und Frontend-Teams lassen sich für agentisches Arbeiten nicht sinnvoll kleiner schneiden. Fünf Frontend- und fünf Backend-Teams ergeben keine tragfähige Struktur.
Allein die Organisation zu zerschneiden reicht nicht. Conway’s Law und soziotechnische Architektur greifen hier ineinander. Die Architektur muss so geschnitten sein, dass die Agenten sich auch im Code nicht auf die Füße treten.
Praktisch bedeutet das eher Self-Contained Systems oder eine Modulith als Microservices, bei denen die Gefahr besteht, dass man sich erneut blockiert. Ende-zu-Ende abgeschlossene Einheiten geben den parallel arbeitenden Agenten und Teams den nötigen Raum.
KI-haltige Systeme entstehen anders als deterministische Software
Sobald ein System selbst KI enthält, etwa ein Agent, der eine Verordnung durchliest, ändert sich der Entwicklungsprozess grundlegend. Solche Systeme sind nicht deterministisch wie die Software, die bisher gebaut wurde.
Das verlangt kleinere Iterationen und deutlich mehr Ausprobieren. Bei klassischer Software hat ein Entwickler eine Vorstellung von der Lösung und implementiert einen Algorithmus. Bei KI-haltigen Systemen muss man viel mehr experimentieren, weil sich das Verhalten nicht vorab festlegen lässt.
Damit stoßen alte Steuerungsmodelle an Grenzen. Lasten- und Pflichtenheft scheiden ohnehin aus, aber auch agile Prinzipien reichen für diese Art von Entwicklung nicht mehr aus.
