Ein Entwickler baut ein neues Feature in 20 Minuten per Chat mit einem AI-Agenten. Das Ergebnis sieht gut aus, die Tests laufen durch. Drei Tage später verbringt das Team eine volle Arbeitswoche damit, die Sicherheitslücken zu fixen, die Architektur an den bestehenden Code anzupassen und die hardkodierten Credentials aus dem Repository zu entfernen. Was als Produktivitätsgewinn begann, endete als technische Schuld.
Diese Geschichte wiederholt sich tausendfach in der Branche. Immer mehr Startups setzen auf überwiegend AI-generierten Code - Y Combinator berichtete, dass ein Viertel der akzeptierten Startups Codebases mit 95 Prozent AI-generiertem Code einreichten. Doch was anfangs begeistert, führt schnell zu Ernüchterung: generischer Code, schlechte Architektur, Sicherheitslücken. Spec Driven Development (SDD) verspricht einen Ausweg - indem es die Spezifikation zur “Single Source of Truth” macht, bevor eine einzige Zeile Code entsteht.
Das Versprechen und die Ernüchterung
Als Andrej Karpathy im Februar 2025 den Begriff “Vibe Coding” prägte [1], war die Euphorie groß. Einfach drauflos prompten, der AI beim Programmieren zusehen - Softwareentwicklung als kreatives Gespräch statt mühsamer Handarbeit. Innerhalb weniger Wochen bauten Entwickler Prototypen, die früher Wochen gedauert hätten.
Die Realität sieht inzwischen nüchterner aus. Der Stack Overflow Developer Survey 2025 [2] zeichnet ein ernüchterndes Bild: Nur 3 Prozent der Entwickler haben “hohes Vertrauen” in AI-generierten Code, 72 Prozent lehnen Vibe Coding für professionelle Arbeit ab. GitClears Langzeitanalyse [3] über 211 Millionen Zeilen Code zeigt, dass Code Churn - also Code, der kurz nach dem Schreiben wieder geändert oder gelöscht wird - sich seit der Einführung von AI-Coding-Tools verdoppelt hat, während Refactoring um 60 Prozent zurückging. Das bedeutet: AI produziert mehr Code, aber dieser Code hat eine kürzere Halbwertszeit. CodeRabbit [4] meldet parallel 1,7-mal mehr Issues in AI-generiertem Code als in menschlich geschriebenem.
Die Zahlen zur Sicherheit sind besonders alarmierend. Veracodes GenAI Code Security Report [5], der über 100 LLMs bei 80 Programmieraufgaben testete, fand in 45 Prozent der Fälle unsichere Methoden. Bei Java lag die Failure-Rate über 70 Prozent, bei Cross-Site-Scripting bei 86 Prozent, bei Log Injection bei 88 Prozent. Eine Stanford-Studie (Perry et al.) [6] ergab, dass Entwickler mit AI-Unterstützung nicht nur unsichereren Code schrieben, sondern dessen Sicherheit gleichzeitig 3,5-fach überschätzten.
Apiiros Analyse [7] von Fortune-50-Unternehmen bestätigt den Trend im Enterprise-Kontext: Während AI die Entwicklungsgeschwindigkeit vervierfachte, verzehnfachten sich die Sicherheitsrisiken. Privilege-Escalation-Vulnerabilities stiegen um 322 Prozent, und die Unternehmen fanden sich mit über 10.000 neuen Sicherheitsfunden pro Monat konfrontiert.
Die Konsequenzen sind nicht abstrakt. Im Juli 2025 entdeckte das Sicherheitsunternehmen Wiz eine kritische Authentication-Bypass-Schwachstelle in Base44 [8], einer von Wix akquirierten Vibe-Coding-Plattform - 20.000 Nutzer waren betroffen. CVE-2025-54135 (CurXecute) [9] ermöglichte Angreifern, Cursor zur Ausführung beliebiger Befehle auf dem Entwicklerrechner zu zwingen. Und GitGuardians Analyse [10] von 20.000 Repositories mit aktivem Copilot zeigte, dass 6,4 Prozent mindestens ein Secret leakten - 40 Prozent mehr als der Durchschnitt aller öffentlichen Repositories. Die Konsequenz war nicht weniger AI - sondern der Ruf nach besserer Steuerung.
Snyks AI Code Security Report [11] unterstreicht die systemische Dimension: 75 Prozent der Entwickler glauben, AI-Code sei sicherer als menschlicher Code - obwohl 56 Prozent gleichzeitig zugeben, dass AI-generierter Code manchmal oder häufig Sicherheitsprobleme einführt. Rund 80 Prozent umgehen etablierte Security-Policies zur Nutzung von AI-Code-Tools, und nur 10 Prozent scannen den Großteil des AI-generierten Codes. Die Overconfidence ist systemisch - und genau hier setzt SDD an.
Die Wurzel des Problems: Kontext ist King
Warum produzieren leistungsfähige Modelle so häufig mangelhaften Code? Die Antwort liegt im fehlenden Kontext. Ein Chat-Prompt wie “Baue mir ein User-Login” enthält nichts über Architekturentscheidungen, bestehende Dependency-Strategien, Sicherheitsanforderungen oder Coding-Konventionen des Projekts. Das Modell füllt diese Lücken mit statistisch wahrscheinlichen Annahmen - und generiert generischen Code, der technisch funktioniert, aber nicht ins Projekt passt.
Birgitta Böckeler von Thoughtworks beschrieb bereits 2023 drei Ebenen, auf denen AI-Coding-Assistenten Kontext benötigen [12]: die Organisation (Architektur, Standards, Non-Functional Requirements), das Projekt (Abhängigkeiten, Patterns, Konventionen) und die einzelne Aufgabe (Akzeptanzkriterien, Edge Cases, Abhängigkeiten). Ohne diesen Kontext operiert die AI wie ein brillanter, aber uninformierter Freelancer am ersten Tag.
McKinseys Analyse [13] von über 200 Organisationen, die AI-Coding-Tools einsetzen, identifiziert genau diesen Punkt als Differenzierungsmerkmal: Top-Performer verlagerten ihren Fokus von “story-driven” auf “spec-driven” Development. Sie investierten mehr Zeit in die Vorbereitung des Kontexts und ernteten dafür konsistentere Ergebnisse. Gleichzeitig zeigte die vielbeachtete METR-Studie [14], dass erfahrene Entwickler mit AI-Tools bei vertrauten Projekten sogar 19 Prozent langsamer arbeiteten als ohne AI - weil der Overhead für Kontextvermittlung, Review und Korrektur die Generierungsgeschwindigkeit überwog. Die Schlussfolgerung: Nicht mehr AI ist die Lösung, sondern besserer Kontext.
Was ist Spec Driven Development?
Spec Driven Development (SDD) kehrt die gängige Reihenfolge um: Statt zuerst Code zu generieren und dann zu dokumentieren, beginnt der Prozess mit einer präzisen, maschinenlesbaren Spezifikation. Diese Spezifikation dient als Vertrag zwischen menschlicher Intention und AI-Implementierung - eine “Single Source of Truth”, die sowohl für Entwickler als auch für AI-Agenten lesbar ist.
Der Ansatz steht in der Tradition von Design by Contract (Bertrand Meyer, 1986) [15], API-First Development und Behavior-Driven Development (BDD). Was SDD unterscheidet, ist die explizite Ausrichtung auf AI-Agenten als primäre Konsumenten der Spezifikation. Während klassische Dokumentation für Menschen geschrieben wird, sind SDD-Specs gleichzeitig menschlich lesbar und maschinenoptimiert. Gegenüber TDD liegt der Unterschied im Scope: TDD spezifiziert Verhalten auf Funktionsebene, SDD auf Feature- und Systemebene.
Thoughtworks nahm SDD im Technology Radar Vol. 32 [16] offiziell als empfohlene Technik auf - ein Signal, dass die Methodik über den Hype hinausgekommen ist.
Der typische SDD-Workflow folgt vier Phasen. In der Specify-Phase werden Requirements, Constraints und Akzeptanzkriterien in strukturiertem Format festgehalten - oft im Given/When/Then-Format, das aus BDD bekannt ist. Eine Spec könnte etwa so aussehen:
Feature: User Session Management
Given: Ein authentifizierter User mit gültiger Session
When: Die Session länger als 30 Minuten inaktiv ist
Then: Der User wird automatisch ausgeloggt
And: Alle temporären Daten werden bereinigt
And: Ein Audit-Log-Eintrag wird erstellt
Constraints: Keine Verwendung von localStorage für Session-TokensDie Plan-Phase übersetzt die Spezifikation in einen technischen Implementierungsplan: Welche Komponenten sind betroffen? Welche Schnittstellen ändern sich? Welche Risiken bestehen? In der Tasks-Phase wird der Plan in atomare, umsetzbare Aufgaben zerlegt, jeweils mit klaren Akzeptanzkriterien und geschätztem Umfang. Erst in der Implement-Phase generiert die AI den eigentlichen Code - nun aber mit vollem Kontext über das Was, das Warum und die Rahmenbedingungen.
Die Tools: Spec Kit und OpenSpec im Detail
Zwei Open-Source-Projekte haben sich als führende SDD-Frameworks etabliert: GitHub Spec Kit [17] und Fission-AI OpenSpec [18]. Sie verfolgen die gleiche Grundidee, unterscheiden sich aber erheblich in Philosophie und Umsetzung.
GitHub Spec Kit: Das methodische Schwergewicht
Spec Kit entstand aus der Forschung von John Lam bei GitHub und wurde im September 2025 veröffentlicht [17]. Mit rund 67.000 GitHub-Stars hat es schnell eine große Community aufgebaut. Das Tool ist Python-basiert, läuft über uv/uvx und setzt auf einen strikten, phasenbasierten Workflow.
Das Alleinstellungsmerkmal ist das “Constitution”-Konzept: Vor jeder Spezifikation definiert das Team nicht-verhandelbare Projektprinzipien - Architekturentscheidungen, Technologie-Stacks, Sicherheitsrichtlinien, Coding-Standards. Eine typische Constitution enthält Aussagen wie “Alle API-Endpunkte müssen Rate-Limiting implementieren” oder “Keine direkten Datenbankzugriffe außerhalb der Repository-Schicht”. Diese Constitution bildet den unveränderlichen Rahmen, innerhalb dessen die AI arbeitet. Das verhindert, dass die AI bei jedem Feature eigene Architekturentscheidungen trifft - ein Problem, das ohne Constitution regelmäßig zu inkonsistenten Codebases führt.
Ein typischer Spec-Kit-Workflow:
Jede Phase hat einen expliziten Review-Punkt - ein “Gate”, an dem der Entwickler das Ergebnis prüft und freigibt. Zusätzlich bietet speckit.clarify die Möglichkeit, Ambiguitäten in der Spezifikation systematisch aufzudecken, und speckit.analyze ermöglicht die Analyse bestehender Codebases als Input für neue Specs. Die Gründlichkeit hat ihren Preis: Das initiale Setup dauert rund 30 Minuten, und der Token-Verbrauch ist durch die detaillierten Markdown-Dokumente erheblich.
/speckit.constitution # Projektprinzipien definieren
/speckit.specify # Requirements strukturiert erfassen
/speckit.plan # Technischen Implementierungsplan erstellen
/speckit.tasks # Atomare Aufgaben generieren
/speckit.implement # Code auf Basis der Tasks generierenOpenSpec: Das leichtgewichtige Framework
OpenSpec wurde im Oktober 2025 von Fission-AI veröffentlicht [18] und verfolgt eine bewusst andere Philosophie. Mit rund 22.000 Stars richtet es sich explizit an bestehende Codebases - “Brownfield-first” statt primär Greenfield. Die fünf Kernprinzipien: fluid not rigid, iterative not waterfall, easy not complex, built for brownfield, scalable from personal to enterprise.
Das Setup dauert wenige Minuten, und der empfohlene Workflow ist bewusst weniger formal:
/opsx:new feature-auth # Neuen Change starten
/opsx:ff # Fast-Forward: alle Artefakte auf einmal
/opsx:apply # AI implementiert die Tasks
/opsx:archive # Change archivierenDer Fast-Forward-Befehl (/opsx:ff) generiert in einem Schritt vier Artefakte: ein Proposal (das Warum), Specs im Given/When/Then-Format (die Requirements), ein Design-Dokument (der technische Ansatz) und eine Task-Liste (die Implementierungsschritte). Im Verzeichnis openspec/changes/<n>/ entsteht eine nachvollziehbare Dokumentation jedes Changes.
Ein besonderes Feature ist das Delta-Spec-System: Änderungen an bestehenden Spezifikationen werden als ADDED, MODIFIED und REMOVED markiert. So bleibt die Entwicklungshistorie der Requirements nachvollziehbar - entscheidend in Brownfield-Projekten, wo sich Anforderungen kontinuierlich weiterentwickeln.
Die Wahl zwischen beiden
Spec Kit eignet sich für Greenfield-Projekte, große Teams und Organisationen, die strikte Prozesssicherheit brauchen - etwa in regulierten Branchen oder bei der Zusammenarbeit mit externen Dienstleistern. OpenSpec spielt seine Stärke bei bestehenden Codebases aus, in kleineren Teams und bei schneller, iterativer Feature-Entwicklung, wo Agilität wichtiger ist als formale Vollständigkeit. Beide Tools sind MIT-lizenziert und integrieren sich mit über 20 verschiedenen AI-Assistenten - von Claude über Cursor bis Copilot, ohne API-Keys. Sie sind auch nicht exklusiv: Manche Teams nutzen Spec Kits Constitution-Konzept für die übergreifenden Architekturprinzipien und OpenSpec für die tägliche Feature-Arbeit.
Was Unternehmen berichten
Mehrere prominente Tech-Unternehmen haben ihre Erfahrungen mit spec-driven Ansätzen öffentlich geteilt - und die Ergebnisse sind konsistent.
Shopifys CEO Tobi Lütke erklärte 2025 [19], dass jeder Mitarbeiter AI-Nutzung nachweisen müsse, bevor er zusätzliche Ressourcen anfordere. Der Wandel von “einfach drauflos prompten” zu strukturierten Workflows führte zu messbaren Verbesserungen. Die interne Devise: AI als “95th-percentile junior developer” behandeln - äußerst schnell und produktiv, aber ohne eigenes Urteilsvermögen über Architektur und Designentscheidungen. Diese Metapher trifft den Kern von SDD: Nicht die AI muss besser werden, sondern die Anweisungen, die sie bekommt.
EPAM Systems [20], eines der größten Software-Engineering-Unternehmen weltweit mit über 50.000 Entwicklern, integrierte Spec Kit in bestehende Enterprise-Projekte und berichtete von signifikant weniger Iterationsschleifen bei der AI-gestützten Code-Generierung. Der entscheidende Faktor war laut EPAM nicht das Tool selbst, sondern der Zwang, Requirements vor der Implementierung vollständig zu durchdenken - ein Effekt, den die agile Community als “Shift Left of Thinking” bezeichnet. Besonders in regulierten Branchen, wo Nachvollziehbarkeit und Audit-Trails wichtig sind, erwies sich die automatisch entstehende Dokumentation als wertvoller Nebeneffekt.
HumanLayer, ein Startup im Bereich AI-Agent-Orchestrierung, setzt OpenSpec für die eigene Produktentwicklung ein. CTO Dex Horthy [21] beschreibt den Ansatz als “Context Engineering” - die systematische Aufbereitung von Kontext als eigenständige Engineering-Disziplin. Das Team stellte fest, dass die Qualität des AI-generierten Codes direkt proportional zur Qualität der Spezifikation war, und machte Spec-Writing zur expliziten Aufgabe im Sprint.
Red Hat [22] verfolgt mit “Spec Coding” einen ähnlichen Ansatz, der auf 95 Prozent und mehr AI-Code-Accuracy abzielt. Der Schlüssel liegt in der strikten Trennung von Was (Spezifikation, menschliche Verantwortung) und Wie (Implementierung, AI-Verantwortung). Erste interne Ergebnisse zeigen, dass diese Trennung nicht nur die Code-Qualität verbessert, sondern auch die Review-Effizienz steigert, weil Reviewer die Spezifikation als Referenz nutzen können.
Das breitere Ökosystem
SDD existiert nicht im Vakuum. Ein wachsendes Ökosystem von Context-Dateien und Rule-Systemen adressiert verwandte Probleme auf verschiedenen Ebenen.
AGENTS.md [23], ein offener Standard der Agentic AI Foundation unter der Linux Foundation, bietet eine tool-agnostische Möglichkeit, AI-Agenten Projektkontext zu geben. Eine einzelne AGENTS.md-Datei im Repository-Root wird automatisch von unterstützten Tools gelesen - darunter OpenAI Codex, Google Jules, Cursor, Windsurf, Devin und viele weitere. OpenAIs eigenes Hauptrepository enthält mittlerweile 88 solcher Dateien.
Anthropics CLAUDE.md [24] bietet ein hierarchisches Memory-System für Claude Code mit drei Ebenen: User-Memory (~/.claude/[CLAUDE.md](<http://CLAUDE.md>)), Project-Memory (./[CLAUDE.md](<http://CLAUDE.md>)) und Directory-spezifische Overrides. Cursor Rules [25] im .mdc-Format ermöglichen path-spezifische Anweisungen mit vier Aktivierungsmodi (Always, Auto Attached, Agent Requested, Manual) - das Cursor Rules Directory hat bereits über 250.000 monatliche Nutzer.
AWS Kiro [26] verdient besondere Erwähnung als Enterprise-Alternative: Die im Juni 2025 vorgestellte IDE kombiniert Spec-Generierung aus natürlicher Sprache, automatische Task-Zerlegung und einen “Steering Hook”-Mechanismus, der bei jedem File-Save die Spec-Compliance prüft - eine kontinuierliche Validierung, die weder Spec Kit noch OpenSpec bieten.
Diese Tools sind komplementär: Während AGENTS.md [23] und Cursor Rules [25] den statischen Projektkontext bereitstellen (Coding-Standards, Architekturprinzipien, Tool-Konfiguration), definiert SDD den dynamischen, feature-spezifischen Kontext. In der Praxis nutzen viele Teams beides - eine CLAUDE.md für allgemeine Standards und Spec Kit oder OpenSpec für die Feature-Spezifikation.
Kritische Einordnung
Der offensichtlichste Einwand gegen SDD: Klingt das nicht verdächtig nach dem Wasserfall-Modell? Spezifikation vor Implementierung, strikte Phasen - hat die Branche das nicht aus guten Gründen hinter sich gelassen?
SDD unterscheidet sich vom klassischen Wasserfall in drei wesentlichen Punkten: Die Spezifikationen sind leichtgewichtig und iterativ, nicht monolithisch. Der Feedback-Loop ist extrem kurz - Minuten statt Monate. Und die Specs werden mit der Implementierung co-evoliert, nicht vorab eingefroren. OpenSpecs Delta-Spec-System ist ein gutes Beispiel dafür: Requirements verändern sich kontinuierlich, und die Spec bildet diesen Wandel ab, statt ihn zu verhindern.
Ein zweiter Kritikpunkt betrifft die Skalierung: Lohnt sich der Overhead für jede Art von Aufgabe? Vermutlich nicht. Bei kleinen Scripts, einmaligen Prototypen und explorativen Spike-Tasks ist Vibe Coding effizienter. Niemand braucht eine formale Spezifikation für ein Shell-Script, das Logfiles rotiert. SDD entfaltet seinen Wert bei Features ab einer gewissen Komplexität, bei teamübergreifender Arbeit und überall dort, wo Code länger als einen Sprint überleben soll.
Schließlich bleibt die Frage der Toolchain-Fragmentierung. Spec Kit, OpenSpec, Kiro, AGENTS.md, CLAUDE.md, Cursor Rules - das Ökosystem ist jung und unkonsolidiert. Standards fehlen, und die Gefahr besteht, dass Teams mehr Zeit mit der Tool-Auswahl verbringen als mit dem eigentlichen Spezifizieren. Die Konsolidierung wird kommen - die Frage ist nur, ob sich ein Standard durchsetzt oder ob die fragmentierte Landschaft bestehen bleibt.
Die Kunst liegt letztlich darin, den richtigen Grad an Spezifikation für den jeweiligen Kontext zu finden - genug Struktur, um die AI zu steuern, aber nicht so viel, dass der Overhead den Nutzen überwiegt.
Fazit und Ausblick
SDD steht noch am Anfang seiner Entwicklung, aber die Richtung ist klar. Die nächste Generation von Tools wird voraussichtlich AI-gestützte Spec-Generierung aus Codebase-Analyse bieten, Echtzeit-Compliance-Checks während der Implementierung und automatische Spec-Updates bei Code-Änderungen. AWS Kiros Steering Hooks [26] deuten bereits in diese Richtung.
Wenn die AI den Code schreibt, wird die Fähigkeit, präzise zu spezifizieren, zur zentralen Engineering-Kompetenz. SDD systematisiert genau diese Fähigkeit mit Tools und Workflows, die heute bereits produktiv einsetzbar sind. Die Verschiebung von “Code schreiben” zu “Specs schreiben” ist vielleicht die tiefgreifendste Veränderung, die AI-Tools in der Softwareentwicklung auslösen - nicht weil Coding verschwindet, sondern weil es zum Implementierungsdetail wird, während die eigentliche Engineering-Leistung in der Spezifikation liegt.
Für Entwickler und Tech Leads lautet die pragmatische Empfehlung: Klein anfangen. Ein bestehendes Feature mit OpenSpec oder Spec Kit spezifizieren, den AI-Output mit und ohne Spec vergleichen, und eigene Schlüsse ziehen. Die Tools sind Open Source, das Risiko ist gering - und die Wahrscheinlichkeit hoch, dass der Unterschied überrascht.
Quellen
[1] Andrej Karpathy, “Vibe Coding” — X/Twitter Post, 3. Februar 2025. https://x.com/karpathy/status/1886192184808149383
[2] Stack Overflow, “Developer Survey 2025”. https://survey.stackoverflow.co/2025
[3] GitClear, “AI Code Quality Research 2025 — Analyzing 211 Million Lines of Code”. https://www.gitclear.com/ai_assistant_code_quality_2025_research
[4] CodeRabbit, “State of AI vs Human Code Generation Report”, Dezember 2025. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
[5] Veracode, “GenAI Code Security Report 2025”. https://www.veracode.com/resources/genai-code-security-report
[6] Neil Perry et al., “Do Users Write More Insecure Code with AI Assistants?”, Stanford University, arXiv:2211.03622. https://arxiv.org/abs/2211.03622
[7] Apiiro, “4x Velocity, 10x Vulnerabilities: The AI-Generated Code Crisis”, September 2025. https://apiiro.com/blog/4x-velocity-10x-vulnerabilities
[8] Wiz Research, “Critical Vulnerability in AI Vibe Coding Platform Base44”, Juli 2025. https://www.wiz.io/blog/critical-vulnerability-base44
[9] CVE-2025-54135 (CurXecute) — Cursor IDE Remote Code Execution Vulnerability. https://nvd.nist.gov/vuln/detail/CVE-2025-54135
[10] GitGuardian, “State of Secrets Sprawl 2025”. https://www.gitguardian.com/state-of-secrets-sprawl-report-2025
[11] Snyk, “AI Code Security Report: Secure Adoption in the GenAI Era”. https://snyk.io/reports/secure-adoption-in-the-genai-era/
[12] Birgitta Böckeler, “Context is Everything: How to Make AI Coding Assistants Work for You”, Thoughtworks, 2023. https://www.thoughtworks.com/insights/blog/generative-ai/context-is-everything-ai-coding-assistants
[13] McKinsey, “Unlocking the Value of AI in Software Development”, 2025. https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/unlocking-the-value-of-ai-in-software-development
[14] METR, “Measuring the Impact of Early AI Assistance on Software Development” (Randomized Controlled Trial), arXiv:2507.09089, Juli 2025. https://arxiv.org/abs/2507.09089
[15] Bertrand Meyer, “Design by Contract”, in: Object-Oriented Software Construction, Prentice Hall, 1988.
[16] Thoughtworks, “Technology Radar Vol. 32 — Spec Driven Development”. https://www.thoughtworks.com/en-us/radar/techniques/spec-driven-development
[17] GitHub, “Spec Kit — Specification-Driven Development Framework”. https://github.com/github/spec-kit
[18] Fission-AI, “OpenSpec — Lightweight Spec-Driven Development”. https://github.com/Fission-AI/OpenSpec
[19] Tobi Lütke, “Reflexive AI usage is now a baseline expectation at Shopify” — Internes Memo, April 2025. https://x.com/tobi/status/1909251946235437514
[20] EPAM Systems, Erfahrungsbericht zur Integration von Spec Kit in Enterprise-Projekte, 2025.
[21] Dex Horthy / HumanLayer, “Advanced Context Engineering for Coding Agents”. https://github.com/humanlayer/context-engineering
[22] Red Hat, “Spec Coding: Achieving 95%+ AI Code Accuracy”, 2025.
[23] AGENTS.md — Offener Standard der Agentic AI Foundation / Linux Foundation. https://agents.md
[24] Anthropic, “CLAUDE.md — Memory Files for Claude Code”. https://docs.anthropic.com/en/docs/claude-code/memory
[25] Cursor Rules Directory. https://cursor.directory
[26] AWS, “Kiro — Spec-Driven AI IDE”, Juni 2025. https://kiro.dev
