Loop Engineering heißt: Du entwirfst den Loop, der deinem KI-Coding-Agent die Prompts gibt – was ihn weckt, welche Aufgabe er bekommt, wie seine Arbeit geprüft wird und wann er aufhört –, statt den Agent selbst Runde für Runde per Hand zu prompten. Deine Arbeit als Engineer verschiebt sich vom Schreiben von Prompts zum Schreiben von Loops.

Woher der Begriff kommt

Der Begriff hob im Juni 2026 ab. Boris Cherny, der Claude Code bei Anthropic leitet, sagte in einem Talk, er prompte Claude nicht mehr – sein Job sei es, Loops zu schreiben (The New Stack). Wenige Tage später schrieb Peter Steinberger, der OpenClaw entwickelt hat, man solle Coding-Agents nicht mehr prompten, sondern Loops entwerfen, die das übernehmen. Addy Osmani fasste die Idee in einem Essay zusammen und gab ihr eine Struktur, „Loop engineering“, und Ende Juni veröffentlichte Anthropic im Claude-Blog „Getting started with loops“. Im Juli berichtete die Fachpresse darüber (ADTmag), und im August veröffentlichten Forschende die erste Studie dazu, „Loop Engineering: Building Blocks, Adoption, and Impact“.

Prompt, Kontext, Harness, Loop

Das arXiv-Paper ordnet Loop Engineering als nächste Stufe einer Treppe ein, die viele schon hinaufgestiegen sind:

  • Prompt Engineering – eine einzelne Anfrage gut formulieren.
  • Context Engineering – dem Agent die richtigen Dateien, Docs und die richtige Historie geben.
  • Harness Engineering – die Umgebung des Agents: Tools, Sandbox, Berechtigungen, Zustand.
  • Loop Engineering – der Zyklus drumherum: wann ein Lauf startet, was er tut, wie er geprüft wird, wann er aufhört und wann ein Mensch dazugeholt wird.

Eine hilfreiche Unterscheidung der letzten beiden stammt von Data Science Dojo: Das Harness ist Infrastruktur, die sich selten ändert; der Loop ist eine Policy, an der du ständig drehst. Ein Agent in Produktion braucht beides.

Die Teile eines Loops

Jede Beschreibung nennt dieselben paar Teile, nur unter leicht unterschiedlichen Namen:

  • Ein Auslöser. Loops starten nach Zeitplan oder auf ein Ereignis hin – einen Push, ein neues Issue, einen Fehler-Alert – und nicht dann, wenn jemand tippt.
  • Eine Aufgabe. Eine Aufgabe pro Lauf, eng genug, um fertig zu werden.
  • Zustand. Was frühere Läufe getan und entschieden haben, festgehalten in Dateien oder einer Datenbank, damit der nächste Lauf nicht bei null anfängt.
  • Eine Prüfinstanz. Eine separate Kontrolle der Arbeit – Tests, ein zweiter Agent, ein Mensch. Osmanis Variante: Ein Sub-Agent hat die Idee, ein anderer prüft sie.
  • Eine Abbruchbedingung. Etwas, das eine Maschine auswerten kann: Die Tests laufen durch, die Checkliste ist abgehakt, das Budget ist aufgebraucht.
  • Ein Eskalationspunkt. Der Moment, in dem der Loop eine Entscheidung an einen Menschen übergibt.
  • Ein Budget. Tokens und Zeit pro Lauf, damit ein Loop, der aus dem Ruder läuft, wenig kostet und nicht viel.

Osmanis Essay zählt die Bausteine auf der Tooling-Seite auf: geplante Automationen für Discovery und Triage, Worktrees, damit sich parallele Agents nicht in die Quere kommen, Skills, die Projektwissen festhalten, Connectors (MCP), um andere Systeme zu erreichen, und Sub-Agents, um Maker und Checker zu trennen.

Das Schwierige ist, zu wissen, wann Schluss ist

Code in einem Loop zu generieren ist billig; ihn zu beurteilen nicht. Darauf läuft das meiste hinaus, was über Loop Engineering geschrieben wird: Sobald ein Agent die ganze Nacht durchlaufen kann, ist die Prüfinstanz der Engpass. Ein Loop mit dem Auftrag „verbessere den Code“ weiß nie, wann er fertig ist, und ein Agent, der seine eigene Arbeit bewerten soll, winkt sie meist durch.

Ein guter Loop braucht deshalb eine Abbruchbedingung, die jemand vorher aufgeschrieben hat – eine Definition of Done, die der Loop prüfen kann. Genau das ist eine gute Spec: die Änderung, die Dateien und Akzeptanzkriterien, die ein Test auswerten kann. Deshalb sind Loop Engineering und Spec-driven Development zwei Hälften einer Idee; mehr dazu in Loop Engineering und Spec-driven Development.

Wo sich Loops lohnen – und wo nicht

Die arXiv-Studie hat Tausende öffentliche Repositories durchsucht und nur in einem kleinen Teil davon autonome Loops gefunden, meist für Pull-Request-Reviews und Issue-Triage. Das Forschungsteam merkt außerdem an, dass die meisten Aussagen über den Nutzen von Loops noch auf Anekdoten beruhen. Die Kritik ist berechtigt: The Register nannte es das neueste Buzzword, das immer noch Menschen im Loop braucht, und wer skeptisch ist, nennt es einen while-Loop um einen LLM-Call.

Beides stimmt. Ein Loop ist schnell gestartet und schwer vertrauenswürdig zu machen. Loops lohnen sich bei engen, wiederholbaren Fragen mit überprüfbarer Antwort: Hat diese Änderung eine Sicherheitslücke geöffnet, kann dieser Retry jemandem doppelt abbuchen, hat dieser neue Endpoint einen Test? Sie enttäuschen, wenn die Aufgabe vage ist, wenn die Prüfinstanz derselbe Agent ist, der die Arbeit gemacht hat, oder wenn niemand die Ergebnisse liest.

Loop Engineering auf deinem eigenen Produkt

Die meisten Loop-Engineering-Beispiele richten den Loop auf eine Aufgabe: Bau dieses Feature, behebe dieses Issue, mach weiter, bis die Tests grün sind. Dieselbe Maschinerie lässt sich auf ein ganzes Produkt richten: Loops, die Code und Produktion ständig im Blick behalten, finden, was sich ändern sollte, und es vorschlagen. Genau das lässt Software sich selbst verbessern.

Tekk nimmt dir das Loop Engineering für genau dieses Problem ab. Es lässt sechzehn Loops auf deiner Codebase laufen – Security, Reliability, Backend, Payments, Performance, Testing, React, Code quality, Architecture, AI engineering, Compliance, Observability, Alerts, Product analytics, Documentation und Customer feedback. Jeder davon:

  • wacht bei einem Auslöser auf – dein Code hat sich geändert, Sentry hat angeschlagen oder ein Teil seines Bereichs wurde zu lange nicht angesehen;
  • liest ein Briefing – was sich geändert hat, was er schon vorgeschlagen hat, was du abgelehnt hast und warum;
  • arbeitet eine Methode aus seinem Regal voller Skills von Anfang bis Ende ab;
  • hört bei einem Proposal auf – oder bei einem ehrlichen „nichts gefunden“;
  • eskaliert an dich – du gibst mit Greenlight frei oder lehnst ab, und deine Ablehnungen lenken den nächsten Lauf;
  • schließt ab, wenn der PR deines Coding-Agents mit Closes TEK-123 gemergt wird und die Checkliste der Spec abgehakt ist – und dieser Merge ist die nächste Änderung, die die Loops lesen.

Tekk schreibt nie Code und liefert keinen aus; das macht dein Coding-Agent, auf Grundlage einer Spec, die du freigegeben hast. Wenn du die Loops lieber selbst baust: So setzt du Loops auf dein Produkt an – mit oder ohne Tekk.

Teil des Leitfadens zu Loop Engineering. Die andere Hälfte von Loop Engineering ist Spec-driven Development: An der Spec erkennt ein Loop, dass er fertig ist.