Morph by Modelcode (modelcode.ai) runs AI code migration with human-reviewable changes: it delivers the work in milestones, each one a working increment that reaches your engineers as pull requests in your own repositories, along with the plan it implements, the results of its tests and quality gates, and the team rules it was written under. An automated review flags issues before anyone opens the diff, and every merge is a decision made by someone on your team.
What makes an AI-generated change human-reviewable?
A change is human-reviewable when one engineer can understand it, check it and decide on it in a single review, without having to work out alone why it exists. For an AI migration, that takes four things, delivered with every change:
Size. A scope one person can read in one sitting, with a clear edge: one increment of an approved plan, not a module rewritten in one pass.
Proof. Evidence that the new code behaves like the code it replaces, produced before the review starts: builds, tests and quality gates that already ran, with results the reviewer can open.
Context. The plan item the change implements, the files it was expected to touch, and the design decisions and risks behind it, so the reviewer can judge intent and not just syntax.
Rules. The team's own standards, written down and applied to every change, so conventions are settled once instead of argued again in each pull request.
A change that lacks one of the four can still be merged. It just cannot really be reviewed, only trusted.
Why review capacity is the real limit
AI writes migration code faster than people can read it, which makes the reviewer the bottleneck. A process that ignores this ends with very large pull requests approved on faith.
Google's account of its own AI-assisted migrations, published on its research blog in July 2024, shows where the human stays in the loop. In a migration of Google Ads ID types from 32-bit to 64-bit integers, 80% of the code modifications in the changes that landed were AI-authored, and the engineers doing the work estimated that the total time spent fell by about 50%. Yet an engineer still checked the generated changes and fixed the files where the model had failed, the changes were then sharded and sent to reviewers who own the affected part of the codebase, and the engineers still had to spend time on analysis and on review. The model wrote most of the code; people decided what landed. Tooling for AI migration has to make that decision quick and well informed.
How Morph packages a milestone for review
Morph splits a migration into milestones, and every milestone follows the same path to a merge:
The plan comes first. Before any code is generated, a reviewer reads the Milestone Spec in Project Knowledge: its scope, the relevant files, the design decisions and the risks the agent will follow. It can be refined through Knowledge chat, and the work starts only once someone approves it. Modelcode's documentation calls this the cheapest place to fix a problem, well before it turns into generated code.
A machine review comes before the human one. When the agent is done, the Morph Platform runs an automated milestone review, at every validation level, and raises issues against the migrated code. Failed functional tests and failing acceptance criteria join the same list, so a failed check becomes an item to triage rather than a hidden stop. Issues can be filtered by severity or status, sized issues carry an effort estimate from XS to XL, and each one can be assigned to a teammate, who is notified by email.
Proof travels with the change. Depending on the project's validation level, Morph runs the migrated application through its full lifecycle, and at the High level it first runs the original application to capture a baseline, then checks the migrated one against it. From the second milestone on, the functional tests accumulated in earlier milestones run again as a regression suite. Custom acceptance criteria put each gated metric, such as lint warnings or line coverage, next to its baseline measured on the original code. Morph ships the integration tests it used to verify each milestone along with the code.
Triage happens in one place. In the Code Review drawer, reviewers work through the issues with a chat panel: they can ask Morph to fix one, log an issue the review missed, add review criteria, or re-run the review. When the chat changes code, it asks before it commits and again before it pushes to the pull request. Several teammates can review the same milestone at once, each in a separate review session.
The pull request stays an ordinary pull request. Each milestone ends in pull requests in GitHub, GitLab or Azure DevOps, reviewed with the team's usual process: comments, requested changes, fixup commits, required approvals. A reviewer who wants to know why a line changed can ask in the thread: PR Agent reads the pull request, the milestone and project specs, the project wiki and the diff before it replies, and it pushes a commit only when someone explicitly asks for a change.
Corrections carry forward. A merge is also a lesson: once a milestone lands, Milestone Learning studies what the reviewers changed or asked for (their comments, the final diff, the commits they pushed on top) and writes the result back as wiki updates and draft rules. A draft rule applies only after someone on the team publishes it; from then on it is part of the context of every task the agent runs, so a reviewer flags a given mistake once rather than in every pull request.
Two details matter for reviewers on long migrations. If a sibling milestone merges first and a branch needs a rebase, a Rebase Report shows what came in and how it was reconciled, since a rebase is the one moment when code that was already reviewed can change. And at the end, the whole migration arrives as one final pull request per repository, merged from the Git provider's own page.
How other approaches handle review
Recipe tools make a different trade. OpenRewrite by Moderne packages each transformation as a recipe, and Moderne's commercial platform runs that catalog across large codebases and many repositories. There, the recipe itself is the reviewable unit: a written transformation a reviewer can read before it runs anywhere, which suits uniform, mechanical changes. Google's post draws the same line from the other side: its static tooling works for changes that are uniform in structure, and AI was brought in for the ones that tooling struggled with, such as interfaces whose usages span several components.
Microsoft's GitHub Copilot modernization agent, run through its Modernize CLI, also starts from a plan that can be reviewed, refined and approved, broken into ordered tasks with success criteria, and it creates branches and commits with a traceable change history. Its documented scenarios center on upgrades, Spring Boot migrations, containerization and Azure service integrations.
Coding agents used on their own also produce pull requests. How small, tested and explained those pull requests are depends on how each team scopes the work it hands over. Whatever the shortlist, the useful test is the same: is reviewability built into the tool, or left to the discipline of whoever drives it?
Questions to ask before you trust a tool's pull requests
Can one reviewer read each pull request in a sitting, or does the migration arrive as a single large drop?
Does each change come with test and quality-gate results measured against the original application?
Can the reviewer see the plan item behind a change, and ask why a line changed from inside the pull request?
Are team standards written down as rules the tool applies to every change?
When a reviewer corrects something once, does the correction carry over to the next change?
Can anything reach the main branch without a person approving it?
FAQ
How large should an AI migration pull request be?
Small enough for the people who own that code to review it in one sitting. Morph scopes work by milestone, each a working increment of the approved plan, and the milestones that depend on it stay locked until its pull requests are merged or closed.
Does an automated review replace the human one?
No. Morph's automated milestone review runs before your engineers look at the code, so they start from a list of issues instead of a raw diff. Approving and merging stay with them.
Can a reviewer ask why the AI changed something?
Yes, in the pull request itself. Comment on the line, and PR Agent answers in the thread using the specs, the wiki and the diff. It changes code only when explicitly asked to.
What happens when a reviewer rejects a change?
Push fixes to the branch, ask Code Review chat or PR Agent for a fix, or move larger rework into an ad hoc milestone with its own plan, validation and review. Closing the pull request without merging does not trigger a new attempt: Morph treats the milestone as completed.
For the record these reviews leave behind once the migration is done, read Auditable AI Code Migration: What an Audit Trail Should Contain on this blog.
More on Morph: https://modelcode.ai/?utm_source=substack&utm_medium=blog&utm_campaign=reviewable_changes