How Nubank refactors millions of lines of code to improve engineering efficiency with Devin
Overview
One of Nubank’s most critical, company-wide projects for 2023-2024 was a migration of their core ETL — an 8 year old, multi-million lines of code monolith — to sub-modules. To handle such a large refactor, their only option was a multi-year effort that distributed repetitive refactoring work across over one thousand of their engineers. With Devin, however, this changed: engineers were able to delegate Devin to handle their migrations and achieve a 12x efficiency improvement in terms of engineering hours saved, and over 20x cost savings. Among others, Data, Collections, and Risk business units verified and completed their migrations in weeks instead of months or years.
The Problem
Nubank was born into the tradition of centralized ETL FinServ architectures. To date, the monolith architecture had worked well for Nubank — it enabled the developer autonomy and flexibility that carried them through their hypergrowth phases. After 8 years, however, Nubank’s sheer volume of customer growth, as well as geographic and product expansion beyond their original credit card business, led to an entangled, behemoth ETL with countless cross-dependencies and no clear path to continuing to scale.
For Nubankers, business critical data transformations started taking increasingly long to run, with chains of dependencies as deep as 70 and insufficient formal agreements on who was responsible for maintaining what. As the company continued to grow, it became clear that the ETL would be a primary bottleneck to scale.
Nubank concluded that there was an urgent need to split up their monolithic ETL repository, amassing over 6 million lines of code, into smaller, more flexible sub-modules.
Nubank’s code migration was filled with the monotonous, repetitive work that engineers dread. Moving each data class implementation from one architecture to another while tracing imports correctly, performing multiple delicate refactoring steps, and accounting for any number of edge cases was highly tedious, even to do just once or twice. At Nubank’s scale, however, the total migration scope involved more than 1,000 engineers moving ~100,000 data class implementations over an expected timeline of 18 months.
In a world where engineering resources are scarce, such large-scale migrations and modernizations become massively expensive, time-consuming projects that distract from any engineering team’s core mission: building better products for customers. Unfortunately, this is the reality for many of the world’s largest organizations.
The Decision: an army of Devins to tackle subtasks in parallel
At project outset in 2023, Nubank had no choice but to rely on their engineers to perform code changes manually. Migrating one data class was a highly discretionary task, with multiple variations, edge cases, and ad hoc decision-making — far too complex to be scriptable, but high-volume enough to be a significant manual effort.
Within weeks of Devin’s launch, Nubank identified a clear opportunity to accelerate their refactor at a fraction of the engineering hours. Migration or large refactoring tasks are often fantastic projects for Devin: after investing a small, fixed cost to teach Devin how to approach sub-tasks, Devin can go and complete the migration autonomously. A human is kept in the loop just to manage the project and approve Devin’s changes.
The Solution: Custom ETL Migration Devin
A task of this magnitude, with the vast number of variations that it had, was a ripe opportunity for fine-tuning. The Nubank team helped to collect examples of previous migrations their engineers had done manually, some of which were fed to Devin for fine-tuning. The rest were used to create a benchmark evaluation set. Against this evaluation set, we observed a doubling of Devin’s task completion scores after fine-tuning, as well as a 4x improvement in task speed. Roughly 40 minutes per sub-task dropped to 10, which made the whole migration start to look much cheaper and less time-consuming, allowing the company to devote more energy to new business and new value creation instead.
Devin contributed to its own speed improvements by building itself classical tools and scripts it would later use on the most common, mechanical components of the migration. For instance, detecting the country extension of a data class (either ‘br’, ‘co’, or ‘mx’) based on its file path was a few-step process for each sub-task. Devin’s script automatically turned this into a single step executable — improvements from which added up immensely across all tens of thousands of sub-tasks.
There is also a compounding advantage on Devin’s learning. In the first weeks, it was common to see outstanding errors to fix, or small things Devin wasn’t sure how to solve. But as Devin saw more examples and gained familiarity with the task, it started to avoid rabbit holes more often and find faster solutions to previously-seen errors and edge cases. Much like a human engineer, we observed obvious speed and reliability improvements with every day Devin worked on the migration.
“Devin provided an easy way to reduce the number of engineering hours for the migration, in a way that was more stable and less prone to human error. Rather than engineers having to work across several files and complete an entire migration task 100%, they could just review Devin’s changes, make minor adjustments, then merge their PR”
Jose Carlos Castro, Senior Product Manager
How AngelList Completed a Redshift-to-Snowflake Migration 5.2x Faster with Devin
About the company
AngelList is one of the largest fund-administration platforms in venture capital, with $171B in assets on platform across 25,000 funds and syndicates.
Overview
By late 2025, AngelList had grown into one of the largest fund-administration platforms in venture capital, with $171B in assets on platform across 25,000 funds and syndicates. The Redshift-backed analytics stack that had powered that growth was now hitting concurrency limits, with queries queuing and timing out under load. As a result, AngelList’s data team committed to completing a Redshift-to-Snowflake migration by the end of Q1 2026.
By February 2026, AngelList had already migrated the data layer, over 2000 dbt models, to Snowflake. But the hardest part still lay ahead: migrating the BI layer. The data team needed to retarget, rewrite, and validate 14,000 Metabase cards (the charts and metrics powering LP reports and fund performance dashboards) across 40+ collections, most of which used Redshift-specific SQL or Metabase’s proprietary query language.
Beau Rothrock, a data engineer who’d joined AngelList just two months earlier, took ownership of the Metabase cutover — the final phase of the migration.
“I remember when I started. There was just kind of a brief moment of terror about how that was actually going to happen. I knew I couldn’t do this all by myself.”
Beau Rothrock, Data Engineer at AngelList
Without Devin, the Metabase migration was trending six months late, toward August or September, and would have required three or four additional engineers. With Devin, AngelList cut over to Snowflake on March 23, 2026 — 5.2× faster than the team estimated without Devin.
Shifting From Using Devin as a Tool to a Teammate
Before writing any code, Thibaut, an engineering lead at AngelList, suggested Beau scope the problem with Devin first. Beau pointed Devin at all 40 top-level Metabase collections and asked it to create a project spec.
What came back surprised him. Devin worked across all of AngelList’s repositories simultaneously, tracing which dbt models produced which tables and which tables fed which Metabase queries. In an IDE, reasoning across a dozen codebases would mean checking out every repo locally and constantly switching workspaces. Devin held all of them in scope at once.
“It really was much more like having a remote coworker rather than a sidebar in my IDE. Because Devin could see through multiple repositories the same way I could, it had better context on how to respond to my questions.”
Beau Rothrock, Data Engineer at AngelList
That changed how Beau approached the project. He had been planning to build a single monolithic tool to process cards sequentially. When he ran the approach by Devin, Devin pushed back: if the tool failed on casing, dialect, and data issues all in the same pipeline, every failure would block the entire run and require Beau to manually diagnose what went wrong.
Devin proposed a different architecture — a suite of composable tools, each handling one step of the migration. And because each tool operated on a single Metabase collection, the work could be partitioned across multiple agents running in parallel.
“Devin actually is the one who suggested an improved approach to this migration process. And I realized I had a really good partner here.”
Beau Rothrock, Data Engineer at AngelList
Together, they built five tools:
- A CLI admin tool for exploring Metabase collections and mapping the scope of the migration.
- A cloning tool for duplicating cards and retargeting them to Snowflake.
- A name-mapping tool for casing inconsistencies between warehouses — Redshift lowercases all unquoted identifiers; Snowflake uppercases them.
- A fixing tool for the long tail of SQL dialect differences between Redshift and Snowflake.
- A verification tool that sampled both warehouses and produced data reconciliation reports.
Twenty Agents Running the Migration in Parallel
With the tooling ready, Beau launched the migration at scale. At peak, 20 Devin agents ran in parallel — each picking up a Metabase collection, cloning its cards to Snowflake, resolving dialect issues, and validating the results against Redshift.
Early runs exposed a bottleneck. To resolve casing differences between Redshift and Snowflake, Devin needed to map each Metabase card back to the dbt model that produced its underlying table. Rather than computing this mapping once up front, Devin was re-deriving it for every card — walking the full dbt dependency graph from scratch each time.
While this approach worked, it was not fast enough. Beau recognized that dbt natively generates a complete dependency graph of every model relationship in the project. He had Devin precompute it into a lookup table it could reference directly, instead of re-tracing the graph for each card.
The full manifest was too large for Devin to hold in a single context window. Devin proposed splitting it into two tiers: a compact top-level graph mapping every table to its upstream models, and deeper subgraphs for the staging and marts layers that loaded only on demand. Lineage tracing then collapsed from a full graph walk to a direct lookup — fast enough that twenty parallel agents could migrate all 14,000 cards in just three weeks.
A Year of Work Delivered in Four Months
After cutover, AngelList decommissioned Redshift. The data layer for over 25,000 funds now runs on a modernized infrastructure built to scale. LP reports, fund performance dashboards, and compliance pipelines all run on Snowflake.
For Beau, four months into the job, this was the kind of impact most engineers spend years chasing. He had taken on the most difficult piece of a company-wide migration in his first quarter and attached his name to something hundreds of people across AngelList use every day.
“Being able to have a really big impact in the company, especially in my first three months of employment — that’s a really big deal. We’ve now empowered people to use Devin in ways that they weren’t empowered before. It’s just really great to think about that I had something to do with that.”
Beau Rothrock, Data Engineer at AngelList