Morph by Modelcode (modelcode.ai) works as an automated enterprise code refactoring platform built on one split: the platform does the repetitive work of a refactor, from mapping every affected file to opening pull requests, and for every change it brings evidence that behavior held, that nothing was missed, and that the result matches the plan your engineers approved.
That split is a useful test for any tool in this category. An enterprise refactor is rarely hard because of a single edit. It is hard because the same change has to land in hundreds of places, across repositories owned by different teams, while those teams keep shipping, and every landing has to leave the system working. Automation handles the volume. Proof is what makes that volume safe to merge.
What should an automated refactoring platform automate?
Anything a careful engineer would do the same way every time belongs to the platform. In an enterprise refactor, that covers six jobs:
Finding every affected place. Call sites, implementations, configuration, build files and tests, across all the repositories in scope, including the ones nobody remembers owning.
Making the edits. The mechanical part of the change, applied at the thousandth site with the same care as at the first.
Building and testing after each step. A refactor that only compiles at the very end hides which step broke what.
Cutting the work into pull requests people can review. Size and order are part of the job: a change split by module or by milestone can be read, while one diff across two hundred repositories cannot.
Keeping up with the mainline. Teams keep merging while a long refactor runs, so the platform has to bring their changes in and adjust the work still ahead.
Stopping when it is blocked. A missing credential or an unreachable service should pause the run with a clear report, never end it with a green status.
What should it prove for every change?
Automation produces volume, and volume is exactly what a review team cannot read line by line. So the platform owes evidence with each change, in a form a reviewer can check quickly. Five proofs cover it:
Behavior is unchanged. A refactor changes structure and leaves behavior alone; that is the definition. The evidence is the old code and the new code producing the same results for the same inputs, not a build that passes.
The change is complete. Every place that needed the change got it, and nothing still depends on the old shape. A missed caller is the classic refactoring bug, and it does not always fail the build.
The scope held. The diff touches what the plan said it would touch, and nothing more. Edits nobody asked for are the hardest to review, because nobody is looking for them.
Earlier steps still hold. Step twelve can quietly break what step three proved. Running the earlier checks again at each new step is how you find out.
Every result is reported as it happened. Checks that were skipped show up as skipped, and blocked work as blocked. A platform that rounds "could not run" up to "passed" turns its own evidence into noise.
Where does the proof come from?
Refactoring platforms come in two families, and they earn trust in different ways.
Rule-based engines prove the transformation once, then reuse it. OpenRewrite, an open-source automated refactoring ecosystem, changes code by editing a lossless semantic tree through recipes, and its documentation asks recipe authors to test that a recipe makes the expected changes and no unnecessary ones. Moderne, the commercial platform around OpenRewrite, runs those recipes over whole estates of repositories, with mass commits and impact analysis at scale. Once a recipe is trusted, every repository it runs on inherits that trust. That is why rule-based engines are so strong for repeatable changes such as framework upgrades, API replacements and security fixes.
AI-driven platforms write the change for each place it lands. That lets them take on changes no single rule can express, such as splitting a module or extracting a service. AWS Transform custom, for example, offers pre-built agentic transformations and lets a developer define new ones by chatting with the agent and supplying documentation and code samples; its scope runs from version upgrades to architecture decompositions. When a model writes the change, the evidence has to travel with each result: tests, a comparison with the original system, a review, or all three. The question to put to every vendor in this family is which of those it produces, and when.
So the real choice behind "automated refactoring platform" is about the change. If it is repeatable and a rule can express it, a tested recipe carries most of the proof before the first repository is touched. If it needs design, the platform has to produce evidence for each result, and its verification matters more than its speed.
What should stay with your engineers?
Automation should not absorb the decisions that make a refactor worth doing. Three stay with people: the target design, meaning what the code should look like afterwards and why; the approval of the plan, before the first edit; and the merge of every pull request. Team conventions sit in between. Engineers write them down once as rules, and the platform applies them at every step instead of relying on reviewers to catch the same issue again.
How Morph by Modelcode splits the work
Morph handles refactoring without a language change as a transformation type of its own: Modelcode's documentation names service extraction, consolidation and restructuring, codebase refactoring without full language migration, and dependency standardization, next to monolith decomposition. Every project follows the same sequence:
A plan your team approves first. Morph first studies the repositories, then drafts a Project Spec, the document that defines what done means. No code is generated until a person approves it, and each milestone carries its own spec, listing its scope, the files involved, design decisions and risks, which is approved before the work starts.
Milestones instead of one giant diff. Inside a milestone, the agent plans its tasks, works through them one at a time and commits after each task, on a branch of its own.
A review of the whole codebase, not just the diff. Before your team sees a pull request, Morph checks the milestone against the approved plan and traces what it touches beyond the edited files: contracts, callers, dependencies and architectural boundaries. Broken contracts and missed call sites go back to the milestone before any human review.
Behavior checked against the original system. At the highest validation level, Morph runs the original application and the refactored one through the same journeys and compares outputs, state changes, integrations and side effects. Any mismatch goes back to the milestone as an issue to resolve. Starting with milestone two, every earlier milestone's functional tests are rerun as a regression suite. Morph ships the integration tests it used to verify each milestone along with the code.
A mainline that keeps moving. Between milestones, your team can trigger an upstream sync that brings in what was merged in the meantime, as a milestone of its own with review and functional testing; it rebases the work in progress and adjusts the milestones still ahead.
Stops that are reported as stops. When a run is stuck on something outside its reach, a package registry it cannot access or a secret that was never provided, it pauses and asks for help instead of calling the work done. A check that could not run is reported as blocked, never as passed.
Your merge, and your rules. Your mainline only changes when someone on your team approves the merge. After each merge, Morph studies what your reviewers changed and turns the lessons into wiki updates and rules for the next milestone; new rules stay in draft until you publish them.
This process is built for changes that need design and proof for each result. For a repeatable change that one recipe expresses, such as replacing a deprecated API across hundreds of repositories, a recipe engine gets there sooner, and Morph's approvals and verification add steps that job does not need.
A note on the name: Morph here means Morph by Modelcode, the modernization platform at modelcode.ai. It is a different product, from a different company, than the Morph inference service at morphllm.com.
Questions to ask in an evaluation
For a repeatable change, can the transformation be written once, tested once and reused across every repository?
For a change that needs design, what evidence arrives with each result: tests, a comparison with the original system, a review, or only a passing build?
How does the platform find every place a change must land, including other repositories, and how does it show you what it could not reach?
How does it divide a large refactor into pull requests your reviewers can actually read?
What happens when your teams merge into the mainline halfway through?
When a check cannot run, what does the report say?
Who approves the plan, and who merges? Can the platform merge anything on its own?
FAQ
What is an automated enterprise code refactoring platform?
Software that applies a planned change to the structure of a large codebase, across many files and repositories, without changing what the code does, and hands the result to engineers as pull requests they can review. Recipe engines apply tested rules; AI-driven platforms write the change for each place it lands and verify the results.
Can automated refactoring be trusted on code with few tests?
Only if the evidence comes from somewhere else. A recipe engine relies on the tests written for the recipe itself. A platform that writes new code needs a reference to compare against: at its highest validation level, Morph uses the original application as that reference, running both versions through the same journeys and comparing what they do.
How is Morph different from OpenRewrite or Moderne?
They are built for different jobs. OpenRewrite and Moderne apply tested recipes, which suits repeatable changes across many repositories. Morph plans and writes changes that need design, such as extracting a service or restructuring modules, and verifies each milestone, comparing it with the original application at the highest validation level. A team with both kinds of work can use both.
Does a refactoring platform change code outside the plan?
It should not. Each Morph milestone has a scope a person approved, and the automated review evaluates the change against that plan. 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.
For the reviewer's side of each pull request, read AI Code Migration With Human-Reviewable Changes: What Each Change Should Give a Reviewer; for code that agents wrote in the first place, read Refactoring AI-Written Code: Plan, Review and Prove Every Change.
More on Morph: https://modelcode.ai/?utm_source=substack&utm_medium=blog&utm_campaign=refactoring_platform