Top
Best
New

Posted by cdrnsf 5 days ago

Let's talk about LLMs(www.b-list.org)
194 points | 186 commentspage 2
rglover 5 days ago|
We are obsessed with fortune telling.

Use the damn thing or don't.

It's that simple.

zapataband1 5 days ago|
it would be that simple if a mental-health altering token-predictor wasn't being consistently shoved down our collective throats.
rglover 5 days ago||
Fair. But it's worth considering that anything "they" need to shove is a tell that they need you more than you need them. The sky-hath-fallen narrative is just what top-dollar marketing gets you these days. Clever, but mostly bark.
andai 5 days ago||
On my device the article displayed 5 words per line, so I switched to "Desktop site" in the hamburger menu which made it much more readable.

(Sorry for bikeshedding, but you can't discuss an article if you can't read it.)

moritzwarhier 4 days ago||
No, not again. Unless you had a point, which would probably apparent from the headline.
jwpapi 5 days ago||
Its the biggest swindle...

You could fetch some unfinished github repos or download free templates. It’s actually faster than LLMs, still no body would do it.

I don’t start my project with the ecommerce nextjs starter repo. I build it from scratch, because it’s faster...

empthought 5 days ago||
> But ultimately, the only situation in which LLMs could meaningfully democratize access to software development is one where they achieve a true silver bullet, by significantly reducing or removing essential difficulty from the software development process.

The author didn't seem to read the Brooks essay for comprehension. There is an entire section about expert systems that foreshadows agents. While there is no singular silver bullet, Brooks explores the most promising techniques to reduce essential complexity that were anticipated in 1986.

> The most powerful contribution of expert systems will surely be to put at the service of the inexperienced programmer the experience and accumulated wisdom of the best programmers. This is no small contribution.

Furthermore, his objection to automatic programming was simply an argument from incredulity, which is an understandable opinion at the time, yet quite vacuous in hindsight.

trwhite 5 days ago||
A well researched and written piece
senko 5 days ago||
The accidental vs essential difficulty argument ignores the fact that you can abstract away (some) essential difficulty if you're willing to take a performance hit.

Design patterns in an older (programming) language become core language features in a newer one. As we internalize and abstract away the best patterns for something, it becomes accidental but it's only obvious in retrospect.

The article quotes Brooks (quoting Parnas) about just that (later, in context of LLMs):

> automatic programming always has been a euphemism for programming with a higher-level language than was presently available to the programmer. [...] Once those accidents have been removed, the remaining ones are smaller, and the payoff from their removal will surely be less.

Considering this was written when C was the hot new stuff, let's compare the ability to code a CRUD web app in Python/Django vs C. What Brooks and Parnas are saying that Python/Django cannot bring big improvements in building a CRUD web app when compared to C because they can only make it easier to program, reducing accidental complexity. But we've since redefined "accidental" and I would argue that you can write a CRUD web app in Python/Django at least 100x faster than in C (and probably at least 100x more secure), although it may take 1000x as more CPU and RAM while running.

So "we removed most of the accidental difficulties and the most that remains is essential" is a kind of "end of history" argument.

> I’d be surprised if there’s even a doubling of productivity still available from a complete elimination of remaining accidental difficulty.

It's good that this statement has a conditional subjective guard, because that's just punditry.

> LLM coding does not represent a silver bullet

Here I agree with the author completely, but probably not for the same reasons. The definition of "silver bullet" the article uses (quoting Brooks):

> There is no single development, in either technology or management technique, which by itself promises even a single order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

AI-assisted development is not a single technique, the same way "devops" or "testing" or "agile" is not a single technique. But more importantly, I agree it will take time to find best practices, for the technology change to slow down, and for the best approaches to diffuse across the industry.

The article's conclusion:

> You should be adopting and perfecting solid foundational software development practices like version control, comprehensive test suites, continuous integration, meaningful documentation, fast feedback cycles, iterative development, focus on users, small batches of work… things that have been known and proven for decades, but are still far too rare in actual real-world software shops.

These are great and I'm gonna let him/her finish, but it's curious actual coding isn't mentioned anywhere. The author doesn't suggest "polish your understanding of C pointer semantics" or "Rust ownership model" or "Django ORM" or to really, deeply, understand B-trees. Looks like pedestrian detailes like those are left as an excercise for the reader ... or the reader's LLM.

rambojohnson 5 days ago|
that's all we been doing now.
More comments...