Was Agentic Coding eigentlich heißt

Prolog · Serie: Agentic Coding mit Claude Code

Wer sich in diesem Jahr durch Tech-Newsletter, Konferenz-Keynotes und Tool-Landingpages liest, trifft auf zwei Begriffe, die beide mit denselben Versprechen verkauft werden: Vibe Coding und Agentic Coding. Die Zukunft des Programmierens, heißt es. Natürliche Sprache statt Code. Der Entwickler als Dirigent, der Absichten formuliert, während das Modell die Details erledigt. Zehnfache Produktivität, niedrigere Einstiegshürden, das Ende des mühsamen Handwerks.

Was dabei auffällt: Ob man einen Cursor-Tweet liest, einen Claude-Code-Demo-Clip anschaut oder einer Konferenz-Keynote über „AI-driven development" folgt — der Eindruck bleibt derselbe. Das alles sei eine Bewegung, ein Trend, im Wesentlichen eine Sache. Verschiedene Logos, ähnliche Botschaft. Die Begriffe wandern durch die gleichen Texte, werden in denselben Atemzügen genannt, und niemand scheint es für nötig zu halten, sie auseinanderzuhalten.

Diese Reihe tut das — nicht aus Spitzfindigkeit, sondern weil der Unterschied praktische Konsequenzen hat. Wer Vibe Coding und Agentic Coding für dasselbe hält, wird bei bestimmten Projekten auf eine Wand zufahren und erst dann verstehen, warum. Ich zeige anhand eines konkreten Projekts, wie Agentic Coding mit Claude Code tatsächlich aussieht: mit einem Workflow, klaren Werkzeugen und der nötigen Disziplin, damit am Ende eine Codebasis steht, die man in drei Monaten noch anfassen kann. Der Testfall ist byhaushalt — eine interaktive Webanwendung zum bayerischen Haushalt 2026/27, deren Code offen auf Codeberg liegt.

Was Vibe Coding ist — und warum es nicht reicht

Den Begriff hat Andrej Karpathy im Februar 2025 geprägt. Der Entwickler öffnet ein Chat-Fenster, tippt einen Wunsch, übernimmt was das Modell liefert, tippt den nächsten Wunsch. Kein Spec, keine Tests, kein Architekturgedanke. Die Arbeit fühlt sich produktiv an — und ist es für einen Abend auch. Für alles, was länger als ein Wochenende lebt, beginnt dann das eigentliche Problem.

Vibe Coding ist keine schlechte Absicht. Es ist eine natürliche Reaktion auf Werkzeuge, die plötzlich auf einfache Anfragen brauchbaren Code produzieren. Das Problem ist strukturell: Code wächst. Anforderungen ändern sich. Wer heute ohne Disziplin schreibt, debuggt morgen ohne Kontext. Das gilt für Menschen, und es gilt genauso für KI-Agenten, die in Codebasen arbeiten.

Was Agentic Coding ist

Wenn Agentic Coding nicht Vibe Coding ist und kein Ersatz fürs Entwickeln — dann lautet die positive Antwort: Es ist Software-Entwicklung mit klar verteilten Rollen zwischen Mensch und Werkzeug. Der Mensch gibt die Spec vor, trifft Entscheidungen und reviewed Ergebnisse. Der Agent führt aus, verifiziert, korrigiert und meldet zurück. Weder übernimmt der Agent die Kontrolle, noch tippt der Mensch jede Zeile selbst. Das Dazwischen ist der Punkt.

Der Ablauf sieht in der Praxis so aus: Wir schreiben eine Spec — was soll gebaut werden, was ist Erfolg, welche Randbedingungen gelten. Das kann direkt als CLAUDE.md oder als Plan entstehen, den der Agent im Plan Mode ausarbeitet und wir anschließend prüfen und freigeben. Dann setzt der Agent um: Er liest Dateien, schreibt Code, führt Befehle aus, lässt Tests laufen. Nach jedem relevanten Schritt folgt Verification — Tests müssen grün sein, Lint darf nicht klagen, Type-Checks müssen durchgehen. Scheitert etwas, korrigiert der Agent selbst oder fragt nach. Erst wenn alles passt, geht es zur nächsten Aufgabe. Wir greifen dort ein, wo Entscheidungen fallen — nicht dort, wo getippt wird.

Was diesen Workflow von einer gewöhnlichen LLM-Session unterscheidet, ist nicht die Stärke des Modells, sondern die Disziplin der Struktur. Hooks, die Tests erzwingen, bevor Code committed wird. Spec-Dateien, die explizit machen, was Erfolg bedeutet — damit der Agent nicht interpretiert, sondern ausführt. Subagents, die Teilaufgaben übernehmen, ohne den Hauptkontext zu überfluten. Worktrees, die parallele Experimente erlauben, ohne den laufenden Stand zu gefährden. Kein einzelnes Werkzeug davon ist entscheidend — zusammen machen sie aus einer Sitzung ein nachvollziehbares, reproduzierbares Vorgehen, das auch Tage später noch lesbar ist.

Für byhaushalt heißt das konkret: Die Spec beschreibt, was aus den Haushaltsdaten extrahiert werden soll. Der Agent baut den Parser, Tests prüfen die Summen-Konsistenz gegen den Gesamthaushalt, und Hooks verhindern, dass ungetesteter Code in den Branch gelangt. Jeder Schritt ist nachvollziehbar in Git und im Buildlog.

Ein letzter Punkt, der uns wichtig ist: Kein Agentic-Coding-Workflow muss am ersten Tag vollständig sein. Was zählt, ist dass die Disziplin in Werkzeugen verankert ist und nicht in Willenskraft. Auf Willenskraft allein kann man sich nur so lange verlassen, bis man es nicht mehr tut. Wer Hooks einrichtet und Tests schreibt, hat die Disziplin automatisch — auch am schlechten Tag.

Was Agentic Coding nicht ist

Bevor wir in die Werkzeuge einsteigen, eine Klarstellung: Agentic Coding ersetzt nicht das Entwickeln. Wer Python, TypeScript oder Bash nicht selbst lesen und einordnen kann, kann den Agenten weder sinnvoll steuern noch seine Ergebnisse prüfen. Der Agent ist ein schnellerer Coder und ein gründlicherer Reviewer als der Mensch — aber er ist kein Ersatz für jemanden, der versteht, was geschrieben wird. Wer ohne diese Grundlage anfängt, baut Vertrauen auf Output, den er nicht beurteilen kann. Genau das ist die Falle in die Viele ob der vollmundigen Versprechen von Marketingabteilungen tappen.

Was einen Agenten vom Chatbot unterscheidet

Ein Sprachmodell, das nur auf Prompts antwortet, ist ein Textgenerator. Ein Agent entsteht erst, wenn drei Dinge zusammenkommen.

Das erste ist Tool-Use: Das Modell ruft Funktionen auf, statt nur Text zu schreiben. Es liest Dateien, führt Terminal-Befehle aus, sucht in Dokumentation. Es schreibt nicht über Code — es interagiert mit einer echten Umgebung.

Das zweite ist der Loop: Nach jedem Tool-Ergebnis entscheidet das Modell, was als Nächstes kommt. Es liest den Output eines Befehls, bewertet ihn, wählt den nächsten Schritt. Kein One-Shot-Prompt, der einen vollständigen Plan vorgibt — sondern eine Schleife, die sich an Ergebnissen orientiert.

Das dritte ist Verification: Das System prüft, ob das Ergebnis stimmt. Tests schlagen fehl oder bestehen. Ein Lint-Lauf meldet Fehler oder nicht. Ohne Verifikation bleibt jeder Loop blind — der Agent kann nicht unterscheiden, ob er Fortschritt macht oder sich im Kreis dreht.

Vibe Coding ist im Wesentlichen Tool-Use ohne Loop und ohne Verification. Der Mensch übernimmt den Output manuell, im Browser, im Editor — und wenn er nicht genau hinschaut, übernimmt er auch die Fehler.

Spec-First, nicht Prompt-First

Der entscheidende Schritt vor jedem Agenten-Run ist eine Spec. Nicht im Sinne eines zwanzigseitigen Pflichtenhefts — sondern eine knappe, präzise Beschreibung dessen, was gebaut werden soll, welche Constraints gelten, welche Annahmen explizit gemacht werden. Claude Code hat dafür einen eigenen Modus: Plan Mode plant nur, schreibt keinen Code. Der Agent entwirft eine Architektur, schlägt Dateipfade vor, benennt Abhängigkeiten — und der Mensch entscheidet, bevor eine einzige Zeile geschrieben wird.

Das ist keine Formalität. Wer den Agenten direkt losschickt, bekommt eine Lösung für das Problem, wie das Modell es verstanden hat. Das ist nicht immer das Problem, wie man es gemeint hat.

Die zweite Säule sind CLAUDE.md-Dateien: Markdown-Dateien im Repo, die der Agent beim Start automatisch liest. Man schreibt hinein, was der Agent wissen muss — Projektstruktur, Konventionen, welche Befehle es gibt, was er nicht anfassen soll. Das Modell hat kein Gedächtnis über Sessions hinweg; CLAUDE.md ist das Gedächtnis, das der Mensch schreibt. Ohne diese Datei erklärt man dem Agenten bei jedem Run von vorne, wie das Projekt aufgebaut ist.

Was die Reihe behandelt

Die zehn Hauptartikel folgen einem Bogen vom ersten Projektsetup bis zum produktiven Deploy. Wir zeigen, wie man eine CLAUDE.md schreibt, die den Agenten tatsächlich steuert — nicht nur beruhigt. Wir zeigen, wie Hooks funktionieren: Shell-Skripte, die an bestimmte Ereignisse im Agenten-Loop gebunden sind und automatisch Validierung, Formatierung oder Tests auslösen. Wir zeigen, wie man Subagenten für abgegrenzte Teilaufgaben einsetzt und wie Git Worktrees dabei helfen, parallele Experimente sauber zu halten.

Dazu kommen Slash Commands und Skills — wiederverwendbare Arbeitsabläufe, die der Agent auf Abruf ausführt — sowie MCP, das Model Context Protocol, das den Agenten mit externen Diensten verbindet. Jedes dieser Werkzeuge wird im Kontext eines echten Problems eingeführt: mit der Konfiguration, die wir tatsächlich verwendet haben, mit den Fehlern, die dabei aufgetreten sind, und mit dem Code, der am Ende dabei herausgekommen ist.

Was die Reihe nicht zeigt: wie man Code schreibt. Das setzt Claude Code bereits voraus. Was sie zeigt, ist wie man einen Agenten so aufstellt, dass er in einer wachsenden Codebasis zuverlässig arbeitet — nicht nur beim ersten Run.

byhaushalt als Testfall

2015 habe ich die bayerischen Haushaltspläne 2012-2016 schon einmal visualisiert — als Opendata Projekt für die bayrische Piratenpartei, mit den Daten anschließend an openspending.org übergeben. Zehn Jahre später öffnet man die Webseite des Freistaats: Der Haushalt 2026/27 erscheint — wie damals — als PDF. Keine API, keine maschinenlesbare Tabelle, keine offene Datenstruktur. Wer mit den Zahlen arbeiten will, fängt bei null an.

2015 und heute

Was sich geändert hat, ist nicht die Bereitschaft des Freistaats — die ist gleich null geblieben. Was sich geändert hat, ist der Aufwand auf meiner Seite.

2015 war PDF-Parsing eine RegEx Schlacht, Tabellenzeilen, die über Seiten umbrechen. Kopfzeilen, die sich von Kapitel zu Kapitel geringfügig ändern. Tausende von Haushaltsstellen, viele mit einem anderen Format, je nach Abteilung und Druckvorlage. Ich schrieb Heuristiken, prüfte Spaltenbreiten, fluchte auf fehlende Unicode-Zeichen, und am Ende hatte man eine CSV-Datei, die man noch einmal von Hand validieren musste, weil schlicht arithmetische Rechenfehler im Söders Haushalt waren. Das war damals der Stand der Werkzeuge.

Heute kann ein Sprachmodell diesen Teil übernehmen — nicht weil es das Problem grundsätzlich gelöst hätte, sondern weil es Extraktion, Validierung und Fehlerkorrektur in einem Loop zusammenfassen kann, der sich an echten Ergebnissen orientiert. Aber nur, wenn man es richtig einsetzt. Wer ein Modell mit einer PDF-Datei füttert und sich den Output direkt in die Anwendung kopiert, bekommt Vibe Coding: es sieht aus wie Fortschritt, und es ist welcher — für eine Stunde. Danach beginnt das Aufräumen.

Das Projekt byhaushalt — eine interaktive Webanwendung, die den bayerischen Haushalt 2026/27 ( Entwurf ) navigierbar macht. Keine Kartenanwendung, keine gamifizierte Bürger-App: eine direkte Visualisierung der Haushaltsdaten, mit Filterung nach Einzelplänen, Kapiteln und Titeln, und mit der Möglichkeit, Beträge und Veränderungen gegenüber dem Vorjahr nachzuschlagen.

Der Code ist öffentlich, alle Schritte sind dokumentiert, und wer das Projekt klonen und lokal ausführen will, soll das ohne Rückfragen können. Das war 2015 genauso das Ziel — damals mit einer anderen Infrastruktur und ohne die Werkzeuge, die wir heute haben.

Agentic Coding verschiebt die Arbeit, es ersetzt sie nicht. Der Mensch entwirft, prüft, entscheidet. Der Agent tippt, führt aus, iteriert. Wer das umdreht — wer dem Agenten entwirft und sich selbst ausführen lässt — hat Vibe Coding mit mehr Zwischenschritten. Der Unterschied liegt nicht im Werkzeug, er liegt in der Disziplin.

Im nächsten Artikel schreiben wir CLAUDE.md für byhaushalt — die erste Memory-Datei, die festlegt, woran sich Claude Code zu halten hat.