Skip to main content
Strategic use cases are large, high-business value projects that can be sliced into isolated, repetitive subtasks. Each slice is the work of one Devin, so should be straightforward (under 90 minutes of human engineering time) and incremental.
TLDR — Devin Use Case Requirements:
  1. High volume of repetitive subtasks (slices)
  2. Subtasks of junior engineer-level difficulty
  3. Subtasks that are isolated and can be done incrementally
  4. Subtasks with an objective verification loop
  5. (Recommended): Minimal project dependencies

​
Necessary characteristics

An optimal strategic Devin use case is shallow and broad, as opposed to narrow and deep. Complex, net-new features (even if repetitive) are unlikely to be sufficiently reliable at scale.
Narrow-deep vs Shallow-broad comparison
A large backlog of horizontal, simple changes (e.g. SonarQube issues) generates enormous ROI when horizontally scaled. Horizontal changes diagram
The simpler the slice, the more reliable the overall project.

​
Slicing Use Cases [IMPORTANT]

Migrations, refactors, modernizations, and technical debt backlogs are strong use cases. For example, consider a code migration. Split the migration into isolated slices, where each task gets tackled by an individual Devin session. Slicing use cases illustration

​
Verification

A slice should be the smallest atomic unit of the project (file, notebook, or module) with:
  1. Under 90 minutes of human engineering work
  2. A way to verify code changes (tests, build, CI checks, or custom verification script)
Each Devin must know objectively if it has successfully completed its task. Until it completes verification, it should continue to iterate using detailed stack traces or error logs.
Each slice should avoid having too many dependencies or platforms to interact with. Focus Devin on the code changes! Backwards compatibility diagram Each slice must be isolated and incremental. Taking advantage of Devin’s parallelism, complete the migration one slice at a time. After human review, successively merge each PR into master. Parallel execution visualization The overall model for a Devin use case: Overall model diagram Devin must be maximally reliable at the individual slice level, so that when parallelizing over 1000s of slices we maintain high reliability at scale. Even a small margin of error can result in many incorrect changes when scaled up.

​
To be provided by the customer

  • Clear detail for every step in each slice (a detailed write-up or video of the end-to-end process is highly effective)
  • Several examples of before/after code changes (input/output pairs)
  • Access granted to Devin for all required dependencies in each slice

​
Examples

Ongoing technical debt tasks (e.g. PR review or QA testing) are also strong use cases, assuming they can be split into slices.
Migrations, modernizations, and refactors are strong use cases for Devin when they are incremental. A migration that requires upgrading the entire repository to the new system at the same moment, rather than one slice at a time, is not recommended.
Additional Reading: Nubank Migration Case Study
⌘I