Google Ads has been using artificial intelligence (AI) to update its codebase, as detailed in a scientific paper by the Google Ads team. The paper outlines how AI was employed to tackle four major code migration tasks: transitioning from 32-bit to 64-bit IDs, updating from JUnit3 to version 4, changing the time format from Joda to java.time, and cleaning up unused sample code across repositories. These tasks resulted in a time and effort saving of about fifty percent, although the pure code advantage was higher, offset by increased verification efforts.
Google Ads’ code repositories contain over 500 million lines of code, which the team needed to update. They utilized a tailored version of the Gemini AI model, which was trained on Google’s repositories to make changes across all sources. A significant challenge was the high variability in the code sections that needed modification.
In addition to AI, traditional methods such as Abstract Syntax Trees (AST), heuristics, and regular expression searches were employed. ASTs primarily helped identify the areas that needed changes, which the AI then executed. Human review was conducted as with any code change. Prompting rules included general task instructions and more specific sub-steps, which were interchangeable depending on the application. The team found it helpful to ask the AI which of its suggestions was the best.
The transition from 32-bit to 64-bit IDs involved “tens of thousands of locations” including all class interfaces. These IDs, used for users, merchants, and campaigns, were often stored as integers or even as text in C++ or Java. ASTs compiled the relevant files, and the AI made the changes. The AI was only applied to code sections that could be verified by unit tests, which the team adjusted accordingly. Human reviewers approved eighty percent of the AI-modified sections as correct. Errors typically involved the AI making excessive changes.
A prompt example for the AI was:
{id} should be of type int64_t.
Update the tests to reflect a large id.
Initialize the {id}s with values larger than 10000000000.
If necessary add new test parameters with large ids.
If previous id was negative, new value should be negative.
This instructed the AI to adjust only the class constructor where the type needed changing. The AI correctly modified the private field and usage within the class. Images accompanying the paper showed the correct changes in the diff and test files.
Similar experiences were noted in other projects. The transition from the old Joda library to the java.time package was complicated because not all types are comparable, like the lack of a java.time.Interval equivalent in the standard Java time API. This required logical changes in the function. The authors admitted that “the migration is ongoing and we face challenges in resolving it”.
The paper concludes that the best migration path combines old and new methods. “We found that the planning capabilities of LLMs were unnecessary and added a level of complexity that should be avoided if possible.” ASTs are always correct and suitable for verifying changed code. The team recommends using small, tailored models, which “increase the reliability of results and reduce debugging effort”. Human review can become a bottleneck as specialists are required. Better tools, possibly agents, could mitigate this in the future, though the paper does not elaborate further.
The paper also notes: “Whether this will have a long-term impact on quality needs to be observed.” Overall, Google plans to further expand AI-driven migration in the Ads area.