Google Uses Gemini 4 Argon to Refactor Chromium and Its Millions of Lines of Code

Google DeepMind has published a video about how the Chromium team uses the Gemini 4 Argon model to maintain one of the heaviest codebases in open source. The raw numbers are modest: "millions of lines" and "decades" of history. The material gives no precise figures, such as the number of merged changes, the share of accepted patches, or the person-hours saved. It does describe the workflow well, though, and that workflow is more interesting than the model itself.

What exactly Gemini 4 Argon does in Chromium

According to DeepMind, Chromium is built in such a way that working with it means navigating a maze of tangled features. Touch one component, and another one unexpectedly breaks. Eric Chen, a Google engineer, uses Gemini 4 Argon to "untangle" the architecture. In other words, this is refactoring: the code changes structure, but its behavior stays the same.

The key detail is that several agents work on the code at once, each independently of the others. This differs fundamentally from the familiar scenario in which an assistant suggests edits in a single file and a human assembles the result by hand. Here the task is split into pieces, and each agent takes its own.

How quality is controlled

The main question for any AI refactoring in a large codebase is who guarantees that nothing is broken. DeepMind names two layers of protection:

• Chromium's test suites, which the agents' changes must pass;
• code review by Chromium engineers.

In other words, automation does not replace the project's established process. The agent acts as the author of a patch, and verification stays the same. For a codebase of this age, that is a sensible position: the browser has huge test coverage, and that coverage is what makes large-scale refactoring feasible.

What the material tells us

• Model: Gemini 4 Argon; Google put the details in a separate blog post.
• Target: the Chromium codebase, with millions of lines and decades of history.
• Executors: several agents working independently.
• Verification: Chromium tests and engineer review.
• Stated goal: free Eric Chen's team to work on the future of Chromium.
• Not disclosed: the volume of changes, the percentage of rejected patches, the cost of the runs, the number of bugs caught by tests.

How to read this case

The material comes from DeepMind itself. It is a showcase of the model's capabilities, not an independent audit. The claim that "agents maintain the codebase" is so far backed only by a description of the process. The numbers will show the real value: how many changes reached the main branch, and how much time reviewers spend checking agent patches compared with human ones. Review is a resource too, and if a flood of machine-generated patches overloads it, the gain disappears.

That said, the chosen task is a good one. Refactoring is easy to formalize, tests can verify the result, and the value grows with scale. Agentic programming looks most plausible on exactly this kind of work, which engineers put off for years.

Practical takeaways for teams

If you have a large legacy project, take the workflow from the Chromium case, not the model name. First, make sure your test coverage is good enough to trust a green build. Then split the refactoring into independent tasks so agents don't fight over the same files. Keep human review as a mandatory step, and collect metrics on accepted and rejected patches from day one. Without them, you cannot tell whether the agent saves time or simply shifts the load onto reviewers.