Hacker News Reader

Comment by ramesh31 | Hacker News Reader

>LLM agents make bad pairs because they code faster than humans think

This is why I strongly dislike all of the terminal based tools and PR based stuff. If you're left to read through a completed chunk of code it is just overwhelming and your cycle time is too slow. The key to productivity is using an IDE based tool that shows you every line of code as it is being written, so you're reading it and understanding where it's going in real time. Augmentation, not automation, is the path forward. Think of it like the difference between walking and having a manual transmission car to drive, not the difference between having a car and having a self driving car.

View on HN

If I have a 20 line function in my mind and the LLM injects 20 lines for me to accept or reject, I have two problems

First I have to review the 20 lines the LLM has produced

Second, if I reject those lines, it has probably shoved the function I had in mind out of my head

It's enormously disruptive to my progress

The hard truth here is in accepting that the 20 lines in your head were probably wrong, or suboptimal, and letting go of that urge. Think in interfaces, not implementations. Successive rendering, not one-shot.

This is just fundamentally not the case most of the time. LLMs guess where you're going, but so often what they produce is a "similar looking" non sequitur relative to the lines above it. It guesses, and sometimes that guess is good, but as often, or more, it's not.

The suggestion "think in interfaces" is fine; if you spell out enough context in comments, the LLM may be able to guess more accurately, but in spelling out that much context for it, you've likely already done the mental exercise of the implementation.

Also baffled by "wrong or suboptimal," I don't think I've ever seen an LLM come up with a better solution.

> The hard truth here is in accepting that the 20 lines in your head were probably wrong, or suboptimal, and letting go of that urge.

Maybe, but the dogshit that Cursor generates is definitely wrong so frankly if it's gonna be my name on the PR then I want it to me my wrong code not hide behind some automated tool

> Think in interfaces, not implementations

In my experience you likely won't know if you've designed the right interface until you successfully implement the solution. Trying to design the perfect interface upfront is almost guaranteed to take longer than just building the thing

I agree with the last two sentences but simultaneously think that starting to defacto believe you cannot have an equal or better solution compared to the AI is the start of atrophy of those skills.

Maybe it's the domain I work in, or the languages I use, but the 20 lines the LLM comes up with is almost certainly wrong.

> ...and letting go of that urge.

What urge? The urge to understand what the software you're about to build upon is doing? If so, uh... no. No thanks.

I've seen some proponents of these code-generation machines say things like "You don't check the output of your optimizing compiler, so why check the output of Claude/Devon/whatever?". The problem with this analogy is that the output from mainstream optimizing compilers is very nearly always correct. It may be notably worse than hand-generated output, but it's nearly never wrong. Not even the most rabid proponent will claim the same of today's output from these code-generation machines.

So, when these machines emit code, I will inevitably have to switch from "designing and implementing my software system" mode into "reading and understanding someone else's code" mode. Some folks may be actually be able to do this context-shuffling quickly and easily. I am not one of those people. The results from those studies from a while back that found that folks take something like a quarter-hour to really get back into the groove when interrupted while doing a technical task suggest that not that many folks are able to do this.

> Think in interfaces...

Like has been said already, you don't tend to get the right interface until you've attempted to use it with a bunch of client code. "Take a good, educated stab at it and refine it as the client implementations reveal problems in your design." is the way you're going to go for all but the most well-known problems. (And if your problem is that well-known, why are you writing more than a handful of lines solving that problem again? Why haven't you bundled up the solution to that problem in a library already?)

> Successive rendering, not one-shot.

Yes, like nearly all problem-solving, most programming is and always has been an iterative process. One rarely gets things right on the first try.

Reply on news.ycombinator.com