Von Vibe Coding zu Agentic Engineering: Produktionssysteme mit KI-Agenten entwickeln

Im Februar 2025 beschrieb Andrej Karpathy „Vibe Coding“ als die Praxis, Absichten in natürlicher Sprache zu beschreiben, Änderungen eines LLM mit minimaler Überprüfung zu akzeptieren und den Code über das eigene Verständnis hinaus wachsen zu lassen. Für persönliche Projekte und Prototypen lieferte dies eine beeindruckende Geschwindigkeit.

Ein Jahr später beobachtete er, dass sich die Fähigkeiten von Agenten weiterentwickelt hatten, und schlug „Agentic Engineering“ als seinen bevorzugten Namen für die weiterentwickelte Praxis vor – das Orchestrieren von Agenten unter Beibehaltung einer starken menschlichen Kontrolle über Architektur und Prozess. Das Ziel, wie er es formulierte, ist es, die Hebelwirkung von Agenten zu nutzen, ohne die Softwarequalität zu beeinträchtigen.

Der Unterschied ist wesentlich. Vibe Coding funktioniert gut für einen einzelnen Benutzer bei wenig kritischen persönlichen Arbeiten, aber es sammelt schnell versteckte Schulden, Sicherheitslücken und Wartbarkeitsprobleme an, sobald andere Personen von dem Ergebnis abhängen. Agentic Engineering bewahrt die Geschwindigkeit und Hebelwirkung moderner Agenten, verankert aber alles in einer klaren Struktur, nachvollziehbaren Artefakten und menschlicher Verantwortung.

Der Agentic Engineering Workflow

Beginne mit einer groben Absicht und führe Design-Gespräche mit der KI, während du die Funktionalität in Design-Meeting-Notizen dokumentierst, die die Funktionalität in ihre Bestandteile zerlegen. Sobald das Design solide erscheint, erfasse die übergeordnete Ansicht und die Komponentenkarte in einer Design-Hierarchie (das ist das, was Leute zeigen, wenn sie ein Obsidian-"Gehirn" präsentieren) – einer navigierbaren Struktur, die sowohl dir als auch dem Agenten jederzeit Zugriff auf den umgebenden Kontext, verwandte Entscheidungen und Abhängigkeiten gibt. Hier finden sich auch Designdiagramme, wie UML (Unified Modeling Language), Code- oder Benutzerinteraktionsabläufe, sowie Links zu Architectural Decision Records (ADRs), wo sie klären, wie Komponenten zusammenhängen.

Erstelle für jedes Modul oder den kleinsten Funktionsblock eine fokussierte spec.md innerhalb des LLD, die genaues Verhalten, Funktionssignaturen, Randfälle, Testerwartungen und Integrationspunkte definiert. Verwende die gesamte Struktur als Design-Kontext-Prompt, um die KI zu veranlassen, eine Ticket-artige Hierarchie mit direkter Rückverfolgbarkeit zu den Wiki-Seiten und den Specs zu erstellen. Setze Ticket für Ticket um, wobei der Agent die relevante spec.md als seinen Vertrag befolgt. Dann durchläufst du Verifikations-Gates, deployest, beobachtest und aktualisierst die lebenden Artefakte, während sich die Anforderungen weiterentwickeln.

Praktisches Beispiel: Täglicher Backup-Verifier

Stelle dir ein kleines, produktionsreifes CLI-Tool vor, das tägliche S3-Backups überprüft und bei Fehlern Slack-Benachrichtigungen sendet.

Beginne mit dem groben Ziel: „Ich brauche etwas Zuverlässiges, das täglich prüft, ob meine Backups in Ordnung sind.“ Führe dann architektonische Gespräche mit der KI, um Anforderungen und Randfälle zu ermitteln:

• Was sind die realistischen Fehlermodi für S3-Backups in der Praxis?
• Was genau sollten wir überprüfen (Alter, Dateianzahl, Größe, Erfolgsrate), und welche Schwellenwerte sind sinnvoll?
• Wie sollten Konfiguration und Geheimnisse zwischen lokaler Entwicklung und produktiven IAM-Rollen gehandhabt werden?
• Welche CLI-Befehle und Ausgabeformate wären im täglichen Gebrauch nützlich?
• Welche nichtfunktionalen Anforderungen sind für ein geplantes tägliches Tool am wichtigsten?

Diese Gespräche klären den Umfang und helfen, das Tool in seine Kernkomponenten zu zerlegen: S3-Metadatenabruf mit Wiederholungslogik, eine Verifikationsregel-Engine, ein Benachrichtigungssystem, ein Konfigurationslader, eine CLI-Schnittstelle, strukturierte Protokollierung und Fehlerbehandlung.

Sobald das Design klar ist, dokumentierst du die übergeordnete Ansicht und die Komponentenkarte im Design-Hierarchie-Wiki, wobei jede Seite versioniert und verlinkbar ist.

Das Wiki bietet zukünftigen Lesern den umgebenden Kontext, den ein flaches Dokument nicht bieten kann. Als Teil derselben Designarbeit erstellst du für jedes Modul eine fokussierte spec.md auf der Sub-LLD-Ebene. Hier ist der Vertrag für den S3-Metadatenabrufer.

Diese spec.md ist der Vertrag, den du dem Agenten übergibst, zum Beispiel: „Implementiere genau nach spec.md im Verzeichnis s3_client/, befolge die Projektstandards und füge umfassende Tests hinzu.“ Mit dem Wiki und den Modul-Spezifikationen an Ort und Stelle veranlasst du dann die KI, die Ticket-Hierarchie direkt daraus zu generieren. Jeder Punkt führt zu einer funktionalen Anforderung und zu der Spezifikation zurück, die seinen Vertrag definiert.

Die Implementierung erfolgt dann Ticket für Ticket, jedes wird dem Agenten mit seiner passenden spec.md als Vertrag übergeben. Hier ist, was das in der Praxis produziert: Ein geplanter Durchlauf, der einen kurzen Backup-Satz erkennt und den Alarm auslöst.

Der Durchlauf wird mit einem Fehlercode beendet, sodass der Cron-Job es bemerkt und den Alarm auslöst, der in Slack landet.

Der Alarm enthält den Regelkontext, den ein diensthabender Ingenieur benötigt, um zu handeln: Welcher Check fehlgeschlagen ist, was gefunden wurde, was erwartet wurde und um welchen Backup-Satz es sich handelt.

Vorteile dieses geschichteten Ansatzes

• Agenten übernehmen das Implementierungsvolumen, während Menschen auf jeder Ebene die Architektur und Qualität kontrollieren.
• Das Wiki bietet Auffindbarkeit und Entscheidungen auf Projektebene, während spec.md-Dateien präzise Modul-Verträge liefern, ohne das übergeordnete Design aufzublähen.
• Anforderungen und Entscheidungen fließen direkt von Wiki-Seiten und Spezifikationen in Tickets und Code.
• Änderungen beginnen mit lebenden Design-Artefakten, nicht mit dem Reverse-Engineering der Codebasis.
• Eine klare Trennung der Belange unterstützt parallele Arbeit, Einarbeitung und Audits.
• T-förmige Fachkräfte navigieren mit Breite und hinterfragen mit Präzision, und der Agent liefert bei Bedarf Tiefe, ohne dass jemand das gesamte System im Kopf behalten muss.

Vibe Coding bleibt eine ausgezeichnete Methode für Exploration und schnelles persönliches Prototyping. Agentic Engineering ist der Weg, dieselbe Gesprächskraft in Systeme zu kanalisieren, denen andere Menschen vertrauen und die sie warten können.

Die Rolle der T-förmigen Fachkraft

Dieser Workflow ist besonders wirkungsvoll für T-förmige Fachkräfte: Ingenieure, die breites Wissen über den gesamten Anwendungsbereich hinweg besitzen und die Fähigkeit haben, bei Bedarf in die Tiefe zu gehen.

Weil du kein vollständiges, stets aktuelles mentales Modell davon benötigst, wie die gesamte Anwendung zu jedem Zeitpunkt funktioniert. Der Agent kann diese Tiefe tragen und jeden Teil auf Abruf neu erklären, solange er den richtigen Kontext aus dem Wiki, den spec.md-Dateien und dem Gesprächsverlauf hat.

Was du brauchst, ist die Fähigkeit zu wissen, was du suchen musst und wo du suchen musst, plus die Disziplin, weiterhin präzise Fragen zu stellen, bis du das spezifische, zu bearbeitende Element verstehst. Der breite Teil des T gibt dir die Karte des Systems; der KI-Agent unterstützt die Fähigkeiten, die erforderlich sind, um in das genaue Modul, den Randfall oder den Integrationspunkt einzutauchen, der gerade wichtig ist. Der Agent liefert auf Nachfrage die erschöpfenden Details.

Dies verschiebt die menschliche Rolle von „Ich muss alles und jederzeit verstehen“ zu „Ich weiß, wie man auf der richtigen Höhe navigiert, hinterfragt und validiert.“ Das ist die wahre Fähigkeit des Agentic Engineering.