Your migration backlog, turned into pull requests that already pass CI.

CodeFlow maps your repositories into a syntax-tree graph and uses Claude agents to plan and make every change. Framework upgrades, dependency swaps and tech-debt cleanups, delivered in batches your team can review.

Get early access Scan your dependencies

Built on Claude, using tool use, adaptive thinking and prompt caching

northwind / billing-worker

Sample data

Batch 3 of 7, 61 files, 214 call sites

Migrate billing from moment to date-fns

Index
Plan
Rewrite
Verify
Review

Agent activity

Indexer Parsed 2,318 files into the syntax graph
Planner find_references({ symbol: "moment" }) 214 call sites in 61 files
Planner read_module({ path: "billing/" }) 3 patterns: format strings (171), add and subtract (38), locale (5)
Rewriter propose_edit × 213 Applied to the syntax tree, all files parse
Planner read_node({ file: "billing/proration.ts", line: 88 }) This call site relies on moment mutating start. Two valid rewrites, so it needs your decision.
Rewriter propose_edit({ file: "billing/proration.ts", line: 88 }) Applied your decision
Verifier run_build() Build passed in 38s
Verifier run_tests() 1,904 unit tests passed
Verifier run_lint() Lint and type check passed
Reviewer open_pull_request() Opened #482 with 2 notes for reviewers

Needs your decision: billing/proration.ts:88

moment's add() changes the original date. date-fns returns a new one, so the result has to be assigned. Both options below behave the same; they differ in style.

- const start = moment(invoice.periodStart);
- start.add(proratedDays, "days");
- return start.format("YYYY-MM-DD");

Open #482 Migrate billing from moment to date-fns (batch 3 of 7)

Ready for review by billing-platform. Your decision is recorded in the description: reassign start at billing/proration.ts:88.

A working demo with sample data. When the agents stop for a decision, pick one and watch the pull request update.

62%

of developers name technical debt as their biggest frustration at work, about twice the next answer. Stack Overflow Developer Survey, 2024

The changes everyone agrees on, and nobody has time to make

A framework upgrade touches hundreds of files owned by a dozen teams. It is tedious, risky by hand, and it rarely wins against roadmap work. So it waits, and every release makes it bigger.

Framework and runtime upgrades

Version jumps with breaking API changes spread across every service.

Spring Boot 2 to 3
Java 11 to 21
Vue 2 to 3
Django to 5.2 LTS

Dependency migrations

Replacing a library that is deprecated, unmaintained or flagged by security.

moment to date-fns
Log4j 1 to Logback
Enzyme to Testing Library
Retiring an internal SDK

Technical debt

Cleanups that are easy to describe and slow to finish by hand.

Removing dead flags and code paths
Replacing deprecated call sites
Consistent error handling
Adding types to untyped modules

Claude plans every change. Your build decides what ships.

The syntax graph decides where a change applies. Claude decides how to make it, including the cases that need judgment. Your build and tests decide whether it ships. Nothing reaches a pull request until all three agree.

Step 1

Your repositories

Read access to the code in scope
Step 2

Syntax graph

Every symbol, reference, type and build target
Step 3

Claude agents

Plan, rewrite and explain each change
Step 4

Sandboxed build

Compile and run your tests on every batch
Step 5

Pull request

Small, reviewable, with notes on every decision

When the build or tests fail, the compiler output goes back to Claude with the edit that caused it, and the batch is retried or held for review.

Tool use over the syntax graph

Claude never greps or guesses. It calls typed tools such as find_references, read_node and propose_edit, with strict schemas, so every edit targets a real node in the graph.

Adaptive thinking for judgment calls

Mutable dates, implicit locales, security config that has to be restructured: Claude reasons through the cases a codemod rule cannot express, and explains the choice it made.

Prompt caching for repository context

The migration playbook, tool definitions and module context are cached once per run, so the thousandth call site costs a fraction of the first.

Message Batches for bulk work

Single-shot jobs that need no tools, such as classifying thousands of call sites by pattern and drafting pull request summaries, run through the Message Batches API at half the per-token price.

1M-token context for module-level reasoning

When a change crosses files, Claude sees the whole module and its callers at once instead of a window of lines.

Structured output for the pull request

Every batch ends in a schema-checked report: what changed, which tests ran, and each judgment call with its file and line.

See the agent architecture and code

One migration, many small merges

CodeFlow never lands a migration as one giant diff. It splits the work by module and code owner, so main moves forward in steps your team can review in one sitting.

Step 1: Connect

You grant read access to the repositories in scope and permission to open pull requests. CodeFlow never pushes to protected branches.
Step 2: Index

Each repository is parsed into a graph of syntax trees, symbols, types, imports and build targets, so every use of an API is found.
Step 3: Plan

Claude works out the right edit for each call site through tools that read the graph. Cases that need a human decision are flagged, not guessed.
Step 4: Verify

Every batch is built and tested in a sandbox. Failures go back to Claude with the compiler output until the batch passes or is held.
Step 5: Deliver

Changes arrive as small pull requests grouped by module and owner. Your CI runs, your reviewers decide.

Syntax trees for precision. Agents for judgment.

Codemod and recipe tools are precise, but only for the cases someone wrote a rule for. Coding assistants and agents understand intent, but edit text and lose consistency across thousands of files. CodeFlow uses the syntax graph to find every place a change applies and to keep edits structural, and uses agents for the cases that need reading rather than matching. Where a deterministic recipe already exists for your migration, we use it.

Edits the code structure, not the text

CodeFlow: Yes. Works on the syntax tree

Search and replace scripts:: No. Matches strings
Codemod and recipe tools:: Yes. Works on the syntax tree
AI coding assistants and agents:: No. Generates text

Handles changes that need judgment

CodeFlow: Yes. Agents decide, graph constrains

Search and replace scripts:: No. Only exact patterns
Codemod and recipe tools:: Partly. Only cases a rule was written for
AI coding assistants and agents:: Yes. Reads intent

Covers thousands of files consistently

CodeFlow: Yes. Whole repository graph

Search and replace scripts:: Partly. Fast, but blind to meaning
Codemod and recipe tools:: Yes. Once the rules exist
AI coding assistants and agents:: Partly. Session by session, with drift

Compiled and tested before a person sees it

CodeFlow: Yes. Build and tests run on every batch

Search and replace scripts:: No. Up to you
Codemod and recipe tools:: Partly. Some tools run tests
AI coding assistants and agents:: Partly. Some agents run tests

Same input, same output every time

CodeFlow: Partly. Agent choices vary; verification and review catch the difference

Search and replace scripts:: Yes. Fully deterministic
Codemod and recipe tools:: Yes. Fully deterministic
AI coding assistants and agents:: No. Varies run to run

How CodeFlow compares with other ways of making large code changes
Capability	Search and replace scripts	Codemod and recipe tools	AI coding assistants and agents	CodeFlow
Edits the code structure, not the text	No. Matches strings	Yes. Works on the syntax tree	No. Generates text	Yes. Works on the syntax tree
Handles changes that need judgment	No. Only exact patterns	Partly. Only cases a rule was written for	Yes. Reads intent	Yes. Agents decide, graph constrains
Covers thousands of files consistently	Partly. Fast, but blind to meaning	Yes. Once the rules exist	Partly. Session by session, with drift	Yes. Whole repository graph
Compiled and tested before a person sees it	No. Up to you	Partly. Some tools run tests	Partly. Some agents run tests	Yes. Build and tests run on every batch
Same input, same output every time	Yes. Fully deterministic	Yes. Fully deterministic	No. Varies run to run	Partly. Agent choices vary; verification and review catch the difference

What would CodeFlow change in your repo?

Paste a package.json, requirements.txt, pom.xml or build.gradle. The scanner lists the migrations that apply, what changes in the code, and which cases would come to you for a decision. It runs in your browser; nothing is uploaded.

Open the migration scanner

3 migrations found in your package.json

moment to date-fns Some judgment calls
Enzyme to React Testing Library Significant judgment
TSLint to ESLint with typescript-eslint Mostly mechanical

What lands in your repository

Sized for one review sitting: Work is batched by module and code owner, so each pull request lands with the team that knows that code.
Judgment calls are written down: Anywhere behavior could change, the description names the line, explains the choice made and asks for confirmation.
Your process stays in charge: CI, code owners and branch protection apply exactly as they do for a pull request from a colleague.

Open codeflow/billing-date-fns-3 into main

Migrate billing from moment to date-fns (batch 3 of 7)

Summary

Replaces moment with date-fns across the billing module: 214 call sites in 61 files. Format strings are converted to date-fns tokens. No public interfaces change.

Verification

Build passed
1,904 unit tests passed
Lint and type check passed

Needs your confirmation (2)

billing/proration.ts:88 moment dates are mutable and this code relied on .add() changing the original. The rewrite keeps that behavior by reassigning start.
billing/locale.ts:14 A global moment locale was set here. date-fns takes the locale per call, so enGB is now passed explicitly in 9 places.

Reviewers requested from CODEOWNERS: billing-platform

Become a design partner

We are working with a small group of engineering teams on real migrations. You bring one change you already need; we run CodeFlow on it with you and shape the product around what your team needs.