Die meisten Ratschläge zu Spec-driven Development sind zu glatt. Sie tun so, als würden alle Spec-Tools denselben Job erledigen.
Tun sie nicht.
Im Mai 2026 wurde der Gegenwind laut. SDD wurde als „Wasserfall mit Markdown“ bezeichnet, als „Produktivitätsfalle“ und als „Token verbrennende Zeremonie“. Simon Willison und Birgitta Böckeler brachten in den Diskussionen rund um spec-first, spec-anchored und spec-as-source eine nützlichere Einteilung ins Spiel, denn das Kernproblem ist nicht „Specs sind schlecht“. Sondern dass starre Formate, oft geprägt von Addy Osmanis kanonischer Spec mit sechs Abschnitten, schnell veralten, wenn du an echter Software iterierst statt an Lehrbuchbeispielen. Diese Kritik zeigte sich deutlich in dieser Diskussion aus dem Produktmanagement über Spec-driven Development.
Die Kritik liegt nicht falsch. Ein aufgeblähter Spec-Prozess bremst Solo Builder bis zum Stillstand aus.
Aber vages Prompting ist schlimmer. Wenn du mit Cursor, Claude Code, Codex oder Gemini baust, brauchst du irgendwo Struktur. Die Frage ist, wo diese Struktur lebt, wie viel Zeremonie sie mitbringt und was passiert, wenn der erste Plan falsch ist. Genau das übersehen die meisten Vergleiche. Für Solo Builder ist die wichtigste Kennzahl der Preis jeder Iteration.
Wenn du dir neben Coding-Specs auch allgemeinere Workflow-Tools anschaust, liefert diese Übersicht über die besten KI-Tools zur Aufgabenautomatisierung nützlichen Kontext. Und wenn du noch überlegst, ob du überhaupt einen Spec-Workflow brauchst, ist dieser Leitfaden zu Spec-driven Development vs. Vibe Coding der treffendere Vergleich.
Inhalt
- Ist Spec-driven Development eine Produktivitätsfalle?
- Die drei Tools auf einen Blick
- Wann du GitHub Spec Kit wählen solltest
- Wann du ChatPRD wählen solltest
- Wann du Tekk.coach wählen solltest
- Das Fazit: Deine finale Checkliste
Ist Spec-driven Development eine Produktivitätsfalle?
Ja, das kann es sein.
Wenn dein Workflow jedes Feature in einen Mini-Wasserfall verwandelt, betreibst du keine disziplinierte KI-Entwicklung. Du schreibst Papierkram um seiner selbst willen. Genau deshalb hat der Gegenwind getroffen. Begriffe wie Spec Drift, eingefrorene Specs und Wasserfall mit Markdown fanden Anklang, weil viele, die bauen, den Schmerz schon selbst gespürt hatten.
Der Gegenwind reagiert auf etwas Echtes
Spec-driven Development wurde populär, weil KI-Coding-Agents besseren Kontext brauchen als „bau mir Stripe-Billing“. Aber viele Teams haben überkorrigiert. Sie haben schlampiges Prompting durch schwerfällige Prozesse ersetzt.
Daraus entstehen typische Fehler:
- Specs veralten: Du änderst das Produkt, aber das Markdown hält nicht Schritt.
- Agents verbrennen Kontext für Zeremonie: Lange Docs fressen Tokens, ohne die Umsetzung zu verbessern.
- Iteration wird teuer: Kleine Änderungen zwingen dich, einen großen Planungsstapel neu zu schreiben.
Praktische Regel: Wenn du für einen einzigen Button oder eine einzige Validierungsregel ein halbes Spec-System aktualisieren musst, ist dein Prozess zu schwer.
Solo Builder brauchen trotzdem Disziplin bei Specs
Die Antwort ist nicht, zurück zu reinem Vibe Coding zu gehen. Für Spielzeug-Prototypen ist das in Ordnung. Bei allem mit Auth, Billing, Jobs, Migrationen, Edge Cases oder einer bestehenden Codebase fällt es auseinander.
Bis Ende 2025 hatten über 60 % der neuen KI-Coding-Projekte einen strukturierten Spec-Workflow eingeführt, um Agents zur richtigen Zeit den richtigen Kontext zu geben. Dieser Wandel war wichtig, weil Specs kein Wegwerfgerüst mehr waren und in vielen Workflows zum wichtigsten Artefakt wurden. Code galt zunehmend als generierter Output der Spec, nicht umgekehrt.
Deshalb lautet die richtige Frage nicht „Soll ich Specs nutzen?“. Sie ist enger.
Nimm ein CLI-Kit, wenn du portable Templates willst und den Kontext gern selbst verwaltest. Nimm einen PRD-Generator im PM-Stil, wenn dein Hauptjob die Abstimmung mit Stakeholdern ist. Nimm einen Planer, der deine Codebase kennt, wenn dein eigentliches Problem ist, einen AI Agent dazu zu bringen, in bestehendem Code korrekt zu arbeiten.
Die drei Tools auf einen Blick
Am schnellsten entscheidest du zwischen GitHub Spec Kit, ChatPRD und Tekk.coach, wenn du aufhörst zu fragen, welches mehr Features hat.
Frag stattdessen, für welchen Job du es einstellst.
| Kriterium | GitHub Spec Kit | ChatPRD | Tekk.coach |
|---|---|---|---|
| Zielgruppe | Engineers, die in der CLI zu Hause sind, Tüftelnde, Open-Source-orientierte Builder | PMs, Founder, Stakeholder, die für Menschen lesbare Docs brauchen | Solo Builder und kleine KI-Coding-Teams, die wollen, dass die Arbeit für sie gefunden und nicht nur aufgeschrieben wird |
| Output-Format | Strukturierte Markdown-Dateien und ein Workflow mit Slash-Commands | Klassische Dokumentation im PRD-Stil | Specs auf einem Board, mit Akzeptanzkriterien und einer Checkliste für die Build-Reihenfolge |
| Kenntnis der Codebase | Keine native Verankerung im Live-Repo im Kern-Workflow | Prompt-first, nicht in deiner Codebase verankert | Loops lesen, was sich in deinem Repo geändert hat, finden die Arbeit und schreiben die Spec als Proposal, das du mit Greenlight freigibst |
| Ausführungsebene | Du gibst die generierten Artefakte an den Assistenten deiner Wahl weiter | Meist zuerst ein Übergabe-Artefakt für Menschen | Dein Coding-Agent (Claude Code, Codex, Cursor) baut die Spec über den Tekk-MCP-Server; der PR mit Closes TEK-123 schließt sie beim Merge ab |
| Preis | Open Source, MIT-Lizenz | Kommerzielles PRD-Tool | Kommerzielles Produkt |
| Ökosystem | Viel Aufmerksamkeit in der Open-Source-Welt und breite Unterstützung für Assistenten | Auf der PM-Seite bekannt | Neuer und fokussierter |
| Brownfield-Unterstützung | Möglich, aber du lieferst den Kontext von Hand | Schwach bei bestehenden Codebases | Dafür gebaut: Loops starten beim Delta in einer bestehenden Codebase |
| Lernkurve | Steiler, wenn du CLI-Workflows nicht magst | Flach, wenn du ohnehin in PRDs denkst | Flach, sobald das Repo verbunden ist; meist gibst du Proposals nur mit Greenlight frei oder lehnst sie ab. Setzt GitHub-Zugriff voraus |
Was mehr zählt als die Feature-Liste
Für Solo Builder haben diese Zeilen nicht dasselbe Gewicht.
Kenntnis der Codebase zählt mehr als ein polierter Output, wenn du in Brownfield-Code arbeitest. Die Ausführungsebene zählt mehr als schöne Prosa, wenn du einen AI Agent fütterst und kein Teammeeting. Und die Lernkurve zählt nur bis zu dem Punkt, an dem schlechte Specs Nacharbeit erzwingen.
Das beste Spec-Tool ist nicht das, das das hübscheste Dokument schreibt. Sondern das, das die zweite und dritte Iteration billiger macht.
Unter der Oberfläche verbirgt sich außerdem eine Spaltung im Markt. GitHub Spec Kit ist am stärksten, wenn du offene, Agent-agnostische Struktur willst. ChatPRD ist am stärksten, wenn das Dokument für Menschen ist. Tekk.coach ist am stärksten, wenn die Specs für dich geschrieben werden sollen, ausgehend von dem, was sich in einem echten Repository geändert hat, und geschlossen werden, wenn die Arbeit gemergt ist.
Diese Spaltung wird noch deutlicher, wenn du Greenfield- und Brownfield-Arbeit unterscheidest. Laut Branchendaten aus dem Stack Overflow Developer Survey 2025 arbeiten 78 % der professionellen Devs hauptsächlich an Legacy-Systemen, und trotzdem laufen die meisten Demos von Spec-Tools auf Projekten auf der grünen Wiese. Das ist genau verkehrt herum, gemessen daran, wie die meisten typischerweise bauen.
Wann du GitHub Spec Kit wählen solltest
GitHub Spec Kit gewinnt, wenn du Kontrolle willst, keine Lizenzkosten und einen Workflow, der sich im Terminal wohlfühlt.
Es startete im September 2025 und erreichte innerhalb von zwei Monaten 50.000 GitHub-Sterne. So eine Verbreitung passiert nicht zufällig. Sie hat dem Markt gezeigt, dass Builder mehr Struktur wollten als freies Prompting, aber auch keinen Vendor-Lock-in. Das Toolkit war darauf ausgelegt, mit allen großen Coding-Assistenten zu funktionieren, und Ende 2025 gehörte es zu den am stärksten anpassbaren SDD-Optionen überhaupt.
Warum Spec Kit so schnell eingeschlagen hat
Spec Kit gibt dir einen portablen Workflow mit klaren Vorgaben. In v0.1.6 kommt es als Open-Source-CLI-Toolkit unter MIT-Lizenz mit sieben Slash-Commands wie /specify, /plan, /tasks, /analyze, /implement, /clarify und /constitution, und es unterstützt über 15 KI-Assistenten – so steht es im Launch-Material von GitHub und in der Diskussion, die dieser Reddit-Thread über den Token-Verbrauch von Spec Kit festhält.
Das zählt, wenn dir ein paar Dinge wichtig sind:
- Kein Budget: Du kannst es einführen, ohne noch ein SaaS zu kaufen.
- Portabilität: Du bist nicht an einen IDE-Assistenten gebunden.
- Eigene Templates: Du kannst den Workflow an deine Gewohnheiten anpassen.
- Klarheit auf der grünen Wiese: Eine neue App aus einem leeren Repo zu starten, ist der Fall, in dem es sich am saubersten anfühlt.
Viele Engineers mögen genau das. Die Struktur ist explizit. Die Commands sind einprägsam. Die Dateien lassen sich prüfen. Wenn du einen reproduzierbaren Workflow willst statt Spaghetti aus Chatverläufen, ist Spec Kit ein echtes Upgrade.
Dazu kommt die Anziehungskraft des Ökosystems. Das Repository selbst wurde zu einem starken Signal dafür, wie viel Aufmerksamkeit das Thema bekommt, und die breitere Community rund um das Repo von GitHub Spec Kit macht es leichter, Beispiele, Forks und Leute zu finden, die über Best Practices streiten.
Wo Spec Kit an seine Grenzen kommt
Spec Kit hat ein typisches Fehlermuster, und das ist nicht subtil.
Es kann zu Markdown-Overhead werden, der sich als Gründlichkeit tarnt.
Die Kritik nannte das eine Zeremonie, die Tokens verbrennt, und das Etikett blieb hängen, weil es eine echte Erfahrung beschreibt. Der Workflow kann eine Menge Markdown erzeugen. Manchmal verbessert die zusätzliche Struktur die Umsetzung. Manchmal bringt sie den Assistenten nur dazu, mehr zu lesen, bevor er das Offensichtliche tut.
„Spec-driven Development mit Speckit frisst mein Token-Budget“
Diese Beschwerde ist berechtigt, denn der Workflow verlangt, dass du vorab eine Overhead-Steuer zahlst. Wenn du diszipliniert bist, kann sich diese Steuer lohnen. Wenn du schlampig bist, bekommst du die ganze Zeremonie und nichts vom Ertrag.
Spec Kit lässt dich die Brownfield-Last außerdem selbst tragen. Es liest dein Repository nicht nativ und leitet keine Vorgaben aus dem Live-Code ab. Bei einer bestehenden App musst du Architektur-Kontext, Dateistruktur, Implementierungsvorgaben und die unangenehmen „Fass diesen Service nicht an“-Regeln selbst zusammensuchen. Wenn du etwas übersiehst, kann die Spec solide aussehen und den Agent trotzdem in die falsche Richtung lenken.
Wähl Spec Kit, wenn deine Rahmenbedingungen so aussehen
Passt gut:
- Du lebst in CLI-Workflows: Arbeit im Terminal fühlt sich natürlich an, nicht lästig.
- Du willst Open Source: Die MIT-Lizenz ist dir wichtig.
- Du startest auf der grünen Wiese: Die Constitution von Grund auf zu definieren, ist für dich ein Feature, keine lästige Pflicht.
- Du willst Agent-Agnostik: Du willst kein Tool, das an einen Anbieter gebunden ist.
Passt schlecht:
- Du hasst es, Docs zu pflegen: Der Markdown-Stapel wird dich nerven.
- Du steckst tief in Brownfield-Code: Fehlender Repository-Kontext wird dich teuer zu stehen kommen.
- Du brauchst möglichst wenig Reibung beim Iterieren: Kleine Änderungen können sich schwerer anfühlen, als sie sollten.
Spec Kit ist am besten für Builder, die ein Framework wollen, das ihnen gehört. Schlechter ist es für alle, die wollen, dass das Tool die Realität aus dem Code ableitet, den sie schon haben.
Wann du ChatPRD wählen solltest
ChatPRD erledigt einen engeren Job, als viele annehmen. Es ist ein Tool zum Schreiben über Produkte, das grobe Feature-Ideen in ein PRD verwandelt, das jemand anderes lesen, kritisieren und verfeinern kann. Für Solo Builder ist diese Unterscheidung wichtig, weil der Preis der Iteration erst später sichtbar wird. Der erste Entwurf fühlt sich schnell an. Die Aufräumphase oft nicht.
Was ChatPRD gut kann
ChatPRD funktioniert am besten, wenn das Ergebnis die Kommunikation zwischen Menschen verbessern soll, bevor irgendwer Code anfasst.
Das heißt meistens:
- Übergabe-Docs fürs PM
- Abstimmung mit Stakeholdern
- Feature-Briefings
- Hintergrund, Ziele, User Stories und Anforderungen in einem vertrauten Format
Für nicht-technische Founder, PMs oder Beratende, die mit Kundschaft arbeiten, hilft diese Struktur. Ein sauberes PRD gibt Menschen etwas Konkretes, worauf sie reagieren können. Es reduziert vages Feedback und erzwingt Scope-Entscheidungen früher.
Es hilft auch, wenn dein Engpass noch auf der Produktseite liegt. Wenn die Idee unscharf ist, ist ein ausgefeiltes PRD besser, als einen halbgaren Prompt in einen KI-Coding-Agent zu kippen und zu hoffen, dass sich die fehlenden Details von selbst klären. Wenn du dieses Artefakt zuerst schärfen willst, hilft dieser Leitfaden dazu, wie du ein PRD schreibst.
Der echte Trade-off für Solo Builder
ChatPRD ist schwächer, wenn dasselbe Dokument die Implementierung direkt steuern soll.
Das Problem ist nicht, dass das PRD schlecht wäre. Das Problem ist, dass ein Dokument für Menschen und eine Spec, mit der ein Agent arbeiten kann, verschiedene Artefakte sind. Das eine erklärt die Absicht. Das andere braucht genug Implementierungskontext, um den ersten Kontakt mit einem echten Repository zu überstehen.
Für Solo Builder ist diese Lücke teuer. Niemand aus dem PM übergibt das Doc ans Engineering. Kein Senior Engineer übersetzt die Produktabsicht in Vorgaben auf Dateiebene. Diese Arbeit machst du selbst, meist nachdem der erste generierte Plan wichtige Details falsch erwischt hat.
Genau dort beginnt der Preis der Iteration zu steigen.
Ein PRD kann das Feature gut beschreiben und trotzdem die Details verfehlen, die entscheiden, ob ein AI Agent nützlichen Code schreibt oder Zeit verbrennt:
- Falsche Annahmen über Dateien
- Fehlende Framework-Konventionen
- Erfundene API-Strukturen
- Schwache Grenzen des Scopes
- Keine Repository-spezifischen Vorgaben
Auch ein ausgefeiltes PRD kann einen langsamen Implementierungs-Loop erzeugen.
Ich habe dieses Fehlermuster mehr als einmal erlebt. Der erste Durchgang wirkt klug, der zweite wird zur Korrektur, und der dritte wird zur manuellen Übersetzung von Produktsprache in Engineering-Sprache. Wenn du allein baust, zählt diese Übersetzungssteuer mehr als die Qualität des Dokuments selbst.
Hier ist eine nützliche Diskussion, die die benachbarte Denkweise aus dem PM-Workflow zeigt:
Wähl ChatPRD, wenn Menschen das Dokument lesen
Nutze ChatPRD, wenn dein Workflow so aussieht:
- Du brauchst Abstimmung vor der Implementierung: Das Dokument braucht Freigabe, Feedback oder das Okay der Kundschaft.
- Ein Mensch interpretiert das PRD, bevor das Coden beginnt: Die Übergabeebene existiert, auch wenn nur du selbst prüfst und umschreibst.
- Dir ist Klarheit übers Produkt wichtiger als Präzision, die im Code verankert ist: Der Hauptjob ist festzulegen, was gebaut werden soll.
Lass es als dein wichtigstes Spec-Tool weg, wenn dein Ziel die direkte Umsetzung in einer bestehenden Codebase ist. In diesem Workflow wird jede Abweichung zwischen PRD und Repo zu neuem Spezifizieren, Prompt-Reparatur oder manuellem Debugging. Für Solo Builder ist das die Kennzahl, die zählt. Nicht, wie schnell der erste Entwurf erscheint, sondern wie viele Korrektur-Loops er danach auslöst.
Wann du Tekk.coach wählen solltest
Wähl Tekk.coach, wenn der teure Teil deines Workflows nicht das Schreiben der Spec ist. Sondern überhaupt zu bemerken, was eine Spec braucht, und die Spec ehrlich zu halten, nachdem das Repo Widerstand geleistet hat.
Das ist das Problem von Solo Buildern.
Ein sauberer erster Entwurf bedeutet wenig, wenn du die nächsten zwei Stunden damit verbringst, falsche Annahmen über Routen, Modelle, Namenskonventionen oder den richtigen Ort für das Feature zu korrigieren. Tekk.coach passt zu allen, die in einer bestehenden App arbeiten und wollen, dass die Spec bei dem ansetzt, was sich in der Codebase geändert hat, nicht bei einem leeren Prompt.
Warum Tekk.coach Iterationen billiger macht
Der praktische Vorteil ist einfach: Loops finden die Arbeit und schreiben die Spec. Sechzehn Loops (Security, Reliability, Payments, Testing und mehr) wachen auf, wenn sich dein Code ändert, lesen, was sich geändert hat, und bringen dir ein Proposal nach dem anderen. Gibst du es mit Greenlight frei, wird es zur Spec auf deinem Board; lehnst du es mit einer Begründung ab, lernen die Loops daraus. Du kannst eine Spec weiterhin von Hand schreiben, auf dasselbe Board. Wenn du den breiteren Ansatz verstehen willst, erklärt ihr Artikel über Spec-driven Development, das deine Codebase kennt das Modell.
Das verändert, was in der Spec landet:
- Verweise auf konkrete Dateien statt allgemeiner Implementierungstipps
- Hinweise, die das Framework und die Muster widerspiegeln, die schon im Repo stecken
- Klare Grenzen des Scopes auf Basis der bestehenden Architektur
- Vorgaben aus dem tatsächlichen Projekt, nicht aus dem Prompt erraten
- Akzeptanzkriterien und eine Checkliste, die die Spec beim Merge des PRs schließen
Für Solo Founder zählt das, weil Nacharbeit meist mit falschen Annahmen beginnt. Prompt-first-Tools klingen oft selbstsicher, während sie Strukturen erfinden, die dein Repo nicht hat. Dann zahlst du für diesen Fehler an drei Stellen: Prompt-Reparatur, Debugging und das Umschreiben der Spec, damit der Agent aufhört herumzuirren.
Ich bin oft genug auf dieses Problem gestoßen, um Kenntnis des Repos als Tempo-Feature zu behandeln, nicht als nettes Extra.
Das Prinzip „ein Proposal nach dem anderen“ ist aus demselben Grund nützlich. Tekk tut nicht so, als würde es die Implementierung ersetzen; es schreibt nie den Code. Jeder Loop bringt pro Lauf höchstens ein Proposal, und dein Coding-Agent baut über den Tekk-MCP-Server, was du mit Greenlight freigibst. Diese Beschränkung ist ein Feature. Du bekommst einen fokussierten nächsten Schritt statt einer Flut spekulativer Ratschläge, die noch mehr Prüfarbeit erzeugen.
Wann es die richtige Wahl ist
Tekk.coach ist die bessere Wahl, wenn deine Woche so aussieht:
- Du erweiterst ein Produkt, das schon Nutzende, Datenmodelle und schwer änderbare Flows hat.
- Du brauchst Specs, die sich auf echte Dateien und Muster im Repo zurückführen lassen.
- Du nutzt KI-Coding-Tools für die Umsetzung, aber die Schwachstelle ist, zu wissen, was als Nächstes gebaut werden soll.
- Du arbeitest allein, also wird jede falsche Annahme sofort zu deinem Problem.
Der Gewinn ist keine hübschere Dokumentation. Der Gewinn sind weniger Korrektur-Loops nach dem ersten Durchgang.
Die Trade-offs
Tekk.coach ist nicht für jedes Projekt die Standardantwort.
- Workflow nur mit GitHub: Wenn das Repo woanders liegt, ist diese Einschränkung relevant.
- Geschlossenes Produkt: Du bekommst nicht dasselbe hackbare CLI-Gefühl und nicht dieselbe lokale Kontrolle wie bei Spec Kit.
- Bauen tut weiterhin dein Agent: Tekk schreibt nie Code. Dein Coding-Agent holt sich die Spec über MCP, und nur ein PR mit
Closes TEK-123schließt sie ab. - Kleineres Ökosystem: Weniger Community-Erweiterungen, Beispiele und eingespielte Gewohnheiten rund um das Tool.
Diese Trade-offs sind akzeptabel, wenn dein Engpass darin liegt, in einem Brownfield-Repo die richtige Arbeit zu finden und zu spezifizieren. Weniger akzeptabel sind sie, wenn dir Portabilität, offene Tools oder Docs im PM-Stil am wichtigsten sind.
Wähl Tekk.coach, wenn du Specs lieber prüfst als schreibst und jede einzelne in deinem Repo verankert und durch den Merge geschlossen sein soll, der sie fertigstellt.
Das Fazit: Deine finale Checkliste
Feature-Tabellen sind ein schlechter Weg, diese Entscheidung zu treffen.
Solo Builder bezahlen Fehler mit Zeit, nicht mit fehlenden Häkchen. Die Kernfrage ist nicht, welches Tool in einer Demo am stärksten aussieht. Sondern welches den unvermeidlichen zweiten Durchgang weniger schmerzhaft macht, nachdem die erste Spec einen Edge Case, eine Abhängigkeit oder eine im Repo vergrabene Vorgabe übersehen hat.
Wähle nach dem Preis der Iteration
Diese Brille verändert die Rangfolge.
Wenn das Geld knapp ist und du bereit bist, die Struktur selbst zu liefern, ist GitHub Spec Kit der günstigste Weg zu einem disziplinierten Workflow. Wenn dein größtes Fehlermuster unscharfes Produktdenken oder fehlende Abstimmung vor dem Coden ist, liefert ChatPRD meist das bessere Artefakt. Wenn deine Woche vor allem aus fehleranfälligen Änderungen in einem bestehenden Produkt besteht, spart es meist die meiste Zeit, wenn Loops die Arbeit finden und die Spec schreiben, weil die Spec bei dem ansetzt, was sich tatsächlich geändert hat.
Genau das übersehen viele Vergleiche. Solo Builder arbeiten selten an sauberen Greenfield-Demos. Sie arbeiten in halb fertigen Produkten, mit verkorksten Schema-Entscheidungen, alten Routennamen, brüchiger Auth-Logik und Flows, die sich nicht ohne Nebenwirkungen neu schreiben lassen. In diesem Umfeld zählt der Preis der Iteration mehr als die Frage, wie poliert das Template aussieht.
Eine praktische Shortlist
Wähl GitHub Spec Kit, wenn du Folgendes willst:
- Einen Open-Source-Workflow
- Einen Prozess, der von der CLI ausgeht
- Templates, die an kein bestimmtes Modell und keinen Anbieter gebunden sind
- Volle Kontrolle – und es macht dir nichts aus, mehr von der Vorarbeit selbst zu leisten
Wähl ChatPRD, wenn du Folgendes willst:
- Ein Dokument, das zuerst für die Prüfung durch Menschen gebaut ist
- Klare Anforderungen, bevor die Implementierung beginnt
- Einen Workflow, der zur Denkweise von Foundern oder PMs passt
- Ein Übergabe-Artefakt, das noch eine Interpretation durchs Engineering braucht
Wähl Tekk.coach, wenn du Folgendes willst:
- Loops, die die Arbeit finden und die Spec aus dem schreiben, was sich in deinem GitHub-Repo geändert hat
- Ein Proposal, das du mit Greenlight freigibst oder ablehnst, statt einer leeren Seite
- Deinen eigenen Coding-Agent, der die Spec über MCP baut
- Specs, die sich schließen, wenn der PR gemergt und die Checkliste erledigt ist
Nachdem ich alle drei genutzt habe, ist meine Sicht einfach.
- GitHub Spec Kit gibt dir die meiste Kontrolle. Es bürdet dir aber auch den meisten Kontext auf. Wenn du vage bist, macht es aus dieser Vagheit getreu einen schwachen Plan.
- ChatPRD liefert das sauberste Produktdokument. Du musst dieses Doc aber immer noch in Code-Entscheidungen, Dateiänderungen und eine Implementierungsreihenfolge übersetzen.
- Tekk.coach schreibt die Specs für dich. Seine Loops finden die Arbeit in einer bestehenden Codebase, und der Merge schließt sie. Im Gegenzug gibst du etwas Portabilität und Offenheit auf.
Entscheide nach der Schwachstelle in deinem aktuellen Prozess.
Wenn der KI-Output chaotisch ist, weil der Prompt zu lose ist, nimm mehr Struktur. Wenn die Planung zur Zeremonie geworden ist, die das Ausliefern bremst, nimm weniger Prozess. Wenn das Problem ist, dass das Modell den Code, den du schon hast, immer wieder missversteht, fang mit dem Tool an, das die Spec aus dem Repo schreibt.
Dieser letzte Fall wird für Solo Builder schnell teuer. Eine einzige falsche Annahme in einer Live-Codebase kann dich in die falschen Dateien schicken, zur falschen Abstraktion und in eine Aufräumrunde, für die du kein Budget eingeplant hattest.
Die Kurzfassung: Wähl das Tool, das Fehler billiger macht. Für Kontrolle auf der grünen Wiese nimm Spec Kit. Für Produktanforderungen, die Menschen lesen sollen, nimm ChatPRD. Für bestehende Codebases, in denen Loops die Arbeit finden und die Spec schreiben sollen, nimm Tekk.coach.
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.