Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Eternal Sloptember

geohot.github.io

Post reply on HN
Print view View original

41–50 of 389 posts

Re: The Eternal Sloptember

#41

Post by blobbers »

Alex_L_Wood wrote: post #9
wyager wrote: post #5

> They are a highly sophisticated statistical model designed to mimic the distribution of programming Are we really still doing this?

Well, since the fundamental underlying structure is still the same, yes.

It's not exactly what it is; they now model an incredibly complex markov process, and harnesses that control how that thinking is done.

Is this any different than how a PM gets a programmer to work on a project? They think, then they deliver. If given more time, maybe they deliver something better. Maybe they consult some text and try to apply a design pattern.

The LLM in this use case is perfect because almost everything involved is text based, and the model is able to take in all the expressive that is language.

Re: The Eternal Sloptember

#42

Post by protocolture »

Eh but statistical models are obviously useful, because statistically 99% of your codebase wont involve new idea invention. Tools that write all the boilerplate code used to have names and job titles.

I hate how both the for and against case for LLMs are just so bloody terrible at addressing these things.

Re: The Eternal Sloptember

#43

Post by hibikir »

tra3 wrote: post #21
farhanhubble wrote: post #14

I'm in the "haven't written any code in a while" boat ATM. I'd love to see examples of issues that are so big that they warrant reverting to manual coding. My main issue has been the inconsistent quality across between model releases and the tendency to insert older APIs or documentation, especially with command line tools. I can understand if the model struggles with a million line monolithic codebase with a decade…

When every prompt produces a thousand line PR, you’re not very far from another million line monolith. I’m a little more hopeful than the author though. I feel like it’s possible to manage the process so that does not happen.

It's not difficult to avoid the 1000 lines per PR thing: Depending on what kind of thing I am adding, the plan might also receive as instructions to value making as small a code change as possible. It still requires judgement, as on something big, the smallest possible code base is not necessarily the most readable, but this is the kind of thing one can decide with some experience and little work.

I've also managed to use LLMs to cut a lot of manual duplication in code where we typically didn't do enough investment: "Claude, evaluate code duplication in the functional test suite" will have no problem finding things like insufficient helpers, or tests that are testing simpler things as prerequisites, so they can rely on each other. So I am not seeing my codebases growing all that much. There's some risks of functional changes that before would be rejected due to cost which now are not, but I am not all that sure of how much that is controllable without being relatively antagonistic with management.

Re: The Eternal Sloptember

#44

Post by Chaosvex »

> and it’s taking longer and longer to realize that they can’t

For something to take "longer and longer" to realise, doesn't they imply that it's been realised at least once before or that there was an expected deadline for the realisation?

Okay, that's a nitpick.

Re: The Eternal Sloptember

#45

Post by dwd »

bandrami wrote: post #13
intended wrote: post #7

If nothing else, Eternal Sloptember is a term that seems obvious once you have it. I can’t believe this is the first time I’m seeing it.

If you were on Usenet before '93 the words still haunt you

Joined Usenet in 1990 and for a few years it was great.

I always wonder whether HN suffers from periodic influxes of newbies who don't get it yet and rile up the regulars.

Re: The Eternal Sloptember

#46

Post by sandruso »

Not reviewing outputs, which is my main issue, is one-way to subpar experience. No amount of "make it right" will fix that.

I hope that professionalism still matters as these new ways of doing things strikes me as unprofessional as f...

Yeah, the next macOS will be worse... time to place bet on prediction market

Re: The Eternal Sloptember

#47

Post by pipeline_peak »

The more specific your work is, the more these LLM’s seem to struggle.

If your work was previously googling stack overflow, it can be incredibly useful at working through that. Which let’s face it, that’s what a lot of us do.

Re: The Eternal Sloptember

#49

Post by sodafountan »

Nition wrote: post #17

With the level of ability that AI is at right now, I've found it useful personally to think of it something like a very good search over existing knowledge. Another step up in searchability in the lineage of reference books, stack overflow, GitHub etc. Programmers are rewriting and reinventing the same techniques more often than any other vocation I can think of, and so we were primed for a really good search over pr…

Yes, I don't have anything important to say other than I 100% agree with this comment. AI in its current state is akin to Stack Overflow and Google on steroids, but from my experience, it doesn't do well building out full-scale applications other than perhaps some initial scaffolding.

If I were to use it against a legacy, rather poorly written codebase, where the code may be hard to understand without some in-depth analysis. I could certainly ask an AI agent to read the code (How does application X do Y, for example), but I wouldn't have it start hammering out features or have it do any type of refactoring. That would cause far too many commits and confusion amongst the development team, leading to even more slop than whatever we'd already be dealing with.

Just leaving this comment here so I can come back to your comment. I've been getting a bit discouraged by AI lately, but this sums up my experience with it well enough.

Post reply on HN