Vom Vibe Coding zum Agentic Engineering

Mit einer KI lässt sich eine Idee schnell in eine erste Anwendung übersetzen. Man beschreibt eine Funktion, probiert das Ergebnis aus und lässt nachbessern. Für einen Bauversuch kann das genügen. Soll dieselbe Anwendung aber Teil der täglichen Arbeit werden, muss jemand verstehen und prüfen, was die Änderungen im gesamten System bewirken.

Diese Unterscheidung steht hinter den Begriffen Vibe Coding und Agentic Engineering, die Andrej Karpathy verwendet. Beide beschreiben Entwicklung mit KI. Der Unterschied liegt darin, wie viel Verantwortung der Mensch für Anforderungen, Code und Prüfung übernimmt. Agentic Engineering bedeutet, die Arbeit von KI-Agenten so zu führen, dass daraus nachvollziehbare und wartbare Software entsteht.

Vibe Coding beschreibt eine bestimmte Arbeitsweise

Beim Vibe Coding steht das sichtbare Ergebnis im Vordergrund: Funktioniert die Anwendung ungefähr so, wie ich es mir vorgestellt habe? Der erzeugte Code wird dabei nicht unbedingt im Detail gelesen oder verstanden. Das kann helfen, eine Idee auszuprobieren und herauszufinden, ob ein Ansatz überhaupt interessant ist.

Damit ist aber nicht jede Programmierung per Spracheingabe automatisch Vibe Coding. Ein erfahrener Entwickler kann einer KI ebenfalls in normaler Sprache Anweisungen geben und ihre Arbeit anschließend gründlich prüfen. Entscheidend ist, ob das Verständnis der Software mit der wachsenden Anwendung Schritt hält.

Karpathy beschreibt Agentic Engineering als professionelle Zusammenarbeit mit fehlbaren Agenten. Die Anforderungen an Korrektheit, Sicherheit und Wartbarkeit bleiben bestehen, auch wenn ein Agent den Code schreibt. Die Verantwortung dafür liegt weiterhin beim Menschen. Karpathys eigener Beitrag ordnet die beiden Arbeitsweisen entsprechend ein.

Ein Agent braucht mehr als einen Funktionswunsch

Nehmen wir eine bestehende Anwendung, in der Erstattungsanträge genehmigt werden. Das Team möchte, dass Beträge über einer bestimmten Grenze zusätzlich von der Geschäftsführung freigegeben werden. Die Anweisung klingt einfach. Für die Umsetzung muss aber geklärt sein, ob die neue Regel auch für bereits eingereichte Anträge gilt und wer eine ausstehende Freigabe sehen darf.

Diese Entscheidungen sollte ein Agent nicht nebenbei für das Unternehmen treffen. Sie gehören in die Anforderung, bevor er den Ablauf verändert. Dazu braucht er den bisherigen Code, die geltenden Projektregeln und die Stellen, an denen Berechtigungen und Statuswechsel bereits umgesetzt sind.

Mit diesem Kontext kann der Agent eine Änderung vorschlagen und passende Prüfungen ergänzen. Der Entwickler kontrolliert anschließend, ob die Lösung zur Anwendung passt und die vereinbarten Fälle abdeckt. Dazu gehört etwa ein Antrag genau an der Betragsgrenze, ein bereits offener Antrag und der Zugriff durch eine Person ohne Freigaberecht.

Der wesentliche Schritt ist damit nicht ein besonders geschickter Prompt. Es ist die Übersetzung eines fachlichen Wunsches in eindeutige Regeln und überprüfbares Verhalten. Diese Arbeit bleibt nötig, auch wenn die KI einen großen Teil des Codes erzeugt.

Prüfung gehört in den Entwicklungsablauf

Die verbreitete Nutzung von KI bedeutet nicht, dass ihre Ergebnisse ungeprüft übernommen werden. In der Stack-Overflow-Umfrage 2025 nutzten 84 Prozent der Befragten KI-Werkzeuge im Entwicklungsprozess oder planten dies. Zugleich misstrauten 46 Prozent der Genauigkeit ihrer Ausgaben, während 33 Prozent ihr vertrauten. Das beschreibt die Einschätzung der Befragten, keine gemessene Fehlerquote. Quelle: Stack Overflow.

Für ein Team folgt daraus eine praktische Aufgabe: Es muss festlegen, woran eine Änderung gemessen wird, bevor sie in die laufende Anwendung gelangt. Automatische Tests prüfen wiederholbare Bedingungen. Eine Vorschau zeigt, ob der Ablauf für den Nutzer verständlich bleibt. Das Code-Review prüft zusätzlich, ob die Änderung zur bestehenden Struktur passt und keine unerwarteten Zugriffe ermöglicht.

Diese Prüfungen ergänzen sich. Ein erfolgreicher Testlauf beantwortet nur die Fragen, die tatsächlich getestet wurden. Deshalb muss ein Mensch auch beurteilen, ob wichtige Fälle fehlen oder die ursprüngliche Anforderung falsch verstanden wurde. Wer nur kontrolliert, ob die Oberfläche funktioniert, übernimmt diese Aufgabe noch nicht vollständig.

So kann ein Team damit beginnen

Für den Einstieg eignet sich eine begrenzte Änderung an einer Anwendung, die das Team kennt. Vor der Umsetzung hält es das gewünschte Verhalten fest, gibt dem Agenten die nötigen Projektinformationen und prüft danach Ergebnis und Code. So wird sichtbar, welche Vorgaben fehlen und welche Kontrollen bereits zuverlässig funktionieren.

Aus diesen Erfahrungen lassen sich wiederverwendbare Projektregeln entwickeln: Welche Bereiche darf ein Agent ändern? Welche Tests müssen bestehen? Wer prüft und veröffentlicht die Änderung? Je klarer diese Regeln sind, desto besser lässt sich die Arbeit an den Agenten übergeben, ohne dass Verantwortung unbemerkt mitwandert.

Bei vector zero Build verbinden wir den MVP deshalb mit einer eingerichteten Entwicklungsumgebung und einer Schulung am eigenen Projekt. Das Team lernt, Änderungen mit KI zu beschreiben, in einer Vorschau zu prüfen und zu veröffentlichen. Projektregeln, automatische Tests und Versionsverlauf bilden dafür die Grundlage. Die Fähigkeit zur Weiterentwicklung entsteht durch diesen gesamten Ablauf.