Introducing Code Scans

Today we’re introducing Code Scans: a new way to turn broad engineering goals into concrete improvements across your codebase. Tell Devin what you want to achieve, and it helps you investigate what needs to change, evaluate the findings, and turn them into pull requests.

Many engineering tasks start with a specific change. Others start with an outcome:

• Improve SEO
• Reduce maintenance overhead
• Make your application compile faster

These goals often stay on the backlog because the first step alone is a substantial project: investigating the codebase to figure out where to start. Additionally, identifying the opportunities is only half the work — someone still has to implement the changes, and many of them.

Code Scans helps with both.

Powered by Agentic MapReduce, the architecture we built for Devin Security Swarm, Code Scans breaks large investigations into focused batches, distributes them across parallel agents, and synthesizes their findings into one report. Devin then turns its findings into PRs ready to review.

To get started, type /scan in the Devin webapp.

Start with a goal

You don’t need to know which files to look at before starting a scan. Instead, you define what you’re looking for, and Devin works with you to turn that goal into a concrete codebase investigation.

For example:

Find unused code in our web app. Exclude generated files and test fixtures, and check for indirect references before recommending a removal.

You can also bring your own criteria: a team’s coding standards, an accessibility checklist, or requirements for an upcoming migration. Devin helps establish what to inspect, what to skip, and what should count as a finding.

Once you confirm the scope and settings, Devin runs the investigation and brings back a list of findings ordered by priority. From there, you can inspect the evidence, discuss the results with Devin, and ask it to open PRs for the issues you want to address.

Improve Rust compilation time

We asked Code Scans to speed up compilation in the Dioxus repository. Devin identified opportunities to streamline dependencies and build configuration, including making heavyweight CLI features opt-in rather than compiling them by default. After applying the changes locally, clean debug build time dropped from 58.6 seconds to 21.0 seconds—a 64% reduction across the 22 workspace crates tested.

Scan findings

dioxus · compile-time scan

1. Default mounted feature forces web-sys/js-sys/wasm-bindgen (and serialize forces serde) onto every non-web renderer

   The default feature set enables mounted, which activates the heavyweight optional web-sys dependency (and transitively js-sys + wasm-bindgen) — yet those bindings are…

2. Oversized foundational crate: stable generated element/attribute tables bundled with volatile logic causes full re-expansion and downstream recompiles

   dioxus-html is a foundational crate that every renderer depends on, and it bundles its enormous, near-static generated element/attribute API (elements.rs, global_attributes.rs)…

3. builder_constructors! element table is the html crate's dominant compile cost (~112 elements, ~112 per-element proc-macro invocations, duplicated hot-reload traversal)

   The single builder_constructors! invocation is the html crate's dominant compile-time cost. It expands 112 HTML/SVG elements, each into a unit struct, TAG_NAME/NAME_SPACE…

4. cargo-generate compiled unconditionally in dioxus-cli though used only by dx create

   cargo-generate is a non-optional dependency used only by the dx create/dx init scaffolding path, but it drags in git2/libgit2-sys (a native C library build), liquid templating…

5. dioxus-ssr pulls tokio "full" (default-on) but only uses fs + io-util

   dioxus-ssr declares tokio = { version = "1.28", features = ["full"], optional = true }, but the crate uses tokio in exactly one module (incremental.rs) and only touches tokio::fs and…

SEO Optimization

We ran a scan for SEO issues across devin.ai and cognition.com. It surfaced 44 findings across the two repositories, and we shipped fixes over the following days. Comparing Ahrefs crawls before and after:

• Ahrefs health score increased from 87 to 92 on devin.ai.
• Slow pages decreased by 73% on devin.ai.
• Missing image alt text was eliminated on cognition.com.

Scan findings

devin.ai + cognition.com · SEO scan

1. Customer case-study pages emit relative og:image / twitter:image / JSON-LD i…

   Every customer case-study page (/customers/<slug>) sets its Open Graph image, Twitter image, and Article JSON-LD image to the raw frontmatter.ogimagePath value, which is a root-relative path with no domain and no leading slash. Open Graph / Twitter Card spec and schema.org require absolute URLs, so previews and the Article rich-result image break.

   devin-website

2. Redirect chain /resources/university → /university → external drops a hop on a…

   vercel.json defines /resources/university -> /university and, separately, /university -> https://learn.devinenterprise.com. Because the first redirect targets another redirect source, requests to /resources/university traverse a two-hop 301 chain instead of going straight to the final destination. Ahrefs confirms /resources/university has 157 live backlinks (22 referring domains).

   devin-website

3. Homepage og:url resolves to non-canonical /index (mismatches canonical https:…

   The root layout sets openGraph.url: './' on every page. This holds for sub-routes but is false for the homepage: Next resolves ./ for the root route against pathname /index, so the served homepage emits og:url = https://cognition.com/index while its canonical link tag is https://cognition.com.

   cognition-marketing-website

4. Terminal layout omits the JSON-LD structured data every base/desktop page emits

   The _terminalLayout head assembles title/description/canonical/OG/hreflang but emits no JSON-LD, unlike _baseLayout and _desktopLayout which both ship a default SoftwareApplication block. Its consumers /cli (the Devin CLI product page) and /auto-triage are both indexable central product surfaces.

   devin-website

5. Ended event stays indexable with meta description advertising a live webinar

   The whats-new-in-devin-06-24-26 event page announces on-page that the event is over ('This event has ended', 'Event ended', 'Registration closed'), yet its metadata contains no robots: {index:false} and its meta/OG descriptions still advertise the webinar as live and upcoming. So an expired page remains indexable while its search snippet promotes a past event as though registration were open.

   cognition-marketing-website

Agentic MapReduce

Code Scans is built on top of Agentic MapReduce, the architecture we built for Devin Security Swarm, to make codebase-wide investigations practical. It works in 4 phases:

1. Plan. Devin studies your repository and defines rules for identifying code relevant to your goal.
2. Shard. Those rules run across the codebase, and the matching code is divided into focused batches.
3. Map. Parallel Devin agents investigate each batch, reading surrounding code as needed and reporting their findings.
4. Reduce. A final agent combines the findings, removes duplicates, and prioritizes the results into one report.

Agentic MapReduce Pipeline

dead-code scan example

1. 1Plan
2. 2Shard
3. 3Map
4. 4Reduce

1. Plan

Agentic

Devin studies the repository and defines rules for the code relevant to your goal — here, symbols, modules, and dependencies that may no longer be used.

repoagentselectors

exports with no importersunreferenced modulesunused dependenciesstale feature flags

This keeps each agent’s context focused and directs the reasoning budget toward relevant code rather than repeated searching. This architecture also ensures completeness: every selected batch must be processed. Code Scans brings that same approach beyond security to the engineering goals you define.

What would you scan for?

Code Scans can investigate a wide range of engineering questions, using your codebase’s conventions and the criteria you provide. Here are some examples:

Scan	Goal
Performance	Find slow paths, redundant computation, and missed caching opportunities that could make your application faster.
Database queries	Look for N+1 queries, unnecessary round trips, unbounded reads, and other inefficient or unreliable data-access patterns.
Test coverage	Identify important flows, edge cases, and failure paths that aren’t covered by tests.
Dead code	Find unused functions, modules, dependencies, and obsolete feature flags, with evidence for what can safely be removed.
Code quality	Look for duplicated logic, unnecessary complexity, better abstraction opportunities, and patterns that violate your team’s coding standards.
Cleanup	Identify redundant abstractions, excessive boilerplate, and code that can be simplified without changing behavior.
Telemetry	Find gaps in logging, metrics, and tracing that make failures difficult to diagnose or important behavior difficult to measure.
Accessibility	Look for missing labels, broken keyboard interactions, and other gaps against the WCAG criteria you specify.
Compliance	Investigate sensitive-data handling, audit trails, and retention logic against your organization’s regulatory requirements and policies.
Migration planning	Trace existing dependencies, end-to-end flows, and business logic to produce a plan for an upcoming migration.
SEO Optimization	Find code-level issues affecting search visibility, including missing or duplicated metadata, incorrect canonical URLs, indexing directives, and gaps in sitemaps or structured data.
Your own	Define a pattern you want Devin to look for throughout the codebase.

The most useful scan might come from a question your team has been putting off because answering it meant looking everywhere.

Type /scan in your Devin session, specify what you want to investigate, build the scope together, and start optimizing your codebase today.

Try Code Scans at devin.ai.