The Engineering Studio team manually updated some Java services, such as JDK, Spring Boot, and Gradle, to more recent stack versions earlier this year. We combined AI with OpenRewrite, an automated refactoring tool, to speed up this process, and the results were encouraging. As a result, we upgraded all of our repositories by systematizing the procedure and developing an AI-powered workflow.
Objective
At a high level, the goal of this project is to get all JVM services to follow a “golden path,” also referred to by other companies as a “paved road.” We use the term Golden Path and define it as a set of clear, opinionated standards designed to reduce complexity and ensure consistency across microservices and resources within an organization.
In practice, what this means right now is that services have to be on the following versions:
There are some other things involved in the Golden Path, like Galaxy, pre-commit, migrating to workbench etc., but we focused solely on application-level changes.
Part 1: Manual upgrades with OpenRewrite and AI
We started by using OpenRewrite, a refactoring tool, to automate as much of the upgrade process as possible. In our upgrades, OpenRewrite handled standard elements of the upgrades that had existing recipes. For example:
- Updating Gradle build files and dependency versions
- Migrating from javax to jakarta
- Refactoring code to use new methods from Java 21 and replacing deprecated ones
However, once the automated refactoring was done, we were still left with build errors, runtime issues, and deprecated code. That’s where AI agents came in. We used it to help us diagnose and fix post-upgrade errors, including deprecated methods, misconfigured Dockerfiles, JVM flags, and more.
Highlights
It was simple to use OpenRewrite. We were able to use all of the pre-existing recipes for the major updates without having to make any adjustments.
The AI agents were very helpful in troubleshooting and correcting construction difficulties. In addition to providing information on the appropriate replacement technique for obsolete methods, they were able to identify the root cause of build issues.
The subsequent service upgrade was considerably simpler after the initial one. Overall, the process was accelerated by weeks when OpenRewrite and AI agents were used.
Lowlights
One of the OpenRewrite recipes added a conflicting dependency that caused build failures. Tracking down the root cause was challenging and slowed us down. While the AI agents were good at providing debugging strategies, it wasn’t good at looking through the code and finding where the conflicting dependency was coming from.
There were also plenty of hallucinations. AI agents often detected deprecated methods but, when they didn’t, they would go in circles trying to fix the code.
The workflow
Thus, we demonstrated that Golden Path upgrades can be greatly accelerated by integrating OpenRewrite with AI agents. In order to further expand and expedite the renovations, the next step was to organize this procedure.
When planning and constructing the workflow, the objective was to have something that could be utilized for upcoming upgrades and migrations in addition to bringing all JVM services up to current Golden Path standards.
Approach
The first thing we did was create a YAML file structure that would serve as the foundation for the workflow. This would allow us to do a few key things to accomplish our goal
For the upgrades we are currently targeting, the steps look like this:
- Gradle 8, JDK 17 and Kotlin 2.1.20
- Spring Boot 3.x and Base Library 3
- JDK 21
- Debian Bookworm
- OpenTelemetry 1.33.6
Every single framework, library, dependency, etc. that is being upgraded is a component in these processes. For instance, Gradle 8, JDK 17, and Kotlin 2.1.20 are the three components of the first step mentioned above.
The OpenRewrite recipe (if any), whether the upgrade calls for AI to make modifications, and which prompt to utilize are all specified in the YAML file for each component.
Processing this configuration file is the first step in the workflow. The workflow will then use the OpenRewrite recipe and/or AI prompt to upgrade each component for each upgrade step. After a single step’s upgrades are finished, the workflow goes into a loop that deterministically determines whether there are build issues and, if so, employs AI to
Once there are no more build errors, a PR is created and the workflow moves on to the next upgrade step until everything has been successfully upgraded.
Challenges
The core challenge of this project was making a workflow that could consistently generate valid upgrade PRs across all of our repos. Getting the workflow to work on a single service was easy, getting it to work for hundreds was a different story.
This comes down to the fact that services vary in many, often unexpected, ways. Here are a few specific challenges we faced
- Breaking upgrades into smaller steps saves a lot of time. Smaller steps made it easier to improve prompting, debug issues, re-run the workflow in the case of errors, and deploy changes.
- Don’t over-rely on AI. Learn to love determinism. Being able to apply OpenRewrite recipes to start off allowed us to get to a very solid starting point for our upgrades. We only used AI to fill in the gaps. Also, having a separate and deterministic validation step made the workflow more reliable.
What’s next
Only a few repos have been upgraded thus far utilizing the method. We’ll keep making small-batch enhancements while improving the prompts to minimize the amount of manual labor needed to produce pull requests that are ready for production. We will then begin updating all of our JVM repositories. We will also look into ways to make the procedure usable for future migrations and upgrades, such as putting our Python repos on the Golden Path.
This is just the start of the process. There is a lot of potential to expand on this work and push the limits of automated large-scale code migrations because AI tools and models are getting better every day.
If you want to create innovative, AI-powered solutions, you won’t
