Ein Coding-Agent durchsucht das Projektverzeichnis, zieht Ausschnitte aus früheren Sessions und führt nach einigen gezielten Editierungen die Testsuite aus. Er meldet zurück, alles sei grün – und doch wäre es fahrlässig, das als Beleg für korrektes Arbeiten zu nehmen.
Agentic Engineering verlagert das Vertrauen vom Selbstbericht des Modells auf die Struktur des Systems, in dem es arbeitet. Wer schon einmal mit Coding-Agents gearbeitet hat, kennt das Muster: Das Modell formuliert einen Plan, schreibt Code und besteht darauf, dass alle Prüfungen bestanden sind. Scott Spence fasst es in seinem Leitfaden so: Agentic Engineering bettet Coding-Agents in ein technisches System ein, das Kontext, Umfang, Validierung, Beweise und menschliche Überprüfung explizit macht. Das Modell darf planen und Code schreiben, aber es darf nicht selbst bestimmen, dass seine Arbeit korrekt ist.
Was ist Agentic Engineering? Eine Definition für die Praxis
Agentic Engineering ist Softwareentwicklung, bei der Agents wesentliche Teile des Entwicklungszyklus übernehmen, während Ingenieure die Umgebung gestalten, in der diese Arbeit stattfindet. Ein Coding-Agent kann ein Repository durchsuchen, Dokumentation lesen, Dateien editieren, Befehle ausführen und auf die Ergebnisse reagieren. Das macht ihn mächtiger als eine Autovervollständigung – aber Fehler bekommen einen Ort, an dem sie sich festsetzen. Eine falsche Annahme wird zu einer Codeänderung. Eine fehlende Randbedingung wird zu einer neuen Abhängigkeit. Und eine selbstbewusste Zusammenfassung kann behaupten, dass die Validierung erfolgreich war, obwohl der entscheidende Test nie lief.
Die eigentliche Arbeit verschiebt sich eine Ebene nach oben. Du kümmerst dich nicht mehr nur um den Code, sondern auch darum, wie der Agent den passenden Kontext findet, welche Aktionen er ausführen darf, wie eine Aufgabe begrenzt ist, welche Prüfungen er nicht stillschweigend überspringen kann und wie Fehler aufgezeichnet werden. Dazu kommen die Fragen, die sich bei jeder Zusammenarbeit stellen: Wer prüft das Ergebnis – ein anderer Agent oder ein Mensch – und was passiert, wenn der ursprüngliche Plan falsch war?
Populär wurde der Begriff durch Andrej Karpathy, der Anfang 2026 darüber reflektierte, dass sich die Programmierung mit Agents weiterentwickelt hat und seine frühere Beschreibung als „Vibe Coding“ nicht mehr ausreicht. Doch so neu der Name ist, so alt sind die dahinterliegenden Prinzipien: Spezifikationen, Werkzeuge, Berechtigungen, Tests, Beobachtbarkeit und Review – angewendet auf ein Arbeitsgerät, das schnell und nützlich, aber eben auch stochastisch ist. Das ist Agentic Engineering in der Praxis.
Vibe Coding vs. Agentic Engineering: Wo verläuft die Grenze?
Vibe Coding ist ergebnisorientiert und bewusst lose. Du beschreibst, was du willst, lässt das Modell etwas generieren, probierst das sichtbare Ergebnis aus und promptest so lange erneut, bis es sich richtig anfühlt. Für Prototypen, Wegwerf-Tools oder das Erkunden einer Idee kann das großartig sein. Das Problem entsteht, wenn du denselben Vertrauensmechanismus für Produktionssoftware nutzt.
Eine Produktionscodebasis hat Dinge, die eine schnelle Demo gut versteckt: Berechtigungen, Datenmigrationen, Fehlerbehandlung, Audit-Trails, Barrierefreiheit, Performance, bestehende Konventionen und Nutzer, die Dinge in falscher Reihenfolge tun. „Es hat funktioniert, als ich geklickt habe“ ist kein Beweis dafür, dass diese Systeme weiterhin funktionieren. Agentic Engineering behält die Geschwindigkeit, verändert aber die Abnahmekriterien. Der Agent darf weiterhin viel tippen – abgeschlossen ist die Arbeit erst, wenn die Checks des Repositories und die eigentlichen Erfolgsbedingungen der Aufgabe es bestätigen.
Die Grenze ist unscharf. Simon Willison hat darauf hingewiesen, dass sich Vibe Coding und Agentic Engineering im Laufe der Zeit annähern, wenn die Modelle besser werden und unüberwachte Erfolge das Vertrauen erhöhen. Die Gefahr liegt nicht in der zunehmenden Autonomie, sondern darin, dass wiederholter Erfolg die Kontrollen leise abschafft, die beim nächsten Lauf warnen. Der Unterschied zwischen Vibe Coding und Agentic Engineering ist keine Frage des Werkzeugs, sondern des Trust-Modells: Liegt das Vertrauen im Prompt-Gefühl oder im Kontrollsystem?
Der Baukasten für einen zuverlässigen Agentic-Engineering-Workflow
Der Workflow aus „my-pi“, einem Eigenbau-Setup, ist keine universelle Lösung, aber einige Bausteine haben sich in der Praxis bewährt. Zuerst muss der Agent die Quelle der Wahrheit rekonstruieren. Eine frische Session kennt nur den Prompt und den vom Harness eingefügten Kontext. Sie weiß nicht, warum eine Architektur gewählt wurde, was letzte Woche fehlschlug oder welche Nutzerkorrektur die Aufgabe verändert hat. Deshalb beginnt die Arbeit mit Recherche: Repository und lokale Anweisungen ansehen, aktuelle Implementierung und Tests finden, frühere Sessions durchsuchen, externe APIs aus Primärquellen recherchieren und Annahmen offenlegen.
Das Ziel ist nicht maximaler Kontext. Ein riesiges Instruction-File kann die eigentliche Aufgabe verdrängen. Relevant ist der Kontext, den der Agent bei Bedarf abrufen kann. Dafür gibt es den Session-History-Abruf „pirecall“ und einen SQLite-Kontext-Storage für große Tool-Ausgaben. Beides verwandelt eine Wand aus Text in etwas Durchsuchbares. Der zweite Baustein ist ausführbares Projektwissen. Eine AGENTS.md-Datei ist nützlich für stabile Regeln, aber sie ist kein Schutzschild. Wenn eine Regel so wichtig ist, dass ihr Verstoß die Codebasis beschädigen würde, dann formuliere sie als Typ, Lint-Regel, Boundary-Check, Test, Hook oder CI-Befehl. Prosa beschreibt, wie guter Code aussieht; deterministische Checks verhindern, dass ein plausibler Abkürzungsweg zur neuen lokalen Konvention wird.
Für Aufgaben mit materialem Risiko kommt ein externer Task-Harness zum Einsatz. Dieser hält die erlaubten Pfade, verbotenen Operationen, Validierungskommandos, Aufgabenstatus und gesammelte Beweise außerhalb des Arbeitskontexts des Ausführenden fest. Der Agent kann seinen Umsetzungsplan an neue Fakten anpassen, aber er kann nicht leise seine Berechtigungen erweitern oder lästige Prüfungen entfernen. Ein guter Harness beantwortet vier Fragen: Was darf sich ändern? Was darf nicht passieren? Wie wird Erfolg geprüft? Welche Beweise wurden gesammelt? Und wann sollte der Agent anhalten und um Hilfe fragen? Nicht jede Aufgabe braucht einen Harness – eine Rechtschreibkorrektur in eine Mini-Softwarefabrik zu verpacken ist Zeremoniell, nicht Sorgfalt.
Auch die Validierung gehört in die Hände des Agents. Ein Agent kann keinen Fehler beheben, den er nicht sieht. Deshalb sollten Typfehler, Unit- und Integrationstests, Browser-Checks, Lint-Ausgaben, Build-Ergebnisse und Language-Server-Diagnostik genauso verfügbar sein wie für einen menschlichen Entwickler. Das Hinzufügen von LSP-Unterstützung hat mehr gebracht als erwartet: Der Agent kann Diagnosen für die geänderte Datei anfordern, statt nach jedem Edit das ganze Projekt zu prüfen, und er kann Definitionen und Referenzen nachschlagen. Entscheidend ist, dass der Abschluss-Check nicht „der Agent sagt, dass es gut aussieht“ ist, sondern ein unabhängiger Befehl oder ein beobachtbares Ergebnis. Für eine Nutzerreise bedeutet das, die Seite tatsächlich zu laden und zu nutzen; für eine Migration, das resultierende Schema und die Daten zu inspizieren.
Telemetrie, Secrets und Multi-Agent-Betrieb
Wenn jede Session spurlos im Transkript verschwindet, lässt sich die Arbeit von Coding-Agents kaum verbessern. Der Autor hat deshalb lokale Telemetrie eingeführt, die Session, Modell und Werkzeugnutzung aufzeichnet, sowie durchsuchbare Session-History und fokussierte Evals, wenn sich eine Prompt-, Tool- oder Retrieval-Strategie ändert. Damit lassen sich konkrete Fragen beantworten: Hat der Agent das neue Tool genutzt? Hat er die richtige Quelle gefunden? Hat die Änderung verschwendete Ausgaben reduziert? Hat der Guard den Fehler abgefangen, für den er gebaut wurde? Evals sind nicht nur Checks gegen den letzten Absatz, den ein Agent schreibt. Entscheidend ist das Ergebnis. Ein Beispiel: Ein Flugbuchungs-Agent mag behaupten, den Flug gebucht zu haben, aber die eigentliche Frage ist, ob die Reservierung existiert. Bei Coding-Arbeit gilt dasselbe. Bewerte den Zustand des Repositories und die Nutzerreise, nicht die Selbstsicherheit der Zusammenfassung.
Ein weiterer Aspekt sind Secrets und Berechtigungen. Ein Coding-Agent mit Shell-, Dateisystem- und Netzwerkzugriff hat einen größeren Blast Radius als ein Chat-Fenster. Prompt Injection kann nicht nur über Nutzereingaben kommen, sondern auch über eine Webseite, ein Ticket, eine README-Abhängigkeit oder eine Tool-Antwort. Im Setup gelten schmale Tool-Berechtigungen, explizite Genehmigungsgrenzen und eine Implementierung namens „nopeek“, mit der ein Agent einen prozessabhängigen Befehl ausführen kann, ohne vorher die ganze .env-Datei in den Kontext zu drucken. Das macht nicht jede Kindprozess-Ausgabe sicher, beseitigt aber einen häufigen unnötigen Expositionspfad.
Mehrere Agents einzusetzen lohnt sich nur, wenn die Arbeit wirklich parallel ist: Ein Agent recherchiert eine API, während ein anderer die bestehende Implementierung kartiert, oder getrennte Agents arbeiten in isolierten Worktrees und ein Lead prüft die Ergebnisse. Wenn dagegen fünf Agents dieselben Dateien, Kontexte und Entscheidungen brauchen, schaffst du ein Koordinationsproblem und nennst es Skalierung. In seinem „Team Mode“ gelten die Prinzipien Eigentum, dauerhafte Übergaben und explizites Review. Delegation verschiebt die Verantwortung nicht auf eine schwarmförmige Wolke – der Lead muss das kombinierte Ergebnis weiterhin verstehen.
Erfahrungswerte: Was der Workflow tatsächlich bringt
Einen sauberen Benchmark hat der Autor nicht. Dafür gibt es Zahlen aus dem Betrieb: Zwischen dem 28. Juni und dem 25. Juli 2026 erzeugten Agents 173 aufgezeichnete Task-Harnesses in 104 Sessions und 10 echten Projekt-Workspaces. 144 davon erreichten mindestens einmal einen abgeschlossenen Zustand, 155 haben Validierungs- oder Review-Beweise aufgezeichnet, und 133 Enforcement-Blocks traten in 69 Sessions auf. Diese Zahlen beweisen nicht, dass jede abgeschlossene Änderung gut war. Sie zeigen aber, dass das System außerhalb einer Demo genutzt wurde, dass Agents regelmäßig überprüfbare Beweise erzeugten und dass durchsetzbare Grenzen tatsächliches Verhalten abfingen.
Die Zahlen offenbaren auch Schwächen: Manche verbotenen Kommandos-Muster waren zu grob, Pläne brauchten öfter legitime Ergänzungen als erwartet, veralteter Aufgabenstatus machte spätere Sessions verwirrend, und fehlgeschlagene Harnesses brauchten immer noch einen Menschen, der das Ergebnis interpretierte. Zudem wurden risikoarme Aufgaben langsamer, wenn sie durch dieselbe Zeremonie liefen. Agentic Engineering bedeutet also nicht „mehr Harness“, sondern genügend System für das Risiko und die Komplexität der jeweiligen Aufgabe. Für eine kleine Änderung reicht ein einfacher Workflow; für eine Migration braucht es die volle Kontrollstruktur.
Was nicht funktioniert – und warum
Einige Muster scheitern konsistent, egal welches Modell. Dazu gehört das härtere Prompting: Wiederholt zu sagen „nicht driften“, „sei vorsichtig“ oder „sorge dafür, dass die Tests laufen“ hilft für einen einzelnen Turn, erzeugt aber keine dauerhafte Kontrolle. Wenn eine Regel wichtig ist, gib ihr einen Test oder lege sie außerhalb der Autorität des Ausführenden ab. Ebenso scheitert das Prinzip „alles in den Kontext laden“. Mehr Kontext ist nicht automatisch besserer Kontext. Riesige Instruction-Files, jedes verfügbare MCP-Tool und komplette Session-Transkripte machen das relevante Signal schwerer auffindbar. Progressive Disclosure und durchsuchbare Quellen sind der Ausweg.
Auch das Selbst-Review des Agents gehört auf den Prüfstand. Es ist nützlich, aber nicht unabhängig. Ein Agent, der über die eigene Arbeit urteilt, ist leicht zu optimistisch. Deshalb braucht es externe Mechanismen wie Tests, Harness-Evidenz und menschliche Überprüfung. Das erinnert an die Qualitätssicherung in klassischen Ingenieurdisziplinen: Wer prüft, darf nicht derjenige sein, der gebaut hat. Und genau dieses Prinzip macht Agentic Engineering zu einer echten Ingenieursdisziplin.
Du kannst Coding-Agents vertrauen, wenn du das System, in dem sie arbeiten, kontrollierst. Das bedeutet nicht, jedem Agenten zu misstrauen. Es bedeutet: Die Entscheidung über die Korrektheit fällt nicht im Bauch des Modells, sondern in der Struktur, die du um es herum gebaut hast. Agentic Engineering ist in erster Linie Systemdesign – und erst danach die Arbeit mit dem nächsten Modell.
Quelle: scottspence.com
