## Vision GitLab's lacks the structured, spec-driven development (SDD) approach that makes tools like [Kiro](https://kiro.dev/) highly effective for AI-assisted development. We want to create a Kiro-style workflow directly in GitLab. SDD in GitLab will enable users to work with AI agents more effectively by explicitly documenting requirements, design decisions, and implementation plans within GitLab Work Items, giving both humans and AI a clear source of truth. ## What is SDD? SDD is an AI-assisted coding approach where structured specifications are written before code, serving as the source of truth for both humans and AI. More information can be found in the following article, [Understanding Spec-Driven Development](https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html). ## Goals of SDD * Enable users to create and maintain structured specifications directly in GitLab with AI * Establish specs with AI as living artifacts that evolve with features * Create a single source of truth for feature requirements and implementation details using AI ## Design proposal > [!important] > > The design proposal for this initiative can be found in https://gitlab.com/gitlab-org/gitlab/-/work_items/592316+ ## Current focus - Parent epic: https://gitlab.com/groups/gitlab-org/-/work_items/22445+ - Active workstreams: https://gitlab.com/groups/gitlab-org/-/work_items/22445#workstreams - Target timeline + outcomes: https://gitlab.com/groups/gitlab-org/-/work_items/22445#workstreams ## Roadmap > [!note] The current acceptance criteria are subject to change based on the rapidly evolving agentic capabilities within GitLab. They represent our "best guess" as of today. Additionally, post-GA acceptance criteria will be pulled into GA as necessary depending on design partner validation and evolving software factory business requirements. ### MLP GA scope "_As an engineer on a team_, _I can efficiently delegate many backlog items to the loop to work autonomously, understand when I need to take an action to keep forward progress, understand what decisions have been made, and collaborate with my team asynchronously to bring my unique expertise to the highest priority task at hand._" Workflow steps must support the ability to run with HITL or fully autonomous. All steps are agent-driven by default based on human or automated triggers. Functional acceptance criteria: - Refine a work item description ("[change spec](https://gitlab.com/gitlab-org/plan-stage/software-factory-exploration/-/work_items/4#1-what-a-spec-is--the-two-object-model)") -- Captures the **what** and **why** - Generate a work plan -- Captures the **how** - Decision log -- Stores agent and human clarifying questions to improve the quality of the what, why, and how. - Multiplayer question resolution (agent-to-human, human-to-human) -- Extract key questions during refinement and planning out of a single session so everyone on the team can collaborate together. - Readiness score -- A visible quality signal and guardrail that reflects how well-defined and complete the plan is for agent consumption. - A user can easily visualize when an agent is working OR awaiting their input across the most frequented planning surface areas (todos/notifications, boards, list). - Token Economics, Quality, and Performance -- The overall flow must improve correctness of code generated, reduce token/credit cost compared to not using the flow, but ideally both. Customer impact and business value must be positively quantified prior to GA. Non-functional acceptance criteria: - The UX and overall flow must be highly polished, streamlined, and match (or exceed) the interaction quality as competitors (Claude, Claude Code, Cursor, ...) - Customer Zero is seeing positive value as evidenced by consistent growth in weekly adoption. - Design partners demonstrate a concrete "propensity to buy" - Instrumentation and telemetry - Directional alignment with the software factory initiative ### Post GA roadmap (FY28) <table> <tr> <th></th> <th>Focus</th> <th>Outcome</th> </tr> <tr> <td>H1</td> <td> * Initiate the "intent-to-code" workflow with context in third-party planning tools (e.g. Jira issue). * "intent-to-code" is natively integrated with a software factory (policies, flow configuration, UI surface area, ...) * Decompose larger workstreams (multi-level epics) into discrete vertical feature slices that can be executed in parallel. * Readiness score can be utilized as an automated quality checkpoint/gate. * Improved multi-player experience (in-line comments, presence indicator, richer context in the decision log) * SSoT contexts are shared/persisted between work items and downstream artifacts ("Acceptance Criteria" as a first-class widget, Decision log, ...). * Verification of acceptance criteria once initial code has been committed. (this may fall outside of the scope of the Plan stage. [Summary of the problem to solve](https://gitlab.com/gitlab-org/plan-stage/software-factory-exploration/-/work_items/4#capability-2--independent-verification--general-market)) </td> <td> "_As a product manager on a team_, _I can collaborate with Duo to capture and refine more complex, multi-step requirements into actionable workstreams my engineers can pick up and execute on. As decisions are made, scope changes, and implementation progresses, everyone on my team effortlessly stays aligned and has shared, transparent context._" </td> </tr> <tr> <td>H2</td> <td> * [Long-lived specs (true SDD)](https://gitlab.com/gitlab-org/plan-stage/software-factory-exploration/-/work_items/4) -- The requirements are still being explored, along with the necessary risks and failure modes that need to be validated and mitigated prior to committing to specific roadmap line items. </td> <td> "_As a/n \[insert role\] on a delivery team, agents drive the majority of the work, only requiring human intervention when certain guardrails we put in place are triggered. Instead of a backlog of work to be executed, we build and ship software by writing, and evolving, long-lived specs. We still review code, but have high confidence and trust in the output of the agents. Collaboration on the specs and higher-level system design is where we spend the bulk of our time._" </td> </tr> </table> ## DRIs for Plan Stage SDD Implementation * Product * @mmacfarlane * @izzychu * Engineering: * EM: @acroitor * ~frontend * @deepika.guliani * @fredericcaplette * @kushalpandya * @vanessaotto * ~backend * @msaleiko * @ngala * @stefanosxan * @rchanyj * Design: * @nickbrandt * Technical Writing: * @brendan777