Vage Pläne erzeugen vagen Code.
Gib einem Coding-Agent einen Absatz, und du bekommst die Präzision eines Absatzes zurück. Die Lücken füllt der Agent mit Vermutungen. Dann verbringst du zwei Stunden damit, rückgängig zu machen, was er falsch geraten hat.
Tekks Loops schreiben strukturierte Pläne für dich. Sechzehn Loops lesen, was sich in deinem Code geändert hat, und wenn einer etwas findet, das sich lohnt, bringt er ein Proposal, das du mit Greenlight freigibst oder ablehnst. Freigegeben wird es zur Spec mit Akzeptanzkriterien und einer Checkliste für die Reihenfolge der Umsetzung. Kein Template. Keine Chatnachricht. Eine Spec, die auf deiner tatsächlichen Codebase beruht.
[Tekk.coach kostenlos testen →]
So plant Tekk.coach strukturiert
Jede Tekk-Spec hat eine feste Struktur, egal ob ein Loop sie geschrieben hat oder du. Das bekommst du.
Was und warum – Was gebaut wird und warum es zählt. Die Spec eines Loops zeigt auf den Code, um den es geht, also ist das Warum nachvollziehbar und kein Bauchgefühl.
Akzeptanzkriterien – Die Bedingungen, die sagen, wann es fertig ist. Formuliert als Verhalten, das ein Agent prüfen kann, nicht als Implementierungsnotizen.
Checkliste für die Umsetzung – Die Schritte, in Reihenfolge. Die Checkliste ist das Tor: Ein gemergter PR schließt die Spec erst ab, wenn jeder Punkt abgehakt ist. Sonst bleibt die Spec in Arbeit, und Tekk hält fest, wie weit sie ist.
Betroffener Code und Abhängigkeiten – Die Code-Bereiche, die eine Spec ändert, und die Specs, die vorher fertig sein müssen. Ein Feature, das in unabhängige Teile zerfällt, wird zu einer übergeordneten Spec mit einer Teilaufgabe pro Teil.
Typ – Feature, Problem, Technical, Research oder Improvement, damit das Board lesbar bleibt.
Du kannst alles davon bearbeiten, bevor dein Coding-Agent startet. Es ist die Spec, nach der dein Team arbeitet.
Das ist kein Notion-Template mit Platzhaltertext. Ein Loop liest deine Codebase und schreibt die Spec auf Grundlage dessen, was er findet. Oder du schreibst sie von Hand auf demselben Board – die Struktur und der Merge, der sie schließt, bleiben gleich.
Die wichtigsten Vorteile
Pläne, die du nicht selbst anfangen musst. Loops bemerken die Arbeit – eine fehlende Ownership-Prüfung, einen Webhook, der sich per Replay erneut auslösen lässt, eine Query ohne Index – und bringen sie dir, zugeschnitten auf ein Proposal. Ein enger Scope hält Coding-Agents davon ab, Angrenzendes zu bauen, das du nie verlangt hast. Das ist der häufigste Fehler in der KI-gestützten Entwicklung.
Teilaufgaben, die dein Agent prüfen kann. Akzeptanzkriterien sind als Verhalten formuliert: „man kann jetzt X“, nicht „Datei Y ändern“. Dein Agent weiß, wann die Aufgabe erledigt ist. Du auch.
Dateiverweise, damit der Agent an der richtigen Stelle ändert. Schluss mit „es hat eine neue Komponente angelegt, statt die bestehende zu aktualisieren“. Die Spec eines Loops nennt die betroffenen Dateien, weil der Loop sie zuerst gelesen hat.
Fertig heißt fertig. Ein gemergter PR mit Closes TEK-123 schließt die Spec nur ab, wenn ihre Checkliste das bestätigt. Halbfertige Arbeit bleibt in Arbeit, mit gezählten offenen Punkten, statt still vom Board zu verschwinden.
So funktioniert’s
Tekk durchläuft für jede Änderung denselben Loop. Es ist kein einmaliger Prompt.
Aufwachen. Ein Loop wacht auf, wenn sich dein Code ändert, wenn Sentry anschlägt oder wenn ein Teil seines Bereichs zu lange ungeprüft geblieben ist. Er liest, was sich geändert hat, und verfolgt es bis zu dem, was davon berührt wird.
Vorschlagen. Er arbeitet eine Methode aus seinem Regal an Skills ab und bringt höchstens ein Proposal – oder hält ehrlich „nichts gefunden“ fest, damit er morgen nicht denselben Boden noch einmal prüft.
Entscheiden. Du gibst das Proposal mit Greenlight frei, und es wird zur Spec auf deinem Board, oder du lehnst es mit Begründung ab, und die Loops lernen, was für dein Projekt Rauschen ist.
Schließen. Dein Coding-Agent baut die Spec über den Tekk-MCP-Server. Der PR mit Closes TEK-123 schließt sie ab, wenn er gemergt wird, und dieser Merge ist die nächste Änderung, die die Loops lesen.
All das ist heute live. Willst du lieber selbst etwas planen? Schreib die Spec von Hand – sie landet auf demselben Board und wird genauso geschlossen.
Für wen das ist
Devs, die von AI-Agents ständig Nacharbeit zurückbekommen. Du gibst Cursor eine Aufgabenbeschreibung und bekommst Code zurück, der größtenteils funktioniert, aber etwas übersehen hat. Das Problem ist die Spec, nicht der Agent. Tekk repariert die Spec.
PMs, die strukturierte Specs brauchen. Zu beschreiben, was ein Feature können muss, ist ein Skill. Das in etwas zu übersetzen, das ein Agent ausführen kann, ein anderer. In der KI-Projektplanung passiert diese Übersetzung. In Tekk schreibst du die Spec von Hand, wenn du weißt, was du willst, und die Loops schlagen den Rest aus dem Code vor.
Solo Founder, die Pläne wie aus der Architektur brauchen, aber niemanden für die Architektur haben. Du baust gleichzeitig an Backend, Frontend und Infrastruktur, ohne Senior Engineer im Team. Tekks Loops lesen deinen Code so, wie ein Senior Engineer es nach einer Pause tun würde, und bringen dir die Pläne, die er angestoßen hätte.
Alle, die Claude Code, Cursor oder Codex nutzen. Diese Agents setzen um, was du ihnen gibst. Tekk gibt ihnen Specs mit Akzeptanzkriterien, über MCP. Verbinde dein Repo, gib ein Proposal mit Greenlight frei, starte den Agent, merge.
Was ist ein Structured Planner?
Ein Structured Planner erstellt Pläne mit klarer Ordnung. Keine Aufgabenliste, sondern ein Dokument, das den Scope festlegt, die Arbeit in prüfbare Teile zerlegt, Annahmen offenlegt und Erfolgskriterien bestimmt.
In der Softwareentwicklung zählt strukturierte Planung, weil die Qualität des Plans die Qualität des Outputs bestimmt. Eine Aufgabenliste sagt „Authentifizierung hinzufügen“. Ein strukturierter Plan sagt, welches Auth-Muster, welche Dateien neu anzulegen sind, welche bestehenden Dateien sich ändern, welche Akzeptanzkriterien für jeden Schritt gelten und was nicht gebaut wird (kein Passwort-Reset, kein OAuth, keine Admin-Impersonation in diesem Sprint). Genau diese Grundlage formalisiert Spec-driven Development – und deshalb schlagen Specs Aufgabenlisten, wenn Agents die Umsetzung übernehmen.
Dieser Unterschied zählt, wenn du allein arbeitest. Er zählt noch mehr, wenn du mit KI-Coding-Agents arbeitest, die genau das ausführen, was man ihnen sagt. Ein guter strukturierter Plan trennt einen Coding-Agent, der ausliefert, von einem, der ins Straucheln gerät.
Der Unterschied zwischen einer Aufgabenliste und einem strukturierten Plan ist der Unterschied zwischen „bau Auth“ und „hier ist die exakte Spec, die dein Agent braucht, um Auth gleich beim ersten Mal richtig zu bauen“.