PaperlayerView exact revision on arXiv

Source-linked AI summary

Spec-Driven Development for Agentic Software Engineering: Harnessing Human-Agent Teamwork

Jessica Diaz, Joaquin Gayoso, Andrea Cimminio, Jorge Perez

arXiv:2609.00252v1cs.SE

TL;DR

The paper addresses the lack of established terminology and evidence for team-scale agentic software engineering. Through a conceptual framework, it characterizes Spec-Driven Development, its harness, and recurring human–agent roles, while concluding that individual productivity alone does not determine team performance.

  • Problem

    The field lacks established terminology and agreed vocabulary, while increased individual productivity alone may not determine improved team performance.

  • Method

    The paper develops a conceptual socio-technical characterization of Spec-Driven Development and the methodological harness governing agent behavior at team scale.

  • Results

    The article characterizes the methodological harness governing agent behavior at team scale and identifies recurring human–agent interaction patterns.

  • Takeaways & Limitations

    Individual productivity alone does not determine whether increased productivity translates into improved team performance.

  • Takeaways & Limitations

    The work proposes a conceptual socio-technical framework rather than an empirical evaluation, and whether SDD mitigates the productivity paradox requires further validation.

Abstract

from arXiv · show

Context: Software engineering is moving from AI-assisted practices like vibe coding, in which assistants accelerate individual developers, towards Agentic Software Engineering (ASE), in which autonomous agents are delegated goal-level tasks. However, industry reports a productivity paradox: as individual productivity increases, team throughput, review capacity, and stability degrade because team-scale software engineering discipline is neglected. Objective: This paper aims to establish the conceptual and methodological foundations of Spec-Driven Development (SDD) as an enabling discipline for ASE at team scale and characterize the harness, i.e., the technical and methodological mechanisms through which teams govern agent behavior. Method: We conducted a conceptual analysis drawing predominantly on gray literature, including ASE vision and roadmap papers, practitioner reports, talks, and tooling, because peer-reviewed evidence and a shared academic-industrial vocabulary are not yet established. Results: Using a comparative characterization of the paradigm progression as conceptual framing, the article presents (i) a socio-technical model of SDD in which specifications act as the contract substrate between humans and agents; (ii) an operational characterization of the harness, distinguishing the technical harness around the agent from the methodological harness around the team, with worked examples; and (iii) a typology of five human--agent interaction patterns through which the human role is redefined. Conclusion: We conclude that SDD reconstitutes, in specification-centric form, the contracts that vibe coding dissolves: accountability, verifiability, and transferability. Given the immaturity of the evidence base, this work is presented as a first step toward academic-industrial consensus rather than a validated theory, and outlines a research agenda for future empirical validation.

1 Introduction

Software engineering is shifting from assistant-supported coding toward autonomous agents, exposing a productivity paradox in which faster individual work does not reliably improve team outcomes. The paper frames Spec-Driven Development and a team-level harness as governance mechanisms for making this transition workable.

  • Paradigm transition: Three distinct development models coexist: traditional or Agile development with light GenAI assistance, vibe coding, and ASE with goal-level task delegation.These models impose different demands on team structure, artifact discipline, and governance.
  • Productivity paradox: Higher AI adoption was associated with reduced delivery performance and greater team instability in 2024, while 2025 throughput associations reversed but instability persisted.DORA summarized the broader pattern as AI amplifying what a team already has rather than fixing the team.
  • Productivity paradox: Across 211 million changed lines, refactoring fell from 25% to below 10% while duplicated code blocks increased eightfold, indicating maintainability degradation alongside delivery acceleration.The paper connects these downstream effects to unchanged review, verification, integration, and coordination capacities.
  • Paradigm transition: Vibe coding emphasizes rapid individual production through conversational interaction but often leaves limited traceability, rationale preservation, and reusable artifacts.This creates a contrast with agentic work, where humans orchestrate and verify delegated tasks.
  • Spec-Driven Development: SDD makes specifications the canonical, version-controlled contract from which code, tests, documentation, and infrastructure are derived with traceable origins.The paper positions specifications as the contract substrate between humans and agents.
  • Harness: The harness comprises technical mechanisms around the agent and methodological mechanisms around the team for translating agent capabilities into meaningful team-scale outcomes.The paper extends the practitioner notion of Agent = Model + Harness to the team level and connects it to SDD.
  • Contributions: The paper contributes a socio-technical SDD model, an operational harness characterization with worked examples, and five human–agent interaction patterns redefining the human role.It presents these contributions as a structured synthesis intended to support future empirical work.

2 Background: From Agile to Agentic

Software engineering progresses from team-centered Agile through AI-assisted and conversational practices toward autonomous agents, changing how work, cognition, accountability, and coordination are organized. The paper frames SDD as a specification-centered response that restores team-scale contracts for ASE.

  • Paradigm progression: The comparison examines four paradigms across unit of work, primary artifact, locus of cognition, accountability, and team topology.The transition toward vibe coding and ASE changes the socio-technical structure of software development teams.
  • Agile: Agile coordinates small, persistent human teams through shared artifacts, stable structures, explicit review, and shared responsibility.Its review practices assume human-authored code evolving at a human pace.
  • GenAI-augmented SE: GenAI-augmented SE accelerates sub-activities such as boilerplate generation and API recall while retaining Agile’s work unit, artifact, accountability, and topology.IDE assistants also create almost-correct code and context limitations because they lack accumulated cross-cutting knowledge.
  • Vibe coding: Vibe coding expands work toward whole features or systems, shifts cognition toward conversation, and makes accountability ambiguous as AI-authored code increases.It can be locally effective, with capable developers producing in hours what previously took days.
  • Vibe coding: At team scale, vibe coding is associated with non-reproducibility, non-auditability, non-transferability, review saturation, and noise scaling.Reviewers may face delays or reconstruct intent from diffs, while independently generated codebases diverge.
  • SDD and ASE: Under SDD, accountability becomes contractual against specifications, verification audits evidence, and onboarding reads specifications rather than code.The paper presents this as reconstituting teamwork contracts while exploiting AI agency at scale.

3 Research Methodology

The paper uses a qualitative multivocal literature review to synthesize emerging academic and gray-literature evidence on ASE, SDD, team governance, and human–agent interaction. Its interpretive synthesis develops harness mechanisms and five interaction patterns rather than statistically testing them.

  • Research design: The study adopts a qualitative constructivist perspective focused on structuring the semantic meaning of agentic models and human–agent interaction.A Multivocal Literature Review integrates formal literature with blogs, videos, white papers, and other gray literature.
  • Research questions: The review addresses which mechanisms constitute the team harness and which interaction patterns support effective human–agent collaboration under SDD.These questions also examine the role of specifications and the changing human role.
  • Search strategy: Searches covered academic databases and gray-literature domains because the field’s literature was scarce and fragmented.The formal search used a broad Agentic Software Engineering query because of the field’s novelty.
  • Search strategy: Sources included technical industry reports, specialized technical publications, whitepapers, and pioneering technical content creators.Examples include DORA, METR, Faros AI, Martin Fowler, LangChain Research, Andrej Karpathy, and MoureDev/Gentleman.
  • Selection process: The selection process applied inclusion criteria for agentic-paradigm and SDD relevance and excluded traditional-assistant, promotional, or irrelevant discussions.The review records source-level inclusion and exclusion counts and identified nine duplicates.
  • Analysis and synthesis: Evidence fragments were descriptively coded, compared across sources, and thematically synthesized into harness mechanisms and five interaction patterns.The resulting constructs are interpretive and not empirically validated findings.

4 Spec-Driven Development for Agentic SE

SDD is presented as a socio-technical discipline that makes specifications the authoritative contract between teams and agents. It separates durable norms, task intent, reusable procedures, and derived artifacts so agent work can be governed, reviewed, and traced.

  • Operational definition: SDD treats team commitments about workflow, artifact governance, and human–agent contracts as a socio-technical discipline for operating ASE at scale.Specifications anchor generated artifacts to originating intent and support implementation and validation assessment.
  • SDD commitments: SDD requires non-trivial changes to originate from written specifications version-controlled alongside code under review, audit, and rollback discipline.The specification is the canonical artifact from which humans or agents derive code, tests, documentation, and infrastructure.
  • Specification hierarchy: System specifications define durable architecture, conventions, domain models, and normative rules, while feature specifications define task-specific objectives, constraints, and acceptance criteria.Both levels must be present in the agent’s context.
  • Specification hierarchy: When only feature specifications are loaded, agents may produce functionally correct but architecturally inconsistent code; system specifications alone cannot ground the current task.The two specification levels therefore serve distinct but complementary roles.
  • Specification hierarchy: Skills are selectively loaded procedural capabilities, whereas system specifications are always-active normative constraints.Separating them prevents unnecessary context growth and avoids making mandatory rules dependent on skill loading.
  • SDD commitments: Specifications are design inputs rather than retrospective documentation: iterative proposal, application, and archive cycles surface ambiguity before implementation and preserve provenance.When specifications and artifacts disagree, teams amend the specification or re-derive the artifact rather than silently editing it.
  • Contract substrate: Specifications provide the contract substrate for agent consultation, output review, decomposition, escalation, merging, and evidence-based trust.The specification scopes what an agent must produce, while the working tree scopes where it may produce it.

5 Harnessing Agentic Capability: The Technical and Methodological Harness

The paper distinguishes a transient technical harness around each agent from a durable methodological harness owned by the team. Specifications and persistent shared knowledge form the methodological substrate for coordination, governance, and scalable human–agent collaboration.

  • Technical harness: The technical harness turns a text-generating model into an engineering actor through orchestration, tools, context management, memory, guardrails, and verification.Its components support file editing, execution, testing, repository queries, state continuity, permissions, and self-correction.
  • Knowledge management: Persistent shared knowledge lets later sessions build on prior artifacts, decisions, and outcomes instead of restarting from zero.Its benefits include compounding context, continuity across sessions and agents, reduced re-derivation, and fewer silent inconsistencies.
  • Two complementary harnesses: The technical harness is transient and depreciates as models improve, while the methodological harness accumulates intent, norms, and decisions and appreciates over time.The paper therefore recommends prioritizing durable team practices over tool selection.
  • Two complementary harnesses: The technical harness governs one agent in one session, whereas the methodological harness addresses team-level coordination, reproducibility, auditability, transferability, and review.The methodological harness consists of team-owned practices and artifacts centered on specifications.
  • Methodological harness: The methodological harness organizes eight mechanisms into knowledge management, production support, and governance functions.These mechanisms are presented with worked examples using a fictitious refund operation in an e-commerce payments service.
  • Knowledge management: Context engineering governs what an agent knows within a session, while persistent shared knowledge governs what teams and agents know across sessions.Persistent shared knowledge is identified as the key enabler of teamwork in this model.
  • Knowledge management: A team knowledge store must make information available across tools and boundaries; otherwise agents retain private memories and the team fragments.The paper illustrates continuity across session, tool, and agent boundaries as the criterion for team-owned work.
  • Knowledge management: Persistent shared knowledge amortizes decision re-derivation across sessions, reducing token and time costs while limiting silent inconsistency.The paper characterizes it as an organizational substrate for coherent work by stateless agent executions.

5.5 Harness 3: Executable specifications

Executable specifications make SDD contracts actionable by connecting requirements to tests, constraints, and downstream conformance checks. They also enable parallel candidate generation, isolated implementation, and evidence-based comparison at merge time.

  • Executable specifications: Under SDD, specifications are written for agent consumption and automated validation rather than human reading alone.This keeps specifications operationally connected to implementation and verification.
  • Executable specifications: Executable specifications make acceptance criteria testable, constraints checkable, and design decisions explicit for downstream conformance checks.Given–When–Then is presented as the canonical form for testable acceptance criteria.
  • Worked example: An explicit exactly-once refund criterion lets reviewers reject a race-prone candidate and compare the trade-offs of schema-based and lock-based alternatives.The comparison is possible because the specification states the required behavior rather than merely requesting refunds.
  • Parallel generation: Working trees isolate parallel agents at the file level while preserving shared history and remotes through a common object store.This prevents uncommitted edits and index locks from colliding while keeping creation near-instantaneous and disk use negligible.
  • Parallel generation: Working-tree isolation moves conflicts from silent active-work corruption to visible merge-time detection by standard tooling.The specification scopes what an agent produces, while the working tree scopes where it produces it.
  • Human role: The developer’s role shifts from writing one implementation to comparing and composing several acceptable implementations against a shared specification.The resulting skills are evaluative and combinatorial, including trade-off identification and component recombination.
  • Caveat: Working-tree isolation separates code but not runtime resources, so parallel agents may still share ports, databases, and external services.Those resources require additional separation through environment files, scratch databases, or port ranges.
  • Delivery discipline: Isolated branches can partition large changes into small, reviewable units, while delivery strategy and rollback boundaries become explicit harness decisions.The paper contrasts stacked mainline units with integration-branch delivery.

5.7 Harness 5: Normative specifications

Normative specifications encode the conventions, patterns, and prohibitions that every change must respect. Because they are always active, reviewed, versioned, and checkable, they turn tacit team knowledge into persistent agent guidance.

  • Normative specifications: Standing team conventions belong in always-loaded normative specifications rather than on-demand skills, because they must apply in every relevant session.The paper distinguishes declarative norms from procedural skills loaded only when needed.
  • Normative specifications: Normative specifications prescribe how every change must behave, complementing system specifications that describe the system’s durable architecture and models.They are materialized in an always-loaded rule file and govern behavior across sessions.
  • Normative specifications: Norms inherit SDD’s review and conformance discipline when added through reviewed pull requests, deprecated when obsolete, and checked for compliance.This frames institutional memory as explicit, machine-readable guidance within the specification substrate.
  • Worked example: A repeated human correction can become a normative clause paired with a lint sensor, allowing agents to self-correct before human review.The example turns repeated exception-handling corrections into a checked service-layer rule.
  • Human consultation: Scoped consultation replaces continuous supervision by pausing agents at unresolved decisions and recording the human resolution against the relevant specification.Consultation occurs before the fact, while review evaluates work afterward.
  • Human consultation: A consultation request includes the unresolved question, considered options, relevant specification clauses, and consequences, so later agents need not repeat the question.The mechanism grounds the Consultation Request Pack in the shared specification substrate.

5.9 Harness 7: Evidence-backed acceptance

Evidence-backed acceptance changes completion from merging a pull request to demonstrating conformance through a structured evidence bundle. Integrated harness mechanisms connect executable specifications, parallel generation, autonomy calibration, norms, consultation, and persistent knowledge.

  • Evidence-backed acceptance: Under SDD, completion is a structured evidence bundle demonstrating that each item of evidence discharges a clause of the originating specification.This makes audit tractable and changes review from broad code reading to targeted evidence inspection.
  • Evidence-backed acceptance: Merge-readiness under SDD refers every acceptance dimension—functionality, verification, maintainability, rationale, and auditability—to the originating specification.This specification referent is the paper’s addition to the proposed Merge-Readiness Pack.
  • Evidence-backed acceptance: An evidence pack can combine executed acceptance tests, CI outputs, design rationale, consultation records, specification versions, and normative rules.The refund example maps evidence to acceptance, ownership, API-conformance, rationale, and auditability requirements.
  • Evidence-backed acceptance: Evidence-focused review lets reviewers audit whether the contract is discharged and investigate specific artifacts only when evidence is weak.The paper presents this as less cognitively demanding per artifact and as a way to address the review bottleneck structurally.
  • Autonomy calibration: Autonomy is calibrated explicitly and revisably by task class rather than granted or denied globally.The paper frames autonomy levels as versioned team decisions supported by workflow evidence and review outcomes.
  • Integrated harness: The harness works as an integrated system in which specifications, evidence, isolation, autonomy calibration, norms, consultation, context, and persistent knowledge reinforce one another.Persistent knowledge closes the loop by allowing subsequent sessions, agents, and teammates to begin where prior work ended.
  • Adoption boundary: Fragmented harness adoption provides only a fraction of the benefit while retaining most discipline costs, and the paper links partial ungoverned adoption to degraded team outcomes.The authors therefore frame adoption as a staged organizational process for future study.
  • Conceptual unification: A rule file can simultaneously materialize the system specification, guide agent behavior, and carry team norms as one reviewed artifact.This unifies artifacts that practitioner discourse often treats as separate.

6 Human–Agent Interaction Patterns and the Redefinition of Human Roles

SDD organizes human–agent work around five recurring interactions on a shared specification substrate, shifting human effort from code production toward orchestration, specification, and verification.

  • Interaction patterns: Five recurring patterns—briefing, consultation, review, norm encoding, and orchestration—form a continuous collaboration cycle centered on shared specifications.Specifications are created, interpreted, validated, enriched, and reused across agent executions.
  • Interaction patterns: Briefing translates human intent, constraints, and edge cases into a structured specification that agents operate under contractually.The human is responsible for articulating properties such as idempotence rather than relying only on examples.
  • Interaction patterns: Consultation lets agents suspend work and request scoped, recorded decisions, requiring rapid human context loading and team routing rules.The pattern is agent-initiated and bounded, with response-time discipline needed to prevent unanswered requests from blocking progress.
  • Interaction patterns: Review has humans audit evidence packs against originating specifications, supported by automated quality gates that produce the evidence.The human reads evidence and selectively investigates weak support rather than re-deriving correctness from scratch.
  • Interaction patterns: Norm encoding turns recurring corrections into team-shared normative clauses, while orchestration composes multi-agent workflows with explicit autonomy and evidence requirements.The orchestrator controls flow, quality gates, and result synthesis while final responsibility remains human and code production is delegated.
  • Redefinition of human roles: Under SDD-governed ASE, human outputs become briefs, rules, workflow definitions, consultation resolutions, and evidence judgments, while code production is largely delegated.Roles redistribute toward upstream intent, architectural judgment, comparative evaluation, specification authoring, and evidence-based acceptance; team composition becomes a design variable in an N-to-N topology.

7 Traceability of the Synthesis

The paper makes its synthesis traceable through a representative mapping from source evidence to proposed mechanisms and interaction patterns.

  • Traceability: Table 4 provides representative traceability from reviewed source evidence to the paper’s synthesized mechanisms and interaction patterns.The authors state that the table is not exhaustive and that the full extraction matrix and source-selection material are in the replication package.

8 Discussion

The proposed framework predicts organizational benefits from SDD-governed ASE, but these predictions, risks, and broader claims remain subject to empirical validation and contextual limits.

  • Expected benefits: The framework predicts consistency, absorption, transferability, and compounding through shared context, evidence-backed acceptance, persistent knowledge, and declining supervision costs.These benefits are presented as theoretical predictions rather than empirically validated findings.
  • Expected benefits: Consistency is associated with normative specifications reducing stylistic and architectural divergence, while absorption addresses review bottlenecks through evidence-backed acceptance.Transferability uses specifications and persistent knowledge for onboarding and handover, and compounding reflects growth of the persistent context asset.
  • Risks and mitigations: Adoption risks include cost spirals, specification drift, platform lock-in, talent bifurcation, and cultural fracture, requiring governance and organizational responses.Proposed mitigations include cost accounting, drift detection and audits, platform-neutral formats, deliberate training, and change management.
  • Scope conditions: SDD is characterized as a governance discipline rather than a universal prescription, with lighter practices potentially more appropriate when exploratory requirements remain genuinely unknown.The appropriate degree of specification depends on work-product uncertainty, stability, and expected lifetime.
  • Limitations: The framework is a conceptual synthesis that has not been empirically validated, and whether SDD mitigates the productivity paradox remains an empirical question.Its operational details may date quickly as agent capabilities improve, while its proposed socio-technical principles are intended to remain stable across technological generations.
  • Limitations: The evidence base relies on recent, controversial terminology and motivating material skewed toward web, SaaS, and platform engineering, limiting transferability to other domains.Generalization to embedded, safety-critical, and scientific software has not been established, and results may not transfer under different definitions.

9 Research Agenda

The research agenda proposes empirical work across team dynamics, interaction patterns, competences, organizational adoption, and measurement to turn the framework into an evidence-based discipline.

  • Agenda overview: Five research lines address team dynamics, interaction-pattern validation, orchestration competences, organizational adoption pathways, and measurement frameworks.Figure 10 organizes these directions across human, team, and organizational levels, connected by interaction patterns and measurement.
  • Team dynamics: Team-dynamics studies should examine team reorganization, human-to-agent ratios, and responsibility distribution using qualitative methods such as grounded theory.The proposed interaction patterns and competences serve as sensitizing concepts to be challenged by data.
  • Interaction-pattern validation: Mixed-methods studies should test whether the five interaction patterns are complete, how they compose into workflows, and how they vary by domain and agent capability.Interaction logs, observation, and surveys are proposed for this validation.
  • Orchestration competences: Research on orchestration competences should investigate how engineers acquire specification literacy, comparative reading, orchestration, and norm articulation, and which educational interventions accelerate them.The agenda also asks how software-engineering curricula should incorporate specification literacy as a first-class skill.
  • Organizational adoption: Multi-case studies should characterize organizational adoption sequences, successful orderings, stalled adoptions, and whether partial adoption is worse than none.The paper does not propose an adoption or maturity model because available cross-organizational evidence is thin and largely self-reported.
  • Measurement frameworks: Measurement research should operationalize specification quality, evidence-pack completeness, normative-specification maturity, consultation latency, agent portfolio cost, and energy use.Existing team metrics such as DORA were designed for human-authored work.
  • From model to discipline: The framework is intended as a foundation for community efforts to validate, refine, or refute its assumptions rather than as a definitive methodology.The research directions are meant to transform the conceptual model into an empirically grounded engineering discipline.

10 Conclusion

The conclusion frames agentic software engineering as a socio-technical transition requiring specifications and governance to coordinate humans and autonomous agents. It presents SDD and the harness as conceptual foundations for team-scale collaboration, while treating the framework as provisional and empirically testable.

  • 10 Conclusion: Specifications become the primary coordination artifact between humans and autonomous agents, while governance determines whether individual productivity improves team performance.The conclusion frames this shift as a socio-technical reconfiguration rather than a change in model capability alone.
  • 10 Conclusion: The framework offers a coherent conceptual basis for understanding the transition and connects discussions across academic work, industrial practice, and emerging tools.The authors present this integrated perspective as a way to organize previously fragmented discussions.
  • 10 Conclusion: The paper positions SDD as an enabling discipline for agentic software engineering and characterizes the methodological harness governing agent behavior at team scale.It also identifies recurring human–agent interaction patterns and the competences and organizational structures required to support them.
  • 10 Conclusion: The authors describe the framework as a conceptual socio-technical framework rather than a validated engineering methodology because the phenomenon and evidence base remain immature.They present it as a set of falsifiable hypotheses motivating future empirical research.
  • 10 Conclusion: The central research challenge is designing socio-technical systems that enable effective, safe, and scalable human–agent collaboration.The conclusion links this challenge to converting individual AI productivity into sustainable improvements in team and organizational performance.
  • 10 Conclusion: The framework is intended as a foundation that the community can build on, validate, refine, and challenge rather than as a final account of agentic software engineering.This positions the conclusion as an invitation to continued empirical and conceptual development.

Declarations

The authors report no conflict of interest and make the synthesis materials available through a Zenodo replication package.

  • Declarations: The authors declare that they have no conflict of interest.
  • Declarations: The replication package contains the source-selection material and extraction matrix used to support the reported synthesis.
  • Declarations: The replication package is deposited in Zenodo under DOI https://doi.org/10.5281/zenodo.22151221.
Loading 2609.00252v1…