Was ist Agentic Engineering — und warum nicht Vibe Coding (2026)

Vor genau einem Jahr hat derselbe Mann einen anderen Begriff geprägt — und ihn jetzt selbst zurückgezogen.

Am 2. Februar 2025 schrieb Andrej Karpathy auf X einen Tweet, der innerhalb weniger Wochen 4,5 Millionen Views hatte. Die Definition von “Vibe Coding” war so radikal wie der Name:

“There’s a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

Der ausführlichere Teil desselben Tweets erklärt, was das im Alltag heißt:

“I barely even touch the keyboard. I ‘Accept All’ always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, but it’s not really coding — I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.”

Im April 2026 hat er den Begriff kassiert.

Karpathys Pivot

Auf Sequoias AI Ascent 2026 hat er einen Satz gesagt, der die ganze Verschiebung in zwei Sekunden erzählt:

“Vibe Coding raised the floor. Agentic Engineering raises the ceiling.”

Hobby-Programmierer und Prototyp-Bauer haben durch Vibe Coding eine neue Untergrenze bekommen. Code, der vorher gar nicht entstanden wäre, entsteht jetzt. Aber für professionelle Softwareentwicklung mit Qualitäts-, Sicherheits- und Wartbarkeitsansprüchen reicht das nicht. Agentic Engineering hebt die Obergrenze: nicht durch Coden ohne Review, sondern durch Orchestrieren mit Review.

Was es heißt, ein Mensch zu sein, der von 80 Prozent Selbst-Coden auf 20 Prozent gewechselt ist? Karpathy beschreibt sich selbst genau so. Im Dezember 2025 sei das Verhältnis umgekippt. Das ist kein effizienterer Karpathy. Das ist ein anderer Job. Seine Begründung für die Begriffswahl ist präzise:

“Agentic — weil du den Code in 99 Prozent der Fälle nicht mehr selbst schreibst, sondern Agenten orchestrierst. Engineering — weil dahinter Kunst, Wissenschaft und Expertise stehen.”

Und der entscheidende Differenzpunkt zu Vibe Coding in einem Satz, der sich auf eine Konferenzbühne malen lässt:

“You can outsource thinking. You cannot outsource understanding.”

Drei operative Kriterien

Was Agentic Engineering von Vibe Coding trennt, sind nicht Worte. Es sind drei operative Eigenschaften. Wer alle drei macht, arbeitet agentic. Wer eine oder zwei macht, ist auf dem Weg dahin — aber nicht da.

Multi-Step Tool Use mit Selbstkorrektur. Der Agent läuft kein einzelnes Prompt-Antwort-Spiel. Er macht 20 bis 200 Tool-Calls in einem Run, ohne dass jemand nach jedem Schritt eingreift. Schreibt Code, führt Tests aus, liest die Output, korrigiert, iteriert weiter — bis ein Erfolgs- oder Stop-Kriterium erreicht ist.

Lange Task-Horizonte. Eine agentic Task läuft Minuten bis Stunden, nicht Sekunden. Der Mensch definiert Outcome und Guardrails, dann ist der Agent autonom unterwegs. Eine API-Migration über Hunderte Files. Ein Modul-Refactor. Eine Bug-Reproduktion mit Fix-Vorschlag.

Parallelisierung. Der Senior-Praktiker führt drei bis fünf Agents gleichzeitig — auf getrennten Branches oder in mehreren Instanzen derselben Codebase. Während ein Agent eine Migration macht, schreibt der zweite Tests, der dritte reviewt eine PR.

Wer das nicht macht, betreibt klassisches AI-Supported Coding. KI hilft beim Tippen, der Mensch bleibt in jedem Schritt der Fahrer. Auch das ist okay — aber es ist eine andere Liga.

Wie das in der Praxis aussieht

Drei Leute lohnt es, sich anzuschauen.

Karpathy hat seinen eigenen Übergang öffentlich dokumentiert. Was sein Tag jetzt prägt, ist nicht Tippen, sondern Navigation. Er beschreibt LLMs als “jagged ghosts” — Geister mit gezackten Fähigkeiten, die simultan ein 100K-Zeilen-Codebase refaktorieren und Zero-Day-Vulnerabilities finden, dir aber sagen, du sollst 50 Meter mit dem Auto zur Waschanlage laufen. Wo der RL-Reward-Verteilung deines Use-Cases entspricht, fliegen die Modelle. Wo nicht, kämpfen sie. Der Engineer entscheidet, welcher Geist gerade gut ist und welcher nicht — und in welcher Reihenfolge er sie einsetzt.

Peter Steinberger hat einen anderen Stil. Er ist Anfang 2026 vollständig auf Codex CLI umgestiegen und fährt typischerweise drei bis acht Instanzen parallel in einem 3×3-Terminal-Grid — meistens im selben Folder, ohne Git-Worktrees. Er hat die Worktrees mal probiert und wieder aufgegeben, weil sie ihn verlangsamten. Stattdessen pickt er seine Arbeitsbereiche so, dass die Agents sich nicht gegenseitig überfahren. Sein AGENTS.md-File ist rund 800 Zeilen lang und wächst durch das, was er “organisational scar tissue” nennt: Jedes Mal wenn etwas schiefgeht, kommt eine knappe Notiz dazu. Das ist die Stimme eines Praktikers, nicht eines Theoretikers.

Wer einen 18-Minuten-Eindruck davon bekommen will, wie das in der Praxis aussieht: Steinberger hat im April 2026 bei TED einen Talk gehalten, in dem er die Geschichte seines AI-Agents OpenClaw erzählt — inklusive der Marokko-Anekdote, die zeigt, was Multi-Step-Autonomie konkret heißt. Er schickt seinem Bot eine Voice-Message, obwohl er nie Voice-Support programmiert hatte. Neun Sekunden später hat der Agent das Audio-File inspiziert, das Format identifiziert, einen OpenAI-Key gefunden und geantwortet. Das ist nicht Theorie. Das ist die operative Realität, die wir hier beschreiben.

Simon Willison dokumentiert die Patterns, die andere nur intuitiv anwenden. Seit Februar 2026 schreibt er an einer Pattern-Bibliothek namens Agentic Engineering Patterns — Stand jetzt 12 Kapitel, jede Woche kommen ein bis zwei dazu. Drei Beispiele, was darin steht: “Writing code is cheap now” — der Code ist billig geworden, also schreib mehr explorativ und wegwerfbar. “Red/green TDD” — Test-First hilft Agenten, präziseren Code mit weniger Zusatz-Prompting zu schreiben. “Hoard things you know how to do” — wiederverwendbare Skill-Files als Team-Wissensspeicher.

Drei Stile, eine gemeinsame Realität: Sie schreiben in fünf bis fünfzehn Prozent der Zeit selbst Code. Den Rest orchestrieren sie.

Vibe, Coding, Engineering — drei Stufen, kein Synonym

Eine Schwierigkeit in der aktuellen Diskussion: Die Begriffe werden synonym verwendet. Sie sind es nicht. IBM hat im April 2026 eine Topic-Page veröffentlicht, die das Spektrum sauber zerlegt — und sie hilft, weil sie ein klares Gefälle aufmacht.

Die drei Modi schließen sich nicht aus. Teams starten oft mit Vibe Coding zum schnellen Prototypen, gehen über zu Agentic Coding in der mittleren Phase und kommen bei Agentic Engineering an, sobald die Stakes — Sicherheit, Wartbarkeit, Compliance — steigen.

Im professionellen Kontext, vor allem in regulierten Branchen wie Finance oder Insurance, ist Agentic Engineering der einzig tragfähige Modus. Vibe Coding ist dort kein Modell. Es ist ein Risikofaktor.

Warum “Agentic Coding” gerade stirbt

Eine kleine Beobachtung am Rand, aber wichtig für jeden, der über das Thema schreibt oder spricht: “Agentic Coding” — die Zwischenstufe — ist im Branchengebrauch 2026 auf dem Rückzug.

Karpathys Pivot hat den Wechsel beschleunigt, aber er war schon vorher unterwegs. IBM, Glide, Software Mansion, der gesamte Bloomberg-Stratechery-Pragmatic-Engineer-Cluster nutzen jetzt Agentic Engineering als Standardbegriff. Codecentric, einer der wenigen deutschen Tech-Blogs, der das Thema überhaupt aufgegriffen hat, schreibt im selben Vokabular. The New Stack hat im April 2026 mit dem Artikel “Vibe Coding is passé” den Begriffswechsel endgültig in den Mainstream gedrückt.

Wer 2026 noch von Agentic Coding spricht, signalisiert: Hier ist das Vokabular vom Frühjahr nicht aktualisiert. Für interne Diskussionen okay. Für Stellenausschreibungen, Pitches und externe Kommunikation eine schwache Position.

Was das fürs Hiring bedeutet

Wenn der Begriff Agentic Engineering erst seit April 2026 etabliert ist und die Methodik erst seit November 2025 produktiv reif, dann gibt es niemanden mit fünf Jahren Agentic-Engineering-Erfahrung. Punkt.

Was es gibt, sind Senior-Engineers, die zwischen November 2025 und heute mit den aktuellen Tools gearbeitet haben — Claude Code, Codex CLI, Plan-Mode, Multi-Instance-Setups, eigene Skill-Files, Spec-Driven-Workflows. Sechs Monate intensive Praxis sind 2026 das Maximum, das physikalisch möglich ist.

Wer länger verlangt, sucht eine Person, die nicht existiert. Im Hub-Artikel haben wir das als den falschen Filter beschrieben — die Stellenausschreibungen, die genau die richtigen Senior-Praktiker systematisch aussortieren.

Was im Briefing stattdessen stehen sollte, sind drei einfache Anker. Aktueller Workflow — drei bis fünf parallele Agents in den letzten sechs Monaten, eigene Skill-Files, Spec-Driven-Praxis. Subscription-Tier als Diagnose — wer auf Pro für 20 Dollar pro Monat sitzt, nutzt die Tools nicht ernsthaft. Senior-Praktiker fahren Max 5x oder Max 20x, oder API direkt. Wir haben die Mathematik dahinter in der Token-KPI-Vertiefung konkret aufgeschlüsselt. Und drittens: Ehrliches Fehler-Handling — wer nur Erfolgsstorys hat, hat entweder wenig Praxis oder keine Selbstreflexion.

Wie sich diese drei Anker in einem 45-Minuten-Interview konkret prüfen lassen, haben wir hier als Format mit 25 Fragen ausgearbeitet.

Wenn ihr gerade vor dieser Frage steht

Die meisten CTO-Calls, die wir 2026 führen, fangen mit demselben Satz an: “Wir haben Claude Code freigegeben, aber das Team kommt nicht ins Tempo.” Die Tools sind da. Die Methodik ist es nicht.

Wir vermitteln Senior-Freelancer, die diese Methodik mitbringen — keine Berater, keine Workshop-Anbieter. Engineer, die mittendrin liefern und nebenbei den internen AI-Champion aufbauen.

Schreib mir kurz auf LinkedIn, wo ihr gerade steht. Oder stell eine konkrete Anfrage an unser Team — wir melden uns innerhalb von 48 Stunden.