Die meisten Ratschläge zu SDD für Solo Developer sind verkehrt herum. Sie sagen dir, du sollst dich wie ein zehnköpfiges Team verhalten, obwohl du allein und müde vor einem Repo, einem Backlog und einer KI sitzt, die fröhlich in die falsche Richtung sprintet, wenn du sie mit Brei fütterst.
Genau deshalb wird so viel Spec-first-Rat 2026 verspottet. Man nennt es „Wasserfall mit Markdown“, „Spec Drift“, „eingefrorene Specs“ und „Token verbrennende Zeremonie“. Ganz unrecht hat die Kritik nicht. Ein großes PRD, eine Constitution, ein Plan, Tasks und jede Menge Zeremonie werden schnell zur Produktivitätsfalle. Simon Willison gehört zu diesem breiteren Gegenwind, und Birgitta Böckelers Einteilung in spec-first, spec-anchored und spec-as-source ist wichtig, weil sie nützliche Disziplin von Dogma trennt. Der Fehler ist, jedes SDD für dasselbe zu halten.
Für Solo Builder ist die nützliche Version schlank. Eine kurze Spec. Eine fokussierte Build-Session. Ein Self-Review gegen die Akzeptanzkriterien. Mehr braucht es nicht. Wenn du die lange Version darüber willst, wo Specs helfen und wo sie deine Zeit verschwenden, lies diese Analyse, wann Specs dich bremsen und wann sie helfen.
Inhalt
- Warum die meisten SDD-Ratschläge eine Falle für Solo-Devs sind
- Die solotaugliche Spec nach Addy Osmanis Format
- Dein Workflow vom Problem zur KI-tauglichen Spec
- Die Übergabe: Specs an KI-Coding-Agents geben
- Der Loop: Self-Review und nächtliche Audits
- Typische Fallstricke und wie du sie vermeidest
Warum die meisten SDD-Ratschläge eine Falle für Solo-Devs sind
Der Gegenwind ist verdient
Wenn du dir GitHub Spec Kit, Kiro, OpenSpec, Traycer, Vibe Kanban oder BMAD angesehen hast, ist dir die Spaltung wahrscheinlich aufgefallen. Manche schwören darauf. Andere halten die ganze Kategorie für Beschäftigungstherapie mit KI-Anstecker.
Dieser Gegenwind ist echt, weil viele SDD-Inhalte immer noch nach Prozess-Cosplay riechen. Sie geben dir eine Constitution, eine Planungsphase, eine Zerlegung in Tasks, vielleicht eine Taxonomie, vielleicht eine Matrix – und tun dann überrascht, wenn jemand, der allein gründet, den Tag mit Doku-Pflege verbringt statt mit Ausliefern. Thoughtworks Tech Radar und Addy Osmani werden aus guten Gründen zitiert, aber oft wird nur die Zahl der Artefakte kopiert und der Kern übersehen.
Praktische Regel: Wenn dein Spec-Workflow mehr Dokumente als Entscheidungen erzeugt, ist er für Solo-Arbeit schon zu schwer.
Es gibt noch einen Grund, warum die Kritik gesessen hat. 2026 wird Spec-driven Development so definiert: Eine präzise, ausführbare Spec ist die Source of Truth, und Code gilt als generiertes, überprüfbares Artefakt – ausdrücklich als Antwort auf „Vibe Coding“, einen Begriff, den Andrej Karpathy Anfang 2025 für das lockere Prompten einer KI bekannt machte, die ungeprüfte Ergebnisse ausliefert. Dieselbe Definition lehnt „Wasserfall mit Markdown“ ausdrücklich ab, weil die Spec lebendig und versioniert bleiben soll, statt zu Beginn einer langen Phase eingefroren zu werden, wie dieser SDD-Überblick von 2026 festhält.
Die Solo-Version ist anders
Hier ist der Teil, den die meisten Ratschläge übersehen. Du brauchst kein SDD in Teamgröße, wenn du kein Team hast.
Du brauchst eine minimale Spec, die sich wie der Senior Engineer verhält, den du nicht einstellen kannst. Sie soll fehlende Constraints aufdecken, festlegen, was außerhalb des Scopes liegt, und deiner KI genug Struktur geben, damit sie aufhört, auf eigene Faust Architektur zu erfinden. Das ist der ganze Job.
Wer allein baut, läuft in öffentlichen Threads immer wieder gegen dieselbe Wand. In den Reddit-Diskussionen über gescheitertes Vibe Coding, Guardrails und solotaugliche „Get stuff done“-Spec-Muster ist das Muster offensichtlich. Reines Prompten fühlt sich schnell an – bis zur zweiten oder dritten Änderungsanfrage. Dann wird das Repo zu einem Haufen zufälliger Entscheidungen. Du kannst das wieder geradebiegen, aber das kostet mehr, als eine kurze Spec gekostet hätte.
Der richtige Schritt ist nicht „kein Prozess“. Es ist Disziplin mit wenig Zeremonie.
Eine gute Solo-Spec leistet vier Dinge:
- Das Problem klar benennen. Nicht das Feature. Das Problem.
- Grenzen ziehen. Deine KI braucht einen Zaun.
- Akzeptanzkriterien festhalten. Die geben dir später einen Maßstab fürs Review.
- Kurz genug bleiben, um sie neu zu schreiben. Wenn du sie nicht überarbeiten wirst, ist sie schon tot.
Deshalb rate ich Solo Buildern von PRD-lastigen Frameworks ab. Die Enterprise-Form von SDD ist oft eine Falle. Die Solo-Form kann messerscharf sein.
Die solotaugliche Spec nach Addy Osmanis Format
Addy Osmanis Format ist der beste Standard, den ich für Solo-Arbeit kenne, weil es nicht so tut, als müsse dein Dokument fünf Stakeholder zufriedenstellen. Es muss eine Person zufriedenstellen, die baut, und einen Coding-Agent.
Warum dieses Format funktioniert, wenn du allein bist
Das kanonische Spec-Format mit sechs Abschnitten, das Addy Osmani zugeschrieben und vom Thoughtworks Tech Radar zitiert wird, sagt: Specs sollen eine Constitution mit projektweiten Regeln enthalten und den Negativraum definieren, also das, was außerhalb des Scopes liegt, um Drift zu verhindern. Außerdem sollen Specs kurz bleiben, etwa 1 bis 3 Seiten, und aufgeteilt werden, wenn sie größer werden, wie diese Besprechung des Formats zusammenfasst.
Diese Größengrenze ist wichtiger, als viele zugeben. Sobald deine Solo-Spec aufgebläht ist, hörst du auf, sie zu benutzen. Dann hört die KI auf, ihr zu folgen. Dann driftest du.
Wenn du diese Notizen auf einfache Weise in einem System führen willst, das du schon nutzt, ist SystemSculpts Obsidian-Template für Projekt-Specs ein ordentlicher Ausgangspunkt, weil es die Spec als Arbeitsdokument behandelt statt als formales Relikt.
Die sechs Teile, auf die es ankommt
Ich nutze eine abgespeckte Auslegung des Formats. Dasselbe Rückgrat. Weniger Theater.
| Abschnitt | Was er für Solo-Devs leistet |
|---|---|
| Projektüberblick | Benennt das Feature in einfachen Worten |
| Problemstellung | Zwingt dich zu sagen, warum es das gibt |
| User Stories | Bindet die Arbeit an echtes Verhalten |
| Komponenten | Begrenzt, welche Teile des Systems sich ändern dürfen |
| API oder Interaktionen | Klärt Berührungspunkte und Datenfluss |
| Edge Cases | Verhindert, dass die KI nur den Happy Path baut |
Ein paar Hinweise sind wichtiger als die Bezeichnungen.
Der Negativraum hält dich aus dem Kaninchenbau raus
Out-of-Scope gehört in jede Solo-Spec. Nicht weil ein PM danach gefragt hat. Sondern weil du ganz sicher in Versuchung gerätst, „nur noch eine Sache“ dazuzunehmen, sobald die KI Tempo aufnimmt.
Schreib auf, was du nicht baust. Sag es deutlich.
- Fass die Auth nicht an, wenn es in diesem Task um Onboarding-Texte geht.
- Bau keine Datenmodelle um, wenn du einen einzelnen Reporting-Flow reparierst.
- Rühr keine Mobile-Layouts an, wenn diese Spec nur Desktop betrifft.
Dieser eine Abschnitt spart Stunden.
Akzeptanzkriterien machen die Spec zum Reviewer
Dein künftiges Ich braucht eine testbare Ziellinie. Ohne sie reviewst du nach Gefühl. So rutschen Bugs durch, und der Scope wächst unkontrolliert.
Eine kurze Spec schlägt einen klugen Prompt. Der Prompt verschwindet. Die Spec bleibt und gibt dir etwas, das du prüfen kannst.
Gute Akzeptanzkriterien sind absichtlich langweilig. Sie beschreiben sichtbare Ergebnisse und Constraints. Sie enthalten keine Fan-Fiction über die Implementierung.
Ein Template zum Kopieren
Nimm das hier. Füll es zügig aus. Wenn das länger als eine fokussierte Session dauert, denkst du über das Feature wahrscheinlich zu viel nach.
# [Feature name]
## Project overview
One paragraph on what this feature is.
## Problem statement
What problem are you solving?
Who has it?
What breaks today?
## User stories
- As a [user], I want [capability], so that [outcome].
- As a [user], I want [capability], so that [outcome].
## Components
Files, modules, routes, services, or UI areas allowed to change:
-
-
-
Project rules:
- Follow existing patterns in the repo
- Prefer modifying existing code over adding new abstractions
- Keep naming consistent with current modules
## API or interactions
Inputs:
Outputs:
Events:
External dependencies:
Data contracts affected:
## Edge cases
- Empty state
- Error state
- Retry behavior
- Permission or auth constraints
- Loading and timeout behavior
## Out of scope
-
-
-
## Acceptance criteria
- [ ]
- [ ]
- [ ]
## Assumptions
-
-
## Validation
- Manual checks:
- Tests to update or add:
- Rollback plan:
Mehr braucht SDD für Solo Developer nicht. Du brauchst kein zeremonielles PRD. Du brauchst ein scharfes Dokument, das dumme Fehler verhindert.
Dein Workflow vom Problem zur KI-tauglichen Spec
Die meisten Solo Builder fangen zu spät an. Sie beginnen bei „bau das Feature“ statt bei „benenne das Problem“. Deshalb fühlt sich der erste Entwurf, den die KI zurückgibt, produktiv an, ist aber falsch.
Fang beim Schmerz an, nicht bei Features
Ein schwacher Ausgangspunkt klingt so:
- „Onboarding verbessern“
- „Suche besser machen“
- „Dashboard-UX aufräumen“
Das ist kein Keim für eine Spec. Das ist vage Unzufriedenheit.
Ein besserer Ausgangspunkt klingt so:
- Wer sich gerade registriert hat, weiß nicht, was als Erstes zu tun ist
- Die Suche liefert bei exakten Namensanfragen zu viele irrelevante Datensätze
- Das Dashboard versteckt fehlgeschlagene Syncs, bis Support-Tickets auftauchen
Das reicht für den Anfang.
Schreib dann drei kurze Notizen, bevor du deinen Editor öffnest:
- Was gerade kaputt ist
- Wer es spürt
- Wie „fertig“ aussieht
Diese kurze Übung streicht eine Menge Scheinkomplexität. Wenn das Problem danach immer noch unscharf ist, bist du noch nicht so weit, eine KI daran coden zu lassen.
Verankere die Spec in der Codebase
Wer allein baut, kürzt meistens ab. Man schreibt eine ordentliche Feature-Beschreibung und gibt sie Cursor oder Claude Code, ohne zu sagen, wie sich das aktuelle Repo verhält.
Schlechte Idee.
Deine Spec muss auf die Realität der Codebase zeigen:
- Relevante Dateien und Ordner
- Bestehende Muster, die nachgeahmt werden sollen
- Constraints, die du auf keinen Fall brichst
- Tests, die angrenzendes Verhalten schon abdecken
Wenn du nicht weißt, wie du die Verhaltensseite formulieren sollst, können Prompt-Sammlungen für Produkt und UX helfen, die Sprache zu schärfen. Ich stöbere gern in Ressourcen wie diesen fortgeschrittenen KI-Design-Prompts, um Beispiele für klarere Problemformulierungen zu sehen – nicht um blind zu kopieren, sondern um unfertige Gedanken zu straffen.
Es gibt ein paar Wege zu einer Spec, die beim ersten Versuch sitzt:
| Ansatz | Wann es funktioniert | Wo es bricht |
|---|---|---|
| Markdown von Hand in deinem Repo | Am besten, wenn du die Codebase im Schlaf kennst | Versteckte Abhängigkeiten übersieht man leicht |
| Notiz-App plus Grep im Repo | Reicht für kleine Features | Der Kontext verstreut sich |
| Spec-Tools, die das Repo kennen | Gut für Brownfield-Codebases | Urteilsvermögen brauchst du trotzdem |
Eine Option ist Tekk.coach. Seine Loops lesen dein GitHub-Repo und schreiben Specs für dich aus dem, was sich in deinem Code geändert hat, und du kannst auch selbst eine Spec von Hand auf dasselbe Board schreiben. Cursor, Claude Code oder Codex holt sich die Spec über den Tekk-MCP-Server und baut sie. Tekk schreibt den Code nie selbst. Wenn du einen breiteren Blick auf das Design von Agent-Flows willst, hilft dieser Leitfaden zu AI-Agent-Workflows.
Mach einen KI-Preflight, bevor du übergibst
Bevor du irgendetwas in einen Agent einfügst, mach einen Preflight-Check. Ich nutze fünf Fragen.
- Lässt sich das in einer Build-Session erledigen? Wenn nicht, teil es auf.
- Sagt die Spec, was nicht angefasst wird? Wenn nicht, ergänz Out-of-Scope.
- Sind die Akzeptanzkriterien testbar? Wenn nicht, schreib sie neu.
- Hast du die beteiligten Dateien oder Module benannt? Wenn nicht, hol das jetzt nach.
- Würde jemand Fremdes das Feature ohne Slack-Kontext verstehen? Wenn nicht, versteht es deine KI auch nicht.
Realitätscheck: Eine KI-taugliche Spec ist kein poliertes Artefakt. Sie ist ein ausreichend klares Artefakt.
Dieser Maßstab ist wichtig. Solo Founder verlieren Tage damit, ein Planungsdokument zu polieren, das eine Stunde hätte dauern sollen.
Die Übergabe: Specs an KI-Coding-Agents geben
Eine Spec ist keine Magie. Du musst sie dem Modell trotzdem richtig übergeben.
Deine Spec ist auch dein Prompt
Das muss man ausdrücklich sagen, weil es immer wieder verwässert wird. Du gibst die Spec von Hand an Cursor, Claude Code, Codex oder Gemini. Das ist die Übergabe. Keine geheimnisvolle Zwischenschicht.
Verschiedene Agents verhalten sich unterschiedlich, aber das Prinzip bleibt gleich. Gib ihnen die Spec, den erlaubten Scope, die relevanten Dateien und deine Erwartungen ans Review. Wenn du Tools für den breiteren Einsatz im Startup vergleichst, helfen Listen wie diese Übersicht über AI Agents für Startups bei der Orientierung.
Viele neuere Workflows scheitern genau hier, weil sie die Spec als Hintergrunddokument behandeln statt als zentrale Anweisung. Das ist verkehrt herum. Die Spec sollte der Kern-Prompt sein. Der Chat drumherum sollte minimal bleiben.
Wenn du Beispiele dafür willst, wie das in einen größeren Stack passt, bildet diese Seite über Spec-driven Development mit deinem Coding-Agent-Stack die Übergabemuster gut ab.
Übergabe-Prompts zum Kopieren
Nimm diese als Ausgangspunkt.
Cursor
Am besten, wenn du direkt auf Dateien zeigen kannst.
Use the attached spec as the source of truth for this task.
Rules:
- Stay inside the listed components and files
- Do not expand scope beyond the spec
- If acceptance criteria conflict with current code, flag it before changing architecture
- Prefer existing patterns over new abstractions
Task:
Implement the feature exactly as written. Then list:
1. files changed
2. open questions
3. which acceptance criteria are satisfied
4. what still needs manual verification
In Cursor wähle ich gern die zugehörigen Dateien aus und nutze dann den Command-Flow mit eingefügter Spec. So bleibt der Kontext eng.
Claude Code
Am besten, wenn du stärkeres Reasoning und eine sauberere Review-Zusammenfassung willst.
Treat this spec as binding unless you find a clear conflict in the existing codebase.
First:
- inspect the relevant files
- summarize the implementation plan in 5 bullets
- ask questions only if a blocked decision exists
Then:
- implement in small, reviewable changes
- do not touch unrelated code
- map your final output to the acceptance criteria
Claude Code schneidet meist besser ab, wenn du zuerst um einen kurzen Plan bittest. So fallen Missverständnisse früh auf.
Ein kurzes visuelles Beispiel hilft hier.
Codex oder Gemini
Halte diese knapper. Zu viel Prosa kann zu Umwegen führen.
Implement this spec within existing repo patterns.
Constraints:
- no new frameworks
- no unrelated refactors
- preserve existing APIs unless the spec says otherwise
Return:
- implementation summary
- changed files
- acceptance criteria checklist
- risks or follow-up items
Wie gute Umsetzung aussieht
Du willst, dass sich der Agent verhält wie eine sorgfältige Fachkraft auf Mid-Level, die ein gutes Tech-Lead-Dokument vor sich hat.
Deshalb enthalten die besten Übergaben meistens:
- Eine Spec-Datei mit Scope, Out-of-Scope und Akzeptanzkriterien
- Eine Dateiliste der wahrscheinlich betroffenen Bereiche
- Die klare Anweisung, Refactorings zu vermeiden
- Eine Pflicht, jede Änderung den Akzeptanzkriterien zuzuordnen
Wenn das Modell anfängt, deine App neu zu designen, war deine Spec nicht scharf genug, oder dein Übergabe-Prompt hat ihm zu viel Freiheit gelassen.
Der Loop: Self-Review und nächtliche Audits
Die meisten Solo Builder hören bei „die KI hat Code geschrieben“ auf. Das ist zu früh, um sich fertig zu fühlen.
Prüf gegen die Spec, nicht nach Gefühl
Deine Spec sollte zum Maßstab fürs Review werden. Genau dafür schreibst du sie überhaupt.
Öffne die Spec und prüf die Akzeptanzkriterien eins nach dem anderen. Nicht „Sieht das gut aus?“. Nicht „Klang das Modell selbstsicher?“. Nur die Checkliste.
Ich mache einen schonungslosen Review-Durchgang:
- Verhaltens-Check. Tut das Feature, was die Spec sagt?
- Grenz-Check. Hat die KI etwas außerhalb des Scopes angefasst?
- Fehler-Check. Sind die Edge Cases abgedeckt?
- Code-Fit-Check. Passt es zu den bestehenden Mustern im Repo?
Dieser Review-Stil ist weniger glamourös als Coden nach Vibe, aber er bewahrt dich vor dem Loop des Schein-Tempos, in dem jeder „schnelle Erfolg“ künftige Reparaturarbeit erzeugt.
Was bei Solo-Entwicklung fehlt, ist nicht noch jemand, der codet. Es ist jemand, der mit Maßstäben reviewt. Deine Spec kann den Großteil dieses Jobs übernehmen, wenn du sie am Ende auch wirklich benutzt.
Nutze einen winzigen Audit-Loop
Du brauchst außerdem eine Art asynchronen Review-Rhythmus, besonders wenn du müde bist. Wer müde ist, winkt ständig schlechten Code durch.
Ein nützliches Muster ist ein nächtlicher Audit-Loop. Ein Durchgang, der fragt: Was driftet, was ist riskant, und welches eine Problem verdient morgen Aufmerksamkeit?
Das kann manuell laufen. Es kann auch toolgestützt sein. Bei Tekk übernehmen das die Loops. Jeder wacht auf, wenn sich dein Code ändert oder ein Teil seines Bereichs zu lange ungeprüft geblieben ist, und bringt höchstens ein Proposal. Du gibst es mit Greenlight frei oder lehnst es mit einer Begründung ab. Das ist eine enge Beschränkung, und eine gute. Sie verhindert eine Flut verrauschter Ratschläge.
Die Grundidee ist wichtiger als das Tool. Du willst eine wiederkehrende Prüfung, die die Richtung des Repos mit der Richtung vergleicht, die du vorhast.
Warum das zum Micro-Launch-Modell passt
Dieser Review-Loop funktioniert besonders gut, wenn du klein baust und oft auslieferst.
Für Solo-Devs, die SDD mit einem Micro-Launch-Ansatz verbinden, ist das stärkste Muster, 1 bis 4 kleine Projekte anzulegen, die innerhalb von 1 bis 3 Monaten starten können, den Market Fit hart zu validieren und Ideen zu beerdigen, die nicht zünden. Ein erfolgreiches Projekt kann 500 $ im Monat erreichen, so die Diskussion in diesem HN-Thread über Micro-Launches.
Dieses Modell passt zu SDD im Alleingang, weil es Zurückhaltung erzwingt. Du brauchst kein großes Framework. Du brauchst Specs, die kurz genug für schnelle Validierung sind, schnell neu geschrieben und klar genug, um sie nach jedem Release zu reviewen.
Wenn eine Idee nicht zündet, beerdige sie. Bau nicht noch mehr Architektur drumherum.
Typische Fallstricke und wie du sie vermeidest
Die üblichen Fehlschläge bei SDD für Solo Developer beweisen nicht, dass die Methode kaputt ist. Meist heißen sie, dass du in Gewohnheiten zurückgefallen bist, die für Teams gemacht sind.
Drift heißt: Deine Spec ist zu vage
Wenn die Implementierung immer wieder abschweift, gib nicht zuerst dem Modell die Schuld. Prüf die Spec.
Spec Drift entsteht meist aus einem von drei Fehlern:
- Der Scope ist matschig. Du hast nicht festgehalten, was unberührt bleibt.
- Die Akzeptanzkriterien sind abstrakt. „Fühlt sich flüssiger an“ lässt sich nicht reviewen.
- Komponenten sind nicht benannt. Die KI hat geraten, wo sie arbeiten soll.
Die Kurskorrektur ist einfach. Schreib die Spec kleiner neu. Ergänz den Negativraum. Schärf die Kriterien.
Perfektionismus ist der eigentliche Prozess-Bug
Das größere Risiko für Solo Builder ist nicht zu wenig Planung. Es ist zu viel Politur.
Laut Smashing Magazines Artikel über Solo-Entwicklung und Perfektionismus scheitern 70 % der Solo Developer innerhalb von 12 Monaten an Feature Creep und Perfektionismus, und besser zur Solo-Arbeit passt ein flexibles, iteratives Notizsystem statt eines formalen GDD.
Das deckt sich mit dem, was tatsächlich ausgeliefert wird. Deine Spec sollte sich lebendig anfühlen, billig zu ändern sein und notfalls wegwerfbar. Wenn sie sich heilig anfühlt, hast du schon Tempo verloren.
Eine einfache Regel hilft:
| Fallstrick | Kurskorrektur |
|---|---|
| Die Spec wächst immer weiter | Teil das Feature in eine kleinere Spec auf |
| Die KI halluziniert Architektur | Zieh engere Dateigrenzen und ergänz Out-of-Scope |
| Du schreibst ständig Doku neu | Bau das kleinste ausführbare Stück |
| Das Review fühlt sich unscharf an | Formulier die Akzeptanzkriterien als sichtbare Ergebnisse neu |
Verwechsle Framework-Komplexität nicht mit Gründlichkeit
GitHub Spec Kit kann nützlich sein. Kiro kann nützlich sein. OpenSpec, BMAD und der Rest haben alle ihre Stärken. Aber Solo Builder kopieren oft zuerst die schwersten Teile und zuletzt die nützlichen.
Gründlichkeit ist nicht die Zahl der Artefakte. Gründlichkeit heißt, dass deine Spec Drift verhindert und das Review trägt.
Wenn sich dein Prozess wie eine Token verbrennende Zeremonie anfühlt, speck ihn ab. Behalte die Spec mit sechs Abschnitten. Behalte die Disziplin bei der Übergabe. Behalte den Self-Review-Loop. Wirf den Rest raus.
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 mit dem Merge des PRs, der sie baut.
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.