Nubank used Devin to split an 8-year-old ETL monolith into sub-modules

Nubank had a core ETL codebase with millions of lines of code. Engineers gave the repetitive refactoring work to Devin and reviewed the output. Cognition reports large time and cost savings.

Organization: Nubank
Industry: Banking
When: 2024
Evidence: Vendor case study
Agents and tools: Devin

Reported outcome

Cognition reports 8–12x engineering-time efficiency and over 20x cost savings on the data-class migrations.

8–12x (vendor)
Engineering efficiency
>20x (vendor)
Cost savings

Caveats

Published by the company that sells the agent. Treat numbers as marketing until confirmed elsewhere.

Published by Cognition, the company that sells Devin.
The case study page shows 8x in its header and 12x in its body text. Its own method note gives a range of 8–12x.
Efficiency is measured against hours spent prompting and reviewing Devin, not against total project time.

What the agent does

Devin takes one migration task at a time. Each task moves one data class out of the monolith into a sub-module. Engineers write the instructions, then review and merge the result.

Why this works

The work is repetitive, well-defined, and checkable. Each migration follows the same pattern. Tests and the build tell you if a change is correct. This is the best kind of task to give to a coding agent.

What to copy

Do one migration by hand first. Turn it into a written playbook.
Give the agent the playbook plus one finished example.
Run many small tasks in parallel. Review each one like a junior engineer's pull request.
Track hours spent on prompting and review, so you can measure the real saving.

Starter prompt

Written by us, not by Nubank or Cognition.

Task: migrate {ClassName} out of {monolith_path} into the module {target_module}.

Follow the playbook in docs/migration-playbook.md exactly.
A finished example is in PR #{example_pr}. Match its structure.

Done means:
1. The class and its tests live in {target_module}.
2. All imports in the monolith point to the new location.
3. `make test` and `make lint` pass.
4. No behavior change. Do not refactor anything else.

Open one pull request. In the description, list every file you touched
and anything you were unsure about.