RFCs und Design Docs helfen dir bei der Entscheidung, ob wir das überhaupt bauen sollten, während SDD-Specs einem AI Agent sagen, wie er es bauen soll. Gut eingesetzt haben klassische, an Specs ausgerichtete Prozesse die Code-Review-Zyklen schätzungsweise um 30 bis 40 Prozent verkürzt, und Teams berichten von 25 Prozent weniger Bugs nach dem Deployment, wenn sie die Spec-Phase nicht überspringen.
Die meisten Ratschläge zum Thema SDD vs. RFC/Design-Doc-Prozess führen die Debatte falsch. Sie behandeln beides wie konkurrierende Religionen. Das sind sie nicht. Sie gehören an unterschiedliche Entscheidungspunkte.
Deine Skepsis ist trotzdem berechtigt. Ein großer Teil des Gegenwinds aus 2025 und 2026 ist verdient. „Wasserfall mit Markdown.“ „Produktivitätsfalle.“ „Spec Drift.“ „Eingefrorene Specs.“ „Token verbrennende Zeremonie.“ Alles echte Fehlermuster. Wenn du ein Dokument schreibst, weil dir irgendeine Prozesspolizei das vorschreibt, verschwendest du Zeit. Wenn das Dokument eine Entscheidung verbessert oder die Umsetzung schärfer macht, behalte es. Wenn nicht, wirf es weg.
Das ist der Rahmen, der zählt, wenn du als Solo Founder Cursor, Claude Code, Codex oder Gemini in einer echten Codebase einsetzt. Dokumente zur Abstimmung unter Menschen und Specs für die Ausführung durch KI sind nicht dasselbe Artefakt. Wer sie als dasselbe behandelt, dokumentiert winzige Aufgaben zu ausführlich oder beschreibt die schwierigen zu dünn.
Inhalt
- Hör auf zu debattieren und fang an zu bauen
- RFC und Design Doc klassisch erklärt
- Die moderne SDD-Spec für AI Agents
- Die wichtigsten Unterschiede zwischen SDD und RFC
- Wann du was einsetzt und wie beides zusammenhängt
- Ein schlanker Prozess für dich und deinen AI Agent
- So führst du diesen Prozess noch heute ein
Hör auf zu debattieren und fang an zu bauen
Der Streit SDD vs. RFC ist größtenteils ein Scheinstreit. Du hast kein Tooling-Problem. Du hast ein Entscheidungsproblem.
Wenn du dich fragst, ob du einen RFC oder eine SDD nutzen sollst, fang hiermit an: Was willst du verringern? Strategisches Risiko oder Unklarheit bei der Umsetzung? RFCs gibt es, um eine Entscheidung auf die Probe zu stellen, bevor Code entsteht. SDDs gibt es, um die Umsetzung so präzise zu machen, dass ein AI Agent nicht wie eine verwirrte Praktikumskraft durch dein Repo irrt.
Der meiste Gegenwind zielt auf das Falsche
Das Anti-Spec-Lager liegt nicht völlig falsch. Ein schlechter Prozess wird schnell zur Zeremonie.
Das geht typischerweise schief:
- Wasserfall mit Markdown. Du schreibst ein riesiges Dokument, frierst es zu früh ein und tust dann so, als würde sich die Realität nicht ändern.
- Produktivitätsfalle. Du polierst Prosa, statt Code zu schreiben.
- Spec Drift. Das Dokument passt nach dem ersten echten Kompromiss in der Umsetzung nicht mehr zum Repo.
- Token verbrennende Zeremonie. Leute schreiben Dokumente, um seriös zu wirken, nicht, um bessere Ergebnisse zu erzielen.
Die scharfe Kritik lautet: Viele Teams bewerten die Qualität des Dokuments, nicht die Qualität der Entscheidung. Diese Lücke benennt dieser Beitrag über Ziele und Fehlermuster von RFCs und technischen Design-Dokumenten direkt. Das ist die richtige Beschwerde. Ein poliertes Dokument, das den Build nicht verbessert hat, war trotzdem Verschwendung.
Praxisregel: Wenn das Dokument weder Nacharbeit verringert noch Trade-offs geklärt oder den Prompt verbessert hat, den du deinem Coding-Agent gibst, war es Overhead.
Die nützliche Trennung
Für dich als Solo Builder ist die Trennung einfach.
Ein RFC beantwortet Fragen wie diese:
- Löst du das richtige Problem?
- Ist die Architekturänderung ihren Wirkungsradius wert?
- Welche Alternativen hast du verworfen, und warum?
- Wo kann das schiefgehen?
Eine SDD beantwortet andere:
- Welche Dateien ändern sich?
- Wie sieht „fertig“ aus?
- Welche Edge Cases muss die Umsetzung abdecken?
- Wie prüfst du, ob der Code der Absicht entspricht?
Diese Unterscheidung zählt auch außerhalb von Software. Wenn du ein Geschäftsmodell, einen Finanzierungsweg oder eine Launch-Strategie wählst, trennst du die Entscheidung ebenfalls vom Umsetzungsplan. Deshalb sind Ressourcen für Founder wie die besten Finanzierungsplattformen für Creator nützlich. Entscheide zuerst, welcher Weg sinnvoll ist. Leg dann die genauen Schritte fest.
Wenn du diese Trennung bei Software überspringst, bekommst du eines von zwei schlechten Ergebnissen. Entweder denkst du ewig nach und lieferst nichts aus, oder du lieferst schnell ins falsche Design.
RFC und Design Doc klassisch erklärt
Klassische RFCs und Design Docs sind aus einem Koordinationsproblem zwischen Menschen entstanden. Nicht aus einem Prompting-Problem mit KI.
Google ist das deutlichste Beispiel. Design Docs wurden Anfang der 2000er zu einem Grundpfeiler der Engineering-Kultur, mit einem typischen Optimum von 10 bis 20 Seiten bei größeren Projekten, damit vielbeschäftigte Engineers sie noch lesen konnten. Größere Änderungen brauchen ein Dokument, das Trade-offs und Alternativen ausbuchstabiert, und der Prozess gilt in Googles Design-Doc-Kultur als Kernkompetenz von Senior Engineers.
Wofür diese Dokumente gedacht waren
Ein klassischer RFC heißt nicht einfach „schreib deine Idee auf“. Er soll teure Verwirrung verhindern, bevor die Umsetzung beginnt.
Bei Google ist der Lebenszyklus ausgereift und klar festgelegt:
- Erstellung und schnelle Iteration
- Review in mehreren Runden
- Umsetzung mit Iteration
- Pflege mit Lerneffekt
Dieser Prozess zählt, weil es nicht um Dokumentation fürs Archiv geht. Es geht darum, falsche Annahmen früh zu erwischen, Konsens in der Organisation herzustellen und erfahrenes Urteilsvermögen über den Kopf einer einzelnen Person hinaus zu verbreiten.
Stripe folgt einem ähnlichen Instinkt. Der RFC zwingt zu klarem Denken, bevor irgendwer anfängt zu coden. Wenn du diesen Muskel nie trainiert hast, hilft es, die Grundlagen des Softwaredesigns zu lernen, bevor du „Strategiedokumente“ schreibst, die in Wahrheit nur ausufernde Notizen sind.
Was in ein echtes Design Doc gehört
Ein gutes klassisches Design Doc macht ein paar Dinge richtig:
- Es benennt das Problem klar. Kein vages „das System verbessern“.
- Es erklärt Alternativen. Keine Schein-Alternativen. Echte Optionen, für die du dich hättest entscheiden können.
- Es dokumentiert Trade-offs. Performance, Zuverlässigkeit, Sicherheit, Skalierbarkeit, Kosten fürs Team.
- Es lädt vor der Umsetzung zum Review ein. Genau darum geht es.
Wenn du einen konkreten Startpunkt willst, nimm ein Template für ein Software-Design-Dokument und kürz es auf das, was dein Projekt braucht.
Die besten RFCs sparen Coding-Zeit, indem sie den falschen Build verhindern, nicht, indem sie im Review beeindruckend klingen.
Die Lehre für dich als Solo Founder lautet nicht „kopier Google“. Sie lautet „übernimm den Teil, der teure Fehler abfängt“.
Die moderne SDD-Spec für AI Agents
Eine SDD-Spec will nicht die Zustimmung im Team gewinnen. Sie will Unklarheit für eine Maschine verringern.
Das ändert alles. Das Publikum sind jetzt Cursor, Claude Code, Codex oder Gemini bei der Arbeit in einer echten Codebase. Also darf das Dokument nicht auf der Ebene der „Architekturerzählung“ stehen bleiben. Es braucht operative Details.
Was eine SDD anders macht
Eine nützliche SDD ist eher ein Ausführungspaket als ein Positionspapier.
Sie sollte dem Agent sagen:
- Was das Ziel ist
- Was außerhalb des Scopes liegt
- Welche Teile des Repos wichtig sind
- Welche Randbedingungen nicht verletzt werden dürfen
- Wie der Erfolg geprüft wird
Das liegt näher an spec-anchored Arbeit als an der klassischen, vom Review getriebenen RFC-Kultur. Die Stärke ist nicht die Diskussion. Die Stärke ist, dass später weniger Diskussion nötig ist.
Die öffentlichen Engineering-Texte von Stripe sind hier trotzdem nützlich, weil sie zeigen, was es bringt, Ziele, Architektur und Alternativen vorab zu klären. In Unternehmen mit dieser Art von Spec-Prozess verkürzten sich die Code-Review-Zyklen mit Stripes RFC-Ansatz schätzungsweise um 30 bis 40 Prozent.
Was ich in jede KI-taugliche Spec packen würde
Schreib keinen Aufsatz. Schreib Anweisungen mit genug Kontext, um die Umsetzung zu überstehen.
Eine solide Minimalstruktur sieht so aus:
- Ziel in klarer Sprache. Ein Absatz. Kein Fachjargon als Füllmaterial.
- Kontext aus dem Repo. Nenn die Module, Services oder Dateien, die wahrscheinlich betroffen sind.
- Randbedingungen. Performance, Sicherheit, sichere Migrationen, Abwärtskompatibilität.
- Akzeptanzkriterien. Was wahr sein muss, wenn die Arbeit erledigt ist.
- Validierungsszenarien. Die Checks, Testpfade und Fehlerfälle, auf die es ankommt.
Wenn du ein schlankes Format für genau diese Art von Arbeit willst, nimm dieses minimale Spec-Format.
Ein vager RFC kann trotzdem ein gutes Gespräch im Team anstoßen. Eine vage SDD ist für einen AI Agent nahezu nutzlos.
Das ist der ganze Wandel. In der Debatte SDD vs. RFC/Design-Doc-Prozess ist die SDD die Ausführungsebene.
Die wichtigsten Unterschiede zwischen SDD und RFC
Beides ist „Doku vor Code“. Damit enden die Gemeinsamkeiten auch schon weitgehend.
Hier ist die Gegenüberstellung, die zählt, wenn du allein auslieferst.
RFC und SDD im Vergleich
| Eigenschaft | RFC / Design Doc | SDD-Spec |
|---|---|---|
| Hauptaufgabe | Entscheiden, ob sich der Ansatz lohnt | Einem AI Agent genau sagen, wie er umsetzen soll |
| Hauptpublikum | Menschen: wer reviewt, Stakeholder | KI-Coding-Agent, danach du im Review |
| Bester Zeitpunkt | Vor der Umsetzung nicht-trivialer Änderungen | Wenn die Richtung feststeht, vor dem Coden |
| Scope | Strategisch, architektonisch, übergreifend | Taktisch, auf Aufgabenebene, in der Codebase verankert |
| Kerninhalt | Kontext, Trade-offs, Alternativen, Ansatz im Überblick | Dateien, Schritte, Randbedingungen, Akzeptanzkriterien, Validierung |
| Art des Reviews | Debatte, Feedback, Abstimmung | Klären, Anweisungen schärfen, Unklarheit beseitigen |
| Typisches Fehlermuster | Analyse-Paralyse | Zu vage Vorgaben |
| Erfolgssignal | Bessere Entscheidungen | Bessere Umsetzung im ersten Anlauf |
| Verhältnis zu ADRs | Vor der Entscheidung oder entscheidungsbildend | Vor der Ausführung |
| Ideale Länge | Hängt von Risiko und Komplexität ab | So kurz wie möglich, aber trotzdem präzise |
Warum beides verwechselt wird
RFCs und SDDs werden verwechselt, weil beide auftauchen, bevor der Code landet. Aber sie beantworten unterschiedliche Fragen.
RFCs und Design Docs setzt du am besten vor der Umsetzung nicht-trivialer Änderungen mit Abhängigkeiten ein, weil sie Kontext, den vorgeschlagenen Ansatz und Trade-offs teilen und zu Feedback auf höherer Ebene einladen. Sie sind nicht dasselbe wie ADRs, die enger gefasst sind und eine Entscheidung festhalten, nachdem sie gefallen ist, so diese Erklärung zu Engineering-Entscheidungen, RFCs und ADRs.
Die Fehlermuster sind verschieden
Ein aufgeblähter RFC scheitert auf die eine Art. Eine schwache SDD auf eine andere.
So sieht das Scheitern eines RFC aus:
- Du dokumentierst jeden Sonderfall, bevor du entschieden hast, ob sich das Projekt überhaupt lohnt.
- Du verlangst einen Schein-„Konsens“, obwohl sonst niemand wirklich mitreden muss.
- Du verwechselst Gründlichkeit mit gutem Urteilsvermögen.
So sieht das Scheitern einer SDD aus:
- Du lässt den Repo-Kontext weg, also bearbeitet der Agent die falsche Schicht.
- Du überspringst die Akzeptanzkriterien, also wird „fertig“ subjektiv.
- Du lässt Edge Cases unausgesprochen, also bricht die Umsetzung beim ersten seltsamen Eingabepfad.
Meine unverblümte Empfehlung
Nimm einen RFC, wenn du eine Entscheidung schärfen musst. Nimm eine SDD, wenn die Entscheidung schon gefallen ist und jetzt die Qualität der Umsetzung der Engpass ist.
Wenn du einen RFC als Anweisungssatz für die KI nutzen willst, ist er zu vage. Wenn du mit einer SDD über Strategie entscheidest, zieht sie dich in verfrühte Details.
Wann du was einsetzt und wie beides zusammenhängt
Für die meisten Solo Founder lautet die Antwort nicht „nimm eins von beiden“. Sie lautet: „Nutze weniger Prozess, aber den richtigen Prozess im richtigen Moment.“
Fang mit dieser Aufteilung an:
Nimm einen RFC, wenn die Entscheidung selbst riskant ist
Du brauchst wahrscheinlich irgendeine Form von RFC, wenn du Dinge wie diese tust:
- Die Architektur ändern. Neue Datenbank, neues Auth-Modell, neues Job-System, neues Mandantenmodell.
- Eine schwer umkehrbare Entscheidung treffen. Vendor-Lock-in, Richtung des Schemas, Billing-Design.
- Einen großen Wirkungsradius berühren. Die Änderung betrifft mehrere Abläufe oder wichtige Randbedingungen.
- Unschöne Trade-offs durcharbeiten. Zuverlässigkeit gegen Tempo, Einfachheit gegen Flexibilität.
Bei dieser Art von Arbeit macht sich ein kurzes schriftliches Entscheidungsprotokoll vor dem Coden bezahlt. Das historische Muster ist eindeutig. Teams mit RFCs und Design Docs berichten von 25 Prozent weniger Bugs nach dem Deployment als Teams, die die Spec-Phase überspringen, und größere Projekte brauchen in Spec-basierten Workflows üblicherweise rund 2 bis 4 Wochen für Erstellung, Review und Umsetzung.
Nimm eine SDD für den Großteil der Umsetzungsarbeit
Die meiste Arbeit braucht kein Gremientheater. Sie braucht saubere Anweisungen.
Dazu gehören:
- Feature-Umsetzung
- Bugfixes mit Edge Cases
- Refactorings innerhalb bekannter Grenzen
- API-Endpunkte und UI-Abläufe
- Integrationsaufgaben, bei denen die Architektur schon feststeht
Sieh dir das hier an, wenn du eine weitere Perspektive auf Spec-basierte KI-Entwicklung in der Praxis willst:
Das saubere Schichtenmodell
Am einfachsten denkst du so darüber nach:
RFC-Denkprozess
Entscheiden, ob der Ansatz gut ist.SDD-Spec
Diese Entscheidung in ausführbare Anweisungen übersetzen.Code Review
Prüfen, ob die Umsetzung zur Spec und zur Realität des Repos passt.
Wenn die Architekturentscheidung offensichtlich ist, lass den formellen RFC weg und schreib eine winzige Entscheidungsnotiz. Dann geh direkt zur SDD über.
Genau dieser Teil geht in der Diskussion SDD vs. RFC/Design-Doc-Prozess oft unter. RFCs speisen SDDs. Sie sind keine konkurrierenden Formen. Das eine grenzt die Entscheidung ein. Das andere schärft den Build.
Ein schlanker Prozess für dich und deinen AI Agent
Die meisten Ratschläge zu Design Docs setzen eine voll besetzte Engineering-Organisation voraus. Das ist nicht dein Setup. Du hast dich selbst, ein Repo und einen AI Agent, der schnell ist, aber nicht vertrauenswürdig genug, um Architektur zu improvisieren.
Deshalb brauchst du einen abgespeckten Prozess.
Der Mini-RFC in fünf Zeilen
Bevor du Cursor oder Claude Code öffnest, schreib fünf Zeilen:
- Problem
- Ziel
- Vorgeschlagener Ansatz
- Hauptrisiko
- Verworfene Alternative
Das reicht, damit du dich nicht in eine Sackgasse codest. Mehr brauchst du nicht, es sei denn, der Wirkungsradius ist groß.
Die meisten Inhalte zu Design Docs drehen sich immer noch um die Koordination zwischen mehreren Personen. Es gibt viel weniger praktische Anleitung für Solo Founder, die schlanke Specs mit Bezug zum Repo brauchen und trotzdem die Verantwortung für Architektur und Sicherheit tragen. Diese Lücke ist real, wie weiter oben im Artikel besprochen.
Mach daraus eine Ausführungs-Spec
Erweitere den Mini-RFC jetzt zu einer SDD, mit der dein AI Agent arbeiten kann.
Nutze diese Checkliste:
- IST-Zustand. Was gibt es heute? Welches Verhalten oder welche Struktur änderst du?
- Gewählte Logik. Welchen Weg genau soll die Umsetzung nehmen?
- Alternativen. Lass den verworfenen Weg sichtbar, wenn der Agent dazu neigen könnte, dorthin abzudriften.
- Aufteilung in Aufgaben. Zerleg die Arbeit in einzelne, abgegrenzte Umsetzungsschritte.
- Akzeptanzkriterien. Mach „fertig“ in klarer Sprache testbar.
- Validierungsszenarien. Nimm Edge Cases und Fehlerpfade auf.
Wenn du eine praktische Anleitung willst, wie du Specs auf diese Weise schreibst, ist dieser Leitfaden dazu, wie man technische Specs schreibt, ein guter Startpunkt.
So sieht das in der Praxis aus
Angenommen, du baust Team-Einladungen in eine bestehende SaaS-App ein.
Dein Mini-RFC könnte so aussehen:
- Problem: Wer die App nutzt, kann niemanden zur Zusammenarbeit einladen.
- Ziel: Einladungs-Flow hinzufügen, ohne die bestehende Auth kaputtzumachen.
- Vorgeschlagener Ansatz: Modell mit Einladungstokens, gebunden an den Workspace.
- Hauptrisiko: Fehlerhafter Umgang mit Tokens sorgt für Verwirrung bei den Accounts.
- Verworfene Alternative: Freies Teilen per E-Mail ohne Einladungsdatensätze.
Deine SDD wird dann konkret:
- Dateien, die wahrscheinlich betroffen sind
- Änderungen an der Datenbank
- Verhalten der neuen Endpunkte
- Annahmen zum E-Mail-Flow
- Akzeptanzkriterien für Einladen, erneutes Senden, Widerrufen, Annehmen
- Validierung für abgelaufene oder wiederverwendete Tokens
Das ist genug Kontext, damit Cursor, Claude Code, Codex oder Gemini etwas liefern, das näher an dem liegt, was du willst.
Aus der Praxis: Das Optimum ist nicht „möglichst wenige Worte“. Es ist „möglichst wenig Unklarheit“.
So führst du diesen Prozess noch heute ein
Bau nicht deinen ganzen Workflow um. Teste das bei deiner nächsten Aufgabe.
Mach das beim nächsten Feature
- Schreib zuerst einen Mini-RFC. Öffne eine Textdatei und schreib das Problem, das Ziel, die vorgeschlagene Lösung und eine verworfene Alternative auf.
- Erweitere ihn zu einer kleinen SDD. Ein starkes Design Doc sollte den IST-Zustand, Alternativen, die gewählte Logik und die Aufteilung in Aufgaben abdecken, damit sich der Plan an Performance, Skalierbarkeit, Sicherheit und Zuverlässigkeit messen lässt, so dieser praxisnahe Design-Doc-Benchmark.
- Füg diese SDD in deinen Coding-Agent ein. Bitte um eine Umsetzung auf Basis der Spec, nicht auf Basis einer vagen Feature-Anfrage.
- Bewerte das Ergebnis. Lag der erste Anlauf näher dran? Wurde das Review leichter? Hast du eine schlechte Idee vor dem Coden erwischt?
Wenn du schon mit Agent-Workflows experimentierst, lohnt sich dieser Beitrag über Code-Optimierung mit Claude AI, weil er sich auf praktische Arbeitsgewohnheiten konzentriert statt auf vagen Hype.
Mach es nicht komplizierter als nötig. Wenn die Aufgabe klein ist, ist dein RFC winzig. Wenn die Aufgabe riskant ist, nimm dir mehr Zeit für die Entscheidung. Dann schreib die Ausführungs-Spec und liefere aus.
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 PR, 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.