4 ms·
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 wan
by exe34 2y ago
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.
- lherron 2y agoI 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 2y 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 2y 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.
- jimbokun 2y agoI 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?
- bluefirebrand 2y ago> If you already speak the programming language fluently, why do you need a translator? And if you don't speak the language please spare us from your LLM generated vibe coding nonsense
- tsimionescu 2y agoThe 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.
- otabdeveloper4 2y ago> spin the LLM wheel until you get lucky with something that works Isn't that exactly what "vibe coding" is supposed to be? (BRB, injecting code vulnerabilities into my state actor LLM.)
- bluefirebrand 2y ago> The only way to learn a programming language (beyond the basics) is to use it I don't quite agree. This may seem like splitting hairs, but I think the only way to learn a programming language is to write it I don't think any amount of reading and fixing LLM code is sufficient to learn how to code yourself Writing code from scratch is a different skill
- deleted 2y ago[deleted]