Die meisten Ratschläge in dieser Kategorie stehen auf dem Kopf. Leute tun so, als wäre Spec-driven Development eine einzige Sache und deine Aufgabe, den Gewinner zu finden. Ist es nicht. Du wählst einen Arbeitsstil.
Das ist wichtig, weil der Gegenwind echt ist. Bis Mai 2026 nannten viele Builder SDD bereits „Wasserfall mit Markdown“, sprachen von „Spec Drift“, „eingefrorenen Specs“ und einer Token verbrennenden Zeremonie. Simon Willison hat deutlich vor den Risiken gewarnt, KI-Workflows zu stark zu formalisieren. Auch Birgitta Böckelers Taxonomie zählt hier: spec-first, spec-anchored und spec-as-source sind nicht dieselbe Praxis. Addy Osmanis kanonisches Spec-Format mit sechs Abschnitten ist nützlich, aber ein Format allein bewahrt dich nicht vor schlechter Planung. Thoughtworks Tech Radar, GitHub Spec Kit, Kiro, OpenSpec, Traycer, Vibe Kanban und BMAD liegen alle an unterschiedlichen Punkten dieses Spektrums.
Wenn du einfach nur schnell Web-Apps ausliefern willst, bremst dich der falsche Spec-Prozess stärker aus als gar kein Prozess. Deshalb lautet die nützliche Frage nicht „Welches Spec-Tool ist das beste?“, sondern „Welche Art von Unterstützung brauchst du?“
Für die größere Landkarte, inklusive Tekk vs. BMAD und Tekk vs. Get Shit Done, sieh dir das Tekk-Playbook zu Spec-driven Development an. Wenn du die Anti-Hype-Version dieser Debatte willst, ist der eigene Beitrag dazu, wann Specs dich ausbremsen und wann sie dich verzehnfachen, eine brauchbare Einordnung.
Inhalt
- Spec-driven Development: Ist es eine Falle?
- Tekk.coach vs. Traycer vs. OpenSpec auf einen Blick
- Die drei Philosophien: Plattform vs. Organizer vs. Framework
- Wann Traycer deinen Workflow gewinnt
- Wann OpenSpec mit Einfachheit gewinnt
- Wann Tekk.coach als deine Plattform gewinnt
- Das Fazit: So wählst du dein Tool
Spec-driven Development: Ist es eine Falle?
Manchmal ja.
Eine schlechte Spec ist schlimmer als ein grober Prompt, weil sie dir falsche Sicherheit gibt. Du fühlst dich organisiert, während dein Agent veralteten Annahmen folgt. Genau da trifft die Kritik „Wasserfall mit Markdown“. Sie sagt nicht, dass Specs nutzlos sind. Sie sagt, dass Zeremonie ohne Feedback nutzlos ist.
Das eigentliche Problem ist eingefrorenes Denken
Die stärkste Kritik an Spec-driven Development ist nicht, dass Leute Dinge aufschreiben. Sondern dass sie Schreiben mit Lernen verwechseln. Wenn deine Spec wie ein Vertrag behandelt wird statt wie ein Arbeitsdokument, bist du zurück im Anforderungstheater alter Schule.
Praxisregel: Wenn sich die Spec nach Repo-Kontext, Reibung bei der Umsetzung und Test-Feedback nicht ändern darf, hilft sie nicht. Sie bremst nur die Ausführung.
Deshalb müssen „spec-first“, „spec-anchored“ und „spec-as-source“ auseinandergehalten werden. Ein schlankes Markdown-Gerüst kann helfen. Ein riesiges Ritual kann schaden. Für beides wird dasselbe Etikett benutzt.
Die drei Tools lösen unterschiedliche Probleme
Viele Vergleiche greifen zu kurz. Sie vergleichen Kästchen in einer Feature-Matrix und übersehen, welche Aufgabe jedes Tool eigentlich erfüllen will.
- Traycer ist für alle, deren KI-Stack schon funktioniert, sich aber chaotisch anfühlt.
- OpenSpec ist für alle, die die leichtestmögliche Spec-Ebene wollen und kein weiteres Produkt um ihren Workflow gewickelt haben möchten.
- Tekk.coach gehört ins Plattform-Lager: Seine Loops finden die Arbeit in deinem Repo und schreiben die Spec, und das Board trackt sie, bis ein Merge sie schließt.
Wenn du hoffst, dass eines davon Unklarheit im Produkt wie von Zauberhand beseitigt: nein. Das kann keines von ihnen. Aber jedes geht anders mit Drift, Scope und Ausführung um.
Tekk.coach vs. Traycer vs. OpenSpec auf einen Blick
Hier die Kurzfassung. Das ist keine Tabelle für das „beste Tool“. Es ist eine Tabelle dafür, was zu dir passt.
| Kriterium | Tekk.coach | Traycer | OpenSpec |
|---|---|---|---|
| Integrationstiefe | Loops finden die Arbeit und schreiben die Spec; ein Board trackt sie, bis ein Merge sie schließt | Organizer-Ebene über deinem bestehenden KI-Coding-Stack | Schlankes Framework und Markdown-Struktur, den Rest bringst du mit |
| Bezug zur Codebase | Loops lesen, was sich in deinem verbundenen GitHub-Repo geändert hat, und verfolgen es bis zu dem, was es berührt | Stärker darin, die Ausführung zu organisieren, als darin, Specs aus dem Repo heraus zu erzeugen | Hängt davon ab, wie du es mit deinen eigenen Tools nutzt |
| Spec-Erzeugung | Loops schreiben Specs aus dem, was sich in deinem Code geändert hat; du kannst auch selbst eine schreiben | Strukturierte Aufschlüsselung und Tickets für die Ausführung durch Agents | Schlankes Markdown-Gerüst |
| Kanban und Workspace | Eingebautes Board; ein PR mit Closes TEK-123 schließt die Spec beim Merge ab |
Workflow-Organisation steht im Mittelpunkt | Nicht um ein Workspace-Produkt herum gebaut |
| Lernkurve | Flacher, wenn du an einem Ort arbeiten willst | Steiler, wenn dein Stack schon komplex ist | Am flachsten, wenn du dich in Markdown und im CLI wohlfühlst |
| Ökosystem | Produktzentriert; funktioniert mit Claude Code, Codex oder Cursor über MCP | Von Creators getragen und nah an Agent-Workflows | Offenes Repo, schlankes Ökosystem, oft mit OpenCode kombiniert |
| Für wen | Solo Founder und kleine KI-Coding-Teams, die sich die Arbeit finden lassen wollen | Fortgeschrittene, die mehrere Tools und Agents jonglieren | Alle, die im CLI zu Hause sind und Kontrolle und Minimalismus wollen |
Was diese Tabelle wirklich bedeutet
Wenn du Cursor, Claude Code, Codex oder Gemini schon in eine Routine eingebunden hast, die dir gefällt, ergibt Traycer mehr Sinn als eine komplette Plattform.
Wenn du zusätzliche UI hasst und nur ein Spec-Muster willst, das dir nicht im Weg steht, ist OpenSpec die sauberere Antwort.
Wenn du dir die Arbeit finden und als Spec aufschreiben lassen willst, in einem System statt verteilt über Docs, Notizen und Agent-Chats, passt der Plattform-Weg besser.
Der größte Fehler bei Tekk.coach vs. Traycer vs. OpenSpec ist die Annahme, dass sie direkt gegeneinander antreten. Meist tun sie das nicht. Sie liegen auf unterschiedlichen Ebenen des Workflows.
Die drei Philosophien: Plattform vs. Organizer vs. Framework
Sinnvoll vergleichst du diese Tools nach ihrer Philosophie, nicht nach der Zahl ihrer Badges oder dem Text auf ihrer Homepage.
Warum Feature-Listen diesen Vergleich verzerren
Eine Feature-Liste lässt alle drei ähnlicher aussehen, als sie sind. Alle haben mit Specs zu tun. Alle überschneiden sich mit KI-Coding-Workflows. Alle wollen verschwendete Zyklen reduzieren.
Aber die Ebene, die sie besetzen, ist eine andere.
Eine integrierte Plattform versucht, Kontextwechsel zu verringern. Ein Organizer geht davon aus, dass dein Stack schon existiert, und bringt Ordnung hinein. Ein Framework gibt dir Struktur ohne Produkthülle.
Wenn du eine breitere Übersicht über leichtgewichtigere Optionen willst, ist dieser Überblick über schlanke SDD-Frameworks im Vergleich eine nützliche Ergänzung.
Worauf jede Philosophie optimiert
Plattform heißt: ein Ort zum Planen, Verfeinern und Tracken. Das ist attraktiv, wenn du als Solo Builder den ganzen Tag zwischen Founder-Kopf, PM-Kopf und Umsetzungskopf hin und her wechselst. Der Nachteil liegt auf der Hand. Du entscheidest dich für eine abgeschlossene Umgebung statt für reine Flexibilität.
Organizer heißt: Deine Tools bleiben deine Tools. Der Organizer sitzt darüber und versucht zu verhindern, dass dein Workflow zu einem Haufen aus Prompts, halbfertigen Branches und Agent-Output wird, dem du nicht trauen kannst. Das ist mächtig, wenn du schon tief in CLI- und Agent-Workflows steckst. Es nervt, wenn du dir ein einfacheres Leben gewünscht hast und keine weitere Betriebsebene.
Framework heißt: maximale Kontrolle. Du bekommst ein sauberes Muster dafür, wie du Specs schreibst und weiterentwickelst, meist in Markdown, und das war es im Wesentlichen. Keine schwere App. Kein Workspace mit festen Vorgaben. Keine versteckte Automatisierung. Das ist der Weg für alle, die lieber ihren eigenen Stack zusammenstellen, als den von jemand anderem zu übernehmen.
Viel von der Aufregung um Spec-driven Development kommt daher, dass Leute diese Kategorien durcheinanderwerfen. Sie probieren ein Framework aus und erwarten die Führung einer Plattform. Oder sie führen einen Organizer ein, obwohl sie eigentlich weniger bewegliche Teile brauchen.
Wann Traycer deinen Workflow gewinnt
Zu Traycer greifst du, wenn dein aktuelles KI-Setup funktioniert, sich dein Tag aber chaotisch anfühlt. Du hast schon Agents. Du hast schon Prompts. Du hast schon einen IDE-Flow. Was dir fehlt, ist Kontrolle.
Traycer ist als Kontrollebene am stärksten
Am meisten spricht für Traycer bei großer, unübersichtlicher Arbeit. Der Epic Mode ist das herausragende Beispiel. In einem ausführlichen YouTube-Video wurde der Epic Mode als strukturierter, wiederholbarer Workflow beschrieben, der Absicht, Randbedingungen und Anforderungen von der Idee bis in die Produktion trägt und große Features dann in abgegrenzte Tickets zerlegt, die Agents ausführen können. Dasselbe Review sagt aber auch, dass Traycer über 30 Minuten brauchte, um Phasen und Pläne zu erzeugen, gegenüber 3 bis 3,5 Minuten bei Codex, Claude Code und Cursor, und nannte es in der Praxis für 9 von 10 Anwendungsfällen übertrieben, laut diesem Praxis-Review des Epic Mode auf YouTube.
Dieser Trade-off ist das ganze Produkt. Traycer investiert vorab mehr Zeit, um großer Arbeit Struktur aufzuzwingen. Wenn dein Hauptproblem Chaos ist, kann sich das lohnen.
Ein Reddit-Thread in der Vibecoding-Community zeigte dasselbe Muster. Jemand schrieb, Traycer funktioniere gut für größere Aufgaben, weil es Features in der Entwicklung automatisch validiert, beschrieb aber auch Nachteile, die die Person bei größeren Aufgaben trotzdem zu OpenSpec trieben. Nachlesen kannst du das in dieser Vibecoding-Diskussion auf Reddit über Traycer.
Wo Traycer schwerfällig wird
Traycer fühlt sich falsch an, sobald die Aufgabe klein, unsicher oder schnell im Wandel ist. Dann wird die Struktur zur Reibung.
Ein paar Fälle, in denen es gewinnt:
- Große Refactorings: Du brauchst Zerlegung mehr als Inspiration.
- Arbeit mit mehreren Agents: Du springst ohnehin zwischen Tools hin und her und willst ein Rückgrat für deinen Workflow.
- Arbeit mit Fokus auf Validierung: Dir sind Review-Durchgänge und Prüfungen nach dem Plan wichtig, nicht nur die erste Generierung.
Ein paar Fälle, in denen es verliert:
- Kleine Features: Die Zeremonie kostet mehr, als die Klarheit bringt.
- Schnelle Experimente: Du willst eine Idee heute Nachmittag testen, nicht formalisieren.
- Noch kein stabiler Stack: Traycer organisiert ein bestehendes System besser, als es eines erschafft.
Traycer würde ich niemandem in die Hand drücken, der als Solo Founder den eigenen Workflow noch nicht kennt. Besser passt es, wenn du schon einen hast und er dir über den Kopf wächst.
Dazu kommen die Signale aus der Community. Traycer ist in YouTube-Creator-Kreisen und Diskussionsthreads präsent, was zu seinem Stil passt. Es passt zu allen, die lernen, indem sie Workflows zuschauen und Prozessmuster übernehmen. Wenn das nach dir klingt, ist es ein ernsthafter Kandidat. Wenn du den einfachsten Weg vom Problem zur brauchbaren Spec willst, wahrscheinlich nicht.
Wann OpenSpec mit Einfachheit gewinnt
OpenSpec ist die sauberste Antwort, wenn du „Plattform“ hörst und am liebsten sofort den Tab schließen würdest.
Es will nicht dein Workspace sein. Es will nicht deinen ganzen Prozess einpacken. Es gibt dir ein schlankes Spec-Format, meist in Markdown, und lässt dich den Rest auf deine Art machen.
OpenSpec passt zu allen, die Zeremonie hassen
Die stärksten Belege für OpenSpec sind praktischer, nicht theoretischer Natur. In einem Praxisvergleich von KI-Tools für Spec-driven Development erzielte OpenSpec über 13 Dimensionen hinweg mit 4,00 die höchste Gesamtwertung, vor BMAD mit 3,65, Spec-Kit mit 3,74 und einem Basis-Tool mit 2,77. Derselbe Test bescheinigte OpenSpec den reibungsärmsten Einstieg, die beste Erfahrung direkt nach der Installation und Unterstützung für parallele Arbeit von Haus aus. Außerdem senkte es die Umsetzungszeit auf 1 Tag gegenüber 4 Tagen bei BMAD und die Umsetzungskosten auf 45 $ gegenüber 150 $ bei BMAD, so dieser Praxisvergleich mit OpenSpec.
Das Ergebnis ergibt Sinn. OpenSpec räumt fast alles aus dem Weg, was dich am Anfang bremst.
In der Community heißt es meist „Spec-Kit, nur schlank“. Das ist nah genug dran, um nützlich zu sein. Das offizielle OpenSpec-Repository von Fission-AI und die Dokumentationsseite von OpenSpec machen den Reiz deutlich. Es ist Markdown-first, leicht und lässt sich gut mit deinem eigenen Editor und Agent-Setup kombinieren.
Was du für diese Einfachheit aufgibst
OpenSpec gibt dir Freiheit, indem es sich weigert, viel für dich zu tun. Das ist zugleich seine Stärke und seine Grenze.
- Der Workflow gehört dir: Planung, Tracking, Review und Übergabe bleiben dein Problem.
- Du brauchst Urteilsvermögen: Ein leichtes Framework rettet kein unscharfes Feature.
- Du brauchst Gewohnheiten: Wenn deine Docs abdriften, hält OpenSpec dich nicht auf.
Deshalb passt OpenSpec gut zu allen, die sich im CLI schon wohlfühlen. Sie brauchen kein Produkt, das ihnen sagt, wo die Arbeit liegt. Das wissen sie schon.
Es wächst auch ein Ökosystem drumherum, darunter die Community-Ressourcen von awesome-openspec. Und wenn du prüfen willst, wie es in freier Wildbahn tatsächlich genutzt wird, sind die Community-Diskussion zu OpenSpec mit OpenCode auf Reddit und dieser YouTube-Vergleich OpenSpec vs. Spec Kit bessere Signale als polierte Landingpages.
Wenn du weniger Software zwischen dir und deiner Spec willst, lässt sich gegen OpenSpec kaum etwas sagen.
Wann Tekk.coach als deine Plattform gewinnt
Tekk.coach gewinnt, wenn das Problem nicht das Schreiben einer Spec ist. Das Problem ist, zu wissen, welche Spec du schreiben sollst, und sie ehrlich zu halten, sobald sie auf ein echtes Repo trifft.
Warum der Bezug zur Codebase bei Brownfield-Arbeit zählt
Am meisten zählt das bei Brownfield-Code, wo das Schwierige meist versteckter Kontext ist.
Legacy-Repos schleppen alte Namensentscheidungen, halbfertige Abstraktionen, seltsame Edge Cases und Geschäftsregeln mit sich, die erst Sinn ergeben, nachdem du drei Dateien und eine Migration gelesen hast. Generische Spec-Workflows bügeln diese Realität gern glatt. Du bekommst einen sauber aussehenden Plan, der plausibel klingt, und dann stößt die Umsetzung auf die tatsächlichen Randbedingungen des Repos. Laut Analysen von Augment Code scheitern 78 % der neuen KI-Coding-Features in Legacy-Codebases an vagen Specs, wie der Report von Augment über die besten Tools für Spec-driven Development darlegt.
Das spricht stark für eine Plattform, die das Repo kennt. Sie verringert die Unklarheit, bevor die Arbeit bei Cursor, Claude Code, Codex oder Gemini ankommt.
Was diese Plattform tut und was nicht
Tekk.coach gehört in eine andere Kategorie als Traycer und OpenSpec. Seine Loops finden die Arbeit und schreiben die Spec. Sechzehn davon (Security, Payments, Reliability, Testing und weitere) wachen auf, wenn sich dein Code ändert, lesen, was sich geändert hat, und bringen ein Proposal mit. Du gibst es mit Greenlight als Spec auf deinem Board frei oder lehnst es mit einer Begründung ab, und die Loops lernen daraus. Du kannst auf demselben Board auch selbst eine Spec schreiben.
Dieser Ansatz passt zu allen, die ihren Prozess nicht selbst aus Markdown-Dateien, Tickets, Prompts und Chat-Threads zusammenbauen wollen. Das Board hält Proposals, Specs und die Pull Requests, die sie umsetzen, an einem Ort, und das zählt, wenn du die einzige Person bist, die den Produktkontext im Kopf trägt.
Die Grenzen sind ebenfalls real:
- Es schreibt nie Code und liefert keinen aus: Claude Code, Codex oder Cursor setzt die Spec über den Tekk-MCP-Server um
- Es betreibt keinen eigenen Coding-Agent
- Die PR-Verknüpfung ist für GitHub gebaut
- Die Loops sind kein Schwarm von Agents
Die Loops sind enger gefasst als ein Schwarm, was ich als Vorteil sehe. Jeder Lauf arbeitet mit einer Methode und bringt höchstens ein Proposal mit oder ein ehrliches „nichts gefunden“, statt einer Flut generierter Aktivität. So bleibt der Takt gleichmäßig und überprüfbar.
Richtig ist das meist für Solo Founder oder kleine Teams, die in einem bestehenden Repo arbeiten und spüren, was verstreuter Kontext kostet. Wenn Traycer ein Organizer ist und OpenSpec ein schlankes Framework, dann ist Tekk.coach die Option für alle, die sich die Arbeit finden lassen wollen, die Spec aus dem Repo-Kontext geschrieben bekommen möchten und einen Merge wollen, der sie schließt.
Das Fazit: So wählst du dein Tool
Der falsche Weg, zwischen diesen dreien zu wählen, ist Features zu zählen. Alle drei können dir helfen, Specs zu erstellen. Sie unterscheiden sich darin, worauf sie optimieren, und diese Wahl macht sich schnell bemerkbar, sobald das Projekt unübersichtlich wird.
Wähl nach dem Fehlermuster
Wähl Traycer, wenn Koordination die größte Herausforderung ist. Das Repo existiert, die Arbeit läuft schon, und die Dinge zerfasern immer wieder über Aufgaben, Prompts und Übergaben hinweg. Traycer passt am besten, wenn du einen Organizer willst, der einem vollen Workflow Struktur gibt. Wenn du diesen Blickwinkel genauer erklärt haben willst, ist diese Analyse zu Traycer-Alternativen ein nützlicher nächster Schritt.
Wähl OpenSpec, wenn du am besten nah am Code arbeitest und fast keinen Plattform-Overhead willst. Es passt zu allen, die den Prozess gern selbst in der Hand haben, Markdown direkt bearbeiten und das Framework so leicht halten, dass es nie zu einem weiteren System wird, das gepflegt werden muss.
Wähl Tekk.coach, wenn dein Engpass darin besteht, zu wissen, was du in einem bestehenden Repo als Nächstes bauen sollst. Es passt, wenn du als Solo Founder oder in einem sehr kleinen Team willst, dass Loops die Arbeit finden und die Spec schreiben, und ein Board, auf dem der Merge sie schließt, statt Arbeit, die über Docs, Chats und Tickets verstreut ist.
Das ist die saubere Aufteilung. Plattform, Organizer oder Framework.
Zwei benachbarte Optionen, die du kennen solltest
Ein paar Optionen in der Nähe verdienen trotzdem eine kurze Erwähnung, vor allem, damit du sie nicht mit den drei Kategorien oben verwechselst.
Get Shit Done (GSD) passt zu einem engeren Setup. Es richtet sich vor allem an alle, die mit Claude Code arbeiten, einen leichteren Prozess wollen und nicht viel Abstraktion brauchen.
BMAD ist stärker von der Community getragen. Es kann nützlich sein, wenn dir gemeinsame Muster und eine aktive Diskussion wichtiger sind als Feinschliff oder Konsistenz in den Docs.
Wenn du die früheren Vergleiche in diesem Artikel schon gelesen hast, ist das genug Kontext, um beide einzuordnen.
Specs von Hand zu schreiben ist der manuelle Weg. Die Loops von Tekk.coach schreiben sie für dich, aus dem, was sich in deinem Code geändert hat – dasselbe Board, dieselben Akzeptanzkriterien, und die Spec schließt sich, sobald der PR gemergt wird, der sie umsetzt.
Teil des Leitfadens zu Spec-driven Development – ein ehrliches Playbook dafür, mit KI-Coding-Agents auszuliefern. Die andere Hälfte ist Loop Engineering: An der Spec erkennt ein Loop, dass er fertig ist.