Coding-Agents geraten ins Schlingern, wenn sie ohne Plan umsetzen. Du tippst einen Satz, der Agent macht irgendetwas, und jetzt debuggst du Code, der fast funktioniert. Tekk behebt das an der Quelle.

Verbinde dein Repo. Tekks Loops lesen, was sich in deinem Code geändert hat, und bringen dir Proposals; jedes, das du mit Greenlight freigibst, wird zu einer Spec mit Akzeptanzkriterien, bevor auch nur eine Zeile Code läuft. Dann holt sich Claude Code, Codex oder Cursor die Spec über den Tekk-MCP-Server und setzt gegen etwas Konkretes um.

Erst planen. Einmal umsetzen. Keine Nacharbeit.

[Tekk.coach kostenlos testen →]

Wie Tekk.coach Plan and Execute umsetzt

Die meisten Devs geben ihrem Coding-Agent ein, zwei Sätze. Der Agent setzt schnell um – und falsch. Er kennt deine Konventionen nicht, weiß nicht, welche Dateien er anfassen soll und welche Architekturentscheidungen du schon getroffen hast. Der Output wirkt etwa fünf Minuten lang plausibel.

Tekk ist die Planungshälfte von Plan and Execute. Sechzehn Loops beobachten dein Repository – Security, Backend, Payments, Performance, Testing und sieben weitere. Wenn sich dein Code ändert, wacht einer auf, liest, was sich geändert hat, und verfolgt es bis zu allem, was es berührt. Er findet deine Muster, deine Abhängigkeiten, deinen tatsächlichen Code. Dann bringt er höchstens ein Proposal, mit Verweis auf die betroffenen Dateien.

Du gibst es mit Greenlight frei oder lehnst es mit Begründung ab. Freigegeben wird es zur Spec – keine Chatnachricht, die du in Cursor einfügst, sondern ein Dokument auf deinem Board: was gebaut wird, warum, Akzeptanzkriterien und eine Checkliste mit der Reihenfolge der Umsetzung. Du planst lieber selbst? Schreib die Spec selbst; sie landet auf demselben Board.

Du prüfst sie. Du bearbeitest sie. Dann liest dein Coding-Agent sie über MCP und baut sie.

Diese Spec ist der Unterschied zwischen einem Agent, der ausliefert, und einem, der ins Schlingern gerät.

Auch die Umsetzungshälfte ist angebunden. Dein Agent arbeitet das Board über den Tekk-MCP-Server ab, und der Pull Request mit Closes TEK-123 schließt die Spec ab, wenn er gemergt wird – sobald ihre Checkliste erledigt ist.

Die wichtigsten Vorteile

Dein Coding-Agent bekommt eine echte Spec, keinen Absatz. Die meisten Fehlschläge von Agents gehen auf schwachen Input zurück. Wie JetBrains schreibt, sind Sprachmodelle hervorragend im Vervollständigen von Mustern, brauchen aber strukturierten Kontext – eine detaillierte Spec ist genau dieser Kontext. Tekks Specs enthalten Akzeptanzkriterien und eine Checkliste mit der Reihenfolge der Umsetzung, und die Spec eines Loops verweist auf die betroffenen Dateien. Dein Agent hat, was er braucht, um richtig umzusetzen, statt zu raten.

Der Plan ist in deiner tatsächlichen Codebase verankert. Loops lesen dein Repo, bevor sie irgendetwas vorschlagen. Jedes Proposal verweist auf deine konkreten Dateien und Muster – nicht darauf, wie eine generische Version deines Stacks vermutlich aussieht.

Was „fertig“ heißt, steht fest, bevor irgendwer Code schreibt. Akzeptanzkriterien und eine Checkliste sagen, wann die Spec fertig ist. Ein Merge schließt sie nur ab, wenn die Checkliste zustimmt; sonst bleibt sie In Progress, und die offenen Punkte werden gezählt.

Die Spec lebt in einem dauerhaften Workspace, nicht in einem Chatverlauf. Tekk ist keine Chat-Oberfläche. Jede Spec lebt auf einem Board, wandert von Todo über In Progress zu Completed und zeigt die Pull Requests, die sie gebaut haben. Kontext verpufft nicht zwischen Sessions. Für Teams, die über mehrere Features oder eine ganze Roadmap planen, hält KI-Projektplanung das große Ganze neben den Specs auf Feature-Ebene geordnet.

So funktioniert’s

1. Verbinde dein Repository Verbinde dein Repo und schalte die Loops ein, die du willst. Das ist es, was sie lesen, bevor sie irgendetwas anderes tun.

2. Ein Loop wacht auf Dein Code hat sich geändert, Sentry hat angeschlagen, oder ein Teil eines Bereichs wurde zu lange nicht geprüft. Der zuständige Loop wacht auf.

3. Der Loop liest deine Codebase Er liest, was sich geändert hat, und verfolgt es bis zu allem, was es berührt – so, wie es ein Senior Engineer tut, der zu einer Codebase zurückkehrt –, und arbeitet dann eine Methode aus seinem Regal voller Skills ab. Er prüft nicht jedes Mal das ganze Repository neu.

4. Ein Proposal Findet er etwas Echtes, bringt er ein Proposal, das erklärt, was ihm aufgefallen ist und was er tun würde. Wenn nicht, hält er ein ehrliches Negativ fest und macht weiter.

5. Du gibst mit Greenlight frei oder lehnst ab Gib es mit Greenlight frei, und es wird zu einer Spec auf deinem Board. Lehnst du es mit Begründung ab, lernen die Loops, was für dein Projekt Rauschen ist. Du kannst auch selbst eine Spec schreiben.

6. Die Spec Was gebaut wird, warum, Akzeptanzkriterien und eine Checkliste mit der Reihenfolge der Umsetzung. Gegen dieses Dokument setzt dein Coding-Agent um.

7. Mit deinem Coding-Agent umsetzen Claude Code, Codex oder Cursor liest die Spec über den Tekk-MCP-Server und baut sie. Der PR mit Closes TEK-123 schließt die Spec ab, wenn er gemergt wird. Dein Plan ist fertig. Die Umsetzung ist ihr Job. Teams, die mehrere Agents gleichzeitig laufen lassen, können den MCP-Server einen kollisionsfreien Batch planen lassen – die Seite von AI Agent Orchestration, die Abhängigkeiten kennt, ohne separates Tool.

Für wen das ist

Devs, die Cursor, Claude Code oder Codex nutzen und genug von Nacharbeit haben. Du hast dich an Agents verbrannt, die halb verstandene Anweisungen umsetzen. Du hast plausibel aussehenden Code debuggt, der auf eine Weise falsch war, die eine Stunde Fehlersuche gekostet hat. Damit willst du aufhören.

Solo Founder und kleine Teams ohne eigene Architektur-Expertise. Du bewegst dich in Bereichen, in denen dir tiefes Fachwissen fehlt – Auth-Systeme, Datenpipelines, Payment-Integrationen. Tekks Security-, Backend- und Payments-Loops füllen die Wissenslücke schon beim Planen, nicht erst, wenn du das Falsche gebaut hast.

Kleine Teams (1–10 Personen), die strukturierte Specs brauchen, aber nicht den Overhead von PRDs, Abstimmungsmeetings und Backlog Grooming wollen. Repo verbinden, Proposal mit Greenlight freigeben, Spec bekommen. Das ist der ganze Prozess.

Tekk ist nicht das Richtige, wenn du als Senior Architect ohnehin wasserdichte Specs aus dem Kopf schreibst und jede Änderung selbst reviewst. Oder wenn du Enterprise-Workflow-Governance brauchst: Freigabeketten, Prozesskonfiguration im Jira-Stil. Tekk ist bewusst meinungsstark und schlank.

Was ist Plan-and-Execute?

Plan-and-Execute ist ein zweiphasiger Ansatz für KI-gestützte Softwareentwicklung. Phase eins: einen vollständigen, schriftlichen Plan erstellen. Phase zwei: ihn umsetzen. Die Planungsphase ist getrennt – sie denkt über die Codebase nach, ohne sie anzufassen. Erst wenn der Plan geprüft und freigegeben ist, läuft überhaupt Code.

Neu ist die Idee in der Softwareentwicklung nicht. Erst entwerfen, dann implementieren ist seit Jahrzehnten der Standardrat. Was KI-Coding-Agents verändert haben, sind die Kosten, wenn man es überspringt. Gib Cursor oder Claude Code einen Prompt aus einem Satz, und sie legen sofort los, ohne deine Konventionen, deine Einschränkungen oder die Entscheidungen zu verstehen, die du noch nicht getroffen hast. Der Output sieht richtig aus und fällt dann auf eine Weise auseinander, die Stunden kostet.

2025 bekam die Praxis feste Namen. ThoughtWorks nannte Spec-driven Development „eine der wichtigsten Praktiken, die 2025 aufgekommen sind“. AWS hat in Kiro einen expliziten Ablauf Specify → Plan → Execute in die IDE eingebaut. GitHub hat das Open-Source-Toolkit Spec Kit veröffentlicht. Traycer hat „Spec-first Development“ zu seinem zentralen Begriff gemacht. Plan First Development tauchte in Dev-Blogs auf, als Leute dokumentierten, was bei ihnen wirklich funktionierte.

Was all das gemeinsam hat: Die Spec ist das Erste, was du mit KI baust. Nicht der Code. Die Spec IST das erste Artefakt.