Making major updates trivial with the right context

It’s been reported that software engineers spend roughly 22% of their time maintaining existing code. This includes keeping up with the latest releases of code libraries that have been included in their application. If the library’s release process adheres to the semantic versioning specification, minor and patch releases are guaranteed to be backward compatible and therefore trivial to implement. On the contrary, major releases may include backward-incompatible API changes that could break existing code, resulting in more time dedicated to code refactoring.

Using an AI code assistant for code refactoring provides many benefits. But when you’re upgrading to a new major version of a library, it’s not as straightforward. New releases for many libraries are released almost every day. It’s practically guaranteed that the newest major version you’re dealing with will have been released after an LLM’s knowledge cutoff date — the specific date up to which an LLM was trained on data, and therefore the limit of its knowledge about current events or updates. As of this post, Claude 3.5 Sonnet was last updated in April 2024, and GPT-4o in June 2024. Without knowing the details of any major release changes since that time, the LLM may struggle to provide accurate updates. 

Here’s how you can help guide the code assistant and fill in any gaps in its knowledge.

Be specific in the prompt

Remove as much guesswork as possible. Specify which library you wish to upgrade and include the current version and desired version:

I am upgrading from {library} X.X.X to version Y.Y.Y. Apply these changes.

If the library version was released before the model’s knowledge cutoff date, you’ll likely see all the necessary changes. If not, you might see a partial change and an explanation about potential breaking changes.

Give notes

If the LLM you’re using was updated before the major version release, you can add notes to the prompt to help fill in the gaps. Good libraries provide a detailed changelog for each release including how to handle breaking changes. Many of these libraries will also provide a migration guide. You can copy/paste either of these into the prompt to provide more context to the LLM.

I am upgrading from {library} X.X.X to version Y.Y.Y. Here are the release notes for the changes. Apply these changes.

[…pasted change notes or migration guide]

This should result in more accurate and complete changes that you can review and apply.

Ask questions and give feedback

While reviewing the suggested changes, continue the conversation by asking any questions and providing feedback as necessary. Ask for places where updates need to be made. Ask clarifying questions about the provided code. Apply the code when you feel comfortable and verify that all the tests are still passing.

Example: Upgrading from Conform 0.9.2 to 1.2.2

The following example is based on a LinkedIn post I made after upgrading Conform on a personal project. Conform is a type-safe form validation library utilizing web fundamentals to progressively enhance HTML Forms with full support for server frameworks like Remix and Next.js. For this example, I’ll use the provided Remix application example on the v0 branch.

Before starting, I was very aware of all the API changes going into the v1 release of Conform. Every place the library was used would need to be refactored. In addition to a detailed changelog, a migration guide was also provided. Using this information, I provided the following prompt to the Tabnine chat using Claude 3.5 Sonnet:

I am upgrading from Conform 0.9.2 to 1.2.2. Use the following migration guide to apply these changes.
[…pasted migration guide contents]

This resulted in the changes required for the three pages that use Conform, along with a summary of the changes made to each page. Here’s an example of the changes made to the login page:

1. Renamed lastSubmission to lastResult in the useForm hook.
2. Updated the import for parseWithZod from @conform-to/zod.
3. Added the required type option to all getInputProps calls.

After reviewing and applying all the changes, I tested it in the browser, and that was it. I completed what originally felt like a daunting task in a fraction of the time.

Is it time to make the move to the next major version of a library in your codebase? Perhaps now with a little added context, Tabnine can do the refactoring for you and get you back to writing new code.

Not yet a Tabnine user? Try Tabnine Dev free for 30 days.