How DANA Indonesia ran a massive code migration with Cursor agents inside Notion

Design system migration has the right shape for agent work. The backlog is massive, but the work is repetitive and clearly defined: update a component, compare it with the new standard, document the result, and prepare it for review. Doing that sequence manually across 2,970 components would consume engineering time without requiring a new decision at every step.

For Randi Waranugraha, VP of Engineering, and DANA’s engineering team, the question was not whether Cursor could rewrite one component. It was how to repeat the process at scale without losing consistency, context, or review. In Notion, the team turns the backlog into batches of tasks, gives each agent focused instructions and access, and moves the work from code generation to visual audit to pull request. Each stage produces a concrete output for the next agent and leaves a visible record for the human reviewer.

Years before this migration, DANA moved its engineering work out of Jira and Confluence and consolidated task management and its knowledge center in Notion. When Notion launched External Agent capabilities, Randi knew bringing Cursor agents into the workspace was a natural next step. The tasks, documentation, agent instructions, and review trail could all stay beside the engineering work the team already managed.

The agents work alongside DANA’s existing engineering system, not inside a separate AI sandbox. Notion provides the shared context, coordination, and visibility layer. Cursor provides the coding execution environment.

Because the agents work in the team’s shared workspace, the workflow is collaborative by default. Engineers can see each run, review outputs on the same task, and step in without reconstructing context from a private AI chat. The work belongs to the team, not only to the person who started the agent.

DANA organizes components into batches, then moves each batch through a multi-agent pipeline:

1. The Migration Agent generates the code. It picks up a task batch, follows the migration instructions, writes the replacement code, and creates a branch.

2. The Audit Agent screenshots and annotates the work. It opens the same prepared virtual machine, creates a new audit page, and produces annotated screenshots that check details such as text, labels, and colors. Some color differences are expected because the component is moving to the new design system.

3. The PR Agent prepares the work for review. Once code generation and audit are complete, a third agent creates the pull request.

4. The Learning Agent improves the next run. It periodically synthesizes previous runs and turns those lessons into better instructions for the agents that follow.

Together, the agents have processed 575 components to date, completing 180 runs per week.

The repository contains DANA’s full Android app, so starting every environment from scratch would make the pipeline impractical. The team pre-builds the environment so each virtual machine starts warm and the agents can get to the migration work faster. That setup reduces average environment startup time by 47% (from 17 to 9 minutes).

Running many agents created a second problem: knowing which jobs were active and which had finished. DANA built a worker that listens for agent start and end events, then sends them to a registry agent. That gives the team one place to observe concurrent runs rather than opening tasks one by one to check their status.

The current pipeline deliberately stops at agent audit. During pull request review, the page owner still examines the code and confirms that the screenshot audit is correct. The agent moves the migration to a reviewable state, but a person decides whether the result is ready to merge.

A batch now moves from assignment to a review-ready PR in 52 minutes, compared with a previous average of 24 hours, without shipping any AI slop.