Hacker News Reader

Comment by exe34 | Hacker News Reader

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.

View on HN

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?

> 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

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.

> 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.)

> 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

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.

> 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.

> 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.

Reply on news.ycombinator.com