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

Lessons for Agentic Coding: What should we do when code is cheap?

dbreunig.com

Post reply on HN
Print view View original

41–50 of 260 posts

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#41

Post by orangecoffee »

xandrius wrote: post #7
theshrike79 wrote: post #4

Earlier quoted context omitted.

What will close the way back?

You cutoff a generation of juniors from employment and learning , the seniors are gone and it's all harnesses and AI systems. I'm not all gloom and doom but the treatment of junior engineers is something I think we will either regret or rejoice. Either will have a spur of creative people doing their own independent thing or we'll have lost a generation of great engineers.

This is not happening at least for 25 years, is what seniors I trust tell me.

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#43

Post by varjag »

pjc50 wrote: post #12
theshrike79 wrote: post #4

Earlier quoted context omitted.

What will close the way back?

The problem of "instant legacy" systems: something that's vibe coded and reached unmaintainable by either the AI or humans, but is also now indispensable because users are relying on it.

Hey you can just rewrite (or should we say regenerate) it. Second system has never been cheaper!

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#44

Post by user34283 »

duskdozer wrote: post #32
user34283 wrote: post #22

Earlier quoted context omitted.

How do you reconcile these ideas with the fact that cheap open weight models are only slightly behind the state of the art? If anything, I would bet that next year you could get today’s flagship performance for significantly cheaper via an open-weights model.

By that time, the hypebeasts will be explaining how worthless the models of today always were.

And there’s some truth to it.

I expect tomorrow’s models will be so much more capable that we will happily pay more.

But if not, we will still likely get today’s capabilities or more for cheap.

I don’t see a realistic scenario in which the AI genie is going back into the bottle because of affordability.

It seems like wishful thinking by people who dislike the new paradigm in software engineering.

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#46

Post by nubg »

codebje wrote: post #10
theshrike79 wrote: post #4

Earlier quoted context omitted.

What will close the way back?

Brain drain. If you fire all your SWEs they won't sit around twiddling their thumbs waiting for an AI collapse, they'll career shift. Maybe to an unemployment line and/or homelessness, maybe to something else productive, but either way they'll lose SWE skills. If you close down all the SWE junior positions you'll strongly discourage young people training in the field. They'll do something else. Then if you want to go…

I agree with you, but it's a case of the tradegy of the commons. One single company cannot make a meaningful dent even with your insight.

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#47

Post by energy123 »

raincole wrote: post #39
livinglist wrote: post #33

Earlier quoted context omitted.

The article is from 2023, I’m wondering if things mentioned still stand true today, can someone pls let me know.

It's much truer today. You can say that article is extremely insightful, as it predicted today's open weighted models scenario 2 years earlier.

It remains an unproven hypothesis. The revenue of the top 2-3 labs is still growing nearly exponentially, which is the ultimate piece of data that settles the question empirically for now. Benchmark scores aren't really proof. Benchmaxxing is possible, for example. Only revenue numbers (and gross margins) count.

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#48

Post by noelwelsh »

pell wrote: post #40
noelwelsh wrote: post #36

Certain types of code are cheap. Proof of concept is cheap. Adding small features that fit within the existing architecture is cheap. Otherwise, I'm not so sure. Coding agents are fantastic at minutiae, but have no taste. They'll turn a code base into a ball of mud very quickly, given the opportunity.

While I agree with you that agentic coding still has quite a way to go and is not always producing the quality that I would want from it, I can say quite confidently that its baseline is way above some of the production code in many applications many people use today. It really isn’t that code before agents was primarily written with taste and beautiful structure in mind. Your average code base is a messy hell full o…

I agree. I do wonder if what I'm seeing is a limitation of the reasoning power of LLMs or if it's just replicating the patterns (or lack thereof) in the training data.

Re: Lessons for Agentic Coding: What should we do when code is cheap?

#50

Post by jmull »

pell wrote: post #40
noelwelsh wrote: post #36

Certain types of code are cheap. Proof of concept is cheap. Adding small features that fit within the existing architecture is cheap. Otherwise, I'm not so sure. Coding agents are fantastic at minutiae, but have no taste. They'll turn a code base into a ball of mud very quickly, given the opportunity.

While I agree with you that agentic coding still has quite a way to go and is not always producing the quality that I would want from it, I can say quite confidently that its baseline is way above some of the production code in many applications many people use today. It really isn’t that code before agents was primarily written with taste and beautiful structure in mind. Your average code base is a messy hell full o…

I took the previous post, with its mention of the ball of mud, to be about complexity.

“Taste”, is used in many cases, I suspect, to give a name the collection of practices and strategies developers use to keep their code and projects at a manageable level of complexity.

LLMs don’t seem to manage complexity. They’ll just blow right past manageable and keep on going. That’s a problem. The human has to stay in the loop because LLMs only build what we tell them to build (so far).

BTW, the essay that introduced the big ball of mud pattern to me didn’t hold it up as something entirely bad to be avoided. It pointed out how many projects — successful or at least on-going projects — use it, and how its passive flexibility might actually be an advantage. Big ball of mud might just be the steady state where progress can be made while leaving complexity manageable.

Post reply on HN