## Summary Today, the **Plan** button on a work item is a single action that enables AI planning and kicks off the workplan generation flow. This issue proposes evolving it into a **split dropdown** that also exposes a direct **Implement** entry point — allowing users who trust the agent (or whose work item is simple enough) to skip the explicit planning step and go straight to implementation. ## Problem The current Plan → Implement flow is sequential and mandatory. Every user must go through workplan generation before implementation can begin. This creates unnecessary friction for: - **Simple, well-scoped work items** where the requirements are already clear and a full planning pass adds little value. - **High-trust / "YOLO mode" users** who want to delegate the entire loop to the agent and only intervene if something is blocking. The parent epic ([https://gitlab.com/groups/gitlab-org/-/work_items/22445](https://gitlab.com/groups/gitlab-org/-/work_items/22445)) explicitly calls out YOLO mode as a supported user intent: > *"This is so that we can support YOLO mode (I trust the agent suggestions, I don't have to read) and more gated approach of getting a work plan and then iterating on it before passing off to Duo Developer."* There is currently no UI affordance to express this intent. ## Proposed Solution ### UI Change: Split dropdown on the Plan button Replace the single **Plan** button with a **split dropdown** (primary action + chevron revealing additional options): | Option | Icon | Behaviour | |---|---|---| | **Plan** *(primary / default)* | `tanuki-ai` | Current behaviour — enables AI planning, kicks off workplan generation flow | | **Implement** *(dropdown option)* | `tanuki-ai` | New — enables AI planning and proceeds directly to implementation | The split dropdown pattern keeps **Plan** as the default (safe, recommended path) while making **Implement** discoverable for users who want to skip ahead. ### Behaviour of "Implement" Clicking **Implement** from the dropdown: 1. Sets `aiPlanningEnabled = true` on the work item (same as Plan). 2. Proceeds toward implementation — either directly triggering Duo Developer, or via a lightweight pre-flight step (see open questions below). ### Open Questions The key design decision is **what happens between clicking "Implement" and Duo Developer starting work**. Three approaches are under consideration: **Option A — Always run the workplan flow first (invisible to the user)** Run the full workplan generation flow as a background step before handing off to Duo Developer. The user sees implementation start; the plan is generated silently and used to guide the agent. - ✅ Consistent quality: blocking questions are always surfaced upfront; agent always has a structured plan. - ✅ Aligns with benchmarking findings that plans improve output quality (see [WS-1](https://gitlab.com/groups/gitlab-org/-/work_items/22774)). - ⚠️ Adds latency before implementation begins. - ⚠️ May feel redundant for very simple issues where the plan adds no signal. **Option B — Never run the workplan flow; go directly to Duo Developer** Skip workplan generation entirely and hand the work item description directly to Duo Developer. - ✅ Fastest path to implementation; lowest latency. - ⚠️ No blocking questions surfaced upfront — agent may hit ambiguity mid-implementation. - ⚠️ Loses the token-cost and quality benefits of a structured plan. **Option C — Evaluate and decide per work item** Run a lightweight evaluation (e.g., using the readiness score signal from [WS-6](https://gitlab.com/groups/gitlab-org/-/work_items/23050)) to determine whether a workplan pass is warranted before implementation. - ✅ Best of both worlds: simple issues go straight through; complex ones get a plan. - ✅ Connects naturally to the readiness score infrastructure already being built. - ⚠️ Adds complexity; evaluation logic needs to be defined and tuned. - ⚠️ Requires the readiness score to be reliable enough to gate on. The preferred approach needs to be decided before implementation begins. Option A is the lowest-risk starting point and most consistent with the existing architecture; Option C is the most elegant long-term direction. ## Scope - **In scope:** UI change to the Plan button (split dropdown), wiring the Implement option to enable AI planning and trigger the appropriate downstream flow, surfacing any blocking questions via the existing HITL mechanism ([WS-4](https://gitlab.com/groups/gitlab-org/-/work_items/22772)) if a workplan pass is run. - **Out of scope:** User-configurable autonomy thresholds, project-level policy to enforce Plan-first (future), changes to the Duo Developer flow itself. ## Related - Parent epic (WS-2): [https://gitlab.com/groups/gitlab-org/-/work_items/22703](https://gitlab.com/groups/gitlab-org/-/work_items/22703) - "YOLO mode" concept: [https://gitlab.com/groups/gitlab-org/-/work_items/22445](https://gitlab.com/groups/gitlab-org/-/work_items/22445) - WS-6 Readiness Score (Option C dependency): [https://gitlab.com/groups/gitlab-org/-/work_items/23050](https://gitlab.com/groups/gitlab-org/-/work_items/23050) - WS-4 HITL & Notifications (blocking questions surface): [https://gitlab.com/groups/gitlab-org/-/work_items/22772](https://gitlab.com/groups/gitlab-org/-/work_items/22772) - WS-1 Benchmarking (plan quality evidence): [https://gitlab.com/groups/gitlab-org/-/work_items/22774](https://gitlab.com/groups/gitlab-org/-/work_items/22774) - Show disabled "Implement" button with tooltip: [https://gitlab.com/gitlab-org/gitlab/-/work_items/629904](https://gitlab.com/gitlab-org/gitlab/-/work_items/629904)