Devin vs YYLO

Agent access

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

   weight 2 · round to Devin
   Devin✓fullprobed7/10

   Devin explicitly supports AGENTS.md, an agent-oriented documentation file that Devin reads before starting a coding session to gain project context — directly matching the story's intent of pointing an agent at agent-oriented docs. Devin's own docs site also serves an llms.txt endpoint (verified via probe), showing familiarity with the convention, though this is Devin's own site rather than evidence Devin ingests arbitrary llms.txt files from user projects. Missing for 10: explicit documentation that Devin consumes/parses llms.txt files themselves (as opposed to AGENTS.md) and independent hands-on confirmation of this workflow.

   • [claimed-docs] “Just put an AGENTS.md file in your project root (or anywhere else). Devin will look for the file before it starts coding.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.devin.ai/llms.txt # Devin Docs - [Desktop (100 pages)](https://docs.devin.ai/_llms/en/desktop.md):…”

   proof ↗⚑ flag

   YYLO—none0/10

   Direct probes show no llms.txt (404), no docs.md machine-readable variant (404), and no OpenAPI spec (404), meaning there is no agent-oriented docs endpoint to point an agent at; the only docs are standard human-facing HTML pages.

   • [probe] “PROBE llms.txt: HTTP 404 at https://yylo.dev/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://yylo.dev/docs/yylo.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://yylo.dev/openapi.json, https://yylo.dev/swagger.json, https://yylo.dev/api/openapi.json, htt…”

   proof ↗⚑ flag

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

   weight 2 · round to Devin
   Devin✓fullclaimed8/10

   Devin exposes a full REST API for session creation and automation (devin-docs-8, devin-docs-9), supports scheduling recurring/one-time headless runs via MCP (devin-docs-17), auto-triggers on CI failures and code review comments via Devin Review/Auto-Fix (devin-docs-20), and supports parallel/headless session orchestration (devin-docs-18). This covers CI/automation use cases well beyond interactive use. Missing for 10: no independent/hands-on CI-integration case study, and no dedicated 'CI runner' or GitHub Actions-style first-class integration doc beyond the review/auto-fix hook.

   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “you can create sessions on behalf of any user in your organization using the create_as_user_id parameter”
   • [claimed-docs] “Supports cron expressions for recurring schedules, one-time scheduling, notification preferences, and agent selection”
   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”
   • [claimed-docs] “Run multiple Devins in parallel: Carve out independent tasks and run them simultaneously.”
   • [claimed-docs] “Extend Devin's reach with MCP integrations: Connect Devin to Datadog, Sentry, databases, Figma, Notion, Stripe, and hundreds of other tool”

   proof ↗⚑ flag

   YYLO✓fullprobed7/10

   YYLO is a CLI orchestrator with scriptable commands (init, task start, ledger, loop, parallel-runner, run-until-completion) that produce structured watch receipts with exit codes and JSON state, and it's installable via npm as a public package with documented bins (yylo, yy, ypl) suitable for CI invocation. missing for 10: no explicit CI pipeline example (e.g., GitHub Actions config), no independent hands-on report of running it headlessly in CI, and llms.txt/openapi probes returned 404 suggesting thinner machine-readable integration docs.

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [claimed-docs] “`yy loop` repeats arbitrary shell commands sequentially.”
   • [claimed-docs] “Bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item.”
   • [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
   • [github] “A successful run prints the installed YYLO version, initializes `.juno_task/`, then emits a watch receipt with `"state":"COMPLETED"`, `"exit…”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”

   proof ↗⚑ flag

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

   weight 3 · round to Devin
   Devin✓fullprobed9/10

   Devin CLI explicitly supports connecting external MCP servers, exposing their tools as slash commands with permission controls, and docs list example integrations (Datadog, Sentry, databases, Figma, Notion, Stripe, etc.). Missing for 10: independent/hands-on community verification of MCP tool usage in practice.

   • [claimed-docs] “MCP (Model Context Protocol) lets you connect external tool servers to Devin CLI, giving the agent access to APIs, databases, issue trackers…”
   • [claimed-docs] “MCP tools are subject to the same permission system as built-in tools. You can control access at multiple levels”
   • [claimed-docs] “Devin CLI exposes each one as a slash command”
   • [claimed-docs] “Extend Devin's reach with MCP integrations: Connect Devin to Datadog, Sentry, databases, Figma, Notion, Stripe, and hundreds of other tool”
   • [probe] “official MCP server documented at https://docs.devin.ai/cli/extensibility/mcp/overview”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO's docs describe orchestrating coding agents, ledgers, workflows, and an 'open-standard path' for skills, but no evidence anywhere mentions MCP servers or a mechanism to plug in MCP tools for the agents it orchestrates.

   ⚑ flag

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

   weight 3 · round to Devin
   Devin✓fullclaimed8/10

   Devin ships an official MCP server (documented at docs.devin.ai/work-with-devin/devin-mcp) that exposes session management, playbooks, knowledge, and scheduling to any MCP-compatible agent or IDE — this is distinct from Devin's own MCP-client capability and directly satisfies the 'connect an agent via an official MCP server' story. Missing for 10: independent/hands-on confirmation that external agents successfully connect and operate through this server, and more detail on setup/auth flow beyond first-party docs.

   • [claimed-docs] “create sessions, manage playbooks and knowledge, set up schedules, and more”
   • [claimed-docs] “These tools let you explore and query documentation for any GitHub repository (public or private with authentication)”
   • [claimed-docs] “Supports cron expressions for recurring schedules, one-time scheduling, notification preferences, and agent selection”
   • [claimed-docs] “it gives any MCP-compatible AI agent or IDE full access to session management, playbooks, knowledge, and scheduling.”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO is a CLI orchestrator for coding agents/workflows, and as such platform-type product it could plausibly ship an official MCP server for other agents to connect to, but no evidence pack item mentions MCP at all (only 'open-standard' skills installation, ledger, workflow-runner, etc.). No official MCP server documentation, endpoint, or announcement exists in the evidence.

   ⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round drawn
   Devin✓fullprobed8/10

   Devin ships an official CLI documented extensively (adaptive model routing, slash commands, MCP extensibility) confirmed by both docs and a probe hit, plus a separate Terminal/local CLI mode for quick fixes. Missing for 10: independent hands-on review of the CLI itself and more detail on installation/versioning.

   • [claimed-docs] “Running Devin for Terminal in your local environment for quick fixes, code exploration, and interactive coding right from the command line”
   • [claimed-docs] “Adaptive analyzes your prompt and routes it to the model that will deliver the best result.”
   • [claimed-docs] “You can switch away from Adaptive to a specific model at any time with /model.”
   • [claimed-docs] “MCP (Model Context Protocol) lets you connect external tool servers to Devin CLI, giving the agent access to APIs, databases, issue trackers…”
   • [claimed-docs] “Devin CLI exposes each one as a slash command”
   • [probe] “official CLI documented at https://docs.devin.ai/cli/adaptive”

   proof ↗⚑ flag

   YYLO✓fullprobed8/10

   YYLO ships an official CLI (@yylo/cli) with documented commands (init, ledger, loop, doctor, task start, merge land) and is verifiably published on npm plus MIT-licensed on GitHub, matching an AI-native agentic workflow tool. missing for 10: independent third-party usage reports/reviews beyond vendor docs and registry probes, and some llms.txt/docs-md/openapi endpoints 404 suggesting incomplete machine-readable doc surface.

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
   • [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
   • [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”

   proof ↗⚑ flag

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

   weight 3 · round to Devin
   Devin✓fullprobed8/10

   Devin publishes a documented public API for integrating into applications, automating workflows, and creating sessions programmatically (including on behalf of other users), plus an MCP server exposing session/playbook/knowledge/scheduling management to external agents. Missing for 10: a discoverable machine-readable OpenAPI/swagger spec (probe found 404s) and independent third-party corroboration of API usage beyond vendor docs.

   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “you can create sessions on behalf of any user in your organization using the create_as_user_id parameter”
   • [claimed-docs] “create sessions, manage playbooks and knowledge, set up schedules, and more”
   • [claimed-docs] “it gives any MCP-compatible AI agent or IDE full access to session management, playbooks, knowledge, and scheduling.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.devin.ai/llms.txt # Devin Docs - [Desktop (100 pages)](https://docs.devin.ai/_llms/en/desktop.md):…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.devin.ai/openapi.json, https://docs.devin.ai/swagger.json, https://docs.devin.ai/api/op…”

   proof ↗⚑ flag

   YYLO~partialprobed5/10

   YYLO exposes a well-documented CLI (`yylo`, `yy`, `ypl`) with structured JSON output, a ledger/task API, YAML workflow contracts, and templating for chaining steps, which an AI-native user could script against — supported by first-party docs and a live public npm package. However, there is no true public HTTP/OpenAPI-style API: explicit probes for llms.txt, docs.md, and OpenAPI specs all returned 404, meaning the only 'API' is the CLI surface, not a documented network API a remote agent could call directly. Missing for 10: an OpenAPI/REST API spec, an llms.txt or machine-readable API manifest, and evidence of remote/programmatic (non-CLI) invocation.

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [claimed-docs] “`yy loop` repeats arbitrary shell commands sequentially.”
   • [claimed-docs] “Save the same contract as YAML for a reusable workflow.”
   • [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”
   • [probe] “PROBE llms.txt: HTTP 404 at https://yylo.dev/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://yylo.dev/docs/yylo.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://yylo.dev/openapi.json, https://yylo.dev/swagger.json, https://yylo.dev/api/openapi.json, htt…”
   • [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Devin
   Devin✓fullprobed8/10

   Devin publishes a documented API reference for building integrations (create sessions, manage on behalf of users, automate workflows), plus MCP support for extensibility — clear official SDK-like surface for AI-native developers. Missing for 10: no official language-specific SDK packages (e.g. Python/JS client libraries) are cited, only REST API docs and no discoverable OpenAPI spec (probe found 404s), and no independent/hands-on corroboration of API usage.

   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “you can create sessions on behalf of any user in your organization using the create_as_user_id parameter”
   • [claimed-docs] “MCP (Model Context Protocol) lets you connect external tool servers to Devin CLI, giving the agent access to APIs, databases, issue trackers…”
   • [claimed-docs] “create sessions, manage playbooks and knowledge, set up schedules, and more”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.devin.ai/openapi.json, https://docs.devin.ai/swagger.json, https://docs.devin.ai/api/op…”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO ships an official CLI (@yylo/cli) and open MIT-licensed repo, but there is no evidence of an SDK (client library/API) to build against — OpenAPI/spec probes and llms.txt/docs-md endpoints all return 404, and no SDK docs are mentioned anywhere in the pack.

   • [probe] “PROBE llms.txt: HTTP 404 at https://yylo.dev/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://yylo.dev/docs/yylo.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://yylo.dev/openapi.json, https://yylo.dev/swagger.json, https://yylo.dev/api/openapi.json, htt…”
   • [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
   • [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Devin—none0/10

   No evidence in the pack mentions webhooks or event subscription mechanisms for Devin; only API session creation, MCP integrations, and CLI features are documented. As an API-driven agentic product, webhook support would be a plausible and expected capability, so its absence counts as 'none' rather than 'na'.

   ⚑ flag

   YYLO—none0/10

   No evidence of any webhook subscription mechanism; YYLO documents Slack/GitHub integrations pulling into kanban but nothing about outbound event webhooks, and API/openapi probes returned 404s.

   • [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://yylo.dev/openapi.json, https://yylo.dev/swagger.json, https://yylo.dev/api/openapi.json, htt…”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to Devin
   Devin~partialclaimed6/10

   Devin's repo indexing enables 'Ask Devin' and DeepWiki features that generate AI insights and explanations from your codebase data, and Devin can proactively suggest fixes/improvements via code review auto-fix and bug triage. However, evidence is scoped only to codebase/ticket data, not broader business or analytics data, and there's no dedicated insights dashboard or proactive summarization feature documented. Missing for 10: evidence of insights beyond code (e.g., analytics/dashboards), independent corroboration of Ask Devin/DeepWiki quality, and any UI showcasing generated insights.

   • [claimed-docs] “Indexing your repositories allows Devin to understand your codebase and enables powerful features like Ask Devin and DeepWiki.”
   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”
   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”
   • [claimed-docs] “Language migrations (e.g. JavaScript to TypeScript) Framework upgrades (e.g. Angular 16 -> 18)”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO is an orchestration/CLI tool for running coding agents, workflows, and task ledgers; it launches subagents to perform tasks but nothing in the evidence describes it generating analytic insights or suggestions from a user's own data. Merge/validation explicitly avoids invoking models (yylo-gh-6), and no docs mention dashboards, analytics, or AI-generated insight surfacing.

   • [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”

   proof ↗⚑ flag

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

   weight 2 · round to Devin
   Devin✓fullclaimed8/10

   Devin supports scheduling via cron expressions (recurring/one-time) and agent selection through its MCP tooling, plus API session creation and Slack/Teams triggering, enabling autonomous background automations beyond interactive chat sessions. missing for 10: independent/hands-on verification of scheduled runs actually executing unattended, and more detail on failure/retry handling for scheduled tasks.

   • [claimed-docs] “Supports cron expressions for recurring schedules, one-time scheduling, notification preferences, and agent selection”
   • [claimed-docs] “create sessions, manage playbooks and knowledge, set up schedules, and more”
   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “you can create sessions on behalf of any user in your organization using the create_as_user_id parameter”
   • [claimed-docs] “Tag Devin on Slack or Teams: Start sessions directly from conversations about bugs, feature requests, or questions.”
   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”

   proof ↗⚑ flag

   YYLO~partialclaimed7/10

   Docs describe multiple mechanisms for autonomous, repeated execution — `yy loop` for repeating shell commands, run-until-completion scripts that iterate until kanban work is done, a workflow-runner for chained multi-step automations, a bounded parallel-runner for concurrent fan-out, and integrations that pull Slack/GitHub work into a kanban queue and post results back. This supports background-style autonomous task execution, and sessions can be resumed via `yy continue SESSION_ID` rather than reconstructed from a terminal. However, there's no evidence of a persistent scheduler/cron-like trigger or a hosted background service — everything appears CLI/session-driven, and there is no independent or hands-on confirmation that these loops truly run unattended over long periods. Missing for 10: evidence of scheduled/triggered automations independent of an active session, and third-party corroboration of long-running unattended execution.

   • [claimed-docs] “`yy loop` repeats arbitrary shell commands sequentially.”
   • [claimed-docs] “Bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item.”
   • [claimed-docs] “Continue a captured session with `yy continue SESSION_ID`; do not reconstruct work from tmux scrollback.”
   • [claimed-docs] “Choose Workflow Runner when a step consumes `{{ steps.<id>.response }}`, a generated file, or a session from an earlier step.”
   • [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
   • [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”

   proof ↗⚑ flag

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

   weight 3 · round to Devin
   Devin✓fullcommunity8/10

   Devin itself functions as the built-in AI assistant to which tasks are delegated across web app, terminal, Slack/Teams, and API, with rich first-party documentation of the delegation workflow (docs-1,3,4,5,8,19). Community feedback raises reliability/skepticism concerns but does not concretely contradict that delegation itself works, so it's not disputed. Missing for 10: independent hands-on validation of delegation reliability/success rate beyond old demo critiques.

   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”
   • [claimed-docs] “using /handoff to send longer tasks to cloud Devin”
   • [claimed-docs] “Tagging Devin on a Slack or Teams thread about a bug you’re discussing with coworkers”
   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”
   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “Tag Devin on Slack or Teams: Start sessions directly from conversations about bugs, feature requests, or questions.”
   • [community] “From the graph at the end: 13.8% of issues resolved. Devin may need some additional help for awhile.”

   proof ↗⚑ flag

   YYLO~partialclaimed4/10

   YYLO's CLI lets a user delegate a task to an AI agent via `--subagent claude` and manage it through kanban/ledger workflows, so task delegation to an AI is documented, but the AI capability is an external subagent (e.g., Claude) invoked by the orchestrator rather than an assistant built into YYLO itself. missing for 10: evidence of an assistant embedded in the product (not requiring an external model/agent), and any first-party assistant UI/API rather than orchestration of third-party agents.

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”

   proof ↗⚑ flag

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

   weight 2 · round to Devin
   Devin✓fullcommunity8/10

   Devin is fundamentally driven by natural-language task requests across web app, Slack/Teams tagging, CLI, and API (create_as_user_id sessions), letting users describe tasks like bug fixes, features, and migrations in plain language rather than issuing structured commands. Community evidence corroborates that Devin operates via conversational/task-based prompts even amid skepticism about output quality. missing for 10: independent hands-on confirmation of NL command fidelity across all surfaces (CLI/Slack/API), and no evidence addressing ambiguous or multi-step NL instruction handling limits.

   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”
   • [claimed-docs] “Tagging Devin on a Slack or Teams thread about a bug you’re discussing with coworkers”
   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”
   • [claimed-docs] “Tag Devin on Slack or Teams: Start sessions directly from conversations about bugs, feature requests, or questions.”
   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “you can create sessions on behalf of any user in your organization using the create_as_user_id parameter”
   • [community] “Clearly an extremely impressive demo... I notice in the first demo Devin hits a KeyError and decides to resolve it by wrapping the code in a…”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO's interface is a structured CLI (yylo/yy commands with explicit flags like --task, --subagent) rather than a natural-language command interface; the --task string is passed through to a subagent, not parsed as an operator instruction to YYLO itself. No evidence shows a chat-like or NL command surface for driving YYLO's own operations (init, start, finish, ledger, merge, etc.).

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Devin—none0/10

   Devin documents an API reference overview and parameters (e.g. create_as_user_id) but nothing describes an interactive, in-browser 'try it' experience with runnable code examples; a probe for standard OpenAPI/Swagger interactive-doc endpoints returned 404s, suggesting no such interactive explorer exists.

   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “you can create sessions on behalf of any user in your organization using the create_as_user_id parameter”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.devin.ai/openapi.json, https://docs.devin.ai/swagger.json, https://docs.devin.ai/api/op…”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO is a CLI orchestrator for coding agents, not an API product; there is no evidence of an interactive API reference, and explicit probes for openapi.json/swagger.json and llms.txt all return 404, indicating no such reference exists.

   • [probe] “PROBE llms.txt: HTTP 404 at https://yylo.dev/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://yylo.dev/docs/yylo.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://yylo.dev/openapi.json, https://yylo.dev/swagger.json, https://yylo.dev/api/openapi.json, htt…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Devin—none0/10

   Devin has a documented API (devin-docs-8, devin-docs-9) but a direct probe for OpenAPI/swagger spec files at common paths returned 404s (devin-probe-2), and no docs page offers a downloadable machine-readable spec.

   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.devin.ai/openapi.json, https://docs.devin.ai/swagger.json, https://docs.devin.ai/api/op…”

   proof ↗⚑ flag

   YYLO—none0/10

   Explicit probes for llms.txt, docs-md, and OpenAPI/swagger endpoints all returned 404, and no evidence shows any downloadable machine-readable API spec; YYLO is a CLI orchestrator without a documented API surface to spec.

   • [probe] “PROBE llms.txt: HTTP 404 at https://yylo.dev/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://yylo.dev/docs/yylo.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://yylo.dev/openapi.json, https://yylo.dev/swagger.json, https://yylo.dev/api/openapi.json, htt…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to YYLO
   Devin~partialclaimed3/10

   Devin's docs describe each session running in its own configurable workspace/environment (devin-docs-25) and connecting via VPN to reach internal services rather than being embedded in production (devin-docs-23), which implies some environment isolation, but there is no explicit claim of a dedicated 'sandbox vs production' testing mode or safeguards against touching production data. missing for 10: explicit documentation of a production-safe/sandboxed test environment, evidence of data isolation guarantees, and independent confirmation that production systems are never touched.

   • [claimed-docs] “Configure it once, and every session boots into that known-good state.”
   • [claimed-docs] “Devin can connect to a VPN from inside its workspace, so sessions can reach internal services such as package registries, databases, and int…”

   proof ↗⚑ flag

   YYLO✓fullclaimed7/10

   YYLO's task worktrees isolate work from the protected target SHA, preflight checks are documented as read-only, and merges compose changes into a private detached candidate rather than touching the live branch directly, while the benchmark tool explicitly runs 'isolated attempts' with 'recover safely' semantics—together these describe a sandboxed testing flow that avoids touching the protected/production state. Missing for 10: explicit 'production data' terminology or a dedicated staging/prod environment concept, and independent (non-vendor) confirmation that isolation holds up in practice.

   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [github] “`doctor workspace` is intentionally nonzero when it finds an actionable topology problem; it never fetches or changes the workspace.”
   • [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
   • [claimed-docs] “Plan immutable experiments, execute isolated attempts, retain evaluator provenance, recover safely, and produce bounded reports.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Devin—none0/10

   There is an API reference (devin-docs-8) but no evidence of API versioning scheme or a documented deprecation policy; the openapi.json probe returned 404s, suggesting no formal machine-readable spec either. Missing for 10: versioning scheme documentation, deprecation policy/notice, changelog for breaking changes.

   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.devin.ai/openapi.json, https://docs.devin.ai/swagger.json, https://docs.devin.ai/api/op…”

   proof ↗⚑ flag

   YYLO—none0/10

   No evidence of any versioned API contract or documented deprecation policy; the product is a CLI orchestrator with a version like 0.2.1rc6, but no API versioning scheme or deprecation guarantees are mentioned, and openapi/llms.txt probes returned 404.

   • [probe] “PROBE openapi: all candidate paths 404 (https://yylo.dev/openapi.json, https://yylo.dev/swagger.json, https://yylo.dev/api/openapi.json, htt…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://yylo.dev/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://yylo.dev/docs/yylo.md”
   • [claimed-docs] “The 0.2.1rc6 channel adds ID-first general Records and typed task, wiki, workflow, and artifact profiles.”

   proof ↗⚑ flag

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

   weight 2 · round to YYLO
   Devin~partialclaimed6/10

   Devin's docs describe running multiple Devins in parallel for independent tasks, an API for creating sessions programmatically (including on behalf of other users), and scheduling capabilities—together supporting bulk/automated task dispatch across many items. However, there's no concrete example or independent evidence of actually orchestrating large-scale bulk operations (e.g., processing hundreds of tickets at once), and community evidence focuses on single-task demos rather than bulk workflows. Missing for 10: hands-on/independent evidence of large-scale bulk runs, explicit parallelism limits, and a documented case study of bulk item processing.

   • [claimed-docs] “Run multiple Devins in parallel: Carve out independent tasks and run them simultaneously.”
   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “you can create sessions on behalf of any user in your organization using the create_as_user_id parameter”
   • [claimed-docs] “Supports cron expressions for recurring schedules, one-time scheduling, notification preferences, and agent selection”

   proof ↗⚑ flag

   YYLO✓fullprobed8/10

   YYLO's parallel-runner explicitly supports 'bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item,' and run-until-completion repeats iterations until all kanban work is done, directly enabling bulk operations across many items with automated evidence capture. This is corroborated by a live public CLI (npm registry, MIT-licensed source), though there's no independent hands-on report of large-scale fan-out in practice. Missing for 10: independent/third-party validation of bulk-scale runs and concrete concurrency limits or throughput numbers.

   • [claimed-docs] “Bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item.”
   • [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
   • [claimed-docs] “Continue a captured session with `yy continue SESSION_ID`; do not reconstruct work from tmux scrollback.”
   • [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
   • [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”

   proof ↗⚑ flag

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

   weight 3 · round to Devin
   Devin~partialclaimed7/10

   Devin supports event-driven automation via scheduled/cron triggers (create schedules with cron expressions, notification preferences) and via Devin Review's Auto-Fix which automatically responds to code review comments and CI failures, plus API-based workflow automation. However, these are fixed built-in trigger types (schedule, CI/review events) rather than a general user-defined rules engine for arbitrary events. Missing for 10: evidence of a flexible custom rule/trigger builder covering arbitrary event sources (e.g., webhooks, ticket status changes) beyond scheduling and code-review auto-fix, and independent confirmation these triggers work reliably in practice.

   • [claimed-docs] “Supports cron expressions for recurring schedules, one-time scheduling, notification preferences, and agent selection”
   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”
   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “create sessions, manage playbooks and knowledge, set up schedules, and more”

   proof ↗⚑ flag

   YYLO~partialclaimed5/10

   YYLO's integrations pull Slack messages and GitHub issues into its kanban system and return responses to source threads, which is a form of event-triggered automation, and run-until-completion/workflow-runner allow chained/looping actions. However there's no evidence of a general user-defined rule engine (conditions + custom triggers) — the event handling is limited to specific hardcoded integrations rather than an open rule-definition system. Missing for 10: a documented rules/conditions DSL, support for arbitrary custom event sources/triggers, and evidence of user-authored trigger logic beyond the built-in Slack/GitHub integrations.

   • [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
   • [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
   • [claimed-docs] “Choose Workflow Runner when a step consumes `{{ steps.<id>.response }}`, a generated file, or a session from an earlier step.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Devin
   Devin✓fullclaimed8/10

   Devin's MCP documentation explicitly states scheduling support with 'cron expressions for recurring schedules, one-time scheduling, notification preferences, and agent selection,' and this scheduling capability is exposed via MCP for session/playbook management. Missing for 10: independent/hands-on corroboration of recurring job execution in practice and more detail on scheduling UI/reliability beyond the docs mention.

   • [claimed-docs] “create sessions, manage playbooks and knowledge, set up schedules, and more”
   • [claimed-docs] “Supports cron expressions for recurring schedules, one-time scheduling, notification preferences, and agent selection”
   • [claimed-docs] “it gives any MCP-compatible AI agent or IDE full access to session management, playbooks, knowledge, and scheduling.”

   proof ↗⚑ flag

   YYLO~partialclaimed5/10

   YYLO supports repeatable workflows (YAML-saved contracts, `yy loop` shell repetition, run-until-completion looping, workflow-runner chaining) which cover automation-depth, but there is no evidence of a scheduler, cron-like trigger, or time-based recurring job execution — workflows appear to be manually invoked or run-to-completion rather than scheduled on a recurring basis. missing for 10: cron/schedule syntax or trigger mechanism, evidence of unattended recurring execution (e.g., daily/hourly runs), and independent confirmation of scheduling in production use.

   • [claimed-docs] “`yy loop` repeats arbitrary shell commands sequentially.”
   • [claimed-docs] “Save the same contract as YAML for a reusable workflow.”
   • [claimed-docs] “Choose Workflow Runner when a step consumes `{{ steps.<id>.response }}`, a generated file, or a session from an earlier step.”
   • [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”

   proof ↗⚑ flag

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

   weight 1 · round to YYLO
   Devin—none0/10

   No evidence of version history, review/diff UI, or rollback of Devin's automations (playbooks, schedules, sessions); docs mention creating/scheduling sessions and playbooks but never versioning, auditing changes, or reverting them. missing for 10: version history for playbooks/sessions, review/approval workflow for automation changes, rollback/undo mechanism.

   • [claimed-docs] “create sessions, manage playbooks and knowledge, set up schedules, and more”
   • [claimed-docs] “Supports cron expressions for recurring schedules, one-time scheduling, notification preferences, and agent selection”
   • [claimed-docs] “Knowledge is the best way to share codebase-level (vs. task-level) context that can help Devin when working in your codebase.”

   proof ↗⚑ flag

   YYLO~partialclaimed5/10

   YYLO ledger provides task versioning-like constructs (immutable task source, worktree branching, candidate composition, expected-old ref protection for merges) and workflow YAML contracts can be saved/reused, giving some review/rollback semantics via git-based merge protections. However there is no explicit 'automation version history', diff/review UI, or a documented rollback command for automations themselves beyond git branch/worktree mechanics. missing for 10: dedicated automation versioning/history view, explicit rollback command for a run/automation (not just git ref protection), review workflow UI, and independent/hands-on confirmation of these rollback flows.

   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
   • [claimed-docs] “Save the same contract as YAML for a reusable workflow.”
   • [claimed-docs] “The 0.2.1rc6 channel adds ID-first general Records and typed task, wiki, workflow, and artifact profiles.”

   proof ↗⚑ flag

End to end feature delivery

1. ai-native userHave an agent automatically generate and run tests to validate its own code changes before proposing them

   weight 2 · round to Devin
   Devin~partialclaimed6/10

   Devin's docs describe autonomous CI-failure iteration and auto-fix behavior (devin-docs-20) and a terminal for executing/observing command output (devin-docs-6), implying it runs and reacts to test/build results before finalizing changes, but there is no explicit documentation of Devin proactively writing new tests and running them pre-emptively to self-validate before proposing a PR. missing for 10: explicit test-generation workflow documentation, evidence of Devin authoring test cases for new code, independent hands-on confirmation of this specific validation loop.

   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”
   • [claimed-docs] “Devin’s terminal, where you can watch commands being executed and view output logs. You can also copy the shell output for debugging purpose…”
   • [claimed-docs] “Language migrations (e.g. JavaScript to TypeScript) Framework upgrades (e.g. Angular 16 -> 18)”

   proof ↗⚑ flag

   YYLO—none0/10

   The evidence explicitly states that tests and semantic reviews are 'explicit project checks outside merge' and that YYLO's merge step 'launches no models, chooses no reviewers, schedules no suites, and maintains no validation cache' (yylo-gh-6). While `yy loop` can repeat arbitrary shell commands, there is no evidence of an agent autonomously generating tests or validating its own changes before proposing them.

   • [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
   • [claimed-docs] “`yy loop` repeats arbitrary shell commands sequentially.”

   proof ↗⚑ flag

2. developerHave an agent autonomously diagnose and fix a reported bug

   weight 3 · round to YYLO
   Devin!disputedcontradicted5/10

   Devin's docs explicitly describe autonomous bug repro/fix workflows, Slack-triggered bug sessions, and auto-fix on CI/review failures (devin-docs-1, devin-docs-4, devin-docs-19, devin-docs-20), supporting the core story. However, independent commentary cites a low real-world resolution rate (13.8% of issues resolved) and hands-on accounts describing shallow fixes (e.g., wrapping errors in try/catch rather than真正 diagnosing root cause), directly contradicting the strength of the autonomous-fix claim (devin-comm-2, devin-comm-6, devin-comm-4). Missing for 10: independent benchmark showing high success rate, more recent hands-on verification of bug-fix quality, and resolution of the discrepancy between vendor claims and community-reported performance.

   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”
   • [claimed-docs] “Tagging Devin on a Slack or Teams thread about a bug you’re discussing with coworkers”
   • [claimed-docs] “Tag Devin on Slack or Teams: Start sessions directly from conversations about bugs, feature requests, or questions.”
   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”
   • [community] “From the graph at the end: 13.8% of issues resolved. Devin may need some additional help for awhile.”
   • [community] “Clearly an extremely impressive demo... I notice in the first demo Devin hits a KeyError and decides to resolve it by wrapping the code in a…”
   • [community] “Although the demos are impressive, they seem short and limited in scope... How often will the solution only be 90% correct, which is 100% no…”

   proof ↗⚑ flag

   YYLO~partialclaimed5/10

   YYLO orchestrates coding agents through task worktrees, kanban-driven work items, and iteration loops (run-until-completion, subagent tasking) that could be pointed at a bug-fix task, and it supports ingesting GitHub issues into kanban as a trigger. However there is no evidence of autonomous bug diagnosis (root-causing, log/trace analysis) as a distinct capability — the docs describe generic task/workflow orchestration and merge/validation boundaries rather than an end-to-end 'diagnose then fix' agent behavior. missing for 10: explicit diagnosis/root-cause capability, an end-to-end bug-fix case study or hands-on validation, evidence the agent itself (vs. the orchestrator) performs debugging reasoning.

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
   • [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”

   proof ↗⚑ flag

3. product-managerGo from a mockup or design to a working implementation without an engineering handoff

   weight 2 · round to Devin
   Devin~partialclaimed5/10

   Devin's docs show it can autonomously implement features from tickets (Jira/Linear) and be tagged by non-engineers on Slack/Teams, supporting the general 'PM delegates, Devin implements' workflow, and it can connect to Figma via MCP integrations. However, there is no documented mockup-to-code pipeline, no PM-specific onboarding flow, and no evidence of turning a design file into a working UI end-to-end. missing for 10: direct design/mockup ingestion workflow, PM-focused case study or walkthrough, independent evidence of successful design-to-implementation outcomes.

   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”
   • [claimed-docs] “Tag Devin on Slack or Teams: Start sessions directly from conversations about bugs, feature requests, or questions.”
   • [claimed-docs] “Extend Devin's reach with MCP integrations: Connect Devin to Datadog, Sentry, databases, Figma, Notion, Stripe, and hundreds of other tool”
   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO's evidence describes a CLI orchestrator for coding agents (task/worktree/merge/ledger workflows) aimed at developers and project operators, with no mention of ingesting mockups/designs or enabling a non-technical PM to go from a design to working code without engineering involvement.

   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”

   proof ↗⚑ flag

4. developerHave an agent implement a requested feature end-to-end, including writing tests

   weight 3 · round to YYLO
   Devin!disputedcontradicted5/10

   Devin's docs explicitly claim end-to-end feature implementation (docs-1, docs-31) and even test-writing is implied as part of full feature delivery, but independent hands-on reporting from the original demo showed only 13.8% of issues resolved and reviewers noted the work was often only ~90% correct or used hacky fixes (e.g. wrapping in try-catch) rather than proper fixes (devin-comm-2, devin-comm-4, devin-comm-6), directly contradicting the 'implements features end-to-end reliably' claim. missing for 10: verified success-rate data on test-writing specifically, more recent independent benchmarks showing improved reliability, and evidence tests are written/passed as part of the workflow rather than just code changes.

   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”
   • [claimed-docs] “Language migrations (e.g. JavaScript to TypeScript) Framework upgrades (e.g. Angular 16 -> 18)”
   • [community] “From the graph at the end: 13.8% of issues resolved. Devin may need some additional help for awhile.”
   • [community] “Although the demos are impressive, they seem short and limited in scope... How often will the solution only be 90% correct, which is 100% no…”
   • [community] “Clearly an extremely impressive demo... I notice in the first demo Devin hits a KeyError and decides to resolve it by wrapping the code in a…”

   proof ↗⚑ flag

   YYLO~partialclaimed5/10

   YYLO documents an end-to-end task loop (yylo init --task ... --subagent claude, worktree creation, commit-and-queue candidate flow) showing an agent can implement a described feature autonomously, but the evidence explicitly states 'tests and semantic reviews are explicit project checks outside merge' — meaning YYLO's own agent loop does not itself guarantee test-writing as part of implementation, only that separate check scripts exist for validation. missing for 10: explicit evidence the invoked subagent writes/adds tests as part of a task, and any example showing test-authoring within the init/finish workflow.

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”

   proof ↗⚑ flag

Environment setup

1. developerHave an agent automatically clone the repo, install dependencies, and configure its own working environment

   weight 2 · round to Devin
   Devin✓fullclaimed8/10

   Devin's docs describe indexing repos, configuring a persistent environment/workspace that boots into a known-good state every session, VPN access to internal registries/git hosts, and AGENTS.md-based setup instructions it follows before coding — together these show it autonomously clones, configures, and prepares its own working environment. missing for 10: independent/hands-on verification of the clone+dependency-install flow end-to-end, and explicit documentation of automatic dependency installation step-by-step.

   • [claimed-docs] “Indexing your repositories allows Devin to understand your codebase and enables powerful features like Ask Devin and DeepWiki.”
   • [claimed-docs] “Devin can connect to a VPN from inside its workspace, so sessions can reach internal services such as package registries, databases, and int…”
   • [claimed-docs] “Just put an AGENTS.md file in your project root (or anywhere else). Devin will look for the file before it starts coding.”
   • [claimed-docs] “Configure it once, and every session boots into that known-good state.”

   proof ↗⚑ flag

   YYLO~partialprobed7/10

   Docs and GitHub README describe `task start`/`yy init` hydrating a dedicated worktree from a protected base SHA and completing 'configured dependency hydration' before reporting WORKING, which covers automated environment setup and dependency install; the CLI is confirmed live on npm and the repo public. Missing for 10: explicit description of cloning an arbitrary remote repo (vs. hydrating a pre-defined workspace), and independent/hands-on confirmation that dependency install works end-to-end.

   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
   • [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
   • [github] “A successful run prints the installed YYLO version, initializes `.juno_task/`, then emits a watch receipt with `"state":"COMPLETED"`, `"exit…”

   proof ↗⚑ flag

Interactive takeover

1. developerTake over an in-progress agent task in my editor, terminal, or browser to finish or redirect the work

   weight 2 · round to Devin
   Devin✓fullclaimed8/10

   Docs explicitly describe multi-surface handoff: delegate via web app then take over in Devin's IDE, use /handoff to send terminal tasks to cloud Devin, jump into the Interactive Browser to help Devin navigate, and tag Devin in Slack/Teams threads to redirect work — covering editor, terminal, and browser takeover. Missing for 10: independent/hands-on confirmation of a smooth mid-task handoff experience (community evidence is generic skepticism, not a concrete handoff failure).

   • [claimed-docs] “using /handoff to send longer tasks to cloud Devin”
   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”
   • [claimed-docs] “Devin’s terminal, where you can watch commands being executed and view output logs. You can also copy the shell output for debugging purpose…”
   • [claimed-docs] “You can jump in to help Devin navigate through browsing tasks via the Interactive Browser.”
   • [claimed-docs] “Tag Devin on Slack or Teams: Start sessions directly from conversations about bugs, feature requests, or questions.”
   • [claimed-docs] “Running Devin for Terminal in your local environment for quick fixes, code exploration, and interactive coding right from the command line”

   proof ↗⚑ flag

   YYLO~partialclaimed4/10

   YYLO offers terminal-based session continuation (`yy continue SESSION_ID`) that lets a developer pick back up captured agent work rather than reconstructing it from scrollback, and task start/finish flows expose worktree/branch state that could be inspected or redirected from the CLI. However, there is no evidence of any editor integration or browser UI for taking over tasks — YYLO is documented purely as a CLI/orchestrator tool. Missing for 10: editor plugin/extension support, browser-based task takeover UI, and explicit interactive 'redirect mid-task' semantics beyond resuming a session.

   • [claimed-docs] “Continue a captured session with `yy continue SESSION_ID`; do not reconstruct work from tmux scrollback.”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”

   proof ↗⚑ flag

2. developerSend follow-up instructions to an active agent session to steer its work without restarting

   weight 2 · round to Devin
   Devin~partialclaimed5/10

   Devin's docs describe delegating tasks and then 'taking over in Devin's IDE' or 'jumping in' to help with browsing tasks, implying some interactivity with an active session, but there is no explicit documentation of sending follow-up chat instructions to steer an in-progress session without restarting it. missing for 10: explicit docs on mid-session chat/steering, confirmation that follow-up messages are incorporated live, independent hands-on evidence of this workflow.

   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”
   • [claimed-docs] “You can jump in to help Devin navigate through browsing tasks via the Interactive Browser.”
   • [claimed-docs] “Tagging Devin on a Slack or Teams thread about a bug you’re discussing with coworkers”
   • [claimed-docs] “Tag Devin on Slack or Teams: Start sessions directly from conversations about bugs, feature requests, or questions.”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO's docs describe task lifecycle (init/start/preflight/finish) and resuming a captured session via `yy continue SESSION_ID`, but there is no evidence of sending new instructions to an already-running agent session to redirect its work mid-flight; `continue` appears to resume/reattach rather than inject steering input. missing for 10: any documented mechanism for mid-session instruction injection or steering, evidence that an active agent process accepts new prompts without restart.

   • [claimed-docs] “Continue a captured session with `yy continue SESSION_ID`; do not reconstruct work from tmux scrollback.”
   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”

   proof ↗⚑ flag

Sandbox execution

1. developerHave an agent safely execute code and install dependencies inside an isolated sandbox

   weight 3 · round to Devin
   Devin~partialclaimed6/10

   Docs describe Devin operating in its own workspace/VM with terminal execution, environment configuration ('known-good state'), VPN access to internal services, and multi-platform (Android/macOS/Windows) build environments, implying isolated sandboxed execution, but there is no explicit documentation of sandbox security guarantees, dependency isolation, or safety controls around code execution, and no independent/hands-on verification of sandbox isolation. missing for 10: explicit sandbox/isolation security documentation, independent verification of safe execution, details on dependency install safety and containment.

   • [claimed-docs] “Devin’s terminal, where you can watch commands being executed and view output logs. You can also copy the shell output for debugging purpose…”
   • [claimed-docs] “Devin can connect to a VPN from inside its workspace, so sessions can reach internal services such as package registries, databases, and int…”
   • [claimed-docs] “Configure it once, and every session boots into that known-good state.”
   • [claimed-docs] “Devin can build and run Android applications directly on its own machine — giving it the Android equivalent of Computer Use and browser inte…”
   • [claimed-docs] “Devin now has access to macOS virtual machines. This means Devin can now build and test iOS and macOS applications.”
   • [claimed-docs] “Devin supports Windows as a build and session platform.”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO's docs describe git-worktree/branch isolation for tasks and merge safety, but none of the evidence mentions a sandboxed execution environment (container/VM) for running agent code or installing dependencies safely. Worktree isolation protects git state, not runtime/process isolation.

   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”

   proof ↗⚑ flag

Approval controls

1. developerConfigure an agent to auto-approve all its actions instead of confirming each one

   weight 2 · round drawn
   Devin—none0/10

   The evidence pack describes permission systems for MCP tools (devin-docs-13) and autonomous features like Auto-Fix (devin-docs-20), but there is no documentation of a setting that lets a developer toggle between 'confirm each action' and 'auto-approve all actions' for Devin's own task execution. missing for 10: explicit auto-approve/confirmation toggle documentation, evidence of a per-action approval workflow that can be disabled, any community confirmation of this specific control.

   • [claimed-docs] “MCP tools are subject to the same permission system as built-in tools. You can control access at multiple levels”
   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”

   proof ↗⚑ flag

   YYLO—none0/10

   The evidence describes YYLO's orchestration architecture (task worktrees, ledger, merge protections) but nothing addresses a configurable auto-approve/no-confirmation mode for agent actions; in fact merge land explicitly requires checks and human-oversight-style gating rather than blanket auto-approval. Missing for 10: any documented auto-approve flag/setting, evidence of confirmation prompts being bypassable, or explicit human-oversight configuration options.

   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
   • [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”

   proof ↗⚑ flag

2. product-managerApprove key agent decisions from my phone while agents continue working

   weight 1 · round drawn
   Devin—none0/10

   No evidence describes a mobile app or phone-based approval interface for agent decisions; docs mention Slack/Teams tagging, web app, IDE, and scheduling notifications but nothing about approving decisions from a phone while sessions continue. The axis is plausible for an agentic dev tool with human-in-the-loop needs, but no supporting evidence exists.

   ⚑ flag

   YYLO—none0/10

   YYLO is documented purely as a CLI/terminal orchestrator (yylo/yy commands, ledger, worktrees, merge gating) with no mention of any mobile app, phone notification, or remote-approval interface for product managers. The axis is plausible for an agent-orchestration tool but no evidence supports it.

   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”

   proof ↗⚑ flag

3. engineering-leadSet tiered autonomy levels controlling what an agent can do without manual confirmation

   weight 3 · round to Devin
   Devin~partialclaimed4/10

   Devin documents a permission system for MCP/tool access that can be controlled 'at multiple levels' and features like Auto-Fix, human takeover in the IDE, and interactive browser intervention imply some control over autonomous action, but there is no documented feature specifically framed as configurable 'tiered autonomy levels' for an engineering lead to set organization-wide policies on unattended agent actions. missing for 10: explicit autonomy-tier configuration UI/API, organization-wide policy controls, and confirmation-threshold settings distinct from ad-hoc MCP tool permissions.

   • [claimed-docs] “MCP tools are subject to the same permission system as built-in tools. You can control access at multiple levels”
   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”
   • [claimed-docs] “You can jump in to help Devin navigate through browsing tasks via the Interactive Browser.”
   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”

   proof ↗⚑ flag

   YYLO—none0/10

   Evidence shows preflight/read-only checks, merge protections, and validation boundaries, but there is no mention of configurable tiered autonomy levels or a settings mechanism letting an engineering-lead define graduated confirmation thresholds for agent actions. missing for 10: explicit autonomy-level configuration, tiered permission settings, evidence of user-controlled confirmation thresholds.

   ⚑ flag

Model control

1. ai-native userHave each task prompt automatically routed to the most suitable underlying model

   weight 2 · round to Devin
   Devin✓fullprobed8/10

   Devin's CLI has an explicit "Adaptive" model router that analyzes each prompt and automatically routes it to the best-performing model, with an override via /model if manual control is desired. This directly matches the story of automatic per-task model routing, though it's documented only for the CLI product surface and lacks independent/hands-on validation of routing quality. Missing for 10: independent corroboration of routing accuracy, and confirmation this applies across all Devin surfaces (web/IDE) not just CLI.

   • [claimed-docs] “Adaptive analyzes your prompt and routes it to the model that will deliver the best result.”
   • [claimed-docs] “You can switch away from Adaptive to a specific model at any time with /model.”
   • [claimed-docs] “Adaptive is an intelligent model router that automatically selects the best AI model for each task.”
   • [probe] “official CLI documented at https://docs.devin.ai/cli/adaptive”

   proof ↗⚑ flag

   YYLO—none0/10

   Evidence shows YYLO lets users manually specify a subagent/model (e.g. `--subagent claude`) but nothing describes automatic routing of a task prompt to the 'most suitable' underlying model based on task characteristics. missing for 10: any evidence of automatic model-selection logic, routing criteria, or multi-model comparison/selection mechanism.

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”

   proof ↗⚑ flag

2. engineering-leadSwitch away from automatic model selection to a specific model of my choice

   weight 1 · round to Devin
   Devin✓fullprobed8/10

   Devin's docs explicitly state that Adaptive automatically routes prompts to the best model, but users can switch away from Adaptive to a specific model at any time using /model, directly matching the story. Missing for 10: independent/hands-on corroboration of the /model switch in practice and more detail on which specific models are selectable.

   • [claimed-docs] “Adaptive analyzes your prompt and routes it to the model that will deliver the best result.”
   • [claimed-docs] “You can switch away from Adaptive to a specific model at any time with /model.”
   • [claimed-docs] “Adaptive is an intelligent model router that automatically selects the best AI model for each task.”
   • [probe] “official CLI documented at https://docs.devin.ai/cli/adaptive”

   proof ↗⚑ flag

   YYLO~partialclaimed5/10

   The CLI init command shows a --subagent flag (e.g. 'claude') letting a user specify which model/agent to use instead of relying on defaults, implying manual model selection is possible; however there is no documentation of an explicit 'automatic model selection' mode being overridden, no list of supported models, and no engineering-lead-oriented control/settings UI shown. missing for 10: explicit documentation of an automatic/default model-selection mode, a full list of selectable models, and confirmation that this override is persistent/configurable at a project or team level.

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”

   proof ↗⚑ flag

Visibility monitoring

1. developerWatch what a running agent is doing in real time, including its current status

   weight 3 · round to Devin
   Devin✓fullclaimed7/10

   Devin's docs describe real-time observability features like watching the terminal execute commands with live output logs, jumping in during interactive browsing, and taking over in Devin's IDE mid-task, all indicating a live view of the agent's current activity/status. Missing for 10: no explicit dedicated 'status dashboard' documentation and no independent/hands-on corroboration of the real-time monitoring UX beyond vendor docs.

   • [claimed-docs] “Devin’s terminal, where you can watch commands being executed and view output logs. You can also copy the shell output for debugging purpose…”
   • [claimed-docs] “You can jump in to help Devin navigate through browsing tasks via the Interactive Browser.”
   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”

   proof ↗⚑ flag

   YYLO~partialclaimed4/10

   The GitHub docs mention a successful run ending in a 'watch receipt' with a state field (e.g. COMPLETED, exit_code, log_bytes), implying some status-tracking mechanism exists, and 'task start' reports a WORKING state before completion. However there is no dedicated 'watch' command, live dashboard, or streaming log evidence showing real-time observation of an in-progress agent's actions. missing for 10: explicit real-time streaming/monitoring command or UI, documentation of live status polling during execution, independent confirmation of watch behavior.

   • [github] “A successful run prints the installed YYLO version, initializes `.juno_task/`, then emits a watch receipt with `"state":"COMPLETED"`, `"exit…”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [claimed-docs] “Continue a captured session with `yy continue SESSION_ID`; do not reconstruct work from tmux scrollback.”

   proof ↗⚑ flag

2. developerGet notified when an agent completes a task or needs my input

   weight 2 · round to Devin
   Devin~partialclaimed6/10

   Devin supports Slack/Teams tagging where sessions and results appear in-thread (devin-docs-4, devin-docs-19), and scheduled sessions explicitly support 'notification preferences' (devin-docs-17), implying some completion/status alerts. However there's no dedicated first-party documentation of a generic notify-on-completion or needs-input alert system (e.g., email/push) outside Slack/Teams and scheduling contexts. Missing for 10: explicit documentation of a unified notification mechanism across all session types, and independent/hands-on confirmation that notifications reliably fire when input is needed.

   • [claimed-docs] “Tagging Devin on a Slack or Teams thread about a bug you’re discussing with coworkers”
   • [claimed-docs] “Tag Devin on Slack or Teams: Start sessions directly from conversations about bugs, feature requests, or questions.”
   • [claimed-docs] “Supports cron expressions for recurring schedules, one-time scheduling, notification preferences, and agent selection”
   • [claimed-docs] “You can jump in to help Devin navigate through browsing tasks via the Interactive Browser.”

   proof ↗⚑ flag

   YYLO~partialclaimed5/10

   YYLO emits watch receipts with a COMPLETED state/exit_code after a run finishes, and its Slack/GitHub integrations can return completed responses to the originating thread, giving developers a way to learn a task finished. However there's no evidence of a proactive notification for when an agent 'needs input' mid-task, nor any push/alert channel beyond polling receipts or the source-thread reply. Missing for 10: explicit 'needs input' alerting, a dedicated notification/webhook system, and independent confirmation the integration loop works end-to-end.

   • [github] “A successful run prints the installed YYLO version, initializes `.juno_task/`, then emits a watch receipt with `"state":"COMPLETED"`, `"exit…”
   • [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
   • [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”

   proof ↗⚑ flag

Natural language task intake

1. developerDescribe a feature or bug in plain language and have it automatically turned into a scoped implementation task

   weight 3 · round to Devin
   Devin✓fullcommunity7/10

   Devin's docs describe accepting natural-language asks (tickets, Slack/Teams messages, delegated tasks) and turning them into sessions/implementation tasks, which is the core intent-to-spec workflow (devin-docs-1, devin-docs-4, devin-docs-5, devin-docs-19). Community commentary raises concerns about actual task success rates and correctness (devin-comm-2, devin-comm-4), tempering confidence in scoping quality. Missing for 10: independent hands-on evidence that the auto-generated task scope/plan is accurate or reviewable before execution, and no dedicated 'plan/spec preview' feature described.

   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”
   • [claimed-docs] “Tagging Devin on a Slack or Teams thread about a bug you’re discussing with coworkers”
   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”
   • [claimed-docs] “Tag Devin on Slack or Teams: Start sessions directly from conversations about bugs, feature requests, or questions.”
   • [community] “From the graph at the end: 13.8% of issues resolved. Devin may need some additional help for awhile.”
   • [community] “Although the demos are impressive, they seem short and limited in scope... How often will the solution only be 90% correct, which is 100% no…”

   proof ↗⚑ flag

   YYLO~partialclaimed6/10

   YYLO's CLI lets a developer pass a plain-language task string (e.g. `yylo init --task "Describe one verifiable outcome"` or `yy ledger create "Validate recovery"`) which is then hydrated into a dedicated branch/worktree and handed to a subagent (yylo-docs-1, yylo-docs-2, yylo-gh-4, yylo-docs-11). This covers the 'turned into a scoped implementation task' half of the story, but there's no evidence of NLP-based scoping/decomposition logic — the description appears passed through largely as-is rather than analyzed/refined into a structured spec. Missing for 10: evidence of automatic task decomposition or requirement extraction from free-text input, and independent/hands-on confirmation that vague feature/bug descriptions produce well-scoped tasks.

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”

   proof ↗⚑ flag

2. product-managerConvert user feedback submissions into structured tasks with proposed scope

   weight 2 · round to Devin
   Devin~partialclaimed5/10

   Devin can ingest raw inputs like Linear/Jira tickets and Slack/Teams threads about bugs or feature requests and turn them into an actionable session (devin-docs-1, devin-docs-4, devin-docs-19), which covers the 'feedback-to-task' intake path, but there is no evidence of a distinct structured-task output with an explicit proposed scope/plan artifact for PM review before execution. Missing for 10: evidence of a scoping/planning deliverable (e.g., a spec doc or task breakdown with effort/scope estimate) generated prior to coding, and any PM-specific workflow or UI for reviewing/approving that scope.

   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”
   • [claimed-docs] “Tagging Devin on a Slack or Teams thread about a bug you’re discussing with coworkers”
   • [claimed-docs] “Tag Devin on Slack or Teams: Start sessions directly from conversations about bugs, feature requests, or questions.”
   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”

   proof ↗⚑ flag

   YYLO~partialprobed4/10

   YYLO can ingest external feedback (Slack messages, GitHub issues) directly into its kanban/ledger as structured tasks (yylo-docs-10), and a dedicated `feedback-yylo` CLI binary is confirmed live on npm (yylo-probe-rt-1), suggesting a feedback-to-task pathway exists. However, there is no documented mechanism for generating a 'proposed scope' alongside the task — no scope estimation, sizing, or planning artifact is described anywhere in the docs or GitHub evidence. Missing for 10: explicit scope-proposal output tied to feedback conversion, documentation of what the feedback-yylo binary actually produces, and any PM-facing evidence of structured scoping fields.

   • [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
   • [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
   • [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”

   proof ↗⚑ flag

Plan approval

1. developerReview and approve an agent's implementation plan before any code changes are made

   weight 3 · round drawn
   Devin—none0/10

   The evidence pack describes Devin's task delegation, IDE handoff, terminal visibility, and MCP integrations, but nowhere documents a plan-review/approval gate before Devin begins making code changes. Missing for 10: any doc mentioning an upfront plan proposal, explicit approval step, or 'plan mode' prior to execution.

   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”
   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”

   proof ↗⚑ flag

   YYLO—none0/10

   Evidence describes YYLO's task lifecycle (init, start, preflight read-only, finish queuing a candidate, merge land) but nothing indicates the agent produces an implementation plan that a developer reviews and approves before any code is written — preflight/checks occur on already-produced work, not a pre-code plan gate.

   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
   • [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”

   proof ↗⚑ flag

2. engineering-leadApprove a task's scope and contract before an agent is allowed to modify the repository

   weight 2 · round to YYLO
   Devin—none0/10

   The evidence pack shows delegation, review-after-the-fact, and IDE takeover workflows, but no documented mechanism where an engineering-lead must approve a task's scope/contract before Devin is allowed to start modifying the repository. Missing for 10: explicit pre-execution approval/gating workflow, scope/contract sign-off UI or API, evidence of blocking repo writes until lead approval.

   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”
   • [claimed-docs] “using /handoff to send longer tasks to cloud Devin”

   proof ↗⚑ flag

   YYLO~partialclaimed4/10

   YYLO documents a task/contract concept (YAML contracts, ledger tasks) and isolates agent work in dedicated branches/worktrees with a read-only preflight before any commit is queued (yylo-docs-2, yylo-docs-4, yylo-gh-4), which implies some spec-first gating. However there is no documented human approval/sign-off step where an engineering-lead explicitly reviews and approves scope/contract before the agent is permitted to start modifying the repo—task start appears automatic once invoked. Missing for 10: explicit lead-approval gate/workflow, evidence of a review UI or command requiring human sign-off, and confirmation that agent modification is blocked pending that approval.

   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”
   • [claimed-docs] “Save the same contract as YAML for a reusable workflow.”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”

   proof ↗⚑ flag

Ticket driven tasking

1. developerAssign a coding task to an agent directly from an existing issue or ticket

   weight 3 · round to Devin
   Devin✓fullclaimed8/10

   Docs explicitly state Devin can be asked to tackle Linear/Jira tickets, tagged on Slack/Teams threads about bugs to start sessions, and integrated via API/MCP to create sessions from external triggers, directly supporting assigning tasks from existing issues/tickets. Missing for 10: independent hands-on verification of ticket-to-task handoff and no direct product screenshot of ticket-linking UI in evidence.

   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”
   • [claimed-docs] “Tag Devin on Slack or Teams: Start sessions directly from conversations about bugs, feature requests, or questions.”
   • [claimed-docs] “Tagging Devin on a Slack or Teams thread about a bug you’re discussing with coworkers”
   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “you can create sessions on behalf of any user in your organization using the create_as_user_id parameter”

   proof ↗⚑ flag

   YYLO~partialclaimed6/10

   YYLO integrations pull GitHub issues into its kanban ledger and return completed responses to the source thread, and ledger tasks can then be started with a subagent via task start or yylo init, supporting the flow of turning an issue into an agent task. Missing for 10: a single documented command that directly converts one specific issue into an agent task in one step, and hands-on confirmation the GitHub-issue import works end-to-end.

   • [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [claimed-docs] “yy ledger create "Validate recovery" --status todo --tags auth yy ledger ready --sort asc yy ledger get TASK_ID”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”

   proof ↗⚑ flag

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

   weight 3 · round to YYLO
   Devin—none0/10

   No evidence of any data export feature, open-format export, or account/data portability tooling in Devin's docs; evidence covers task delegation, MCP, CLI, and platform support but nothing about exporting session data, knowledge, or playbooks in open formats for migration away from the product.

   ⚑ flag

   YYLO~partialprobed4/10

   Workflow contracts can be saved as YAML (yylo-docs-4) and the CLI/ledger source is fully open-source under MIT (yylo-probe-rt-2), suggesting no vendor lock-in, but there is no documented single 'export all data' command covering ledger records, task history, sessions, and artifacts in open formats. Missing for 10: an explicit data-export command/feature, documentation of export formats for ledger/kanban/session data, and confirmation that all state (not just workflow YAML) is portable.

   • [claimed-docs] “Save the same contract as YAML for a reusable workflow.”
   • [claimed-docs] “The 0.2.1rc6 channel adds ID-first general Records and typed task, wiki, workflow, and artifact profiles.”
   • [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”

   proof ↗⚑ flag

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

   weight 2 · round to YYLO
   Devin—none0/10

   Devin is a closed-source commercial SaaS product; no evidence of any open-source license or public source repository is present in the evidence pack, and the axis is applicable since AI tooling could conceivably publish open-source components. missing for 10: any open-license source release, public repo link, or licensing statement.

   ⚑ flag

   YYLO✓fullprobed8/10

   The GitHub repo is public and licensed under MIT, confirmed by a runtime probe reading the LICENSE file directly, and the repo (yylo-dev/yylo) is documented as the CLI orchestrator's source. missing for 10: no independent third-party audit or community commentary confirming completeness of the published source beyond the license file check.

   • [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to YYLO
   Devin—none0/10

   Devin is exclusively delivered as a cloud SaaS product (with local CLI/terminal front-ends that hand off to cloud sessions); no evidence anywhere in the docs or community discussion describes a self-hostable core engine or on-prem deployment option. Missing for 10: any documentation of self-hosted/on-prem deployment, container/binary distribution of the core agent, or licensing for self-hosting.

   • [claimed-docs] “Running Devin for Terminal in your local environment for quick fixes, code exploration, and interactive coding right from the command line”
   • [claimed-docs] “using /handoff to send longer tasks to cloud Devin”
   • [claimed-docs] “Configure it once, and every session boots into that known-good state.”

   proof ↗⚑ flag

   YYLO✓fullprobed8/10

   YYLO is an open-source, MIT-licensed CLI orchestrator (installable via npm, source on GitHub) that runs locally against a user's own repo/agents, so self-hosting the core product is inherently satisfied — confirmed by the public npm registry listing and the MIT LICENSE in the public repo. missing for 10: no dedicated self-hosting/deployment guide (e.g. server install, Docker, or persistent-service setup instructions) and no independent third-party report of someone self-hosting it in production.

   • [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
   • [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”

   proof ↗⚑ flag

Enterprise licensing

1. engineering-leadLicense an enterprise deployment with SSO and commercial support for organization-wide rollout

   weight 2 · round drawn
   Devin—none0/10

   No evidence pack items mention enterprise licensing, SSO, or commercial support offerings for Devin; only product feature docs and community sentiment are present. Missing for 10: SSO/SAML documentation, enterprise plan/pricing page, commercial support SLA details.

   ⚑ flag

   YYLO—none0/10

   YYLO's evidence pack shows only an open-source CLI orchestrator (MIT-licensed, npm package) with no mention of enterprise licensing tiers, SSO integration, or commercial support offerings; there is no pricing/plans page or enterprise sales material in evidence. missing for 10: enterprise/SSO licensing tier, commercial support plans, organization-wide deployment documentation.

   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
   • [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”

   proof ↗⚑ flag

Model flexibility

1. engineering-leadBring my own LLM or API key so agents run on the model of my choice

   weight 2 · round drawn
   Devin—none0/10

   Docs describe an internal 'Adaptive' model router and a /model command to pick among Devin's supported models, but there is no evidence of bringing a custom LLM or your own API key to run agents on a model of the engineering lead's choice.

   • [claimed-docs] “Adaptive analyzes your prompt and routes it to the model that will deliver the best result.”
   • [claimed-docs] “You can switch away from Adaptive to a specific model at any time with /model.”
   • [claimed-docs] “Adaptive is an intelligent model router that automatically selects the best AI model for each task.”

   proof ↗⚑ flag

   YYLO—none0/10

   Evidence shows a `--subagent claude` CLI flag implying some agent selection, but there is no documentation of configuring API keys, choosing alternate LLM providers, or any pricing/billing control for engineering leads. Missing for 10: explicit BYO-API-key setup, multi-provider/model configuration docs, and any pricing-limits guidance.

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”

   proof ↗⚑ flag

1. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Devin—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or privacy configuration options for Devin; the docs cover features, MCP, CLI, and environments but not data governance/retention settings.

   ⚑ flag

   YYLO—none0/10

   YYLO's evidence covers task orchestration, worktrees, ledgers, and merges, but nothing addresses data retention policies, storage duration, or user-controlled deletion of tasks/sessions/records. No docs mention exporting, purging, or deleting stored data or session logs.

   ⚑ flag

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

   weight 2 · round drawn
   Devin—none0/10

   No evidence pack item mentions telemetry opt-out, analytics settings, or usage-tracking controls for Devin; nothing addresses this privacy axis at all.

   ⚑ flag

   YYLO—none0/10

   No evidence pack item mentions telemetry, usage tracking, analytics collection, or an opt-out mechanism for YYLO; the docs and GitHub description focus entirely on task orchestration features.

   ⚑ flag

Knowledge context

1. developerAdd a context file describing my codebase conventions so agents generate more relevant plans and code

   weight 3 · round to Devin
   Devin✓fullclaimed9/10

   Devin explicitly supports AGENTS.md files placed in the project root that Devin reads before coding, plus a separate 'Knowledge' feature for sharing codebase-level conventions/context to improve plans and code generation. Missing for 10: independent/hands-on confirmation that this measurably improves plan/code relevance beyond vendor docs.

   • [claimed-docs] “Just put an AGENTS.md file in your project root (or anywhere else). Devin will look for the file before it starts coding.”
   • [claimed-docs] “Knowledge is the best way to share codebase-level (vs. task-level) context that can help Devin when working in your codebase.”
   • [claimed-docs] “Indexing your repositories allows Devin to understand your codebase and enables powerful features like Ask Devin and DeepWiki.”

   proof ↗⚑ flag

   YYLO—none0/10

   The evidence pack covers task orchestration, kanban ledgers, merge protections, and workflow runners, but nowhere describes a context/conventions file that agents read to generate more relevant plans or code. No mention of AGENTS.md, project instructions, or codebase-convention configuration exists in the docs or GitHub items provided.

   ⚑ flag

Project management integration

1. product-managerConnect issue trackers like Jira, Linear, ClickUp, or Monday.com so agents can manage tickets directly

   weight 3 · round to Devin
   Devin~partialclaimed6/10

   Devin explicitly supports Linear and Jira tickets natively (devin-docs-1) and its MCP extensibility (devin-docs-12, devin-docs-21) lets it connect to arbitrary tool servers including issue trackers, which could cover ClickUp/Monday.com. However, there's no first-party documentation of native ClickUp or Monday.com connectors, and no independent/hands-on evidence confirming ticket-management workflows actually work end-to-end via these integrations. missing for 10: explicit native ClickUp/Monday.com support docs, independent verification of issue-tracker workflows succeeding in practice.

   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”
   • [claimed-docs] “MCP (Model Context Protocol) lets you connect external tool servers to Devin CLI, giving the agent access to APIs, databases, issue trackers…”
   • [claimed-docs] “Extend Devin's reach with MCP integrations: Connect Devin to Datadog, Sentry, databases, Figma, Notion, Stripe, and hundreds of other tool”
   • [claimed-docs] “MCP tools are subject to the same permission system as built-in tools. You can control access at multiple levels”

   proof ↗⚑ flag

   YYLO—none0/10

   The integrations doc only mentions bringing Slack messages or GitHub issues into kanban (yylo-docs-10); there is no mention of Jira, Linear, ClickUp, or Monday.com anywhere in the evidence pack. Missing for 10: any documented connector or API integration for Jira, Linear, ClickUp, or Monday.com.

   • [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”

   proof ↗⚑ flag

Version control integration

1. developerConnect a GitHub repository so an agent can access the code and open pull requests against it

   weight 3 · round to Devin
   Devin~partialclaimed6/10

   Docs confirm repository indexing (public/private) and GitHub-repo access for context, plus 'Devin Review with Auto-Fix' responding to code review/CI, implying PR interaction, but there's no explicit documentation of a GitHub connection/auth flow or of Devin opening pull requests directly. missing for 10: explicit GitHub app/OAuth connection setup steps, explicit 'opens pull requests' documentation, independent/hands-on confirmation of PR creation.

   • [claimed-docs] “Indexing your repositories allows Devin to understand your codebase and enables powerful features like Ask Devin and DeepWiki.”
   • [claimed-docs] “These tools let you explore and query documentation for any GitHub repository (public or private with authentication)”
   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”
   • [claimed-docs] “Devin can connect to a VPN from inside its workspace, so sessions can reach internal services such as package registries, databases, and int…”

   proof ↗⚑ flag

   YYLO—none0/10

   Evidence shows YYLO operates on local git worktrees/branches and has an internal 'merge land' step, and can pull GitHub issues into its kanban, but there is no evidence of connecting a GitHub repository as a remote and having the agent open pull requests against it — the merge feature explicitly stays local/internal with no GitHub PR API integration mentioned.

   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
   • [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
   • [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”

   proof ↗⚑ flag

2. developerGrant an agent access to my repositories with a one-click install, without complex setup

   weight 2 · round to Devin
   Devin~partialclaimed5/10

   Devin does support connecting to repos (indexing, GitHub-based session creation, VPN access to internal git hosts) and this is described as straightforward onboarding, but there's no evidence of a literal 'one-click install' flow like a GitHub App marketplace install — setup instead involves indexing, environment configuration, AGENTS.md, and knowledge onboarding steps. Missing for 10: explicit one-click/marketplace-style install flow, independent evidence of setup simplicity, and confirmation that repo access requires no additional configuration.

   • [claimed-docs] “Indexing your repositories allows Devin to understand your codebase and enables powerful features like Ask Devin and DeepWiki.”
   • [claimed-docs] “Devin can connect to a VPN from inside its workspace, so sessions can reach internal services such as package registries, databases, and int…”
   • [claimed-docs] “Configure it once, and every session boots into that known-good state.”
   • [claimed-docs] “Just put an AGENTS.md file in your project root (or anywhere else). Devin will look for the file before it starts coding.”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO is documented as a CLI orchestrator requiring `npm install -g @yylo/cli` plus explicit `yylo init`/`task start` workflows that freeze SHAs, create worktrees, and hydrate dependencies — this is CLI-based setup, not a one-click repo-access grant. No evidence describes a GitHub App-style one-click install or OAuth flow for repo access. Missing for 10: any one-click install/authorization mechanism, evidence of simplified non-CLI onboarding, or a hosted install button.

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”

   proof ↗⚑ flag

Ci remediation

1. engineering-leadHave failed CI workflows automatically diagnosed and fixed with a proposed pull request

   weight 3 · round to Devin
   Devin✓fullclaimed7/10

   Devin explicitly documents 'Devin Review with Auto-Fix' that responds to code review comments, fixes flagged bugs, and iterates on CI failures, directly matching the story of auto-diagnosing and fixing failed CI with a proposed PR. However, this is vendor-only documentation with no independent/hands-on corroboration of the CI-fix workflow specifically. Missing for 10: independent verification of CI-fix accuracy/success rate, details on PR proposal format, and evidence of real-world reliability beyond the single docs line.

   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO is a CLI orchestrator for coding agents/workflows with kanban, ledger, and merge tooling, but nothing in the evidence pack mentions CI workflow failure detection, diagnosis, or auto-generating a fix PR from a failing CI run. Merge/land explicitly excludes running tests or validation ('Tests and semantic reviews are explicit project checks outside merge'), which is the opposite of an integrated CI-fix loop.

   • [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
   • [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”

   proof ↗⚑ flag

2. developerTrigger an agent from CI/CD pipelines to fix a broken build or failing test

   weight 2 · round to Devin
   Devin~partialclaimed6/10

   Docs explicitly state Devin Review with Auto-Fix can iterate on CI failures and fix flagged bugs, and the Devin API lets you integrate Devin into applications/workflows and create sessions programmatically (including on behalf of users), which supports triggering it from automated pipelines. However, there's no explicit documented example of a CI/CD pipeline (e.g., GitHub Actions/Jenkins) directly invoking Devin on a failing build/test, and no independent/hands-on confirmation of this exact workflow. Missing for 10: explicit CI/CD trigger integration example, independent verification that pipeline-triggered fixes work reliably.

   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”
   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “you can create sessions on behalf of any user in your organization using the create_as_user_id parameter”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO is documented as a CLI orchestrator with kanban tasks, workflow/parallel runners, and Slack/GitHub-issue integrations, but nothing in the evidence describes triggering it from a CI/CD pipeline or having it react to a failing build/test. Since it's a scriptable CLI, this axis plausibly applies, but there is no documented CI hook, GitHub Actions example, or build-failure-triggered workflow.

   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
   • [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”

   proof ↗⚑ flag

Diff review

1. developerConfigure an agent to automatically open a pull request when its task completes

   weight 2 · round to Devin
   Devin~partialclaimed5/10

   Devin is known to work within GitHub workflows and create PRs as part of its task completion (implied by its coding-agent nature and features like Auto-Fix responding to review comments/CI), but the evidence pack has no explicit documentation describing a configurable setting to auto-open a pull request upon task completion. missing for 10: explicit docs describing PR-creation-on-completion configuration, settings/toggle for auto-PR behavior, and independent confirmation of this specific workflow.

   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”
   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”
   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO's docs describe task branches, worktrees, and an internal 'merge land' step that composes a candidate directly, explicitly stating merge 'launches no models, chooses no reviewers'—there is no mention anywhere of opening a GitHub pull request on task completion, only importing issues into kanban and returning responses to source threads. No CLI flag, workflow step, or integration doc references PR creation.

   • [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
   • [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
   • [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”
   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”

   proof ↗⚑ flag

2. developerReview a diff of an agent's changes and approve it before it becomes a pull request

   weight 3 · round to Devin
   Devin~partialclaimed4/10

   Docs mention delegating a task and 'taking over in Devin's IDE once it gives you a good first draft' (devin-docs-5), implying some human checkpoint before final output, and Devin's terminal/log viewing lets you watch work in progress (devin-docs-6). However there is no explicit documentation of a diff-review/approve-before-PR gate — 'Devin Review with Auto-Fix' (devin-docs-20) is about post-PR review comment handling, not a pre-PR approval step. Missing for 10: explicit diff viewer with approve/reject before PR creation, documentation of a formal approval gate, and independent/hands-on confirmation of this workflow.

   • [claimed-docs] “Delegating a more complex task via the web application and taking over in Devin’s IDE once it gives you a good first draft.”
   • [claimed-docs] “Devin’s terminal, where you can watch commands being executed and view output logs. You can also copy the shell output for debugging purpose…”
   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”

   proof ↗⚑ flag

   YYLO—none0/10

   Docs describe worktrees, candidate branches, and a 'merge land' step, but nowhere is there evidence of a diff-review UI or an explicit developer approval gate before a pull request is opened; in fact merge is described as launching 'no models, no reviewers' and reviews are called 'explicit project checks outside merge', with no PR-creation flow documented at all.

   • [github] “`task start` freezes the protected target SHA, creates a dedicated branch/worktree, and completes configured dependency hydration before rep…”
   • [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
   • [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
   • [claimed-docs] “Start hydrates an exact-base task worktree. Preflight is read-only, finish queues the committed candidate”

   proof ↗⚑ flag

Pr review automation

1. ai-native userHave incoming issues automatically triaged with severity suggested and routed to the right owner

   weight 2 · round drawn
   Devin—none0/10

   Devin can be pointed at Linear/Jira tickets or tagged in Slack to work a bug, but nothing in the evidence describes automatic triage logic that assesses severity or routes issues to the correct owner — these are core, specific parts of the story. Missing for 10: severity classification/scoring, ownership/routing logic, any 'triage' feature or automated inbox-sorting workflow.

   • [claimed-docs] “Ask Devin to tackle Linear/Jira tickets, implement entirely new features, repro and fix bugs, build internal tools, and more!”
   • [claimed-docs] “Tagging Devin on a Slack or Teams thread about a bug you’re discussing with coworkers”
   • [claimed-docs] “Tag Devin on Slack or Teams: Start sessions directly from conversations about bugs, feature requests, or questions.”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO's integrations feature only pulls GitHub issues/Slack messages into a kanban board and returns responses to the source thread (yylo-docs-10); there is no evidence of automated severity classification or owner-based routing logic anywhere in the pack.

   • [claimed-docs] “Bring Slack messages or GitHub issues into kanban and return completed responses to their source thread.”

   proof ↗⚑ flag

2. engineering-leadHave every pull request automatically reviewed with AI-generated inline comments

   weight 3 · round to Devin
   Devin~partialclaimed5/10

   Devin documents a 'Devin Review with Auto-Fix' feature that responds to code review comments, fixes flagged bugs, and iterates on CI failures, implying an automated review capability tied to PRs, but the evidence pack gives no detail on how review comments are generated, whether they are inline, or how coverage/setup works for 'every PR'. missing for 10: explicit documentation of inline AI-generated PR comments, configuration for gating every PR, and independent/hands-on confirmation of the review quality.

   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO's own docs describe it as a CLI orchestrator for coding-agent tasks, workflows, and receipt-backed merges — not a PR-review tool. Evidence explicitly states 'Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers' (yylo-gh-6), meaning there is no automated AI-generated inline PR review capability in the product.

   • [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”
   • [github] “`merge land` selects one immutable task source, composes in a private detached candidate, and uses Git expected-old ref protection. A moved …”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”

   proof ↗⚑ flag

Readiness checks

1. engineering-leadAutomatically fix failing agent-readiness criteria in my repository

   weight 1 · round to Devin
   Devin~partialclaimed6/10

   Devin Review with Auto-Fix explicitly auto-fixes CI failures and review comments, which could cover agent-readiness gate checks if they're wired into CI/PR review, and AGENTS.md support shows Devin can consume agent-readiness config files. However there's no evidence of a dedicated 'agent-readiness criteria' scorecard or targeted remediation workflow distinct from generic CI/review auto-fix. Missing for 10: explicit agent-readiness scoring/criteria detection, evidence of automatically remediating specific agent-readiness failures (vs generic CI/review comments), and independent validation of this auto-fix loop working reliably.

   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”
   • [claimed-docs] “Just put an AGENTS.md file in your project root (or anywhere else). Devin will look for the file before it starts coding.”
   • [claimed-docs] “Configure it once, and every session boots into that known-good state.”

   proof ↗⚑ flag

   YYLO—none0/10

   YYLO's diagnostic tool (`doctor workspace`) explicitly never fetches or changes the workspace, and merge/tests are described as explicit checks with no automated remediation; there is no documented feature that automatically fixes failing agent-readiness criteria.

   • [github] “`doctor workspace` is intentionally nonzero when it finds an actionable topology problem; it never fetches or changes the workspace.”
   • [github] “Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, a…”

   proof ↗⚑ flag

2. engineering-leadRun a readiness report that evaluates how ready my repository is for autonomous agents

   weight 2 · round to YYLO
   Devin—none0/10

   No evidence of any 'readiness report' or scoring feature that evaluates a repository's suitability for autonomous agents; docs cover onboarding features like AGENTS.md, environment setup, indexing, and knowledge, but nothing that generates a readiness assessment/report artifact for engineering leads.

   ⚑ flag

   YYLO~partialclaimed4/10

   YYLO ships a `doctor workspace` check that flags actionable topology problems without mutating the repo, and its GitHub description references 'release-readiness boundaries,' which gesture at repo-readiness diagnostics, but there is no documented dedicated report scoring or evaluating overall repository readiness for autonomous agents. missing for 10: a named readiness-report command/output, criteria for 'agent readiness' beyond topology checks, and any sample report artifact.

   • [github] “`doctor workspace` is intentionally nonzero when it finds an actionable topology problem; it never fetches or changes the workspace.”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”

   proof ↗⚑ flag

Concurrent execution

1. engineering-leadRun many agent tasks concurrently to scale delivery throughput

   weight 3 · round to Devin
   Devin~partialclaimed7/10

   Devin docs explicitly document running multiple Devins in parallel on independent tasks and provide an API with create_as_user_id for programmatically spawning sessions on behalf of org members, directly supporting concurrent scaling of throughput. However, there's no first-party data on concurrency limits, cost/resource management at scale, or independent case studies validating throughput gains at team scale; missing for 10: quantified concurrency limits/scaling guidance, independent evidence of large-scale parallel usage, and cost/governance controls for many simultaneous sessions.

   • [claimed-docs] “Run multiple Devins in parallel: Carve out independent tasks and run them simultaneously.”
   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “you can create sessions on behalf of any user in your organization using the create_as_user_id parameter”
   • [claimed-docs] “create sessions, manage playbooks and knowledge, set up schedules, and more”

   proof ↗⚑ flag

   YYLO~partialclaimed6/10

   YYLO documents a 'bounded concurrent fan-out' parallel-runner for independent kanban tasks with structured evidence per item, plus run-until-completion looping, which supports running multiple agent tasks concurrently. However, evidence lacks details on concurrency limits, scaling numbers, resource isolation at scale, or independent/hands-on validation of throughput gains. missing for 10: concrete concurrency limits/benchmarks, independent third-party validation of parallel scaling, evidence of large-scale (10s-100s of tasks) usage in production.

   • [claimed-docs] “Bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item.”
   • [claimed-docs] “Repeat bounded YYLO iterations until no open kanban work remains.”
   • [claimed-docs] “Continue a captured session with `yy continue SESSION_ID`; do not reconstruct work from tmux scrollback.”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”

   proof ↗⚑ flag

Deployment flexibility

1. engineering-leadSelf-host agent infrastructure locally, in containers, or on my own VMs

   weight 2 · round to YYLO
   Devin—none0/10

   Devin is delivered as a cloud-hosted SaaS agent platform; all evidence points to cloud sessions, API access, VPN connectivity into customer networks, and a CLI/terminal client for local interaction, but nothing indicates the core agent infrastructure itself can be self-hosted on-prem, in customer-managed containers, or on customer VMs. Missing for 10: any documentation of a self-hosted/on-prem deployment option, container images for the agent runtime, or VM-based installation of Devin's backend.

   • [claimed-docs] “Devin can connect to a VPN from inside its workspace, so sessions can reach internal services such as package registries, databases, and int…”
   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “Running Devin for Terminal in your local environment for quick fixes, code exploration, and interactive coding right from the command line”

   proof ↗⚑ flag

   YYLO~partialprobed5/10

   YYLO is an open-source, MIT-licensed CLI (npm package + public GitHub repo) that runs locally as an orchestrator, implying it can be run on a developer's own machine, in containers, or VMs since it's just a Node CLI operating on a local git worktree. However, there is no explicit documentation of container/VM deployment, Docker images, self-hosting guides, or infrastructure requirements for running at scale. missing for 10: explicit self-hosting/deployment docs (Docker/container images, VM setup guides), infrastructure/scaling guidance, and confirmation of statelessness or multi-instance operation for parallel agent infrastructure.

   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”
   • [probe] “PROBE runtime (recorded 2026-09-14): `curl -s https://raw.githubusercontent.com/yylo-dev/yylo/HEAD/LICENSE | head -3` returns 'MIT License /…”
   • [github] “A successful run prints the installed YYLO version, initializes `.juno_task/`, then emits a watch receipt with `"state":"COMPLETED"`, `"exit…”

   proof ↗⚑ flag

Headless automation

1. developerRun an agent headlessly inside CI/CD pipelines and shell scripts

   weight 2 · round drawn
   Devin~partialprobed6/10

   Devin's API is explicitly designed to 'integrate Devin into your applications, automate workflows, and build powerful tools' and supports creating sessions on behalf of users, which enables scripted/headless invocation, and a CLI is also documented. However, there is no explicit CI/CD pipeline example, exit-code/status handling, or GitHub Actions/shell-script integration guide in the evidence — the closest CI-related capability shown is 'Auto-Fix' reacting to CI failures rather than Devin running as a CI step itself. missing for 10: explicit CI/CD pipeline integration docs (e.g., GitHub Actions/shell script examples), documented headless/non-interactive CLI invocation with exit codes.

   • [claimed-docs] “The Devin API enables you to integrate Devin into your applications, automate workflows, and build powerful tools.”
   • [claimed-docs] “you can create sessions on behalf of any user in your organization using the create_as_user_id parameter”
   • [claimed-docs] “Enable Devin Review with Auto-Fix so Devin automatically responds to code review comments, fixes flagged bugs, and iterates on CI failures”
   • [probe] “official CLI documented at https://docs.devin.ai/cli/adaptive”

   proof ↗⚑ flag

   YYLO~partialprobed6/10

   YYLO is a CLI-first orchestrator with commands (init, task start, ledger, loop, workflow-runner, parallel-runner) that are inherently scriptable and non-interactive, and its runtime bins (yylo, yy, ypl) are published on npm confirming CLI availability. However, there's no explicit CI/CD documentation, no exit-code/error-handling guarantance for pipeline use beyond doctor workspace, and no CI examples (GitHub Actions, GitLab CI, etc.) or headless/no-TTY confirmation. missing for 10: explicit CI/CD pipeline examples or docs, confirmed non-interactive/headless mode guarantees, exit-code contract documentation for scripting, independent hands-on CI usage reports.

   • [claimed-docs] “npm install -g @yylo/cli@0.2.2 yylo init --task "Describe one verifiable outcome" --subagent claude”
   • [claimed-docs] “`yy loop` repeats arbitrary shell commands sequentially.”
   • [claimed-docs] “Bounded concurrent fan-out for independent kanban tasks, data items, or complete commands—with structured evidence for every item.”
   • [github] “`doctor workspace` is intentionally nonzero when it finds an actionable topology problem; it never fetches or changes the workspace.”
   • [github] “YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes. It is for developers who…”
   • [probe] “PROBE runtime (recorded 2026-09-14): `npm view @yylo/cli name version bin` — the official CLI is live on the public npm registry (@yylo/cli …”

   proof ↗⚑ flag