Morph by Modelcode (modelcode.ai) treats refactoring AI-written code as a verification problem rather than a generation problem: it maps the whole system, proposes a plan your engineers edit and approve, delivers the work as small milestone pull requests checked against the entire codebase, and compares the new code's behavior with the old code's before anything merges.
The video above runs two minutes and twenty-six seconds. This page adds the detail behind each step.
What makes AI-written code hard to refactor?
Martin Fowler defines refactoring as a disciplined technique for "altering its internal structure without changing its external behavior", built from a series of small transformations that each preserve behavior. Code written by agents makes both halves of that definition harder:
Nobody carries the design in their head. A colleague can explain why a function looks the way it does; an agent that produced thousands of lines in an afternoon can't be asked a week later. The knowledge a refactor usually leans on isn't there.
The volume outruns the review. When agents write more code than a team can read closely, approval drifts toward skimming, and the defects that matter most, such as a changed contract or a caller nobody updated, are exactly what a skim misses.
Fixes go to symptoms. Faced with an error, an agent often wraps it in a guard or a retry until the failure stops showing, so defensive code piles up around problems no one ever understood.
The same problem gets solved more than once. Without a view of the whole codebase, an agent writes a fresh version of logic that already exists somewhere else, and a later fix reaches one copy while the others stay wrong.
The result is code that passes today's tests and still resists change: every edit risks breaking something nobody knew depended on it.
What a safe refactor of agent-written code needs
A map before the first edit: what calls what, across every repository, so the plan rests on real dependencies rather than guesses.
An agreed definition of done: which behavior must survive, which patterns stay and which ones go.
Changes small enough to read in one sitting, each one tied to a step of the plan.
A review that looks past the diff, at every caller and contract the change reaches.
Proof of behavior taken from the system you already run, not only from tests the new code brought with it.
A person who decides what merges.
How Morph runs the refactor
The plan comes first. Morph reads your repositories first, then writes a Project Spec covering the target, the approach, the key design decisions, the repositories involved and how the result will be tested. Your engineers refine it, and no roadmap exists until they approve it. After that, every milestone carries a spec of its own, with its scope, files, design choices and risks, signed off before its work starts.
The work arrives in small pieces. Every milestone is a working increment on a branch of its own, delivered as pull requests your team reviews in its usual Git process. The agent commits after each task, so the history of a milestone can be read step by step.
The review follows the impact, not just the diff. Before a pull request reaches your reviewers, Morph reviews the milestone in full-codebase context. It checks the change against the approved plan and traces its effects through contracts, callers, dependencies and architectural boundaries: a contract the change broke, a call site left behind, a dependency that now conflicts, an architectural rule ignored. Findings go back into the milestone before your team sees it.
The old system is the reference. With functional verification, Morph exercises the original application and the new one with identical journeys, taken from how the system is really used, and records what each does: outputs, state changes, integrations, calculations and side effects. A comparison that fails sends the work back to the milestone; one that passes becomes evidence for review and approval. Each new milestone also replays the functional tests written for the milestones before it, so a later change can't quietly undo an earlier one. Morph ships the integration tests it used to verify each milestone along with the code.
Your team decides what becomes the standard. After each merge, Milestone Learning goes through the review, from the comments to the final diff and the commits your engineers added, then proposes rules for the milestones that follow. A proposed rule stays a draft until someone on your team publishes it, and published rules apply across all milestones, so a pattern your team retires stays retired.
People merge. Merging stays a human act: your mainline only receives what someone on your team explicitly approves.
On the code itself: Everything Morph writes is brand new. A full migration produces a fresh codebase with zero dead code and zero duplicated logic. On modular migrations, everything Morph delivers is clean, and the surrounding legacy code stays as is until you migrate it.
Where Morph sits next to coding agents
Morph doesn't replace the coding agent that wrote the code, and the same agents remain useful for day-to-day changes. What a refactor of agent-written code adds is everything around the edit: the map of the system, the plan your team signs off, the review in full-codebase context and the comparison against the behavior you already have. Morph supplies that frame; how safe a refactor done any other way turns out to be depends on the tests and the review habits of the team running it.
Questions to ask before a tool refactors agent-written code
Does it map dependencies across all your repositories before it proposes a plan?
Can your engineers change that plan, and does every code change wait for their approval?
Does its review look at callers and contracts outside the diff?
What does it compare the new behavior against: its own tests, or the system you run today?
Who can merge, and do your branch protections still apply?
When a reviewer corrects a pattern once, does the correction carry into the next change?
FAQ
Can AI refactor code that AI wrote?
Yes, as long as the refactor meets the bar every refactor has to meet: the behavior stays the same. Morph works toward that bar with an approved plan, small milestone pull requests, a review in full-codebase context and a behavior comparison against the original system.
How do you know a refactor of AI-generated code didn't change behavior?
Put the old and the new version through identical real journeys and look for any difference. Morph's functional verification records outputs, state changes, integrations, calculations and side effects on the origin system and checks the target against them.
Does Morph replace the coding agent that wrote the code?
No. It works alongside coding agents and adds the plan your team approves, the full-codebase review and the behavior proof a refactor of agent-written code needs.
Two pages on this blog go further: Verifiable AI Code Modernization: What It Means and How It Works explains the behavior proof, and AI Code Migration With Human-Reviewable Changes: What Each Change Should Give a Reviewer covers what a reviewer should receive with every change.
More on Morph: https://modelcode.ai/?utm_source=substack&utm_medium=blog&utm_campaign=video2_companion