Comment by avalys | Hacker News Reader

Comment by avalys | Hacker News Reader

I find LLMs very useful when I need to learn something new, e.g. a new library or API, or a new language. It is much faster to just ask the LLM how to render text in OpenGL, or whatever, than read through tons of terrible documentation. Or, if I have a bunch of repetitive boilerplate stuff that I have no good templates for or cannot borrow from another part of the codebase. But when it comes to what I consider the actual 'work', the part of my codebase that is actually unique to the product I'm building, I rarely find them valuable in the "letting them write the code for me" sense.

I reflected once that very little of my time as a senior engineer is actually spent just banging out code. The actual writing of the code is never the hard part or time-consuming part for me - it's figuring out the right architecture, figuring out how to properly refactor someone else's hairball, finding performance issues, debugging rare bugs, etc. Yes, LLMs accelerate the process of writing the boilerplate, but unless you're building brand new products from scratch every 2nd week, how much boilerplate are you really writing? If the answer is "a lot", you might consider how to solve that problem without relying on LLMs!

> I find LLMs very useful when I need to learn something new, e.g. a new library or API, or a new language. It is much faster to just ask the LLM how to render text in OpenGL, or whatever, than read through tons of terrible documentation.

LLMs are better at reading terrible documentation than the average programmer. So in that sense, "obscure text reading and explain it better" there seems to be a clear value add.

> If the answer is "a lot", you might consider how to solve that problem without relying on LLMs!

Aren't there languages with a lot of boilerplate though?

> LLMs are better at reading terrible documentation than the average programmer.

LLMs don't go and read the terrible documentation for you when prompted. They reproduce the information posted by other people that struggled with said terrible documentation, if it was posted somewhere.

It's still better than a modern web search or struggling with the terrible documentation on your own - for introductory stuff.

For going into production you have to review the output, and reading code has always been harder than writing it...

This is is wildly incorrect. Documentation categorically isn't excluded from LLMs' training sets, and they are very well able to summarize that documentation when asked.

I believe you missed "when prompted".

There’s no silver bullet. Conceptualization is the hard part, exactly as you say. Mythical man-month is an important text and should be studied more.

And also the seminal papers by Gödel, Turing, and the books on cybernetics (robotics and automation in 1950s) by Ashby and Wiener.

The limits of what can be automated have been clear for almost a century now. Yet people insist in selling ways to automate your way out of social, political, economical problems. Come to think about it, people should also read Comways's paper as well.

What is Comways's paper?

"How committees invent"

https://www.melconway.com/Home/pdf/committees.pdf

Reply on news.ycombinator.com