same, the amount of work I have to put into thinking of what to say to the llm is the same or more work than just telling the compiler or interpreter what I want (in a language I'm familiar with), and the actual coding is the trivial part. in fact I get instant feedback with the code, which helps change my thinking. with the llm, there's an awkward translating for the llm, getting the code, checking that it might do what I want, and then still having to run it and find the bugs.
the balance only shifts with a language/framework I'm not familiar with.
I think it’s useful to think of LLMs performing translation from natural language to a program language. If you already speak the programming language fluently, why do you need a translator?
The only way to learn a programming language (beyond the basics) is to use it and gain familiarity, and see code that others wrote for it. Assuming you don't just spin the LLM wheel until you get lucky with something that works, it's a valid strategy for learning a language while also producing working (though imperfect) code.
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.
> 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.
> 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.
the balance only shifts with a language/framework I'm not familiar with.