Von Vibe Coding zu Agent Engineering: Was sich wirklich verändert hat
Im Februar 2025 veröffentlichte Andrej Karpathy einen Tweet, der eine Ära prägte: “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.”
Dreizehn Monate später verabschiedete er sich im No Priors Podcast von seinem eigenen Begriff.
“I went from 80/20 of writing code myself versus delegating to agents to like 2/98. I don’t think I’ve typed a line of code since December.”
Der Mann, der uns “Vibe Coding” bescherte, nennt es jetzt überholt. Sein neuer Begriff: Agentic Engineering. Nicht weil KI schlechter darin geworden ist, Code zu generieren — sondern weil das Generieren von Code nie der schwierige Teil war.
Was Karpathy wirklich sagte
Das No Priors Interview lohnt sich vollständig anzuschauen, doch drei Verschiebungen stechen heraus:
1. Das Verhältnis hat sich umgekehrt. Karpathy ist von 80 % eigenem Code auf 2 % gesunken. Agenten erledigen den Rest. Der Flaschenhals verlagerte sich von der Tippgeschwindigkeit zur Orchestrierungskompetenz — wie gut man mehrere parallel arbeitende Agenten steuert.
2. “Code ist nicht einmal mehr das richtige Verb.” Softwareentwicklung wurde zur Makro-Aktions-Orchestrierung. Man schreibt keine Funktionen mehr; man delegiert Features. Man debuggt nicht Zeile für Zeile; man prüft auf Architekturebene. Peter Steinberger führt dutzende Agenten gleichzeitig, jeden für 20-Minuten-Aufgaben über mehrere Repositories hinweg.
3. AutoResearch entfernt den Menschen vollständig aus dem Kreislauf. Karpathy baute eine autonome Forschungsschleife für nanoGPT, die über Nacht läuft und Hyperparameter optimiert. Trotz jahrelangem manuellen Tuning fand der Agent Verbesserungen, die ihm entgangen waren — vergessenes Weight Decay auf Value Embeddings, unzureichend abgestimmte Adam-Betas. Sein Fazit: “To get the most out of the tools, you have to remove yourself as the bottleneck.”
Der rote Faden: Der Wert verlagerte sich von der Ausführung zur Beurteilung. Vibe Coding drehte sich um Ausführung — prompten, generieren, ausliefern. Agentic Engineering dreht sich um Beurteilung — Architektur, Verifikation, Orchestrierung.
Das Engineering-Handbuch für das Nächste
In derselben Woche veröffentlichte Tw93 — Schöpfer von Pake, Mole und produktiver Open-Source-Entwickler — “You Don’t Know AI Agents,” einen technischen Leitfaden, der beschreibt, was es wirklich braucht, um Agenten in der Produktion zuverlässig zu machen. Wo Karpathy die Vision liefert, liefert Tw93 das Engineering-Handbuch.
Seine zentrale These: Harnesses sind wichtiger als Modelle.
“Using a more expensive model doesn’t always yield the massive improvements you’d expect. Instead, the quality of your harness and validation tests has a far greater impact on success rates.”
Das ist keine Theorie. OpenAIs eigenes Engineering-Team bewies es: Drei Ingenieure schrieben eine Million Zeilen Code in fünf Monaten — zehnmal schneller als üblich. Der Schlüssel war kein besseres Modell. Es waren die richtigen Entscheidungen über Constraints, Validierung und Agenteninfrastruktur.
Fünf Prinzipien, die Vibe Coding von Agent Engineering trennen
1. Context Engineering statt Prompt Engineering
Die Aufmerksamkeitskomplexität eines Transformers beträgt O(n²). Je länger der Kontext, desto leichter werden entscheidende Signale verwässert. Der häufigste Fehlertyp ist nicht “das Modell kann es nicht” — es ist Context Rot: irrelevante Inhalte häufen sich an, bis die Entscheidungsqualität des Agenten spürbar nachlässt.
Die Lösung ist ein geschichtetes Kontextmanagement:
- Permanente Schicht: Identität, Konventionen, harte Constraints. Kurz, stabil, immer geladen.
- Abrufbare Schicht: Fähigkeiten und Domänenwissen. Deskriptoren bleiben resident; vollständige Inhalte laden nur bei Bedarf.
- Laufzeit-Injektion: Zeitstempel, Nutzerpräferenzen, dynamischer Zustand. Pro Turn hinzugefügt.
- Gedächtnis-Schicht: Sitzungsübergreifende Erfahrung. Nur bei Relevanz gelesen, nicht in jeden Prompt gestopft.
Die entscheidende Erkenntnis: Deterministik gehört nicht in den Kontext. Alles, was als Code-Regeln, Linter oder Hooks ausdrückbar ist, sollten externe Systeme übernehmen. Das Modell soll denken, keine Regelwerke lesen.
2. Tool-Design nach ACI-Prinzipien
Die meisten Tool-Fehler liegen nicht daran, dass das Modell das falsche Tool wählt — sondern daran, dass das Tool für Ingenieure entworfen wurde, nicht für Agenten. Das Agent-Computer Interface (ACI)-Framework verändert die Designperspektive:
| Aspekt | Schlechtes Tool-Design | Gutes Tool-Design |
|---|---|---|
| Granularität | Bildet API-Endpunkte ab | Bildet Agentenziele ab |
| Rückgabe | Vollständige Rohdaten | Für die nächste Entscheidung relevante Felder |
| Fehler | Generischer String | Strukturiert mit Lösungsvorschlägen |
| Beschreibung | Was es tut | Wann man es nutzt und wann NICHT |
Ein praktisches Beispiel: Statt get_post + update_content + update_title als separate Tools anzubieten, bietet man update_yuque_post an, das die vollständige Aktion in einem Aufruf ausdrückt. Gegenbeispiele in Tool-Beschreibungen steigern die Genauigkeit von 53 % auf 85 %.
Beim Debuggen von Agenten: Tool-Definitionen zuerst prüfen. Die meisten Tool-Auswahlfehler entstehen durch ungenaue Beschreibungen, nicht durch mangelnde Modellkompetenz.
3. Gedächtnis als Infrastruktur, nicht als Nachgedanke
Agenten haben keine native zeitliche Kontinuität. Wenn eine Sitzung endet, ist der Kontext weg. Vier Gedächtnistypen lösen unterschiedliche Probleme:
- Arbeitsgedächtnis (Kontextfenster): Aktueller Aufgabenstatus. Aktiv verwaltet.
- Prozedurales Gedächtnis (Skills): Wie Dinge erledigt werden. Bei Bedarf geladen.
- Episodisches Gedächtnis (Session-Logs): Was passiert ist. Persistiert, durchsuchbar.
- Semantisches Gedächtnis (MEMORY.md): Stabile Fakten. Beim Start injiziert.
Die entscheidende Designentscheidung: Gedächtnis-Konsolidierung muss umkehrbar sein. Beim Komprimieren langer Konversationen keine Rohdaten löschen — archivieren. Einen Zeiger verschieben, keine Daten zerstören. Produziert die Konsolidierung eine schlechte Zusammenfassung, kann der Agent noch auf die Rohhistorie zurückgreifen.
4. Evaluation vor Optimierung
Agentenbewertung ist grundlegend schwieriger als traditionelles Testen. Der Eingaberaum ist unendlich, LLMs reagieren empfindlich auf Prompt-Formulierung, und dieselbe Aufgabe kann über Durchläufe hinweg unterschiedliche Ergebnisse liefern.
Zwei Metriken, zwei Zwecke:
- Pass@k: Mindestens ein korrekter Durchlauf von k. Testet Fähigkeitsgrenzen. Für die Entwicklung.
- Pass^k: Alle k Durchläufe korrekt. Testet Zuverlässigkeit. Vor dem Deployment.
Das gefährlichste Anti-Pattern: Den Agenten anpassen, wenn die Evaluation fehlerhaft ist. Bei verzerrtem Scoring optimiert man gegen falsche Signale. Wenn die Performance sinkt, zuerst die Infrastruktur prüfen — Ressourcenlimits, die Abstürze verursachen, fehlerhafte Grader, oder Testfälle ohne Bezug zur Realität — bevor man den Agenten anpasst.
5. Multi-Agenten-Koordination erfordert Protokolle
Mehrere Agenten zu betreiben geht nicht um Parallelismus — es geht um Isolation und Koordination. Sub-Agenten sollten nur Zusammenfassungen zurückgeben; ihre Suche, ihr Trial-and-Error und ihr Debugging-Prozess bleiben in ihrem eigenen Kontext. Der Hauptagenten-Kontext erhält nur Schlussfolgerungen.
Die Reihenfolge zählt: erst Protokolle definieren, dann Isolation etablieren, dann über Kollaboration sprechen. Ohne strukturierte Kommunikation (JSONL-Message-Queues, Task-Graphen, Workspace-Isolation) verstärken sich Fehler über Agenten hinweg. Agent A driftet, Agent B verstärkt die Verzerrung, Agent C stapelt darauf, und alle drei konvergieren mit hoher Zuversicht auf eine falsche Schlussfolgerung.
Die Entwicklung in einer Tabelle
| Phase | Entwicklerrolle | Codequalität | Verifikation | Maßstab |
|---|---|---|---|---|
| Manuelles Coding | Schreiber | Hoch (eigener Code) | Man testet selbst | Einzelperson |
| Vibe Coding | Prompter | Variabel | Man prüft selbst | Ein Agent |
| Agentic Coding | Architekt | Strukturiert | Agent testet sich selbst | Mehrere Agenten |
| Agent Engineering | Orchestrator | Harness-gestützt | Automatisierte Evaluation | Agententeams |
Jede Phase ersetzte die vorherige nicht — sie umfasste sie. Man braucht noch immer Gespür, noch immer architektonisches Denken, noch immer Code-Verständnis. Aber die Ausführungsschicht rückt immer weiter weg.
Was das in der Praxis bedeutet
Karpathy baute einen Heimautomatisierungs-Agenten namens “Dobby the House Elf” — drei Prompts, die sein lokales Netzwerk scannten, Smart-Device-APIs per Reverse Engineering entschlüsselten und sechs separate Apps durch WhatsApp-Befehle ersetzten. “Dobby, sleepy time” schaltet alles aus.
Sein Fazit zur Software: “These apps shouldn’t even exist. Shouldn’t it just be APIs and agents are the glue of intelligence that tool-calls all the parts?”
Das ist die Richtung. Software entwickelt sich von Produkten, die man bedient, zu Agenten, die Produkte in Ihrem Namen bedienen. Die Schnittstelle kollabiert von GUIs zu natürlicher Sprache. Die Komplexität verschwindet nicht — sie wandert in den Harness, die Tools, die Evaluation, die Gedächtnissysteme, die Agenten zuverlässig machen.
Vibe Coding hat uns mit dem Gedanken vertraut gemacht, dass KI Code schreibt. Agent Engineering dreht sich darum, die Infrastruktur aufzubauen, die KI-generierten Code vertrauenswürdig, wartbar und autonom macht.
Die Vibes waren Schritt 1. Das Engineering ist alles danach.
TeamDay betreibt autonome KI-Agenten in der Cloud — SEO, Content, Social Media, Analytics und mehr. Dieselben Agent-Engineering-Prinzipien, die Karpathy und Tw93 beschreiben, treiben unsere KI-Belegschaft an. Bauen Sie Ihr Agententeam auf.