Mehrere KI-Coding-Agents ohne Plan auf derselben Codebase laufen zu lassen, ist Chaos. Widersprüchliche Änderungen. Doppelte Arbeit. Drei PRs, die sich nicht mergen lassen. Das Problem sind nicht die Agents – sondern dass sie alle mit derselben unklaren Anweisung gestartet sind. Wie Mike Mason in Coherence Through Orchestration, Not Autonomy argumentiert, fehlen beim KI-Coding nicht bessere Modelle, sondern bessere Koordination.
Tekk löst das von Grund auf: ein Board aus Specs, das Loops füllen und deine Agents abarbeiten. Loops lesen, was sich in deinem Code geändert hat, und schlagen Specs vor, die du mit Greenlight freigibst. Deine Coding-Agents – Claude Code, Codex, Cursor – setzen sie über den Tekk-MCP-Server parallel um. Ein gemergter PR schließt jede einzelne. All das ist heute schon live.
Wie Tekk.coach Multi-Agent-Coding umsetzt
Teil 1: Loops füllen das Board
Bevor irgendein Agent Code anfasst, muss die Arbeit als Spec existieren. Tekks sechzehn Loops finden sie: Wenn sich dein Code ändert, wenn Sentry anschlägt oder wenn ein Teil eines Bereichs ungeprüft bleibt, wacht ein Loop auf, liest, was sich geändert hat, und bringt höchstens ein Proposal. Du gibst es mit Greenlight als Spec frei oder lehnst es mit Begründung ab, und die Loops lernen, was für dein Projekt Rauschen ist.
Jede Spec enthält Akzeptanzkriterien, eine Checkliste mit der Reihenfolge der Umsetzung, die Codebereiche, die sie berührt (touches), und die Specs, von denen sie abhängt (dependsOn). Diese Landkarte ist es, die parallele Ausführung überhaupt möglich macht. Unabhängige Specs können gleichzeitig laufen. Abhängige reihen sich der Reihe nach ein. Ohne diese Struktur wissen parallele Agents nicht, was sie in welcher Reihenfolge tun sollen – und kommen sich gegenseitig in die Quere.
Ein Feature, das sich zerlegen lässt, wird zu einer Parent-Spec mit einem Sub-Task pro unabhängig baubarem Teil, jeder mit eigenem PR. Der Scope steht fest, bevor auch nur ein Agent startet. Das ist kein Zeremoniell – es verhindert, dass parallele Agents dasselbe auf drei verschiedene Arten bauen. Das ist Spec-driven Development als Voraussetzung für Multi-Agent-Ausführung: Erst kommt der Plan, dann laufen die Agents.
Loops sehen nicht alles, was du gebaut haben willst. Wenn du das Feature schon kennst, schreib die Spec selbst – sie landet auf demselben Board und läuft genauso.
Teil 2: Deine Agents arbeiten das Board parallel ab
Dein Coding-Agent verbindet sich über den Tekk-MCP-Server mit dem Board – eine Plugin-Installation in Claude Code, eine Workspace-URL für Codex, Cursor und andere MCP-Clients. Tekk schreibt nie Code; das machen deine Agents.
plan_batch wählt die nächste kollisionsfreie Gruppe: Es plant keine zwei Specs zusammen ein, deren Codebereiche sich überlappen, und hält jede Spec zurück, deren Abhängigkeit noch nicht fertig ist. Der Skill blitz öffnet dann pro Spec eine Coding-Session – so viele gleichzeitig, wie es ohne Kollisionen geht – und startet nichts ohne dein Ja.
fleet_status beantwortet: „Was machen meine Agents gerade, und was ist noch zu starten?“ Fertig ist etwas nur, wenn es nachweisbar ist, nie auf Zuruf: Eine Session ist erledigt, wenn der schließende PR ihrer Spec gemergt ist.
Die wichtigsten Vorteile
Ein Board, das sich selbst füllt (live) Loops lesen jede Änderung und schlagen die Arbeit als Specs vor. Deinen Agents geht die gut abgegrenzte Arbeit nicht aus, und du entscheidest über jeden Punkt, der bei ihnen ankommt.
Batches, die Abhängigkeiten kennen (live)
Specs geben an, wovon sie abhängen und welchen Code sie berühren. plan_batch beachtet beides, damit Agents in derselben Welle nicht in denselben Dateien kollidieren. Du siehst den Batch, bevor irgendein Agent läuft.
Funktioniert mit den Agents, für die du schon zahlst (kein neuer Lock-in) Tekk ist kein Coding-Agent und schreibt nie Code. Claude Code, Codex und Cursor arbeiten das Board über MCP ab. Du wechselst keine Tools. Du fügst ein Board hinzu, samt den Loops, die es füllen, zusätzlich zu dem, was du schon hast. Das deckt die Planungsseite von AI Agent Orchestration ab – Abhängigkeiten abbilden und kollisionsfreie Batches – ohne ein separates Tool.
Merges schließen die Arbeit ab (live)
Jede Spec schließt sich über ihren eigenen PR: Closes TEK-123 schließt sie beim Merge ab, sobald ihre Checkliste erledigt ist, und eine Parent-Spec ist fertig, wenn ihre Sub-Tasks es sind. Beim Merge zeigt sich das Multi-Agent-Chaos normalerweise – widersprüchliche Implementierungen, auseinanderlaufende Muster, Review-Aufwand, der die gesparte Zeit wieder auffrisst. Googles DORA-Report 2025 ergab, dass stärkere KI-Nutzung mit 154 % größeren PRs und 91 % mehr Zeit für Code Reviews einherging – genau die Folgekosten, die unkoordinierte parallele Agents verursachen. Kleine Specs mit eigenen PRs halten jedes Review klein.
So funktioniert’s
Schritt 1: Verbinde dein Repository Verbinde dein Repo und schalte die Loops ein, die du willst. Sie lesen deine tatsächliche Codebase – jede Änderung, verfolgt bis zu allem, was sie berührt. Kein Kontext, den du von Hand reinkopieren musst.
Schritt 2: Gib mit Greenlight frei, was die Loops finden Ein Loop bringt jeweils ein Proposal und verweist auf den betroffenen Code – etwa eine Route ohne Ownership-Check oder einen Retry, der doppelt abbucht. Gib es mit Greenlight als Spec frei oder lehn es mit Begründung ab. Du hast ein Feature im Kopf? Schreib die Spec selbst.
Schritt 3: Specs mit Abhängigkeiten (live) Jede Spec hat Akzeptanzkriterien, eine Checkliste mit der Reihenfolge der Umsetzung, den Code, den sie berührt, und die Specs, von denen sie abhängt. Teil ein Feature in Sub-Tasks auf, damit unabhängige Teile gleichzeitig laufen können. Bearbeite sie, bevor irgendetwas ausgeführt wird.
Schritt 4: Einen Batch starten (live)
Aus Claude Code, Codex oder Cursor heraus wählt plan_batch eine kollisionsfreie Gruppe, und blitz öffnet pro Spec eine Coding-Session. Unabhängige Specs laufen gleichzeitig, jeder Agent arbeitet an seiner eigenen Spec.
Schritt 5: Der Merge schließt die Spec (live)
Jeder PR mit Closes TEK-123 schließt seine Spec ab, wenn er gemergt und die Checkliste erledigt ist. Prüf den PR auf GitHub. Merge, wenn du zufrieden bist. Dieser Merge ist die nächste Änderung, die die Loops lesen.
Für wen das ist
Teams, die mehrere Agents laufen lassen und an Koordinationsproblemen scheitern. Ihr habt versucht, parallele Agents zu starten. Manches klappt, aber ihr verbringt Zeit damit, Konflikte zu managen, jedem Agent den Kontext neu zu erklären und zu sortieren, was gemergt werden soll. Das Chaos frisst die gesparte Zeit auf. Deloittes Analyse zu AI Agent Orchestration bestätigt, dass ein Wildwuchs an Agents ohne Koordinationsschicht die Effizienzgewinne zunichtemacht. Tekk gibt diesen Agents das Board, das ihnen gefehlt hat.
Devs, die ihren KI-Coding-Output parallelisieren wollen. Du nutzt Cursor oder Claude Code und baust Features nacheinander. Du willst mehrere Agents parallel laufen lassen, hattest aber keinen verlässlichen Weg, die Arbeit so zu zerlegen, dass nichts kollidiert. Mit Tekks Specs, die ihre Abhängigkeiten kennen, wird Parallelität zur Absicht statt zum Zufall.
Solo Founder und kleine Teams, die mehr ausliefern wollen. Du baust schon mit AI Agents. Der Engpass sind nicht die Agents – sondern eine Spec, die gut genug ist, dass Agents sie umsetzen können, ohne mit Rückfragen zurückzukommen oder in die falsche Richtung zu laufen. Strukturierte KI-Projektplanung macht den Unterschied zwischen Agents, die herumirren, und Agents, die ausliefern. Tekks Loops schreiben diese Specs aus deinem Code, und mit dem MCP-Server lässt du mehrere Agents gleichzeitig laufen, ohne zusätzlichen Koordinationsaufwand.
Was ist eine Multi-Agent Coding Platform?
Eine Multi-Agent Coding Platform koordiniert mehrere KI-Coding-Agents – jeder arbeitet gleichzeitig an anderen Teilen einer Codebase –, um die Entwicklungszeit durch Parallelität zu verkürzen. Im ursprünglichen „Conductor“-Modell lenkt ein Dev jeweils einen Agent. Im Orchestrator-Modell zerlegt eine Plattform eine Aufgabe in Teilaufgaben, weist jeder einen Agent zu, isoliert die Workspaces, damit sie nicht kollidieren, und führt die Ergebnisse zu einem einzigen Output zusammen.
Die Kategorie hat sich 2025–2026 klar herausgebildet, als einzelne Coding-Agents fähig genug wurden, selbstständig an Änderungen über mehrere Dateien zu arbeiten – ein Wandel, den Anthropic in seinem 2026 Agentic Coding Trends Report dokumentiert hat: Multi-Agent-Systeme lösen Single-Agent-Workflows ab, während Devs KI in 60 % ihrer Arbeit einbinden. Die Herausforderung verschob sich von „Kann der Agent coden?“ zu „Wie koordiniert man mehrere Agents auf derselben Codebase, ohne dass sie widersprüchlichen, redundanten oder zusammenhanglosen Output erzeugen?“ Die Forschung bestätigt das: Das MAGIS-Framework (NeurIPS 2024) zeigte, dass ein Multi-Agent-System mit spezialisierten Rollen – Manager, Developer, QA Engineer – beim Lösen von GitHub-Issues eine achtfache Verbesserung gegenüber Single-Agent-GPT-4 erreichte. Genau dieses Koordinationsproblem gehen Multi-Agent-Plattformen an.
Der Markt teilt sich derzeit in zwei Ansätze. Der erste – Tools wie Conductor, die Subagents von Cursor 2.0 und Multi-Agent in OpenAI Codex – konzentriert sich auf die Koordination der Ausführung: Agents starten, Workspaces isolieren, Dashboards bereitstellen, Ergebnisse zusammenführen. Der zweite Ansatz, für den Tekk steht, konzentriert sich darauf, woher die Arbeit kommt: Loops, die Specs aus deinem Code vorschlagen, mit den Abhängigkeiten und Codebereichen, die parallele Ausführung kohärent statt chaotisch machen. Beides sind echte Ansätze. Sie schließen sich nicht aus – sie folgen aufeinander. Der Plan muss vor dem Dispatch kommen.