So funktioniert’s
So arbeiten die Loops
Die autonome Seite von Tekk – was einen Loop auslöst, wie aus einem Proposal eine Spec wird und wo du die Kontrolle behältst.
Loops machen Tekk self-improving statt nur reaktiv. Ein Loop ist eine autonome Routine, die auf deinem Projekt läuft, nach einer bestimmten Art von Verbesserung sucht und – wenn er etwas findet, das deine Zeit wert ist – dir ein Proposal bringt. Du verlierst nie die Kontrolle: Ohne Greenlight von dir wird nichts ausgeliefert.
Wie ein Loop abläuft
Jeder Loop folgt demselben Bogen:
- Ein Auslöser greift. Etwas gibt dem Loop einen Grund zu laufen – Code, der sich seit dem letzten Lauf geändert hat, ein Signal aus einem verbundenen Tool oder ein regelmäßiger Durchgang durch das Projekt.
- Tekk untersucht. Der Loop liest die relevanten Teile deiner tatsächlichen Codebase und die Dokumente des Workspaces (was das Produkt ist, für wen es gedacht ist, wie es Geld verdient), damit seine Überlegungen auf deinem Projekt beruhen statt auf allgemeinen Ratschlägen.
- Er entwirft ein Proposal. Findet der Loop etwas Echtes, schreibt er ein Proposal, das erklärt, was ihm aufgefallen ist und was er tun würde – zugeschnitten auf ein zusammenhängendes Stück Arbeit, keine vage Ahnung.
- Du entscheidest. Du nimmst es mit Accept an (es wird ein Spec-Entwurf auf deinem Board), überarbeitest es mit Revise und Feedback (Tekk schreibt es direkt um) oder lehnst es mit Reject und Begründung ab (was künftige Loops von dieser Richtung weglenkt).
Was einen Loop auslöst
Ein Loop läuft in Wakes. Drei Dinge geben ihm einen Grund aufzuwachen:
- Dein Code hat sich geändert. Ausgangspunkt jedes Loops ist das Delta seit seinem letzten Lauf – die geänderten Dateien, sortiert danach, wie viel vom System von ihnen abhängt, und worin diese Dateien einfließen. Er liest, was sich geändert hat, und verfolgt, worauf sich das auswirkt – so wie man es als Senior Engineer macht, wenn man zu einer Codebase zurückkommt; er prüft nicht jedes Mal das ganze Repository neu.
- Ein Signal aus deinen Tools. Verbindest du ein Tool über eine Integration – etwa Sentry –, kann ein neuer Fehleranstieg oder eine langsame Transaktion den zuständigen Loop wecken. Der Loop nimmt das Signal als Ausgangspunkt und untersucht den Code dahinter.
- Ein Teil seines Bereichs wurde zu lange nicht angesehen. In seinem eigenen Rhythmus wirft ein Loop einen breiteren Blick auf die kritischsten Stellen seines Bereichs, damit nichts ungeprüft bleibt, nur weil es sich nicht mehr ändert.
Loops sind pro Workspace Opt-in – du wählst, welche laufen. Du schaltest Loops in der App ein und aus.
Woraus ein Loop besteht
Jeder Loop ist ein Regal voller Skills: eine kurze Datei, die sagt, was der Loop ist und was in seinem Bereich als Fund zählt, dazu zwei bis fünf in sich geschlossene Methoden – eine pro Art von Frage. Ein Lauf liest sein Briefing, öffnet dann genau einen Skill und arbeitet ihn von Anfang bis Ende ab. Er hält fest, welchen er benutzt hat, damit der nächste Lauf weiß, welche Methoden wirklich schon zum Einsatz kamen. Die vollständige Liste der Loops und der Skills in jedem Regal steht unter Loops und ihre Skills.
Erst vorschlagen, dann handeln
Entscheidend ist die Reihenfolge: Tekk schlägt vor, du entscheidest. Loops ändern deinen Code nicht still und heimlich. Sie liefern geprüfte Vorschläge, und die Entscheidung zwischen Accept und Reject liegt immer bei dir. Ablehnen ist nicht vergeudet – mit deiner Begründung bringst du Tekk bei, was für dein Projekt Rauschen ist, sodass die Proposals mit der Zeit schärfer werden.
Angenommene Proposals werden zu Specs und laufen von da an wie jede andere Arbeit über das Board – bis hin zur Umsetzung direkt aus deinem Coding-Agent über den MCP-Server.
Was unter der Haube läuft
- Claude. Tekks Denken läuft auf den Claude-Modellen von Anthropic.
- Dein Repo, im Kontext. Loops lesen den echten Code des Projekts, dem sie zugeordnet sind, sodass ein Proposal auf genau die Dateien zeigt, um die es geht.
- Deine verbundenen Tools. Über Composio sehen Loops Signale aus den SaaS-Tools, die du verbindest, sodass sich die Software als Reaktion auf das verbessern kann, was in Produktion tatsächlich passiert.
Die Interna von Planung, Priorisierung und Kostensteuerung lassen wir in dieser Doku weg – aber der Vertrag, auf den du dich verlassen kannst, ist einfach: in deinem Projekt verankert, immer von dir geprüft, von deinem Feedback gesteuert.
Zuletzt aktualisiert 13. September 2026