Google Patents a Two-AI System That Checks Its Own Code Translation Work
Getting an AI to rewrite your code is one thing. Getting it to check whether its own rewrite is correct is another. Google's latest patent does both by pitting two AI models against each other.
What Google's prompt-optimizing code migrator actually does
Ever tried to convert a massive old document into a new format, only to find the automated tool mangled half of it? That's what happens when companies try to move millions of lines of code from one programming language or framework to another using AI.
Google's patent describes a fix: instead of asking one AI to do the conversion and hoping for the best, the system uses two AI models in sequence. The first model's only job is to write better instructions for the second model, the one that actually rewrites the code. It produces several versions of those instructions at once, so the second AI tries the migration multiple ways.
Each attempt comes back with a score showing how many predicted errors it contains. The system picks the attempt with the fewest errors and delivers that version to the developer. It's a feedback loop, baked directly into the process, so the output you get has already been through a self-sorting round of quality checks.
… providing a prompt associated with the user query as an input to a first artificial intelligence (AI) model, wherein the first AI model is trained to generate optimized prompts for a second AI model to perform code migration operations …
Translation: The system feeds user requests into a first AI that creates better instructions for a second AI.
How the two-model loop scores and picks the best migration
The patent describes a pipeline where a developer sends a request to migrate source code, say, converting a codebase from one language or API version to another. That request goes to a first AI model whose sole purpose is generating optimized instructions (prompts) for a second AI model that performs the actual code rewriting.
The first model doesn't produce just one set of instructions. It generates multiple candidate prompts, each a slightly different way of telling the second model how to approach the migration. The second model then runs the migration once per candidate prompt, producing a separate rewritten codebase for each.
Critically, each migration attempt also produces a predicted validation error count: an estimate of how many things are likely broken or incorrect in that version of the rewritten code. The system compares those counts across all the candidates and selects the migrated version tied to the lowest predicted error count, labeling both that version and its corresponding prompt as "optimized."
The winning rewrite goes back to the developer. The architecture is essentially a meta-learning loop: one AI learns to write better instructions for another AI, and the whole system is graded on how clean the output code turns out to be.
The system selects an optimized migrated version associated with a prompt upon determining that a migrated version has a lowest number of predicted validation errors.
Translation: It picks the translated code option that is expected to have the fewest bugs.
What this means for developers facing large legacy code rewrites
Large-scale code migration is one of the most expensive and error-prone tasks in software engineering. Moving a production system from one framework or language to another can take teams months, and subtle bugs introduced during conversion can be invisible until something fails in production. A system that automatically generates, tests, and ranks multiple migration attempts before handing anything to a developer could meaningfully shorten that process.
Google's consistent investment in AI-assisted developer tooling suggests this isn't an isolated experiment. If the predicted-error scoring is accurate enough to act as a reliable proxy for real test results, developers could stop treating AI-generated code migrations as drafts that need heavy manual review, and start treating them as auditable first passes.
This is the 18th Google filing we've tracked since May in our AI models working in teams watchlist, after one on autonomous ad building and AI grading its own image drafts.
The system bets everything on predicted error counts before anyone actually runs the code. That prediction has to be reliable, because if it misses the quieter failures, code that runs fine but does the wrong thing, the whole selection process optimizes for the appearance of quality rather than quality itself.
That gap between predicting problems and finding them is the real cost of the design. A developer receiving the "optimized" output still needs to treat it as a strong draft, not a finished answer.
Even so, the trade reads as worth it. Moving large codebases between programming languages is slow and expensive work, and a system that generates multiple versions, scores them, and surfaces the best one reduces how much a human has to dig through on their own. The error prediction doesn't have to be perfect to earn its place; it just has to be better than no filter at all, and at scale, even a rough one usually is.
There are more where this came from
We read every patent application Big Tech publishes and send you the ones worth knowing. Plain English, free, every week.
The drawings
3 drawing sheets from US 2026/0267636 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →