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

211–220 of 389 posts

Re: The Eternal Sloptember

#211

Post by wiseowise »

farhanhubble wrote: post #176
4ndrewl wrote: post #128

Earlier quoted context omitted.

> I'm in the "haven't written any code in a while" boat ATM How long do you think it will be before you can't write any code because you're out of practice? One of the dangers of engineering management is that it can turn you into a person that can no longer do the thing. Does that even matter?

That's fair. In all honesty I'm already feeling challenged but given how much time I save I can set aside some time to keep myself sharp. I can learn more languages. Additionally, as pointed out by others, I'm trading coding effort for design and and strategy, which generally control business outcomes a lot more. Having said that, I won't use AI for production system if I don't understand the programming constructs i…

> In all honesty I'm already feeling challenged but given how much time I save

And how much is that?

Re: The Eternal Sloptember

#212

Post by joe_the_user »

cafkafk wrote: post #74

I think a lot of the problem with the current discourse is how black-and-white it is. Either you're a luddite or "ai pilled". In most cases, LLMs can get you 80-95% of the way, sometimes less, sometimes more. And heck, sometimes, it just gets you somewhere wrong. But it seems everyone is arguing about whether LLMs can be perfect software engineers in isolation running in a closet, and using that to say that LLMs do n…

LLMs can get you 80-95% of the way

But the big question is "where will '80-95% of the way' get you?"

Do you grind-out the last 5-20% in a period that's disappointingly long compared to the initial step? Or do you another 80% complete thing on top, and another and another until the whole structure collapses?

The post is talking about what groups might go what directions, which seems fair.

Re: The Eternal Sloptember

#213

Post by blobbers »

kelnos wrote: post #99
blobbers wrote: post #41

Earlier quoted context omitted.

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 every…

> Is this any different than how a PM gets a programmer to work on a project? Yes, it's very different. You seem to be suggesting that the current frontier LLMs, when tied to their tools and harnesses, have emergent properties that are similar to human consciousness. If you truly believe that, I'm not sure how to have a productive discussion here.

I think they have the capabilities to execute a well defined plan. If you truly don't believe that, then you I suspect any work you do as a programmer will not survive the coming changes.

Re: The Eternal Sloptember

#214

Post by blobbers »

Alex_L_Wood wrote: post #91
blobbers wrote: post #41

Earlier quoted context omitted.

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 every…

It's not just that, but the core is just that, even with reasoning models. Harness can only get you closer to the good result, but can't save you from every pitfall. As for PM analogy - don't forget that models don't learn and keep doing same stupid stuff they were doing a month ago.

I would suggest you examine current harness memory persistence. Any reprimand you give your model will be remembered, in the same way a puppy that has a bad social experience will become more shy.

They will not save you from every pitfall, but that isn't the point; engineers walk into pitfalls all the time. This can get you in, and out, much much quicker.

Re: The Eternal Sloptember

#215

Post by borski »

4ndrewl wrote: post #128
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…

> I'm in the "haven't written any code in a while" boat ATM How long do you think it will be before you can't write any code because you're out of practice? One of the dangers of engineering management is that it can turn you into a person that can no longer do the thing. Does that even matter?

The ability to read code doesn’t decay at nearly the same rate. Neither does your experience.

Re: The Eternal Sloptember

#216

Post by farhanhubble »

imron wrote: post #76
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…

Here's one that hit the frontpage recently: https://blog.k10s.dev/im-going-back-to-writing-code-by-hand/

That's indeed a good example.

However I find their claim "I've lead teams of really competent engineers and I can leave them without supervision for months and come back and not feel like throwing away the entire code base." dubious. We all know how much effort it is to keep the quality of even small patches consistent.

Design, architecture, style and refactoring still require significant involvement. Providing only a description and a criteria will likely produce hopelessly messy code, which is also what you get with most corporate dev teams.

Re: The Eternal Sloptember

#217

Post by simianwords »

baq wrote: post #191
vips7L wrote: post #122

Earlier quoted context omitted.

People are skeptical of LLMs because the experiences they’ve had with LLMs. You can’t blog your way out those experiences. I’m skeptical because I’ve seen this exact situation and I’ve seen the result be something that anyone experienced wouldn’t do.

Sometimes I think folks having ‘experiences’ should play more poker. The point is, it’s a game of chance and yet good players beat bad players in the long run. Your job in the new era of software engineering is to design the process so LLMs doing your code monkeying avoid the losses (including discarding bad changes) and take the wins. Win often enough and you’ll come out ahead.

Hmm you have written it in a way that gives me a new line of thinking.

I think what you are saying is that people should learn and appreciate working in high variance environments and still exploit small gains. This is clearly not something that is easily digestible to people so they end up rejecting LLMs.

Re: The Eternal Sloptember

#218

Post by ponector »

torben-friis wrote: post #208
bruce511 wrote: post #197

Earlier quoted context omitted.

Goods are usually (although not always) inferior when made by a machine. A hand-crafted solid wood table is still superior to something from Ikea. Of course hand made tables are expensive. They service a sliver of the market. Ikea serves the rest of us who'd prefer not to eat off the floor. Fundamentally, Luddites didn't like being replaced by a machine. They were skilled workers, who used to have very desirable skil…

>Of course hand made tables are expensive. They service a sliver of the market. Ikea serves the rest of us who'd prefer not to eat off the floor. And yet my working class grandparents didn't eat off the floor, they had great quality tables. Mine is made of disguised cardboard. This is a big part of the problem, there is zero trust that any potential improvement in cost or access will reach consumers. Companies don't…

How many hours it was required for them to work to earn money for that table?

The truth is people mostly want not an improved version but cheaper one.

Re: The Eternal Sloptember

#219

Post by mattlondon »

It's just a tool. Use it well or use it badly - just the same as any. If you are generating slop using the tool, we'll then that is your own problem.

For me, the AI is essentially "faster hands" that can type what I am thinking way faster than I can do it. I tell it what I want, I give it the broad architecture and design patterns/types to use, and any specific test conditions, and let it write all of that usually by the time I have responded to a single email or chat message or two. Custom instructions etc build overtime to address model blind spots or my own personal taste so I don't have to repeat myself in every prompt for cross-cutting things.

Does it "one shot it"? Almost never - we go around the cycle a few times, treating it like pair programming a junior or intern by keeping a close eye on the broad direction and making sure it is acceptable - course-correcting where it matters, but cutting some slack where it doesn't. Sometimes I ask it why it picked a particular approach (that I wouldn't have necessarily) and it gives me a cogent explanation and we go with it, so I actually sometimes learn new things from it too which is great.

The other use case is just it's sheer capacity to research a codebase and hold everything in it's attention at once. It can comprehend unfamiliar code way faster and way more in-depth than I can. So if you are in an unfamiliar code base or a language or framework you are not that familiar with, it absolutely shines because it can just absorb all that info in seconds, and then you can just drill it with questions and what-abouts and how does it do this and what technique is used for that and that, what are the existing patterns and norms in this codebase when it comes to foo or bar? Etc etc

What I am not doing is deferring everything off to the AI unless it really doesn't matter (e.g. disposable one-off or prototype code). Same that I would not expect a junior or intern to make big architectural decisions when implementing something - you keep them on a fairly close leash and watch what they are up to.

Re: The Eternal Sloptember

#220

Post by frabcus »

rebuilder wrote: post #23
simianwords wrote: post #19

Nah this person is dead wrong. Lets come back in 2 years and check on it. I'm willing to make a reasonable bet on these terms: companies will go even more AI native, will use even more tokens and spend even more money. EDIT: To people downvoting me, please come up with a reasonable bet and lets try to work it out. EDIT 2: $500 bet paid to your account on whether LLM's are going to still be used productively or not. N…

You could both be right.

Right the original article says "Do you think macOS will get better or worse in the next 2 years?" (rhetorically implying "worse").

That could easily be true and Apple "will use even more tokens and spend even more money".

Post reply on HN