Damit sich dein Produkt selbst verbessert, lass Loops darauf laufen: kleine, spezialisierte Routinen, die aufwachen, wenn sich dein Code ändert, nach einer bestimmten Art von Verbesserung suchen und sie als Spec mit klarer Ziellinie vorschlagen. Du gibst frei, was sich lohnt, dein Coding-Agent baut es, und jeder Merge wird zum Nächsten, was die Loops lesen – so wird das Produkt immer besser, ohne dass du ans Nachsehen denken musst.

Das ist die ganze Idee. Der Rest dieser Seite zeigt, wie du es aufsetzt – per Hand oder mit Tekk, das sechzehn solcher Loops für dich laufen lässt.

Was „sich selbst verbessern“ hier heißt

Software, die sich selbst verbessert, schreibt sich nicht im Dunkeln selbst um. Sie ist ein Produkt mit eingebautem Feedback-Loop: Etwas behält Code und Produktion ständig im Blick, bemerkt, was sich ändern sollte, und macht daraus Arbeit, die ein Coding-Agent erledigen kann. Was ausgeliefert wird, entscheidet weiterhin ein Mensch.

Vergleich das damit, wie sich die meisten Produkte heute verbessern. Die Sicherheitslücke findest du, wenn jemand aus der Kundschaft sie meldet. Die langsame Query findest du, wenn das Dashboard in einen Timeout läuft. Den Retry, der jemandem doppelt abgebucht hat, findest du, wenn dir diese Person eine Mail schreibt. Verbesserung passiert in Schüben, wenn zufällig jemand hinschaut. Ein Produkt, das sich selbst verbessert, schaut die ganze Zeit hin.

Die sechs Teile eines Produkts, das sich selbst verbessert

1. Leg fest, was „besser“ gerade heißt

Schreib die ein, zwei Ergebnisse auf, die dir diesen Monat wichtig sind: eine stabile v1, ein schnellerer Checkout, keine Abrechnungsfehler mehr. Loops ohne Richtung schlagen alles vor; Loops mit einem Ziel schlagen vor, was zählt. In Tekk ist das ein Goal – es richtet die Loops aus, statt selbst ein Loop zu sein.

2. Teil das Produkt in Bereiche auf, ein Loop pro Bereich

Ein einziger riesiger Prompt „verbessere den Code“ weiß nie, wann er fertig ist. Enge Loops wissen es. Typische Bereiche: Sicherheit, Zuverlässigkeit, Payments, Performance, Tests, deine KI-Features, Observability. Jeder Loop braucht seine eigene Definition davon, was als Fund zählt – ein Security-Fund ist ein Request, den jemand von außen tatsächlich stellen kann, kein Muster, das riskant aussieht.

3. Gib jedem Loop einen Auslöser

Ein Loop braucht einen Grund aufzuwachen. Diese drei funktionieren:

  • Dein Code hat sich geändert. Lies den Diff seit dem letzten Lauf und verfolge, worauf er sich auswirkt. Das ist günstig, und Probleme fallen auf, solange sie frisch sind.
  • Die Produktion hat sich gemeldet. Ein neuer Fehleranstieg oder eine langsame Transaktion in Sentry ist ein Ausgangspunkt für den Loop, der dafür zuständig ist.
  • Hier hat schon länger niemand hingeschaut. Code, der sich nicht mehr ändert, braucht trotzdem regelmäßig einen Blick, sonst verrottet er unbemerkt.

4. Mach aus jedem Fund eine Spec mit Abbruchbedingung

Hier scheitern die meisten selbstgebauten Loops. „Fix das Auth-Ding“ ist keine Ziellinie. Was ein Loop liefert, sollte eine Spec sein: was zu ändern ist, welche Dateien, und Akzeptanzkriterien, die ein Test prüfen kann. Die Spec ist die Abbruchbedingung des Loops – ist ihre Checkliste abgehakt, ist der Loop mit ihr fertig. (Mehr dazu in Loop Engineering und Spec-driven Development.)

5. Behalte eine menschliche Freigabe

Loops vervielfachen Fehler genauso leicht wie Verbesserungen. Setz eine Entscheidung zwischen einen Fund und deine Codebase: annehmen oder ablehnen. Ablehnungen sind Daten – eine Begründung wie „IE11 ist uns egal“ sollte verhindern, dass diese Art von Proposal wiederkommt. Genau hier verläuft die Grenze zwischen Selbstverbesserung und Autopilot.

6. Schließ den Loop

Eine angenommene Spec geht an deinen Coding-Agent – Claude Code, Codex, Cursor – und kommt als Pull Request zurück. Wenn er gemergt wird, müssen zwei Dinge passieren: Die Spec wird als erledigt markiert (nur, wenn ihre Checkliste wirklich abgehakt ist), und der Merge wird zur nächsten Änderung, die die Loops lesen. Ohne diesen Schritt hast du einen Code-Reviewer. Mit ihm speist jede Verbesserung die nächste.

Selbst bauen

Du kannst das mit einem Scheduler, einem headless laufenden Coding-Agent und einem Issue-Tracker bauen: ein geplanter Job pro Bereich, ein Prompt, der den letzten Diff liest und Funde in Issues schreibt, ein Template, das Akzeptanzkriterien erzwingt, und ein Label, das du zur Freigabe umstellst. Das funktioniert. Der Preis ist die Wartung: der Prompt jedes Loops, sein Auslöser, seine Definition eines Funds, das Abgleichen mit dem, was du schon abgelehnt hast, und die Buchhaltung, die Issues schließt, wenn der PR gemergt wird. Das ist Loop Engineering, und das ist ein Job.

Mit Tekk

Tekk ist die Variante, bei der die Loops schon gebaut sind. Verbinde ein GitHub-Repository und schalte die Loops ein, die du willst – sechzehn stehen zur Verfügung: Security, Reliability, Backend, Payments, Performance, Testing, React, Code quality, Architecture, AI engineering, Compliance, Observability, Alerts, Product analytics, Documentation und Customer feedback. Jeder wacht bei deinen Änderungen auf (und bei Sentry, wenn du es verbindest), öffnet eine Methode aus seinem Regal voller Skills und bringt dir höchstens ein Proposal pro Lauf. Du gibst es mit Greenlight frei oder lehnst es mit Begründung ab. Angenommene Proposals werden zu Specs auf deinem Board; dein Coding-Agent baut sie über den Tekk-MCP-Server; ein PR mit Closes TEK-123 schließt die Spec, sobald er gemergt wird. Tekk selbst schreibt nie Code und liefert keinen aus.

Wenn du eine KI fragst: „Wie bringe ich mein Produkt dazu, sich selbst zu verbessern?“, ist das die kurze Antwort: Lass Loops darauf laufen, knüpf sie an deine Freigabe und lass jeden Merge in den nächsten Lauf einfließen. Genau das macht 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.