So You Want to Refactor Code with an Agentic Developer

Refactors are one of those engineering tasks everyone agrees are important, but few teams have time to prioritize.

The reasons are familiar. Refactors are repetitive. They require deep context. They often span hundreds of files. They create overhead between engineers. And if you are not careful, they can slow down product delivery for weeks or even months.

That raised an interesting question:

“What if refactoring work could scale the same way infrastructure scales?”

Refactoring Modals

We were running into exactly that problem during a fairly large design shift in our mobile app. Instead of an old and inconsistent modal implementation, we were standardizing on a new modal entirely. That meant migrating more than 50+ existing modals to a single consistent paradigm.

The goal was simple in theory: a singular way to define and present modals across the app. However, in practice it meant large, repetitive changes over a big surface area that would have taken significant engineering time if done manually. 

So, we wrote a Claude Code skill.

This skill was designed specifically to migrate old modals to the new modal paradigm. It understood:

• The new modal paradigm and required structure
• How to map old implementations into new modals
• Edge cases where modals had custom logic for Android

At that point, something interesting started happening organically. Luis, one of our Directors of Engineering, began assigning Linear tickets directly to Nitro for these modal migrations. Nitro is an agentic developer in our company’s cloud that’s integrated with all of our tools. 

Luis migrating Modals with Nitro

Instead of treating Nitro like a second class tool, teams started treating it like a real engineer:

• Nitro picks up the ticket
• Nitro performs the migration for a given modal
• Engineers review and test the changes

The migration continues to progress without consuming ongoing engineering bandwidth.

That workflow fundamentally changed the cost of the refactor. The bottleneck stopped being “who has time to migrate 50+ modals” and became “how quickly can we perform code reviews and test the code.”

Turning Refactors into Liquid Glass

One area where this approach became especially effective was our work introducing liquid glass to the mobile app.

We were working on a new visual liquid glass overhaul. After a pattern was found, the implementation itself was not particularly difficult, but applying it consistently across hundreds of screens required a lot of repetitive work. Historically, that type of migration would involve:

• Writing implementation docs
• Creating examples
• Aligning engineers across teams
• Reviewing inconsistencies manually

Instead, we wrote a Claude Code skill specifically for adding liquid glass to mobile screens. Then provided Claude with guidelines for Nitro to follow.

The skill had:

• The component patterns
• Common edge cases
• Existing conventions in our React Native codebase

Once the skill existed, Nitro could apply the code repeatedly and consistently.

Now, instead of explaining the pattern to every engineer, we can assign the work to Nitro through Linear. Nitro generates the implementation, engineers review and test the output, and the migration moves forward with way less overhead.

The important part is not just speed. It is that the organizational knowledge becomes reusable. Now anyone at the organization can apply liquid glass to a screen without needing historical context.

One unexpected benefit of this workflow is documentation quality. Traditionally, documentation competes with feature work for engineering time. During refactors, docs are often incomplete, outdated, or skipped entirely because the team is focused on execution. But when the migration logic itself lives inside a Claude Code skill, the documentation effectively becomes embedded into the system.

The skill contains:

• The reasoning behind the migration
• The expected implementation patterns
• The examples engineers need

Instead of documentation drifting away from implementation over time, the implementation and documentation evolve together. That creates a compounding effect:

• Refactors become repeatable
• Knowledge becomes discoverable
• Teams become less dependent on institutional knowledge
• Large migrations stop feeling like a burden

Agentic Development Changes the Engineering Work

Nitro does not replace engineers. If anything, it pushes engineers higher up “the stack” - it shifts them towards setup, review, and higher-value work. The valuable work is no longer manually updating the 50th modal implementation. The valuable work becomes:

• Designing better migration strategies
• Defining architectural patterns
• Writing high quality skills
• Reviewing complex edge cases
• Testing the implementation

The repetitive work becomes delegated. That matters because most engineering organizations are not constrained by ideas. They are constrained by migration costs, coordination overhead, and maintenance burden. Agentic systems can help reduce those costs when implemented effectively.

If you want to learn more about Nitro and how we built our autonomous background agent system, the Fullscript engineering team wrote about it here:

So We Built Our Own Agentic Developer…and then the CEO shipped a feature