|
So there's a wrong way and a right way to code with LLMs. The wrong way is to ask the LLM to write a bunch of code you don't understand, and to keep asking it to write more and more code to fix the problems each iteration has. That will lead to a massive tower built on sand, where everything is brittle and collapses at the slightest gust of wind. The right way is to have it autocomplete a few lines at a time for you. You avoid writing all the boilerplate, you don't need to look up APIs, you get to write lines in a tenth of the time it would normally take, but you still have all the context of what's happening where. If there's a bug, you don't need to ask the LLM to fix it, you just go and look, you spot it, and you fix it yourself, because it's usually something dumb. The second way wins because you don't let the LLM make grand architectural choices, and all the bugs are contained in low-level code, which is generally easy to fix if the functions, their inputs, and their outputs are sane. I like programming as much as the next person, but I'm really not lamenting the fact that I don't have to be looking up parameters or exact function names any more. Especially something like Cursor makes this much easier, because it can autocomplete as you type, rather than in a disconnected "here's a diff you won't even read" way. |
Then you got into code boilerplate, and if you find yourself doing this a lot, that's a signal to start refactoring, add some snippets to your editor (error handling in go), write some code generators, or lament the fact that your language can't do metaprogramming.
> but I'm really not lamenting the fact that I don't have to be looking up parameters or exact function names any more.
That's a reckless attitude to have, especially if the function have drastic behavior switch like mutating argument or returning a fresh copy. All you do is assume that it behaves in certain way while the docs you haven't read will have the related warning label.