Google Patents an AI System That Edits, Reviews, and Fixes Code on Its Own
Google has filed a patent for an AI system that doesn't just suggest code, it can edit it, predict what a human reviewer would say about it, resolve those review comments, fix broken builds, and even guess what errors a piece of code will cause before it runs.
What Google's AI code-editor actually does
Every time a programmer pushes new code to a shared project, a chain of events kicks off: automated tests run, reviewers leave comments, builds either succeed or fail, and someone has to fix what breaks. That cycle can eat hours or days.
Google's patent describes a single AI model designed to handle several of those steps automatically. Feed it some code and a task ("predict what the reviewer will say" or "fix this broken build"), and it returns the answer in structured form that software tools can act on directly.
The system works across all of those jobs using one common approach: it turns both the code and the task description into a shared list of tokens (think of tokens as word-chunks the AI can read), processes them together, and produces an output in a tidy internal language that maps neatly onto real code changes.
… processing an input sequence comprising the first sequence of text tokens and the second sequence of text tokens using a language model neural network to generate, as output, an output sequence of text tokens in a domain specific language …
Translation: An artificial intelligence neural network processes the code and tasks to generate solutions.
How the language model reads tasks and rewrites code
The patent covers a method that routes several classic software-development chores through a single language model neural network (the same kind of AI that powers text generation tools like Gemini or GPT).
The supported tasks include:
- Code editing: predicting what changes a developer is likely to make next
- Review comment prediction: guessing what feedback a human code reviewer would leave
- Comment resolution: automatically editing code to satisfy a reviewer's comment
- Build repair: figuring out what changes will fix a broken compile or test run
- Build error prediction: forecasting what errors will occur before the code even runs
The key technical move is a domain-specific language (DSL), a compact internal format for describing code edits. Instead of producing raw code directly, the model outputs instructions in this DSL (think of it like a recipe card for code changes), which a separate layer then converts into actual file edits.
The input is structured as two token sequences: one describing the task, one representing the code itself. Both are fed together into the model, which generates the DSL output. This unified representation means the same model weights can handle all five task types without training a separate model for each.
… predict edits that will repair a given code build, or to predict build errors that will result from compiling a piece of computer code …
Translation: The system can automatically fix broken code builds and predict compilation errors.
What this means for AI-assisted software development
For software teams, the most expensive part of shipping code often isn't writing it, it's the back-and-forth of review, fixing broken builds, and chasing down errors. A system that can predict reviewer objections before a human sees the code, or automatically repair a failed build, could cut that cycle significantly.
Google's run of AI-assisted developer-tooling filings fits a clear pattern: the company wants AI embedded at every step of the coding workflow, not just at the "write some code" step. If this approach reaches production tools (like Google's internal developer infrastructure or a future Gemini Code Assist feature), it would mean AI acting more like a full junior developer than an autocomplete engine.
Google's 31st filing we've tracked since May in AI agents acting for you, after visual search recommending apps and tap-to-identify screen buttons, pushes further into software that reads and acts on your screen.
Google's idea here lives entirely in software, which means the main ingredients already exist: a language model, a coding tool, and a set of rules for turning the model's output into automatic edits rather than suggestions a human still has to type in manually.
The shortest path to a real product is plugging this into an existing coding assistant. The clever piece is that structured rule layer, because without it an AI can tell a developer what to change but cannot actually change it. With it, the assistant becomes something closer to a co-pilot that acts.
The gap between filing and feature is reliability. Predicting whether a code review will flag a problem, or whether a build will fail before you run it, only earns developer trust if it is right most of the time, and the document makes no promises about accuracy. That is the empirical work left to do.
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
5 drawing sheets from US 2026/0259729 A1 · click any drawing to enlarge
Want this weekly breakdown for a company we don't cover? Patentlyze Pro →