Every AI assisted code change creates more work than expected. But “Recovery” is the wrong descriptor
My workflow, which one could also call “change handing” on my main project which is about 370K lines of code is as follows. All my “Changes” usually consist of several hundred lines of code, new and deleted lines are totalled and displayed by Cursor IDE. For Design enhancements of course the line count is in the thousands.
For complex real time designs where milliseconds count, I now find prototyping dry run simulations to be more effective than assuming expectations of success right out of the gate for any design enhancement or change I am implementing.
Procedurally, each Cursor thread has multiple Cursor plans that consist of slices, most plans are are around 7 slices, that is the target. Each slice is a block of work that may or may not be code, research, or acceptance level testing, but if code ends with a github commit, that is rust compiled for validity before the commit.
The Cursor plans document the design chainin, the per slice Github commit messages explicitly detail the work encompassed in the code changes for that slice.
The cursor thread, depending on the model is either as short lived or as long lived as possible depending on LLM context handling and expenses. Models prefer to search Github commit messages for detailed change summary, rather than the thread, which becomes very cluttered over time.
My root assumption for complexity smoothing is how many ways can this fail? Do not expect 100% success first try. Collect detailed telemetry at every critical logic gate, analyze it, then re-wire up something that’s been the lesson learned via telemetry. The telemetry range from 3 to 21 days in depth depending on disk space consuption.
For historical back tracking of significant design or change failures identified as route cause, frequent Github commits, with verbose messages, leaves a very usable history, making many Git Commits per thread is best practice. I only consider up thread reverts beyond 2 prompts on very rare occaisions. If you are that far off track the design is wrong, or you are not paying attention.
The BIG Cursor short coming I will one day post a bug report about is Cursor Plan handling. Plans are kept out of the project hierarchy, and the same plan is hard to reach for reviews by other LLM models, before execution. Nor can plans easily be integrated in ./cursor/ as design path documentation – This is a Cursor design flaw.