4 ms·
I agree for method-level changes, but the more you’re willing to cede control for larger changes, even in a familiar language, the more an LLM accelerates you.
by lherron 1y ago
I agree for method-level changes, but the more you’re willing to cede control for larger changes, even in a familiar language, the more an LLM accelerates you.
For me, I give Gemini the full context of my repo, tell it the sweeping changes I want to make, and let it do the zero to one planning step. Then I modify (mostly prune) the output and let Cursor get to work.
- AdieuToLogic 1y ago> I agree for method-level changes, but the more you’re willing to cede control for larger changes, even in a familiar language, the more an LLM accelerates you. Another way to phrase this is: I agree for method-level changes, but the more you’re willing to cede *understanding* for larger changes, even in a familiar language, the more an LLM accelerates you *to an opaque change set*. Without understanding, the probability of a code generation tool introducing significant defects approaches 1.
- tsimionescu 1y ago> For me, I give Gemini the full context of my repo, tell it the sweeping changes I want to make If the full context of your repo (which I assume means more or less the entire git history of it, since that is what you usually need for sweeping changes) fits into Gemini's context window, you're working on a very small repo, and so your problems are easy to solve, and LLMs are ok at solving small easy problems. Wait till you get to more than some few thousand lines of code, and more than two years of Git history, and then see if this strategy still works well for you.