Spec-Driven Development für Agentic Software Engineering: Warum die Spec der Vertrag zwischen Team und Agents ist

Warum mehr Code pro Entwickler weniger Output pro Team bringen kann

Coding ist schnell geworden. Die Koordination nicht. Wer Spec-Driven Development für Agentic Software Engineering verstehen will, startet bei dieser Zahl: Teams mit hoher AI-Nutzung erledigten 21 Prozent mehr Aufgaben und mergten 98 Prozent mehr Pull Requests, aber die Review-Zeit stieg um 91 Prozent, die PR-Grösse um 154 Prozent und die Defekte pro Entwickler um 9 Prozent. Das ist der Befund von Faros AI über 10'000 Entwickler in 1'255 Teams.³

Die anderen Quellen zeigen dasselbe Muster. DORA fand 2024 mit steigender AI-Adoption sinkende Delivery-Stabilität und fasste es 2025 so zusammen: AI repariert kein Team, sie verstärkt, was schon da ist. METR mass in einem randomisierten Versuch, dass erfahrene Entwickler mit AI 19 Prozent länger brauchten, während sie glaubten, 20 Prozent schneller zu sein. Und GitClear sah über 211 Millionen geänderte Zeilen den Anteil von Refactoring von 25 auf unter 10 Prozent fallen, bei achtfach mehr duplizierten Blöcken.^4,5,6

Ein Paper der Universidad Politécnica de Madrid, eingereicht bei ACM und seit Ende August 2026 auf arXiv, zieht daraus eine klare Diagnose: Der limitierende Faktor ist nicht die Modellfähigkeit, sondern die Absorptionskapazität des sozio-technischen Systems drumherum. Wer eine Phase des Lebenszyklus (Codeproduktion) beschleunigt, beschleunigt nicht das System, solange Review, Verifikation und Integration ihre alte Kapazität behalten. Das ist Amdahls Gesetz, angewandt auf den Software-Lebenszyklus, und es ist dieselbe Lektion, die früher Scrum-Teams lernten, deren Sprints die Ops-Abteilung überrollten.¹

Ich lese das Paper seit Wochen mit dem Stift. Nicht, weil es neue Zahlen bringt, sondern weil es die lose Praktiker-Diskussion um Harness, Specs und Agents in einen Rahmen bringt, den ein Produktteam operativ umsetzen kann. In diesem Beitrag lernst du, was die Autoren unter Spec-Driven Development verstehen, aus welchen acht Mechanismen ihr methodischer Harness besteht, wie sich die Rolle von Product Managern und Engineers verschiebt, und wo das im PM Grader und im AI Product Playbook landet.

Was Vibe Coding im Team zerstört: Verantwortung, Prüfbarkeit, Übertragbarkeit

Die Autoren vergleichen vier Entwicklungsparadigmen entlang von fünf Dimensionen: Arbeitseinheit, primäres Artefakt, Ort der Kognition, Verantwortung und Teamtopologie. Agile und DevOps: die User Story, lauffähige Software, der einzelne Entwickler, individuelle Verantwortung, das cross-funktionale Squad. AI-augmentiertes Engineering mit Copilot-artigen Assistenten ändert daran wenig; es beschleunigt Teilaufgaben, der Mensch bleibt Autor. Vibe Coding, von Karpathy Anfang 2025 so benannt, verschiebt dagegen die Kognition ins Chatfenster: Die Arbeitseinheit wird das ganze Feature, das Artefakt ist AI-geschriebener Code, die Verantwortung wird unklar, weil der Entwickler den PR signiert, den er nicht geschrieben hat.¹

Lokal funktioniert das. Ein guter Entwickler schafft in Stunden, was früher Tage brauchte. Im Team bricht es an fünf Stellen, die das Paper sauber benennt. Nicht-Reproduzierbarkeit: Derselbe Prompt liefert im selben Kontext anderen Code, und niemand kann die Frage «warum steht dieser Code hier?» beantworten, ohne ein Gespräch zu rekonstruieren, das selten gespeichert ist. Nicht-Prüfbarkeit: Die Begründung liegt in einem flüchtigen Chat-Log, der Reviewer hat nur den Code. Nicht-Übertragbarkeit: Wer das Team verlässt, nimmt den Gesprächskontext mit; der Nachfolger muss aus dem Code zurückschliessen, was einmal explizit war.¹

Dazu kommen Review-Sättigung, weil ein Reviewer die Absicht hinter einem agentengenerierten PR nicht wiederherstellen kann und sie aus dem Diff rekonstruieren muss, und Noise-Scaling, weil mehrere Entwickler mit je eigenen AI-Dialogen die Codebasis in Namen, Struktur und Architektur auseinanderlaufen lassen. Die Autoren betonen: Das sind Fehler der Methodik, nicht der Praktiker. Vibe Coding ist die natürliche Erkundungsphase eines neuen Werkzeugs. Das Produktivitätsparadox ist das sichtbare Symptom fehlender Team-Disziplin.¹

Agentic Software Engineering, die vierte Stufe, delegiert Ziele statt Prompts: Die Arbeitseinheit ist das technische Ziel («Rate Limiting für die Orders-API»), die Kognition verteilt sich auf Menschen (Absicht, Aufsicht, Strategie) und Agents (Ausführung, parallele Exploration), die Topologie wird N-zu-N. Und genau hier wird die Spec zur Voraussetzung: Agentic Engineering ohne Spec-Disziplin reproduziert die Schwächen des Vibe Codings in grösserem Massstab, schneller, breiter, schlechter koordiniert.^1,7

Die These: Die Spec ist der Vertrag, der Harness gehört dem Team

Meine These, gestützt auf das Paper: Das Produktivitätsparadox ist eine Governance-Lücke, und sie schliesst sich nicht mit besseren Modellen, sondern mit einer Spec, die als versionierter Vertrag zwischen Menschen und Agents gilt, und mit einem Harness, der dem Team gehört statt dem Werkzeug. Das ist keine Rückkehr zum Pflichtenheft. Es ist der Schritt, der Verantwortung, Prüfbarkeit und Übertragbarkeit in einer Form wiederherstellt, die mit Agenten funktioniert: Verantwortung wird vertraglich gegen die Spec, Verifikation prüft Evidenz statt Absicht zu rekonstruieren, Onboarding liest Specs statt Code.¹

Das Paper begründet den Bedarf an Specs über eine Kette: Specs ermöglichen Verträge, Verträge ermöglichen Koordination, Koordination ermöglicht Vertrauen in einem Massstab, in dem direkte menschliche Inspektion nicht mehr möglich ist. Drei Probleme hängen daran. Das Vertragsproblem: Ein Agent mit vagem Ticket produziert plausiblen Code, der nicht das Gewollte ist, und die Kosten zahlt das Review. Das Koordinationsproblem: Wenn das gemeinsame Artefakt der Code ist, schreiben Agents widersprüchlichen Code. Das Vertrauensproblem: Menschen können Agent-Output in Agent-Volumen nicht Zeile für Zeile prüfen; Vertrauen braucht Evidenz der Konformität, und Evidenz braucht einen Referenten.¹

Was Spec-Driven Development operativ bedeutet: vier Verpflichtungen und zwei Ebenen

Die operative Definition ist kurz. Ein Team arbeitet spec-driven, wenn erstens jede nicht-triviale geplante Änderung von einer schriftlichen Spezifikation ausgeht, die das Team als Vertrag behandelt; zweitens die Spec neben dem Code versioniert ist, mit derselben Review-, Audit- und Rollback-Disziplin; drittens Artefakte (Code, Tests, Doku, Infrastruktur) von Menschen, Agents oder beiden aus der Spec abgeleitet werden, mit expliziter Herkunft; und viertens bei Widerspruch zwischen Spec und Artefakt die Spec die Wahrheit ist und der Widerspruch durch Neuableitung oder Spec-Änderung gelöst wird, nie durch stille Edits. Vier Sätze, leicht zu sagen, schwer zu leben.¹

Der praktische Kern, den viele Teams übersehen, ist die Trennung zweier Ebenen. Systemspezifikationen beschreiben die dauerhafte Welt des Projekts: Architektur, Konventionen, Domänenmodell, Muster und die normativen Regeln, die jede Änderung respektieren muss. Sie gehören Tech Leads und Architekten, ändern sich mit Architekturentscheiden und werden zunehmend als maschinenlesbare Regeldatei materialisiert, die der Agent bei jedem Sessionstart lädt: agent.md, CLAUDE.md, AGENTS.md oder Äquivalent. Feature-Spezifikationen beschreiben eine konkrete Änderung in dieser Welt: Ziel, Anforderungen, Constraints, Akzeptanzkriterien. Sie gehören dem verantwortlichen Entwickler, entstehen pro Aufgabe und werden nach Auslieferung archiviert.¹

Beide müssen im Kontext des Agents sein. Nur die Feature-Spec geladen, liefert der Agent funktional korrekten, aber architektonisch inkonsistenten Code. Nur die System-Spec geladen, kann er die Aufgabe nicht verankern. Und wer beides vermischt, bekommt entweder Rigidität (Feature-Entscheide in der System-Spec) oder Architektur-Drift (globale Constraints, die in jeder Feature-Spec neu erfunden werden). Als drittes Artefakt nennen die Autoren Skills: prozedurales Know-how, das der Orchestrator nur lädt, wenn eine Aufgabe es braucht. Normen sind immer aktiv («was jede Änderung respektieren muss»), Skills sind on demand («wie man X tut»). Wer eine Konvention in einen Skill packt, wird sie in jeder Session verletzt sehen, die den Skill nicht auslöst.¹

Zwei Missverständnisse räumt das Paper aus. SDD heisst nicht mehr Dokumentation: Code zu dokumentieren, der schon existiert, ist retrospektiv und hinkt; Verhalten zu spezifizieren, bevor es gebaut wird, ist Design, und im agentischen Modell wird der Unterschied verschärft, weil der Agent die Spec zur Ausführungszeit konsumiert. Eine vage Spec ist nicht schlechte Doku, sondern schlechter Input, der in Agent-Massstab schlechten Output erzeugt. Und SDD ist kein Wasserfall: Der Zyklus Vorschlag, Anwendung, Archiv (wie bei OpenSpec-artigen Workflows) ist iterativ, nur eben Spec zuerst, Code danach. Das deckt sich mit dem, was ich im Beitrag zur Arbeitsteilung zwischen Discovery und Execution als Define-Gate beschrieben habe.¹

Wie der methodische Harness aussieht: acht Mechanismen, die dem Team gehören

Harness ist in der Agent-Community der Name für alles im Agentensystem ausser dem Modell: Agent = Modell + Harness. Der technische Harness (Orchestrierungsschleife, Tools, Kontextmanagement, Speicher, Guardrails, Verifikationsschleifen) steuert einen Agent in einer Session. Er ist transient: Je besser die Modelle, desto weniger Gerüst brauchen sie, und er wird mit dem Modell co-evolviert. Investitionen darin entwerten sich schnell. Der zweite, methodische Harness besteht aus Praktiken und Artefakten, die dem Team gehören. Er kodiert Absicht, Normen und akkumulierte Entscheide und gewinnt mit der Zeit an Wert. Die praktische Folge: Teams sollten zuerst in den dauerhaften Harness investieren und die Werkzeugwahl als zweitrangig behandeln.^1,8

Wissen. Mechanismus 1, Context Engineering: Das Team baut und pflegt die Informationsumgebung der Agents als gemeinsames, versioniertes Asset. Das Beispiel im Paper ist bitter vertraut: Eine zwei Jahre alte Architekturentscheidung (alle Zeitstempel in UTC) liegt in einem Wiki, das der Agent nie sieht; er baut die Refund-Funktion mit der lokalen Zeitzone, Tests laufen in UTC durch, der Fehler erscheint Monate später in der Abstimmung. Die Korrektur ist eine Zeile in der Systemspezifikation, die die ganze Fehlerklasse für jedes künftige Feature verhindert. Mechanismus 2, Persistent Shared Knowledge: ein Speicher für Entscheide, Begründungen und Session-Zusammenfassungen, der zu Beginn jeder Agent-Session gelesen und am Ende beschrieben wird. Agents haben keine Kontinuität zwischen Sessions; ohne diesen Speicher entdeckt jede Session die Entscheide des Projekts neu, und der Sub-Agent weiss nichts vom Entscheid, den ein anderer Agent vor einer Stunde traf. Drei Eigenschaften machen ihn teamfähig: Er speichert Zusammenfassungen und Entscheide statt Transkripte, er erlaubt lazy Retrieval, und er ist agent- und tool-neutral. Das ist, in der Sprache der Forschung, das Product Brain.¹

Produktion. Mechanismus 3, ausführbare Spezifikationen: Akzeptanzkriterien sind testbar (Given, When, Then), Constraints prüfbar (eine Regel, die kein Werkzeug durchsetzen kann, ist ein Wunsch), Entscheide explizit (POST /payments/{id}/refunds mit 201, nicht PUT), damit Konformitätschecks sie validieren. Eine Spec, die ein Agent konsumiert und Tests validieren, bleibt lebendig; eine, die nur Menschen lesen, verfällt zur Doku, der niemand traut. Mechanismus 4, N-Version-Denken und parallele Agents: Dieselbe Spec geht an drei Agents, die drei Kandidaten liefern; die kognitive Aufgabe des Entwicklers wird «spezifiziere klar genug, dass sich Implementierungen vergleichen lassen», und die gefragte Fähigkeit ist vergleichendes Lesen statt Schreiben. Technisch braucht das Working Trees statt geteilter Branches, damit Konflikte von der stillen Arbeitszeit in die laute Merge-Zeit wandern.¹

Governance. Mechanismus 5, normative Spezifikationen: Die stehenden Normen des Teams (Konventionen, Muster, Verbote) sind ein expliziter, versionierter, reviewter Teil der Systemspezifikation, nicht stilles Wissen im Kopf des Senior Engineers. Das Beispiel: Nach der dritten identischen Review-Korrektur («Service-Methoden fangen keine generische Exception») wird die Korrektur per Pull Request zur Regel in der Regeldatei, gekoppelt mit einem Lint-Sensor, und der Agent korrigiert sich selbst, bevor ein Mensch den Code sieht. Mechanismus 6, strukturierte Rückfrage: Der Agent hält bei einer Entscheidung an, die er nicht treffen darf, und stellt eine begrenzte Anfrage mit Frage, Optionen, betroffenen Spec-Klauseln und Konsequenzen; die Antwort wird gegen die Spec festgehalten, damit dieselbe Frage nie zweimal gestellt wird. Mechanismus 7, Evidenz-basierte Abnahme: «Fertig» ist nicht «PR gemerged», sondern ein Evidenzpaket, das jede Spec-Klausel entlastet: ausgeführte Akzeptanztests, CI-Ausgabe, eine kurze Begründung, Links auf Spec-Version und geltende Normen. Der Reviewer prüft Evidenz und bohrt nur nach, wo sie schwach ist. Mechanismus 8, abgestufte Autonomie: Autonomie wird pro Aufgabenklasse explizit und revidierbar festgelegt (Dependency-Updates vollautonom, Feature-Arbeit mit Pflicht-Rückfrage, Auth-Änderungen mit genehmigtem Plan und schrittweisem Review), als Teamentscheid in Artefakten, nicht als individuelle Gewohnheit.^1,7

Die acht Mechanismen verstärken sich gegenseitig, und das ist der wichtigste Satz des Papers für Produktteams: Ein Team, das den Harness fragmentarisch übernimmt, etwa Feature-Specs schreibt, aber Normen und Entscheide nicht persistiert, bekommt einen Bruchteil des Nutzens und zahlt den Grossteil der Disziplinkosten. Teilweise, ungesteuerte Adoption kann Team-Ergebnisse verschlechtern. Das deckt sich mit dem DORA-Befund, dass AI Dysfunktion verstärkt. Im Teklens-Vokabular: Das Product Brain ist Mechanismus 1 und 2, die Quality Gates sind Mechanismus 6 bis 8, und die Activities des Playbooks sind die Orte, an denen Mechanismus 3 bis 5 konkret werden: Write a PRD und Write a good ticket für Feature-Specs mit ausführbaren Kriterien, Record an architecture decision für Normen und Entscheide, Review a code change für die Abnahme gegen Evidenz.^1,4

Wie sich die Rolle des Menschen ändert: fünf Interaktionsmuster und sechs Kompetenzen

Der Harness hat eine Folge: Das Team selbst verändert sich. Die Autoren destillieren fünf wiederkehrende Interaktionen, alle als Operationen auf der gemeinsamen Spec. Briefing: Der Mensch vermittelt Absicht über eine strukturierte Spec und muss in Eigenschaften denken («die Operation muss idempotent sein»), nicht in Beispielen. Rückfrage: Der Agent fordert eine begrenzte Entscheidung an; das verlangt vom Menschen schnelles Kontextladen und vom Team Routing-Regeln, weil eine unbeantwortete Rückfrage parallele Agents blockiert. Review: Der Mensch prüft ein Evidenzpaket gegen die Spec; das verlangt die Fähigkeit, Evidenz zu lesen statt Korrektheit neu herzuleiten, und die kulturelle Akzeptanz, dass manche Senior Engineers als Kontrollverlust empfinden. Normkodierung: Wiederkehrende Korrekturen werden zu Regeln generalisiert. Orchestrierung: Der Mensch komponiert Workflows aus Agents mit Autonomiestufen und Evidenzanforderungen, schreibt aber selbst keinen Code, damit sein eigener Kontext frei von Ausführungsdetails bleibt.¹

Zusammengenommen beschreiben die Muster, was die primäre Arbeit des Menschen ist: Briefs, Regeln, Workflow-Definitionen, Rückfrage-Antworten und Evidenz-Urteile. Codeproduktion ist weitgehend delegiert. Das kognitive Zentrum wandert stromaufwärts (Klarheit der Absicht, Architektur-Urteil) und seitwärts (vergleichende Bewertung von Kandidaten). Sechs Kompetenzen nennen die Autoren: Spezifikations-Literacy, Architektur-Denken als tägliche Kompetenz, vergleichendes Lesen, Norm-Artikulation, Orchestrierung mit Kostenbewusstsein und strategische Geduld, also der Widerstand gegen «einfach mal coden», wenn die Situation Spezifizieren verlangt. Das ist die kulturelle Umkehr, die das ganze agentische Modell verlangt.¹

Für Produktteams ist ein Satz besonders wichtig: «The product manager becomes a co-author of product specifications in a tighter loop than under Agile, because ambiguity at the product level now propagates directly into agent output.» Der Tech Lead wird Hauptautor der Systemspezifikation, deren Wirkung über alle Features skaliert. QA dreht sich von nachträglichem Testen zu vorgängiger Spezifikation der Testbarkeit. Ops und Security wechseln vom Gatekeeping zum Schreiben der operativen und sicherheitsrelevanten Specs, die ihre Agents steuern. Die Topologie wird N-zu-N: mehrere Menschen, mehrere spezialisierte Agents, verbunden über das gemeinsame Spec-Substrat. Drei kulturelle Verschiebungen nennen die Autoren als die eigentlich harten: Seniorität wandert vom Coden zur Spezifikation (Deference Shift), Verantwortung verteilt sich auf Brief-Autor, Orchestrator und Evidenz-Reviewer (Accountability Shift), und Juniors können nicht mehr nur über Code senior werden (Skill Investment Shift).¹

Was das für den PM Grader und euer Playbook heisst

Der PM Grader fragt in sechs Situationen, wie euer Team heute mit AI arbeitet, und vier davon sind direkt Harness-Mechanismen. Die Situation «Ein Agent übernimmt morgen eine Story. Was findet er vor?» misst Mechanismus 1 und den technischen Harness (Doku, Berechtigungen, Testumgebung, CI, Release-Kontrollen). «Ein neues Teammitglied oder ein Agent muss euer Vorhaben verstehen. Wo findet es die Wahrheit?» ist Mechanismus 2, Persistent Shared Knowledge, in einer Frage. «Der Agent sagt: fertig. Wer gibt das Ergebnis frei und wogegen?» ist Mechanismus 7, Evidenz-basierte Abnahme. Und «Welche Regeln gelten für Daten, Anbieter und Aktionen eurer AI?» ist Mechanismus 8, abgestufte Autonomie, plus die normativen Regeln aus Mechanismus 5.

Die Reifestufen des Graders folgen der Logik des Papers. Stufe 1 und 2 sind Vibe Coding im Team: Kontext wird zusammenkopiert, Ergebnisse werden informell abgenickt. Stufe 3 hat die Artefakte (ein Projektdokument, eine benannte Review-Regel), aber nicht den Kreis. Stufe 4 hat den Vertrag: verknüpfte Evidenz mit Owner, Prüfung gegen explizite Kriterien, Regeln zu Daten und Anbietern. Stufe 5 schliesst den Kreis: Widersprüche sind sichtbar, Review-Entscheide nachvollziehbar, Regeln werden nach Vorfällen angepasst. Wer im Grader bei Kontext oder Freigabe auf Stufe 2 landet, bekommt als nächsten Schritt genau die Activities, die Mechanismus 1 bis 3 herstellen; wer auf Stufe 4 steht, bekommt die für Mechanismus 6 bis 8. Der Deep Dive mit sechs weiteren Situationen schärft dieselben Dimensionen, und der Report ordnet die drei Prioritäten in einen 30/60/90-Tage-Plan.

Und das Playbook? Die 43 Activities sind in der Sprache des Papers Feature-Specs für Produktarbeit: Jede hat Auslöser, benötigten Kontext, Schritte mit Skills, Qualitätskriterien und eine menschliche Freigabe. Das Product Brain ist der gemeinsame Wissensspeicher, aus dem Menschen und Agents den passenden Kontext pro Aufgabe ziehen. Dass die Autoren Produkt-Specs explizit als zweiten Spec-Typ neben Code-Specs nennen, ist für mich die Bestätigung, dass Spec-Driven Development nicht beim Engineering aufhört: Die Ambiguität, die in Agent-Output durchschlägt, entsteht meist eine Stufe höher, in Discovery und Define.

Wo die Grenzen liegen: vier Vorhersagen, fünf Risiken, ein Forschungsprogramm

Der stärkste Beleg für die These ist, dass die Autoren ihn nicht überdehnen. Vier Nutzen sagen sie voraus und nennen sie testbare Hypothesen: Konsistenz (geteilter Kontext und Normen reduzieren Drift), Absorption (Evidenz-basierte Abnahme adressiert den Review-Engpass, den Faros und Qodo als Hauptbremse identifizieren), Übertragbarkeit (Onboarding liest Specs und den Wissensspeicher statt Code) und organisationales Compounding (das Kontext-Asset wächst mit jedem Feature, die Grenzkosten der Aufsicht sinken). Fünf Risiken stellen sie daneben: Talent-Bifurkation zwischen denen, die Orchestrierung lernen, und denen, die es nicht tun; kultureller Bruch bei erfahrenen Engineers; Kostenspirale durch ungezählte Agent-Aufrufe; Spec-Drift, wenn Spec und Code still auseinanderlaufen; und Plattform-Lock-in durch proprietäre Spec-Formate.^1,3

Methodisch ist das Paper eine multivokale Literaturübersicht: 94 eingeschlossene Arbeiten aus IEEE Xplore, ACM, Scopus und arXiv plus graue Literatur von DORA, Faros, METR, GitClear, Stack Overflow, Martin Fowler, LangChain und Praktikern wie Karpathy; das Replikationspaket liegt auf Zenodo. Die Autoren sagen unmissverständlich, dass die Konstrukte (Agentic SE, Vibe Coding, Harness, Spezifikation) jung und umstritten sind, dass die Synthese kohärent, aber nicht empirisch validiert ist, und dass die motivierende Evidenz zu Web, SaaS und Plattform-Engineering tendiert; für eingebettete, sicherheitskritische oder stark regulierte Software ist die Übertragung plausibel, aber unbewiesen. Das Forschungsprogramm, das sie aufstellen, deckt sich mit den Fragen, die ich aus Gesprächen mit Teams kenne: Wie organisieren sich Teams um die Orchestrator-Rolle, welche Mensch-zu-Agent-Verhältnisse entstehen, wie erwerben Engineers die neuen Kompetenzen, wie sequenzieren Organisationen die acht Mechanismen, und wie misst man Spec-Qualität, Evidenz-Vollständigkeit, Rückfrage-Latenz und Agent-Portfolio-Kosten, wo DORA-Metriken für menschlich geschriebene Software gebaut wurden.^1,2

Damit schliesst sich der Kreis zur ersten Zahl. 98 Prozent mehr Pull Requests sind kein Fortschritt, wenn sie 91 Prozent längere Reviews und mehr Defekte erzeugen. Das Paper erklärt, warum: Die Beschleunigung hat den Vertrag aufgelöst, der Teamarbeit möglich macht. Spec-Driven Development stellt ihn in agentischer Form wieder her. Wer schlechten Input automatisiert, liefert den Schlamassel nur schneller aus; wer die Spec zum Vertrag macht, liefert Evidenz. Die tiefere Erkenntnis ist unbequem für alle, die auf das nächste Modell warten: Der Harness, der zählt, ist nicht der technische um den Agent, sondern der methodische um das Team. Und den muss das Team selbst bauen.³

Häufige Fragen

Empfehlungen

• Trennt die zwei Spec-Ebenen diese Woche. Legt eine Systemspezifikation als Regeldatei im Repo an (Architektur, Konventionen, Verbote, maximal ein paar hundert Zeilen) und ein Template für Feature-Specs mit Ziel, Constraints, Akzeptanzkriterien und Verifikationsschritt. Activity: [Record an architecture decision](/playbook/record-an-architecture-decision) für die Normen, [Write a good ticket](/playbook/write-a-good-ticket) für die Feature-Spec.
• Macht Akzeptanzkriterien ausführbar. Für die nächste nicht-triviale Änderung: jedes Kriterium als Given, When, Then, jeder Constraint mit einem Werkzeug, das ihn prüft, jeder Entscheid explizit. Was kein Werkzeug prüfen kann, ist ein Wunsch, kein Constraint. Activity: [Write a PRD](/playbook/write-a-prd).
• Ersetzt «PR gemerged» durch ein Evidenzpaket. Verlangt von jedem Agent-PR ausgeführte Akzeptanztests, CI-Ausgabe, eine Begründung in drei Absätzen und den Link auf die Spec-Version. Reviewer prüfen Evidenz gegen Klauseln und bohren nur dort nach, wo sie schwach ist. Activity: [Review a code change](/playbook/review-a-code-change).
• Persistiert Entscheide und Rückfragen an einem Ort. Jede Agent-Rückfrage und ihre Antwort wird gegen die Spec festgehalten; jede Session endet mit einer Zusammenfassung im gemeinsamen Speicher, den die nächste Session liest. Das ist der Unterschied zwischen einer Sammlung von Sessions und einem Team. Im Teklens-Vokabular: das Product Brain.
• Kalibriert Autonomie pro Aufgabenklasse und schreibt sie auf. Drei Klassen reichen zum Start: vollautonom (Dependency-Updates mit Testsuite als Richter), autonom mit Pflicht-Rückfrage (normale Feature-Arbeit), Plan-Freigabe plus schrittweises Review (Auth, Zahlungen, Daten). Revidiert die Kalibrierung quartalsweise nach Vorfällen. Activity: [Run a blameless incident postmortem](/playbook/run-a-blameless-incident-postmortem).
• Messt, was DORA nicht misst. Spec-Qualität (wie oft musste nachgefragt werden), Vollständigkeit der Evidenzpakete, Latenz der Rückfragen, Review-Zeit pro PR und Agent-Kosten pro Feature. Steigt die Review-Zeit mit der PR-Zahl, habt ihr Vibe Coding im Team, nicht SDD. Activity: [Define and use KPIs](/playbook/define-and-use-kpis).

Einordnung & Grenzen

• Das Paper von Díaz, Gayoso, Cimminio und Pérez (Universidad Politécnica de Madrid, arXiv 2609.00252, 31. August 2026, bei ACM eingereicht) ist eine konzeptionelle Synthese aus einer multivokalen Literaturübersicht, überwiegend graue Literatur. Die Autoren betonen selbst, dass es kein validiertes Framework ist und dass die Frage, ob SDD das Produktivitätsparadox auflöst, empirisch offen bleibt. Ich übernehme ihre Begriffe, nicht ihre Beweiskraft.
• Die Zahlen zum Paradox stammen aus externen Quellen und sind so zitiert, wie das Paper sie wiedergibt: Faros AI (2025, Telemetrie von 10'000+ Entwicklern in 1'255 Teams, Vendor-Daten), DORA 2024 und 2025 (Korrelationen, Selbstauskunft), METR 2025 (16 Entwickler, 246 Aufgaben, inzwischen von METR selbst als veraltet bezeichnet) und GitClear (211 Mio. Zeilen, 2020 bis 2024). Keine davon ist eine Aussage über euer Team.
• Die Zuordnung von Product Brain, Quality Gates und Playbook Activities zu den acht Mechanismen ist meine Interpretation, keine Aussage der Autoren. Teklens wird im Paper nicht erwähnt. Die Reifestufen des PM Graders sind ein Teklens-Praxismodell und keine validierte Messung des Harness.
• SDD ist eine Governance-Disziplin, keine Universalvorschrift. Die Autoren selbst sagen: Für explorative Arbeit mit wirklich unbekannten Anforderungen kann eine bewusst leichtere Disziplin mit Wegwerf-Artefakten angemessener sein. Der Grad der Spezifikation hängt von Unsicherheit, Stabilität und erwarteter Lebensdauer des Ergebnisses ab.

Quellen

Jede externe Zahl und jedes Zitat in diesem Beitrag – nachprüfbar verlinkt.

1. 1.Díaz, J., Gayoso, J., Cimminio, A., Pérez, J. (2026). Spec-Driven Development for Agentic Software Engineering: Harnessing Human–Agent Teamwork. Universidad Politécnica de Madrid, arXiv:2609.00252, manuscript submitted to ACM ↗ – Multivokale Literaturübersicht; sozio-technisches Modell von SDD, acht Harness-Mechanismen, fünf Interaktionsmuster.
2. 2.Replikationspaket zum Paper, Zenodo, DOI 10.5281/zenodo.22151221 ↗ – Quellenauswahl und Extraktionsmatrix der Synthese.
3. 3.Faros AI (2025), The AI Productivity Paradox Report ↗ – Telemetrie von über 10'000 Entwicklern in 1'255 Teams: +21 % Aufgaben, +98 % PRs, +91 % Review-Zeit, +9 % Defekte.
4. 4.Google Cloud / DORA (2024, 2025), Accelerate State of DevOps Report und State of AI-assisted Software Development ↗ – 2024 sinkende Stabilität mit AI-Adoption; 2025 «AI verstärkt, was schon da ist».
5. 5.METR (2025), Measuring the Impact of Early-2025 AI Tools on Experienced Open-Source Developer Productivity ↗ – RCT mit 16 Entwicklern: 19 Prozent langsamer, gefühlt 20 Prozent schneller.
6. 6.GitClear (2025), AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones ↗ – 211 Mio. geänderte Zeilen 2020 bis 2024; Refactoring-Anteil von 25 auf unter 10 Prozent.
7. 7.Hassan, A. E., Li, H., Lin, D., Adams, B., Chen, T.-H., Kashiwa, Y., Qiu, D. (2025). Agentic Software Engineering: Foundational Pillars and Research Roadmap. arXiv:2509.06216 ↗ – SE für Menschen und SE für Agents, Briefing-Dokumente, Consultation Request Packs, Merge-Readiness Packs.
8. 8.Böckeler, B., Fowler, M. (2026). Harness Engineering for Coding Agent Users. martinfowler.com ↗ – Praktiker-Artikel: Agent = Modell + Harness.

Weiterlesen im PM Lab

Verwandte Deep Dives – aus demselben Pillar und den angrenzenden Phasen.

Passende Activities aus dem Playbook

Vom Beitrag direkt in die Praxis: Diese Activities setzen die Konzepte mit Teklens um.