Spec Driven Development через все роли команды как мы внедрили единый процесс в монолит с 10 летне

Main ideas, concepts, and lessons

SDD (Spec-Driven Development)

• Definition emphasized: specification is the single source of truth.
• Workflow: intention is recorded in the spec → code (and related artifacts) are generated from it.
• AI transformation benefit: helps counter “chaos of practices” and inconsistent context across roles.

Why they adopted SDD (two-part narrative / motivations)

1. Story 1: Getting 100% developer adoption, then improving depth

   • They reached 100% adoption among developers (target year mentioned as 2025 in subtitles).
   • How adoption happened:
     • Formed a small club of enthusiasts (15–20 people) to redesign the “harness” foundations.
     • Assigned club members as trackers to support all engineers.
     • Used pair programming where an SDD/AI expert would sit with developers for about a day to solve real problems.
     • Skeptics were largely overcome, reaching ~95% via practice; the remaining gap was handled through staffing/personnel decisions.
   • Next challenge: “Everyone uses it, but are they using it correctly?”
     • Created a developer maturity matrix, but stopped short of training everyone in deep harness internals.
     • Reason: harness is treated as a platform—developers should use ready-made workflows/skills rather than understand every internal detail.

2. Story 2: Introducing an autonomy maturity matrix

   • They created an engineering maturity matrix based on the dimension “autonomy”, using a factory metaphor.
   • Metaphor levels:
     • Level 0: manual pipeline
     • Level 1: chat-based assistance
       • AI doesn’t directly interact with artifacts; specs/code/tests exist and are pasted/managed manually
     • Level 2: local agents that operate directly on artifacts (exoskeleton metaphor)
     • Level 3: move agents from laptops to cloud, enabling more autonomy
       • agents can bypass some role dependencies for certain tasks
     • Level 4: “dark factory” (Japan term)—fully closed automation where people may not operate during production
   • Current practice: still around Level 2.
   • Planning: design Level 3 to reduce bus factor risk as teams shrink (“Tiny Teams” trend).

Need for end-to-end SDD across all roles

• Problem addressed: many teams implement SDD only for developers, not for analysts/testers.
  • Failure mode: multiple sources of truth
    • e.g., specs in Confluence vs copied/derived “truth” for developers
  • Testers may validate against Confluence instead of developer-generated artifacts → “deeply broken cycle.”
• Their solution: a single end-to-end platform and a single context bus
  • Analysts/product propose and generate initial intent/spec artifacts.
  • Developers implement by applying artifacts from the same change context.
  • QA/quality gates validate artifacts:
    • after analyst/product output
    • and after developer implementation steps
• Shift-left concept: close the loop earlier by letting agents write and verify tests end-to-end using acceptance criteria.

What they built on top of SDD: “Harness” as the engine

• They consider SDD the foundation; the harness is configured above it.
• Their harness includes:
  • practices and skills
  • automated artifact generation
  • testing strategy automation
  • Confluence export (for stakeholder compatibility when required)
  • tracing/signing of changes

---

Methodology / process details (end-to-end SDD and OpenSpec usage)

1) Chosen SDD framework and why

• They compared “about five top ones” (names mentioned):
  • GitHub Spec Kit
  • BMAT
  • Open Spec
  • JSD (described as recently “hacked” with author leaking)
• Selected: OpenSpec
• Reasons:
  • Simple to start
  • Two context states out of the box:
    • “increment state” and “current/spec state”
  • Built-in support for diff/layering-like documentation behavior
  • Strong fit for brownfield systems (10-year-old monoliths with weak/no docs)
• Community popularity mentioned: ~58,000 stars on GitHub (as stated in subtitles).

2) OpenSpec core model (as described)

• Change / Increment concept:
  • A “Change” is a unit representing a set of artifacts needed to implement a specific increment.
  • Change lifecycle: review → implementation → deployment → merge into source of truth.
• Spec as source of truth:
  • Spec folder contains only what represents the current state.
• Artifacts auto-generated by agents:
  • They emphasized that manual writing is minimized; agents generate artifacts and humans/agents review/edit them.

3) Key artifacts in a Change increment (the “basic set”)

• prop (intent/purpose)
  • Contains why and intent behind the increment
  • Ownership hinted: business ideally owns it; increment director creates it
• design
  • Ad-hoc / lower-level description
  • May include decomposition down to low-level increments and components
• tasm(d) (plan described in subtitles)
  • Not a checklist; a plan that can break and continue across sessions (e.g., token limits, subscriptions expiring)
  • Decomposes into smaller tasks that agents handle more effectively
• acceptance criteria
  • Generated specs become acceptance criteria (default format: Gherkin)
  • Used so agents can check work against expected outcomes

4) Main OpenSpec commands/skills referenced

• Propose / Props (as phrased in subtitles)
  • Input: what you want to create
  • Output: creates major artifacts from existing specs/artifacts and prior context
• Apply
  • Run by the developer to implement from the designed change folder
• Archive
  • After implementation and push/release, merge into the source of truth
• Explore (optional skill)
  • Used before “Propose” to brainstorm/refine the idea (possibly via internal proposal run)

5) Their end-to-end SDD process across roles (practical sequence)

• Analyst / Product phase
  • Generates initial intent/spec artifacts (why/what/how)
  • Passes into the same change context for developers
• Developer phase
  • Reviews generated artifacts, corrects if needed
  • Runs apply for implementation
• Quality gates / testing
  • QA checks artifacts after analyst/product release and after developer implementation
  • They mention replacing traditional tester writing with agent-driven end-to-end test verification
• Tracing and final merge
  • Artifacts and generated outputs trace back to acceptance criteria
  • Changes are archived/merged into the spec/source of truth

6) Additional artifact: test plan (to reduce heavy test explosion)

• They extended the OpenSpec process with an added generated artifact: test plan
• Purpose:
  • Determine which parts of the testing pyramid should cover the increment
  • Provide tracing from tests to acceptance criteria, validated by testers
• Benefit claimed:
  • Avoids an inflated number of heavy E2E tests
  • Improves effective coverage without excessive maintenance cost

7) Multi-repository (“multi-rep”) support: turning it into a usable “mono-rep” for agents

• Problem: “large monolith” reality included:
  • frontend monolith + backend monolith
  • many services/microservices
  • stored across two monolith repos and additional repos
• Solution:
  • Create a meta-repository with an “up” command to clone required repos
  • Place OpenSpec and skills in the meta-repo so the agent knows where to navigate
  • Use recursive Agents.md/Cloud.md so each repository pulls its own nested context
• Outcome:
  • Enables cross-cutting end-to-end changes across multiple repos with one increment per domain

8) “Change ID” tagging and tracing discipline (and related governance)

• They use a Change ID mechanism to track which changes produced which commits.
• Current enforcement/analysis approach:
  • Aggregate commits across multi-repos
  • Compare commits signed/linked to change vs not linked
  • Identify “lazy” commits made without creating a formal Change
• Optional future: an agent validator to check compliance
• Rationale: skipping Change creation degrades spec history quality, harming throughput/quality.

9) “Change-centric” paradigm vs “when not everything needs a Change”

• They state: not everything must go through a Change.
  • Example: changing button color that doesn’t affect specs doesn’t require a new Change.
  • Example: if an agent made a mistake, refine spec elements directly.
• However, they emphasize discipline:
  • If a technical modification affects spec-relevant history/context that agents rely on, it must be preserved.
• They mention refactoring/technical change teams:
  • Sometimes refactoring changes behavior without changing meaning, so they may not create a full “spec” in the strict sense.

---

Tools / practices integrated (as mentioned)

• Confluence export for stakeholders (some clients require strict bureaucratic formats)
  • Use a special skill to generate required Confluence artifacts from the Change
• Testing format choice
  • Default is Gherkin in OpenSpec
  • They experimented with “use cases” due to Gherkin readability concerns, but reverted partially because automated test quality degraded
• Tracing/commit signing with change context
  • For traceability: use git blame/VD lines → map back to specific change intent
• Harness evolution toward autonomy
  • They warn about tool choices that might “pin” them at Level 2 by lacking CLI/e2e binding consistency, forcing later harness rewrites

---

Effects and measurement approach (outcomes)

• They claim SDD shifted work “to the left” (earlier in the lifecycle, reduced bottlenecks).
• Measurement method described:
  • Before AI: baseline from everyone’s ratings, functionality broken into simple evaluable elements
  • After deeply implementing E/D D/SDD: update the baseline and observe direct multiples of acceleration for some task types
  • Acceleration varies by task; some tasks show little/no acceleration

---

Speakers / sources featured (as named in subtitles)

• Primary speaker / narrator (unnamed in subtitles)
  • 15 years IT experience
  • CTO at VPT (~150 people mentioned)
  • Oversees AI/DLCK work at conferences (program committee involvement)
  • Organizer of Rostov community of analysts and developers
  • Worked on transforming SDD processes into an AI track for ~1.5 years; claimed 100% developer adoption
• Maxim Larshin (asked a question in Q&A)
• Sberbank systems analyst (asked a question in Q&A)
• Audience participants / hands raised (multiple unnamed people asked questions)
• OpenSpec (tool/framework referenced; author not named in subtitles)