The best enterprise 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 somewhat straightforward (i.e. under 90 minutes of human engineering time) and backwards compatible.
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 enterprise Devin use case is shallow and broad, as opposed to narrow and deep. For example, asking Devin for complex, net-new features (even if the work is repetitive!) is unlikely to be sufficiently reliable at scale.
Narrow-deep vs Shallow-broad comparison
A large backlog of horizontal, simple changes (e.g. SonarQube issues) is much more likely to generate 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, or technical debt backlogs are all great use cases for Devin. For our purposes, let’s assume we’re working on a code migration. We must be able to 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. It can be a:
  • file
  • notebook
  • module
…as long as each slice has:
  1. under 90 minutes of human engineering work
  2. a way to verify code changes, e.g. via running tests, build the code, CI checks, or a custom verification script
It is critical for each Devin to know objectively if it has successfully completed its task. Until it completes the verification step, it should continue to iterate (e.g. 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 backwards compatible. Taking advantage of Devin’s parallelism, we incrementally complete the migration one slice at a time. After a human review, we successively merge each PR into master. Parallel execution visualization The overall model for a Devin use case therefore looks as follows: Overall model diagram We teach Devin to be maximally reliable at the individual slice level of every use case, so that when parallelizing over 1000s of slices we maintain high reliability at scale. Even a seemingly 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 (i.e. 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 often good use cases for Devin, so long as they are incremental. For example, 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