Agentic Coding: wie ich KI-Agenten arbeiten lasse, ohne die Kontrolle zu verlieren

Aktualisiert
Juli 2026 aus meinem laufenden Betrieb mit über 50 eigenen Websites.

Agentic Coding bezeichnet eine Arbeitsweise, bei der du einer KI ein Ziel vorgibst und ein Agent die Aufgabe selbstständig in mehreren Schritten erledigt: Code schreiben, ausführen, Fehler lesen, nachbessern, erneut prüfen. Du beschreibst nicht mehr jeden Schritt, sondern das Ergebnis und die Regeln, nach denen der Agent aufhören soll.

Ich arbeite so seit Monaten. Ich kann bis heute nicht programmieren und betreue trotzdem über 50 eigene Websites. Der Unterschied zu allem, was ich vorher mit KI gemacht habe, liegt nicht in besseren Antworten, sondern darin, dass ich aus der Schleife heraustrete und nur noch das Ziel und die Abbruchbedingung festlege.

In diesem Artikel zeige ich dir meinen echten Ablauf, warum die Abbruchbedingung über deine Rechnung entscheidet, was Agenten zuverlässig übersehen, und für wen sich das Ganze nicht lohnt.

Was ist Agentic Coding?

Agentic Coding ist Softwareentwicklung, bei der ein KI-Agent eigenständig deine Dateien liest, Änderungen schreibt, Befehle ausführt und das Ergebnis überprüft, bis eine Aufgabe erledigt ist. Der Unterschied zum Chat mit einer KI ist die Handlungsfähigkeit: Der Agent kopiert dir keinen Code zum Einfügen, er greift direkt in deine Umgebung ein.

Google Cloud beschreibt das in seiner Definition von agentischem Programmieren als Planen-Handeln-Beobachten-Schleife. Der Agent liest die Projektstruktur, identifiziert die betroffenen Dateien, schreibt die Umsetzung, führt Tests aus, liest Fehlermeldungen, behebt sie und wiederholt den Vorgang.

Damit du dir das einordnen kannst: Ein KI-Agent ist ein Programm, das eigenständig Zwischenschritte plant und Werkzeuge benutzt, statt nur Text auszugeben. Was das grundsätzlich bedeutet, habe ich in meinem Artikel dazu erklärt, was ein KI-Agent überhaupt ist.

Vibe Coding oder Agentic Coding: wo liegt der Unterschied?

Beim Vibe Coding beschreibst du in normaler Sprache, was entstehen soll, und bewertest am Ende das Ergebnis. Beim agentischen Ansatz kommt eine Prüfinstanz dazu: Tests, Linter, ein zweiter Agent. Vibe Coding fragt „gefällt mir das“, der Loop fragt „besteht das die Prüfung“.

Die beiden schließen sich nicht aus. Ich nutze Vibe Coding für kleine, überschaubare Änderungen und den vollen Loop dort, wo mehrere Dateien betroffen sind und ich das Ergebnis messen kann. Wenn du den Vorgängerbegriff noch nicht kennst: Ich habe ausführlich beschrieben, was Vibe Coding ist und wie ich damit ganze Websites baue.

Wie mein Loop in der Praxis aussieht

Mein Ablauf ist immer derselbe, und er ist bewusst simpel:

1. Ziel vorgeben. Ich beschreibe möglichst genau, was am Ende herauskommen soll, und woran man erkennt, dass es fertig ist.
2. Die KI baut. Der Agent setzt die Änderung um, über alle betroffenen Dateien hinweg.
3. Ein zweiter Agent prüft. Er kontrolliert die Arbeit des Bauenden und gibt eine Fehlermeldung zurück.
4. Die KI bessert nach. Der Bauende bekommt die Meldung und korrigiert.
5. Erneut prüfen. Der Prüfer schaut wieder drauf und meldet, was noch fehlt.
6. Stopp. Sobald das Ziel erreicht ist, endet der Durchlauf. Nicht vorher, aber vor allem nicht später.

Der Punkt, an dem ich am meisten gelernt habe, ist Schritt drei. Der Agent, der prüft, ist nicht derselbe, der gebaut hat. Das klingt nach einer Kleinigkeit und ist der eigentliche Unterschied zwischen einem Loop, der funktioniert, und einem, der sich selbst belügt.

Warum Prüfer und Bauer getrennt sein müssen

Ein Agent, der seine eigene Arbeit bewertet, lobt sie. Das ist kein Verdacht von mir, sondern der zentrale Konstruktionspunkt, den Addy Osmani, Engineer bei Google, in seinem Essay Loop Engineering vom Juni 2026 herausstellt. Er nennt es die Trennung von Generator und Evaluator: Einen unabhängigen, skeptischen Prüfer zu justieren, ist erheblich leichter, als einem Agenten Selbstkritik beizubringen.

Genau so läuft es bei mir, und ich bin da nicht über die Theorie hingekommen, sondern über den Ärger. Solange dieselbe Instanz baute und bewertete, bekam ich zufriedene Meldungen und trotzdem Ergebnisse, die nicht stimmten. Seit der Prüfer ein eigener Durchlauf ist, kommen echte Fehlermeldungen zurück, und der Bauende arbeitet sie ab.

Wenn du einen Schritt aus diesem Artikel mitnimmst, dann diesen. Die meisten Einsteiger lassen die Prüfinstanz weg, weil sie nach unnötigem Aufwand aussieht. Sie ist der Grund, warum der Loop überhaupt zu einem Ergebnis kommt.

Trigger, Verifikation, Abbruchbedingung: die drei Bausteine

Für das systematische Bauen solcher Schleifen hat sich 2026 der Begriff Loop Engineering durchgesetzt. Dahinter stehen drei Bausteine, die jeder funktionierende Loop braucht:

• Trigger. Was startet den Durchlauf? Bei mir ist das fast immer eine konkrete Aufgabe, die ich formuliere.
• Verifikation. Woran wird gemessen, ob das Ziel erreicht ist? Ein Test, eine Prüfroutine, ein zweiter Agent.
• Abbruchbedingung. Wann ist Schluss? Entweder das Ziel ist erreicht, oder eine Obergrenze greift.

Der Begriff kam im Juni 2026 aus mehreren Richtungen gleichzeitig. Peter Steinberger, der Entwickler hinter OpenClaw, brachte es am 7. Juni auf X auf zwölf Worte: „You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.“ Wer OpenClaw noch nicht kennt, findet bei mir eine komplette Anleitung zum Einrichten von OpenClaw.

Kurz darauf sagte Boris Cherny, Head of Claude Code bei Anthropic, auf der Entwicklerkonferenz des Unternehmens denselben Gedanken: „I don’t prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.“ Der Mitschnitt erreichte laut The New Stack in rund 24 Stunden fast 700.000 Aufrufe.

Bemerkenswert daran finde ich: Der Mann, der das bekannteste Coding-Werkzeug gebaut hat, redet mit seiner eigenen KI nicht mehr direkt. Er baut das System, das mit ihr redet.

Warum die Abbruchbedingung über deine Rechnung entscheidet

Hier liegt die größte Gefahr, und sie ist nicht technischer, sondern finanzieller Natur. Ohne saubere Abbruchbedingung wird aus deinem Loop eine Never-Ending-Story. Der Prüfer findet immer noch etwas, der Bauende bessert immer weiter nach, und niemand sagt Stopp.

Das ist deshalb teuer, weil jeder Durchlauf ein vollständiger Agenten-Durchgang ist. Die Kosten wachsen also mit jeder Runde, nicht mit der Aufgabe. Eine Aufgabe, die in drei Runden fertig ist, kostet ein Drittel von derselben Aufgabe in neun Runden, und das Ergebnis kann dasselbe sein.

Deshalb formuliere ich das Ziel so, dass man objektiv erkennen kann, wann es erreicht ist. „Mach die Seite schöner“ hat keine Abbruchbedingung. „Alle Unterseiten nutzen dieselbe Abstandsregel, und der Test läuft ohne Fehler durch“ hat eine. Wie sich die Kosten bei Claude Code konkret aufteilen, habe ich in meinem Beitrag zu den Kosten von Claude Code aufgeschlüsselt.

Wie du eine brauchbare Abbruchbedingung formulierst

Das ist der Teil, an dem in meinem Workflow die meiste Denkarbeit hängt, und gleichzeitig der, den fast alle Anleitungen überspringen. Eine Abbruchbedingung taugt dann etwas, wenn ein Außenstehender ohne Nachfrage entscheiden könnte, ob sie erfüllt ist.

Zwei Zusatzregeln haben sich bei mir bewährt. Erstens setze ich eine Obergrenze für die Zahl der Runden, damit der Durchlauf auch dann endet, wenn das Ziel unerreichbar ist. Zweitens formuliere ich lieber ein zu enges Ziel als ein zu weites. Ein Loop, der zu früh stoppt, kostet mich einen zweiten Anlauf. Ein Loop, der nicht stoppt, kostet Geld.

Wenn du merkst, dass du deine Bedingung nicht sauber aufschreiben kannst, ist das übrigens kein Grund aufzugeben. Es ist meistens das Signal, dass die Aufgabe noch zu groß geschnitten ist. Ich teile sie dann in zwei kleinere, die je eine eigene Prüfung haben.

Das 80-Prozent-Problem: was Agenten zuverlässig übersehen

Es gibt ein Muster, das in der Fachdiskussion einen eigenen Namen bekommen hat: das 80-Prozent-Problem. Agenten erledigen die sichtbaren 80 Prozent einer Aufgabe verlässlich und übersehen die unsichtbaren 20 Prozent, die außerhalb ihres Blickfelds liegen.

Diese fehlenden 20 Prozent sind keine Kleinigkeiten zum Aufräumen. Es geht um Fehlerbehandlung, Sicherheitsprüfungen, Randfälle und Stellen, die an anderer Stelle im Projekt mitgeändert werden müssten. Der Grund dafür ist nachvollziehbar: Ein Modell schreibt den Normalfall, weil der Normalfall in seinen Trainingsdaten am häufigsten vorkommt. Randfälle sind naturgemäß schlecht dokumentiert. Jonathan Beard hat das in seinem Beitrag The 80% Problem ausführlich beschrieben.

Für mich als Betreiber heißt das konkret: Nach einem Durchlauf schaue ich mir an, was der Agent nicht angefasst hat. Wenn er ein Formular geändert hat, prüfe ich, ob die Seiten drumherum noch funktionieren. Die Arbeit verschwindet nicht, sie verschiebt sich vom Bauen zum Kontrollieren.

Agentic Engineering: der Begriff, der Vibe Coding ablösen soll

Parallel dazu taucht immer häufiger Agentic Engineering auf. Gemeint ist die reifere Variante, bei der Architektur, Tests und Qualitätssicherung von Anfang an dazugehören statt nachträglich draufgesetzt zu werden. Laut heise online soll dieser Begriff den des Vibe Coding ablösen.

Für Entwicklerteams ist die Unterscheidung wichtig. Für dich als Webseitenbetreiber ist sie es weniger. Was zählt, ist der gemeinsame Kern: Du gibst Ziele und Leitplanken vor, der Agent arbeitet, jemand prüft das Ergebnis, und die Verantwortung bleibt bei dir.

Ich verwende in der Praxis keinen der beiden Begriffe. Ich sage „ich lasse das durchlaufen“. Die Bezeichnung ändert nichts daran, wie gut das Ergebnis wird.

Welche Tools brauchst du dafür?

Diese Arbeitsweise braucht ein Werkzeug, das nicht nur Text ausgibt, sondern handeln darf. Ich nutze dafür Claude Code, weil es direkt am Server und an der WordPress-Installation arbeitet. Was das Werkzeug im Detail kann, steht in meinem Überblick dazu, was Claude Code ist.

Verbreitet sind außerdem Cursor als Editor mit eingebautem Agent-Modus, GitHub Copilot im Entwickler-Umfeld sowie die Gemini CLI von Google. Alle drei Tools setzen anders an als ein reiner Chat. Die meisten dieser Tools setzen voraus, dass du in einer Entwicklungsumgebung arbeitest. Warum ich mich trotzdem gegen ein zweites Abo entschieden habe, steht im Vergleich Claude Code vs. Cursor.

Ein Baustein, der in fast jedem meiner Loops steckt, sind wiederverwendbare Anweisungen. Statt jedes Mal neu zu erklären, wie eine Aufgabe zu lösen ist, halte ich den Ablauf einmal fest. Wie ich mir solche Claude Code Skills als Nicht-Entwickler baue, habe ich separat beschrieben.

Für wen lohnt sich diese Arbeitsweise und für wen nicht?

Meine Antwort hängt weniger von deinen Programmierkenntnissen ab als von deiner Erfahrung mit KI und davon, wie genau du beschreiben kannst, was du willst.

Probier es aus, wenn: Du im Umgang mit Claude oder einer anderen KI geübt bist, schon mehrfach an Websites damit gearbeitet hast, eine klare Vorstellung vom Ergebnis hast und diese exakt formulieren kannst. Genau das ist die eigentliche Voraussetzung, nicht das Programmieren.

Lass es vorerst, wenn: Du gerade erst anfängst, dein Ziel eher ein Gefühl als eine Beschreibung ist, oder du auf einem System arbeitest, das du selbst nicht überblickst. Dann fehlt dir der Maßstab, um zu erkennen, ob das Ergebnis taugt.

Und in jedem Fall: Lass den ersten Durchlauf nicht unbeaufsichtigt. Nicht weil die Technik unzuverlässig wäre, sondern weil du beim ersten Mal noch nicht weißt, wie viele Runden deine Aufgabe braucht. Genau da tappt man in die Kostenfalle. Wenn du noch ganz am Anfang stehst, ist mein Einstieg für Anfänger der bessere Startpunkt.

Häufige Fragen zu Agentic Coding

Was ist Agentic Coding einfach erklärt?

Agentic Coding bedeutet, dass du einer KI ein Ziel vorgibst und ein Agent die Aufgabe selbstständig in mehreren Schritten erledigt: bauen, prüfen, nachbessern, erneut prüfen, bis das Ziel erreicht ist. Du beschreibst das Ergebnis und die Abbruchbedingung, nicht jeden einzelnen Schritt.

Was ist der Unterschied zwischen Vibe Coding und Agentic Coding?

Beim Vibe Coding prüfst du das Ergebnis am Ende selbst. Beim agentischen Arbeiten prüft nach jedem Durchlauf eine eigene Instanz, ob das Ziel erreicht ist, und der Loop läuft weiter, bis es stimmt. Vibe Coding fragt, ob dir das Ergebnis gefällt, Agentic Coding fragt, ob es die Prüfung besteht.

Was ist das 80-Prozent-Problem?

Agenten erledigen die sichtbaren 80 Prozent einer Aufgabe zuverlässig und übersehen die unsichtbaren 20 Prozent: Fehlerbehandlung, Sicherheit, Randfälle und Stellen, die an anderer Stelle mitgeändert werden müssten. Der Grund ist, dass Modelle den Normalfall schreiben, weil er in den Trainingsdaten am häufigsten vorkommt.

Was ist Loop Engineering?

Loop Engineering bezeichnet das gezielte Entwerfen solcher Schleifen aus drei Bausteinen: Trigger, Verifikation und Abbruchbedingung. Der Begriff kam im Juni 2026 unabhängig voneinander von Peter Steinberger, Boris Cherny und Addy Osmani auf.

Braucht man dafür Programmierkenntnisse?

Zum Starten nicht. Ich betreibe über 50 Websites ohne programmieren zu können. Was du brauchst, ist die Fähigkeit, ein Ziel exakt zu beschreiben und zu erkennen, wann es erreicht ist. Ohne diesen Maßstab kannst du das Ergebnis nicht beurteilen.

Wie teuer wird ein solcher Loop?

Die Kosten wachsen mit der Zahl der Durchläufe, nicht mit der Größe der Aufgabe, weil jeder Durchlauf ein vollständiger Agenten-Durchgang ist. Eine Aufgabe in drei Runden kostet ein Drittel derselben Aufgabe in neun Runden. Deshalb ist eine klare Abbruchbedingung der wirksamste Kostenhebel.

Ist agentische KI gut zum Programmieren geeignet?

Für abgegrenzte Aufgaben auf einem System, das du überblickst, ja. Für komplexe Software mit hohen Anforderungen an Sicherheit und Wartbarkeit bleibt geprüftes Fachwissen nötig, entweder deines oder das eines Entwicklers, der das Ergebnis kontrolliert.