Fast Apply definitely helps with keeping flow state and is a large part of Cursor's success
Personally I work on multiple repos at a time to solve for this
back
1 comments
I do it like simultaneous exhibition in chess:
- Multiple repos or independent changes in monorepo
- First round of changes idgaf about anything beyond public interface and unit tests
- I review public interface and make changes if needed
- I review unit tests it wrote to see that at least from the outside it looks alright.
- here I either:
- make more unit tests (features, edge cases and make it write code for it)
- polish what it generatesounds like flow state to me
oh it's fore sure is. But I use amazon q almost exclusively. One thing that gets me out of this state: when I have to do the math on "should I just do it myself" vs "keep refining prompt/context until this thing finally gets it right".
so frustrating how slow edits are in Q dev
Sometimes it splits edits to a single file into way to many fs_write(s) and often get stuck not being able to apply edits. It also so conservative with using your machine resources: kept trying to run test suit with a single worker, like come on, I paid for 32 cores, I will be using 32 cores.