Qodo vs cubic

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to cubic
   Qodo✓fullprobed8/10

   A live probe confirms Qodo publishes an llms.txt file at docs.qodo.ai/llms.txt returning HTTP 200 with a structured summary of the product, directly enabling an AI agent to be pointed at it for agent-oriented context. This is corroborated by extensive agent-facing documentation (Agentic Toolbox, MCP, CLI) showing Qodo actively targets AI agent consumption of its docs and capabilities. Missing for 10: independent (non-probe) confirmation that agents successfully consume/parse the llms.txt content in practice, and evidence of additional agent-oriented doc formats beyond the single llms.txt file.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.qodo.ai/llms.txt # Qodo Qodo is an AI code review and governance platform for engineering teams. I…”
   • [claimed-docs] “The Qodo Agentic Toolbox brings Qodo's code understanding, coding standards, and review capabilities into your existing coding agent.”
   • [claimed-docs] “Use MCP when you want to connect Qodo Agentic Toolbox managed skills to a remote or custom agent, workflow, or application.”

   proof ↗⚑ flag

   cubic✓fullprobed9/10

   cubic hosts a live llms.txt (HTTP 200) and .md-suffixed agent-friendly docs pages that link back to the llms.txt index, confirming an agent can be pointed at these docs and navigate them. missing for 10: no independent/community confirmation of an agent actually consuming llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.cubic.dev/llms.txt # cubic documentation > cubic reviews code on GitHub and in local coding workfl…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.cubic.dev/ai-review/introduction.md > ## Documentation Index > Fetch the complete documentation inde…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Qodo
   Qodo✓fullprobed7/10

   Qodo's core PR-review bot runs automatically/headlessly on every pull request without manual invocation (qodo-docs-1, qodo-docs-26), and the Agentic Toolbox ships a CLI plus MCP server explicitly meant for automation/local or remote workflows (qodo-docs-5, qodo-docs-32, qodo-docs-33, qodo-probe-3/4), which can be scripted into CI. Missing for 10: an explicit first-party CI pipeline example (e.g., GitHub Actions/GitLab CI snippet running the CLI) and independent hands-on confirmation of headless CI usage.

   • [claimed-docs] “Once connected, Qodo automatically reviews every pull request in your li”
   • [claimed-docs] “Trigger a Qodo code review manually or automatically, and control when reviews run on a pull request.”
   • [claimed-docs] “Review changes before opening a pull request.”
   • [claimed-docs] “Use the Qodo Agentic Toolbox CLI when you want to use Qodo-managed skills locally.”
   • [claimed-docs] “Use MCP when you want to connect Qodo Agentic Toolbox managed skills to a remote or custom agent, workflow, or application.”
   • [probe] “official MCP server documented at https://docs.qodo.ai/agentic-toolbox/mcp”
   • [probe] “official CLI documented at https://docs.qodo.ai/agentic-toolbox/cli”

   proof ↗⚑ flag

   cubic~partialprobed6/10

   cubic's core review flow is already headless — it auto-reviews PRs on open with no manual step (cubic-docs-1, cubic-docs-47), and the cubic CLI can review local changes before a push (cubic-docs-7, cubic-probe-5), which is plausible to script into CI. However there is no explicit documentation of a CI/pipeline integration mode, exit codes for pass/fail gating, or GitHub Actions/other CI examples. Missing for 10: explicit CI pipeline integration docs, non-interactive/exit-code behavior for automation gating, and independent confirmation of CLI use in CI.

   • [claimed-docs] “Once installed, cubic automatically reviews new pull requests.”
   • [claimed-docs] “The **cubic CLI** reviews local changes before you push. It finds bugs and generates a prompt that your coding agent can use to fix them.”
   • [probe] “official CLI documented at https://docs.cubic.dev/ide/cli-review”
   • [claimed-docs] “The AI automatically scans every pull request for a wide range of issues, including logic errors, style inconsistencies, and potential secur…”
   • [claimed-docs] “Codebase scans deploy thousands of AI agents to find bugs and vulnerabilities across your repository.”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Qodo—none0/10

   All MCP-related evidence describes Qodo exposing its own Agentic Toolbox skills AS an MCP server for other agents (Claude Code, Codex, Kiro) to consume (qodo-docs-6, qodo-docs-33, qodo-probe-3), not Qodo itself acting as an MCP client that ingests external MCP servers' tools. No documentation shows a way to configure/plug third-party MCP servers into Qodo's own agent/CLI so it can use their tools.

   • [claimed-docs] “Use MCP when you want to connect Qodo Agentic Toolbox managed skills to a remote or custom agent, workflow, or application.”
   • [claimed-docs] “Retrieve and resolve review findings.”
   • [probe] “official MCP server documented at https://docs.qodo.ai/agentic-toolbox/mcp”
   • [claimed-docs] “Use Qodo with Claude to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resolving code review fin…”
   • [claimed-docs] “Use the Qodo plugin with the Codex agent to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resol…”
   • [claimed-docs] “Use Qodo with the Kiro agent to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resolving code re…”

   proof ↗⚑ flag

   cubic—none0/10

   Cubic's MCP-related evidence is all about cubic exposing its own MCP server for other coding agents to consume (cubic-docs-8, cubic-probe-4) — the reverse of this story, which asks whether the AI-native user can plug external MCP servers into cubic so cubic can use their tools. No evidence shows cubic acting as an MCP client consuming third-party MCP servers; integrations like Jira/Linear/Notion (cubic-docs-37, cubic-docs-61) appear to be native integrations, not MCP-based tool consumption.

   • [claimed-docs] “Connect cubic's MCP server to your coding agent to read review findings and codebase context, request PR reviews, and triage PR or codebase …”
   • [probe] “official MCP server documented at https://docs.cubic.dev/ide/mcp-server”
   • [claimed-docs] “Connect to Jira, Linear, Asana, and Notion”
   • [claimed-docs] “Add page context from Notion to make AI reviews understand your requirements and generate accurate PR descriptions.”

   proof ↗⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round to cubic
   Qodo✓fullprobed7/10

   Qodo documents an official MCP server (Agentic Toolbox MCP) explicitly for connecting Qodo's code-understanding, review, and rules skills to remote or custom agents, confirmed by both docs and a probe hit at the documented URL. missing for 10: independent/hands-on corroboration of MCP usage, detailed setup/auth documentation, and specifics on which skills/tools are exposed over MCP.

   • [claimed-docs] “Retrieve and resolve review findings.”
   • [claimed-docs] “Use MCP when you want to connect Qodo Agentic Toolbox managed skills to a remote or custom agent, workflow, or application.”
   • [probe] “official MCP server documented at https://docs.qodo.ai/agentic-toolbox/mcp”
   • [claimed-docs] “The Qodo Agentic Toolbox brings Qodo's code understanding, coding standards, and review capabilities into your existing coding agent.”

   proof ↗⚑ flag

   cubic✓fullprobed8/10

   cubic documents an official MCP server that lets coding agents read review findings/codebase context, request PR reviews, triage issues, and even manage subscription/seats without leaving the MCP client, with a dedicated docs page (cubic-probe-4) and integration guidance across Cursor, Claude Code, VS Code, Codex, Gemini CLI, etc. missing for 10: independent/hands-on verification that the MCP server works reliably in practice beyond first-party docs.

   • [claimed-docs] “Connect cubic's MCP server to your coding agent to read review findings and codebase context, request PR reviews, and triage PR or codebase …”
   • [claimed-docs] “You can now ask your coding agent to check your cubic subscription, manage team seats and roles, and purchase more seats without leaving you…”
   • [claimed-docs] “Install and connect cubic in Cursor, Claude Code, VS Code, Codex, Gemini CLI, or another coding tool.”
   • [probe] “official MCP server documented at https://docs.cubic.dev/ide/mcp-server”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round drawn
   Qodo✓fullprobed8/10

   Qodo documents an official Agentic Toolbox CLI for local use (retrieving rules, reviewing changes before PR, resolving findings), and community evidence corroborates a real 'Qodo Command CLI' with agentic permission controls. Missing for 10: independent deep-dive review of CLI robustness/feature completeness and broader third-party adoption evidence beyond a single HN thread.

   • [claimed-docs] “Review changes before opening a pull request.”
   • [claimed-docs] “Retrieve the rules and standards that apply to a task.”
   • [claimed-docs] “Use the Qodo Agentic Toolbox CLI when you want to use Qodo-managed skills locally.”
   • [probe] “official CLI documented at https://docs.qodo.ai/agentic-toolbox/cli”
   • [community] “Slick. This applies to the new Qodo Command CLI, yes? I updated to the latest version last night. Enjoyed seeing the process permission togg…”

   proof ↗⚑ flag

   cubic✓fullprobed8/10

   cubic ships an official CLI (documented at /ide/cli-review) that reviews local changes before push, finds bugs, and generates prompts for coding agents to fix them, fitting the ai-native/agentic workflow theme. Missing for 10: independent hands-on verification of the CLI's usage/UX beyond first-party docs, and more detail on CLI command surface/options.

   • [claimed-docs] “The **cubic CLI** reviews local changes before you push. It finds bugs and generates a prompt that your coding agent can use to fix them.”
   • [probe] “official CLI documented at https://docs.cubic.dev/ide/cli-review”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Qodo~partialprobed6/10

   Qodo documents an official MCP server and CLI (Agentic Toolbox) that let external agents retrieve findings, resolve reviews, and fetch rules programmatically, which is a documented interface for AI-native automation. However, a direct probe for a conventional public REST/OpenAPI API returned 404 on all candidate paths, so there is no traditional public API surface beyond the MCP/CLI toolbox. Missing for 10: a documented REST/OpenAPI-style public API, broader API reference docs, and independent confirmation of API robustness beyond first-party docs.

   • [claimed-docs] “Retrieve and resolve review findings.”
   • [claimed-docs] “Use MCP when you want to connect Qodo Agentic Toolbox managed skills to a remote or custom agent, workflow, or application.”
   • [claimed-docs] “Use the Qodo Agentic Toolbox CLI when you want to use Qodo-managed skills locally.”
   • [claimed-docs] “Retrieve the rules and standards that apply to a task.”
   • [probe] “official MCP server documented at https://docs.qodo.ai/agentic-toolbox/mcp”
   • [probe] “official CLI documented at https://docs.qodo.ai/agentic-toolbox/cli”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.qodo.ai/openapi.json, https://docs.qodo.ai/swagger.json, https://docs.qodo.ai/api/opena…”

   proof ↗⚑ flag

   cubic~partialprobed6/10

   cubic exposes some programmatic surfaces — a documented Analytics API for PR-level metrics (cubic-docs-16), an official MCP server for agents to request reviews/triage issues (cubic-docs-8, cubic-probe-4), and a CLI for local review (cubic-probe-5) — which together let an AI-native user drive parts of the product programmatically. However, a probe for a general public REST/OpenAPI spec returned 404 on all standard paths, indicating no comprehensive documented public API beyond these narrower interfaces. Missing for 10: a full OpenAPI/REST API spec covering core product actions (not just analytics), independent hands-on verification of the Analytics API and MCP server working as documented.

   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”
   • [claimed-docs] “Connect cubic's MCP server to your coding agent to read review findings and codebase context, request PR reviews, and triage PR or codebase …”
   • [probe] “official MCP server documented at https://docs.cubic.dev/ide/mcp-server”
   • [probe] “official CLI documented at https://docs.cubic.dev/ide/cli-review”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cubic.dev/openapi.json, https://docs.cubic.dev/swagger.json, https://docs.cubic.dev/api…”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Qodo—none0/10

   Evidence shows admin control over who can access the Agentic Toolbox (qodo-docs-37) and a community mention of a process permission toggle (rwx) in the CLI (qodo-comm-3), but neither documents scoped or least-privilege API credentials/tokens issued specifically to an agent. No API key scoping, token minting, or credential-management docs appear in the pack.

   • [claimed-docs] “Workspace admins can control which users have access to the Qodo Agentic Toolbox. By default, the Agentic Toolbox is enabled for everyone in…”
   • [community] “Slick. This applies to the new Qodo Command CLI, yes? I updated to the latest version last night. Enjoyed seeing the process permission togg…”

   proof ↗⚑ flag

   cubic—none0/10

   cubic documents role-based access control for human team members managing subscriptions/settings (cubic-docs-56) and offers an MCP server/Analytics API, but there is no evidence of any mechanism to issue scoped or least-privilege API credentials/tokens specifically for an agent's use.

   • [claimed-docs] “cubic uses a role-based access control system to manage who can make changes to your team's subscription and settings. Every team member has…”
   • [claimed-docs] “Connect cubic's MCP server to your coding agent to read review findings and codebase context, request PR reviews, and triage PR or codebase …”
   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Qodo—none0/10

   Qodo documents a CLI, an MCP server, and agent plugins (Claude, Codex, Kiro) for its Agentic Toolbox, but there is no evidence of an official SDK/client library for programmatic integration, and the OpenAPI/API-spec probe returned 404s across all candidate paths, indicating no public API surface to build an SDK against.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.qodo.ai/openapi.json, https://docs.qodo.ai/swagger.json, https://docs.qodo.ai/api/opena…”
   • [claimed-docs] “Use the Qodo Agentic Toolbox CLI when you want to use Qodo-managed skills locally.”
   • [claimed-docs] “Use MCP when you want to connect Qodo Agentic Toolbox managed skills to a remote or custom agent, workflow, or application.”
   • [probe] “official MCP server documented at https://docs.qodo.ai/agentic-toolbox/mcp”
   • [probe] “official CLI documented at https://docs.qodo.ai/agentic-toolbox/cli”

   proof ↗⚑ flag

   cubic—none0/10

   Cubic documents an MCP server, CLI, and Analytics API, but the evidence pack shows no official client SDKs (e.g., Python/JS libraries) for building against cubic, and explicit probes for an OpenAPI/swagger spec returned 404s, indicating no formal SDK surface is published.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cubic.dev/openapi.json, https://docs.cubic.dev/swagger.json, https://docs.cubic.dev/api…”
   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”
   • [probe] “official MCP server documented at https://docs.cubic.dev/ide/mcp-server”
   • [probe] “official CLI documented at https://docs.cubic.dev/ide/cli-review”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Qodo—none0/10

   No evidence of a webhook subscription mechanism; Qodo offers MCP, CLI, and Git-provider integrations for reviews but nothing documented about outbound event webhooks for third-party subscription, and the openapi probe found no API spec either.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.qodo.ai/openapi.json, https://docs.qodo.ai/swagger.json, https://docs.qodo.ai/api/opena…”
   • [claimed-docs] “Connect Qodo to your Git provider to enable automated code reviews directly in your pull requests.”

   proof ↗⚑ flag

   cubic—none0/10

   No evidence of a webhook subscription mechanism; cubic offers an Analytics API, MCP server, and GitHub comment interactions but nothing about outbound event webhooks. OpenAPI/webhook probes returned 404s, and no docs mention webhook subscriptions.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cubic.dev/openapi.json, https://docs.cubic.dev/swagger.json, https://docs.cubic.dev/api…”
   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to cubic
   Qodo✓fullcommunity8/10

   Qodo generates AI-driven insights directly inside the product: PR summaries, ranked findings with rationale and fixes, risk/blast-radius classification, relevance links, and in-PR chat, all documented as core platform features (qodo-docs-2,3,8,22,23,24,27). This is corroborated by community mentions of using its review bot, though sentiment is mixed. Missing for 10: independent hands-on validation of insight accuracy/usefulness and some community reports of switching away from Qodo's bot temper full confidence.

   • [claimed-docs] “every finding states what needs attention, why it matters, and how to fix it, ranked by severity”
   • [claimed-docs] “Discuss or dismiss a finding, or let Qodo apply the fix directly.”
   • [claimed-docs] “Qodo makes this classification available as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), so you can triage which pull…”
   • [claimed-docs] “Qodo reviews the full codebase, not just the diff, to generate a structured summary of the pull request (PR) that gives reviewers meaningf”
   • [claimed-docs] “Chat with Qodo to interact with Qodo directly inside pull requests.”
   • [claimed-docs] “The **Relevance** section highlights related pull requests wi”
   • [claimed-docs] “The review focuses on surfacing issues that matter, explaining why they matter, and helping developers resolve them efficiently, without ove…”
   • [community] “Was using their bot for code review for last 2 years but just dropped it for BugBot”

   proof ↗⚑ flag

   cubic✓fullcommunity9/10

   cubic delivers extensive AI-generated insights: automated PR review comments flagging bugs/security issues, AI-generated PR summaries, an AI wiki that indexes the codebase into diagrams/docs, analytics dashboards (AI coding, AI review, delivery) with PR-level insight data, and issue-analysis that checks PRs against linked Jira/Linear tickets. A community reviewer corroborates the quality of these AI-generated technical explanations as more useful than generic LLM output. Missing for 10: independent large-scale benchmarking of insight accuracy beyond one HN anecdote.

   • [claimed-docs] “Spots bugs and improvements: Comments on bugs and improvements in pull requests”
   • [claimed-docs] “PR summaries: Generates PR descriptions based on code changes”
   • [claimed-docs] “cubic's AI wiki automatically indexes your codebase and produces searchable wikis, complete with links to source code, architecture diagrams…”
   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”
   • [claimed-docs] “cubic can automatically analyze your pull requests to see if they meet the requirements from your linked Linear or Jira issues.”
   • [claimed-docs] “The analytics dashboard shows how your team ships code across three lenses: AI coding usage, AI review impact, and delivery speed.”
   • [community] “I really liked it - it hit the mark. The current balance works very well, and it genuinely surprised me. It provides more technical explanat…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to cubic
   Qodo~partialclaimed6/10

   Qodo automatically reviews every PR in the background once connected (qodo-docs-1, qodo-docs-42, qodo-docs-26), and its governance features enforce standards across repos without manual intervention (qodo-docs-38), which qualifies as autonomous background automation for code review. However, this is scoped to PR review/governance rather than general-purpose autonomous agent workflows, and there's no evidence of scheduled/triggered custom automations beyond PR events. missing for 10: evidence of user-configurable autonomous triggers/schedules beyond PR events, independent hands-on confirmation that background automation runs reliably unattended, and broader autonomous task execution beyond code review/governance.

   • [claimed-docs] “Once connected, Qodo automatically reviews every pull request in your li”
   • [claimed-docs] “Trigger a Qodo code review manually or automatically, and control when reviews run on a pull request.”
   • [claimed-docs] “Qodo governance is built for engineering leaders who need consistent standards enforced across every repository, automatically, at scale, an…”
   • [claimed-docs] “Connect Qodo to your Git provider to enable automated code reviews directly in your pull requests.”

   proof ↗⚑ flag

   cubic✓fullclaimed8/10

   cubic automatically reviews every new PR without manual trigger, runs codebase-wide scans deploying many agents, can auto-fix issues and auto-approve PRs, and continuously learns from feedback—all happening in the background once installed, per docs-1, docs-4, docs-6, docs-12, docs-29, docs-52. This matches the story of autonomous background automation for code review workflows. Missing for 10: independent/hands-on verification that these automations run reliably unattended over time, and clearer detail on scheduling/triggers beyond PR events.

   • [claimed-docs] “Once installed, cubic automatically reviews new pull requests.”
   • [claimed-docs] “cubic generates the fix and pushes it to your PR branch.”
   • [claimed-docs] “Enable [auto-approval](/ai-review/auto-approval) to let cubic approve PRs that meet your review policy.”
   • [claimed-docs] “Codebase scans deploy thousands of AI agents to find bugs and vulnerabilities across your repository.”
   • [claimed-docs] “Enable auto-approval to let cubic approve PRs that meet your review policy.”
   • [claimed-docs] “cubic can automatically fix issues in the background. When the AI spots a problem, you can click the **Fix with cubic** button”
   • [claimed-docs] “Auto-approval lets you skip human review for pull requests that cubic determines are low risk and issue-free.”
   • [claimed-docs] “cubic automatically learns when you: Reply to its comments... React to suggestions: Thumbs up/down help cubic calibrate what's useful vs noi…”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   Qodo✓fullcommunity7/10

   Qodo ships a built-in AI assistant that users can delegate review tasks to directly inside the product: chatting with Qodo in PRs, having it apply fixes, triggering reviews, and a Command CLI with agentic permission controls noted by a community user. This is real delegation of tasks to an embedded assistant, though the scope is centered on code review/fix workflows rather than broader open-ended task delegation. Missing for 10: independent hands-on evidence of task delegation quality/reliability, and evidence of delegating non-review tasks (e.g. feature building) to the built-in assistant.

   • [claimed-docs] “Discuss or dismiss a finding, or let Qodo apply the fix directly.”
   • [claimed-docs] “Chat with Qodo to interact with Qodo directly inside pull requests.”
   • [claimed-docs] “Trigger a Qodo code review manually or automatically, and control when reviews run on a pull request.”
   • [claimed-docs] “The review focuses on surfacing issues that matter, explaining why they matter, and helping developers resolve them efficiently, without ove…”
   • [community] “Slick. This applies to the new Qodo Command CLI, yes? I updated to the latest version last night. Enjoyed seeing the process permission togg…”

   proof ↗⚑ flag

   cubic✓fullcommunity7/10

   cubic acts as a built-in AI teammate that users can direct with explicit commands (e.g. '@cubic-dev-ai review this PR', triggering ultrareview, asking it to generate and push a fix, replying for clarification, enabling auto-approval, or running codebase scans that deploy AI agents), and a community reviewer corroborates that it does more than basic checks. Missing for 10: independent/hands-on verification of these delegated actions actually completing end-to-end, and evidence of broader (non-review) task delegation beyond the code-review domain.

   • [claimed-docs] “To review a PR that was opened _before_ you installed the app, comment: `@cubic-dev-ai review this PR`.”
   • [claimed-docs] “Ultrareview runs a longer review using cubic's most capable review models, which is useful for risky migrations, security-sensitive changes,…”
   • [claimed-docs] “cubic generates the fix and pushes it to your PR branch.”
   • [claimed-docs] “Reply to a review comment to ask for clarification:”
   • [claimed-docs] “Enable [auto-approval](/ai-review/auto-approval) to let cubic approve PRs that meet your review policy.”
   • [claimed-docs] “Codebase scans deploy thousands of AI agents to find bugs and vulnerabilities across your repository.”
   • [community] “I really liked it - it hit the mark. The current balance works very well, and it genuinely surprised me. It provides more technical explanat…”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to cubic
   Qodo~partialclaimed6/10

   Qodo supports conversational interaction via 'Chat with Qodo' in pull requests, letting users discuss, dismiss, or apply fixes to findings in natural language (qodo-docs-3, qodo-docs-23), and its Agentic Toolbox exposes skills to other NL-driven agents (Claude, Codex, Kiro) via CLI/MCP (qodo-docs-29–33). However, most core operation (triggering reviews, configuration, governance rules) is done via portal settings or config-as-code files rather than natural-language commands. Missing for 10: evidence of a general NL command interface for controlling reviews/settings outside chat, and independent hands-on confirmation of chat reliability.

   • [claimed-docs] “Discuss or dismiss a finding, or let Qodo apply the fix directly.”
   • [claimed-docs] “Chat with Qodo to interact with Qodo directly inside pull requests.”
   • [claimed-docs] “Use Qodo with Claude to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resolving code review fin…”
   • [claimed-docs] “Use the Qodo plugin with the Codex agent to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resol…”
   • [claimed-docs] “Use Qodo with the Kiro agent to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resolving code re…”
   • [claimed-docs] “Use the Qodo Agentic Toolbox CLI when you want to use Qodo-managed skills locally.”
   • [claimed-docs] “Use MCP when you want to connect Qodo Agentic Toolbox managed skills to a remote or custom agent, workflow, or application.”

   proof ↗⚑ flag

   cubic✓fullclaimed7/10

   cubic supports natural-language interaction: commenting `@cubic-dev-ai review this PR`, replying to review comments to ask clarification or trigger fixes, and requesting an Ultrareview, plus MCP server integration letting a coding agent issue natural-language requests (review, triage, manage subscription) on cubic's behalf. This covers command-like NL operation across PR comments and agent tooling. missing for 10: independent/hands-on verification of NL command robustness beyond documented examples, and no evidence of a broader conversational/chat interface beyond structured comment triggers.

   • [claimed-docs] “To review a PR that was opened _before_ you installed the app, comment: `@cubic-dev-ai review this PR`.”
   • [claimed-docs] “Reply to a review comment to ask for clarification:”
   • [claimed-docs] “@cubic-dev-ai review this PR”
   • [claimed-docs] “Interact with cubic in PR comments to ask questions, trigger reviews, and fix issues. You can tag `@cubic-dev-ai` directly, or reply to cubi…”
   • [claimed-docs] “Connect cubic's MCP server to your coding agent to read review findings and codebase context, request PR reviews, and triage PR or codebase …”
   • [claimed-docs] “You can now ask your coding agent to check your cubic subscription, manage team seats and roles, and purchase more seats without leaving you…”
   • [claimed-docs] “When a pull request needs extra scrutiny, you can ask cubic for an Ultrareview.”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Qodo—none0/10

   No evidence of an interactive API reference or runnable examples; the openapi probe explicitly returned 404 for all candidate paths, and no docs mention a sandbox/playground for API exploration.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.qodo.ai/openapi.json, https://docs.qodo.ai/swagger.json, https://docs.qodo.ai/api/opena…”

   proof ↗⚑ flag

   cubic—none0/10

   There is an Analytics API mentioned but no evidence of an interactive API reference or runnable examples; probes explicitly show no OpenAPI/swagger spec found (all candidate paths 404), indicating no interactive API documentation exists.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cubic.dev/openapi.json, https://docs.cubic.dev/swagger.json, https://docs.cubic.dev/api…”
   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Qodo—none0/10

   A direct probe for OpenAPI/Swagger specs at common paths returned 404s, and no documentation references a downloadable machine-readable API spec; only an llms.txt file and MCP/CLI tooling are documented, which are not equivalent to an API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.qodo.ai/openapi.json, https://docs.qodo.ai/swagger.json, https://docs.qodo.ai/api/opena…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.qodo.ai/llms.txt # Qodo Qodo is an AI code review and governance platform for engineering teams. I…”

   proof ↗⚑ flag

   cubic—none0/10

   cubic has an Analytics API but there is no documented machine-readable OpenAPI spec or equivalent; a direct probe for openapi.json/swagger.json at standard paths returned 404 across all candidates.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cubic.dev/openapi.json, https://docs.cubic.dev/swagger.json, https://docs.cubic.dev/api…”
   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”

   proof ↗⚑ flag

3. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Qodo—none0/10

   No evidence of a versioned API or a documented deprecation policy; the openapi.json probe found only 404s, and no changelog/versioning policy for APIs is mentioned. missing for 10: versioned public API reference, explicit API deprecation/versioning policy documentation, evidence of API version negotiation.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.qodo.ai/openapi.json, https://docs.qodo.ai/swagger.json, https://docs.qodo.ai/api/opena…”

   proof ↗⚑ flag

   cubic—none0/10

   There is an Analytics API mentioned, but no evidence of versioning scheme or a documented deprecation policy; the openapi probe returned 404s across all candidate paths, indicating no discoverable API spec/versioning docs.

   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cubic.dev/openapi.json, https://docs.cubic.dev/swagger.json, https://docs.cubic.dev/api…”

   proof ↗⚑ flag

Ai authored

1. ai-native userThe reviewer holds the line on AI-generated PRs — it verifies agent-authored code at a volume no human team could review

   weight 2 · round to cubic
   Qodo~partialcommunity7/10

   Qodo automatically reviews every PR, surfaces ranked findings with severity/rationale, supports blast-radius risk classification to triage high-risk changes, and offers governance/config-as-code to enforce standards at scale — all pointing at reviewing AI-authored code at volume. However, there's no explicit evidence or metrics about reviewing agent-authored PRs specifically at a volume beyond human capacity, nor independent/hands-on validation of throughput or accuracy claims; one community comment even shows a long-time user switching away to a competitor. Missing for 10: quantified throughput/scale benchmarks for agent-authored PRs, explicit agent-vs-human-authored PR handling, and independent corroboration of review quality at scale.

   • [claimed-docs] “Once connected, Qodo automatically reviews every pull request in your li”
   • [claimed-docs] “every finding states what needs attention, why it matters, and how to fix it, ranked by severity”
   • [claimed-docs] “Qodo makes this classification available as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), so you can triage which pull…”
   • [claimed-docs] “Qodo automatically classifies the risk of a code change and can publish it as a native label in the pull request, helping teams triage which…”
   • [claimed-docs] “Qodo governance is built for engineering leaders who need consistent standards enforced across every repository, automatically, at scale, an…”
   • [claimed-docs] “The review focuses on surfacing issues that matter, explaining why they matter, and helping developers resolve them efficiently, without ove…”
   • [community] “Was using their bot for code review for last 2 years but just dropped it for BugBot”

   proof ↗⚑ flag

   cubic✓fullcommunity8/10

   cubic is explicitly built to auto-review every PR, run deep Ultrareview/codebase scans deploying 'thousands of AI agents,' auto-fix and auto-approve, and surface analytics specifically tracking AI-authored code volume — directly matching the story of scaling review beyond human capacity. Community feedback (cubic-comm-1) corroborates real-world value, though cubic-comm-2 raises a substantive critique that YAML-based rules are less robust than code-based checks, a minor caveat rather than a contradiction of the core capability. Missing for 10: independent large-scale benchmark/study proving review quality holds at massive AI-PR volume, and more than two community data points.

   • [claimed-docs] “Once installed, cubic automatically reviews new pull requests.”
   • [claimed-docs] “Codebase scans deploy thousands of AI agents to find bugs and vulnerabilities across your repository.”
   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”
   • [claimed-docs] “Flex capacity keeps GitHub PR AI reviews running after your workspace uses its included reviewed-line capacity.”
   • [claimed-docs] “The AI coding tab shows how AI assistants contribute to merged pull requests in your repositories.”
   • [claimed-docs] “The AI automatically scans every pull request for a wide range of issues, including logic errors, style inconsistencies, and potential secur…”
   • [claimed-docs] “Auto-approval lets you skip human review for pull requests that cubic determines are low risk and issue-free.”
   • [community] “I really liked it - it hit the mark. The current balance works very well, and it genuinely surprised me. It provides more technical explanat…”
   • [community] “The 'in-codebase' approach is the right one, but a YAML file with plain text is a half-measure. The most reliable rule that 'lives next to t…”

   proof ↗⚑ flag

Checks

1. ai-native userI define custom agentic pre-merge checks in plain language — 'docs updated', 'tests cover new paths' — that run on every PR

   weight 2 · round to cubic
   Qodo~partialclaimed5/10

   Qodo does support defining and enforcing custom engineering standards via a centralized rule system, config-as-code (.pr_agent.toml), and Rule Miner that generates rules from PR history, which are automatically applied on every PR review. However, the evidence never shows a documented feature for writing arbitrary plain-language pre-merge gates like 'docs updated' or 'tests cover new paths' that block/pass PRs as discrete agentic checks. Missing for 10: explicit examples of natural-language custom check definitions, evidence of pass/fail merge-gating behavior, and confirmation these rules run as discrete checks rather than general review guidance.

   • [claimed-docs] “Manage Qodo configuration as code using a .pr\_agent.toml file at the repository, project, group, or organization level.”
   • [claimed-docs] “Define and enforce engineering standards with a centralized rule system.”
   • [claimed-docs] “Generate rules from pull request history with Rule Miner”
   • [claimed-docs] “Manage Qodo configuration as code using a .pr_agent.toml file at the repository, project, group, or organization level.”

   proof ↗⚑ flag

   cubic✓fullcommunity7/10

   cubic's 'Custom agents' feature lets teams define plain-language review rules enforcing org-specific best practices, stored in cubic.yaml, applied automatically across every PR, with a community library for adoption — directly matching the story of custom agentic pre-merge checks defined in plain language. Missing for 10: no first-party example matching the exact 'docs updated' / 'tests cover new paths' phrasing, and no independent hands-on validation of how reliably these plain-text rules enforce (one community comment raises skepticism about plain-text rule reliability vs. hard-coded checks, though this is not a concrete failure report).

   • [claimed-docs] “Custom agents are review rules that enforce your organization's specific best practices across pull requests.”
   • [claimed-docs] “Custom agents: Enforce your team's coding standards”
   • [claimed-docs] “You can also adopt existing agents from the community library with a single click.”
   • [claimed-docs] “cubic.yaml lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, an…”
   • [claimed-docs] “`cubic.yaml` lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, …”
   • [community] “The 'in-codebase' approach is the right one, but a YAML file with plain text is a half-measure. The most reliable rule that 'lives next to t…”

   proof ↗⚑ flag

Fixes

1. developerI turn a review finding into an applied fix — a committed patch or an agent-generated follow-up — without leaving the PR

   weight 3 · round to cubic
   Qodo✓fullclaimed7/10

   Qodo's docs explicitly describe turning a review finding into an applied fix within the PR: 'Discuss or dismiss a finding, or let Qodo apply the fix directly' and 'Chat with Qodo... directly inside pull requests,' plus MCP/CLI/agent-plugin tools to 'retrieve and resolve review findings' for follow-up agent workflows (Claude, Codex, Kiro). This covers both the committed-patch and agent-generated-follow-up paths without leaving the PR context. Missing for 10: independent/hands-on confirmation that the 'apply fix directly' button reliably produces a working commit, and no community evidence specifically validating this exact workflow.

   • [claimed-docs] “Discuss or dismiss a finding, or let Qodo apply the fix directly.”
   • [claimed-docs] “Retrieve and resolve review findings.”
   • [claimed-docs] “Chat with Qodo to interact with Qodo directly inside pull requests.”
   • [claimed-docs] “Use Qodo with Claude to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resolving code review fin…”
   • [claimed-docs] “Use the Qodo plugin with the Codex agent to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resol…”
   • [claimed-docs] “Use Qodo with the Kiro agent to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resolving code re…”
   • [claimed-docs] “Use MCP when you want to connect Qodo Agentic Toolbox managed skills to a remote or custom agent, workflow, or application.”

   proof ↗⚑ flag

   cubic✓fullclaimed8/10

   cubic lets developers turn review findings into applied fixes directly in the PR: it can generate a fix and push it to the PR branch, offers a one-click 'Fix with cubic' button, and its coding-agent/MCP integration lets an agent read findings and generate follow-up fixes without leaving the PR workflow. Auto-resolve threads and interactive PR comments reinforce that the fix loop stays within the PR. Missing for 10: independent/hands-on verification of the auto-fix push actually working in practice beyond vendor docs, and more detail on failure/edge cases of the auto-fix flow.

   • [claimed-docs] “cubic generates the fix and pushes it to your PR branch.”
   • [claimed-docs] “cubic can automatically fix issues in the background. When the AI spots a problem, you can click the **Fix with cubic** button”
   • [claimed-docs] “cubic can automatically fix issues identified during code review. Request a targeted fix with one click.”
   • [claimed-docs] “Auto-resolve threads: Enable automatic thread resolution to close findings when the issue is fixed”
   • [claimed-docs] “Interact with cubic in PR comments to ask questions, trigger reviews, and fix issues.”
   • [claimed-docs] “Connect cubic's MCP server to your coding agent to read review findings and codebase context, request PR reviews, and triage PR or codebase …”
   • [claimed-docs] “Coding agents: Generate fixes when requested, using your configured provider”

   proof ↗⚑ flag

Handoff

1. ai-native userReview findings hand off cleanly to my coding agent — copyable fix prompts or direct integration with Claude Code, Cursor, or Codex

   weight 2 · round to cubic
   Qodo✓fullprobed7/10

   Qodo's Agentic Toolbox explicitly ships review-finding resolution into coding agents via a Claude Code plugin, a Codex plugin, a CLI ('Retrieve and resolve review findings'), and an MCP server for connecting to 'a remote or custom agent, workflow, or application' (which would cover Cursor). This directly matches the hand-off-to-coding-agent story. Missing for 10: an explicit named Cursor plugin/integration, independent/hands-on confirmation that the hand-off works smoothly in practice, and details on the 'copyable fix prompt' UX itself.

   • [claimed-docs] “The Qodo Agentic Toolbox brings Qodo's code understanding, coding standards, and review capabilities into your existing coding agent.”
   • [claimed-docs] “Retrieve and resolve review findings.”
   • [claimed-docs] “Use Qodo with Claude to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resolving code review fin…”
   • [claimed-docs] “Use the Qodo plugin with the Codex agent to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resol…”
   • [claimed-docs] “Use the Qodo Agentic Toolbox CLI when you want to use Qodo-managed skills locally.”
   • [claimed-docs] “Use MCP when you want to connect Qodo Agentic Toolbox managed skills to a remote or custom agent, workflow, or application.”
   • [probe] “official MCP server documented at https://docs.qodo.ai/agentic-toolbox/mcp”
   • [probe] “official CLI documented at https://docs.qodo.ai/agentic-toolbox/cli”

   proof ↗⚑ flag

   cubic✓fullprobed8/10

   cubic explicitly supports both hand-off paths: the CLI reviews local changes and 'generates a prompt that your coding agent can use to fix them' (cubic-docs-7), and cubic's MCP server lets you 'connect cubic's MCP server to your coding agent' with named support for Cursor, Claude Code, VS Code, Codex, and Gemini CLI (cubic-docs-8, cubic-docs-35). PR-level auto-fix ('Fix with cubic') that pushes fixes directly to the branch (cubic-docs-4, cubic-docs-29, cubic-docs-53) and coding-agent skills (cubic-docs-17) further reinforce clean hand-off to agents. Missing for 10: independent/hands-on confirmation that the generated prompts or MCP flow work smoothly in practice, and no community evidence specifically validating the agent hand-off UX.

   • [claimed-docs] “The **cubic CLI** reviews local changes before you push. It finds bugs and generates a prompt that your coding agent can use to fix them.”
   • [claimed-docs] “Connect cubic's MCP server to your coding agent to read review findings and codebase context, request PR reviews, and triage PR or codebase …”
   • [claimed-docs] “Install and connect cubic in Cursor, Claude Code, VS Code, Codex, Gemini CLI, or another coding tool.”
   • [claimed-docs] “cubic generates the fix and pushes it to your PR branch.”
   • [claimed-docs] “cubic can automatically fix issues in the background. When the AI spots a problem, you can click the **Fix with cubic** button”
   • [claimed-docs] “cubic can automatically fix issues identified during code review. Request a targeted fix with one click.”
   • [claimed-docs] “cubic skills give your coding agent instructions for reviewing code, handling PR comments, and using your team's codebase context.”
   • [probe] “official MCP server documented at https://docs.cubic.dev/ide/mcp-server”
   • [probe] “official CLI documented at https://docs.cubic.dev/ide/cli-review”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Qodo~partialclaimed5/10

   Qodo's docs describe automatic, organization-wide operations that touch many items at once — it reviews every PR in a connected list, applies org-level configuration to all repositories, and enforces governance/standards 'across every repository, automatically, at scale' — which is a form of bulk operation. However there's no explicit documentation of a user-triggered bulk action (e.g., select multiple PRs/findings and apply a fix or dismiss in one operation) or independent evidence of this working at scale in practice. Missing for 10: explicit bulk-action UI/API across arbitrary item sets, hands-on/independent verification of scale performance, and confirmation that fixes/findings can be batch-resolved rather than one PR at a time.

   • [claimed-docs] “Once connected, Qodo automatically reviews every pull request in your li”
   • [claimed-docs] “Organization level (default): Settings apply to all connected repositories. Repository level: Settings apply only to the selected repository…”
   • [claimed-docs] “Qodo governance is built for engineering leaders who need consistent standards enforced across every repository, automatically, at scale, an…”
   • [claimed-docs] “Generate rules from pull request history with Rule Miner”
   • [claimed-docs] “The recommended way to manage organization-wide and repository-level code review configuration, from the Configurations page in the Qodo por…”

   proof ↗⚑ flag

   cubic~partialclaimed5/10

   cubic supports some bulk-scale automation — codebase scans that 'deploy thousands of AI agents to find bugs and vulnerabilities across your repository' (cubic-docs-12) and an Analytics API that aggregates PR-level data across many PRs (cubic-docs-16, cubic-docs-59) — but there is no evidence of user-triggered bulk operations like batch-fixing, batch-approving, or batch-triaging many PRs/items at once beyond per-PR auto-approval and auto-fix. Missing for 10: explicit bulk/batch action UI or API (e.g., select-many-and-fix, bulk approve across PRs), evidence of scale/performance at bulk volume, and independent confirmation of the codebase-scan bulk claim.

   • [claimed-docs] “Codebase scans deploy thousands of AI agents to find bugs and vulnerabilities across your repository.”
   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”
   • [claimed-docs] “The analytics dashboard shows how your team ships code across three lenses: AI coding usage, AI review impact, and delivery speed.”
   • [claimed-docs] “Cross-repo reviews help cubic catch changes that need a matching update in another repository. Link related repositories so reviews can chec…”
   • [claimed-docs] “Enable [auto-approval](/ai-review/auto-approval) to let cubic approve PRs that meet your review policy.”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Qodo
   Qodo~partialclaimed6/10

   Qodo documents a rule system for coding standards (qodo-docs-12, qodo-docs-13 Rule Miner) and automatic triggering of reviews on PR events with configurable rules (qodo-docs-26), plus config-as-code and org-wide enforcement (qodo-docs-11, qodo-docs-38). However, the 'rules' are scoped to code review/standards enforcement rather than a general-purpose event→action automation engine (e.g., arbitrary triggers/actions beyond reviews), and there's no independent/hands-on evidence confirming custom rule-trigger behavior works as described. Missing for 10: evidence of broader event types/actions beyond PR review triggering, and independent corroboration of rule automation working reliably.

   • [claimed-docs] “Define and enforce engineering standards with a centralized rule system.”
   • [claimed-docs] “Generate rules from pull request history with Rule Miner”
   • [claimed-docs] “Trigger a Qodo code review manually or automatically, and control when reviews run on a pull request.”
   • [claimed-docs] “Qodo governance is built for engineering leaders who need consistent standards enforced across every repository, automatically, at scale, an…”
   • [claimed-docs] “Manage Qodo configuration as code using a .pr\_agent.toml file at the repository, project, group, or organization level.”

   proof ↗⚑ flag

   cubic~partialcommunity5/10

   cubic supports event-triggered automation within its code-review domain: PRs auto-trigger reviews, custom agents enforce rules on PRs, auto-approval and auto-fix run on policy conditions, and cubic.yaml configures behavior — but this is domain-specific (PR/code-review events) rather than a general-purpose rules engine for arbitrary events/actions that an AI-native user could define. Missing for 10: evidence of a generalized rule/trigger builder spanning arbitrary event sources and actions beyond PR review workflows, and independent hands-on validation of custom-agent rule reliability (community feedback questions robustness of YAML-based rules).

   • [claimed-docs] “Once installed, cubic automatically reviews new pull requests.”
   • [claimed-docs] “Custom agents are review rules that enforce your organization's specific best practices across pull requests.”
   • [claimed-docs] “Enable [auto-approval](/ai-review/auto-approval) to let cubic approve PRs that meet your review policy.”
   • [claimed-docs] “Enable auto-approval to let cubic approve PRs that meet your review policy.”
   • [claimed-docs] “cubic can automatically fix issues in the background. When the AI spots a problem, you can click the **Fix with cubic** button”
   • [claimed-docs] “cubic.yaml lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, an…”
   • [claimed-docs] “Auto-approval lets you skip human review for pull requests that cubic determines are low risk and issue-free.”
   • [community] “The 'in-codebase' approach is the right one, but a YAML file with plain text is a half-measure. The most reliable rule that 'lives next to t…”

   proof ↗⚑ flag

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Qodo
   Qodo~partialclaimed4/10

   Qodo supports managing its review configuration "as code" via a .pr_agent.toml file at repo/org level, which implies git-based versioning and rollback of automation settings, and offers org vs repo-level overrides in the portal. However, there is no explicit documented version-history UI or one-click rollback feature for automations/configurations themselves. Missing for 10: dedicated version history/audit trail for config changes, explicit rollback mechanism beyond inferred git revert, and any review workflow specifically for undoing automation changes.

   • [claimed-docs] “Manage Qodo configuration as code using a .pr\_agent.toml file at the repository, project, group, or organization level.”
   • [claimed-docs] “Manage Qodo configuration as code using a .pr_agent.toml file at the repository, project, group, or organization level.”
   • [claimed-docs] “Organization level (default): Settings apply to all connected repositories. Repository level: Settings apply only to the selected repository…”
   • [claimed-docs] “The recommended way to manage organization-wide and repository-level code review configuration, from the Configurations page in the Qodo por…”
   • [claimed-docs] “Choose a ready-made preset, Minimal, Standard, Comprehensive, or Custom, instead of setting each Display option individually.”

   proof ↗⚑ flag

   cubic~partialclaimed3/10

   cubic's configuration (custom agents, review policies) lives in a `cubic.yaml` file at the repo root, which implies it inherits standard git version control (commit history, diff, revert) for review and rollback, but there is no dedicated in-product versioning, audit trail, or rollback UI/feature described for cubic's automations (custom agents, auto-approval rules, etc.). Missing for 10: explicit in-product version history/changelog for custom agents or review policies, a documented rollback mechanism beyond generic git, and any review workflow specifically for automation configuration changes.

   • [claimed-docs] “`cubic.yaml` lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, …”
   • [claimed-docs] “cubic.yaml lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, an…”
   • [claimed-docs] “Custom agents are review rules that enforce your organization's specific best practices across pull requests.”
   • [claimed-docs] “Custom agents: Enforce your team's coding standards”

   proof ↗⚑ flag

Context

1. engineering leadThe reviewer understands changes that span multiple repositories or a large monorepo and reviews them coherently

   weight 2 · round drawn
   Qodo~partialclaimed7/10

   Qodo's docs describe cross-repo/system-level features relevant to an engineering lead reviewing multi-repo or monorepo changes: a 'Software Map' and code-governance view that shows 'how repositories, services and teams are connected to understand how code changes impact the full system' (qodo-docs-14, qodo-docs-34), org-wide risk/blast-radius classification and PR labeling for triage (qodo-docs-8, qodo-docs-25), and org-level configuration applied across all connected repositories (qodo-docs-10). Reviews also use full-codebase context rather than just the diff (qodo-docs-22). Missing for 10: explicit monorepo-specific handling/performance claims, independent or hands-on validation of cross-repo coherence, and concrete examples of reviewing a single change spanning multiple repos.

   • [claimed-docs] “Learn how repositories, services and teams are connected to understand how code changes impact the full system.”
   • [claimed-docs] “Software Map gives you a live view”
   • [claimed-docs] “Qodo makes this classification available as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), so you can triage which pull…”
   • [claimed-docs] “Qodo automatically classifies the risk of a code change and can publish it as a native label in the pull request, helping teams triage which…”
   • [claimed-docs] “Organization level (default): Settings apply to all connected repositories. Repository level: Settings apply only to the selected repository…”
   • [claimed-docs] “Qodo reviews the full codebase, not just the diff, to generate a structured summary of the pull request (PR) that gives reviewers meaningf”
   • [claimed-docs] “Qodo governance is built for engineering leaders who need consistent standards enforced across every repository, automatically, at scale, an…”

   proof ↗⚑ flag

   cubic~partialclaimed7/10

   cubic explicitly ships cross-repo reviews (link related repositories so reviews can check shared APIs/schemas/docs) and codebase-wide indexing via AI wiki and codebase scans, which support coherent understanding of changes spanning repos or large codebases. However, evidence is entirely vendor docs with no independent/hands-on validation of monorepo-scale coherence, and the cross-repo feature description is thin (only checking shared APIs/schemas, not full monorepo-scale reasoning). Missing for 10: independent/hands-on evidence of multi-repo review coherence at scale, explicit monorepo support details, and any case study of large/complex spanning changes reviewed successfully.

   • [claimed-docs] “Link related repositories so reviews can check shared APIs, schemas, docs, or release work.”
   • [claimed-docs] “Cross-repo reviews help cubic catch changes that need a matching update in another repository. Link related repositories so reviews can chec…”
   • [claimed-docs] “Codebase scans deploy thousands of AI agents to find bugs and vulnerabilities across your repository.”
   • [claimed-docs] “cubic's AI wiki automatically indexes your codebase and produces searchable wikis, complete with links to source code, architecture diagrams…”

   proof ↗⚑ flag

2. developerReview comments reflect the whole repository — call sites, related modules, existing conventions — not just the changed hunks

   weight 3 · round to Qodo
   Qodo✓fullclaimed8/10

   Qodo explicitly documents that it 'reviews the full codebase, not just the diff' to generate context-aware summaries, surfaces related pull requests via a Relevance section, maps repository/service/team connections to understand system-wide impact, and enforces org-wide coding conventions via a centralized rule system — directly supporting repo-wide, cross-module review context beyond changed hunks. Missing for 10: independent/hands-on verification that comments concretely reference call sites and existing conventions in practice, rather than only documented capability claims.

   • [claimed-docs] “Qodo reviews the full codebase, not just the diff, to generate a structured summary of the pull request (PR) that gives reviewers meaningf”
   • [claimed-docs] “The **Relevance** section highlights related pull requests wi”
   • [claimed-docs] “Learn how repositories, services and teams are connected to understand how code changes impact the full system.”
   • [claimed-docs] “Define and enforce engineering standards with a centralized rule system.”
   • [claimed-docs] “Qodo governance is built for engineering leaders who need consistent standards enforced across every repository, automatically, at scale, an…”
   • [claimed-docs] “The review focuses on surfacing issues that matter, explaining why they matter, and helping developers resolve them efficiently, without ove…”

   proof ↗⚑ flag

   cubic~partialclaimed7/10

   cubic's docs describe repo-wide context mechanisms beyond the diff: it auto-detects context files (README, AGENTS.md, .cursorrules), links related repositories for cross-repo reviews of shared APIs/schemas, runs codebase scans across the whole repo, builds an AI wiki index of the codebase, and learns 'unwritten rules' from senior engineers' historical reviews and team feedback — all suggesting reviews draw on broader repository knowledge, not just changed hunks. However, no evidence explicitly confirms it traces call sites or cross-references unrelated modules within a single-repo review, and there's no independent/hands-on corroboration of this specific behavior. Missing for 10: explicit call-site/dependency-tracing evidence, independent verification that review comments actually cite non-hunk code.

   • [claimed-docs] “cubic automatically detects and uses context files in your repository, including `README.md`, `context.md`, `AGENTS.md`, `.cursorrules`”
   • [claimed-docs] “cubic automatically detects and uses context files in your repository, including `README.md`, `context.md`, `AGENTS.md`, `.cursorrules`, age…”
   • [claimed-docs] “Link related repositories so reviews can check shared APIs, schemas, docs, or release work.”
   • [claimed-docs] “Cross-repo reviews help cubic catch changes that need a matching update in another repository. Link related repositories so reviews can chec…”
   • [claimed-docs] “Codebase scans deploy thousands of AI agents to find bugs and vulnerabilities across your repository.”
   • [claimed-docs] “cubic's AI wiki automatically indexes your codebase and produces searchable wikis, complete with links to source code, architecture diagrams…”
   • [claimed-docs] “cubic learns your team's unwritten rules from two sources: direct feedback on its comments, and patterns extracted from your senior engineer…”

   proof ↗⚑ flag

Memory

1. ai-native userThe reviewer builds a persistent memory of my team's conventions and past review decisions and applies it to future PRs

   weight 2 · round to cubic
   Qodo✓fullclaimed7/10

   Qodo documents a persistent memory system for conventions via a 'centralized rule system' and 'Rule Miner' that generates rules from PR history (qodo-docs-12, qodo-docs-13), plus a full history of past findings/decisions/codebase health (qodo-docs-15) and governance enforced automatically across repos (qodo-docs-38), with rules retrievable per task (qodo-docs-7) and configurable as code across org/repo levels (qodo-docs-11/36). This directly matches building and applying institutional memory to future PRs. Missing for 10: independent/hands-on validation of Rule Miner's accuracy or how conventions evolve over time, and no community evidence corroborating this specific memory feature.

   • [claimed-docs] “Define and enforce engineering standards with a centralized rule system.”
   • [claimed-docs] “Generate rules from pull request history with Rule Miner”
   • [claimed-docs] “See a complete history of findings, decisions, and codebase health.”
   • [claimed-docs] “Qodo governance is built for engineering leaders who need consistent standards enforced across every repository, automatically, at scale, an…”
   • [claimed-docs] “Retrieve the rules and standards that apply to a task.”
   • [claimed-docs] “Manage Qodo configuration as code using a .pr\_agent.toml file at the repository, project, group, or organization level.”
   • [claimed-docs] “Manage Qodo configuration as code using a .pr_agent.toml file at the repository, project, group, or organization level.”

   proof ↗⚑ flag

   cubic✓fullcommunity8/10

   cubic explicitly documents persistent memory: it learns from replies/reactions to its comments and from patterns in senior engineers' historical reviews, storing conventions in cubic.yaml and custom agents that persist across PRs and repos (cubic-docs-10,32,33,54,9,11,34). This directly matches the ai-native persona's desire for a reviewer that builds team-convention memory over time. Missing for 10: independent/hands-on verification that learned rules actually persist and improve accuracy over many PRs (one community comment questions whether YAML-based rules are robust vs. hard failures, cubic-comm-2), and no quantitative data on learning effectiveness.

   • [claimed-docs] “cubic automatically learns when you: Reply to its comments... React to suggestions: Thumbs up/down help cubic calibrate what's useful vs noi…”
   • [claimed-docs] “Reply to its comments: Type a response explaining what cubic should do differently, and it remembers for next time”
   • [claimed-docs] “React to suggestions: Thumbs up/down help cubic calibrate what's useful vs noise for your specific codebase”
   • [claimed-docs] “cubic learns your team's unwritten rules from two sources: direct feedback on its comments, and patterns extracted from your senior engineer…”
   • [claimed-docs] “Custom agents are review rules that enforce your organization's specific best practices across pull requests.”
   • [claimed-docs] “`cubic.yaml` lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, …”
   • [claimed-docs] “cubic.yaml lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, an…”
   • [community] “The 'in-codebase' approach is the right one, but a YAML file with plain text is a half-measure. The most reliable rule that 'lives next to t…”

   proof ↗⚑ flag

Chat

1. developerI reply to the reviewer in the PR thread to ask questions, get explanations, or issue commands — and it answers in context

   weight 2 · round to cubic
   Qodo✓fullclaimed7/10

   Qodo docs explicitly describe an in-PR chat feature ('Chat with Qodo to interact with Qodo directly inside pull requests') plus the ability to discuss or dismiss findings within the thread, matching the story of replying to the reviewer for questions/commands with contextual answers. Missing for 10: independent/hands-on verification of chat quality and context-awareness, and no detail on the range of commands supported beyond discuss/dismiss/apply-fix.

   • [claimed-docs] “Chat with Qodo to interact with Qodo directly inside pull requests.”
   • [claimed-docs] “Discuss or dismiss a finding, or let Qodo apply the fix directly.”
   • [claimed-docs] “every finding states what needs attention, why it matters, and how to fix it, ranked by severity”

   proof ↗⚑ flag

   cubic✓fullcommunity8/10

   Docs explicitly describe replying to cubic's PR comments to ask questions, get clarifications, issue fix commands, or trigger reviews/Ultrareview, with cubic responding in-thread and even learning from replies. This is well documented across multiple pages (interactive-comments, memory-and-learning, quickstart) and corroborated by a community user noting cubic gives deeper technical explanations than plain LLMs. missing for 10: independent hands-on verification of multi-turn contextual follow-up quality/accuracy in real threads.

   • [claimed-docs] “Reply to a review comment to ask for clarification:”
   • [claimed-docs] “Reply to a review comment to ask for clarification”
   • [claimed-docs] “Interact with cubic in PR comments to ask questions, trigger reviews, and fix issues.”
   • [claimed-docs] “Interact with cubic in PR comments to ask questions, trigger reviews, and fix issues. You can tag `@cubic-dev-ai` directly, or reply to cubi…”
   • [claimed-docs] “Reply to its comments: Type a response explaining what cubic should do differently, and it remembers for next time”
   • [claimed-docs] “When a pull request needs extra scrutiny, you can ask cubic for an Ultrareview.”
   • [community] “I really liked it - it hit the mark. The current balance works very well, and it genuinely surprised me. It provides more technical explanat…”

   proof ↗⚑ flag

Control

1. developerI control when reviews run — skip drafts, trigger on demand, filter by branch or label — so the bot shows up only when wanted

   weight 1 · round to Qodo
   Qodo~partialclaimed6/10

   Qodo docs explicitly state you can 'trigger a Qodo code review manually or automatically, and control when reviews run on a pull request' (qodo-docs-26), and configuration can be set at org/repo level or via a .pr_agent.toml config-as-code file (qodo-docs-10, qodo-docs-11), which implies fine-grained trigger control. However, the pack lacks explicit documentation of skipping draft PRs or filtering triggers by branch/label — the only label-related evidence is about risk classification tags for triage (qodo-docs-8, qodo-docs-25), not review-trigger filtering. Missing for 10: explicit doc/example of draft-PR skip, branch-based trigger rules, and label-based trigger filters.

   • [claimed-docs] “Trigger a Qodo code review manually or automatically, and control when reviews run on a pull request.”
   • [claimed-docs] “Organization level (default): Settings apply to all connected repositories. Repository level: Settings apply only to the selected repository…”
   • [claimed-docs] “Manage Qodo configuration as code using a .pr\_agent.toml file at the repository, project, group, or organization level.”
   • [claimed-docs] “Qodo makes this classification available as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), so you can triage which pull…”
   • [claimed-docs] “Qodo automatically classifies the risk of a code change and can publish it as a native label in the pull request, helping teams triage which…”

   proof ↗⚑ flag

   cubic~partialclaimed4/10

   cubic clearly supports on-demand triggering (@cubic-dev-ai review this PR, Ultrareview on demand) and configurable behavior via cubic.yaml (ignore patterns, review behavior), giving developers some control over when reviews run. However there is no explicit evidence of skipping draft PRs or filtering by branch/label — cubic.yaml's 'ignore patterns' are documented generically, not tied to draft/branch/label filters. Missing for 10: explicit draft-PR skip setting, branch-based trigger rules, label-based filtering documentation.

   • [claimed-docs] “Once installed, cubic automatically reviews new pull requests.”
   • [claimed-docs] “To review a PR that was opened _before_ you installed the app, comment: `@cubic-dev-ai review this PR`.”
   • [claimed-docs] “When a pull request needs extra scrutiny, you can ask cubic for an Ultrareview.”
   • [claimed-docs] “Ultrareview is cubic's deepest review. It runs a longer, multi-pass analysis using cubic's most capable review models, and typically takes a…”
   • [claimed-docs] “`cubic.yaml` lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, …”
   • [claimed-docs] “cubic.yaml lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, an…”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to cubic
   Qodo~partialprobed4/10

   Qodo exposes a CLI and MCP server (Agentic Toolbox) that let agents review changes, retrieve findings, and fetch rules/standards, and configuration can be managed as code via .pr_agent.toml — some UI functions are scriptable. However there is no documented public REST/OpenAPI API (probe found openapi endpoints 404), and most UI-only features (portal configuration, governance dashboards, risk/blast-radius labels, PR chat, relevance, software map) have no evidenced programmatic equivalent for full parity. Missing for 10: a documented public API/OpenAPI spec, and API-equivalents for governance, risk classification, dashboards, and chat features shown only in the UI docs.

   • [claimed-docs] “Use the Qodo Agentic Toolbox CLI when you want to use Qodo-managed skills locally.”
   • [claimed-docs] “Use MCP when you want to connect Qodo Agentic Toolbox managed skills to a remote or custom agent, workflow, or application.”
   • [claimed-docs] “Retrieve and resolve review findings.”
   • [claimed-docs] “Retrieve the rules and standards that apply to a task.”
   • [claimed-docs] “Manage Qodo configuration as code using a .pr\_agent.toml file at the repository, project, group, or organization level.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.qodo.ai/openapi.json, https://docs.qodo.ai/swagger.json, https://docs.qodo.ai/api/opena…”
   • [probe] “official MCP server documented at https://docs.qodo.ai/agentic-toolbox/mcp”
   • [probe] “official CLI documented at https://docs.qodo.ai/agentic-toolbox/cli”

   proof ↗⚑ flag

   cubic~partialprobed5/10

   cubic exposes some programmatic surfaces beyond the UI — an Analytics API for PR-level metrics, an official MCP server for review findings/PR reviews/triage/subscription management, and a CLI for local review — but there is no general public REST/OpenAPI covering full platform functionality (probe found openapi.json/swagger.json all 404), so many UI features (wiki, custom agents config, integrations, analytics dashboards) lack documented API parity. missing for 10: a comprehensive public API/OpenAPI spec covering all UI capabilities, evidence that wiki/integrations/custom-agent configuration can be done via API, and confirmation that Analytics API + MCP together achieve full UI parity.

   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”
   • [claimed-docs] “Connect cubic's MCP server to your coding agent to read review findings and codebase context, request PR reviews, and triage PR or codebase …”
   • [claimed-docs] “You can now ask your coding agent to check your cubic subscription, manage team seats and roles, and purchase more seats without leaving you…”
   • [claimed-docs] “The **cubic CLI** reviews local changes before you push. It finds bugs and generates a prompt that your coding agent can use to fix them.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cubic.dev/openapi.json, https://docs.cubic.dev/swagger.json, https://docs.cubic.dev/api…”
   • [probe] “official MCP server documented at https://docs.cubic.dev/ide/mcp-server”
   • [probe] “official CLI documented at https://docs.cubic.dev/ide/cli-review”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Qodo—none0/10

   No evidence of any data export feature, open-format export, or account/data portability mechanism; the only related item mentions strict data retention, not export, and there's no indication users can extract their review history, findings, or configuration data in a portable format. Missing for 10: any documented export/download feature, open format support, or data portability guarantee.

   • [claimed-docs] “Pricing FAQ: "Do you train AI models on my code? No. Qodo does not train models on your code. Your code is used only to generate reviews for…”

   proof ↗⚑ flag

   cubic—none0/10

   Cubic is a code review/analysis platform whose data (review findings, PR comments, analytics, wiki) lives in GitHub, Jira, Notion, etc.; there is no evidence of a data export feature for users to download their cubic-generated data in open formats. The Analytics API (cubic-docs-16) offers programmatic access to some metrics but this is not documented as a full data export/portability mechanism, and no evidence addresses exporting AI wiki content, review history, or memory/learning data.

   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”
   • [claimed-docs] “cubic's AI wiki automatically indexes your codebase and produces searchable wikis, complete with links to source code, architecture diagrams…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Qodo—none0/10

   No evidence Qodo's source code is available under an open license; Qodo is presented as a proprietary SaaS/on-prem product with no mention of open-sourcing its codebase.

   ⚑ flag

   cubic—none0/10

   No evidence indicates cubic's source code is open or under an open license; cubic appears to be a closed, commercial SaaS product with SOC2 compliance and privacy policies but no public repository or license mentioned.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Qodo
   Qodo✓fullclaimed7/10

   Qodo explicitly documents on-prem/self-managed deployment ('Deploy Qodo entirely within your own infrastructure', a dedicated on-prem deployment guide, and a deployment-model support table listing single-tenant, on-premises, and air-gapped options), directly satisfying the self-hosting story. Missing for 10: independent/hands-on confirmation that self-hosted deployments work as documented, and more detail on infrastructure requirements/limitations of the self-hosted mode.

   • [claimed-docs] “Deploy Qodo entirely within your own infrastructure.”
   • [claimed-docs] “This guide covers deploying Qodo in a self-managed infrastructure environment.”
   • [claimed-docs] “A reference table of supported deployment models for each Git provider, including multi-tenant, single-tenant, on-premises, and air-gapped o…”

   proof ↗⚑ flag

   cubic—none0/10

   cubic is presented entirely as a hosted SaaS (GitHub app, cloud-based review engine, subscription/seats, analytics API); there is no evidence of a self-hosted/on-prem deployment option, Docker image, or open-source core anywhere in the docs.

   ⚑ flag

Platforms

1. developerThe reviewer installs as a GitHub/GitLab app and posts reviews as native inline comments on my pull requests within minutes

   weight 3 · round to cubic
   Qodo✓fullclaimed7/10

   Docs describe connecting Qodo to GitHub/GitLab via a guided setup wizard, automatic reviews on every PR, findings surfaced with severity that can be discussed/dismissed, chat inside PRs, and native labels/tags posted directly on the PR — consistent with an app-based inline review flow. Missing for 10: explicit wording confirming comments are 'inline' code comments (vs. summary/PR-level), an explicit time-to-first-review claim ('minutes'), and independent/hands-on confirmation beyond vendor docs.

   • [claimed-docs] “Connect Qodo to your Git provider to enable automated code reviews directly in your pull requests.”
   • [claimed-docs] “Once connected, Qodo automatically reviews every pull request in your li”
   • [claimed-docs] “After signing in for the first time, a setup wizard guides you through connecting Qodo to your development environment.”
   • [claimed-docs] “every finding states what needs attention, why it matters, and how to fix it, ranked by severity”
   • [claimed-docs] “Discuss or dismiss a finding, or let Qodo apply the fix directly.”
   • [claimed-docs] “Chat with Qodo to interact with Qodo directly inside pull requests.”
   • [claimed-docs] “Qodo automatically classifies the risk of a code change and can publish it as a native label in the pull request, helping teams triage which…”
   • [claimed-docs] “Trigger a Qodo code review manually or automatically, and control when reviews run on a pull request.”

   proof ↗⚑ flag

   cubic✓fullcommunity8/10

   Docs confirm installation as a GitHub/GitLab app with automatic reviews on new PRs, inline PR comments (@cubic-dev-ai, interactive comments, Fix with cubic), and a quickstart flow explicitly framed as 'minutes' with a free trial. Community feedback corroborates real-world usefulness of PR-level comments. Missing for 10: independent third-party confirmation of install speed and hands-on GitLab app usage (most evidence is first-party docs).

   • [claimed-docs] “Once installed, cubic automatically reviews new pull requests.”
   • [claimed-docs] “Spots bugs and improvements: Comments on bugs and improvements in pull requests”
   • [claimed-docs] “Interact with cubic in PR comments to ask questions, trigger reviews, and fix issues.”
   • [claimed-docs] “Get started with cubic AI code review in minutes.”
   • [claimed-docs] “Post this comment on GitHub to start a review: text theme={null} @cubic-dev-ai review this PR ”
   • [claimed-docs] “7 days free, no credit card required.”
   • [community] “I really liked it - it hit the mark. The current balance works very well, and it genuinely surprised me. It provides more technical explanat…”

   proof ↗⚑ flag

Suggestions

1. developerReview comments include committable suggested diffs I can apply with one click

   weight 3 · round drawn
   Qodo✓fullclaimed7/10

   Qodo's docs explicitly state that for each review finding you can 'discuss or dismiss a finding, or let Qodo apply the fix directly,' and findings include how-to-fix guidance, indicating one-click applicable suggested fixes within PR reviews (qodo-docs-2, qodo-docs-3). Missing for 10: explicit documentation of the diff/commit mechanics (e.g., 'commit suggestion' button semantics) and independent/hands-on confirmation from users that the apply-fix flow works as a one-click committable diff.

   • [claimed-docs] “every finding states what needs attention, why it matters, and how to fix it, ranked by severity”
   • [claimed-docs] “Discuss or dismiss a finding, or let Qodo apply the fix directly.”
   • [claimed-docs] “The review focuses on surfacing issues that matter, explaining why they matter, and helping developers resolve them efficiently, without ove…”

   proof ↗⚑ flag

   cubic✓fullclaimed7/10

   Cubic explicitly supports one-click fixes: reviewers can click 'Fix with cubic' and cubic generates the fix and pushes it directly to the PR branch (cubic-docs-4, cubic-docs-29, cubic-docs-53), fulfilling the core 'one-click apply' story for review comments. Missing for 10: no evidence of an inline GitHub-style suggested-diff block shown for manual approval before commit, and no independent/hands-on corroboration of this specific flow beyond first-party docs.

   • [claimed-docs] “cubic generates the fix and pushes it to your PR branch.”
   • [claimed-docs] “cubic can automatically fix issues in the background. When the AI spots a problem, you can click the **Fix with cubic** button”
   • [claimed-docs] “cubic can automatically fix issues identified during code review. Request a targeted fix with one click.”
   • [claimed-docs] “Coding agents: Generate fixes when requested, using your configured provider”

   proof ↗⚑ flag

Summaries

1. developerEvery PR gets an auto-generated summary and change walkthrough so human reviewers orient fast

   weight 2 · round drawn
   Qodo✓fullclaimed9/10

   Qodo docs explicitly describe generating a structured PR summary from the full codebase (not just diff) to orient reviewers, plus a Relevance section highlighting related PRs and chat-with-Qodo-in-PR for further orientation, all triggered automatically on every PR. Missing for 10: independent/hands-on community confirmation specifically of the summary/walkthrough feature (community evidence covers other aspects like CLI and pricing, not this specific feature).

   • [claimed-docs] “Qodo reviews the full codebase, not just the diff, to generate a structured summary of the pull request (PR) that gives reviewers meaningf”
   • [claimed-docs] “The **Relevance** section highlights related pull requests wi”
   • [claimed-docs] “Chat with Qodo to interact with Qodo directly inside pull requests.”
   • [claimed-docs] “Once connected, Qodo automatically reviews every pull request in your li”
   • [claimed-docs] “Trigger a Qodo code review manually or automatically, and control when reviews run on a pull request.”

   proof ↗⚑ flag

   cubic✓fullcommunity9/10

   cubic explicitly generates PR summaries/descriptions from code changes automatically on every PR (docs-21, docs-57), plus keeps the summary visible alongside the diff while scrolling for easier orientation (docs-43), and community feedback corroborates depth of explanations (cubic-comm-1). Missing for 10: independent/hands-on review specifically confirming summary accuracy or walkthrough quality at scale beyond docs and one community quote.

   • [claimed-docs] “PR summaries: Generates PR descriptions based on code changes”
   • [claimed-docs] “cubic helps your team spend less time writing PR descriptions automatically by generating clear, concise summaries.”
   • [claimed-docs] “Now, the group description stays beside the diff as you scroll, so you can read the code and its explanation together.”
   • [claimed-docs] “Spots bugs and improvements: Comments on bugs and improvements in pull requests”
   • [community] “I really liked it - it hit the mark. The current balance works very well, and it genuinely surprised me. It provides more technical explanat…”

   proof ↗⚑ flag

Updates

1. developerPushing new commits triggers an incremental re-review that tracks what was fixed instead of repeating old comments

   weight 2 · round to cubic
   Qodo~partialclaimed4/10

   Docs confirm reviews can be triggered automatically per push and controlled per PR (qodo-docs-26), and findings can be discussed/dismissed or auto-fixed (qodo-docs-3), implying some tracking of resolved issues, but there is no explicit documentation describing incremental re-review logic that specifically avoids repeating previously raised comments across new commits. missing for 10: explicit doc/example showing re-review skips already-addressed findings and only reports new/changed issues, independent confirmation of this behavior.

   • [claimed-docs] “Trigger a Qodo code review manually or automatically, and control when reviews run on a pull request.”
   • [claimed-docs] “Discuss or dismiss a finding, or let Qodo apply the fix directly.”
   • [claimed-docs] “The review focuses on surfacing issues that matter, explaining why they matter, and helping developers resolve them efficiently, without ove…”

   proof ↗⚑ flag

   cubic~partialclaimed6/10

   cubic auto-reviews new PRs and auto-resolves threads when issues are fixed (cubic-docs-1, cubic-docs-20), and its memory/learning system means feedback and prior comments inform future reviews (cubic-docs-10, cubic-docs-54), which together imply incremental re-review behavior rather than repeating stale comments. However, there's no explicit documentation describing a re-review triggered specifically by new commits that diffs against prior findings or explicitly states old fixed issues won't be re-flagged. missing for 10: explicit docs on commit-triggered incremental re-review logic, confirmation that previously-flagged-and-fixed issues are suppressed on subsequent pushes, and independent/hands-on evidence of this specific workflow.

   • [claimed-docs] “Once installed, cubic automatically reviews new pull requests.”
   • [claimed-docs] “Auto-resolve threads: Enable automatic thread resolution to close findings when the issue is fixed”
   • [claimed-docs] “cubic automatically learns when you: Reply to its comments... React to suggestions: Thumbs up/down help cubic calibrate what's useful vs noi…”
   • [claimed-docs] “cubic learns your team's unwritten rules from two sources: direct feedback on its comments, and patterns extracted from your senior engineer…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Qodo
   Qodo~partialclaimed5/10

   Qodo documents multiple deployment models—multi-tenant, single-tenant, on-premises, and air-gapped (qodo-docs-40, qodo-docs-39, qodo-docs-16)—which lets customers effectively control where their code/data resides by self-hosting infrastructure. However, there is no explicit 'choose a region' selector or data-residency policy for the standard SaaS offering, and qodo-supp-1 only addresses training/retention, not location. Missing for 10: explicit named regions/data centers for the hosted SaaS tier, and any documentation of a customer-facing region selection UI or policy.

   • [claimed-docs] “Deploy Qodo entirely within your own infrastructure.”
   • [claimed-docs] “This guide covers deploying Qodo in a self-managed infrastructure environment.”
   • [claimed-docs] “A reference table of supported deployment models for each Git provider, including multi-tenant, single-tenant, on-premises, and air-gapped o…”
   • [claimed-docs] “Pricing FAQ: "Do you train AI models on my code? No. Qodo does not train models on your code. Your code is used only to generate reviews for…”

   proof ↗⚑ flag

   cubic—none0/10

   No evidence of data residency/region selection options in cubic's documentation; privacy/security docs mention SOC 2 compliance and no third-party model training, but nothing about choosing storage region or data residency controls.

   • [claimed-docs] “Privacy & security: "No third-party model training on Customer Code — Our AI model providers (e.g., OpenAI, Anthropic) contractually commit …”
   • [claimed-docs] “Privacy & security: "cubic is SOC 2 Type 1 compliant, demonstrating our commitment to security and trust for our customers. We maintain comp…”

   proof ↗⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Qodo✓fullclaimed8/10

   Qodo's pricing/FAQ page explicitly states it does not train AI models on customer code and lists 'Strict data retention' as a feature, directly addressing the no-training-data story. This is first-party vendor commitment but lacks independent/hands-on corroboration or detailed technical enforcement documentation. Missing for 10: independent verification of the no-training claim, technical/contractual details on data retention enforcement.

   • [claimed-docs] “Pricing FAQ: "Do you train AI models on my code? No. Qodo does not train models on your code. Your code is used only to generate reviews for…”

   proof ↗⚑ flag

   cubic✓fullclaimed8/10

   cubic's privacy/security docs explicitly state model providers contractually commit to not train on customer code, and offer a full opt-out to block AI features entirely for a workspace. missing for 10: independent/third-party audit confirming the no-training claim, and detail on how the opt-out mechanism is enforced technically.

   • [claimed-docs] “Privacy & security: "No third-party model training on Customer Code — Our AI model providers (e.g., OpenAI, Anthropic) contractually commit …”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Qodo
   Qodo~partialclaimed4/10

   Qodo's pricing FAQ states it does not train models on customer code and lists 'Strict data retention' as a plan feature, and on-prem/self-hosted deployment is offered giving customers infrastructure-level control over data. However, there is no documented user-facing mechanism for explicit data deletion requests, retention period configuration, or export/erasure controls. missing for 10: explicit retention period settings, a documented data deletion/erasure workflow, independent verification of retention claims.

   • [claimed-docs] “Pricing FAQ: "Do you train AI models on my code? No. Qodo does not train models on your code. Your code is used only to generate reviews for…”
   • [claimed-docs] “This guide covers deploying Qodo in a self-managed infrastructure environment.”
   • [claimed-docs] “Deploy Qodo entirely within your own infrastructure.”

   proof ↗⚑ flag

   cubic~partialclaimed3/10

   cubic's privacy/security docs mention no third-party model training and the ability to block AI features for a workspace, showing some data-handling controls, but there is no explicit mention of data retention periods, deletion requests, or a self-service deletion mechanism. missing for 10: explicit retention policy, user-initiated deletion process, confirmation of deletion timelines/scope.

   • [claimed-docs] “Privacy & security: "No third-party model training on Customer Code — Our AI model providers (e.g., OpenAI, Anthropic) contractually commit …”
   • [claimed-docs] “Privacy & security: "cubic is SOC 2 Type 1 compliant, demonstrating our commitment to security and trust for our customers. We maintain comp…”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Qodo—none0/10

   Evidence only shows general data-usage claims (no model training on code, 'strict data retention') but nothing about a telemetry/usage-tracking opt-out setting or control. Missing for 10: any documented telemetry toggle, privacy settings page, or explicit usage-tracking opt-out mechanism.

   • [claimed-docs] “Pricing FAQ: "Do you train AI models on my code? No. Qodo does not train models on your code. Your code is used only to generate reviews for…”

   proof ↗⚑ flag

   cubic—none0/10

   Evidence covers data-training and access-control privacy commitments (no third-party model training, SOC2 compliance, ability to block AI features workspace-wide) but no documented telemetry/usage-tracking toggle or opt-out mechanism specifically for product analytics/telemetry.

   ⚑ flag

Analytics

1. engineering leadI see dashboards of findings, acceptance rates, and review coverage across my org

   weight 1 · round to cubic
   Qodo~partialclaimed6/10

   Qodo's code-governance docs describe org-wide history of findings/decisions, a 'Software Map' live view, and centralized rule enforcement built for engineering leaders (qodo-docs-15, qodo-docs-34, qodo-docs-38), plus risk labels for triage (qodo-docs-8/25) and org-level config controls (qodo-docs-10). However, no explicit evidence of an 'acceptance rate' metric or a 'review coverage' percentage dashboard is present — the docs describe findings history and codebase health qualitatively rather than as quantified acceptance/coverage KPIs. Missing for 10: explicit acceptance-rate metrics, explicit review-coverage percentage reporting, and independent/hands-on confirmation of the dashboard UI.

   • [claimed-docs] “See a complete history of findings, decisions, and codebase health.”
   • [claimed-docs] “Software Map gives you a live view”
   • [claimed-docs] “Qodo governance is built for engineering leaders who need consistent standards enforced across every repository, automatically, at scale, an…”
   • [claimed-docs] “Qodo makes this classification available as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), so you can triage which pull…”
   • [claimed-docs] “Qodo automatically classifies the risk of a code change and can publish it as a native label in the pull request, helping teams triage which…”
   • [claimed-docs] “Organization level (default): Settings apply to all connected repositories. Repository level: Settings apply only to the selected repository…”

   proof ↗⚑ flag

   cubic✓fullclaimed7/10

   cubic's Analytics dashboard explicitly covers PR-level findings/fixes, AI coding and AI review impact tabs, and delivery/effectiveness across repos, directly matching the engineering-lead dashboard story (cubic-docs-16, 41, 42, 59, 60). Missing for 10: explicit org-wide rollup UI screenshots, exact 'acceptance rate' terminology/metric definition, and independent/hands-on corroboration beyond vendor docs.

   • [claimed-docs] “The Analytics API gives you PR-level data on how many issues were flagged, how many were fixed, how much AI code was authored, etc.”
   • [claimed-docs] “The AI coding tab shows how AI assistants contribute to merged pull requests in your repositories.”
   • [claimed-docs] “The AI review tab shows whether cubic reviews are helping your team ship better code faster.”
   • [claimed-docs] “The analytics dashboard shows how your team ships code across three lenses: AI coding usage, AI review impact, and delivery speed.”
   • [claimed-docs] “The Delivery and effectiveness tab focuses on how quickly PRs move from creation to merge and where bottlenecks appear.”

   proof ↗⚑ flag

Gates

1. engineering leadThe reviewer can gate merges — a required status check or blocking review that enforces resolution of critical findings

   weight 2 · round drawn
   Qodo—none0/10

   Qodo's docs describe review findings, severity ranking, risk labels/tags for triage, and governance/standards enforcement, but nowhere document a required status check, branch-protection integration, or blocking-review mechanism that would prevent a merge until critical findings are resolved. Governance language (qodo-docs-38) speaks to standards consistency, not merge gating.

   • [claimed-docs] “Qodo makes this classification available as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), so you can triage which pull…”
   • [claimed-docs] “Qodo automatically classifies the risk of a code change and can publish it as a native label in the pull request, helping teams triage which…”
   • [claimed-docs] “Qodo governance is built for engineering leaders who need consistent standards enforced across every repository, automatically, at scale, an…”
   • [claimed-docs] “every finding states what needs attention, why it matters, and how to fix it, ranked by severity”
   • [claimed-docs] “Trigger a Qodo code review manually or automatically, and control when reviews run on a pull request.”

   proof ↗⚑ flag

   cubic—none0/10

   Cubic documents auto-approval (skipping human review for low-risk PRs) and auto-resolving comment threads, but there is no evidence of a required GitHub status check or blocking review policy that prevents merge until critical findings are resolved — the auto-approval feature actually works in the opposite direction (approving rather than blocking). Missing for full credit: documentation of a required/blocking check integration, branch-protection enforcement, or explicit 'block merge on critical findings' policy.

   • [claimed-docs] “Enable [auto-approval](/ai-review/auto-approval) to let cubic approve PRs that meet your review policy.”
   • [claimed-docs] “Auto-resolve threads: Enable automatic thread resolution to close findings when the issue is fixed”
   • [claimed-docs] “Auto-approval lets you skip human review for pull requests that cubic determines are low risk and issue-free.”

   proof ↗⚑ flag

Detection

1. developerThe reviewer catches real bugs in my PR — logic errors, race conditions, broken edge cases — not just style nits

   weight 3 · round to cubic
   Qodo~partialcommunity5/10

   Qodo's docs claim the reviewer surfaces 'issues that matter' with severity ranking and explanation, and reviews the full codebase (not just diff) for deeper context (qodo-docs-27, qodo-docs-22, qodo-docs-2), which supports the review-accuracy story. However, there is no independent or hands-on evidence confirming it actually catches logic errors, race conditions, or edge-case bugs specifically — all support is vendor-authored marketing copy, and one community comment reports a user dropping Qodo's review bot after two years for a competitor, hinting at unverified quality concerns without a concrete technical failure example. Missing for 10: independent benchmarks or hands-on examples of catching specific logic/concurrency bugs, third-party corroboration of low false-positive/style-nit ratio.

   • [claimed-docs] “The review focuses on surfacing issues that matter, explaining why they matter, and helping developers resolve them efficiently, without ove…”
   • [claimed-docs] “Qodo reviews the full codebase, not just the diff, to generate a structured summary of the pull request (PR) that gives reviewers meaningf”
   • [claimed-docs] “every finding states what needs attention, why it matters, and how to fix it, ranked by severity”
   • [community] “Was using their bot for code review for last 2 years but just dropped it for BugBot”

   proof ↗⚑ flag

   cubic✓fullcommunity7/10

   Cubic's docs explicitly claim to catch logic errors, bugs, and security vulnerabilities (not just style), with deep Ultrareview passes for complex refactors, and one independent HN commenter corroborates that it 'provides more technical explanations than just basic checks' and is 'really powerful.' However, race conditions and specific edge-case handling are not explicitly evidenced, and most support is vendor documentation rather than hands-on benchmarks. Missing for 10: independent benchmark/hands-on evidence of catching race conditions or subtle logic bugs specifically, broader third-party validation beyond a single HN comment.

   • [claimed-docs] “Spots bugs and improvements: Comments on bugs and improvements in pull requests”
   • [claimed-docs] “The AI automatically scans every pull request for a wide range of issues, including logic errors, style inconsistencies, and potential secur…”
   • [claimed-docs] “When a pull request needs extra scrutiny, you can ask cubic for an Ultrareview.”
   • [claimed-docs] “Ultrareview is cubic's deepest review. It runs a longer, multi-pass analysis using cubic's most capable review models, and typically takes a…”
   • [community] “I really liked it - it hit the mark. The current balance works very well, and it genuinely surprised me. It provides more technical explanat…”

   proof ↗⚑ flag

Learning

1. developerPush back on a bad review comment and the reviewer learns — it stops repeating the same rejected feedback

   weight 2 · round to cubic
   Qodo—none0/10

   Docs show developers can discuss or dismiss a finding (qodo-docs-3) and admins can centrally define/generate rules (qodo-docs-12, qodo-docs-13), but there is no evidence that a dismissed or pushed-back finding is remembered and suppressed in future reviews of similar code — i.e., no documented feedback loop that stops the reviewer from repeating the same rejected comment. Missing for 10: any documentation of per-finding dismissal memory, learning from rejected feedback, or reduced recurrence of the same flagged issue after pushback.

   • [claimed-docs] “Discuss or dismiss a finding, or let Qodo apply the fix directly.”
   • [claimed-docs] “Define and enforce engineering standards with a centralized rule system.”
   • [claimed-docs] “Generate rules from pull request history with Rule Miner”

   proof ↗⚑ flag

   cubic✓fullcommunity7/10

   cubic explicitly documents that replying to its comments teaches it 'what to do differently' and it 'remembers for next time,' with learning drawn from direct feedback and thumbs up/down reactions plus senior engineers' review patterns — directly matching the story of pushing back and the reviewer not repeating rejected feedback. However, this is entirely first-party documentation with no independent/hands-on confirmation that the learning actually persists or stops repeat comments in practice; one community comment expresses general skepticism about YAML-based rule interpretation but doesn't concretely show the learning failing. Missing for 10: independent hands-on verification that cubic stops repeating rejected feedback, and details on how long/broadly the learned preference applies.

   • [claimed-docs] “cubic automatically learns when you: Reply to its comments... React to suggestions: Thumbs up/down help cubic calibrate what's useful vs noi…”
   • [claimed-docs] “Reply to its comments: Type a response explaining what cubic should do differently, and it remembers for next time”
   • [claimed-docs] “React to suggestions: Thumbs up/down help cubic calibrate what's useful vs noise for your specific codebase”
   • [claimed-docs] “cubic learns your team's unwritten rules from two sources: direct feedback on its comments, and patterns extracted from your senior engineer…”
   • [community] “The 'in-codebase' approach is the right one, but a YAML file with plain text is a half-measure. The most reliable rule that 'lives next to t…”

   proof ↗⚑ flag

Noise

1. engineering leadThe reviewer keeps noise low — few false positives, deduplicated comments, severity labels — so my team doesn't tune it out

   weight 3 · round drawn
   Qodo~partialcommunity6/10

   Qodo's docs explicitly claim severity-ranked findings, low-signal filtering ('surfacing issues that matter... without overwhelming you with low-signal feedback'), risk/blast-radius labels for triage, and configurable display presets (Minimal/Standard/Comprehensive) that let teams tune noise. However there's no explicit 'deduplication' feature documented, and no independent/hands-on evidence confirming actual false-positive rates in practice — one community comment even reports a team abandoning Qodo's review bot for a competitor, though not specifically citing noise as the reason. missing for 10: explicit deduplication mechanism, independent benchmark or user testimonial confirming low false-positive rate in real-world use.

   • [claimed-docs] “every finding states what needs attention, why it matters, and how to fix it, ranked by severity”
   • [claimed-docs] “The review focuses on surfacing issues that matter, explaining why they matter, and helping developers resolve them efficiently, without ove…”
   • [claimed-docs] “Qodo makes this classification available as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), so you can triage which pull…”
   • [claimed-docs] “Qodo automatically classifies the risk of a code change and can publish it as a native label in the pull request, helping teams triage which…”
   • [claimed-docs] “Choose a ready-made preset, Minimal, Standard, Comprehensive, or Custom, instead of setting each Display option individually.”
   • [community] “Was using their bot for code review for last 2 years but just dropped it for BugBot”

   proof ↗⚑ flag

   cubic~partialcommunity6/10

   cubic documents concrete noise-reduction mechanisms: it learns from thumbs-up/down and reply feedback to calibrate 'what's useful vs noise' (cubic-docs-10, cubic-docs-32/33), learns unwritten rules from senior engineers' historical reviews (cubic-docs-54), supports ignore patterns/custom agents via cubic.yaml (cubic-docs-11), and auto-resolves threads once issues are fixed (cubic-docs-20). One community reviewer corroborates quality/technical depth (cubic-comm-1), while another raises skepticism about YAML-based rule reliability (cubic-comm-2), though this doesn't concretely contradict the noise-reduction claims. Missing for 10: explicit severity labeling of comments, explicit deduplication-of-comments mechanism, and independent data/benchmarks on false-positive rates.

   • [claimed-docs] “cubic automatically learns when you: Reply to its comments... React to suggestions: Thumbs up/down help cubic calibrate what's useful vs noi…”
   • [claimed-docs] “Auto-resolve threads: Enable automatic thread resolution to close findings when the issue is fixed”
   • [claimed-docs] “Reply to its comments: Type a response explaining what cubic should do differently, and it remembers for next time”
   • [claimed-docs] “React to suggestions: Thumbs up/down help cubic calibrate what's useful vs noise for your specific codebase”
   • [claimed-docs] “cubic learns your team's unwritten rules from two sources: direct feedback on its comments, and patterns extracted from your senior engineer…”
   • [claimed-docs] “`cubic.yaml` lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, …”
   • [community] “I really liked it - it hit the mark. The current balance works very well, and it genuinely surprised me. It provides more technical explanat…”
   • [community] “The 'in-codebase' approach is the right one, but a YAML file with plain text is a half-measure. The most reliable rule that 'lives next to t…”

   proof ↗⚑ flag

Security

1. security engineerReviews flag security problems in the diff — injection risks, leaked secrets, insecure patterns — alongside functional bugs

   weight 2 · round to cubic
   Qodo~partialclaimed5/10

   Qodo's docs describe automated PR reviews that flag findings with severity, explanations, and fixes, and generally aim to surface 'issues that matter' beyond just functional bugs, but the evidence never explicitly confirms detection of security-specific issues like injection risks or leaked secrets. missing for 10: explicit documentation of security-issue detection (secrets scanning, injection/insecure-pattern flags), independent/hands-on confirmation that security findings actually appear in review output.

   • [claimed-docs] “every finding states what needs attention, why it matters, and how to fix it, ranked by severity”
   • [claimed-docs] “The review focuses on surfacing issues that matter, explaining why they matter, and helping developers resolve them efficiently, without ove…”
   • [claimed-docs] “Qodo is an AI code review platform that provides automated”
   • [claimed-docs] “Qodo makes this classification available as a native pull request tag (Azure DevOps) or label (GitHub, GitLab), so you can triage which pull…”

   proof ↗⚑ flag

   cubic~partialcommunity6/10

   cubic docs explicitly claim it scans PRs for 'security vulnerabilities' alongside logic errors and style issues, and offers an 'Ultrareview' deep-pass mode explicitly recommended for security-sensitive changes, plus custom agents to enforce org-specific rules. However, there's no documented evidence of specific detection categories like secret leakage or injection-pattern examples, nor independent/hands-on evidence confirming accuracy on real security bugs (community quotes address general usefulness, not security-specific findings). Missing for 10: explicit mention of secret-scanning/injection-detection categories, and independent verification of security-finding accuracy.

   • [claimed-docs] “The AI automatically scans every pull request for a wide range of issues, including logic errors, style inconsistencies, and potential secur…”
   • [claimed-docs] “When a pull request needs extra scrutiny, you can ask cubic for an Ultrareview.”
   • [claimed-docs] “Ultrareview is cubic's deepest review. It runs a longer, multi-pass analysis using cubic's most capable review models, and typically takes a…”
   • [claimed-docs] “Custom agents are review rules that enforce your organization's specific best practices across pull requests.”
   • [community] “I really liked it - it hit the mark. The current balance works very well, and it genuinely surprised me. It provides more technical explanat…”

   proof ↗⚑ flag

Cli

1. developerI run reviews from a CLI against local diffs or in CI scripts, with machine-readable output my tooling can consume

   weight 2 · round drawn
   Qodo~partialprobed5/10

   Qodo documents an official Agentic Toolbox CLI that can 'review changes before opening a pull request' (local diffs) and retrieve findings/rules (qodo-docs-5, qodo-docs-6, qodo-docs-7, qodo-probe-4), showing CLI-based local review support. However, there is no documentation of CI-script invocation patterns or machine-readable (JSON/SARIF) output formats for tooling consumption. Missing for 10: explicit CI/script usage examples, documented machine-readable output format, and independent confirmation of CLI output structure.

   • [claimed-docs] “Review changes before opening a pull request.”
   • [claimed-docs] “Retrieve and resolve review findings.”
   • [claimed-docs] “Retrieve the rules and standards that apply to a task.”
   • [probe] “official CLI documented at https://docs.qodo.ai/agentic-toolbox/cli”

   proof ↗⚑ flag

   cubic~partialprobed5/10

   cubic ships an official CLI (`cubic-docs-7`, `cubic-probe-5`) that reviews local diffs before push and outputs a prompt for a coding agent to fix issues, satisfying the 'local diff' half of the story. However there is no documented evidence of CI-specific usage (e.g., a CI mode/flag) or of structured machine-readable output (JSON/SARIF) that external tooling could consume — the CLI output is described as a natural-language prompt, not a machine-parseable format. missing for 10: CI integration docs/flags, machine-readable (JSON/SARIF) output format, examples of scripting/tooling consumption.

   • [claimed-docs] “The **cubic CLI** reviews local changes before you push. It finds bugs and generates a prompt that your coding agent can use to fix them.”
   • [probe] “official CLI documented at https://docs.cubic.dev/ide/cli-review”

   proof ↗⚑ flag

Ide

1. developerI get the same review inside my IDE before I push, catching issues while the code is still in my editor

   weight 2 · round to cubic
   Qodo~partialprobed6/10

   Qodo's Agentic Toolbox (CLI, MCP, and plugins for Claude Code/Codex/Kiro) explicitly supports 'review changes before opening a pull request' using the same review/coding-standards engine as PR review, which lets a developer catch issues pre-push in their coding environment. However, this is delivered via CLI/agent plugins rather than a dedicated native IDE extension, and there's no evidence confirming parity of findings between local pre-push reviews and PR reviews. Missing for 10: a first-party IDE extension (VS Code/JetBrains) with inline review, and independent confirmation that local/CLI review output matches PR review quality.

   • [claimed-docs] “Review changes before opening a pull request.”
   • [claimed-docs] “The Qodo Agentic Toolbox brings Qodo's code understanding, coding standards, and review capabilities into your existing coding agent.”
   • [claimed-docs] “Use Qodo with Claude to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resolving code review fin…”
   • [claimed-docs] “Use the Qodo plugin with the Codex agent to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resol…”
   • [claimed-docs] “Use Qodo with the Kiro agent to access Qodo Agentic Toolbox skills for understanding your codebase, reviewing changes, and resolving code re…”
   • [claimed-docs] “Use the Qodo Agentic Toolbox CLI when you want to use Qodo-managed skills locally.”
   • [probe] “official CLI documented at https://docs.qodo.ai/agentic-toolbox/cli”

   proof ↗⚑ flag

   cubic✓fullprobed7/10

   cubic ships a dedicated CLI that "reviews local changes before you push. It finds bugs and generates a prompt that your coding agent can use to fix them" (cubic-docs-7, cubic-probe-5), plus IDE/agent integration via cubic skills and an MCP server that lets coding agents read review findings and codebase context (cubic-docs-8, cubic-docs-35, cubic-probe-4), directly matching the story of catching issues pre-push in the editor. Missing for 10: independent/hands-on validation of the CLI's pre-push review quality and no community evidence specifically confirming the IDE experience (community citations discuss PR-level review, not the local CLI).

   • [claimed-docs] “The **cubic CLI** reviews local changes before you push. It finds bugs and generates a prompt that your coding agent can use to fix them.”
   • [claimed-docs] “Connect cubic's MCP server to your coding agent to read review findings and codebase context, request PR reviews, and triage PR or codebase …”
   • [claimed-docs] “Install and connect cubic in Cursor, Claude Code, VS Code, Codex, Gemini CLI, or another coding tool.”
   • [claimed-docs] “cubic skills give your coding agent instructions for reviewing code, handling PR comments, and using your team's codebase context.”
   • [probe] “official MCP server documented at https://docs.cubic.dev/ide/mcp-server”
   • [probe] “official CLI documented at https://docs.cubic.dev/ide/cli-review”

   proof ↗⚑ flag

Config

1. engineering leadI configure the reviewer with a versioned config file in my repo — path filters, per-path instructions, review profiles

   weight 3 · round to cubic
   Qodo~partialclaimed6/10

   Qodo documents a versioned configuration-as-code file (.pr_agent.toml) that can be set at repository, project, group, or org level, plus an org/repo-level portal configuration hierarchy and a centralized rule system for engineering standards. However, the evidence does not explicitly confirm path-based filters or per-path instructions within that file, and the only 'profile' concept shown (Minimal/Standard/Comprehensive/Custom presets) applies to display options rather than a full review-profile system. Missing for 10: explicit documentation of path/glob filters, per-path instruction blocks, and named review profiles beyond display presets.

   • [claimed-docs] “Manage Qodo configuration as code using a .pr\_agent.toml file at the repository, project, group, or organization level.”
   • [claimed-docs] “Manage Qodo configuration as code using a .pr_agent.toml file at the repository, project, group, or organization level.”
   • [claimed-docs] “Organization level (default): Settings apply to all connected repositories. Repository level: Settings apply only to the selected repository…”
   • [claimed-docs] “Define and enforce engineering standards with a centralized rule system.”
   • [claimed-docs] “Choose a ready-made preset, Minimal, Standard, Comprehensive, or Custom, instead of setting each Display option individually.”

   proof ↗⚑ flag

   cubic✓fullcommunity7/10

   cubic.yaml is documented as a versioned, repo-root config file that is the 'source of truth for AI review behavior, ignore patterns, PR descriptions, and custom agents,' directly covering path filters (ignore patterns) and review profiles (custom agents, Ultrareview). Custom context files (README.md, AGENTS.md, .cursorrules, .ai/ dirs) further support per-path/contextual instructions. missing for 10: an explicit documented example of per-path instruction syntax within cubic.yaml, and independent/hands-on verification of the config file working as described (one community comment even questions whether YAML-based rules are as robust as code-based checks).

   • [claimed-docs] “`cubic.yaml` lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, …”
   • [claimed-docs] “cubic.yaml lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, an…”
   • [claimed-docs] “Custom agents are review rules that enforce your organization's specific best practices across pull requests.”
   • [claimed-docs] “Custom agents: Enforce your team's coding standards”
   • [claimed-docs] “cubic automatically detects and uses context files in your repository, including `README.md`, `context.md`, `AGENTS.md`, `.cursorrules`”
   • [claimed-docs] “cubic automatically detects and uses context files in your repository, including `README.md`, `context.md`, `AGENTS.md`, `.cursorrules`, age…”
   • [community] “The 'in-codebase' approach is the right one, but a YAML file with plain text is a half-measure. The most reliable rule that 'lives next to t…”

   proof ↗⚑ flag

Governance

1. engineering leadI roll out org-level review defaults across hundreds of repos and manage exceptions centrally

   weight 1 · round to Qodo
   Qodo✓fullclaimed8/10

   Docs directly address org-level defaults with repo-level exceptions (qodo-docs-10: org-level default settings applying to all connected repos, with repo-level overrides), configuration-as-code across repository/project/group/organization scope (qodo-docs-11/36), a centralized rule system for engineering standards (qodo-docs-12), and explicit governance framing for consistent enforcement at scale across every repo (qodo-docs-38). A portal-based Configurations UI is also documented as the recommended management path (qodo-docs-35). Missing for 10: independent/hands-on evidence of this working across hundreds of repos in practice, and more detail on exception-approval workflows beyond simple repo-level override.

   • [claimed-docs] “Organization level (default): Settings apply to all connected repositories. Repository level: Settings apply only to the selected repository…”
   • [claimed-docs] “Manage Qodo configuration as code using a .pr\_agent.toml file at the repository, project, group, or organization level.”
   • [claimed-docs] “Define and enforce engineering standards with a centralized rule system.”
   • [claimed-docs] “The recommended way to manage organization-wide and repository-level code review configuration, from the Configurations page in the Qodo por…”
   • [claimed-docs] “Manage Qodo configuration as code using a .pr_agent.toml file at the repository, project, group, or organization level.”
   • [claimed-docs] “Qodo governance is built for engineering leaders who need consistent standards enforced across every repository, automatically, at scale, an…”

   proof ↗⚑ flag

   cubic~partialclaimed5/10

   cubic.yaml provides per-repo config (source of truth for review behavior, ignore patterns, custom agents) and custom agents/RBAC roles suggest some centralized governance, but evidence shows configuration is per-repository (cubic.yaml lives in each repo root) rather than an org-level policy pushed/enforced across hundreds of repos with a central exceptions dashboard. missing for 10: an org-wide policy/template propagation mechanism across many repos, a central exceptions-management UI/workflow, and independent evidence of usage at hundreds-of-repos scale.

   • [claimed-docs] “`cubic.yaml` lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, …”
   • [claimed-docs] “cubic.yaml lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, an…”
   • [claimed-docs] “Custom agents are review rules that enforce your organization's specific best practices across pull requests.”
   • [claimed-docs] “cubic uses a role-based access control system to manage who can make changes to your team's subscription and settings. Every team member has…”
   • [claimed-docs] “Custom agents: Enforce your team's coding standards”

   proof ↗⚑ flag

Rules

1. engineering leadI encode my team's own review guidelines — natural-language rules, AST patterns, or linked style guides — and the reviewer enforces them

   weight 2 · round drawn
   Qodo~partialclaimed7/10

   Qodo documents a centralized rule system for defining/enforcing engineering standards, a Rule Miner that generates rules from PR history, and configuration-as-code via .pr_agent.toml or portal-level settings that apply org- or repo-wide, plus an Agentic Toolbox capability to 'retrieve rules and standards that apply to a task.' This covers natural-language rule encoding and centralized enforcement well, but there is no explicit evidence of AST-pattern-based rule definitions or linking external style guide documents specifically. Missing for 10: explicit AST-pattern rule support, direct linking/import of external style guide docs, and independent/hands-on confirmation that custom rules are reliably enforced in reviews.

   • [claimed-docs] “Retrieve the rules and standards that apply to a task.”
   • [claimed-docs] “Manage Qodo configuration as code using a .pr\_agent.toml file at the repository, project, group, or organization level.”
   • [claimed-docs] “Define and enforce engineering standards with a centralized rule system.”
   • [claimed-docs] “Generate rules from pull request history with Rule Miner”
   • [claimed-docs] “The recommended way to manage organization-wide and repository-level code review configuration, from the Configurations page in the Qodo por…”
   • [claimed-docs] “Manage Qodo configuration as code using a .pr_agent.toml file at the repository, project, group, or organization level.”

   proof ↗⚑ flag

   cubic~partialcommunity7/10

   cubic supports engineering-lead-authored review rules via 'Custom agents' (natural-language rules enforcing team standards), a cubic.yaml as source of truth, auto-detected context files (README, context.md, AGENTS.md, .cursorrules) and cross-repo linking for shared style guides, plus adoption of community rule sets. However, there is no explicit evidence of AST-pattern-based rule authoring, and one community comment expresses skepticism that plain-text/YAML rules are a 'half-measure' versus more robust structural checks, though this is opinion rather than a documented failure. Missing for 10: explicit AST-pattern rule support, independent hands-on validation that custom agents reliably enforce guidelines in practice.

   • [claimed-docs] “Custom agents are review rules that enforce your organization's specific best practices across pull requests.”
   • [claimed-docs] “`cubic.yaml` lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, …”
   • [claimed-docs] “Custom agents: Enforce your team's coding standards”
   • [claimed-docs] “You can also adopt existing agents from the community library with a single click.”
   • [claimed-docs] “cubic automatically detects and uses context files in your repository, including `README.md`, `context.md`, `AGENTS.md`, `.cursorrules`”
   • [claimed-docs] “cubic automatically detects and uses context files in your repository, including `README.md`, `context.md`, `AGENTS.md`, `.cursorrules`, age…”
   • [claimed-docs] “cubic.yaml lives in the root of your repository and becomes the source of truth for AI review behavior, ignore patterns, PR descriptions, an…”
   • [community] “The 'in-codebase' approach is the right one, but a YAML file with plain text is a half-measure. The most reliable rule that 'lives next to t…”

   proof ↗⚑ flag