i used cursor to refactor my entire unity project codebase and it found scripts i had completely forgotten existed
My Unity RPG project had been active for eleven months. I had 67 scripts. Some were from month one when I was a worse developer than I am now. Some were half finished experiments I had left in. Some referenced other scripts that no longer existed. I spent one weekend using Cursor to do a full codebase cleanup and refactor. It found problems I did not know I had and cleaned up months of accumulated technical debt in two days. Here is the complete honest account.
Priya Nair
June 26, 2026
State of the project going in: 67 C# scripts, 11 months of development, 3 different naming conventions mixed across the project from different months of development, at least 8 scripts I suspected were unused, several deprecated Unity API calls I knew existed but had not tracked down, and a folder structure that had grown organically without planning. State coming out: 51 scripts, one consistent naming convention, no deprecated API calls, and a folder structure that a new developer could navigate. Two days. One weekend.
Why I Finally Decided to Do This
Two things happened in the same week. I spent 45 minutes looking for a script I was certain I had written for handling item drops, searching through the project by name and not finding it, and eventually discovering it was in a subfolder called OldStuff that I had stopped checking months ago. Three days later Cursor suggested a method completion that used a deprecated rb.velocity call from Unity 2021. Both events pointed to the same problem. My codebase had grown faster than my organization of it. Technical debt had accumulated to the point where it was costing me more time per week than a cleanup weekend would cost me to fix.
Day 1 Morning: Finding Everything That Was Wrong
- First Cursor query: find every deprecated Unity API call in this project. Cursor searched across all 67 scripts and found 12 instances. FindObjectOfType, rb.velocity used instead of rb.linearVelocity, Camera.main in Update loops, and three uses of OnGUI which I had forgotten about entirely from a debug UI I built in month two.
- Second Cursor query: find every script that has no references from any other script in this project. Cursor identified 9 scripts with zero references from other code. I checked each one. Five were genuinely unused experimental scripts from early development. Three were utility scripts that were used via Unity component attachment rather than code reference and should be kept. One was a duplicate of an existing script with a slightly different name.
- Third Cursor query: find every TODO comment across the project. Found 23. Read through them. Six were genuine incomplete implementations I needed to finish. Eleven were notes to myself that had been superseded by later decisions. Six were notes about things I had already fixed but not removed the comment for.
- Fourth Cursor query: find every place where I am using magic numbers instead of named constants or SerializedFields. Found 34 instances. Made a list.
Day 1 Afternoon: The Fixes
- Deprecated API fixes: Cursor replaced all 12 deprecated calls with current Unity 6 equivalents in one Composer operation. I reviewed the plan, approved it, and ran the project. Compiled cleanly. Tested the affected systems. All working.
- Unused script deletions: Deleted the 5 genuinely unused scripts. Unity flagged no missing references after deletion confirming they were genuinely unused.
- Naming convention standardization: My early scripts used camelCase for public fields. My later scripts used PascalCase for serialized public fields following Unity 6 conventions. Cursor renamed 47 public fields across 23 scripts to PascalCase in one Composer operation. I reviewed the changes in the diff view, approved, and resolved the two resulting compile errors where I had missed a reference update.
- Magic number elimination: Cursor converted 34 magic number instances to SerializedField declarations with descriptive names. Three hours of work in 20 minutes of Composer operation plus review.
Day 2: Folder Structure and the Forgotten Scripts
- The OldStuff folder: I had 11 scripts in a folder called OldStuff. I asked Cursor to summarize what each script did. Six were genuinely old versions of scripts that had been superseded by newer versions and should be deleted. Three were experiments that I had abandoned but that contained implementation ideas I wanted to keep. Two were actually useful scripts I had placed there by mistake. The item drop script I could not find was in OldStuff. It was not old. I had moved it there in a file organization session six months ago and completely forgotten.
- Folder reorganization: Moved scripts into a logical folder hierarchy: Systems, Controllers, UI, Managers, Data, Utilities. Cursor helped me identify which category each script belonged to by reading each script and describing its primary responsibility. The reorganization took most of day 2.
- Documentation comments: For the 16 most complex scripts I asked Cursor to add XML documentation comments to all public methods. The comments describe what each method does, what its parameters are, and what it returns. This would have taken me two hours per script to write manually. Cursor wrote them for all 16 scripts in 40 minutes.
What Surprised Me Most
The script I had forgotten about in OldStuff was not the biggest surprise. The biggest surprise was a script called UIHelper.cs that contained 340 lines of utility methods for UI operations that I had apparently written in month three and never referenced from anywhere. Looking at the code I recognized patterns I had later re-implemented in other scripts because I had forgotten UIHelper existed. I had written the same string formatting utility three times in three different scripts because I did not remember writing it the first time. Cursor found UIHelper.cs in its unused script scan. I consolidated the three scattered implementations into UIHelper and referenced it properly. The codebase got smaller and the functionality got cleaner.
Mistakes I Made During the Refactor
- Not making a Git commit before each major Composer operation: I made one large Git commit before starting day 1. When the naming convention Composer operation produced two compile errors I wanted to roll back just that operation rather than the whole day. Lesson: commit before every significant Cursor Composer change.
- Approving a Composer plan without reading the full diff: One naming convention change renamed a property that was referenced in a Unity Inspector serialization. The rename broke the Inspector connection and the serialized values reset to defaults. I caught it in testing but it would have been caught in the diff review if I had read the full plan.
- Trying to reorganize the folder structure and fix code issues simultaneously: Mixing two types of changes produced a confusing diff that was hard to review. Separated the changes into code fixes on day 1 and folder reorganization on day 2. Much cleaner.
Final Thoughts
Two days and 16 fewer scripts. No deprecated API calls. Consistent naming conventions. A folder structure I can navigate. Documentation on the complex scripts. The UIHelper discovery alone saved me from future instances of reimplementing my own utilities a fourth time. Before this weekend I was spending 30 to 45 minutes per session navigating technical debt. The cleanup investment is paying back at roughly 6 hours per week in recovered time based on the first month after the refactor.