Spec-Driven Development на практике: опыт компании из 150 разработчиков / Иван Поддубный #90

Business summary (Spec-Driven Development practice at Webpraktik, ~150 devs)

Why they adopted SDD (Spec-Driven Development)

• Trigger #1: scaling + consistency problem

  • They reached ~100% adoption among developers by the end of the previous year.
  • Then they hit a scaling gap: SDD needed to become systemic across analysts, developers, and testers, not just “local wins.”

• Trigger #2: unify context

  • Earlier attempts created fragmented “sources of context” across teams/roles.
  • That fragmentation produced incompatible artifacts.
  • They needed a single common context bus to connect the full end-to-end flow.

• Strategic objective

  • Primary KPI-like goal: speed up development.
  • They considered targeting up to ~5x improvement, but later validated gains as measured and dependent on the scaling/model environment.

---

What SDD means operationally in their org

SDD is positioned as a workflow engine around specs + artifacts that persists through the lifecycle:

• Analysts/design create spec artifacts
• Developers implement via the spec-driven pipeline
• QA/testing becomes more automated/traceable
• Work is iteratively improved—they reject “finished” as a concept

---

Frameworks / playbooks / “workflow engine” components they use

Process architecture (end-to-end artifacts)

• Core SDD artifacts per “change”
  • proposition.md — proposal from ideation/discovery; includes business why/goal
  • design.md — technical design + data model/components
  • tasks.md — execution plan for agents; low-level steps
  • Plus:
    • “capabilities” inside specks, broken down by domains/functions
    • spec-to-test tracing (often via generating/deriving test scenarios)

Pipeline commands (their mental model)

• Open… / OpenSpec — open/build context for agent work
• Apply — execute the change (implementation)
• Archive — move completed change/spec into history and mark spec state

“Harness” concept (internal execution platform)

They emphasize that SDD succeeds because of a harness/workflow engine that:

• integrates spec writing + execution + validation + review
• enforces hooks/restrictions to prevent common hallucination/failure modes
• aggregates analytics across agent sessions to improve the system

---

Key metrics / measurement approach (explicit KPIs)

Development acceleration measurement (baseline + post-change)

They used a baseline/POC estimation comparison:

• Pre-SDD baseline

  • “backlog estimates” for typical tasks
  • tasks were decomposed into comparable frontend/backend modules/components

• Post-SDD measurement (May)

  • they observed more than half of tasks improving by roughly the x3–x5 range
  • described as multiples like x3, x4, x5

• Scaling plan acknowledgment

  • They did not assume everyone instantly achieves x5.
  • Scaling requires measurement + process adaptation.

Assessment buffers

• They apply time buffers:
  • estimate work in a constrained time window (example: ~5-hour/day)
• Buffers absorb communication/risk uncertainty and improve estimation accuracy.

Additional operational metric mentioned

• Commit-to-change traceability
  • every commit is linked/associated with the relevant “change” (e.g., chnzh/chenja)
  • so agents and humans can quickly understand intent and scope

---

Concrete examples / case studies

Adoption rollout and role-specific difficulties

• Phase 1 (developers)

  • developer adaptation via spec ingestion from the repo
  • earlier analysts used Confluence-like flows; later moved specs into the repository

• Phase 2 (analysts + QA)

  • analysts had to switch from Confluence docs to repo-based spec artifacts
  • required significant process redesign

• Phase 3 (test strategy change)

  • they concluded that having test-writing agents as a separate role was less efficient
  • agents can generate and run automated tests immediately as part of apply/execute
  • reduces role separation and duplicated work

A failed/incorrect spec split incident (important learning)

• In a tight-deadline project, they started without sufficient analyst involvement.
• Result:
  • front-end and back-end agents interpreted requirements differently
  • caused spec divergence
    • duplicated logic
    • inconsistent business meaning
• Fix:
  • require unified specs across FE/BE (avoid splitting across repos or duplicating by role)
  • integrate analyst involvement earlier when specs are reorganized at boundaries

Monorepo / metarepo strategy (multi-repo synchronization)

• Mistake they avoided/learned

  • splitting specs into per-repository contexts broke end-to-end business changes

• Solution they implemented

  • created a meta-repository (“metarepo”) that:
    • clones child repos (services/monolith/front/back) under one OpenSpec root
    • lets agents implement end-to-end changes consistently across services
    • supports hierarchical navigation for capability/domain scopes
  • They stress this does not mean everything is released as one monolith:
    • deployment ordering remains controlled (with manual rules, and later harness-assisted ordering suggestions)

Product/Prototype workflow

• They describe “prototype-to-spec” behavior:
  • product uses an agent skill to generate an HTML prototype
  • analysts run research/storming and generate spec artifacts aligned with design system blocks
• Claimed benefit:
  • helps customer approval and speeds sign-off

---

Actionable recommendations implied by their approach

• Start with developers, then expand to analysts and testers

  • build internal education (“club” + pair adaptation)
  • only expand after the systemic pipeline is ready

• Unify context early

  • avoid duplicated specs between FE/BE
  • require one source-of-meaning

• Use a harness with guardrails

  • add enforcement hooks to reduce “hallucination” or premature “everything is ready” behavior
  • especially important for younger/smaller model variants

• Measure acceleration with baselines

  • compare before/after using decomposed typical tasks

• Prefer spec-to-test tracing over human test role duplication

  • let agents generate and run automated tests immediately
  • humans validate discrepancies

---

Organizational tactics / leadership mechanics

• Internal adoption mechanism

  • created a “club” of committed devs early
  • weekly/biweekly sessions used to:
    • test locally
    • run demos
    • onboard skeptics via guided pair sessions

• SDD committee / governance

  • weekly 1–1.5 hour meeting
  • tracks harness evolution (and a specific service demonstrating spec training/changes)

• Review model

  • they keep human review, but use an agent-assisted reviewer pipeline to reduce manual workload

---

QA / review / ticket handling

• They use a Kanban-like visualization and discourage “returning backwards.”
• When issues arise in testing:
  • developers prioritize fixes
  • analysts may connect to update requirements if needed
• They differentiate:
  • bug fixes that don’t require spec regeneration
  • requirement changes that require OpenSpec/spec updates
  • technical refactors as “technical changes” via a dedicated skill

---

High-level investing/markets note

• No investment theses or market forecasting with quantified financial markets data.
• The only “future” discussion is operational:
  • harness maturity
  • scaling automation
  • model/provider constraints (e.g., certain steps require “older models” for reliability)

---

Presenters / sources

• Host / interviewer: Kirill Makevnin
• Guest: Ivan Poddubny, CTO at Webpraktik
• Referenced tools/brands in the discussion (not presenters): OpenSpecKit, BMAT/JS (as mentioned), Posok/Superpersock-like tooling, Confluence (legacy spec), GitHub, GitLab, and model providers including Claude* and others (Opus/Luna/Son mentioned).