Loop Engineering und Spec-driven Development lösen die zwei Hälften desselben Problems. Ein Loop hält einen KI-Coding-Agent am Arbeiten, ohne dass du ihn promptest; eine Spec sagt dem Loop, was „fertig“ heißt. Ohne Spec weiß ein Loop nie, wann er aufhören soll; ohne Loop wartet eine Spec darauf, dass du an sie denkst.

Zwei Ideen, wenige Monate auseinander

Spec-driven Development war die Antwort auf die erste Wand, gegen die man mit Coding-Agents läuft: Vage Prompts erzeugen plausiblen Code, der das Falsche tut. Schreib zuerst die Spec – Scope, Dateien, Akzeptanzkriterien –, und der Agent baut öfter das Richtige.

Loop Engineering war die Antwort auf die nächste Wand: Selbst mit guten Specs startest du jeden Lauf noch selbst. Entwirf einen Loop, der den Agent weckt, ihm eine Aufgabe gibt und das Ergebnis prüft, und die Arbeit läuft weiter, während du etwas anderes machst.

Meist werden die beiden getrennt diskutiert. Das sollten sie nicht.

Ein Loop braucht eine Abbruchbedingung. Eine Spec ist eine.

Jede ernsthafte Beschreibung von Loop Engineering – Addy Osmanis Essay, Anthropics „Getting started with loops“, die arXiv-Studie – kommt auf dieselbe Anforderung zurück: Ein Loop läuft, bis eine Bedingung wahr ist, die eine Maschine prüfen kann. „Verbessere das Onboarding“ ist keine Bedingung. „Die drei Akzeptanzkriterien in dieser Spec sind erfüllt“ schon.

Schau dir an, was in einer guten Spec steht:

  • Was sich ändert und warum – die Aufgabe für diesen Lauf des Loops.
  • Welche Dateien – die Grenze, innerhalb derer der Agent bleiben soll.
  • Akzeptanzkriterien – die Checkliste der Prüfinstanz.
  • Out of Scope – wohin der Loop nicht abschweifen darf.

Das sind Aufgabe, Grenze, Prüfinstanz und Leitplanke eines Loops, aufgeschrieben, bevor der Lauf beginnt. Spec-driven Development ist die Art, wie du die Abbruchbedingung eines Loops gut schreibst.

Eine Spec braucht einen Loop, sonst veraltet sie

Die häufigste Klage über Spec-driven Development ist, dass Specs einfrieren: einmal geschrieben, nach der ersten Überraschung falsch, ab der zweiten Woche ignoriert (lebende vs. eingefrorene Specs). Ein Loop löst das von der anderen Seite. Wenn der Loop gegen die Spec prüft, muss sie stimmen – und wenn die Arbeit gemergt wird, schließt sich die Spec, sodass das Board zeigt, was wirklich ausgeliefert wurde.

Wer schreibt die Spec?

Hier treffen die beiden Ideen auf eine praktische Frage. Wenn jeder Loop eine Spec braucht, muss jemand sehr viele Specs schreiben. Es gibt zwei Quellen:

  • Du, wenn du weißt, was gebaut werden soll. Klassisches Spec-driven Development.
  • Ein anderer Loop, wenn es um Arbeit geht, von der du noch nichts wusstest – eine Sicherheitslücke in der Änderung von gestern, ein Webhook, der sich per Replay erneut auslösen lässt, eine Query ohne Index. Ein Loop, der die Codebase beobachtet, findet das Problem und schreibt die Spec; ein zweiter Loop (dein Coding-Agent) baut sie.

Die zweite Quelle ist die spannende. Sie macht den Unterschied zwischen einem Agent, der erledigt, worum du ihn bittest, und einem Produkt, das sich selbst verbessert.

Wie Tekk beides zusammenbringt

Tekk betreibt die Loops, die Arbeit finden, und führt die Specs:

  1. Sechzehn Loops beobachten deine Codebase – Security, Reliability, Backend, Payments, Performance, Testing, React, Code quality, AI engineering, Observability, Alerts, Product analytics (die Liste). Jeder wacht auf, wenn sich dein Code ändert, wenn Sentry anschlägt oder wenn ein Teil seines Bereichs zu lange nicht angesehen wurde.
  2. Aus einem Fund wird ein Proposal mit dem, was dem Loop aufgefallen ist, und dem, was er tun würde. Du gibst es mit Greenlight frei oder lehnst es ab.
  3. Aus einem freigegebenen Proposal wird eine Spec auf deinem Board – Scope, Dateien, Akzeptanzkriterien, eine Checkliste mit der Build-Reihenfolge. Du kannst Specs auch per Hand schreiben; sie landen auf demselben Board.
  4. Dein Coding-Agent baut die Spec über den Tekk-MCP-Server – Claude Code, Codex oder Cursor.
  5. Der Merge schließt sie. Ein PR mit Closes TEK-123 schließt die Spec ab, aber erst, wenn ihre Checkliste abgehakt ist (so funktioniert das). Die Checkliste ist die Abbruchbedingung.
  6. Der Merge speist den nächsten Lauf. Er ist die nächste Änderung, die die Loops lesen.

Specs sind die Arbeitseinheit. Loops sorgen dafür, dass Arbeit hereinkommt und abgeschlossen wird. Tekk selbst schreibt nie Code und liefert keinen aus.

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.