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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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

What changes when the agent works alone?

With an assistant in the editor, a developer accepts or rejects each suggestion, and that developer is the record: they saw every line before it existed. Autonomous modernization takes the person out of the middle. Between two human decisions, the agent plans tasks, edits files, builds, runs tests, retries and commits, sometimes for hours. An audit trail for that kind of work has to cover the stretch nobody watched, and it has to make the decisions at either end easy to find.

Autonomy moves review from every step to a few gates. The record is what gives those gates their value: an approval means little if nobody can later open what was approved, see what happened after it, and read the evidence that came back.

A checklist borrowed from security auditing

Security teams already have a vocabulary for this. NIST SP 800-53, Security and Privacy Controls for Information Systems and Organizations, includes a control called Content of Audit Records (AU-3). It asks that audit records establish six things: what type of event occurred, when and where it occurred, its source, its outcome, and the identity of the people or entities associated with it. For an autonomous agent, the six become:

• What: which milestone ran, how the agent broke it into tasks, and what each task changed.

• When: the time of each approval, run, pause and merge, so the order of decisions can be rebuilt later.

• Where: the environment the agent worked in, a vendor's sandbox or a machine inside your own network, and the branch it wrote to.

• Source: the instruction behind the work, meaning the approved plan item and the team rules in force when the agent ran.

• Outcome: the results of the tests and quality gates, including the checks that could not run at all.

• Identity: which actions the agent took and which a named person took, kept apart from each other.

AU-3 was written for information systems in general, and meeting it does not make a migration tool compliant with any framework. It is still a fair test of a vendor's record: if the record cannot answer one of the six questions about an autonomous run, someone will eventually have to answer it from memory.

Five things autonomy should still record

1. The mandate. What the agent was cleared to do before it started: the scope, the target, the constraints, and the spend someone agreed to.

2. The stops. Every point where the agent could not go on, and what happened next. A run that hits a wall should pause and say so, not skip the hard part and report success.

3. The agent's own decisions. Patterns it adopted, workarounds it chose, fixes it made to the build. Kept only in the agent's context, they vanish with the run, and the next run and the next auditor lose them.

4. The proof, gaps included. Evidence that behavior was preserved, next to an explicit account of what was not checked.

5. The human acceptance. Who approved, who merged, who turned a lesson into a rule, and when.

How Morph records an autonomous milestone

• The mandate is approved twice. The Project Spec (target stack, high-level migration plan, key design decisions, repo map, testing strategy) must be approved before Morph plans the roadmap. Each Milestone Spec, which sets out the milestone's scope, the files involved, its design choices and its risks, is approved before that milestone starts. On Morph's credit-based plans, a "Start this milestone?" dialog shows the run's cost in dollars and credits, and nothing starts until someone approves it. Queued milestones are locked, so the plan cannot shift underneath a run.

• The starting point is pinned. When a project is created, Morph records the commit SHA of each repository's origin branch. Mainline work that lands later shows up against that baseline, and syncing it into the migration becomes a milestone of its own, reviewed like the rest.

• Access is checked before each step. Before Morph generates a spec, sets up a project or starts migration work, it confirms it can read, push to and open pull requests on every repository it changes, and refuses a step whose check failed. On GitHub it works through the Modelcode GitHub App; on GitLab and Azure DevOps, pull requests are opened with the project creator's connection.

• The run leaves a trail as it goes. Once a milestone is approved, the agent works autonomously on a branch of its own: it breaks the milestone into tasks, takes them in turn and commits at the end of each one. Every task has an ID (M1-T001, for example) and a status, and progress is persisted, so the run is on the record whether or not anyone watches it.

• Blockers are written down, not worked around. Since November 2026, a run that hits a problem it cannot solve alone, such as a registry it can't reach, a service behind a VPN, an expired sign-in or a missing secret, pauses instead of failing or skipping the work and calling it done. It files a blocker issue with what is blocked, the evidence and its suggested fixes, and the project owner gets an email. A help chat that works in the run's own workspace records what was done in the issue and asks before marking it resolved; it cannot commit or push, so only the resumed run changes the branch. If the team tells it to proceed without the missing piece, the run reports that part as blocked and never as passed. Afterward, Code Review lists these issues in an Execution Blockers group, each with what was done about it.

• What the agent learns is written back. Before working, an agent reads the Project Spec, the project setup, the rules, the relevant wiki pages and the milestone description. Afterward, it writes new patterns, architectural decisions and fixes to the lifecycle scripts back into Project Knowledge, mostly as wiki pages, where the next agent and any reviewer can read them.

• Evidence travels with the work. At the Medium and High validation levels, Morph exercises the migrated application itself. High adds the original: Morph starts it before anything changes, records how it behaves as a baseline, and compares the new version with that recording. Starting with milestone two, every functional test from earlier milestones is replayed as a regression suite; a failure there goes to the team for a decision instead of silently blocking or passing. Morph ships the integration tests it used to verify each milestone along with the code.

• People make the final call, on the record. A milestone's work reaches the team as pull requests on GitHub, GitLab or Azure DevOps, where it goes through the usual review and merge process, and no change lands on the mainline until someone explicitly approves it. Comments on the spec, milestones, wikis and rules carry the author, a timestamp and the quoted text, and resolved or outdated ones stay visible. A rule drawn from a merged pull request stays a draft until someone publishes it, and an edited rule changes future milestones, never completed ones. Knowledge chat conversations are saved by default, so a team can reopen a session and see what was discussed and decided; an organization can ask Modelcode to turn that retention off.

One setup detail belongs in any audit plan. When Morph commits and pushes a run's work, the repository's git hooks (husky, lint-staged, commitlint, pre-commit) do not run. If the team relies on a hook to enforce a check, that check belongs in CI on pull requests, or in a lifecycle script such as lint so Morph runs it during validation.

How other tools leave a record

GitHub's Copilot cloud agent keeps its record at the level of the commit and the session. GitHub describes it as designed to be auditable and traceable: the agent's commits are authored by Copilot with the developer who assigned the task marked as co-author, they are signed, each commit message links to the agent's session log, and session logs and audit log events are available to administrators. The developer who asked for a pull request cannot approve it, and the agent cannot approve or merge one. GitHub adds a caution about those logs: "Logs do not replace your own review and testing."

AWS Transform continuous modernization, generally available since August 2026, makes modernization a recurring practice. It scans connected repositories on demand or on a schedule, prioritizes what it finds, and at your direction opens pull requests with validated code changes. Findings accumulate from scan to scan, so the record reads as a history of what each analysis found, alongside the pull requests raised to fix it.

Morph keeps its record at the level of the milestone: the plan and spend approved before a run, what happened inside it, and the evidence and human decisions after it. The right shape depends on the work: the longer a job runs between human decisions, the more the record needs to hold beyond the code itself.

Questions to ask about an autonomous agent's record

• What exactly did a person approve before the run started, and can you open that version today?

• When the agent got stuck, does the record say so, or does the run simply end as done?

• Which checks were skipped or could not run, and where is that written down?

• At every step, can you tell what the agent did from what a person did?

• Where did the agent run, and under whose credentials did it act?

• Do the decisions the agent made between gates outlive the run, in a form the next run reads?

• Do your own repository checks still apply to what the agent pushes?

FAQ

What is autonomous code modernization?

Modernization in which an AI agent carries out a planned piece of a migration, such as a framework upgrade, a module port or a service extraction, from start to finish without a person approving each edit. People still set the scope, approve the plan and decide what merges.

What should the audit trail of an autonomous agent contain?

Enough to answer six questions about every run: what happened, when, where, on what instruction, with what outcome, and who did each part, agent or person. In practice that means the approved plan and spend, the run's tasks and commits, any blockers and how they were resolved, test results with the checks that were skipped, and the human approvals and merges.

What does Morph do when a run hits a blocker?

It pauses, files a blocker issue with the evidence, and notifies the project owner. The run waits up to seven days; if the blocker is still open then, the run stops, the milestone fails, and the owner is told. Nothing blocked is reported as passed.

Can Morph merge its own work into the main branch?

No. Your team reviews and merges the pull requests of every milestone, and the full migration comes back as one last pull request into the branch you chose as its target. Nothing lands on your mainline unless a person on your team approves it.

For the layers a finished migration's audit trail should hold, read Auditable AI Code Migration: What an Audit Trail Should Contain; for what each change should hand its reviewer, read AI Code Migration With Human-Reviewable Changes: What Each Change Should Give a Reviewer.

More on Morph: https://modelcode.ai/?utm_source=substack&utm_medium=blog&utm_campaign=autonomous_audit_trail

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

The video below follows one extraction from the dependency map to the merge in under two and a half minutes.

What should an AI platform do in a monolith to microservices migration?

It has two jobs. The first is to give your architects evidence for the boundary decision without taking that decision away from them. The second is to carry out the extractions those boundaries imply, proving at each step that callers see no change. A tool that proposes boundaries and then hands back unverified code leaves the hardest part to your team. A tool that only translates code leaves the sequencing, the cutovers and the verification to people.

Mapping the dependencies across every repository

Where to cut is an architecture decision, and it stays with your architects. What a platform can add is a picture of the actual wiring. Modelcode’s documentation says Morph detects dependencies and architecture across repositories and, on full-stack projects, follows the dependencies that run between backend services and the UI layers calling them. That matters in a decomposition: a module that looks self-contained on the backend can still feed screens kept in a separate frontend repository, and a boundary drawn without that link usually surfaces as a broken page after the cutover.

Morph handles the shape a decomposition takes: one or many source repositories into one or many target repositories, with monolith to microservices decomposition and service extraction listed among the supported transformations. Teams that want help finding the seams sometimes add a runtime analysis tool before the plan is written; vFunction, for example, pairs runtime insights with its own analysis to turn monoliths into modular services.

Step 1: the plan becomes a Project Spec your team approves

The boundary decisions are written into the Project Spec, the document that describes how Morph will transform the code across the repositories in the project. Its Repo map lists each repository before and after the migration and what happens to it: edited in place, kept read only, created new, or fully migrated. In a decomposition, the new service repositories show up there, and Morph creates them only when the spec is approved. Before that, your team can refine the spec in Knowledge chat, run Auto-review to compare it with the codebase analysis and your stated intent, and pull in anyone likely to catch a missing constraint. Approval starts roadmap planning: an ordered sequence of milestones.

Step 2: each extraction runs as approved milestones

In the video, one extraction takes three moves: an empty service is stood up, the capability’s code moves into it, and callers switch to its interface, each move being its own milestone. On the platform, the roadmap sets the milestones from the approved spec, and every milestone follows the same cycle. Before any code is generated, your team reads the Milestone Spec (scope, relevant files, design decisions and risks), adjusts it if needed and approves it; while earlier milestones are still unmerged, the next one can be read but not approved. Inside a milestone, the agent splits the work into tasks, commits after each one, and the milestone ends in one or more pull requests. Each milestone delivers a working increment, so the migration can pause after any extraction with a system that still runs.

Step 3: the new service is checked against the monolith

Validation depth is a project setting. At the Low level, Morph checks the build and runs the tests without starting either application; at Medium, it runs the migrated application; at High, it runs the original first, captures a baseline, and verifies the target against it. That last level is the one the video shows. On the backend, testing agents read the source, start the application and capture how its APIs and CLIs respond. For an API test, the same method, headers and request body go to both versions, and the status code and response body are compared. The tests run against the pull request branch, so the comparison is in front of reviewers before the merge.

A failing test opens a review issue on the milestone automatically. When the two versions differ for an expected reason, such as a version bump, an agent-written note says so, which keeps real regressions easy to spot. In a multi-repository project, each repository’s tests are tracked and reported separately, so every new service keeps its own record.

Step 4: later extractions re-check the earlier ones

From the second milestone onward, Morph re-runs the functional tests accumulated from every previous milestone as a regression suite, after the current milestone’s own tests. In a decomposition, extracting the fourth service re-tests the behavior proven when the first three left the monolith. A regression failure is surfaced rather than blocking the current milestone, because the right fix may belong to either one and that call is yours.

Step 5: review lessons and rules carry forward

When a milestone merges, a background Milestone Learning task reads the merged pull request (review comments, inline feedback, the final diff, your follow-up commits) and writes what it learns back to the project as wiki updates and new rules, which start as drafts until you publish them. Rules are included in the context of every task in every milestone, so a convention your reviewers enforce on the first service, say how services handle errors or receive their dependencies, applies to each service extracted after it. The merge stays with your team: nothing reaches your mainline without your explicit approval, and the final pull request presents the whole migration as one reviewable unit.

Questions to ask any AI platform for this migration

• Does it show dependencies across all the repositories involved, frontend included?

• Can we edit and approve the plan, and each step, before any code is generated?

• Does every step land as pull requests that our reviewers read like any other change?

• Is the new service compared with what the monolith actually returns, or only with tests written after the fact?

• When a later step lands, are the earlier steps tested again?

• Does a correction we make once reach every service that follows?

FAQ

Can an AI platform decide where to split a monolith?

It can inform that decision, not own it. Morph maps dependencies across repositories, including the links between backend services and UI layers, so architects draw boundaries on evidence. The boundaries, and the plan built on them, are approved by your team in the Project Spec before work starts.

How do you extract a microservice without breaking the monolith?

One capability at a time, in the order the approved plan sets, with every step delivered as a working increment your team reviews. Morph lets the next milestone be approved only after earlier ones merge, and it re-runs earlier tests as later work lands.

Which languages and application types does Morph support for a decomposition?

Source or target languages include Java, C#, Python, Go, PHP, Ruby, Kotlin, Scala, Rust, C, C++, Groovy, Clojure, Ada, Node.js, TypeScript and JavaScript. Targets can be RESTful services, CLI tools or full-stack applications. Native mobile apps, desktop GUI applications and plugins are not supported as migrations today.

For why decompositions fail differently at the boundary and at the move, read Monolith to Microservices: the Deciding Half and the Executed Half on this blog.

Learn more about Morph: https://modelcode.ai/?utm_source=substack&utm_medium=blog&utm_campaign=video3_companion

What should “CI/CD integration” mean for an AI migration?

For most engineering teams, the pipeline is the definition of done. A change that skipped it is a change nobody can vouch for, however clean the code looks. So the useful question about an AI modernization tool is not whether it ships a CI/CD plugin. It is whether its output enters the same path as human work: a branch, a pull request, the existing build and test jobs, a reviewer, a merge.

A tool that hands back an archive, a patch to apply by hand, or a rewritten repository in its own console leaves that integration work to your team. A tool that delivers through pull requests inherits your pipeline from day one.

How does Morph fit into an existing pipeline?

Morph works on a dedicated feature branch (morph-main by default) and splits the migration into milestones. Each milestone runs on its own branch and ends with a pull request back to the feature branch. From there, Modelcode’s documentation is explicit: CI/CD checks run on those pull requests automatically, your existing pipelines run against the changes, and you merge once the checks pass.

Three mechanisms sit on top of your pipeline:

• Acceptance criteria. These are quality gates the Morph Platform checks on every milestone pull request. Two are built in when your lifecycle defines them: the build must succeed, and the test suite must pass. Teams can add deterministic thresholds of their own, such as zero lint warnings, a minimum line coverage, or zero high-severity audit findings. A failing criterion shows up as a reviewable issue instead of silently blocking the work.

• The lifecycle. With an agent’s help, your team writes the scripts that install dependencies, build, start, health-check and test the application, plus a smoke script that exercises it enough to show it really works. Smoke is mandatory on the original application: until a smoke run passes there, Morph does not consider the setup validated. The same scripts run first against the original code, which becomes the behavioral reference, then against the migrated code, and the Validation Hub puts the behavior of the two applications next to each other.

• Ordered merges. The next milestone stays locked until each pull request from the current one is merged or closed, so a red pipeline pauses the migration instead of letting new changes pile up on top of a failure.

Once every milestone is merged, Morph opens one final pull request from the feature branch to your target branch: the entire migration as a single reviewable unit, which your team can run through CI/CD and merge when ready. Morph ships the integration tests it used to verify each milestone along with the code.

What runs where?

On a Modelcode Hosted project, builds run in a container image built from the project’s Dockerfile. When the application depends on internal APIs, databases, private package registries or licensed services, the self-hosted ModelDaemon runs the build, run and test steps on a machine inside your network. The daemon only opens outbound connections, so the machine stays unexposed and your firewall keeps its inbound rules as they are.

Repositories connect through a GitHub App, through GitLab (gitlab.com, a self-managed server or a GitLab Dedicated instance), or through Azure DevOps with Microsoft Entra ID.

Where other approaches land

Recipe-based refactoring sits naturally in CI for mechanical changes. OpenRewrite recipes run from Maven or Gradle build plugins, and the Maven plugin’s dryRun goal can act as a gate: with failOnDryRunResults turned on, the build fails whenever a recipe would still change the code. On Moderne, the commercial platform built to run the OpenRewrite recipe catalog, running a recipe does not touch repositories by itself; the team chooses what to commit, directly or as a pull request.

General coding agents can open pull requests as well, but how much of the pipeline their work goes through depends on how each team wires them in. The distinction worth checking on any shortlist is whether CI is the default path for every change, or an option someone has to remember.

Questions to ask any vendor

• Will each change reach us as a pull request in a repository we own?

• Do our existing pipelines run on those pull requests without extra setup?

• Can we add our own thresholds (lint, coverage, audit findings) and see failures before anything merges?

• When the application needs private services, can the build and test steps run on our own machines?

• Does a failed check stop the migration, or does work keep accumulating behind it?

FAQ

Does Morph replace our CI/CD pipeline?

No. Morph delivers its work as pull requests, and your existing pipelines run on them as they would on any other change. Its acceptance criteria and lifecycle checks add migration-specific gates on top.

Which Git providers does Morph work with?

GitHub, GitLab (gitlab.com, self-managed servers and GitLab Dedicated) and Azure DevOps. Each completed milestone opens a pull request in the connected repository.

Who merges the changes?

Your team does. No change lands on your mainline until someone on your team approves it, and the final pull request lets reviewers see the whole migration before it lands.

For how Morph checks behavior milestone by milestone, see Verifiable AI Code Modernization: What It Means and How It Works on this blog.

Learn more about Morph: modelcode.ai

What’s happening to Deno: shutdown dates

On October 9, 2026, the Deno team announced they’re joining Cloudflare. Here’s what that means:

• Deno Deploy keeps running for six months, then shuts down, around April 2027. Deno hasn’t published an exact date.

• The Deno runtime gets monthly bug-fix and security releases for one more year, until around October 2027. Then development ends, though the code stays open source.

• JSR keeps running, on Cloudflare infrastructure.

  

  “We know this is a consequential change for people who have built on Deno,”

  Ryan Dahl wrote in the announcement, which likely pushed more and more developers to add Deno to Cloudflare migration to their backlogs.
  

Deno Deploy to Cloudflare Workers: what actually changes

Most of your code looks the same. That’s the problem. The part that does change is spread across every file, and none of it shows up as a compile error.

Moving from Oak to Hono, routers become route groups, context.request.body() becomes c.req.json(), and config moves from context.state to c.env. Moving from Deno KV to Workers KV, tuple keys like ["device", id] become strings like device:${id}, and the async iterator becomes cursor pagination. Strong consistency becomes eventual consistency.

Meet Notify: a real Deno app, discontinued days after the announcement

Notify is an open-source, self-hosted web push service: send a REST request, and every subscribed device gets a notification. It has a Deno and Oak backend on Deno Deploy, stores devices in Deno KV, has its own Web Push encryption module, and uses a Preact web app as its frontend. It’s MIT-licensed and has 168 stars.

Five days after the announcement, its maintainer discontinued it. The reason is in the README: Notify was built specifically for Deno Deploy, after migrating away from Cloudflare. So we sent it back.

The backend is about 825 lines of TypeScript, with custom cryptography, three authentication schemes and no backend tests. If the migration breaks something, nothing will tell you.

Step 1: Morph plans the migration with you

Morph’s first output isn’t code. It’s a Project Spec: recommendations for the target stack, each with the alternatives it turned down. For Notify, it chose Hono over itty-router, which has far less built-in middleware. It chose Workers KV over D1, because a SQL database is overkill for one table of devices. And it chose Vitest running in the Workers runtime for tests. You can push back on any of it before a line of code changes.

Then comes the plan: one milestone, 12 work areas, four design decisions and five named risks. Each decision lists the options Morph weighed, such as how the KV binding should reach the database layer. Each risk is specific. Workers KV is eventually consistent where Deno KV wasn’t. The plan judged that acceptable for device registration and put the call in front of you before any code was written.

All of it lives in Morph’s Project Knowledge: the origin and target setup, acceptance criteria, the spec, the milestone plan, and the wikis and rules Morph builds as it works. That’s what every later check is measured against.

Step 2: Morph checks its work at every step

Notify had no backend tests, so Morph wrote 37 of them, running in Miniflare, the local Workers runtime. It then checked its work against the spec and caught a requirement it had skipped: adapting the environment validator. It fixed that. It confirmed the app installs, builds, runs, passes a healthcheck and type-checks. Then it added 22 Playwright end-to-end tests.

A separate review then compared the result with the spec and with the original code. It filed 12 issues, and each one was either fixed or closed with a reason. One fix restored a client utility the spec said to keep. Another added unit tests for the Web Push encryption code, bringing the backend suite to 51 tests. One closure explained that a missing `FRONTEND` setting had been removed on purpose, because Workers Static Assets now serves the frontend (We’ve written more about what verifiable modernization means).

Step 3: Comparing the Deno and Workers apps side by side

Plenty of tools will tell you the new code passes its tests. Morph asks a harder question: does the new app do what the old one did?

It checked out the original Deno version of Notify, started it, sent it every request in the test plan and recorded the answers. Then it did the same with the Workers version and compared the two field by field. That’s 19 checks across all API endpoints, including response headers. The checks don’t measure the new app against Morph’s own expectations. They measure it against what the original actually returned.

18 matched exactly. Here’s the 19th: ask the old server about a device that doesn’t exist, for example one that was just deleted, and it crashes with a plain-text “Internal Server Error”. The new server returns a 401 in the same JSON format as every other error, because without a device there’s no secret to check the request against.

That’s a behavior change, and silent behavior changes are what make migrations scary. Morph didn’t hide it. It flagged the mismatch and explained it: the old auth middleware did check for a missing device, but the database lookup threw an error before that check ever ran. The new one handles it. The review confirmed that real infrastructure failures still return a 500. The difference is by design, and it’s documented where the reviewer will see it. Every difference the comparison found was explained and reviewed.

The browser got the same treatment. Morph took screenshots of the main page, the full page and the login-key dialog in both apps and compared them in pairs. All of them matched. The frontend code didn’t change, but what serves it did: Workers Static Assets replaced a custom Oak middleware, and the screenshots show the swap broke nothing visible.

Merging the migration PR with confidence

Morph opened a pull request with an architecture diagram of what’s new, what changed and what was removed.

The diagram isn’t what makes the PR easy to merge. The evidence behind it is:

• a spec and plan you approved before any code was written

• tests the original never had, plus end-to-end coverage of the UI

• API parity checked against the real original app, running

• every difference the comparison found, explained and shown to be by design

With that in hand, merging a migration stops being a leap of faith and becomes an easy call. That’s the point of Morph: you don’t merge because you trust the agent. You merge because the evidence is in front of you. Notify took about two and a half hours of agent time.

Not moving to Cloudflare? That’s fine too

Cloudflare is where the Deno team went, but you don’t have to follow them. Node on your own servers, Bun, or a container on the platform you already run: the target is part of the Project Spec, and you choose it. The comparison works the same way. Run the original, run the new version, and diff them.

Your Deno migration ticket

That “quick migration” ticket is still in your backlog. Hand it to Morph, review the plan, and merge when the evidence says the old and new apps agree.

Migrate a Deno project with Morph

References

• Original repository

• Migrated repository

• Migration pull request

• Deno’s announcement

What makes AI code modernization trustworthy?

In banking, insurance, healthcare or the public sector, a migration gets judged twice. First by the engineers who run it, then by the risk, compliance and audit functions that have to sign it off. An AI migration earns that second signature when those functions can do their job from the artifacts the project leaves behind, without reconstructing anything after the fact.

That comes down to five requirements. They apply to every vendor on a regulated shortlist, from large platforms such as IBM, AWS Transform and Moderne to newer specialists.

1. An approved plan before the migration starts

Morph begins with a Project Spec that the team reviews and approves: the target stack, the migration approach, the requirements and constraints, the scope, and the repositories involved. Approval is what triggers the migration roadmap, so the plan a risk officer reads is the plan the platform executes. Along the way, design decisions are recorded in Project Knowledge, and Rules carry the team's standards into every milestone.

2. Every change reviewable, nothing merged without a person

Work ships as milestone pull requests in the organization's own GitHub, GitLab or Azure DevOps repository. Modelcode's documentation states that nothing is merged to the mainline without explicit approval, and approval rules follow the team's existing policy. Every pull request of a milestone has to be resolved before the next milestone begins, which keeps the review history in order.

3. Behavioral evidence, not just a green build

Together with the agent, the team sets up how the application installs, builds, runs, passes its health check and gets tested. Morph runs that lifecycle on the original code to set a behavioral baseline, then on the migrated code, and its Validation Hub compares how the two applications behave, side by side. Acceptance criteria add deterministic gates on every milestone pull request, for example zero high-severity audit findings or a minimum line coverage. Morph ships the integration tests it used to verify each milestone along with the code.

4. Control over where the work runs

When an application depends on internal systems, the self-hosted ModelDaemon builds, runs and tests it on a machine inside the organization's network. The daemon connects out and nothing connects in, so no inbound port is opened. GitLab self-managed and GitLab Dedicated instances are supported, and sign-in can go through SAML 2.0 or OpenID Connect with identity providers such as Okta or Azure AD; SSO users join only by invitation.

5. A vendor that can pass the security review

A regulated buyer reviews the vendor as well as the code. Modelcode holds SOC 2 Type 2 and ISO/IEC 27001:2022, and its trust center (trust.modelcode.ai) lists both and offers more detail on its security practices on request.

Questions for any shortlist

• Can we approve the plan before the vendor's AI starts the migration?

• Does every change arrive as a pull request under our own review rules?

• What evidence shows the migrated application behaves like the original one?

• Can builds and tests run inside our network?

• Which certifications does the vendor hold, and where can our security team get the documentation?

Frequently asked questions

Is Morph certified for regulated industries?

Certifications belong to the company: Modelcode holds SOC 2 Type 2 and ISO/IEC 27001:2022. Whether a migration meets a specific regulation is for each organization's compliance team to assess, and the plan, pull requests and behavioral evidence above are what they assess it with.

Can the migration run inside our own network?

The build, run and test steps can: the self-hosted ModelDaemon runs them on a machine in your network over outbound-only connections. The Morph Platform coordinates the work.

Does a person approve every change?

Yes. Every milestone ends in a pull request that your team reviews and merges, and nothing reaches the mainline without explicit approval.

For what the audit trail of a migration contains, see Enterprise Code Migration With a Compliance Audit Trail: What It Takes on this blog. To learn more about Morph, visit modelcode.ai.

What counts as audit evidence in an AI migration

Evidence is anything a reviewer can open later and check without asking the people who did the work. For a migration, that means four records per change: the decision that authorized it, the change itself in a reviewable form, proof that behavior survived, and the acceptance by a named person. A log of what the model generated is not on that list. It shows activity, not authorization or correctness.

Step 1: the plan is approved before code exists

Morph starts by mapping the connected repositories and proposing how the migration should run, sequenced into milestones. Your engineers revise that proposal and approve it. Approval also fixes the acceptance criteria, the explicit gates every milestone must pass, so the definition of done is on record before the first line is generated. Every later piece of evidence points back to this approved plan.

Step 2: changes arrive as milestone pull requests

Work is delivered in milestones, each one a pull request scoped to a part of the plan, so a reviewer reads a bounded change instead of one enormous diff. Before any person looks at it, Morph reviews the milestone against the whole codebase for broken contracts, missed call sites, dependency conflicts and architectural violations. Your team then reviews it through the branch protections and approval rules it already enforces, which means the review record sits in your own repository.

Step 3: each pull request carries its proof

Equivalence is checked by behavior, not by reading code. Morph replays identical real-world journeys on the original application and on its migrated version, then compares how each behaves: outputs, state, integrations and side effects. When the two disagree, the comparison goes back to the milestone for rework. When they agree, the results are attached to the pull request as evidence for the reviewer. The integration tests Morph used to verify each milestone are delivered with the code, so the checks stay with the codebase once the migration is over.

Step 4: a person signs off before anything merges

No milestone merges on the model's authority. A reviewer accepts it, and that acceptance is stored in the same pull request history as the change and its evidence. Context carries forward too: each new milestone picks up the approved plan, earlier decisions and the evidence on file, so the record stays continuous from the first pull request to the last.

Where the evidence lives

Because each record is a pull request, a review or an attached result, your auditors find the evidence in the repository they already audit. Execution can stay inside your perimeter as well: ModelDaemon can execute the work inside your network without any inbound access for Modelcode, and a fully on-premises deployment is available. At the company level, Modelcode holds SOC 2 Type 2 and ISO/IEC 27001:2022 (details at trust.modelcode.ai).

Where coding agents fit

Coding agents are good at producing code quickly, and Morph does not replace them. It runs the modernization as a program around that speed, with the approved plan, the milestones and the proof linked from start to finish. Modelcode's migration work spans healthcare systems and safety-sensitive embedded software, delivered against real production constraints.

Frequently asked questions

What audit evidence should an AI code migration produce?

At minimum: an approved migration plan, a reviewable record of each change, proof that behavior was preserved, and the sign-off that accepted it. With Morph, those are the approved plan, the milestone pull requests, the attached comparison results and the pull request approvals.

How do you verify an AI-generated code migration?

Compare behavior, not code. Run the original and migrated systems through the same journeys, check outputs, state, integrations and side effects, and send any mismatch back to the milestone that produced it.

Who approves changes in an AI-driven migration?

Your engineers, at two points: when they approve the plan and its acceptance criteria, and when they review and sign off each milestone pull request. Morph's automated review runs before theirs, not instead of it.

Does the audit trail leave our environment?

The records live in your repository and review tooling. ModelDaemon can run the work inside your network without any inbound access for Modelcode, or you can deploy fully on-premises.

For the requirements side of the same topic, read Enterprise Code Migration With a Compliance Audit Trail: What It Takes. To see Morph, visit modelcode.ai.

Related reading on this blog: Trustworthy AI Code Modernization for Regulated Industries: What to Require.

Two halves, two failure modes

Every decomposition has a deciding half (where are the service boundaries?) and an executing half (how does the code actually get there?). The folklore failure, the eighteen-month project that ships a distributed monolith, is usually a boundary failure: services cut along team lines or module names instead of actual runtime dependencies. Tools that analyze runtime behavior to propose boundaries, vFunction being the established reference, address that half. No execution platform fixes a wrong boundary, Morph included.

The executing half fails differently: not wrong, but unverifiable. Extractions done by hand or by an unsupervised agent drift from the plan, and nobody can prove the extracted service behaves like the code it replaced. That proof is the core of what Morph automates.

How Morph executes a decomposition

The decomposition plan becomes a Project Spec: which capabilities leave the monolith, in what order, with what interfaces, approved by the engineering owner before work starts. Each extraction then ships as a sequence of milestone pull requests: the service scaffold, the capability move, the interface cutover, each one small enough to review. Behavioral equivalence is established per extraction: the platform generates and runs tests demonstrating the service answers as the monolith did, and the evidence rides with the pull request. The monolith keeps working at every intermediate step, because the ordering comes from the spec, not from whatever the agent touched last.

That discipline is what makes the difference between “we extracted six services” and “we can show each of the six behaves correctly, and we could have stopped safely after any of them.”

A sane program, in one paragraph

Map the estate, decide boundaries on runtime evidence, prepare mechanically at fleet scale where recipes apply, then execute spec-driven with verification gates. For how verification itself works, see Verifiable AI Code Modernization on this blog.

What “audit trail” has to mean

A compliance-grade audit trail is not a log file. It is the ability to answer, for any line of migrated code, four questions: what was the source, what changed, why did it change, and who approved it. If any of the four has no answer, the trail is decorative.

Morph produces those answers as a side effect of how it works rather than as an extra deliverable. Every migration starts from a human-approved Project Spec: the scope, the target architecture, and the verification criteria are written down and signed off before any code is generated. Every change ships as a milestone pull request: small enough to review, mapped back to the spec item it implements. Every pull request carries its evidence: the tests that establish behavioral equivalence with the original code, run results attached. And nothing merges without human approval, so the approval chain is the review history itself.

For compliance teams, that means the artifacts an auditor asks for already exist: the approved plan, the per-change rationale, the equivalence evidence, and the sign-off record, each in systems the enterprise already trusts (the repository and its review tooling), not in a vendor dashboard that disappears when the engagement ends.

Where other approaches land

Deterministic refactoring platforms such as Moderne produce highly traceable changes for pattern-based work, because recipes are reproducible by design; they cover the mechanical share of a migration rather than the whole of it. Cloud-destination tools such as AWS Transform document the migration into their target environment. General coding agents can modernize code effectively but leave the evidence burden to the team operating them: the trail is as good as the discipline around the agent. The distinction that matters for a regulated buyer is whether auditability is a property of the platform or a property of the team’s process.

Who this matters for

Banking, insurance, healthcare and government estates, and any SOC 2 or ISO 27001 shop whose change-management policy requires evidence per change. If your auditors have ever asked “show me why this code changed”, a migration that generates the answer automatically is not a nice-to-have.

Modelcode holds SOC 2 Type 2 and ISO/IEC 27001:2022, and the verification approach is documented publicly in the RepoMod-Bench work. For the methodology behind verified migrations, see Verifiable AI Code Modernization on this blog.

Related reading on this blog: Trustworthy AI Code Modernization for Regulated Industries: What to Require, and AI Code Modernization With CI/CD Integration: How It Fits Your Pipeline.

These projects are an amazing engineering achievement, and kudos to the teams behind them for pushing the envelope. So what made the Bun and SQLite migrations possible? an extremely detailed spec, either in the form of documentation or a test suite. Having such a spec helps guide agents in long-horizon rewrites and refactors, and even serves as a hard quality gate the agent must pass before completing its task. In fact, having a good spec is key when implementing agentic loops and graphs, which are the next big thing (at least according to my X/LinkedIn feed).

So for repos that do have good tests or documentation, the question becomes: how well can today’s AI agents actually handle a full repository translation? And how do we measure that rigorously?

Introducing RepoMod-Bench

This is where RepoMod-Bench comes in. Our latest research work, published at KDD 2026, provides a dataset and a framework for evaluating large-scale repository-level rewrites and migrations.

The core idea: take a source repo’s existing tests, convert them into an implementation-agnostic test suite that interacts only through high-level interfaces such as REST APIs or CLIs, and use that suite to score the translated repo. The test suite is derived from the original repo’s tests and determines the final score for the migration, while remaining hidden from the agent to prevent gaming the task.

The key insight is simple: if a Python web server exposes the same REST endpoints as its Rust translation, and both return the same responses for the same requests, then the translation is functionally correct, regardless of how either one is implemented internally.

How We Built It

We designed a four-stage pipeline to construct each benchmark:

1. Repository Selection: We filter for repos that expose a standardized interface (REST API or CLI), check test coverage, and verify licensing.

2. Test Suite Creation: We parse the source repo’s existing tests, convert them to pytest, and critically, filter out any implementation-specific tests. What remains are tests that only interact through the public interface.

3. Configuration: Each benchmark gets a benchmark.yml, a Dockerfile for reproducible builds, and a translation prompt.

4. Validation: We run the generated test suite against the original source repo. If it doesn’t hit 100%, the benchmark doesn’t ship. This guarantees the test suite is a faithful representation of the repo’s behavior.

The Dataset

To demonstrate the framework, we curated a benchmark dataset of 21 real-world repositories of varying sizes, rewritten across 8 programming languages. This totaled over 11,600 unique tests covering over 1.6 million lines of code.

Repository sizes range from 14 LOC to 211K LOC, spanning three complexity tiers: Small (<10K LOC), Medium (10K–50K LOC), and Large (>50K LOC).

What We Found

We used this dataset to evaluate four agent–model combinations on the task of full-repo translation:

A few things stood out:

The scaling collapse is dramatic. Average pass rates drop from 91.3% on small projects (<10K LOC) to just 15.3% on large projects (>50K LOC). The largest project in our benchmark (211K LOC) maxed out at 19.5% pass rate across all agents. Agents aren’t just getting a little worse at scale; they’re hitting a wall.

The harness matters as much as the model. Claude Code outperformed OpenCode by 6.2 percentage points using the exact same underlying model (Claude Opus 4.5). This tells us that agent architecture is a first-class variable, not just the model powering it.

Building compiles; passing tests is another story. Build success rates exceeded 95% across all agents. They can reliably produce code that compiles. But functional correctness, i.e. does the translated code actually do the same thing, is where they struggle, especially at scale.

Single bugs cause cascading failures. In several large repos, a single misunderstood abstraction or incorrectly translated core module would cascade through dozens of dependent tests. The bottleneck isn’t context management, it’s maintaining architectural coherence across thousands of interdependent files.

Why This Matters

At Modelcode we tackle large, messy, complex migrations and rewrites on a daily basis. For us, evaluation is the difference between a successful project and a never-ending bug hunt. That’s why we’re excited to share this work, and hope that it gets adopted and expanded upon by researchers and practitioners alike.

The beautiful thing about this evaluation framework is that it can be used as a feedback signal for the agent performing the migration/rewrite, so for example, an agent can stay in a loop until at least 95% functional equivalence is achieved. But that raises another question - what if my repo doesn’t have such an extensive test suite? What if my documentation is sparse and out-of-date? How do I still benefit from such mechanisms?

That’s a topic for another post, but if you made it this far - check out Morph and find out how our platform connects the dots to enable an end-to-end code modernization process at any scale.

📄 Paper: RepoMod-Bench: A Benchmark for Code Repository Modernization via Implementation-Agnostic Testing

💻 Benchmark & Code: github.com/Modelcode-ai/mcode-benchmark

🔗 Modelcode: modelcode.ai

Comparing Modelcode’s Morph with IBM watsonx Code Assistant now means comparing it with IBM Bob: IBM folded watsonx Code Assistant’s capabilities into Bob, its enterprise AI coding agent, and the old product page redirects there. Bob is a governed agent for daily development with modernization features; Morph is a dedicated migration platform that runs whole modernization programs with verification built in. The shape of the work decides.

First, the Name Change

If you are evaluating “watsonx Code Assistant” from an older shortlist, update the entry: its product page now redirects to IBM Bob, described by IBM as an AI coding agent for enterprises. Bob carries the modernization work forward with repository-wide refactors, dependency upgrades, and premium packages dedicated to Java, IBM i, and mainframe (Z) modernization. Everything below compares Morph with Bob, since that is what you would actually buy today.

--------------------------------------

The Two Products at a Glance

What it is. IBM Bob is an enterprise AI coding agent, now home of the watsonx Code Assistant capabilities. Modelcode’s Morph is an enterprise code modernization platform.

Where modernization lives. In Bob, inside the agent: repository-wide refactors, dependency upgrades, and premium packages for Java, IBM i, and Z. In Morph, it is the platform’s entire purpose: whole migrations run as governed projects.

Working model. Bob works through agentic modes (Ask, Plan, Agent, plus custom modes) under enterprise governance and policy controls. Morph is spec-driven: a human-approved Project Spec, milestone pull requests, and functional testing.

Scope of a typical job. Bob covers daily development plus incremental modernization. Morph covers language upgrades, language translations, framework replacements, and monolith decomposition.

Quality control. Bob relies on governance, policy controls, and security scanning at authoring time, with developer review. Morph adds an approval gate before any code is generated, pull request review per milestone, and behavioral verification against the original application.

Cost visibility. Bob offers multi-model routing with centralized spend visibility (Bobalytics). Morph uses credit-based pricing published on modelcode.ai.

Ecosystem. Bob is built for IBM tooling, with IBM i and Z platforms as first-class targets. Morph is cloud-agnostic (GitHub, GitLab, Azure DevOps) with a self-hosted build daemon (ModelDaemon).

Documented migration types. Bob: Java modernization via its premium package, plus RPG, COBOL, and CL contexts through the IBM i and Z packages. Morph: Python 2 to 3, Java 8 to 21, Ada to C++, COBOL to Java, AngularJS to React, and Express to FastAPI.

------------------------------

What IBM Bob Does Best

Bob’s case is coherence inside the IBM world. One governed agent covers asking, planning, and executing changes across the development lifecycle, with security analysis at authoring time and policy controls an enterprise can actually enforce. The premium packages matter for IBM-heavy estates: Java modernization with structured workflows, and deep platform context for IBM i (RPG, COBOL, CL, SQL) and mainframe Z work that generic tools treat as an afterthought. Cost discipline is a stated design goal, with task-aware model routing and centralized spend visibility. For an organization standardized on IBM tooling, Bob is the natural continuation of watsonx Code Assistant, not a migration.

The structural limit mirrors the strength: Bob is an agent. A whole-stack migration run through an agent still leaves plan ownership, sequencing, and program-level verification with your team.

What Morph Does Best

Morph treats the migration itself as the product. It connects to your repositories, analyzes the codebase, and produces a Project Spec a human approves before any code is generated. Execution ships in milestones, each a pull request through your normal review, and functional tests compare the migrated application’s behavior against the original, increment by increment. Documented migration types span language upgrades, language translations, and framework replacements, and the platform is cloud-agnostic, with a self-hosted daemon for enterprises that keep code on their own infrastructure.

Morph’s structural limit: it is not a daily coding assistant, and it does not try to be. It is designed to work alongside agents (Claude, Codex, or Bob itself) as the modernization overlay.

The Real Difference, in One Paragraph

Bob governs the developer’s daily loop and extends it toward modernization; Morph governs the migration program itself. If modernization for you means continuous upgrades inside a governed IBM development environment, Bob covers it. If it means moving a codebase from one language, version, or framework to another with an approved plan, reviewable increments, and behavioral proof, that is a migration program, and that is what Morph industrializes.

When to Choose Which

Choose IBM Bob when your organization is standardized on IBM tooling, your estate includes IBM i or Z platforms, and modernization arrives as continuous, governed work inside daily development, with Java covered by its premium package.

Choose Morph when the job is a defined migration program, on any cloud, that must be planned, approved, delivered in reviewable milestones, and verified behaviorally, especially outside the IBM ecosystem or across stacks IBM does not prioritize.

They also combine: Bob as the daily agent in an IBM shop, Morph running the migration program alongside, delivering through the same pull-request flow Bob’s developers already review.

Frequently Asked Questions

Is IBM watsonx Code Assistant discontinued?

Its capabilities now live inside IBM Bob, IBM’s enterprise AI coding agent. The watsonx Code Assistant product page redirects to Bob, which carries modernization forward, including a premium Java modernization package.

Is Modelcode’s Morph an alternative to IBM Bob?

For modernization workloads, yes, with a structural difference: Bob is a governed coding agent with modernization features; Morph is a migration platform with an approved spec, milestone pull requests, and functional verification. For daily coding assistance, Morph is not the alternative; it is the overlay.

Which is better for Java modernization?

Both have documented Java paths. Bob’s premium Java package fits IBM-standardized organizations doing continuous modernization. Morph documents Java 8 to 21 among its spec-driven migration types with behavioral verification, and runs cloud-agnostic. The deciding factor is usually ecosystem and whether the work is continuous upgrades or a bounded migration program.

Can Morph and IBM Bob work together?

Yes. Morph explicitly positions itself as a modernization overlay alongside AI coding agents, Bob included: developers keep their governed agent, the migration runs through Morph’s plan-approve-verify process, and both deliver through normal pull requests.

Does Morph support IBM i or mainframe platforms?

Morph’s documented migration types include COBOL to Java, and its platform targets standard Git repositories (GitHub, GitLab, Azure DevOps). For IBM i-specific stacks (RPG, CL, QSYS) Bob’s premium package has dedicated platform context; evaluate per estate.

Why Tests and Documentation Are the Real Deliverables

A migration’s code is, in a sense, the easy part: generative AI produces plausible code fluently. What decides whether the migration holds up is everything around it. Tests are how you know the new stack behaves like the old one, at the moment of migration and at every change after it. Documentation is how the next engineer, auditor, or vendor evaluation understands what exists, why it is shaped that way, and what rules governed the work.

Legacy systems make this concrete: the reason they are hard to migrate is precisely that their original tests and documentation decayed or never existed. A migration that ships modern code with the same gaps has recreated the problem it was hired to solve, one stack newer.

What “Generated Tests” Should Mean

The phrase covers two different things, and a serious evaluation separates them.

Verification tests during the migration. Tests whose job is to prove behavioral equivalence: the migrated increment does what the original did. These belong to the migration process itself, run per increment, and their results should be recorded where the increment is reviewed.

A durable test baseline after the migration. Tests that remain with the codebase as its ongoing safety net: the migration’s opportunity to leave the system more testable than it found it, especially where the legacy code had thin coverage at its observable boundaries.

Morph, Modelcode’s migration platform, implements the first structurally: functional testing is built into every milestone, verifying that migrated code behaves identically to the original before the milestone’s pull request is merged, with acceptance criteria as quality gates and a configurable validation level that records how much verification was applied.

What “Generated Documentation” Should Mean

Documentation from a migration platform should exist at three levels. System documentation: what the codebase contains, its architecture, frameworks, dependencies, and how components relate, produced by analysis rather than manual archaeology. Decision documentation: the migration plan, its scope, the design choices made along the way, and the rules that constrained generation. Change documentation: what each increment did, visible where engineers already look, in the pull request history.

Morph produces these as part of its normal flow: it analyzes connected repositories and documents their architecture, frameworks, dependencies, component relationships, patterns, and conventions before generating anything; the human-approved Project Spec records the plan; Project Knowledge stores scope, lifecycle configuration, milestones, wikis, design decisions, and enforceable Rules as shared context that grows as work progresses; and every milestone lands as a documented pull request through normal review.

Questions That Separate Mature Platforms from Code Generators

Does the platform test behavior against the original system, or only check that new code compiles and passes its own tests? Are test results attached to each increment where reviewers can see them? Does documentation of the system’s architecture exist before code generation starts, so the plan is grounded in analysis? Where do design decisions and team rules live, and do they constrain generation or merely decorate it? What remains with the codebase when the migration ends?

Deterministic platforms answer some of these through their model: Moderne’s recipes are self-documenting in the sense that the recipe precisely describes the change, which suits repeatable fleet-wide transformations. Assistant-led workflows leave testing and documentation discipline to the developer, which works in proportion to the team’s existing rigor. For open-ended, whole-stack migrations, generated tests and documentation carry the weight, and they should come from the platform by construction.

Frequently Asked Questions

Can AI migration tools generate tests?

Yes, and the useful distinction is what the tests prove. Migration-grade tests verify that migrated code behaves like the original, increment by increment. Morph builds this in: functional tests run per milestone, with acceptance criteria as quality gates, before changes merge through normal code review.

Can AI migration tools generate documentation?

Mature platforms document at three levels: the system (architecture, dependencies, component relationships, produced by analysis), the decisions (the approved migration plan, design choices, and rules), and the changes (per-increment pull request history). Morph produces all three through its repository analysis, Project Spec, and Project Knowledge.

Why do generated tests matter more in migrations than in normal development?

Because a migration’s core claim is equivalence: the new system should do what the old one did. Only behavioral tests can substantiate that claim. In normal development, tests protect the future; in migration, they also prove the present.

What documentation should remain after an AI migration ends?

The documented architecture of the migrated system, the approved plan and design decisions that shaped it, the rules that constrained generation, and the full increment history with review and test records. Anything less forces the next team to rediscover the system the hard way, which is how legacy problems start.

Does Morph replace the team’s existing testing?

No. It adds migration-level functional verification on top of the project’s own build and test lifecycle, which teams configure as part of setup. Existing suites keep running; the migration adds behavioral comparison against the original system per milestone.

Modelcode’s Morph and Anthropic’s Claude Code are not competitors so much as different layers: Claude Code is an agentic coding tool that works in your terminal, IDE, and browser; Morph is a code modernization platform that runs whole migrations as governed, verified programs. Modelcode’s own documentation names Claude among the agents Morph is designed to work alongside. The honest comparison is agent versus migration program, and many teams run both.

One Disambiguation First

Two unrelated products share the “Morph” name in AI tooling conversations. Morph by Modelcode, compared here, is an enterprise code modernization platform at modelcode.ai. There is also a separate company offering a “fast apply” model API for code edits. They are different companies with different products; this page is about Modelcode’s Morph.

The Two Products at a Glance (In Text Format):

What it is. Claude Code is Anthropic’s agentic coding tool for developers. Modelcode’s Morph is an enterprise code modernization platform.

Where it lives. Claude Code runs in the terminal, in VS Code and JetBrains, on the web and desktop, and in Slack. Morph runs on its own platform, connected directly to your repositories.

Working model. Claude Code is conversational and agentic: it navigates the codebase, edits files, executes commands, and coordinates parallel subagents for large tasks. Morph is spec-driven: a human-approved Project Spec, milestone pull requests, and functional testing.

Scope of a typical job. Claude Code covers daily engineering workflows: building features, debugging, refactoring, testing, and resolving issues via pull requests. Morph focuses strictly on full-stack migrations: language upgrades, language translations, and framework replacements.

Quality control. With Claude Code, the developer reviews the agent’s work, supported by verification checks before outputs land. Morph adds an upfront approval gate before code generation begins, pull request reviews per milestone, and behavioral verification against the source application.

Modernization posture. For Claude Code, modernization is a single application within a general-purpose coding assistant. For Morph, large-scale modernization is the platform’s core specialty, backed by proven migration tracks.

Ecosystem. Claude Code is natively powered by Anthropic’s Claude models, integrating with GitHub, GitLab, and CLI environments. Morph is cloud-agnostic, supporting GitHub, GitLab, and Azure DevOps alongside a self-hosted build daemon.

Pricing. Claude Code is bundled into Claude Pro and Max plans, detailed on claude.com. Morph operates on a credit-based Pro plan, detailed on modelcode.ai.

What Claude Code Does Best

Claude Code is one of the strongest agentic coding tools available: it maps a codebase with agentic search, makes coherent multi-file edits, turns issues into pull requests, and runs wherever developers work, from the terminal to the IDE to Slack. Its 2026 releases pushed scale further, with dynamic workflows fanning work across parallel subagents and routines for scheduled or event-driven tasks. For day-to-day engineering velocity, including plenty of modernization-flavored work (refactors, upgrades, test generation), it is a general-purpose force multiplier under the developer’s own review.

The structural limit is the same as for every agent: scope and verification stay with the human driving it. An agent does not own a migration plan, sequence a program, or prove behavioral equivalence across an entire estate; the developer does.

What Morph Does Best

Morph industrializes exactly that program layer. It analyzes connected repositories and produces a Project Spec a human approves before any code is generated; execution ships as milestone pull requests through normal review; functional tests compare migrated behavior against the original, increment by increment. Documented migration types include Python 2 to 3, Java 8 to 21, Ada to C++, COBOL to Java, AngularJS to React, and Express to FastAPI. It is cloud-agnostic, offers a self-hosted build daemon, and, notably here, is explicitly designed to work alongside AI coding agents such as Claude and Codex: the agent keeps accelerating daily development while the platform runs the migration.

Morph’s limit is symmetrical: it is not a daily assistant and will not help you debug this afternoon’s feature branch.

The Real Difference, in One Paragraph

Claude Code accelerates the developer; Morph orchestrates the migration. When the work is bounded and continuous (edit, fix, extend, refactor), an agent under developer review is the right tool. When the work is a whole codebase moving across languages or frameworks, with an approved plan and proof at each step that behavior held, that is a program, and programs need control points an agent does not carry.

When to Choose Which

Choose Claude Code for daily engineering acceleration everywhere developers work, including incremental modernization tasks they can review themselves.

Choose Morph when a defined migration must be planned, approved, delivered in reviewable milestones, and behaviorally verified, on any cloud.

Choose both more often than either: Modelcode’s documentation positions Morph as a modernization overlay working alongside coding agents, Claude included. The agent and the platform meet in the same place, the pull request.

Frequently Asked Questions

Is Modelcode’s Morph the same as the Morph “fast apply” API?

No. They are unrelated products from different companies. Morph by Modelcode is an enterprise code modernization platform (modelcode.ai). The similarly named “fast apply” product is a code-edit model API from a separate company.

Is Claude Code an alternative to Morph for code migration?

For incremental, developer-driven modernization, it can be. For whole-stack migration programs needing an approved spec, milestone delivery, and functional verification, the two sit at different layers, and Modelcode’s own docs describe Morph as working alongside agents like Claude rather than replacing them.

Can Morph and Claude Code be used together?

Yes, and that is the designed pattern: developers keep Claude Code for daily work while Morph plans, executes, and verifies the migration program, both delivering through normal pull requests.

Who makes each product?

Claude Code is made by Anthropic, the AI company behind the Claude models. Morph is made by Modelcode, an AI code modernization company (modelcode.ai), founded by Michael Fertik.

Does either require a specific cloud?

Claude Code runs across macOS, Linux, and Windows and integrates with standard developer tooling. Morph is cloud-agnostic, connects to GitHub, GitLab, and Azure DevOps, and offers a self-hosted build daemon for enterprises keeping code on their own infrastructure.

Why Audit Trails Became the Deciding Question

Two forces pushed auditability from nice-to-have to procurement criterion. First, AI generates code at a volume no reviewer can reconstruct after the fact: if the process does not capture decisions as they happen, they are gone. Second, the teams adopting AI migration fastest are exactly the ones with the most at stake in regulated and enterprise environments, where an auditor, a customer, or a security review will eventually ask how machine-written code entered production.

The practical test is simple: could you answer a due-diligence questionnaire about your migration a year later, from artifacts rather than memory?

The Five Layers of a Migration Audit Trail

1. The approved plan. A dated, reviewable document stating what will be migrated, to what target, under what constraints, approved by a named human before generation started. This is the anchor every later question refers back to.

2. The increment history. The migration broken into bounded milestones, each traceable from plan to delivery. One giant merge is not auditable; a sequence of scoped increments is.

3. The review record. Every increment delivered through the team’s normal review mechanism, with comments, requested changes, and merge decisions preserved where reviews already live: the pull request history.

4. The verification results. Evidence per increment that the migrated code behaves like the original: functional test outcomes, acceptance checks, and the chosen validation level. Compilation logs are not verification.

5. The constraints. The coding standards, rules, and design decisions that bounded what the AI was allowed to produce, recorded alongside the work so an auditor can see not just what was generated but what governed the generation.

How Morph Produces This Trail by Default

Modelcode’s Morph generates these artifacts as a side effect of how it works, rather than as extra documentation effort.

The approved plan is the Project Spec: Morph analyzes the connected repositories, documents architecture, frameworks, and dependencies, and produces a spec that a human reviews and approves before any code is generated. The increment history is the milestone structure itself, with each milestone delivered as a pull request through the team’s standard review and merge process, which preserves the review record in Git where audit teams already look. Verification results come from built-in functional testing that compares migrated code against the original, with acceptance criteria acting as quality gates per milestone and a configurable validation level that records how much verification was applied. The constraints live in Project Knowledge and Rules: migration scope, lifecycle configuration, design decisions, and enforceable team standards, stored as shared context across the whole project.

Morph connects to GitHub, GitLab, and Azure DevOps, is cloud-agnostic, and offers a self-hosted build daemon for enterprises whose code cannot leave their infrastructure, which keeps the audit trail on infrastructure the enterprise controls.

What Auditors Actually Ask

Reviews of AI-assisted change tend to converge on the same questions, whatever the framework: Who approved this change before it was made? What exactly changed, in what order? How was equivalent behavior demonstrated? What prevented the AI from violating your standards? Could you reproduce the decision chain today? A migration process that answers these from stored artifacts passes; one that answers from recollection does not.

Deterministic platforms such as Moderne answer some of these differently and legitimately: a recipe is itself a precise, reviewable statement of the change, and identical inputs produce identical outputs, which auditors can verify directly. The gap deterministic tools leave is the open-ended migration that cannot be fully expressed as recipes, which is where plan-approve-verify processes carry the audit burden.

Frequently Asked Questions

What is an auditable AI code migration?

One where the plan, the increments, the reviews, the behavioral verification, and the governing standards are all captured as durable artifacts at the time of the work. Anyone can later reconstruct what changed, why, who approved it, and how it was proven safe, without relying on anyone’s memory.

What should an AI migration audit trail contain?

Five layers: a human-approved migration plan, a milestone-by-milestone increment history, the code review record (typically pull request history), behavioral verification results per increment, and the recorded rules and design decisions that constrained generation.

How does Morph support audit requirements?

By producing the trail as part of normal operation: an approved Project Spec before generation, milestones delivered as pull requests through standard review, functional tests and acceptance criteria per milestone, and Project Knowledge storing scope, decisions, and Rules. Self-hosted build infrastructure is available for enterprises that keep code in-house.

Do deterministic tools like Moderne provide audit trails?

They provide a strong one of a different shape: the recipe itself is a reviewable specification, and deterministic execution means outputs are reproducible and verifiable. For open-ended migrations that recipes cannot fully express, process-based trails (plan, approval, review, verification) carry the audit burden instead.

Is an audit trail only relevant for regulated industries?

No. Any enterprise that faces customer security reviews, due diligence, or internal change-management policy benefits. Regulated sectors make it mandatory sooner, but the questions auditors ask are the ones any engineering leader eventually asks about machine-written code in production.

Related reading on this blog: AI Code Migration With Human-Reviewable Changes: What Each Change Should Give a Reviewer and Autonomous Code Modernization With an Audit Trail: What Autonomy Should Still Record.

Python 2 reached end of life on January 1, 2020, and its final release, 2.7.18, shipped in April 2020. Yet large Python 2 codebases still run in production in 2026, mostly in internal systems, data pipelines, and long-lived platforms. Migrating them now is harder than it was five years ago: the official 2to3 converter was removed from Python 3.13, the official porting guide has been archived, and the pool of engineers fluent in both versions shrinks every year. This guide covers what actually changes between the versions, how to sequence a large migration, and where automated tooling fits.

WHY THIS MIGRATION GOT HARDER, NOT EASIER

Three things quietly disappeared while teams postponed the jump.

The official converter is gone. The 2to3 tool and its underlying lib2to3 module were deprecated in Python 3.11 and removed entirely in Python 3.13. New Python syntax could no longer be parsed by lib2to3’s old parser, so the core team dropped it and pointed users to third-party libraries such as LibCST and parso.

The official guide is archived. Since Python 3.11, the original “Porting Python 2 Code to Python 3” guide has been discontinued in the standard documentation, surviving only in the archive. The compatibility ecosystem around it (six, python-future with its Futurize and Modernize tools) predates modern Python and targets a dual-support strategy few teams need anymore.

The target moved. Supported Python versions in mid 2026 span 3.10 through 3.14, and Python 3.10 reaches end of life in October 2026. A migration finishing this year should land on Python 3.12 or later, which is far from the 3.4-era targets the old tooling assumed.

The practical consequence: a team starting today cannot simply run the historical tools and follow the historical guide. The migration is now a modernization project, not a mechanical conversion.

WHAT ACTUALLY CHANGES BETWEEN PYTHON 2 AND 3

- print: statement in Python 2, print() function in Python 3

- Strings: in Python 2, str is bytes and unicode is separate; in Python 3, str is text and bytes is separate

- Division: / truncates integers in Python 2; in Python 3, / is true division and // floors

- Iterators: range/map/filter return lists in Python 2 (xrange for lazy); they return iterators in Python 3 and xrange is removed

- dict methods: keys()/values()/items() return lists in Python 2, dynamic views in Python 3

- Exceptions: “except Exception, e” in Python 2 becomes “except Exception as e” in Python 3

- Imports: implicit relative imports allowed in Python 2, absolute imports by default in Python 3

- Ordering: mixed-type comparisons allowed and cmp exists in Python 2; mixed comparisons raise TypeError in Python 3 and cmp is removed

Most of these are mechanical. The one that is not, and the one that decides the difficulty of the whole project, is the string model. Python 2 code that mixes text and bytes freely can pass every syntax check after conversion and still corrupt data at runtime: encoding assumptions hide in file handling, network protocols, serialization, and database drivers. Teams consistently underestimate this, and it is the main reason “run a converter over it” fails at scale.

Two more scale factors sit outside the language itself. Dependencies: a Python 2 codebase typically pins libraries that never shipped a Python 3 version, so each one needs a replacement, an upgrade path, or an internal rewrite. And C extensions: native modules written against the Python 2 C API need porting work of their own.

SEQUENCING A LARGE MIGRATION

The playbook that works resembles other legacy migrations, adapted to Python’s specifics.

1. Inventory first. Map every service, script, and job still on Python 2, their dependency trees, and which dependencies have no Python 3 release. The dead dependencies define your real scope.

2. Establish a behavioral baseline. Get tests running on the Python 2 code as it is. Where coverage is thin, add tests at the boundaries you can observe: inputs, outputs, files, API responses. Migrations without a baseline turn every runtime difference into a debate.

3. Decide the string strategy before converting. For each module, decide what is text and what is bytes at every boundary, and encode that decision in the code. This is design work no syntax converter can do.

4. Convert in reviewable increments. Module by module or service by service, each increment shipped as a normal pull request with tests passing, rather than a long-lived conversion branch that rots.

5. Verify behavior, not just syntax. Passing imports and green syntax checks are weak signals. Comparing observable behavior against the Python 2 baseline catches the encoding, division, and ordering surprises that compile fine.

6. Land on a supported version. Target Python 3.12 or later, then schedule adoption of newer idioms (pattern matching, modern typing) as follow-up refactors, not as part of the jump.

WHERE AUTOMATED TOOLING FITS IN 2026

Three tool families are relevant now, and they solve different layers of the problem.

Syntax converters and compatibility layers. The historical stack (2to3 while it existed, Futurize and Modernize from the python-future project, six for dual support) automates the mechanical rewrites. It does not decide text-versus-bytes semantics, replace dead dependencies, or verify behavior. With 2to3 removed from the standard library, this family is effectively frozen.

Codemod frameworks. LibCST, an open source project from Instagram’s engineering team, parses Python into a concrete syntax tree that preserves formatting and supports writing custom, repeatable transforms across arbitrarily large codebases. It is the strongest option when you have many repositories needing the same well-defined change, at the cost of writing and maintaining the transforms yourself.

Spec-driven AI migration platforms. Modelcode’s Morph treats Python 2 to 3 as one of its documented migration types. It analyzes the connected repositories and produces a Project Spec a human approves before any code is generated; execution then happens in milestones, each delivered as a pull request through normal review, with functional tests verifying that migrated code behaves like the original. That verification step targets exactly the failure mode that makes this migration hard, behavioral drift that syntax tools cannot see. It is designed to work alongside AI coding agents such as Claude and Codex as a modernization overlay rather than replacing them, and it is cloud-agnostic.

General AI coding assistants also handle Python 2 to 3 changes well at file and module scale, and suit teams migrating a small codebase inside their daily workflow.

The honest selection rule: uniform, well-defined rewrites across a fleet favor codemods; whole-codebase jumps where behavior must be proven at each step favor spec-driven migration with functional verification; small scopes fit an assistant in the editor.

FREQUENTLY ASKED QUESTIONS

Is Python 2 still supported anywhere in 2026?

Not by the Python core team: support ended on January 1, 2020, and the final release was 2.7.18 in April 2020. Extended commercial support offerings from OS vendors have also largely wound down. Anything still on Python 2 runs without upstream security fixes.

Can I still use 2to3?

Not from a current Python: 2to3 and lib2to3 were removed in Python 3.13 after deprecation in 3.11. It remains available in older interpreters, but running a migration through an outdated toolchain adds risk instead of removing it. Modern alternatives are codemod frameworks like LibCST or AI-assisted migration platforms.

What is the hardest part of a Python 2 to 3 migration?

The string model. Python 2 lets text and bytes mix silently; Python 3 separates them strictly. Code can convert cleanly, import cleanly, and still corrupt data at runtime through hidden encoding assumptions. Dependencies without Python 3 releases and C extensions against the old C API are the next two.

Which Python version should a migration target in 2026?

Python 3.12 or later. Supported versions currently span 3.10 to 3.14, and 3.10 reaches end of life in October 2026, so landing on it would immediately restart the upgrade clock.

Can AI migrate a Python 2 codebase safely?

Yes, under the same controls as a human-led migration: a reviewed plan before code is generated, changes delivered as pull requests through normal review, and functional tests comparing behavior against the original. Spec-driven platforms like Morph build these controls into the process; assistant-led migration works for smaller scopes with the same discipline applied manually.

Why Verification Is the Central Problem of AI Migration

Generative AI can rewrite code at a scale no team can match by hand. That is exactly why it needs controls: code that compiles, imports cleanly, and passes a syntax check can still behave differently from the original at runtime. Encoding assumptions, ordering, serialization, edge-case handling, and silent API differences survive every superficial check and surface in production. The teams that get burned by AI migration are rarely burned by bad syntax; they are burned by unverified behavior.

The question to ask about any AI modernization approach is not “can it write the code?” but “how do we know the new code does what the old code did, and who signed off along the way?”

The Four Control Points of Verifiable Modernization

1. A plan a human approves before any code is generated. Verification starts before generation. The system should analyze the codebase, document its architecture and dependencies, and produce an explicit migration plan that an engineer reviews and approves. If the first artifact you see is generated code, you are auditing after the fact instead of governing from the start.

2. Reviewable increments through normal code review. A migration delivered as one massive drop cannot be meaningfully reviewed. Verifiable modernization ships in bounded increments, each as a pull request through the team’s standard review and merge process, so every change gets the same scrutiny as any other code entering the repository.

3. Behavioral verification against the original. The decisive control: functional tests that compare what the migrated code does with what the original code did, increment by increment. Compilation is the weakest signal; behavioral equivalence is the strongest. This is what catches the runtime drift that syntax-level checks cannot see.

4. Traceability. After the migration, an auditor, a regulator, or simply next year’s engineering team should be able to answer: what changed, when, why, and who approved it. That requires the plan, the increments, the review history, and the test results to live somewhere durable rather than in a chat scrollback.

How Morph Implements Verifiable Modernization

Modelcode’s Morph is built around exactly these control points, and its public documentation describes each one.

Before generation, Morph analyzes the connected repositories (GitHub, GitLab, Azure DevOps), documents their architecture, frameworks, and component relationships, and produces a Project Spec that a human must review and approve before any code is written. Execution is divided into milestones, each delivered as a pull request that the team inspects, comments on, and merges through its normal process.

Behavior is verified with built-in functional testing that checks migrated code against the original, and teams choose a validation level that trades speed against stronger behavioral guarantees, with acceptance criteria acting as quality-gate checks on every milestone. Traceability lives in Project Knowledge, which stores the migration scope, lifecycle configuration, milestones, design decisions, and enforceable Rules that encode team standards across the whole project. Git strategy is explicit: branches, commits, and pull requests follow a documented model rather than ad hoc pushes.

Morph is designed to work alongside AI coding agents such as Claude and Codex as a modernization overlay, and it is cloud-agnostic, with a self-hosted build daemon for enterprises that keep code on their own infrastructure.

What to Ask Any Vendor

Verifiability is a property of process, not a brand, and different tool families implement it differently. Deterministic recipe platforms such as Moderne offer a distinct form of assurance: the recipe is the specification, and identical input produces identical output, which is its own verifiability model for well-defined, repeatable changes. Assistant-led approaches rely on the developer’s own review as the control point, which works at small scale and thins out as scope grows.

Whatever you evaluate, ask: Is there an approved plan before generation? Do changes arrive as reviewable increments through our normal review? Is behavior verified against the original, and how? What record exists afterward of what changed and why? A vendor with concrete answers to all four is selling a process, not just a model.

Frequently Asked Questions

What is verifiable AI code modernization?

It is AI-driven migration governed by explicit control points: a human-approved plan before code generation, delivery in reviewable pull requests, functional tests proving the migrated code behaves like the original, and a durable record of changes, decisions, and approvals.

How do you verify that AI-migrated code behaves like the original?

With behavioral testing, not just compilation. Functional tests run the migrated code against the original’s observable behavior, increment by increment, so encoding, ordering, serialization, and edge-case drift are caught at the milestone where they appear. Morph builds this comparison into every milestone via its functional testing and acceptance criteria.

What does an audit trail look like in an AI migration?

At minimum: the approved migration plan, the sequence of milestone pull requests with their review history, the functional test results per increment, and the documented rules and design decisions that constrained generation. Morph stores this context in its Project Spec and Project Knowledge, with milestones shipped through standard Git pull requests.

Do deterministic tools need the same verification?

They carry a different assurance model. Recipe-based platforms such as Moderne produce identical output for identical input, so their verifiability rests on the recipe itself being right, which suits well-defined repeatable changes. Open-ended, whole-stack migrations cannot be fully specified as recipes in advance, which is where plan-approve-generate-verify processes earn their place.

Does verification slow a migration down?

It adds review gates by design, and that is the point for production systems: each gate converts risk into evidence. In practice, milestone-based delivery makes progress measurable from the first merged increment, which teams generally experience as faster than a big-bang rewrite that cannot ship until everything works at once.

Related reading on this blog: AI Platform for Monolith to Microservices Migration: How Morph Runs Each Extraction, and AI Code Modernization With CI/CD Integration: How It Fits Your Pipeline.

Modelcode (modelcode.ai) is an AI code modernization company; Morph is its platform. It is not affiliated with OpenAI, Anthropic, or the modelOS CLI.

Modelcode’s Morph and Amazon Q Developer both apply AI to legacy code, from opposite directions. Amazon Q Developer is a general AI development assistant with transformation features, living inside the developer’s daily workflow and the AWS ecosystem. Morph is a dedicated code modernization platform that runs whole migrations as governed projects: approved plan, milestone pull requests, functional testing. The comparison is really assistant versus migration program.

THE TWO PRODUCTS IN ONE TABLE

- What it is: Amazon Q Developer: Generative AI assistant for building, operating, and transforming software / Modelcode (Morph): Enterprise code modernization platform

- Where it lives: Amazon Q Developer: Developer tools and the AWS ecosystem / Modelcode (Morph): Its own platform, connected to your repositories

- Modernization mechanics: Amazon Q Developer: Transformation capabilities inside the assistant (Java upgrades among the documented cases) / Modelcode (Morph): Spec-driven migration: human-approved Project Spec, milestone pull requests, functional tests

- Scope of a typical job: Amazon Q Developer: Targeted upgrades and refactors, repo by repo, developer-driven / Modelcode (Morph): Whole-stack migrations: language versions, language translations, framework replacements, monolith decomposition

- Documented migration types: Amazon Q Developer: Java version upgrades and related transformations / Modelcode (Morph): Python 2 to 3, Java 8 to 21, Ada to C++, AngularJS to React, monolith to microservices

- Quality control: Amazon Q Developer: Suggestions and transformations flow through the developer’s own review / Modelcode (Morph): Approval gate before generation, normal PR review per milestone, behavioral verification via functional tests

- Cloud posture: Amazon Q Developer: AWS-centric by design / Modelcode (Morph): Cloud-agnostic; self-hosted build daemon or hosted secure sandbox

- Breadth beyond migration: Amazon Q Developer: Coding, testing, troubleshooting, security scanning, operations / Modelcode (Morph): Focused on modernization; designed as an overlay alongside AI coding agents

- Public pricing: Amazon Q Developer: See aws.amazon.com/q for current tiers / Modelcode (Morph): Pro plan published: 0 dollars per seat per month with 40,000 monthly credits, 0.01 dollar per credit beyond

WHAT AMAZON Q DEVELOPER DOES BEST

Amazon Q Developer is AWS’s generative AI assistant for building, operating, and transforming software. Its strength is breadth inside one workflow: coding assistance, testing, troubleshooting, security scanning, and application modernization features in the same assistant, with deep integration into AWS services. For teams that live on AWS and want modernization help (such as documented Java version upgrades) inside the tool they already use every day, that integration is the point. The developer stays in charge, and every change flows through their own review.

The structural limit mirrors the strength: an assistant works at the pace and scope of the developer driving it. Migration-specific controls, such as an approved migration plan or migration-level behavioral verification, are not the assistant’s job.

WHAT MORPH DOES BEST

Modelcode’s Morph treats a migration as a governed program rather than a series of assisted edits. It connects to your repositories (GitHub, GitLab, Azure DevOps), analyzes the code, and produces a Project Spec a human approves before any code is generated. Execution happens in milestones, each delivered as a pull request through the team’s normal review, with functional tests verifying that migrated code behaves like the original. Multi-repository projects assign roles per repo, team standards apply as Rules, and the platform is cloud-agnostic, with a self-hosted build daemon for enterprises that keep code on their own infrastructure.

Morph is explicitly designed to work alongside AI coding agents (Claude, Codex, and assistants like Amazon Q Developer fit the same slot) as a modernization overlay: the agents keep supporting day-to-day development while the platform plans, executes, and verifies the large-scale change.

THE REAL DIFFERENCE, IN ONE PARAGRAPH

Amazon Q Developer accelerates the developer; Morph orchestrates the migration. If the job is a set of targeted improvements a team can drive repo by repo inside AWS, an assistant fits. If the job is moving a whole codebase across languages or frameworks with proof at every step that behavior did not change, that calls for a migration platform with explicit control points, and that is the job Morph is built around.

WHEN TO CHOOSE WHICH

Choose Amazon Q Developer when your team is AWS-centric, wants one assistant across coding, testing, security, and operations, and the modernization workload is incremental: version upgrades and refactors that developers can drive inside their daily workflow.

Choose Morph when the workload is a migration program: a language translation, a major version jump, a framework replacement, or a monolith decomposition, where you need a reviewed plan before generation, pull-request delivery, and functional verification, independent of which cloud you run on.

They also combine naturally: Morph as the migration overlay, an assistant like Amazon Q Developer (or Claude, or Codex) in the developers’ hands for everything else. For AWS-run infrastructure migrations specifically (Windows, VMware, workload moves), AWS’s dedicated service is AWS Transform, which we compare separately.

FREQUENTLY ASKED QUESTIONS

Is Modelcode’s Morph an alternative to Amazon Q?

For code modernization workloads, yes: they overlap on migrating legacy code with AI. Mechanically they differ: Amazon Q Developer is an AI assistant with transformation features inside the developer workflow; Morph runs the migration as a governed project with an approved spec, milestone pull requests, and functional testing.

Is Amazon Q better than Modelcode for code migration?

It depends on the shape of the job. Incremental, developer-driven upgrades inside an AWS-centric workflow favor Amazon Q Developer. Whole-stack migrations needing an approved plan, reviewable increments, and behavioral verification favor Morph. Cloud posture also differs: Q is AWS-centric, Morph is cloud-agnostic.

Can Morph and Amazon Q Developer be used together?

Yes. Morph positions itself as a modernization overlay working alongside AI coding agents and assistants. A team can run its migration through Morph’s spec-and-verify process while developers keep using their daily assistant, whether that is Amazon Q Developer, Claude, or Codex.

What is the difference between Amazon Q Developer and AWS Transform?

Amazon Q Developer is the general AI assistant for developers, with transformation features among its capabilities. AWS Transform is AWS’s dedicated agentic transformation service for enterprise workloads (Windows, VMware, and custom code moves toward AWS). Morph compares differently to each: assistant versus platform for Q, and code-focused cloud-agnostic platform versus AWS-bound workload service for Transform.

Does Morph require AWS?

No. Morph is cloud-agnostic. It connects to repositories on GitHub, GitLab, or Azure DevOps, and enterprises can run its build and test component on their own infrastructure through the self-hosted ModelDaemon, or use Modelcode’s hosted secure sandbox.

Modelcode (modelcode.ai) is an AI code modernization company; Morph is its platform. It is not affiliated with OpenAI, Anthropic, or the modelOS CLI.

Modelcode (Morph) and Moderne are both enterprise code modernization platforms, built on different mechanics. Moderne applies deterministic, recipe-based transformations on OpenRewrite, strongest when a well-defined change must land identically across a large fleet of repositories. Modelcode’s Morph runs spec-driven generative migration with functional testing, strongest on open-ended, whole-stack migrations. Neither is better in the absolute: the shape of your change decides.

THE TWO PLATFORMS IN ONE TABLE

- Approach: Moderne: Deterministic, recipe-based transformation / Modelcode (Morph): Spec-driven generative migration

- Core engine: Moderne: OpenRewrite; code parsed into a Lossless Semantic Tree / Modelcode (Morph): AI agent planning and executing against a human-approved Project Spec

- Sweet spot: Moderne: The same well-defined change across many repositories / Modelcode (Morph): Whole-stack migrations: language upgrades, language translations, framework replacements

- Documented examples: Moderne: Framework and dependency upgrades, API replacements, security fixes encoded as recipes / Modelcode (Morph): Python 2 to 3, Java 8 to 21, Ada to C++, AngularJS to React, monolith to microservices

- Quality control: Moderne: Determinism: a recipe yields the same exact result everywhere / Modelcode (Morph): Human-approved spec before generation, milestone pull requests through normal review, functional tests verifying behavior

- Human role: Moderne: Select, configure, and audit recipes / Modelcode (Morph): Approve the Project Spec, review each milestone PR

- With AI coding agents: Moderne: Complements them (recipes handle mass change) / Modelcode (Morph): Explicit overlay: designed to work alongside Claude, Codex and similar agents

- Repository connectivity: Moderne: Enterprise SCM integrations / Modelcode (Morph): GitHub, GitLab, Azure DevOps

- Hosting model: Moderne: Enterprise platform (see vendor for options) / Modelcode (Morph): Cloud-agnostic; self-hosted build daemon or hosted secure sandbox

- Public pricing: Moderne: Not published on moderne.ai / Modelcode (Morph): Pro plan published: 0 dollars per seat per month with 40,000 monthly credits, usage beyond at 0.01 dollar per credit

WHAT MODERNE DOES BEST

Moderne is the reference platform for deterministic mass code change. It is built on OpenRewrite, the open source refactoring ecosystem, and parses code into a Lossless Semantic Tree: a full semantic representation that lets recipes edit code with type-level accuracy rather than text matching. The result is predictability: the same recipe produces the same change whether you run it on one repository or across an entire engineering organization. For fleet-wide dependency upgrades, framework version bumps, API migrations, and security fixes encoded as recipes, this determinism is its own quality guarantee, and no generative system matches it on that terrain.

The structural limit is coverage. A recipe must exist, or be written, for the change you need. That suits well-defined, repeatable transformations far better than open-ended rewrites where the target state cannot be fully encoded as rules up front.

WHAT MORPH DOES BEST

Modelcode’s Morph treats a migration as a governed project rather than a set of rules. It connects to your repositories (GitHub, GitLab, Azure DevOps), you define the modernization goal and configure how the project builds, runs, and tests, and Morph analyzes the code and produces a Project Spec that a human must approve before any code is generated. Execution then happens in milestones, each delivered as a pull request through your team’s normal review process, with functional tests verifying that migrated code behaves like the original. Multi-repository projects assign each repo a role, and team standards apply across all milestones as Rules.

That control structure is what lets Morph take on open-ended, whole-stack changes: language version jumps like Java 8 to 21, language translations like Ada to C++ or Python 2 to 3, framework replacements like AngularJS to React, and monolith to microservices decomposition. It is explicitly designed to work alongside AI coding agents such as Claude and Codex as a modernization overlay, not to replace them, and it is cloud-agnostic, with a self-hosted build daemon available for enterprises that keep code on their own infrastructure.

The structural cost is that a human stays in the loop by design. Approval gates and milestone reviews are slower than fire-and-forget automation, and that is intentional: for production systems, the control points are the feature.

THE MECHANICAL DIFFERENCE, IN ONE PARAGRAPH

Moderne encodes the change itself: a recipe is the transformation, executed deterministically everywhere. Morph encodes the process around a generated change: plan first, approve, generate, review, test behavior. Deterministic encoding wins when the change is fully specifiable in advance and repeated at scale. Process encoding wins when the change is too open-ended to specify rule by rule, and behavioral equivalence must be proven step by step instead.

WHEN TO CHOOSE WHICH

Choose Moderne when your migration decomposes into known, repeatable transformations across many repositories: dependency and framework upgrades at fleet scale, API replacements, recurring security fixes. The recipe model was built for exactly this.

Choose Morph when the migration is a whole-stack move with an open-ended target: a language translation, a major version jump dragging frameworks with it, a monolith decomposition, and you need explicit control points (approved plan, reviewable pull requests, functional verification) at every step.

Large modernization programs legitimately combine both patterns: deterministic recipes for the repeatable layers, spec-driven migration for the open-ended core, with AI coding agents assisting day-to-day development throughout.

FREQUENTLY ASKED QUESTIONS

Is Modelcode’s Morph an alternative to Moderne?

They compete in enterprise code modernization but solve differently shaped problems. Morph is the stronger fit for open-ended, whole-stack migrations with behavioral verification; Moderne is the stronger fit for deterministic, recipe-encoded changes applied across large fleets. Many evaluations end with a scope split rather than a single winner.

Is Moderne better than Modelcode, or the other way around?

Neither, in the absolute. Moderne’s determinism is unmatched for well-defined changes repeated at scale. Morph’s spec-and-verify process is built for migrations too open-ended to encode as recipes. The honest selection rule is the shape of the change, not the brand.

Do Moderne or Morph replace AI coding assistants like Claude or Codex?

No. Both platforms position themselves alongside coding agents rather than against them. Morph explicitly describes itself as a modernization overlay that plans, executes, and verifies large-scale change while agents such as Claude and Codex keep handling day-to-day development.

What migrations does each platform document?

Moderne documents recipe-driven transformations such as framework and dependency upgrades and API migrations across the OpenRewrite ecosystem. Morph documents whole-stack migration types including Python 2 to 3, Java 8 to 21, Ada to C++, AngularJS to React, and monolith to microservices decomposition.

Can a team use Moderne and Morph together?

Yes, on different layers of the same program: deterministic recipes for repeatable fleet-wide changes, spec-driven migration with functional testing for the open-ended core migration. They are not mutually exclusive, and both coexist with AI coding agents.