## Summary GitLab's AI-led flow takes a user from an initial intent through Duo-assisted planning (the Workplan) to implementation (MRs). Throughout this epic, **"spec" refers to the work item's description** — the field capturing the Why (motivation) and What (requirements) of the work. Several structural and UX gaps prevent this flow from feeling cohesive, trustworthy, and appropriately scoped to users who want it. This epic addresses those gaps within current product capabilities — not the longer-term vision of shared Duo sessions, inline commenting, or fully autonomous execution, which are being tracked separately. ## Goals - Give the spec a real, ongoing refinement loop — not just a one-time generation step - Cleanly separate what belongs to the spec (Why/What, open questions) from what belongs to the Workplan (How) - Give users a clear, holistic signal of Duo's confidence in successful, intent-aligned implementation - Make the AI dashboard opt-in/reflective of how a work item was actually created, and extend its visibility through execution - Remove approval steps that don't represent a real decision point - Adopt the existing Q&A component instead of plain-text question dumps ## Non-goals (for this phase) - Shared/live multiplayer Duo chat sessions - Inline commenting on the spec - User-configurable autonomy/confidence thresholds (informed by this work, but not built here) ## Problems **1. No refinement loop for the spec, and open questions are misattached to the Plan.** Duo generates a lightweight initial spec at creation by design, but there's no way to keep refining it afterward — on new or existing items. Open questions do get generated today, but only as a trailing section of Workplan output, when they're really about spec readiness, not the plan. This refinement process also needs to be multiplayer: outcomes need to be visible to and actionable by all participants, not buried in one user's Duo chat history. *Caveat to account for: this loop will need a base template for Duo-driven spec generation/refinement, but must also accommodate users/teams who already have their own description templates — refinement shouldn't fight or override an existing template structure. Detailed handling to be worked out at the sub-issue level.* **2. The Workplan currently duplicates Why/What content that belongs to the spec.** The spec should own Why (motivation) and What (requirements); the Workplan should own How (implementation approach) only. Today the Workplan repeats Why/What, creating duplication and drift risk. Changes to Why/What should happen on the spec, with human approval, and the Workplan should follow from it. **3. No confidence signal exists for how likely Duo is to implement a work item successfully.** There's no mechanism for Duo to communicate its confidence in implementing a work item to the user's actual intent without human intervention. This is foundational groundwork for future confidence-threshold-based autonomy, even in a lightweight first form. **4. An existing Q&A chat component isn't being used, and questions surface as unstructured text.** Duo currently dumps clarifying questions as plain text before Workplan generation. As the refinement loop becomes the primary path for resolving questions, this should become rarer — but for blocking questions surfaced at plan-generation time, they should use the purpose-built Q&A component rather than plain text. **5. The Workplan widget (AI dashboard) surfaces unconditionally, and there's no opt-in path for existing items.** The widget shows on every work item today regardless of whether the user wants this AI-driven experience. Visibility should be tied to whether the item was created via the AI-led flow. For items that weren't, there should be a CTA to retroactively initiate an AI-driven planning pass — reviewing the spec, and surfacing open questions and a confidence score. **6. Once implementation begins, the AI-led flow loses continuity and execution visibility.** MRs get linked into the Development section, but disconnected from the AI-led experience — often invisible to the user as an outcome of the flow they started. There's no rollup of MR status (count, merged, blocking). This should surface at the top of the AI dashboard so users can track progress from intent through to merged code as one continuous surface. **7. Too many approval gates require redundant manual confirmation.** Users must explicitly "Approve" actions they already initiated by starting them (e.g., generating a Workplan, starting implementation) — friction without real safety value. Not all approvals should be removed; some (like reviewing a Workplan before execution) are genuine decision points. Part of this epic is distinguishing real governance moments from redundant rubber-stamps. ## Current Design <iframe style="border: 1px solid rgba(0, 0, 0, 0.1);" width="800" height="450" src="https://embed.figma.com/design/uJb85wjoRaj7MMvjxAmdHf/SDD-Iteration-Path?node-id=5-20727&embed-host=share" allowfullscreen></iframe>