## Why We benchmarked the advanced code review flow against the current single-pass code_review/1.0.0 flow on the Duo Review Bench dataset. Results are in the [benchmark work item](https://gitlab.com/gitlab-org/gitlab/-/work_items/618672#note_3770841977). Three runs of the single deep agentic reviewer (fetches repository context on demand) scored Hit F1 of 0.604, 0.608 and 0.608. The average improvement over the current flow is +0.049, with a 95% confidence interval of [+0.024, +0.075]. Cost is roughly 1.6x the current flow per review. The multi-agent panel variant we also tested did not win and is on hold. Based on this, we are shipping the single-agent design as the first MVP, named `advanced_code_review/1.0.0`, and dogfooding it internally behind a feature flag before any wider rollout. ## What The flow has three steps. First, `fetch_mr_data` makes one deterministic call to `build_review_merge_request_context` with only_diffs on, no preloaded file contents, the instruction format hint off, and a `<changed_files>` list on as a coverage checklist. Second, `review` runs one AgentComponent with the `advanced_code_review_reviewer` prompt, response schema `code_review_phase_findings`, `response_schema_tool_choice` set to `auto`, `max_cycles` 25, and a read-only repository toolset. It emits every candidate finding with a confidence score from 0 to 10. Third, `publish_review` calls the deterministic `post_duo_code_review_findings` tool, which applies the confidence gate, sorts by severity, builds the summary, and posts the review. No finding passes through a model after the reviewer writes it. The ai-assist (Duo Workflow Service) side is already open as four draft MRs off main, milestone 19.4, merging in order: | MR | Purpose | |---|---| | https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/merge_requests/6734 | Add `response_schema_tool_choice` (any/auto) to agent components | | https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/merge_requests/6735 | Add `include_instruction_format_hint` and `include_changed_files_list` flags to `build_review_merge_request_context` | | https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/merge_requests/6737 | Add the `post_duo_code_review_findings` publish tool | | https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/merge_requests/6738 | Add the `advanced_code_review/1.0.0` flow config, prompt and response schema | https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/merge_requests/6603 is the historical end-to-end reference MR before the split and is not to be merged. ### Remaining work, monolith and gateway - [x] Add a feature-flag-gated branch in the code review flow version resolver (`ee/app/models/ai/catalog/foundational_flow/definitions/code_review.rb`) routing flagged projects to `advanced_code_review/1.0.0`, same shape as `duo_code_review_previous_discussions` - [x] Replace the XML review transport with structured findings. Add an optional `findings` array parameter to `POST /ai/duo_workflows/code_review/add_comments` (`ee/lib/api/ai/duo_workflows/code_review.rb`) and a parser behind `ProcessCommentsService#parsed_body` that emits the same `Comment` objects from JSON, so line matching, deduplication, draft note building and publishing stay unchanged. Applyable suggestions keep working because the Apply button comes from a `suggestion` fenced block in the note body, which the new parser builds from `target_code` and `suggestion`, reusing the offset arithmetic in `CodeSuggestionFormatter`. This lets `post_duo_code_review_findings` post findings as JSON and delete `_defuse`, `_UNSAFE_IN_ATTRIBUTE` and the render function, which are the root cause of two parser bugs found in review of https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/merge_requests/6737 - [x] One combined pass: add `end_line` to the findings schema so a suggestion can replace more than one existing line, and carry `severity` and `confidence` through to the monolith. One change rather than three, since all of them extend the findings schema and `ResponseBodyParser::Comment`. **The `end_line` part blocks the rollout**: `target_code` is a single line and `suggestion_block` derives the span from it, so replacing N existing lines is impossible today and the model can publish an Apply button that produces broken code. Severity and confidence then unlock per-severity counts, an emitted-versus-posted funnel, and the sweep below. **Open decision that gates the pass**: validate `end_line` in `FindingsParser` (transport level, no diff access) or in `ProcessCommentsService` (already holds `diff_file.diff_lines`, can degrade to single-line, and is the plumbing a future `line_range` needs; recommended) - [x] Intelligent follow-ups support for advanced code review flow - [x] Pick a production `min_confidence` value from an offline threshold sweep over benchmark candidates before dogfooding at scale. Depends on the combined pass above shipping `confidence` to the monolith ## Dogfooding and rollout 1. Enable the feature flag for Code Review team members only. 2. If that goes well, enable it for all internal GitLab team members. 3. Create a dedicated internal feedback issue for team member reports. 4. Record a demo video and post an announcement. ## Out of scope - The multi-agent specialized reviewer panel, on hold after the benchmark. - Orbit integration for the advanced flow, as a follow-up once internal dogfooding lands. ## References - Parent epic: https://gitlab.com/groups/gitlab-org/-/work_items/21524 - Benchmark work item: https://gitlab.com/gitlab-org/gitlab/-/work_items/618672 - Results note: https://gitlab.com/gitlab-org/gitlab/-/work_items/618672#note_3770841977