Loop Engineering erklärt: Schleifen bauen statt Prompts tippen

„Ich prompte Claude nicht mehr. Ich habe Loops laufen, die Claude prompten und herausfinden, was zu tun ist. Mein Job ist es, Loops zu schreiben.” Dieser Satz stammt von Boris Cherny, dem Kopf hinter Claude Code bei Anthropic – und er klingt erst mal verwirrend. Du sollst also gar nicht mehr mit der KI reden, sondern eine Maschine bauen, die mit ihr redet?

Genau darum geht es bei Loop Engineering. Es ist der Begriff, der gerade die Runde macht, seit auch Entwickler wie Peter Steinberger sagen: „Du solltest Coding-Agenten nicht mehr prompten. Du solltest Loops designen, die deine Agenten prompten.” Dieser Artikel erklärt dir ruhig und ohne Hype, was damit gemeint ist, wie so eine Agenten-Schleife technisch funktioniert, aus welchen Bausteinen ein guter Loop besteht – und wo das Ganze schiefgehen kann.

Wenn die Begriffe KI-Agent und agentisches Arbeiten für dich noch neu sind, lies vorher kurz Was ist ein KI-Agent? Einfach erklärt und Agentic AI einfach erklärt. Den praktischen Vorläufer auf der Ebene einer einzelnen Sitzung findest du unter Claude Code Workflow: Best Practices.

Was ist Loop Engineering?

Loop Engineering ist die Praxis, die Rückkopplungs-Schleifen zu entwerfen, zu betreiben und zu verbessern, mit denen ein KI-Agent eine Aufgabe plant, Code ändert, das Ergebnis prüft und seinen Ansatz anpasst – so lange, bis die Aufgabe erledigt ist. Kurz: Du treibst den Agenten nicht mehr selbst an, du baust das System, das ihn antreibt.

Zwei Jahre lang funktionierte die Zusammenarbeit mit einem Coding-Agenten so: Du schreibst einen guten Prompt, gibst genug Kontext mit, liest die Antwort, tippst die nächste Anweisung. Der Agent ist ein Werkzeug, und du hältst es die ganze Zeit in der Hand – ein Zug nach dem anderen. Loop Engineering verschiebt diesen Hebel. Statt jeden Schritt selbst auszulösen, baust du ein kleines System, das die Arbeit findet, sie verteilt, das Ergebnis prüft, notiert, was erledigt ist, und dann den nächsten Schritt entscheidet. Du designst diese Schleife einmal – und lässt sie den Agenten anstoßen statt dich.

Es hilft, Loop Engineering von zwei verwandten Begriffen abzugrenzen, die du vielleicht schon kennst:

Prompt Engineering formt die Eingabe an das Modell – die eine Frage möglichst gut stellen.
Context Engineering formt das, was der Agent sieht – welche Dateien, Tools und Informationen in seinem Kontextfenster landen.
Loop Engineering formt den gesamten Prozess rund um das Modell – welche Werkzeuge es nutzen darf, welche Prüfung ihm vertraut wird, wann es stoppt und wo ein Mensch eingreift.

Der Unterschied ist mehr als Wortklauberei: Eine starke erste Antwort ist nicht dasselbe wie eine korrekte fertige Änderung. In echtem Code zeigt sich das wichtige Signal oft erst nach der ersten Aktion – ein fehlgeschlagener Test, ein Typfehler, ein Reviewer, der einen Sonderfall findet. Loop Engineering macht diese Signale zum Teil des Systems, statt sie als nachträgliches Aufräumen zu behandeln.

Loop Engineering umfasst Prompt- und Context-Engineering – es formt den gesamten Prozess rund um das Modell.

Warum ein einzelner Prompt nicht reicht

Programmieren ist von Natur aus ein iterativer Prozess: Selbst erfahrene Entwickler schreiben Code selten auf den ersten Versuch perfekt. Sie lassen ihn laufen, sehen den Fehler, korrigieren, lassen ihn erneut laufen. Ein Agent, der nur einmal Code generiert, kann diese Schleife nicht schließen – und bleibt deshalb grundsätzlich begrenzt.

Die meisten modernen Agenten-Schleifen gehen auf das ReAct-Muster zurück (Reason + Act), das aus einer Forschungsarbeit von Princeton und Google stammt. Die Idee: Denk-Schritte und Handlungs-Schritte abwechseln. Das Modell überlegt, führt eine Aktion aus, sieht das Ergebnis, überlegt erneut, handelt erneut. Im Code sieht das so aus: Ziel verstehen → Code schreiben → ausführen und Ausgabe (oder Fehler) beobachten → über das Problem nachdenken → überarbeiten → wiederholen, bis die Tests grün sind.

Wichtig ist der Unterschied zwischen einer Schleife und einer Kette. Eine Kette läuft linear: Schritt A führt zu B führt zu C. Eine Schleife ist dynamisch: Der Agent kann von A nach B gehen, feststellen, dass B nicht funktioniert, mit einem anderen Ansatz erneut versuchen – und erst dann weiterziehen. Genau diese Fähigkeit, aus dem Ergebnis zu lernen, unterscheidet einen Agenten von einem reinen Textgenerator.

Erstaunlich daran ist, wie simpel der Kern technisch ist. Viele der erfolgreichsten Agenten – darunter Claude Code – teilen dieselbe schlichte Architektur: eine while-Schleife, die Tools aufruft.

while (nicht fertig) {
  antwort = frage_das_modell()
  wenn antwort.tool_aufrufe:
    fuehre_tools_aus_und_haenge_ergebnisse_an()
  sonst:
    fertig
}

Das ist im Grunde alles. Jede Runde gibt den aktuellen Stand an das Modell, bekommt eine Entscheidung zurück (meist ein Tool-Aufruf oder eine Textantwort) und macht weiter. Der Agent ist nur ein System-Prompt und eine Handvoll gut gebauter Werkzeuge. Die ganze Magie steckt nicht im Modell allein, sondern darin, wie sauber diese Schleife gebaut ist.

Wie die Agenten-Schleife technisch funktioniert

Jede Agenten-Sitzung folgt demselben Zyklus: Prompt empfangen, bewerten und antworten, Tools ausführen, wiederholen – bis das Modell eine Antwort ohne weitere Tool-Aufrufe liefert.

Am Beispiel von Claude Code lässt sich das gut nachvollziehen. Stell dir den Auftrag vor: „Repariere die fehlschlagenden Tests in auth.ts.”

Empfangen: Der Agent bekommt deinen Prompt, dazu den System-Prompt, die Tool-Definitionen und den bisherigen Verlauf.
Bewerten & antworten: Das Modell schätzt die Lage ein und entscheidet, wie es weitergeht – Turn 1: Es ruft das Bash-Tool auf und lässt npm test laufen (drei Fehler).
Tools ausführen: Das Ergebnis fließt zurück ins Modell – Turn 2: Es liest auth.ts und die Test-Datei.
Wiederholen: Turn 3: Es ändert den Code und lässt die Tests erneut laufen. Alle grün.
Zurückgeben: Letzter Turn: Eine reine Textantwort ohne Tool-Aufruf – „Bug behoben, alle drei Tests laufen.” Die Schleife endet.

Eine Sitzung durchläuft denselben Zyklus – bewerten, Tools ausführen, wiederholen – bis das Modell ohne weiteren Tool-Aufruf antwortet.

Ein Turn ist also eine Runde innerhalb der Schleife. Eine kurze Frage („Welche Dateien gibt es hier?”) braucht ein, zwei Turns. Eine komplexe Aufgabe („Refaktoriere das Auth-Modul und passe die Tests an”) kann Dutzende Tool-Aufrufe über viele Turns verketten.

Zwei Dinge solltest du dabei im Blick behalten:

Das Kontextfenster wächst. Es setzt sich zwischen den Turns nicht zurück – System-Prompt, Tool-Definitionen, Verlauf, Tool-Eingaben und vor allem Tool-Ausgaben sammeln sich an. Tatsächlich machen Tool-Ausgaben in einer typischen Agenten-Sitzung den Löwenanteil der Tokens aus, nicht der Prompt. Deshalb ist sauberer Kontext kein Nebenthema, sondern entscheidend für Qualität und Kosten. Mehr dazu in Claude Code Workflow.
Die Schleife braucht eine Bremse. Ohne Limit läuft sie, bis das Modell von selbst fertig ist – bei offenen Aufträgen („verbessere diese Codebase”) kann das lange dauern und teuer werden. Werkzeuge bieten dafür Obergrenzen wie eine maximale Anzahl Turns oder ein Kosten-Budget, ab dem gestoppt wird.

Zur Prüfung: Die genauen Namen der Optionen (etwa für Turn- oder Budget-Limits) und der Slash-Befehle ändern sich zwischen Versionen. Den aktuellen Stand findest du in der offiziellen Claude-Code-Dokumentation.

Die fünf Bausteine eines Loops

Ein vollständiger Loop braucht fünf Bausteine plus einen Ort zum Erinnern: Automatisierungen, Worktrees, Skills, Plugins/Connectors und Subagents – und ein Gedächtnis außerhalb des Gesprächs.

Das Spannende: Diese Bausteine sind heute kein selbstgebauter Bash-Haufen mehr, den du ewig pflegen musst. Sie kommen fertig in den Produkten – in Claude Code genauso wie in der Codex-App. Sobald du diese Form einmal erkennst, hörst du auf, über das Tool zu streiten, und designst einfach einen Loop, der überall funktioniert.

Automatisierungen – der Herzschlag. Sie machen aus einem einmaligen Lauf einen echten Loop. Ein Zeitplan (Cron), ein wiederkehrender Befehl wie /loop oder ein Trigger über GitHub Actions löst den Agenten aus, ohne dass du danebensitzt. Eine Automatisierung kann morgens die CI-Fehler von gestern sichten, offene Issues triagieren und die Funde in eine Datei schreiben.
Worktrees – damit parallel kein Chaos wird. Sobald zwei Agenten gleichzeitig arbeiten, kollidieren ihre Datei-Änderungen. Ein Git-Worktree ist ein separates Arbeitsverzeichnis auf einem eigenen Branch – so kann der eine Agent dem anderen nicht in den Code pfuschen.
Skills – damit du dein Projekt nicht jedes Mal neu erklärst. Ein Skill (ein Ordner mit einer SKILL.md) hält das Projektwissen fest, das der Agent sonst jedes Mal raten würde: Konventionen, Build-Schritte, „das machen wir wegen Vorfall X nicht so”. Ohne Skills leitet der Loop dein Projekt in jedem Durchlauf bei null neu her. Mehr dazu: Claude Skills.
Plugins und Connectors – der Loop fasst deine echten Tools an. Connectors (gebaut auf MCP) lassen den Agenten dein Issue-Tracking lesen, eine Datenbank abfragen, eine Nachricht in Slack ablegen. Das ist der Unterschied zwischen „hier wäre der Fix” und einem Loop, der selbst den Pull Request öffnet und das Ticket verlinkt, sobald die CI grün ist.
Subagents – trenne den Macher vom Prüfer. Das mit Abstand Nützlichste in einem Loop: den, der den Code schreibt, von dem trennen, der ihn prüft. Das Modell, das seinen eigenen Code benotet, ist viel zu nachsichtig. Ein zweiter Agent mit anderen Anweisungen – oft sogar einem anderen Modell – fängt, was der erste sich schöngeredet hat. Wie das praktisch geht, steht in Claude Code Subagents.

Und dann das Sechste, das Gedächtnis: eine Markdown-Datei oder ein Ticket-Board, das außerhalb des einzelnen Gesprächs lebt und festhält, was erledigt ist und was als Nächstes ansteht. Klingt zu banal, um wichtig zu sein – ist aber der Trick, von dem jeder langlaufende Agent abhängt. Das Modell vergisst alles zwischen den Läufen; das Repository nicht. Deshalb muss das Gedächtnis auf der Festplatte liegen, nicht im Kontext.

Fünf Bausteine plus ein Gedächtnis außerhalb des Gesprächs: Das Modell vergisst zwischen den Läufen – das Repository nicht.

Loops stapeln: vom Agenten zur Selbstverbesserung

Der einfache Agenten-Loop ist nur die erste Ebene. Man kann Schleifen stapeln – swyx nennt das „Loopcraft” –, um Agenten Schritt für Schritt zuverlässiger zu machen. Vier Ebenen haben sich als nützliches Modell etabliert.

Ebene 1 – Der Agenten-Loop. Das Modell ruft Tools in einer Schleife auf, bis die Aufgabe erledigt ist. Diese Ebene automatisiert Arbeit.
Ebene 2 – Der Prüf-Loop (Verification). Der Agenten-Loop erledigt etwas, aber nicht immer korrekt. Hier wickelst du ihn in eine Prüf-Schleife: Ein „Grader” – ein deterministischer Test oder ein zweites Modell als Richter (LLM-as-a-Judge) – bewertet die Ausgabe gegen eine Vorgabe und schickt sie bei Fehlern mit Feedback zurück. Diese Ebene sichert Qualität. Sie kostet etwas mehr Zeit und Geld, lohnt sich aber, sobald Korrektheit zählt – also in den meisten Produktiv-Fällen.
Ebene 3 – Der ereignisgesteuerte Loop. Hier verbindest du den Agenten mit deinem Ökosystem: Ein neues Dokument landet, ein Zeitplan greift, ein Webhook trifft ein – und der Agent läuft. Er ist nichts mehr, das du manuell aufrufst, sondern eine Komponente, die dauerhaft in einem größeren System mitläuft. Diese Ebene bringt automatisierte Arbeit in den Maßstab.
Ebene 4 – Der Hill-Climbing-Loop. Die ersten drei Ebenen automatisieren Arbeit; die vierte automatisiert Verbesserung. Jeder Lauf hinterlässt eine Spur (Trace): was das Modell tat, welche Tools es rief, welches Grader-Feedback kam. Ein Analyse-Agent wertet diese Spuren aus und schreibt damit den „Harness” – Prompts, Tools, Grader – selbst um. Der Rückkopplungs-Pfeil schließt nicht nur zum Anfang zurück, er greift in die inneren Schleifen ein und macht sie mit jedem Durchlauf besser.

Loops stapeln sich: Jede äußere Schleife macht die inneren zuverlässiger – die vierte verbessert sogar den Harness selbst.

Diese Stapelung ist die eigentliche Pointe von Loop Engineering. KI-Forscher und -Praktiker wie Peter Steinberger, Boris Cherny und Andrej Karpathy sind unabhängig zur selben Schlussfolgerung gekommen: Das Potenzial steckt nicht im einzelnen Modell-Aufruf, sondern in den Schleifen, die du darum herum baust. Wenn mehrere Agenten in koordinierten Schleifen zusammenspielen – ein Planer, mehrere Ausführende, ein Prüfer –, sprichst du von Multi-Agenten-Systemen. Die Frameworks, die das organisieren, vergleicht KI-Agenten Frameworks im Vergleich.

Was einen guten Loop ausmacht

Ein guter Loop ist nicht „lass den Agenten einfach weiter probieren”. Er ist um fünf Dinge herum gebaut: ein klares Ziel, den richtigen Kontext, kleine umkehrbare Schritte, verlässliche Beobachtung und explizite Stopp-Regeln.

Klares Ziel. Der Loop braucht eine konkrete Definition von „fertig”. „Verbessere das Dashboard” ist wertlos. „Reduziere die anfängliche Ladezeit, indem du nicht-kritische Charts nachlädst, ohne die Filter zu brechen” gibt dem Agenten etwas Beobachtbares zum Optimieren.
Relevanter Kontext. Zu wenig Kontext führt zu falschen Annahmen, zu viel ertränkt das Modell in Rauschen. Der Loop sollte Kontext vor dem Ändern sammeln und ihn nach wichtigen Beobachtungen auffrischen.
Kleine, umkehrbare Schritte. Ein kleines Diff ist leichter zu prüfen und leichter zu reparieren. Große spekulative Umschreibungen verschleiern, welche Annahme gescheitert ist. Lass den Agenten die kleinste sinnvolle Änderung machen und erst ausweiten, wenn das Ergebnis es stützt.
Verlässliche Beobachtung. Ein Loop ist nur so gut wie seine Beobachtungen. Kann der Agent die Tests nicht laufen lassen, die Compiler-Ausgabe nicht sehen, die Oberfläche nicht per Screenshot prüfen, arbeitet er teilweise blind. Gute Beobachtbarkeit verwandelt vages Vertrauen in Belege.
Stopp-Regeln. Der Agent muss wissen, wann Schluss ist – wenn das gewünschte Verhalten implementiert ist und die Prüfung grün ist, wenn ein Blocker fehlende Zugangsdaten oder eine Produktentscheidung erfordert, oder bevor ein zerstörerischer Befehl ohne ausdrückliche Freigabe liefe.

Daraus ergeben sich ein paar wiederkehrende Loop-Patterns, je nach Aufgabe:

Retry-Loop: Versuchen, prüfen, bei Fehlschlag erneut versuchen. Gut für kurze Aufgaben mit klarem Bestanden/Durchgefallen – aber nur mit Strategiewechsel, sonst dreht er sich im Kreis.
Plan-Execute-Verify-Loop: Erst einen Plan erstellen, dann Schritt für Schritt umsetzen und jeden Schritt prüfen. Gut für mehrstufige Aufgaben, bei denen frühe Fehler sich aufschaukeln.
Explore-Narrow-Loop: Mehrere Lösungswege erkunden, dann auf den vielversprechendsten eingrenzen. Gut für Debugging und unbekannte APIs – Vorsicht vor Kontext-Explosion.
Human-in-the-Loop: Der Agent läuft, bis er eine Entscheidung oder Freigabe braucht, pausiert für deine Eingabe und macht dann weiter. Gut für riskante oder unvollständig spezifizierte Aufgaben.

Wo Loops schiefgehen

Schlecht gebaute Loops verursachen echte Probleme – und die häufigsten Fehler sind vorhersehbar. Jeder zeigt auf einen fehlenden Teil der Schleife zurück.

Thrashing. Der Agent ändert Code immer wieder, ohne zu konvergieren. Meist heißt das: unklares Ziel, verrauschtes Prüf-Signal oder ein zu großes Diff. Gegenmittel: Ziel verengen, Diff verkleinern, verlässlichere Beobachtung.
Overfitting auf Tests. Der Agent macht die Tests grün, verfehlt aber die eigentliche Anforderung – besonders, wenn die Tests zu eng sind. Gegenmittel: automatische Tests mit Anforderungs-Review und, wo nötig, manueller Prüfung kombinieren.
Context Drift. Der Agent arbeitet mit veralteten Annahmen weiter, übersieht eine Änderung oder einen neuen Fehler. Gegenmittel: Kontext nach wichtigen Beobachtungen auffrischen und den ursprünglichen Plan nicht für heilig halten.
Unsichere Autonomie. Mehr Autonomie ist nicht automatisch besser. Ein Agent, der zerstörerische Befehle ausführen oder ungeprüft pushen kann, richtet Schaden an. Gegenmittel: Berechtigungen, eng zugeschnittene Tools, menschliche Freigabe für Riskantes. Hier helfen Claude Code Hooks, um an festen Punkten der Schleife einzugreifen.
Kein Exit. Ohne explizite Abbruchbedingung läuft der Loop endlos oder stoppt willkürlich. Eine Stopp-Regel wie „nach 10 Durchläufen ohne Fortschritt an einen Menschen eskalieren” ist kein Beiwerk, sondern Pflichtbestandteil.

Die häufigsten Fehlmuster sind vorhersehbar – jeder zeigt auf einen fehlenden Teil der Schleife.

Wie es weitergeht

Grundlage: Was ist ein KI-Agent?
Baustein Macher/Prüfer: Claude Code Subagents
Baustein Eingriffspunkte: Claude Code Hooks
Eine Ebene tiefer: Claude Code Workflow
Der große Überblick: Claude Code, MCP & KI-Agenten

Du bleibst der Ingenieur

Der Loop verändert die Arbeit, er löscht dich nicht aus ihr. Drei Probleme werden sogar schärfer, je besser der Loop wird – nicht einfacher.

Erstens: Die Prüfung bleibt an dir. Ein Loop, der unbeaufsichtigt läuft, ist auch ein Loop, der unbeaufsichtigt Fehler macht. Genau deshalb trennst du den Prüfer-Subagenten vom Macher – damit das „ist fertig” des Loops etwas bedeutet. Und selbst dann ist „fertig” eine Behauptung, kein Beweis. Dein Job ist es, Code auszuliefern, von dem du bestätigt hast, dass er funktioniert.

Zweitens: Dein Verständnis verrottet, wenn du es zulässt. Je schneller der Loop Code ausliefert, den du nicht selbst geschrieben hast, desto größer die Lücke zwischen dem, was existiert, und dem, was du wirklich verstehst. Ein glatter Loop lässt diese Lücke schneller wachsen – es sei denn, du liest, was er gebaut hat.

Drittens: Die bequeme Haltung ist die gefährliche. Wenn der Loop sich selbst antreibt, ist es verlockend, keine eigene Meinung mehr zu haben und einfach zu nehmen, was zurückkommt. Den Loop zu designen ist das Heilmittel, wenn du es mit Urteilsvermögen tust – und der Brandbeschleuniger, wenn du es tust, um das Nachdenken zu vermeiden. Dieselbe Handlung, gegenteiliges Ergebnis.

Das ist es, was Loop-Design schwerer macht als Prompt Engineering, nicht leichter. Zwei Menschen bauen denselben Loop und bekommen entgegengesetzte Ergebnisse: Der eine nutzt ihn, um bei Arbeit schneller zu werden, die er tief versteht. Der andere nutzt ihn, um das Verständnis ganz zu vermeiden. Der Loop kennt den Unterschied nicht. Du schon.

FAQ: Häufige Fragen zu Loop Engineering

Was ist Loop Engineering einfach erklärt?

Loop Engineering ist die Praxis, KI-Systeme zu bauen, die nicht nur einmal antworten, sondern in Schleifen arbeiten: eine Aktion ausführen, das Ergebnis beobachten, darüber nachdenken und wiederholen, bis ein Ziel erreicht ist. Statt den KI-Agenten bei jedem Schritt selbst anzustoßen, designst du das System, das ihn anstößt – mit Werkzeugen, Prüfungen, Stopp-Regeln und klaren Punkten für menschliche Eingriffe.

Was ist der Unterschied zwischen Loop Engineering und Prompt Engineering?

Prompt Engineering formt die Eingabe an das Modell – die eine Frage möglichst gut stellen. Loop Engineering formt den gesamten iterativen Prozess rund um das Modell: welche Tools es nutzen darf, welchen Kontext es sieht, welcher Prüfung es vertraut, wann es stoppt und wo ein Mensch eingreift. Prompt Engineering zielt auf eine bessere erste Antwort, Loop Engineering auf ein besseres Endergebnis.

Was ist der Unterschied zwischen einer Schleife und einer Kette bei KI-Agenten?

Eine Kette läuft in fester Reihenfolge: A → B → C. Eine Schleife ist dynamisch – der Agent kann Schritte wiederholen, anhand von Feedback anpassen oder mit einem anderen Ansatz erneut versuchen. Ketten sind vorhersehbar und leicht nachzuvollziehen. Schleifen sind flexibler und besser für Aufgaben, bei denen der richtige Weg vorab nicht feststeht, etwa Debugging.

Brauche ich Loop Engineering nur als Entwickler?

Der Begriff stammt aus dem Coding-Umfeld und ist dort am ausgereiftesten, weil Code von Natur aus prüfbar ist (Tests, Compiler). Das Prinzip – handeln, beobachten, anpassen, wiederholen – gilt aber überall, wo eine Aufgabe mehrere Schritte und echtes Feedback braucht. Wer die Grundideen kennt, vor allem klare Stopp-Bedingungen und Fehlerbehandlung, baut auch ohne Programmierkenntnisse bessere Agenten.

Was macht einen Loop „gut”?

Ein guter Loop hat fünf Dinge: ein konkretes Ziel mit prüfbarer Abbruchbedingung, einen nützlichen Satz an Werkzeugen, sauberes Kontext-Management gegen Token-Überlauf, explizite Fehler-Exits gegen Endlosschleifen und eine Fehlerbehandlung, die echte Anpassung erzeugt statt denselben gescheiterten Versuch zu wiederholen.

Fazit

Loop Engineering ist kein neuer Geheimtrick, sondern eine Verschiebung des Hebels: weg vom perfekten Einzel-Prompt, hin zum Design verlässlicher Systeme aus Kontext, Aktion, Beobachtung und Korrektur. Der Kern ist erstaunlich simpel – eine Schleife, die Tools aufruft, bis eine Aufgabe erledigt ist. Die Kunst steckt in den Rändern: gut gebaute Werkzeuge, sauberer Kontext, ein Prüfer, der vom Macher getrennt ist, und Stopp-Regeln, die etwas bedeuten.

Wenn du mit dem konkreten Handwerk anfangen willst, beginn hier: Claude Code Workflow: Best Practices und Claude Code Subagents. Und für das große Bild rundherum: Claude Code, MCP & KI-Agenten: der große Überblick. Bau die Schleife – aber bau sie wie jemand, der der Ingenieur bleiben will, nicht nur die Person, die auf „Start” drückt.