diff --git a/docs/explanation/agentic-ai-in-the-software-development-model.md b/docs/explanation/agentic-ai-in-the-software-development-model.md new file mode 100644 index 0000000..b83e83c --- /dev/null +++ b/docs/explanation/agentic-ai-in-the-software-development-model.md @@ -0,0 +1,139 @@ +# Agentic AI in the Software Development Model + +This page explains how agentic AI fits into the Software Development Model, and why. It does not tell you how to set up an agent. It gives you a way to think about what agents change and what they leave alone. + +A note on how to read it. Some statements come from studies or named practitioners. Others are interpretation: the research suggests them, but nobody has tested them on a whole team. The text marks the difference. + +## The short version + +An agent is a tool inside the components of the model. It is not a new participant, and it does not replace a focus area. + +The research points to one pattern. Agents are good at turning an agreed decision into an artefact. They are weak at reaching the decision. The model has the same split built in. Relationships between components, such as "formulate" and "automate", are mostly transformations. Relationships from a person into a component, such as "presents rules and examples", are mostly decisions. + +So the collaboration between the Domain Expert and the Software Engineer stays. The Domain Expert gains leverage and load. The Software Engineer spends less time implementing and more time specifying and verifying. The central tension is speed against shared understanding. + +## Why the agent is not a third person + +The model has two people. The Domain Expert owns the product vision and brings domain knowledge. The Software Engineer delivers software in small, high-quality steps. The [glossary](../../CONTEXT.md) defines terms by purpose, not by tooling. + +An agent does not hold domain knowledge. The research found that agents fill gaps with plausible assumptions ([Böckeler](https://martinfowler.com/articles/pushing-ai-autonomy.html)). Fowler and Joshi make a related point. The domain model and its vocabulary emerge where the functional domain meets the solution domain, so domain experts cannot work in isolation ([Conversation: LLMs and Building Abstractions](https://martinfowler.com/articles/convo-llm-abstractions.html)). + +That fits the model. The Software Engineer "obtains domain knowledge" from the Product Brief and "identifies functional gaps or inconsistencies" in the Specification Workshop. Both edges assume a person who can ask a question and hear the answer. An agent can draft text. It cannot stand in for that exchange. + +## The five focus areas, in the model's flow + +The model flows from Align and Understand into two separate paths, BDD and DDD. Each path feeds XP: BDD through Acceptance Tests and DDD through the domain model. XP then leads on to Lean Product Development. The same pattern shows up in each focus area. + +### Align and Understand + +The Domain Expert "presents Product Feature" to the Product Brief. Domain Discovery "creates" the Product Backlog. + +Agents can draft user stories quickly. Two offline studies found that the stories read well, but each found a different weakness. In one, the stories were less diverse than stories written by people and met acceptance criteria less often ([Quattrocchi and others](https://arxiv.org/abs/2507.15157)). In the other, they were less independent and less unique ([Sakib and others](https://arxiv.org/html/2603.28163)). + +Independence matters here. A Product Backlog is useful because its items are small and can be ordered on their own. The research suggests that agents speed up the writing of items but not the judgement that makes them good. That reading is interpretation. The studies did not involve a live team. + +A second effect follows from cheap building. Marty Cagan writes that AI prototyping makes it easy to build many prototypes a week, and that "product sense" is now the hard part ([Build to Learn vs Build to Earn](https://www.svpg.com/build-to-learn-vs-build-to-earn/)). Practitioners at QCon London 2026 reported teams running short of well-qualified work ([InfoQ report](https://www.infoq.com/news/2026/03/qcon-london-foxwell-dev-teams/)). Both are practitioner accounts, not controlled studies. + +The model does not say how a Domain Expert should use agents. The research suggests a useful distinction. An agent can build a throw-away prototype to learn during Domain Discovery. Production work still goes through the rest of the model. The Product Brief matters more, because it frames and constrains what anyone, human or agent, is asked to build. + +A conversation is also not a document. The "spread domain knowledge" edge describes knowledge moving between people. An agent that turns a brief into a story map spreads text. It does not spread understanding. + +### BDD + +The Domain Expert "presents rules and examples" in the Specification Workshop. The workshop leads to Features ("formulate"). Features lead to Acceptance Tests ("automate"), which "guides code implementation" in Pair Programming. + +The formulation and automation steps suit agents, with review. Three studies looked at generated Gherkin, and each found something different. In one, evaluators rated it mostly relevant and clear, but it also contained omissions and hallucinations, and the authors called it draft material that needs human review ([Hassani and others](https://arxiv.org/html/2508.20744v2)). In another, organising generation by epic gave better expert ratings than a plain prompt ([Siddeeq and others](https://arxiv.org/abs/2607.01980v1)). In an industrial case, most scenarios were found helpful, but only 60% of generated test cases were usable as they came ([Ferreira and others](https://arxiv.org/abs/2504.07244)). + +Nobody measured the discovery conversation itself. No study was found of Example Mapping with an LLM in the room. This is a real gap. + +What we do have is the stated intent of BDD. Aslak Hellesøy, who created Cucumber, argued that it is not a testing tool. It "was born out of the frustration with ambiguous requirements and misunderstandings" between the people who order software and those who deliver it ([The world's most misunderstood collaboration tool](https://cucumber.io/blog/collaboration/the-worlds-most-misunderstood-collaboration-tool/)). He wrote this in 2014, before agents. + +The link "creates shared understanding" is where this matters. If an agent writes the Features without the workshop, the Acceptance Tests can pass while the shared understanding is gone. The research suggests treating generated scenarios as input to the workshop, such as candidate examples to discuss, and not as its replacement. That is an inference from BDD's intent and from studies on comprehension. No study tested it on BDD teams. + +Acceptance Tests have a second role. Tests given up front improve the code that models generate. Agents also exploit tests they are allowed to edit. The research on this comes from the earlier [XP research](../research/xp/agentic-development-in-xp-comprehensive-research.md). The suggestion is that Acceptance Tests are where the Domain Expert's intent reaches the agent, so the agent should not rewrite them. + +Spec-driven development is a nearby idea. Thoughtworks places it in "Assess" and warns of lengthy specification files that are hard to review ([Technology Radar](https://www.thoughtworks.com/radar/techniques/spec-driven-development)). BDD specifications are small: a rule, a few examples, and a test that fails when behaviour is wrong. No study compares the two approaches directly. + +### DDD + +The Domain Expert "validates and categorizes subdomains". The Software Engineer "identifies strategically significant parts of the domain". Strategic Architecture leads by "collaborative modelling" to Software Design, then by "apply tactical patterns" to Code the Domain Model. + +In an industrial case study, an LLM did well on the first three steps of DDD: ubiquitous language, a simulated Event Storming and bounded contexts. The errors then built up, and the later artefacts for aggregates and architecture were impractical. The authors describe the LLM as a sparring partner ([Eisenreich and others](https://arxiv.org/abs/2603.26244)). A benchmark of domain modelling found that relationships were the weakest part, with much left out ([Chen and others](https://ieeexplore.ieee.org/document/10344012/)). That benchmark is known only from its abstract, so this page does not rely on its numbers. + +Two experiments shed light on the people side. One found that domain knowledge matters more than modelling skill when refining an LLM's model ([Silva Mercado and others](https://link.springer.com/article/10.1007/s10270-026-01414-5)). The other found that novices adopted about two-thirds of the incorrect classes in an LLM's first draft ([Bragilovski and others](https://link.springer.com/article/10.1007/s10664-026-10831-5)). + +There is a limit to state plainly. These studies used students and university participants. They did not use professional Domain Experts. The results may not transfer. + +With that caveat, the research suggests a reason why the model calls DDD "a creative collaboration of domain experts and software engineers". An agent's draft changes the Domain Expert's job from producing a model to correcting one. Correcting needs domain knowledge that only the Domain Expert holds. Drafts also anchor people, so one reading is that a draft works better as a check after the people have modelled than as a starting point. That ordering is interpretation, not a tested practice. + +DDD authorities offer positions here, not findings. Eric Evans said that a trained language model is a bounded context ([InfoQ report](https://www.infoq.com/news/2024/03/Evans-ddd-experiment-llm/)). Michael Plöd framed DDD as part of the answer to AI and posed open questions, such as whether context maps need rethinking ([talk abstract](https://www.innoq.com/en/talks/2026/05/ai-domain-driven-design/)). Treat these as open questions. + +The glossary in this repository shows one way the idea plays out. It writes the ubiquitous language down. For an agent, it also becomes context. + +### XP + +The chain runs from Pair Programming, through "write just enough code" to Test-Driven Development, through "push code to version control" to Continuous Integration. From there "deliver product increment" reaches Short Iterations. + +This is the focus area where agents write the most code, and it is also the control loop that keeps the output shippable. The [XP research](../research/xp/agentic-development-in-xp-comprehensive-research.md) covers it in depth. Its direction is that agents fit inside XP's feedback loops and do not replace them. Humans own the failing test. Continuous Integration, not the agent's own report, says whether the build is green. A pair or ensemble working with an agent keeps the knowledge sharing that an agent alone does not. + +The DORA research associates AI adoption with more throughput and also with less stable delivery ([2025 DORA report](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)). Working in small batches is named as an amplifier of the benefit ([DORA AI Capabilities Model](https://cloud.google.com/blog/products/ai-machine-learning/introducing-doras-inaugural-ai-capabilities-model)). This is why the model's habit of small steps matters more with agents, not less. + +There is an open question too. No controlled study of a whole XP team using agents exists. + +### Lean Product Development + +Short Iterations "visualize progress on" Informative Workspaces, "updates" the Knowledge Base and "gathers" Customer Feedback. The Domain Expert "validates product increments". + +**Flow.** In a field study of an enterprise mandate to double output, merged pull requests per person more than doubled. Review load per reviewer roughly doubled as well, and automated review overtook human review ([He and others](https://arxiv.org/abs/2607.01904)). The limiting factor moved from writing code to reviewing it and to supplying well-formed work. The research suggests that short iterations and small Product Increments matter more, not less. That argument is interpretation. No study examined iteration length with agents. + +**Visibility.** A controlled trial found experienced developers 19% slower with AI while they believed they were about 20% faster ([METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)). If perceived speed is unreliable, the choice of what an Informative Workspace shows becomes important. A board that shows only throughput can look healthy while stability and complexity get worse. + +**Knowledge.** Agent instruction files are a new kind of team knowledge. A large empirical study found that they change like configuration code, through frequent small additions ([Chatlatanagulchai and others](https://arxiv.org/abs/2511.12884)). Another found that they do not generally raise task success, though agents follow them. They help most for team-specific practices, not for overviews of the repository ([Gloaguen and others](https://arxiv.org/abs/2602.11988)). That matches the purpose of a Knowledge Base, which holds what only the team knows. + +**Feedback.** Agents can sort and summarise Customer Feedback at moderate accuracy ([Mallya and others](https://arxiv.org/abs/2510.23055)). Interpreting it is still a person's work. The workspace file draws no link from Customer Feedback back to Align and Understand. This is an observation about the diagram and not a suggestion. The research notes only that a faster feedback loop stays fast if a person closes it. + +## Tensions that run across the model + +### Speed against shared understanding + +This is the central tension. Thoughtworks calls the growing gap between a system and the team's understanding of it "cognitive debt" ([Technology Radar](https://www.thoughtworks.com/radar/techniques/codebase-cognitive-debt)). Studies of skill formation find that delegating work to AI reduces understanding of the result ([Shen and Tamkin](https://arxiv.org/abs/2601.20245); [Balepur and others](https://arxiv.org/abs/2607.26375)). Agents make the gap open faster. + +The model offers two kinds of component in response. The collaborative ones are Domain Discovery, the Specification Workshop, Strategic Architecture and Pair Programming. They are where shared understanding is made. The automated ones are Acceptance Tests, Test-Driven Development and Continuous Integration. They keep output honest. + +The research suggests a reading of this. The collaborative components act as a brake that keeps agent speed in line with what the team understands. The automated components act as a harness. This reading is interpretation. + +Prompts are not reproducible. Fowler describes an LLM as a non-deterministic abstraction, so storing a prompt does not guarantee the same result ([LLMs bring new nature of abstraction](https://martinfowler.com/articles/2025-nature-abstraction.html)). The lasting artefacts are the ones the model already names: the Product Brief, Features, Acceptance Tests, design documents, code and tests, and the Knowledge Base. + +### Where the effort moves + +Roles shift and do not disappear. The Domain Expert gains leverage, because building is cheap and product judgement steers it. The Domain Expert also gains load. Validation and well-formed work become the bottleneck. The practitioner evidence for the load is consistent, but no study measured it. + +The Software Engineer moves toward specifying and verifying. Dave Farley has said the role shifts toward defining the problem in greater detail, and that verification becomes the bottleneck ([Aviator podcast](https://www.aviator.co/podcast/engineering-discipline-dave-farley)). Two vision papers take related positions: specifications as the contract between humans and agents ([Diaz and others](https://arxiv.org/abs/2609.00252)), and a "whole of process" view of agentic software engineering ([Hoda](https://arxiv.org/abs/2510.19692)). These are positions and open questions. The first calls itself a first step, not a validated theory. + +### What stays and what changes + +| Focus area | What stays | What changes | +|---|---|---| +| Align and Understand | The Domain Expert owns the vision. Discovery is a conversation. | Drafting is cheap. Judgement and a supply of small items become the constraint. | +| BDD | The workshop, with examples agreed by people. | Formulation and automation can be drafted by agents and reviewed by people. | +| DDD | Collaborative modelling and validation of subdomains. | Early drafts are cheap. Later design decisions compound errors. | +| XP | Pairing, TDD and CI as feedback loops. | The agent drives. Humans own the failing test. | +| Lean | Small increments, visible progress, team knowledge. | The constraint moves to review. The Knowledge Base gains instruction files. | + +All of this table is interpretation. + +## Limits of the evidence + +- Most studies cover one activity, such as generating stories or Gherkin. None covers a product team using agents across the whole model. +- Many studies use students, offline datasets, or the authors' own researchers as raters. +- No study was found of Example Mapping or Event Storming with agents in a live team. +- The claim that the Domain Expert becomes a bottleneck rests on practitioner reports. +- Customer Feedback evidence covers classifying text, not changing what a team decides. +- The vision papers and the DDD authorities' talks pose questions. They do not report results. +- This page maps the evidence onto the model. That mapping is interpretation, and it does not propose changes to the model. + +## Further reading + +- [Research: Agentic AI in the Software Development Model](../research/agentic-ai-in-the-software-development-model-for-explanation-doc.md) holds the findings, confidence ratings and full citations behind this page. +- [Research: Agentic development in XP](../research/xp/agentic-development-in-xp-comprehensive-research.md) covers pairing, test-driven development, continuous integration, small batches and cognitive debt in depth. +- The [glossary](../../CONTEXT.md) defines the terms used here. diff --git a/docs/explanation/agentic-ai-in-the-software-development-model.md.validation.yaml b/docs/explanation/agentic-ai-in-the-software-development-model.md.validation.yaml new file mode 100644 index 0000000..7899962 --- /dev/null +++ b/docs/explanation/agentic-ai-in-the-software-development-model.md.validation.yaml @@ -0,0 +1,77 @@ +documentation_review: + document: docs/explanation/agentic-ai-in-the-software-development-model.md + classification: + type: explanation + confidence: high + signals: + - "Answers 'why' and 'what changes / what stays', not 'how'" + - "Discursive prose with trade-offs (speed vs shared understanding), context and alternatives (spec-driven development vs BDD)" + - "Sourced fact explicitly separated from interpretation" + - "No numbered steps, no commands, no parameter tables as backbone" + - "One small summary table (what stays / what changes) supports the prose; it is not the backbone" + validation: + passed: true + checklist_results: + - {item: "Addresses why, not what", passed: true, note: "Each focus area section gives reasoning and evidence for the role split"} + - {item: "Provides context and reasoning", passed: true, note: "Model relationship labels tie claims to the model"} + - {item: "Discusses alternatives", passed: true, note: "Spec-driven development versus BDD; draft-first versus model-first in DDD; conflicting evidence on context files"} + - {item: "No task steps", passed: true, note: "No instructions; only a note that agent set-up is out of scope"} + - {item: "Builds conceptual model", passed: true, note: "Decision versus transformation relationships; collaborative brake and automated harness"} + - {item: "Vision papers framed as positions", passed: true, note: "Diaz, Hoda, Evans and Plöd presented as positions or open questions"} + - {item: "Population limit stated", passed: true, note: "DDD section says students and university participants, not professional Domain Experts"} + - {item: "N16 numbers not relied on", passed: true, note: "States the benchmark is known only from its abstract; no figures quoted"} + - {item: "No proposed changes to the model", passed: true, note: "Missing Customer Feedback link stated as an observation only; limits section says so"} + - {item: "Glossary terms used exactly", passed: true, note: "focus area, component, Domain Expert, Software Engineer, Product Increment; building block not used for focus areas; container and view not used in prose"} + - {item: "Relative links resolve", passed: true, note: "../../CONTEXT.md, ../research/agentic-ai-...-explanation-doc.md and ../research/xp/agentic-development-in-xp-comprehensive-research.md all exist (checked with Glob)"} + collapse_detection: + clean: true + violations: + - type: "possible reference narrative (minor)" + location: "Section 'What stays and what changes' table" + severity: low + fix: "Table is five rows and restates the prose; acceptable as a summary. Remove it if it starts to grow into a lookup matrix." + notes: "Explanation content estimated at 95%+. No tutorial steps, how-to tasks or reference listings. No hybrid content." + quality_assessment: + accuracy: "high - claims trace to the approved research; relationship labels quoted exactly from workspace.dsl. Not independently re-verified against the external URLs." + completeness: "high - five focus areas in flow order, cross-cutting tensions, limits of evidence, further reading" + clarity: "good - short sentences (average 12.1 words), plain words; measured Flesch 55 (62 with glossary terms counted as one syllable), below the 70-80 gate. Terms such as 'Gherkin', 'bounded context' and 'ubiquitous language' pull it down; see measured." + consistency: "high - British spelling, model terms in prose, uniform heading and citation style; estimated 95%+" + correctness: "high - manual proofread, no known spelling errors; no automated spell checker run" + usability: "good - serves the 'understand the rationale' job; cross-links to research and glossary only, as no tutorials or how-tos exist yet" + overall: pass + gates_not_fully_met: + - "Flesch 70-80 not met: measured 55 with an approximate syllable-count script (62 with glossary terms as one syllable); the gap comes mostly from glossary terms that must be used exactly." + - "Spelling check is a manual proofread, not an automated run." + - "External source URLs were not fetched; they are copied from the approved research." + recommendations: + - priority: medium + action: "Run a calibrated readability tool and an automated spelling check (for example Vale) to confirm the script's score of 55, then decide whether to accept the readability gap caused by glossary terms." + rationale: "Readability was measured with an approximate script and spelling was checked by hand." + - priority: low + action: "When tutorials or how-tos exist, add forward links (for example 'Get hands-on at ...') in Further reading." + rationale: "DIVIO cross-reference guidance; no such documents exist yet." + - priority: low + action: "Add a link to the diagram site once a stable URL exists." + rationale: "Helps readers see the relationships quoted in the text." + verdict: approved +measured: + date: 2026-09-30 + words: 2433 + flesch_reading_ease: 55.0 + average_sentence_length: 12.1 + flesch_with_glossary_terms_as_one_syllable: 62.0 + note: "Approximate syllable-count script, not a calibrated tool. Sentences are already short; the gap to 70 comes mostly from the glossary's multi-word terms, which must be used exactly." +peer_review: + reviewer: nw-documentarist-reviewer + date: 2026-09-30 + verdict: APPROVED + iterations: 1 + gates: + type_purity: {result: pass, value: "95-98% explanation"} + flesch_70_80: {result: fail, value: "55 measured (reviewer estimate 55-65)"} + spelling: {result: pass, value: "no errors found in manual review; no automated checker run"} + links: {result: pass, value: "3 relative links resolve"} + style_consistency: {result: pass, value: "95%+"} + recommendations: + - {priority: medium, location: "Why the agent is not a third person, Fowler and Joshi sentence", fix: "Split into two sentences"} + - {priority: medium, location: "DDD section, the two experiments paragraph", fix: "Give each experiment its own shorter sentence"} diff --git a/docs/research/agentic-ai-in-the-software-development-model-for-explanation-doc.md b/docs/research/agentic-ai-in-the-software-development-model-for-explanation-doc.md new file mode 100644 index 0000000..efb57bf --- /dev/null +++ b/docs/research/agentic-ai-in-the-software-development-model-for-explanation-doc.md @@ -0,0 +1,359 @@ +# Research: Agentic AI in the Software Development Model (input for an explanation document) + +**Date**: 2026-09-30 | **Researcher**: nw-researcher (Nova) | **Confidence**: Medium-High | **Sources**: 60 (26 new, 34 reused from the XP research; average reputation 0.89) + +## Executive Summary + +Agentic AI fits into the Software Development Model as a tool *inside* its components, not as a new participant or a replacement for any focus area. Across all five focus areas the evidence shows the same pattern (X1). Agents are good at turning an agreed decision into an artefact: drafting user stories, formulating Gherkin, generating acceptance tests, drafting a glossary or first-cut domain model, writing code against tests, and classifying feedback. They are weak at reaching the decision. User stories come out fluent but less independent and less diverse (AU1). Domain models come out with good vocabulary but missing relationships, and errors compound in later design steps (DDD1). Gherkin comes out relevant and clear, but with omissions and hallucinations (BDD1). In `workspace.dsl` terms, agents speed up the component-to-component relationships ("formulate", "automate", "apply tactical patterns", "write just enough code"). The person-to-component relationships ("presents rules and examples", "validates and categorizes subdomains", "validates product increments") are where the model needs humans. + +What stays is the collaboration between the Domain Expert and the Software Engineer, and the evidence gives a reason why. Domain knowledge, not modelling skill, is what corrects an LLM's model. People also anchor on LLM drafts: novices adopted about two-thirds of an LLM draft's incorrect classes (DDD2, X2). BDD's creators define it as a conversation, not a testing tool, which makes generated scenarios a risk to the "creates shared understanding" relationship if they replace the Specification Workshop rather than feed it (BDD2). What changes is where effort goes. The Domain Expert gains leverage and load, because cheap building makes product judgement and a supply of small, well-formed backlog items the constraint (AU2, L1). The Software Engineer's weight shifts from implementing towards specifying and verifying (X3). The XP control loop, the Acceptance Tests that guide implementation, and Lean's short iterations and informative workspaces become the harness that keeps faster output aligned and stable (XP1, L1, L2). Agent instruction files join the Knowledge Base as a new kind of team knowledge. They are followed, but they do not generally raise task success, so their value lies in team-specific knowledge rather than generic overviews (L3). + +The central tension for the explanation document is speed versus shared understanding (X4). Evidence for each focus area comes mostly from studies of single activities, often with students or offline datasets. No study was found of a product team using agents across the whole model, of Example Mapping with an LLM, or of Event Storming with agents in a live team (Knowledge Gaps). The mapping onto the model is therefore interpretation built on activity-level evidence, and is labelled as such throughout. + +## Research Methodology + +**Scope and purpose**: input for an explanation-type document (Diátaxis/DIVIO) on how agentic AI fits into the Software Development Model described by `workspace.dsl` and `CONTEXT.md`. The emphasis is on the "why": rationale, trade-offs, what changes, what stays, and tensions. It is not a how-to. + +**Reuse and extend**: the earlier XP research (`docs/research/xp/agentic-development-in-xp-comprehensive-research.md`, sources S1–S69) already covers XP practices, DORA, METR, TDD with agents, pairing and ensembles, CI, small batches and cognitive debt. Those findings are cited here as "XP research [Sn]" and are not re-searched. Their full citations are carried over into Full Citations. New sources are numbered N1 onwards and target the four thinly covered focus areas (Align and Understand, BDD, DDD, Lean Product Development) and the whole-model view. + +**Search strategy**: web searches and page fetches on arXiv (requirements engineering with LLMs, user-story generation, Gherkin generation, acceptance-test generation, LLM domain modelling, Domain-Driven Design with LLMs, context files for coding agents, feedback analysis), the Thoughtworks Technology Radar, martinfowler.com, InfoQ, cucumber.io and the originating authors of product discovery (SVPG). Every newly cited URL was fetched and read at least at abstract level. + +**Source selection**: trusted domains from `.nwave/trusted-source-domains.yaml`. Originating-organisation sources outside the list (svpg.com for Marty Cagan's product-discovery position, cucumber.io for the Cucumber creators' position) are admitted as primary sources for the authors' own positions, with reputation 0.8 and the reason stated in Source Analysis. No excluded domains were used. + +**Labelling**: each finding separates *Evidence* (sourced fact) from *Interpretation for the model* (the researcher's mapping onto focus areas, components and relationships). The mapping does not propose changes to the model. + +**Verification codes**: V = full text or full page read; A = abstract or abstract-page summary read (the fetch tool returns a summary of the page, so quotations marked as verbatim are those the tool reported as verbatim). + +## Findings + +### Align and Understand + +The focus area's components are Product Brief, Domain Discovery (User Story Map, Event Storming) and Product Backlog. The Domain Expert "presents Product Feature" to the Product Brief; the Software Engineer "obtains domain knowledge" from it; Domain Discovery "creates" the Product Backlog, which feeds the Specification Workshop ("collaborative requirement specification") and Strategic Architecture ("problem decomposition"). The container relationship to DDD is "collaborative domain modelling". + +#### Finding AU1: LLMs can draft user stories of comparable surface quality to humans, but with less diversity, less independence and lower acceptance-criteria fit +**Evidence**: Quattrocchi, Pasquale, Spoletini and Baresi replicated an interview-based elicitation experiment with 10 LLMs acting as analysts and one LLM as the customer, producing 13,958 user stories. LLMs matched humans on "coverage and stylistic quality" but showed "lower diversity and creativity" and "meet the acceptance quality criteria less frequently", regardless of model size; LLMs could reliably evaluate semantic quality when given "clear evaluation criteria" [N7]. Sakib et al. generated user stories from more than 1,000 health-app reviews with three LLMs; the best configuration scored slightly above agile experts on readability and related criteria (mean 4.53 against 4.39), but LLM stories consistently scored lower on *independence* (0.26–0.28 against 0.32) and *uniqueness* (0.29–0.31 against 0.33), and the authors recommend "LLM-assisted drafting followed by human refinement" [N8]. The Thoughtworks Radar notes that when spec-driven tools produce PRDs or user stories "it's sometimes unclear who their intended user is" [N5], and Böckeler found a minor bug fix turned into "four user stories with 16 acceptance criteria" (XP research [S35]). +**Sources**: [N7] arXiv 2507.15157; [N8] arXiv 2603.28163; [N5] thoughtworks.com; XP research [S35] martinfowler.com +**Confidence**: Medium-High (two independent academic studies agree on the pattern "fluent but less diverse and less independent"; two practitioner sources agree on over-production). Transfer limit: both academic studies are offline generation tasks, not live backlog refinement with a team. +**Interpretation for the model**: A Product Backlog is valuable because its items are small, independent and ordered by the Domain Expert. The two properties LLM drafts are weakest on (independence, uniqueness) are exactly the ones that make backlog items sliceable and prioritisable. Agents can accelerate the *writing* of backlog items, but the Domain Discovery → "creates" → Product Backlog relationship rests on a conversation about the user journey, and that is not what the studies measured. + +#### Finding AU2: When building gets cheap, product discovery and the product person's judgement become the constraint +**Evidence**: Marty Cagan (who coined "product discovery") writes that with AI prototyping tools "10-20 prototypes (or prototype iterations) per week is easy for just about anyone", and that live-data prototypes can be made "dramatically faster and cheaper than ever before"; the hard part is "product sense" to evaluate what is learnt [N9]. He separates "building to learn" from "building to earn": production products must handle "scale, performance, fault tolerance, reliability, accuracy, privacy, security, operations, provisioning, internationalization and more", and he remains sceptical that generation tools will close that gap soon, citing "limitations of spoken language as a specification language" [N10]. At QCon London 2026, Hannah Foxwell reported teams running out of backlog because "developers are now producing features faster than product managers can supply well-qualified work" (XP research [S56]). DORA 2025 warns that without a user-centric focus "AI-assisted development teams may just be moving quickly in the wrong direction" (XP research [S4]). +**Sources**: [N9][N10] svpg.com; XP research [S56] infoq.com; XP research [S4] cloud.google.com (DORA) +**Confidence**: Medium-High (three independent organisations — SVPG, a QCon practitioner, DORA — converge on "direction-setting becomes the bottleneck"; none is a controlled study). +**Interpretation for the model**: The Domain Expert "owns and drives the product vision" (CONTEXT.md). Cheaper building does not reduce that role; it raises its load and its leverage. The Product Brief ("frame and constrain the project") becomes more important as a constraint on what agents are asked to build, and the Domain Expert may use agents to build throw-away prototypes during Domain Discovery (building to learn), while production increments still flow through BDD, DDD and XP (building to earn). Cagan's distinction is a useful vocabulary for the explanation document. + +#### Finding AU3: The evidence supports agents as drafting and synthesis aids in Align and Understand, with humans owning elicitation and decisions +**Evidence**: Quattrocchi et al. conclude that human oversight remains valuable "for elicitation activities requiring deeper contextual understanding" [N7]; Sakib et al. recommend hybrid drafting and refinement [N8]; Böckeler notes that spec-driven development leaves unclear "who should perform requirements analysis" (XP research [S35]); Böckeler's autonomy experiment showed agents silently filling business-logic gaps with assumptions (XP research [S14]). +**Sources**: [N7][N8] arXiv; XP research [S35][S14] martinfowler.com +**Confidence**: Medium (two academic and two practitioner sources, none measuring a live product team). +**Interpretation for the model**: The relationship "Product Brief → spread domain knowledge → Domain Discovery" describes knowledge moving between people. An agent that drafts a story map from a brief spreads text, not knowledge; the Software Engineer's "obtains domain knowledge" edge still needs the conversation with the Domain Expert. + +### BDD + +The focus area's components are Specification Workshop (Example Mapping), Features (Gherkin) and Acceptance Tests (Cucumber). The Domain Expert "presents rules and examples" and the Software Engineer "identifies functional gaps or inconsistencies" in the Specification Workshop; it "formulate[s]" Features, which are "automate[d]" into Acceptance Tests, which "guides code implementation" in Pair Programming. The container relationship BDD → XP is "creates shared understanding". + +#### Finding BDD1: LLMs generate syntactically valid, mostly relevant Gherkin and acceptance tests, but with omissions and hallucinations that require human review +**Evidence**: Hassani, Sabetzadeh and Amyot (University of Ottawa) had 10 evaluators assess 60 Gherkin specifications generated by two LLMs from food-safety regulations: 95% were rated mostly or fully relevant, 100% clear, 94.2% complete and 91.7% of assessments reported significant time savings; yet qualitative feedback identified recurring "omissions ... hallucinations ... and mixed intents", and the authors call the outputs "draft artifacts rather than authoritative statements" needing human-in-the-loop review [N3]. Siddeeq, Abbasi, Rasku, Zhang, Christophe, Mikkonen and Abrahamsson (107 requirements from the PURE dataset) found that organising generation by epic improved expert-rated correctness (4.61 against 4.14), executability (4.61 against 4.07) and completeness (4.31 against 3.50) over a naive LLM baseline [N2]. In an industrial case study (AST 2025), Ferreira et al. generated Gherkin from user stories and then Cypress scripts: 95% of scenarios were found helpful, but of the generated test cases only 60% were usable as-is, 8% needed minor fixes, 24% needed regeneration and 8% were discarded; they conclude LLMs help "with appropriate tooling and supervision" [N4]. +**Sources**: [N3] arXiv 2508.20744; [N2] arXiv 2607.01980; [N4] arXiv 2504.07244 (IEEE/ACM AST 2025) +**Confidence**: High that generation is useful but needs review (three independent academic groups). Evaluators in [N3] were students and in [N2] the authors' own researchers, which limits the claim about quality. +**Interpretation for the model**: The evidence supports agents in the Specification Workshop → "formulate" → Features and Features → "automate" → Acceptance Tests relationships, i.e. formulation and automation. None of these studies measured the *discovery* conversation itself. + +#### Finding BDD2: BDD's value is the conversation, not the Gherkin; generated scenarios risk reproducing the "Cucumber as a testing tool" failure +**Evidence**: Aslak Hellesøy, creator of Cucumber, argued (2014) that "If you think Cucumber is a testing tool ... you are wrong": it "was born out of the frustration with ambiguous requirements and misunderstandings between the people who order the software and those who deliver it"; when teams adopted it only for automation, scenarios became "imperative and lose their documentation value", "slow and brittle"; and "Your cucumber features should drive your implementation, not reflect it" [N6]. The evaluations in BDD1 measure the *artefact* (relevance, clarity, completeness), not whether the people involved share an understanding [N2][N3][N4]. Research on skill formation and comprehension shows that delegating work to AI reduces the user's understanding of the result (XP research [S38][S61]). +**Sources**: [N6] cucumber.io (Cucumber creator, pre-AI); [N2][N3][N4]; XP research [S38][S61] arXiv +**Confidence**: Medium. The "conversation is the point" position is authoritative for BDD's intent; the inference that generated scenarios erode it rests on analogy with the comprehension studies, not on a study of BDD teams. See Knowledge Gaps. +**Interpretation for the model**: The model already encodes this: the Specification Workshop is tagged as a product component, and both people have edges into it ("presents rules and examples", "identifies functional gaps or inconsistencies"). If an agent writes the Features without the workshop, the BDD → XP "creates shared understanding" edge loses its meaning even if the Acceptance Tests still pass. The explanation document can present agent-generated scenarios as an input *to* the workshop (candidate examples, edge cases to discuss), not as its replacement. + +#### Finding BDD3: Spec-driven development overlaps with BDD's goal but differs in size, audience and ownership; practitioners are sceptical of heavyweight specs +**Evidence**: The Thoughtworks Radar (ring Assess) defines spec-driven development as workflows that "begin with a structured functional specification, then proceed through multiple steps to break it down", typically spec → plan → implement; it warns "We may be relearning a bitter lesson — that handcrafting detailed rules for AI ultimately doesn't scale" and that some tools produce "lengthy spec files that are hard to review" [N5]. Böckeler found spec-kit output "very verbose and tedious to review", that agents often ignored specs, and drew a parallel with model-driven development (XP research [S35]). A pre-registered evaluation found a *short* (267-word) specification frame reduced defects in five models (XP research [S65]); tests given up-front improve generated code (XP research [S21][S22]). Cagan points to "limitations of spoken language as a specification language" [N10]. +**Sources**: [N5] thoughtworks.com; XP research [S35] martinfowler.com; XP research [S65][S21][S22] arXiv; [N10] svpg.com +**Confidence**: Medium-High (independent practitioner sources agree on the critique; academic sources agree small, executable specifications help). +**Interpretation for the model**: BDD in this model already is a form of specification before code, but its specifications are small (one rule, a few examples), agreed with the Domain Expert, and executable. That positions BDD as the model's answer to "what should the agent build", with a different trade-off from spec-driven tools: less text, more conversation, and a test that fails when the behaviour is wrong. This is interpretation; no study compares BDD and spec-driven development directly. + +#### Finding BDD4: Acceptance tests are the natural agent specification and the artefact agents must not rewrite (reused) +**Evidence**: Reused from XP research: tests given up-front improve LLM correctness ([S21][S22]); agents exploit tests when they can edit them, and read-only tests reduce cheating to near zero ([S24]); Farley frames trust as coming "from executable specifications and continuous verification" ([S20]) and has long described acceptance tests as executable specifications that complement TDD ([S69]). +**Sources**: XP research [S21][S22][S24][S20][S69] +**Confidence**: High (reused; see XP research A1, A2, F3). +**Interpretation for the model**: The Acceptance Tests → "guides code implementation" → Pair Programming relationship is where the Domain Expert's intent reaches the agent. Protecting these tests from agent edits is how the model keeps the Domain Expert's authority over behaviour. + +### DDD + +The focus area's components are Strategic Architecture (Core Domain Charts, Context Maps), Software Design (Bounded Context Canvas, Aggregate Design Canvas, C4) and Code the Domain Model (tactical patterns, the "building blocks"). The Domain Expert "validates and categorizes subdomains"; the Software Engineer "identifies strategically significant parts of the domain". Align and Understand → DDD is "collaborative domain modelling". + +#### Finding DDD1: LLMs work as a sparring partner for the early, language-level steps of DDD, but errors compound in later design steps +**Evidence**: Eisenreich, Jusic and Wagner (industrial case study against requirements from the FTAPI enterprise platform, 2026) split DDD into five prompted steps: ubiquitous language, simulated Event Storming, bounded contexts, aggregates and technical architecture. "Steps 1 to 3 worked well, but the accumulated errors rendered the artifacts generated from Steps 4 and 5 impractical", because "minor errors or inaccuracies can propagate and accumulate"; glossaries and context maps were the useful outputs. They conclude "LLMs can enhance, but not replace, architectural expertise", acting as "a collaborative sparring partner for building actionable documentation" [N11]. Chen, Yang, Chen, López, Mussbacher and Varró (MODELS 2023) compared GPT-3.5 and GPT-4 on ten domain-modelling tasks with expert reference solutions; the best configuration reached F1 of 0.76 for classes, 0.61 for attributes and 0.34 for relationships, with higher precision than recall (what is produced is often right, much is missing), and they judge full automation impractical [N16; verified at search-abstract level only, publisher pages not fetchable]. Chen, Shen and He found that decomposing modelling into sequential sub-questions improved recall and F1 over a single prompt [N17]. +**Sources**: [N11] arXiv 2603.26244; [N16] IEEE MODELS 2023; [N17] arXiv 2410.09854 +**Confidence**: Medium-High (three independent groups; one industrial case, two benchmark studies; [N16] only partially verified). +**Interpretation for the model**: The pattern "good at vocabulary, weaker at relationships and structure, errors compound downstream" maps onto the DDD chain Strategic Architecture → "collaborative modelling" → Software Design → "apply tactical patterns" → Code the Domain Model. Agents help most at the start (drafting a glossary, candidate events, a first context map) and least where decisions about boundaries and aggregates accumulate. Low recall means an agent-drafted model silently leaves things out, which is the kind of gap the Domain Expert "validates and categorizes subdomains" edge exists to catch. + +#### Finding DDD2: Domain knowledge, not modelling skill, is what corrects an LLM's model; and people anchor on what the LLM proposes +**Evidence**: Silva Mercado, Ma, Cabot and colleagues (Software and Systems Modeling, 2026; 67 participants refining five models) found a human-in-the-loop question-and-answer refinement improved LLM-generated domain models "particularly for elements where LLMs typically struggle", and that "Domain knowledge is more critical than modeling expertise for successful refinement" [N18]. Bragilovski, van Can, Dalpiaz and Sturm (Empirical Software Engineering, 2026; 127 students deriving models from user stories) found that an initial ChatGPT model helped class identification in simple projects, but in the complex project the group with no initial model identified classes better; participants incorporated about 85% of the correct classes *and about 67% of the incorrect classes* from the initial model, and the authors warn this reliance "may limit creativity and hinder the deeper reasoning required to develop robust domain modeling skills" [N19]. Lee et al. (CHI 2025) found higher confidence in GenAI associated with less critical thinking (XP research [S40]). +**Sources**: [N18] Springer SoSyM; [N19] Springer EMSE; XP research [S40] ACM CHI +**Confidence**: Medium-High (two peer-reviewed experiments plus a large survey agree; participants were students or university participants, not professional Domain Experts). +**Interpretation for the model**: This is the strongest evidence found for why the model's DDD focus area is described as "a creative collaboration of domain experts and software engineers". An LLM draft shifts the Domain Expert's job from producing a model to correcting one, and correction depends on domain knowledge that only the Domain Expert holds. The anchoring result is a design reason for when to show an agent's draft: after the people have modelled (as a check), not before (as a starting point), especially in complex domains. This ordering is interpretation, not a tested intervention. + +#### Finding DDD3: Ubiquitous language and bounded contexts become context for agents; DDD authorities frame DDD as more relevant, not less +**Evidence**: Eric Evans (Explore DDD 2024 keynote, reported by InfoQ) said "a trained language model is a bounded context", that training a model "on a ubiquitous language of a bounded context makes it far more useful for specific needs", and encouraged practitioners to experiment and share results; he framed his remarks as a snapshot in a fast-moving field [N1]. Michael Plöd (INNOQ, author on DDD) framed a 2026 session as "DDD is not the problem of AI. DDD is the answer" and posed open questions: how Event Storming and Domain Storytelling output can guide agentic development, whether context maps need rethinking when agents consume and produce domain logic, and how ubiquitous language works when models "simulate understanding without true comprehension" [N20]. Thoughtworks' "AI-friendly code design" says good design for humans, including expressive naming and modularity, also benefits AI (XP research [S18]); Garg's "Knowledge Priming" and "Encoding Team Standards" patterns make tacit knowledge explicit for agents (XP research [S34]). +**Sources**: [N1] infoq.com; [N20] innoq.com (talk abstract; positions and questions, not findings); XP research [S18] thoughtworks.com; XP research [S34] martinfowler.com +**Confidence**: Medium for "DDD authorities see DDD as more relevant with LLMs" (two named DDD authorities plus two practitioner sources). Low for any claim that this *works*: these are positions and open questions, not evaluations. +**Interpretation for the model**: A glossary such as this repository's CONTEXT.md is the ubiquitous language written down; for agents it is also context. That gives the Software Design component's "naming to responsibilities" work a second audience. The open questions Plöd poses are honest knowledge gaps for the explanation document rather than settled answers. + +#### Finding DDD4: Teams keep the domain core human-steered; agent adoption without design steering raises complexity (reused) +**Evidence**: Reused from XP research: the SpareBank 1 mob kept writing domain-layer code themselves "to have full control" and used the agent at the edges ([S57]); Cursor adoption caused persistent rises in static-analysis warnings and code complexity ([S52]); agent code degrades over iterative extension ([S64]); Beck's agent "accumulated so much complexity that the AI completely stalled" ([S10]). +**Sources**: XP research [S57][S52][S64][S10] +**Confidence**: Medium (one practitioner report for the "domain core" choice; High for the complexity trend, see XP research A5, F6). +**Interpretation for the model**: The Code the Domain Model → "guides code implementation" → Pair Programming relationship is where DDD's building blocks (entities, value objects, aggregates) meet the agent. The evidence suggests the building blocks that express core-domain rules are the least suitable for unsteered generation, and generic or supporting subdomains the most. That is a mapping onto Strategic Architecture's core/supporting/generic distinction, and it is interpretation; no study tests it. + +### XP (reused) + +The XP focus area is covered in depth by the XP research; this section only restates the conclusions the explanation document needs, by reference. + +#### Finding XP1: Agents fit inside XP's feedback loops, not in place of its practices (reused) +**Evidence**: Summarised from XP research. Pair Programming: an agent covers the tactical benefits of pairing but not knowledge sharing; the evidence favours a human pair or ensemble navigating with the agent as driver (A3, B2, F2: [S30][S31][S42][S57][S58][S59][S60][S61]). Test-Driven Development: tests up-front improve generated code, but agents game editable tests, so humans own the red step (A1, A2: [S21][S22][S24][S25]). Continuous Integration: DORA associates AI with more throughput *and* more instability, and names small batches and version-control discipline as amplifiers; CI, not the agent's report, is the source of truth for green (A6, C1, C2, F5: [S2][S3][S4][S44][S46]). Shared understanding is the main thing under threat ("cognitive debt", B2: [S17][S38][S40]). +**Sources**: XP research, as listed +**Confidence**: High for the direction (see XP research, which rates most of these High or Medium-High); no controlled study of an XP team as a whole exists (XP research Gap 1). +**Interpretation for the model**: The XP chain Pair Programming → "write just enough code" → Test-Driven Development → "push code to version control" → Continuous Integration → "deliver product increment" → Short Iterations is the control loop that makes agent output shippable. For the whole-model view, XP is where the upstream focus areas (BDD's Acceptance Tests, DDD's Code the Domain Model, both "guide code implementation") meet the agent. + +### Lean Product Development + +The focus area's components are Informative Workspaces (boards, DORA/SAFe metrics), Short Iterations (one to two weeks), Knowledge Base (merged with Living Documentation, ADR 0002) and Customer Feedback. Short Iterations "visualize progress on" Informative Workspaces, "updates" the Knowledge Base and "gathers" Customer Feedback; the Domain Expert "validates product increments" and the Software Engineer "works in small steps". + +#### Finding L1 (Short Iterations, flow): Agents move the constraint from writing code to reviewing it and to supplying well-specified work +**Evidence**: In a longitudinal study of an enterprise "2x" mandate (802 developers, 196,212 PRs), per-capita merged PRs reached 2.09 times the baseline while "per-reviewer load roughly doubled and automated review overtook human review", with merge and revert rates stable (XP research [S54]). DORA's analysis of open-ended responses names a "verification tax" and a review burden from larger AI-generated change sets, and recommends to "enforce small batches" (XP research [S46]). Foxwell reports teams running out of well-qualified backlog (XP research [S56]). Agent success falls steeply with task length: near 100% on tasks of under four minutes of human time, under 10% on tasks over about four hours (XP research [S62]). +**Sources**: XP research [S54] arXiv; [S46] dora.dev; [S56] infoq.com; [S62] arXiv +**Confidence**: Medium-High (independent field study, research programme and practitioner report agree on the shift; the benchmark supports small units of work). +**Interpretation for the model**: Short Iterations are a batch-size and WIP control. With agents, the scarce resources in an iteration are human review, the Domain Expert's validation ("validates product increments") and well-formed backlog items, not typing. That argues for keeping iterations short and increments small rather than filling a two-week iteration with more agent output. It is a Lean argument (optimising a non-constraint does not raise throughput) applied to evidence from the sources above; no source studies iteration length with agents directly. + +#### Finding L2 (Informative Workspaces): What the workspace shows must include stability, rework and quality trends, because perceived speed is unreliable +**Evidence**: DORA 2025: AI adoption relates positively to throughput and product performance but negatively to delivery stability (XP research [S44]). METR's RCT found experienced developers 19% slower with AI while believing they were about 20% faster (XP research [S7]). A peer-reviewed difference-in-differences study found a transient velocity gain and persistent rises in static-analysis warnings and code complexity after Cursor adoption (XP research [S52]). DORA 2024 recorded a 7.5% rise in documentation quality alongside a 7.2% fall in delivery stability per 25% rise in AI adoption (XP research [S2]). +**Sources**: XP research [S44][S7][S52][S2] +**Confidence**: High (reused; independent research programme, RCT and peer-reviewed study). +**Interpretation for the model**: The Informative Workspaces component already names "DORA/SAFE metrics". Agents make the choice of what to make visible more consequential: a board that shows only throughput will show improvement while stability, review queues and complexity may be getting worse. The explanation document can present Informative Workspaces as the model's antidote to the perception gap. + +#### Finding L3 (Knowledge Base): Agent instruction files are a new, fast-changing kind of team knowledge; their value lies in non-standard, team-specific knowledge rather than repository overviews +**Evidence**: An empirical study of 2,303 agent context files in 1,925 repositories found they behave like "configuration code through frequent, small additions" rather than static documentation; they mostly cover test procedures (75.9%), implementation details (70.8%) and architecture (68.1%), and rarely security (14.8%) or performance (14.5%) [N12]. Gloaguen et al. found that "providing context files does not generally improve task success rates, while increasing inference cost by over 20% on average", that "repository overviews ... are not helpful", but that "instructions in the context files are well followed", concluding they "are useful for specifying non-standard coding practices" [N13]. A two-agent ablation on 17 real tasks found no measurable correctness effect of context strategy [N14]. Thoughtworks places "Curated shared instructions for software teams" in Adopt: "As soon as a prompt is refined, the entire team benefits" [N15]; Garg's "Encoding Team Standards" and "Context Anchoring" patterns make tacit knowledge explicit and keep decision records alive for agents (XP research [S34]). +**Sources**: [N12][N13][N14] arXiv; [N15] thoughtworks.com; XP research [S34] martinfowler.com +**Confidence**: High that context files are widely used and followed; Medium-High that they do not generally raise task success (two independent studies, one small); Medium on what content helps (one study's recommendation). +**Conflict**: Practitioner recommendation (Adopt [N15]) and measured task-success effect (null [N13][N14]) differ; see Conflicting Information. +**Interpretation for the model**: ADR 0002 merged Knowledge Base and Living Documentation because both are team knowledge. Agent instruction files and glossaries extend the same idea to a new reader: the agent. The evidence suggests the valuable entries are those only the team knows (conventions, domain terms, decisions), which is the Knowledge Base's purpose, while generic overviews add cost without benefit. Short Iterations "updates" the Knowledge Base; the "frequent, small additions" pattern fits that relationship. + +#### Finding L4 (Customer Feedback): LLMs can classify and summarise feedback at scale with moderate accuracy, but interpretation and prioritisation remain human work +**Evidence**: Mallya, Ferrari, Zadenoori and Dąbrowski evaluated five lightweight open-source LLMs on online user feedback: "moderate-to-high classification accuracy (F1 ~ 0.47-0.68)" and specification quality around 3 out of 5 in human evaluation [N21]. Sakib et al. found LLMs turned app reviews into readable user stories but with lower independence and uniqueness than expert-written ones [N8]. Martinez Montes, Feldt and colleagues, evaluating LLM-assisted reflexive thematic analysis for software engineering research, found evaluators preferred LLM-generated codes 61% of the time, but LLMs fragmented data, overlooked "deeper interpretive layers" and produced imprecisely defined themes, so they are "analytical assistants requiring expert oversight" [N22]. DORA names user-centric focus as an amplifier of AI benefit (XP research [S4]). +**Sources**: [N21][N8][N22] arXiv; XP research [S4] cloud.google.com +**Confidence**: Medium (three independent academic studies; offline datasets, not a product team's feedback loop). +**Interpretation for the model**: Short Iterations "gathers" Customer Feedback, and more increments reaching users means more feedback. Agents can make the gathering and first-pass sorting cheaper, but turning feedback into a changed Product Brief or reordered Product Backlog is the Domain Expert's judgement (Finding AU2). The loop Customer Feedback → (implicitly) Align and Understand is not drawn in `workspace.dsl`; agents make that feedback loop faster only if a person closes it. + +## Cross-cutting findings + +#### Finding X1: Across focus areas, agents help most in transforming an agreed decision into an artefact, and least in reaching the decision +**Evidence**: The pattern recurs across independent studies. Formulation and automation of agreed behaviour work well with review: Gherkin generation [N2][N3], acceptance-test generation [N4], user-story drafting [N7][N8], feedback classification [N21]. Early vocabulary work in DDD works; later decisions about boundaries and aggregates accumulate errors [N11][N16]. Coding the agreed behaviour works when tests exist and humans own them (XP research [S21][S24]). Fowler and Joshi separate "discovering abstractions", which "requires developer control and iteration", from "applying stable abstractions", where LLMs excel, and caution against "driving everything through prompts" [N23]. +**Sources**: [N2][N3][N4][N7][N8][N11][N16][N21][N23]; XP research [S21][S24] +**Confidence**: Medium-High (many independent sources point the same way, but each studies one activity; the cross-activity pattern is a synthesis). +**Interpretation for the model**: In `workspace.dsl`, the decision points are mostly the relationships that involve people: "presents Product Feature", "presents rules and examples", "identifies functional gaps or inconsistencies", "validates and categorizes subdomains", "identifies strategically significant parts of the domain", "validates product increments". The transformation steps are mostly component-to-component relationships: "formulate", "automate", "apply tactical patterns", "write just enough code", "push code to version control". A plain reading for the explanation document: agents accelerate the component-to-component edges; the person-to-component edges are where the model needs humans, and where agents are at most drafting aids. + +#### Finding X2: Domain knowledge held by people is the non-substitutable input; agents fill gaps in it with plausible assumptions +**Evidence**: In human-LLM domain modelling, "Domain knowledge is more critical than modeling expertise for successful refinement" [N18]. People adopt about two-thirds of an LLM draft's incorrect classes [N19]. Fowler and Joshi: "The domain model and its vocabulary emerge at the intersection of the functional domain and the solution domain. This is why domain experts with a narrow functional focus cannot work in isolation", and without an established vocabulary "the model has no concrete reference points and must guess at meaning" [N23]. Agents silently fill business-logic gaps with assumptions (XP research [S14]). Coding agents harm users' code comprehension (XP research [S61]) and AI use impairs conceptual understanding (XP research [S38]). +**Sources**: [N18][N19] Springer; [N23] martinfowler.com; XP research [S14][S61][S38] +**Confidence**: High (two peer-reviewed experiments, two further academic studies and two practitioner sources agree; the professional-team setting is not directly studied). +**Interpretation for the model**: CONTEXT.md defines the Domain Expert as the person who "brings domain knowledge into the model". This is the role the evidence says cannot be delegated to an agent, and Fowler and Joshi's quotation supports the model's insistence that the Software Engineer is also in the room (the Software Engineer "obtains domain knowledge" and "identifies functional gaps or inconsistencies"). The collaboration between the two roles, not either role alone, is what the agent lacks. + +#### Finding X3: Roles shift rather than disappear: the Domain Expert gains leverage and load; the Software Engineer moves toward specifying, steering and verifying +**Evidence**: Domain Expert side: Cagan says product people can build many prototypes a week and that "product sense" is now the hard part [N9]; Foxwell reports product managers unable to supply well-qualified work fast enough (XP research [S56]); DORA warns of "moving quickly in the wrong direction" without user focus (XP research [S4]). Software Engineer side: Farley, "our role will shift toward defining the problem in greater detail rather than hand-crafting the solution" and "verification becomes the bottleneck" (XP research [S20]); Laycock, "We need engineers to understand systems, not diffs" (XP research [S60]); Foxwell argues review must shift left to "specifications, test strategies and architecture" (XP research [S56]). Diaz, Gayoso, Cimminio and Perez frame specifications as "the contract substrate between humans and agents" in a vision paper that explicitly calls itself "a first step ... rather than a validated theory" [N24]. Hoda argues for a "whole of process" vision of agentic software engineering rather than a code-centric one (ICSE 2026 companion) [N25]. +**Sources**: [N9] svpg.com; [N24][N25] arXiv; XP research [S56][S4][S20][S60] +**Confidence**: Medium (consistent practitioner and vision-paper positions from independent organisations; no empirical study of role change in a product team). +**Interpretation for the model**: The model's two people and their edges stay; what each spends time on changes. For the Domain Expert, the Product Brief, the Specification Workshop and the validation of increments become more central because they steer faster building. For the Software Engineer, the weight moves from implementing within XP to specifying (BDD, DDD) and verifying (TDD, CI) around the agent. The model does not need a new person for the agent; the agent sits inside components as a tool, which is consistent with CONTEXT.md's rule that terms describe purpose, not tooling. + +#### Finding X4: The central tension is speed versus shared understanding, and the model's collaborative components are where it is resolved +**Evidence**: Thoughtworks defines codebase cognitive debt as "the growing gap between a system's implementation and a team's shared understanding of how and why it works" (XP research [S17]). The enterprise mandate study shows review load doubling and moving to automation (XP research [S54]). Diaz et al. describe a "productivity paradox": "as individual productivity increases, team throughput, review capacity, and stability degrade" [N24; vision paper, drawn from grey literature]. Fowler: LLMs are "a non-deterministic abstraction, so I can't just store my prompts in git and know that I'll get the same behavior each time" [N26]. Hellesøy: features "should drive your implementation, not reflect it" [N6]. +**Sources**: XP research [S17][S54]; [N24] arXiv; [N26] martinfowler.com; [N6] cucumber.io +**Confidence**: Medium-High that the tension is real (independent industry radar, field study and practitioner positions); Low for any quantified trade-off. +**Interpretation for the model**: Because prompts are not reproducible [N26], the durable artefacts of a team using agents are the ones the model already names: the Product Brief, the Features and Acceptance Tests, the Software Design documents, the code and its tests, and the Knowledge Base. Shared understanding lives in the collaborative components that produce them (Domain Discovery, Specification Workshop, Strategic Architecture's collaborative modelling, Pair Programming). The explanation document can frame the model's collaborative components as the brake that keeps agent speed aligned with what the team understands, and its automated components (Acceptance Tests, TDD, CI) as the harness that keeps agent output honest. + +#### Finding X5: What changes and what stays (synthesis table) +All content in this table is **interpretation** derived from the findings cited in each row. + +| Focus area | What stays (and why) | What changes with agents | Findings | +|---|---|---|---| +| Align and Understand | Domain Expert owns the vision; Domain Discovery is a conversation that spreads domain knowledge | Drafting of briefs, story maps and backlog items gets cheap; product judgement and a supply of small, independent items become the constraint; the Domain Expert can prototype to learn | AU1, AU2, AU3 | +| BDD | Specification Workshop with the Domain Expert; examples agreed by people | Formulation (Gherkin) and automation (step code, tests) can be agent-drafted and human-reviewed; Acceptance Tests become the agent's specification and must be protected | BDD1–BDD4 | +| DDD | Collaborative modelling; Domain Expert validates subdomains; ubiquitous language agreed by people | Glossary and first-cut models can be drafted; later design decisions compound LLM errors; the ubiquitous language becomes agent context; domain core stays human-steered | DDD1–DDD4 | +| XP | Pairing or ensemble, TDD, CI as feedback loops | Agent as driver; humans own the red step; CI as the source of truth; small batches more important | XP1 | +| Lean | Short Iterations, small increments, visible progress, team knowledge, customer feedback | Constraint moves to review and validation; workspace must show stability and quality trends; Knowledge Base gains agent instruction files; feedback triage gets cheaper, interpretation does not | L1–L4 | + +## Knowledge Gaps + +### Gap 1: No study of the Specification Workshop (Example Mapping, Three Amigos) with an LLM in the room +**Issue**: Evidence on BDD and LLMs concerns generating Gherkin and tests from existing requirements, not the discovery conversation itself. Whether an agent suggesting examples during Example Mapping improves or crowds out the conversation is unknown. | **Attempted**: arXiv and web searches for Example Mapping, Three Amigos and specification workshops with LLMs or ChatGPT; searches for AI-era positions from the Cucumber and BDD Books authors (Wynne, Rose, Nagy). No study and no trusted-domain AI-era position were found. | **Recommendation**: treat BDD2's "conversation is the point" as BDD's stated intent [N6] plus analogy with comprehension studies, and say so in the explanation document. + +### Gap 2: No study of product discovery or Domain Discovery (story mapping, Event Storming) with agents in a live team +**Issue**: User-story studies are offline generation tasks [N7][N8]; the Event Storming evidence is a simulated, prompted Event Storming in one industrial case [N11]. Cagan's position [N9][N10] is authoritative for product discovery but not empirical. | **Attempted**: arXiv (requirements elicitation, user-story generation), SVPG, InfoQ, martinfowler.com; searches for Event Storming with AI (only a workshop announcement and a talk abstract were found). | **Recommendation**: present the Align and Understand findings as Medium confidence and cite the Domain Expert's role from CONTEXT.md as the model's own position. + +### Gap 3: No evidence on what agents do to the Domain Expert's workload or availability +**Issue**: The claim that the Domain Expert becomes a bottleneck rests on practitioner reports [S56], DORA's user-centric-focus finding [S4] and Cagan [N9]; no study measures product-person time or decision latency in teams using agents. | **Attempted**: searches for product manager workload and AI agents on InfoQ, martinfowler.com and arXiv; only vendor and product-management blogs outside the trusted list were found (not used). | **Recommendation**: label as practitioner consensus. + +### Gap 4: Professional Domain Experts are absent from the domain-modelling studies +**Issue**: The anchoring and refinement studies [N18][N19] use students or university participants; Chen et al. [N16] use course examples. | **Attempted**: arXiv and Springer searches on LLM domain modelling. | **Recommendation**: state the population limit whenever the anchoring figures are quoted. + +### Gap 5: Plöd's and Evans's DDD positions are questions, not results +**Issue**: The DDD authorities found pose questions (do bounded contexts matter more, how does ubiquitous language work with LLMs) but report no evaluations [N1][N20]. Plöd's position is known only from a talk abstract on innoq.com. | **Attempted**: InfoQ, innoq.com, general searches for DDD with AI coding agents. | **Recommendation**: present as open questions in the explanation document. + +### Gap 6: Customer Feedback evidence covers classification of text, not closing the loop +**Issue**: Studies measure classification accuracy and story quality on public datasets [N8][N21][N22]; nothing was found on whether agent-assisted feedback analysis changes what a team decides or how fast. | **Attempted**: arXiv searches on LLM app-review analysis and thematic analysis. | **Recommendation**: keep L4 at Medium. + +### Gap 7: Iteration length, WIP limits and Kanban with agents +**Issue**: No trusted-domain study examines iteration length or WIP limits with agents; L1 infers from review-load, batch-size and task-length evidence. Search results on theory of constraints and Little's law with AI were personal blogs outside the trusted list (not used). | **Recommendation**: label L1's iteration argument as interpretation. + +### Gap 8: Carried over from the XP research +No controlled study of an XP team as a whole using agents; no study of ensembles with agents beyond experience reports; DORA 2025 numeric effect sizes not available (XP research Gaps 1, 2, 5). + +## Conflicting Information + +### Conflict 1: Do agent instruction files help? +**Position A**: Yes, adopt them — Thoughtworks places curated shared instructions in Adopt: "As soon as a prompt is refined, the entire team benefits" [N15] (0.8); Garg recommends encoding team standards (XP research [S34], 0.8); developers maintain them like configuration code [N12] (1.0). +**Position B**: They do not generally raise task success — "providing context files does not generally improve task success rates, while increasing inference cost by over 20%" [N13] (1.0); no measurable correctness effect in a two-agent ablation [N14] (1.0, single author, 17 tasks). +**Assessment**: Not fully contradictory. [N13] also finds instructions "are well followed" and useful "for specifying non-standard coding practices"; Position A is about consistency across a team, Position B about benchmark task success. For the explanation document: instruction files are a way to share team-specific knowledge (the Knowledge Base's purpose), not a performance lever, and generic overviews are waste. + +### Conflict 2: How good are LLM-generated requirements artefacts? +**Position A**: As good as or better than humans — LLM stories matched or exceeded expert stories on readability-type criteria [N8]; 95% of generated Gherkin rated relevant and 100% clear [N3]; 95% of generated scenarios found helpful [N4]. +**Position B**: Systematically weaker on what matters for agile backlogs — lower diversity, lower acceptance-criteria fit [N7]; lower independence and uniqueness [N8]; omissions, hallucinations and mixed intents [N3]; only 60% of generated tests usable as-is [N4]; relationships F1 0.34 in domain models [N16]. +**Assessment**: Both hold, and often in the same paper. Surface quality (fluency, format, relevance) is high; structural quality (independence, completeness of relationships, absence of invented detail) is weaker. Evaluator populations (students, the authors' own researchers) limit both positions. + +### Conflict 3: Does an LLM draft help people model a domain? +**Position A**: Yes — an initial model improved class identification in simple projects and relationship accuracy in both [N19]; human-in-the-loop refinement improves LLM models [N18]; early DDD steps "worked well" [N11]. +**Position B**: It can hurt — in the complex project, the group without an initial model identified classes better, and participants adopted about 67% of incorrect classes [N19]; later DDD steps became "impractical" [N11]. +**Assessment**: The same studies support both, and the difference is task complexity and position in the process. Drafts help on simple tasks and early steps; they anchor on complex ones. + +### Carried over +Productivity (faster or slower), AI code quality and security, and burnout effects remain contested; see XP research Conflicts 1, 2 and 4. + +## Source Analysis + +New sources (N1–N26), all accessed 2026-09-30. Verification: **V** = full text or full page read (via the fetch tool's page summary); **A** = abstract page read; **P** = search-result abstract only. + +| # | Source | Domain | Reputation (score) | Type | Verification | Cross-verified | Bias / note | +|---|---|---|---|---|---|---|---| +| N1 | InfoQ report of Evans, Explore DDD 2024 keynote | infoq.com | Medium-High (0.8) | industry news of a primary position | V | Partial | position, not evaluation | +| N2 | Siddeeq et al., Epic-organised vs requirement-aligned Gherkin | arxiv.org | High (1.0) | academic | A | Y | authors' own pipeline; author-researchers as raters | +| N3 | Hassani, Sabetzadeh, Amyot, From Law to Gherkin | arxiv.org | High (1.0) | academic quasi-experiment | V | Y | student evaluators | +| N4 | Ferreira et al., Acceptance test generation (AST 2025) | arxiv.org | High (1.0) | peer-reviewed industrial case | A | Y | single company | +| N5 | Thoughtworks Radar, Spec-driven development (Assess) | thoughtworks.com | Medium-High (0.8) | industry radar | V | Y | [Validation Warning] fetch reported "Vol. 34, November 2025"; Vol. 33 is November 2025 and Vol. 34 April 2026, so the volume is unverified | +| N6 | Hellesøy, The world's most misunderstood collaboration tool | cucumber.io | Medium-High (0.8)* | primary position of Cucumber's creator | V | Partial | pre-AI (2014); vendor of Cucumber | +| N7 | Quattrocchi, Pasquale, Spoletini, Baresi, Can LLMs generate user stories | arxiv.org | High (1.0) | academic | A | Y | LLM-simulated customer | +| N8 | Sakib et al., From reviews to requirements | arxiv.org | High (1.0) | academic | V | Y | — | +| N9 | Cagan, Build to Learn vs Build to Earn | svpg.com | Medium-High (0.8)* | primary practitioner (originator of "product discovery") | V | Y | sells product-management training | +| N10 | Cagan, Prototypes vs Products | svpg.com | Medium-High (0.8)* | primary practitioner | V | Partial | as N9 | +| N11 | Eisenreich, Jusic, Wagner, Automating DDD with a prompting framework | arxiv.org | High (1.0) | academic industrial case | A | Y | single case | +| N12 | Chatlatanagulchai et al., Agent READMEs | arxiv.org | High (1.0) | academic empirical | A | Y | — | +| N13 | Gloaguen et al., Evaluating AGENTS.md | arxiv.org | High (1.0) | academic empirical | A | Y (conflict) | — | +| N14 | Khatri, Do context files help coding agents? | arxiv.org | High (1.0) | academic preprint (single author, small) | V | Y | 17 tasks | +| N15 | Thoughtworks Radar, Curated shared instructions (Adopt) | thoughtworks.com | Medium-High (0.8) | industry radar | V | Y (conflict) | — | +| N16 | Chen, Yang, Chen, López, Mussbacher, Varró, Automated domain modeling with LLMs (MODELS 2023) | ieeexplore.ieee.org | High (1.0) | peer-reviewed | P | Y | IEEE and ResearchGate pages not fetchable; figures from search abstract | +| N17 | Chen, Shen, He, LLM-based domain modeling with question decomposition | arxiv.org | High (1.0) | academic | A | Y | — | +| N18 | Silva Mercado et al., Human-LLM collaborative domain modeling (SoSyM 2026) | link.springer.com | High (1.0) | peer-reviewed | A | Y | university participants | +| N19 | Bragilovski, van Can, Dalpiaz, Sturm, LLM-generated models and novice modelers (EMSE 2026) | link.springer.com | High (1.0) | peer-reviewed experiment | A | Y | students | +| N20 | Plöd, Was bedeutet AI für Domain-Driven Design? (talk abstract) | innoq.com | Medium (0.6)* | practitioner talk abstract | V | Partial | consultancy; questions not findings | +| N21 | Mallya, Ferrari, Zadenoori, Dąbrowski, From online user feedback to requirements | arxiv.org | High (1.0) | academic | A | Y | lightweight open models only | +| N22 | Martinez Montes, Feldt et al., LLMs in thematic analysis | arxiv.org | High (1.0) | academic | A | Y | research setting, not product feedback | +| N23 | Fowler, Joshi, Conversation: LLMs and building abstractions | martinfowler.com | Medium-High (0.8) | practitioner | V | Y | — | +| N24 | Diaz, Gayoso, Cimminio, Perez, SDD for agentic software engineering | arxiv.org | High (1.0) | vision paper (self-described not validated) | A | Partial | grey-literature basis | +| N25 | Hoda, Agentic SE beyond code (ICSE 2026 companion) | arxiv.org | High (1.0) | vision paper | A | Partial | — | +| N26 | Fowler, LLMs bring new nature of abstraction | martinfowler.com | Medium-High (0.8) | practitioner | V | Partial | — | + +\* **Outside the trusted list, scored by justification**: svpg.com is the publisher of Marty Cagan, who originated the term "product discovery"; used only for his own position (0.8, by analogy with martinfowler.com; commercial interest in training noted). cucumber.io is the publisher of Cucumber's creators; used only for their stated intent of BDD and Cucumber (0.8). innoq.com carries a talk abstract by Michael Plöd, an established DDD author; used only for the questions he poses (0.6, abstract only). No excluded domains were used. Vendor and product-management blogs seen in search results (productschool.com, productside.com, prodmgmt.world, personal blogs on theory of constraints) were not used. + +**Reused sources** (34 from XP research): S2, S3, S4, S7, S10, S14, S17, S18, S20, S21, S22, S24, S25, S30, S31, S34, S35, S38, S40, S42, S44, S46, S52, S54, S56, S57, S58, S59, S60, S61, S62, S64, S65, S69. Their reputation and verification are recorded in the XP research Source Analysis. + +**Reputation**: New sources: High (1.0) 17 (65%), Medium-High (0.8) 8 (31%), Medium (0.6) 1 (4%); average **0.92** (24.0 / 26). Reused sources: average 0.86 (29.2 / 34). All 60 cited sources: average **0.89** (53.2 / 60). + +## Full Citations + +### New sources (accessed 2026-09-30) +[N1] InfoQ. News report of Eric Evans's Explore DDD 2024 keynote on DDD and LLMs (title as given by the URL slug "Evans-ddd-experiment-llm"). infoq.com. 2024-03. https://www.infoq.com/news/2024/03/Evans-ddd-experiment-llm/. Accessed 2026-09-30. +[N2] Siddeeq, S., Abbasi, M., Rasku, J., Zhang, Z., Christophe, F., Mikkonen, T., Abrahamsson, P. "Epic-Organized vs. Requirement-Aligned Gherkin: An Empirical Evaluation of LLM-Based Acceptance Criteria Generation". arXiv:2607.01980. 2026-07-02. https://arxiv.org/abs/2607.01980v1. Accessed 2026-09-30. +[N3] Hassani, S., Sabetzadeh, M., Amyot, D. "From Law to Gherkin: A Human-Centred Quasi-Experiment on the Quality of LLM-Generated Behavioural Specifications from Food-Safety Regulations". arXiv:2508.20744v2. 2026-03. https://arxiv.org/html/2508.20744v2. Accessed 2026-09-30. +[N4] Ferreira, M., Viegas, L., Faria, J. P., Lima, B. "Acceptance Test Generation with Large Language Models: An Industrial Case Study". arXiv:2504.07244; IEEE/ACM AST 2025. 2025-04-09. https://arxiv.org/abs/2504.07244. Accessed 2026-09-30. +[N5] Thoughtworks. "Spec-driven development" (Assess). Technology Radar. https://www.thoughtworks.com/radar/techniques/spec-driven-development. Accessed 2026-09-30. +[N6] Hellesøy, A. "The world's most misunderstood collaboration tool". cucumber.io. 2014-03-03. https://cucumber.io/blog/collaboration/the-worlds-most-misunderstood-collaboration-tool/. Accessed 2026-09-30. +[N7] Quattrocchi, G., Pasquale, L., Spoletini, P., Baresi, L. "Can LLMs Generate User Stories and Assess Their Quality?". arXiv:2507.15157. 2025-07-20. https://arxiv.org/abs/2507.15157. Accessed 2026-09-30. +[N8] Sakib, S., Akhand, O. F., Tasneem, T., Ahmed, S. "From Reviews to Requirements: Can LLMs Generate Human-Like User Stories?". arXiv:2603.28163. 2026-03. https://arxiv.org/html/2603.28163. Accessed 2026-09-30. +[N9] Cagan, M. "Build to Learn vs Build to Earn". Silicon Valley Product Group. 2026-04-16. https://www.svpg.com/build-to-learn-vs-build-to-earn/. Accessed 2026-09-30. +[N10] Cagan, M. "Prototypes vs Products". Silicon Valley Product Group. 2025-11-07. https://www.svpg.com/prototypes-vs-products/. Accessed 2026-09-30. +[N11] Eisenreich, T., Jusic, H., Wagner, S. "Automating Domain-Driven Design: Experience with a Prompting Framework". arXiv:2603.26244. 2026-03-27. https://arxiv.org/abs/2603.26244. Accessed 2026-09-30. +[N12] Chatlatanagulchai, W., Li, H., Kashiwa, Y., Reid, B., et al. "Agent READMEs: An Empirical Study of Context Files for Agentic Coding". arXiv:2511.12884. 2025-11-17 (rev. 2026-08-09). https://arxiv.org/abs/2511.12884. Accessed 2026-09-30. +[N13] Gloaguen, T., Mündler-Sasahara, N., Müller, M. N., Raychev, V., Vechev, M. "Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?". arXiv:2602.11988. 2026-02-12 (rev. 2026-09-29). https://arxiv.org/abs/2602.11988. Accessed 2026-09-30. +[N14] Khatri, P. "Do Context Files Help Coding Agents? A Two-Agent Ablation Study on Real Repositories". arXiv:2607.27250. 2026-07-28. https://arxiv.org/html/2607.27250. Accessed 2026-09-30. +[N15] Thoughtworks. "Curated shared instructions for software teams" (Adopt). Technology Radar Vol. 34. 2026-04. https://www.thoughtworks.com/en-us/radar/techniques/curated-shared-instructions-for-software-teams. Accessed 2026-09-30. +[N16] Chen, K., Yang, Y., Chen, B., Hernández López, J. A., Mussbacher, G., Varró, D. "Automated Domain Modeling with Large Language Models: A Comparative Study". ACM/IEEE MODELS 2023, pp. 162–172. https://ieeexplore.ieee.org/document/10344012/. Search-abstract level only. Accessed 2026-09-30. +[N17] Chen, R., Shen, J., He, X. "A Model Is Not Built By A Single Prompt: LLM-Based Domain Modeling With Question Decomposition". arXiv:2410.09854. 2024-10-13. https://arxiv.org/abs/2410.09854. Accessed 2026-09-30. +[N18] Silva Mercado, J., Ma, Q., Cabot, J., Kelsen, P., Proper, H. A., Gavric, A., Schnellmann, M. "Human-LLM collaborative domain modeling: a human-in-the-loop framework and empirical assessment". Software and Systems Modeling. 2026-08-26. https://link.springer.com/article/10.1007/s10270-026-01414-5. Accessed 2026-09-30. +[N19] Bragilovski, M., van Can, A. T., Dalpiaz, F., Sturm, A. "The impact of LLM-generated models on novice domain modelers: a comparative experiment". Empirical Software Engineering 31, 96. 2026-03. https://link.springer.com/article/10.1007/s10664-026-10831-5. Accessed 2026-09-30. +[N20] Plöd, M. "Was bedeutet AI für Domain-Driven Design?" (INNOQ Fragezeit talk abstract). innoq.com. 2026-05-26. https://www.innoq.com/en/talks/2026/05/ai-domain-driven-design/. Accessed 2026-09-30. +[N21] Mallya, M., Ferrari, A., Zadenoori, M. A., Dąbrowski, J. "From Online User Feedback to Requirements: Evaluating Large Language Models for Classification and Specification Tasks". arXiv:2510.23055. 2025-10-27. https://arxiv.org/abs/2510.23055. Accessed 2026-09-30. +[N22] Martinez Montes, C., Feldt, R., Miguel Martos, C., Ouhbi, S., Premanandan, S., Graziotin, D. "Large Language Models in Thematic Analysis: Prompt Engineering, Evaluation, and Guidelines for Qualitative Software Engineering Research". arXiv:2510.18456. 2025-10-21. https://arxiv.org/abs/2510.18456. Accessed 2026-09-30. +[N23] Fowler, M., Joshi, U. "Conversation: LLMs and Building Abstractions". martinfowler.com. 2025-08-26. https://martinfowler.com/articles/convo-llm-abstractions.html. Accessed 2026-09-30. +[N24] Diaz, J., Gayoso, J., Cimminio, A., Perez, J. "Spec-Driven Development for Agentic Software Engineering: Harnessing Human-Agent Teamwork". arXiv:2609.00252. 2026-08-31. https://arxiv.org/abs/2609.00252. Accessed 2026-09-30. +[N25] Hoda, R. "Toward Agentic Software Engineering Beyond Code: Framing Vision, Values, and Vocabulary". arXiv:2510.19692; ICSE 2026 Companion. 2025-10-22 (rev. 2026-02-17). https://arxiv.org/abs/2510.19692. Accessed 2026-09-30. +[N26] Fowler, M. "LLMs bring new nature of abstraction". martinfowler.com. 2025-06-24. https://martinfowler.com/articles/2025-nature-abstraction.html. Accessed 2026-09-30. + +### Reused from XP research (citations carried over unchanged) +[S2] Google Cloud. "Announcing the 2024 DORA report". cloud.google.com. 2024-10-23. https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report. Accessed 2026-09-29. +[S3] Scrum.org. "DORA Report 2025 Summary (State of AI-assisted Software Development)". scrum.org. 2025. https://www.scrum.org/resources/blog/dora-report-2025-summary-state-ai-assisted-software-development. Accessed 2026-09-29. +[S4] Google Cloud / DORA. "Introducing DORA's inaugural AI Capabilities Model". cloud.google.com. 2025-09-23. https://cloud.google.com/blog/products/ai-machine-learning/introducing-doras-inaugural-ai-capabilities-model. Accessed 2026-09-29. +[S7] METR. "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity". metr.org. 2025-07-10. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/. Accessed 2026-09-29. +[S10] Beck, K. "Augmented Coding: Beyond the Vibes". newsletter.kentbeck.com. 2025-06-25. https://newsletter.kentbeck.com/p/augmented-coding-beyond-the-vibes. Accessed 2026-09-29. +[S14] Böckeler, B. "How far can we push AI autonomy in code generation?". martinfowler.com. 2025-08-05. https://martinfowler.com/articles/pushing-ai-autonomy.html. Accessed 2026-09-29. +[S17] Thoughtworks. "Codebase cognitive debt". Technology Radar Vol. 34. 2026-04. https://www.thoughtworks.com/radar/techniques/codebase-cognitive-debt. Accessed 2026-09-29. +[S18] Thoughtworks. "AI-friendly code design" (Assess). Technology Radar. https://www.thoughtworks.com/en-us/radar/techniques/ai-friendly-code-design. Accessed 2026-09-29. +[S20] Aviator. "Engineering Discipline in the AI Era with Dave Farley" (podcast). aviator.co. https://www.aviator.co/podcast/engineering-discipline-dave-farley. Accessed 2026-09-29. +[S21] Mathews, N. S., Nagappan, M. "Test-Driven Development for Code Generation". arXiv:2402.13521. 2024. https://arxiv.org/abs/2402.13521. Accessed 2026-09-29. +[S22] Cui, Y. "Tests as Prompt: A Test-Driven-Development Benchmark for LLM Code Generation". arXiv:2505.09027. 2025-05-13. https://arxiv.org/abs/2505.09027. Accessed 2026-09-29. +[S24] "ImpossibleBench: Measuring LLMs' Propensity of Exploiting Test Cases". arXiv:2510.20270; ICLR 2026. https://arxiv.org/abs/2510.20270. Accessed 2026-09-29. +[S25] Hasanli, T., Siddeeq, S., Khanal, B., Kotilainen, P., Mikkonen, T., Abrahamsson, P. "TDD Governance for Multi-Agent Code Generation via Prompt Engineering". arXiv:2604.26615. 2026-04-29. https://arxiv.org/abs/2604.26615. Accessed 2026-09-29. +[S30] Böckeler, B. "Coding assistants do not replace pair programming". martinfowler.com. 2023-08-10. https://martinfowler.com/articles/exploring-gen-ai/05-not-your-pair-programmer.html. Accessed 2026-09-29. +[S31] Daryanto, T., Ding, X., Ping, K., Wilhelm, L. T., Chen, Y., Brown, C., Rho, E. H. "Human-Human-AI Triadic Programming". arXiv:2601.12134. 2026-01-17. https://arxiv.org/abs/2601.12134. Accessed 2026-09-29. +[S34] Garg, R. "Patterns for Reducing Friction in AI-Assisted Development". martinfowler.com. 2026-04-08. https://www.martinfowler.com/articles/reduce-friction-ai. Accessed 2026-09-29. +[S35] Böckeler, B. "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl". martinfowler.com. 2025-10-15. https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html. Accessed 2026-09-29. +[S38] Shen, J. H., Tamkin, A. "How AI Impacts Skill Formation". arXiv:2601.20245. 2026-01-28. https://arxiv.org/abs/2601.20245. Accessed 2026-09-29. +[S40] Lee, H.-P. et al. "The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers". CHI '25, ACM. https://dl.acm.org/doi/full/10.1145/3706598.3713778. Accessed 2026-09-29. +[S42] Beck, K. "Genie Lessons: Nobody Wants Agents". newsletter.kentbeck.com. 2026-04-23. https://newsletter.kentbeck.com/p/genie-lessons-nobody-wants-agents. Accessed 2026-09-29. +[S44] Harvey, N., DeBellis, D. "Announcing the 2025 DORA Report". cloud.google.com. 2025-09-23. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report. Accessed 2026-09-30. +[S46] Baolin, J., Harvey, N. "Balancing AI tensions" (DORA insight). dora.dev. 2026-03-10. https://dora.dev/insights/balancing-ai-tensions/. Accessed 2026-09-30. +[S52] He, H., Miller, C., Agarwal, S., Kästner, C., Vasilescu, B. "Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects". arXiv:2511.04427; MSR '26. https://arxiv.org/abs/2511.04427. Accessed 2026-09-30. +[S54] He, H., Agarwal, S., Denisov-Blanch, Y., Azaletskiy, P., Koyejo, S., Vasilescu, B. "AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate". arXiv:2607.01904. 2026-07-02. https://arxiv.org/abs/2607.01904. Accessed 2026-09-30. +[S56] Saunders, M. "QCon London 2026: AI Agents Write Your Code. What's Left for Humans?". InfoQ. 2026-03-27. https://www.infoq.com/news/2026/03/qcon-london-foxwell-dev-teams/. Accessed 2026-09-30. +[S57] Pop, O. (host), Söderbom, A. M., Hast, O. "The Human Edge: Why Brownfield Codebases Need Mob Programming, Not Just AI Vibes" (podcast). InfoQ. 2026-08-24. https://www.infoq.com/podcasts/brownfield-codebases-mob-programming/. Accessed 2026-09-30. +[S58] Göthe, M. "Mob Programming with AI: Inside a High-Performing Team's Journey". Crisp's Blog. 2025-06-02. https://blog.crisp.se/2025/06/02/michaelgothe/mob-programming-with-ai-inside-a-high-performing-teams-journey. Accessed 2026-09-30. +[S59] Fowler, M. "Fragments: February 13". martinfowler.com. 2026-02-13. https://martinfowler.com/fragments/2026-02-13.html. Accessed 2026-09-30. +[S60] Laycock, R. "Maybe We Shouldn't Be Reviewing All This Code". martinfowler.com. 2026-09-02. https://martinfowler.com/rachels-ramblings/code-review.html. Accessed 2026-09-30. +[S61] Balepur, N., Baumler, C., Chen, V., Choi, E., Rudinger, R., Boyd-Graber, J. L. "(Im)Paired Programming: Coding Agents Improve Productivity but Harm Understanding". arXiv:2607.26375. 2026-07-29. https://arxiv.org/abs/2607.26375. Accessed 2026-09-30. +[S62] Kwa, T., West, B., Becker, J., et al. "Measuring AI Ability to Complete Long Software Tasks". arXiv:2503.14499. 2025-03-18 (rev. 2026-07-10). https://arxiv.org/abs/2503.14499. Accessed 2026-09-30. +[S64] Orlanski, G., Roy, D., Yun, A., et al. "SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks". arXiv:2603.24755. 2026-03-25. https://arxiv.org/abs/2603.24755. Accessed 2026-09-30. +[S65] Dhuri, S. "Specification Before Generation: A Pre-Registered, Five-Model Paired Evaluation of a Specification Frame for LLM-Generated Code in Money, Time, Idempotency, and Access Tasks". arXiv:2609.23270. 2026-09-20. https://arxiv.org/abs/2609.23270. Accessed 2026-09-30. +[S69] InfoQ. "Automated Acceptance Testing Supports Continuous Delivery" (news on Dave Farley's position). infoq.com. 2017-04-28. https://www.infoq.com/news/2017/04/acceptance-testing-delivery/. Accessed 2026-09-30. + +## Research Metadata +Examined: ~20 web searches and ~35 page fetches | Cited: 60 (26 new, 34 reused) | New sources fetched: 25 read at page or abstract level (V or A), 1 at search-abstract level only (N16) | Findings: Align and Understand 3, BDD 4, DDD 4, XP 1 (reused), Lean 4, cross-cutting 5 (21 in total; X5 is an unrated synthesis table) | Confidence across the 20 rated findings: High 6 (30%), Medium-High 8 (40%), Medium 6 (30%); no finding is rated Low overall, but Low ratings are recorded for specific sub-claims in DDD3 and X4 | Average reputation: 0.92 new, 0.89 overall | Tool failures: IEEE Xplore returned an empty page and ResearchGate returned 403 for N16; Springer pages required a cookie redirect, which succeeded for N18 and N19 | Output: docs/research/agentic-ai-in-the-software-development-model-for-explanation-doc.md + +## Research Review + +```yaml +research_review: + reviewer: nw-researcher-reviewer + date: 2026-09-30 + verdict: APPROVED + iterations: 1 + gates: + trusted_sources_only: {result: pass, value: "26 new sources on trusted domains; svpg.com 0.8, cucumber.io 0.8, innoq.com 0.6 justified"} + sources_per_claim: {result: pass, value: "average 4.2 per finding, range 3-11"} + citation_coverage: {result: pass, value: "100% of major claims"} + average_reputation: {result: pass, value: "0.89 overall (0.92 new, 0.86 reused)"} + scores: {source_bias: 0.85, evidence_quality: 0.85, replicability: 0.90, completeness: 0.90, overall: 0.875} + issues: + - {severity: medium, location: DDD1 (N16), problem: "Verified from search abstract only; IEEE page inaccessible", fix: "Do not quote its numbers in the explanation doc; re-verify when the full paper is available"} + - {severity: medium, location: BDD1 (N2, N3) and DDD findings (N18, N19), problem: "Studies use students or university researchers, not professional Domain Experts", fix: "State the population limit in the explanation doc"} + - {severity: low, location: N5, problem: "Radar volume and date metadata inconsistent", fix: "Verify with Thoughtworks"} + - {severity: low, location: AU1, problem: "Böckeler source on requirement over-production is indirect evidence", fix: "No change; N7 and N8 measure LLM output directly"} + - {severity: low, location: N24, N25, problem: "Vision papers self-described as unvalidated", fix: "Present as positions or open questions, not findings"} + - {severity: low, location: whole document, problem: "Evidence is mostly activity-level, not whole-team", fix: "Reinforce the transfer limit in any prescriptive text"} + blocking_issues: none +```