Agentisches Engineering ist kein Vibe Coding mit besserem Namen. Es ist das Betriebsmodell, das KI-generierten Code aus einem Glückstreffer in ein prüfbares System verwandelt: begrenzter Kontext, klare Pläne, kleine Änderungen, Security-Gates und Nachweis vor dem Merge.
Diese Unterscheidung zählt. „Vibe Coding“ war immer als Warnschild nützlich. Andrej Karpathy führte den Begriff im Februar 2025 für eine Arbeitsweise ein, bei der der Entwickler den Code fast vergessen kann. Für Experimente ist das charmant. Für Software mit Kunden, Geld, Sicherheit oder Produktionsdaten ist es kein belastbares Modell.
Die David-Ondrej-Folge vom 17. Mai 2026, Stop Vibe Coding, Start Agentic Engineering – Micky, macht die Linie klarer. Der Gast beschreibt eine Arbeitsweise, in der KI den Großteil des Codes schreibt, der Mensch aber den Harness gestaltet: Source-of-Truth-Kontext, kleine PRs, Review-Loops, Paketregeln und Handoff. Die wichtigste Lektion ist nicht die 95%-AI-Code-Aussage. Wichtig ist die Disziplin um den Agenten.
Warum der Slogan nicht reicht
Vibe Coding optimiert den ersten funktionierenden Demo-Moment. Agentisches Engineering optimiert den zweiten Monat Wartung.
Ein Prompt kann ein Login, ein Dashboard oder einen CRUD-Flow erzeugen. Schwierig wird es, wenn der Code Schema-Änderungen, Eingabefehler, Berechtigungen, Deployment, Tests, Feature Flags, Rollback und einen zweiten Engineer überstehen muss.
Der alte Vergleich „Mensch tippt gegen Modell tippt“ ist erledigt. Modelle erzeugen Code schneller. Die neue Frage ist, ob ein Team diese Geschwindigkeit in ein System lenken kann, das schlechte Änderungen sichtbar macht, bevor sie teuer werden.
Agentisches Engineering hält den Menschen in der wichtigsten Rolle: Ziel, Scope, Architektur, Policy und Abnahmekriterien. Der Agent ist ein schneller Implementierer, nicht Besitzer des Problems. Genau diese Logik steckt auch in 5 Claude Skills für strukturierte KI-Entwicklung: Nicht der Prompt ist das Produkt, sondern der wiederholbare Loop.
Eine gute Definition: Agentisches Engineering ist Software Delivery, bei der KI-Agenten wesentliche Implementierung übernehmen, aber innerhalb von menschlich gestalteten Grenzen, Evidence Gates und Review-Loops arbeiten.
Das Betriebsmodell für Agentisches Engineering
Das Modell hat sechs Bausteine.
Erstens wird die Aufgabe zerlegt, bevor der Agent schreibt. Ein guter Auftrag lautet nicht „bau das Feature“, sondern beschreibt die Änderung, betroffene Dateien, Interfaces, Datenannahmen und Nicht-Ziele. Passt die Aufgabe nicht in eine kleine PR, ist sie zu groß für einen Agentenlauf.
Zweitens bleibt die Codebase die Source of Truth. Dokumentation hilft, aber der echte Vertrag ist Code, der kompiliert, Tests, die laufen, Routen, die existieren, und Schemas, die Produktion nutzt. Die Ondrej-Folge betont, wie wichtig tatsächlicher Package- und Repository-Code als Kontext ist. Das ist richtig: Agenten werden besser, wenn sie das reale System lesen statt aus alten Docs zu raten.
Drittens entscheidet der Harness, welche Tools der Agent nutzen darf. Ein Modell ohne Tools sagt Text voraus. Ein Coding Agent im Harness kann Dateien lesen, Symbole suchen, Tests starten, Browser öffnen, APIs aufrufen und Diffs erzeugen. Diese Macht braucht Grenzen.
Viertens wird der Plan zum Accountability-Objekt. Pläne sind keine Bürokratie. Sie zeigen, ob der Agent den Umfang verstanden hat. Wenn der Plan nach einer 9.000-Zeilen-PR klingt, ist der Plan falsch. Vor der Implementierung splitten.
Fünftens ist Review ein Loop, kein Ritual. Gute Teams kombinieren Tests, statische Checks, zweite Agentenprüfung und menschliches Review. Unser Artikel zu Reviewmaxxing für Agent-PRs geht tiefer darauf ein: Nicht Tokenmenge gewinnt, sondern Review-Qualität.
Sechstens wird Handoff designt. Wenn ein Agent oder eine Session stoppt, braucht der nächste Operator eine kurze Zustandsübersicht, bekannte Fehler, geänderte Dateien, ausgeführte Commands und offene Entscheidungen. Darum sehen Agent-Runtimes inzwischen wie Betriebssysteme aus, wie in Hermes v0.14: Agent-Runtimes werden Betriebssysteme beschrieben.
Kontextbudgets schlagen riesige Prompts
Context Engineering ist die leise Kernfähigkeit hinter Agentischem Engineering.
Ein großes Kontextfenster bedeutet nicht, dass jede Aufgabe das ganze Fenster füllen sollte. Je größer der Prompt, desto stärker muss der Agent Signal von Rauschen trennen. Praktisch besser ist: genau den Code, Vertrag, Fehler und Akzeptanztest geben, den der nächste Schritt braucht.
Produktionsteams sollten hier strenger sein als Demo-Builder. Gute Arbeitsmengen sind klein: ein Feature-Slice, eine Service-Schicht, ein Interface, eine Migration, ein fehlschlagender Test, ein Review-Ziel. Große Aufgaben werden zu mehreren kleinen Agentenläufen mit sauberem Handoff.
OpenAIs Beitrag vom 8. Mai 2026 zu Running Codex safely zeigt denselben Punkt aus Security-Sicht. Sandboxes, Approvals, verwalteter Netzwerkzugang, Identität, Regeln und Telemetrie existieren, weil ein Coding Agent mehr ist als ein Textgenerator. Er handelt in einer Entwicklungsumgebung.
Das Codex-Mobile-Update vom 14. Mai 2026 liefert ein weiteres Signal. OpenAI beschreibt Live-State, Approvals, Diffs, Terminal-Output, Testergebnisse, Remote SSH, Hooks, scoped Access Tokens und Secure Relay in Work with Codex from anywhere. Das sind keine Vibe-Features. Das sind Control-Plane-Features.
Agentisches Engineering beginnt, wenn Teams Kontext, Tools und Freigaben als Architektur behandeln.
Review-Loops sind der echte Produktivitätshebel
Die Produktivitätsgeschichte lautet nicht „KI schreibt 95% des Codes“. Sie lautet: Das Team kann mehr nützliche Änderungen pro Woche sicher reviewen.
Ein schlechter Agentenworkflow vergrößert die Review-Last. Er füllt Branches mit plausibel wirkendem Code, versteckt Fehler in großen Diffs und zwingt Menschen, die Absicht rückwärts zu rekonstruieren. Ein guter Workflow senkt die Review-Last, weil Absicht und Nachweis von Anfang an sichtbar sind.
Jede Agentenaufgabe sollte mindestens vier Artefakte erzeugen: Plan, Diff, Validierungsnachweis und verbleibende Risiken. Fehlt eines davon, ist die Aufgabe nicht fertig.
Der Nachweis kann Tests, Typechecks, Lint, Routenchecks, Browser-Screenshots, Security-Scan oder eine kleine manuelle Abnahme sein. Die Form hängt vom Feature ab. Die Regel ist immer gleich: kein Nachweis, kein Merge.
Darum sind deterministische Workflow-Shells wertvoll. In Archon Workflow Marketplace: Deterministisches KI-Coding im großen Maßstab geht es nicht um einen weiteren Prompt, sondern um die Form: planen, implementieren, validieren, reviewen, freigeben, dann PR. Determinismus gibt KI-Geschwindigkeit ein Geländer.
Security-Regeln gehören in den Workflow
Die Ondrej-Folge nennt eine konkrete Security-Regel: Agenten sollen keine Pakete installieren, die jünger als 14 Tage sind. Das ist keine universelle Wahrheit, aber ein gutes Policy-Muster.
Der Kern stimmt. KI-Agenten greifen schnell zu einer Dependency, die nach Lösung aussieht. Das erzeugt Supply-Chain-Risiko, wenn das Paket neu, obskur, typo-squatted oder schlecht gepflegt ist. Ein Mensch hält vielleicht inne. Ein Agent optimiert auf Abschluss, wenn der Harness ihn nicht stoppt.
Agentisches Engineering macht diese Pause zur Policy. Paketalter-Regeln, Allow-Lists, gesperrte Domains, Read-only-Modi, Secret Scanning, Dependency Review und Approval Gates gehören in den Workflow. Sie dürfen nicht davon abhängen, dass jemand spätabends an alles denkt.
Das ist dieselbe Lektion aus Security Harnesses statt Bauchgefühl: Vercel deepsec. Security Review funktioniert, wenn sie wiederholbar ist: scannen, untersuchen, revalidieren, Ownership-Kontext ergänzen und einen Fix-Pfad exportieren. Agentisches Engineering überträgt dieses Muster auf tägliche Feature-Arbeit.
Ein einfaches Startset reicht: keine neuen Pakete ohne Approval, junge Pakete nur mit Review, Shell-Kommandos für Secrets, Auth, Billing, Produktionsdaten oder Deployment nur mit Freigabe, Netzwerkzugang möglichst allowlisten, externe Writes loggen und rückgängig machbar halten, Abschlussbericht mit Dateien, Checks und Risiken erzwingen.
Eine praktische Checkliste für Teams
Teams brauchen keine riesige Plattform, um mit Agentischem Engineering zu starten. Sie brauchen einen kleinen, wiederholbaren Loop.
Beginnt mit dem Task Brief: Nutzerziel, betroffene Oberflächen, Constraints, Nicht-Ziele und Akzeptanztests. Fünf Minuten Brief sparen oft eine Stunde Cleanup.
Definiert dann das Kontextpaket: relevante Dateien, Source Contracts, API-Referenzen, Datenformen und fehlschlagende Ausgabe. Alte Chats und unpassende Docs bleiben draußen. Ziel ist nicht maximaler Kontext, sondern ausreichend genauer Kontext.
Fordert danach einen Plan vor Code. Prüft Scope Creep, versteckte Migrationen, breite Refactors und fehlende Tests. Wenn der Plan zu groß ist, wird er geteilt. Dort skaliert menschliches Urteil.
Nach der Implementierung braucht es Nachweis. Der Agent führt die kleinsten sinnvollen Checks aus und berichtet das Ergebnis. Kann ein Check nicht laufen, nennt er Grund und Ersatznachweis.
Dann läuft Review als Loop: zweiter Agent, statische Tools und Human Review. Fragt nach Risiko, nicht nach Lob. Ein guter Reviewer sagt, was brechen könnte.
Zum Schluss kommt Handoff: Ziel, geänderte Dateien, getroffene Entscheidungen, Commands, bestandene Checks, übersprungene Checks und offene Risiken. Ohne Handoff verliert das Team den Compound-Effekt von Agentenarbeit.
FAQ
Was ist Agentisches Engineering?
Agentisches Engineering ist Software Delivery, bei der KI-Agenten relevante Teile der Implementierung übernehmen, aber innerhalb von menschlich gesetzten Grenzen, Review-Loops und Evidence Gates arbeiten. Dazu gehören Kontextdisziplin, Planung, Tool-Rechte, Validierung und Handoff.
Das Ziel ist nicht, Engineers zu ersetzen. Das Ziel ist, dass Engineers mehr Implementierung sicher steuern können.
Wie unterscheidet es sich von Vibe Coding?
Vibe Coding optimiert schnelle Ausgabe aus natürlicher Sprache. Agentisches Engineering optimiert verlässliche Delivery: kleiner Scope, source-basierter Kontext, Testnachweis, Security Policy, Review und wartbares Handoff.
Dasselbe Modell kann beides tun. Der Unterschied liegt im Betriebssystem um das Modell.
Sollten Teams KI-Agenten den Großteil des Codes schreiben lassen?
Teams können Agenten viel Code schreiben lassen, wenn Scope, Tests, Review und Rollback stark sind. Der Prozentsatz ist weniger wichtig als der Kontrollloop.
Eine kleine, belegte Agentenänderung ist sicherer als eine große unreviewte Änderung, egal wer sie geschrieben hat.
Was ist ein guter erster Workflow?
Startet mit einem begrenzten Loop: Brief, Kontextpaket, Plan, Implementierung, Validierung, zweites Review, Human Approval und Handoff. Nutzt ihn zuerst für interne Low-Risk-Features.
Messt PR-Größe, Review-Findings, Test-Pass-Rate und Rollbacks, bevor ihr skaliert.
Welche Security-Kontrollen gehören dazu?
Mindestens Paketfreigabe, Secret Scanning, Netzwerkgrenzen, geschützte Pfade, Command Approval, Audit Logs und ein Abschlussbericht zu geänderten Dateien. Für Auth, Billing, Produktionsdaten und externe Posts gelten strengere Regeln.
Der Punkt ist, Vorsicht in den Workflow zu codieren.
Fazit: Geschwindigkeit behalten, System ergänzen
Agentisches Engineering verwirft Vibe Coding nicht, weil es nutzlos wäre. Es verwirft die Idee, dass ein Demo-Workflow unverändert Produktionsworkflow werden sollte.
Die besten Teams behalten die Geschwindigkeit und ergänzen das System: klarer Scope, kleine Kontextpakete, source-basierte Pläne, Security-Regeln, Review-Loops, Validierungsnachweis und sauberes Handoff. So wird KI-Coding von der Show zur Engineering-Fähigkeit.
Wenn euer Team von KI-Demos zu verlässlicher Software Delivery wechseln will, hilft Context Studios beim Design dieses Betriebsloops: Agenten, Policies, Review-Gates und Produktionsworkflows, die schneller liefern, ohne Risiko wegzuerzählen.