Project Maintenance with AI Assistance
How I used AI to help find ways to improve the health of a long-running project
I was recently inspired by some comments from my co-worker (shout out Chris Jones) to use AI to help find things to improve for a project I was working on. I gave it a shot, saw good results, and thought others could benefit.
Background #
At Viget, we have a Ruby on Rails app that we built 10+ years ago that we continue to support. It quite regularly gets new features along with annual upgrades and the general maintenance work that goes with supporting a long-running app. The problem is that because we have been working on this app for so long, it has shifted hands between developers numerous times and it does so much at this point that it is hard for any one person to completely understand everything about it. With that being the case, over the years, I was sure that there were probably some things in this app slipping through the cracks that could use improvement. Either that or there were parts of the codebase that were just dead code that we had long since forgotten about.
Then, in our dev team's daily standup, Chris mentioned having Claude and Knip look over a project he was working on for potential improvements. I thought that was a great idea and decided something like this would be perfect for my project as well.
Querying the AI #
In order to get this done, I pulled up this large Rails app in my Cursor IDE, opened up the secondary side bar where I communicate with the agent, switched to plan mode and the Claude Opus 4.8 model, using Extra High effort and 1M context size, and gave it the following prompt:
Can you look over this app and come up with a list of suggestions for how we could improve this app? These could be things like plugging security gaps, things that could be refactored, or dead code that is not used anymore and can be removed. Do not suggest anything that would change the functionality presented to users or what the app looks like. Also, can you present this in a way that I can easily turn your suggestions into GitHub issues
This worked exactly as I needed it to. It spit out a list that included five small security gaps we could plug, eight instances of dead code we could remove, six places we could update dependencies and improve tooling, and ten places that could use some potential refactoring. Along with that, the agent spit out a list of five other places to investigate if any potential work needed to be done.
Also, the agent provided this list entirely in Markdown and already formatted well for just copying directly into GitHub. Here is an example of one of the dead code issues that it spit out:
### DEAD-5 - Remove orphaned CampaignPromoComponent and advocacy modal
- **Labels:** `cleanup`
- **Problem:** `app/components/campaign_promo_component.rb` + `app/views/shared/components/_campaign_promo.html.erb` are only referenced by their own spec (no CMS block type / `render_component`). The advocacy modal (`app/views/shared/_advocacy_modal.html.erb` + `advocacy-modal.js`) is never rendered anywhere.
- **Proposed change:** Confirm no CMS `content_blocks` reference `:campaign_promo` in the DB, then remove the component, partial, spec, and orphaned advocacy modal files.
- **Acceptance criteria:** Grep + CMS block-type registry confirm no references; specs pass.
- **Behavioral impact:** None (verify CMS content first).Following Up #
I reviewed each of the issues Claude provided and, aside from a couple, decided they were worth doing. I copied the markdown for each into a GitHub issue description, opened the issues, and flagged them as maintenance. (While Claude does have the ability to create GitHub issues for you, I decided this was simple enough to just quickly do myself while I reviewed them.) Then, I ran them by the project managers and got permission to move forward whenever time was available.
After receiving that permission, we had a solid backlog of fairly small tickets the other dev on the project and I could tackle whenever we had some free time between new features and other projects.
Conclusion #
Overall, I think this little experiment was a win. It helped keep another dev and me busy while also getting our project into a much healthier place. Due to potential diminishing returns, I do not think I will need to run this back all the time, but I do think it should be part of my annual process for this and any other long-running support projects I end up working on in the future.
