Devin Code Scans splits repository audits across parallel agents

Cognition has released Code Scans, a Devin mode that audits an entire repository against a defined goal and can turn its findings into pull requests. Teams start a scan by entering /scan in Devin, then specify what the system should inspect, exclude, and report.

In Cognition’s demonstration on the open-source Dioxus repository, Devin analyzed thousands of files across 22 workspace crates and produced changes that reduced debug build time from 58.6 seconds to 21.0 seconds, a 64% decrease. Cognition reported the result; no independent evaluation accompanied the release.

A distributed answer to context limits

Repository-wide work requires tracing relationships across files, packages, services, and configuration. Typical examples include finding unused code, detecting N+1 database queries, locating untested flows, or updating every call site affected by a migration.

A single agent has limited working context and must spend part of it searching for relevant files. Search alone also provides weak evidence of coverage because the agent may stop before examining an important directory or file type.

Code Scans addresses that constraint with Agentic MapReduce, Cognition’s adaptation of the distributed-computing pattern. One agent defines executable selection rules, parallel workers investigate bounded groups of files, and a final agent combines their structured findings.

Four stages turn a goal into findings

The deterministic sharding step distinguishes this design from an agent that repeatedly guesses which file to inspect next. Its filters are ordinary executable logic, so teams can examine whether the scan included the expected directories, extensions, and code patterns.

Subsequent runs process files changed since the last scanned commit. That incremental model reduces the compute required for recurring audits and makes scans more practical in continuous development workflows.

Explicit boundaries produce better scans

Cognition suggests several initial uses for repository-wide audits:

• Slow execution paths and N+1 database queries
• Untested user flows and edge cases
• Dead code and stale feature flags
• Accessibility violations against defined WCAG criteria
• Violations of a team’s internal coding standards

Effective scan goals specify the relevant components, exclusions, and acceptance criteria. A performance scan might name the request paths and latency patterns under review, while a dead-code scan might exclude generated files, public APIs, and code loaded through reflection.

Tasks with measurable repository-wide requirements are the strongest fit. These include migrations that must update every call site, policy enforcement across services, compilation cleanup, and regressions spread across several packages.

Security Swarm supplied the blueprint

Code Scans generalizes the architecture Cognition introduced with Devin Security Swarm. Security audits suit the pattern because vulnerable code is sparse, findings can span several files, and useful coverage requires examining the repository systematically.

Cognition reports that Security Swarm achieved 72% recall on a benchmark of 50 vulnerabilities drawn from the GitHub Advisory Database. Recall measures the share of known vulnerabilities found; it does not describe the false-positive rate. The benchmark included repositories written in Go, Python, JavaScript, Rust, Ruby, C#, Java, Swift, PHP, Elixir, Erlang, C, Kotlin, and Dart.

Those results provide evidence for the architecture under a defined security benchmark, though they do not establish equivalent accuracy for performance, testing, accessibility, or custom policy scans. Each use case depends on its own selectors, evaluation rules, and validation process.

Selectors set the coverage ceiling

The Plan stage determines which files reach the workers. If its filters omit a directory, generated artifact, unusual extension, or indirectly loaded module, later stages cannot recover the missing evidence. Teams should therefore review generated selectors and test them against known examples before treating a scan as comprehensive.

Parallel execution also introduces compute and coordination costs. Code Scans exposes batch size as a per-profile setting, allowing teams to balance runtime, concurrency, and expense. Large batches increase parallelism, while smaller batches limit simultaneous agent work.

Reducer quality creates another constraint because repository-level conclusions depend on compressed worker outputs. Cross-file behavior may be missed when a worker omits relevant details from its structured result, even if it inspected the correct files. Pull requests produced from scan findings still require tests, code review, and the project’s normal validation pipeline.

Repository audits become programmable

Code Scans is available through the /scan command for teams using Devin. Enterprise customers can also list and manage runs through the v3 API, which supports integration with scheduled jobs, internal tooling, and review workflows.

The release shifts repository-wide agent work toward explicit orchestration: executable coverage rules, parallel bounded investigations, structured outputs, and a final synthesis stage. For developers evaluating the feature, the central questions are whether its selectors cover the intended code, whether its findings survive project tests, and whether the runtime and compute cost improve on existing static analysis or manual audits.