Most active commenters
  • stavros(5)

←back to thread

181 points thunderbong | 15 comments | | HN request time: 0s | source | bottom
Show context
stavros ◴[] No.45083136[source]
I've come to view LLMs as a consulting firm where, for each request, I have a 50% chance of getting either an expert or an intern writing my code, and there's no way to tell which.

Sometimes I accept this, and I vibe-code, when I don't care about the result. When I do care about the result, I have to read every line myself. Since reading code is harder than writing it, this takes longer, but LLMs have made me too lazy to write code now, so that's probably the only alternative that works.

I have to say, though, the best thing I've tried is Cursor's autocomplete, which writes 3-4 lines for you. That way, I can easily verify that the code does what I want, while still reaping the benefit of not having to look up all the APIs and function signatures.

replies(7): >>45083197 #>>45083541 #>>45085734 #>>45086548 #>>45087076 #>>45092938 #>>45092950 #
1. talles ◴[] No.45085734[source]
> Since reading code is harder than writing it,

Reading bad code is harder than writing bad code. Reading good code is easier than writing good code.

replies(1): >>45085798 #
2. stavros ◴[] No.45085798[source]
I beg to differ.
replies(3): >>45086195 #>>45088591 #>>45090203 #
3. jagged-chisel ◴[] No.45086195[source]
No need to beg. Everyone’s got their opinion. I just wish, this being Hacker News, that more people would articulate their different opinions instead of just stopping with “I disagree.”
replies(1): >>45086291 #
4. stavros ◴[] No.45086291{3}[source]
Well, my first comment said "reading code is harder than writing code", your comment said "reading good code is easier than writing good code". I believe the two points are about equally articulated.
replies(1): >>45091575 #
5. AlexCoventry ◴[] No.45088591[source]
Why is reading code harder than writing it?
replies(1): >>45089978 #
6. blackoil ◴[] No.45089978{3}[source]
I think it has to do with mental model. If you already know what to write and it is reasonably complex you'll have a mental model ready and can quickly write it down (now even faster as LLMs autocomplete 3-4 lines at a time). While reading someone else code you'll have to constantly map the code in your mind with code written and have to then compare quality, security and other issues.
replies(2): >>45090397 #>>45090528 #
7. fnordpiglet ◴[] No.45090203[source]
This is the sign of seniority IMO. First you learn to write code. Then you learn to write code that can be read. Then you learn to modify code. Then you learn to read other people’s code. Then you learn to modify other people’s code. Then you learn to own code regardless of who reads or writes it.

At this point in my career 35 years in I find reading and writing code whether I wrote it or other did irrelevant. Bad or good code, it’s all the same. By far the most effective work I do involves reading a lot of complex code written by many people over many years and seeing the exact one line to change or improve.

I find LLM assisted coding very similar frankly. I’ve finished maybe 20 projects or more on the last seven months on my own time that I never would have been able to do in my lifetime for want of free time to learn minutia in stuff I am not familiar with. The parts it get hung up on I’m able with quick inspection to recognize and unwedge it, just like any junior engineer. The junior engineers also are often much better versed in XYZ library than I am.

replies(2): >>45090364 #>>45092065 #
8. theshrike79 ◴[] No.45090364{3}[source]
This is the thing.

LLM assisted coding ("vibe coding") is just project management.

You ask it to do things, then you check the work to a sufficient degree.

The better the specifications and documentation you give it, the better the result will be. Keeping tasks short and verifiable also helps a lot.

I've written SO many small tools for myself during the last year it's not even funny. Upgraded some shitty late night Python scripts to proper Go applications with unit tests and all, while catching up on my TV shows.

Converted my whole rat's nest of Docker compose files to a single Opentofu declarative setup.

None of this would've gotten done without an LLM assistant.

replies(1): >>45099626 #
9. theshrike79 ◴[] No.45090397{4}[source]
I'd say just reading your own code from a few years back will be as hard as reading someone else's.
10. stavros ◴[] No.45090528{4}[source]
Yeah, it's exactly this. Having to create a mental model from the code is much harder than having one and just writing it out.
replies(1): >>45096779 #
11. jagged-chisel ◴[] No.45091575{4}[source]
Neither comment is mine. I’m here in the outside wanting to understand the arguments you have in your heads. Sure, the two comments you mention are equally under-articulated. Either continue the discussion for the benefit of others on the site, or leave it as it stands. Stating “I beg to differ” is pointless.
replies(1): >>45091602 #
12. stavros ◴[] No.45091602{5}[source]
This comment put it well: https://news.ycombinator.com/item?id=45089978
13. ontouchstart ◴[] No.45092065{3}[source]
I’m at the same point as well. Doing more reading than writing.

Just want to add one more point: code is not fiction or even nonfiction, “good or bad” style can be subjective, but correct or not correct is not, regardless of the reviewer’s mental model.

The difficulty of reading code is to understand its logic and logical consequences. The more complex the codebase (not just the line we are reading), the more risky to modify it.

That is why I use LLM to write a lot of tests and let it review the logs to help me understand the logic. Even the tests can be disposable.

14. AlexCoventry ◴[] No.45096779{5}[source]
I just tend to find LLM code output extremely to read, I guess. It tends to be verbose and do a lot of unnecessary stuff, but I can always get the point easily and edit accordingly.
15. fnordpiglet ◴[] No.45099626{4}[source]
Funny I end up working on 5-6 things at once that are fairly varied. My favorite rats nest is rebuilding by DIY NAS as a NixOS declaration so I can rebuild the filer root from GitHub.