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

The recurring dream of replacing developers

caimito.net

Post reply on HN
Print view View original

451–460 of 535 posts

Re: The recurring dream of replacing developers

#451

Post by red75prime »

krethh wrote: post #341
red75prime wrote: post #281

Earlier quoted context omitted.

No previous tool was able to learn on its own mistakes (RLVR). It might be not enough by itself, but it shows that something has changed in comparison with the 70-odd previous years.

LLM's don't learn on their own mistakes in the same way that real developers and businesses do, at least not in a way that lends itself to RLVR. Meaningful consequences of mistakes in software don't manifest themselves through compilation errors, but through business impacts which so far are very far outside of the scope of what an AI-assisted coding tool can comprehend.

> through business impacts which so far are very far outside of the scope of what an AI-assisted coding tool can comprehend.

That is, the problems are a) how to generate a training signal without formally verifiable results, b) hierarchical planning, c) credit assignment in a hierarchical planning system. Those problems are being worked on.

There are some preliminary research results that suggest that RL induces hierarchical reasoning in LLMs.

Re: The recurring dream of replacing developers

#452

Post by habinero »

threethirtytwo wrote: post #309
habinero wrote: post #305

Earlier quoted context omitted.

> What is happening now. What the trendlines look like. What follows if those trendlines continue. Output per developer is rising. Time from idea to implementation is collapsing. Junior and mid level work is disappearing first. Teams are shipping with fewer people. These are not hypotheticals. My dude, I just want to point out that there is no evidence of any of this, and a lot of evidence of the opposite. > If you w…

“There is no evidence” is not skepticism. It’s abdication. It’s what people say when they want the implications to go away without engaging with anything concrete. If there is “a lot of evidence of the opposite,” the minimum requirement is to name one metric, one study, or one observable trend. You didn’t. You just asserted it and moved on, which is not how serious disagreement works. “You first, lol” isn’t a rebutta…

> If there is “a lot of evidence of the opposite,” the minimum requirement is to name one metric, one study, or one observable trend. You didn’t. You just asserted it and moved on, which is not how serious disagreement works.

I treated it with the amount of seriousness it deserves, and provided exactly as much evidence as you did lol. It's on you to prove your statement, not on me to disprove you.

Also, you still haven't provided the kind of evidence you say is necessary. None of the "evidence" you listed is actually evidence of mass change in engineering.

> AI-assisted coding is directly eliminating discrete units of programmer labor: boilerplate, CRUD endpoints, test scaffolding, migrations, refactors, first drafts, glue code.

You are not a professional engineer lol, because most of those things are already automated and have been for decades. What on earth do you think we do every day?

Re: The recurring dream of replacing developers

#453

Post by red75prime »

krethh wrote: post #343
red75prime wrote: post #282

Earlier quoted context omitted.

Turning into a human-level intelligence. If you believe that it requires magic, well, it's your right.

A $3 calculator today is capable of doing arithmetic that would require superhuman intelligence to do 100 years ago. It's extremely hard to define "human-level intelligence" but I think we can all agree that the definition of it changes with the tools available to humans. Humans seem remarkably suited to adapt to operate at the edges of what the technology of time can do.

> that would require superhuman intelligence to do 100 years ago

It had required a ton of ordinary intelligence people doing routine work (see Computer(occupation)). On the other hand, I don't think anyone has seriously considered to replace, say, von Neumann with a large collective of laypeople.

Re: The recurring dream of replacing developers

#454

Post by Retric »

groundzeros2015 wrote: post #409
Retric wrote: post #306

Earlier quoted context omitted.

Only the relatively tiny homeless population is poor by historic standards. And that’s almost exclusively mental health issues and addiction. Now we can set arbitrary thresholds for what standard of living every American should have but even knowing people on SNAP it’s not that low.

> Only the relatively tiny homeless population is poor by historic standards. The cost to participate in society is much greater. Yeah we do have more cars. But you also need to buy one to go to work. We have education, but you need 22 years to be employable. It’s probably not with continuing the discussion if you don’t believe poverty exists as a concept.

Millions of working Americans don’t have cars. Also, you can make the median wage in the US without any collage education.

Poverty still exists, but vast inflation of what is considered’a basic standard of living’ hides a great deal of progress. People want to redefine illiteracy to mean being unable to use the internet not by the standards of the past.

Re: The recurring dream of replacing developers

#455

Post by Retric »

groundzeros2015 wrote: post #408
Retric wrote: post #145

Earlier quoted context omitted.

Efficiency is why things continue to work as fewer people work. Social programs, bank account, etc are just an abstraction you need a surplus or the only thing that changes is who starves.

> Efficiency is why things continue to work as fewer people work. Yes, but it’s not why there are fewer adults in the workforce.

Yes it is, if we still needed 90+% of the population to work or people starved that’s a self correcting system. Less than that work and you have less people.

Re: The recurring dream of replacing developers

#456

Post by godelski »

yunohn wrote: post #444
godelski wrote: post #328

Earlier quoted context omitted.

I'm sure those will help. But that doesn't solve the problem the parent stated. Those robots can't solve those real world problems until they can reason, till they can hypothesize, till they can experiment, till they can abstract all on their own. The problem is you can't replace the humans (unilaterally) until you can create AGI. But that has problem of its own, as you now have to contend with previously creating a…

I completely agree - my comment was sarcastic and in jest.

My bad. Getting hard to tell these days lol

Re: The recurring dream of replacing developers

#457

Post by galaxyLogic »

cudgy wrote: post #384
galaxyLogic wrote: post #287

Earlier quoted context omitted.

The way I would approach writing specs and requirements as code would be to write a set of unit-tests against a set of abstract classes used as arguments of such unit-tests. Then let someone else maybe AI write the implementation as a set of concrete classes and then verify that those unit-tests pass. I'm not sure how well that would work in practice, nor why such an approach is not used more often than it is. But ye…

“write a set of unit-tests against a set of abstract classes used as arguments of such unit-tests.” An exhaustive set of use cases to confirm vibe AI generated apps would be an app by itself. Experienced developers know what subsets of tests are critical, avoiding much work.

I agree (?) that using AI vibe-coding can be a good way to prooduce a prototype for stakeholders to see if the AI-output is actually something they want.

The problem I see is how to evolve such a prototype to more correct specs, or changed specs in the future, because AI output is non-deterministic -- and "vibes" are ambiguous.

Giving AI more specs or modified specs means it will have to re-interpret the specs and since its output is non-deterministic it can re-interpret viby specs differently and thus diverge in a new direction.

Using unit-tests as (at least part of) the spec would be a way to keep the specs stable and unambiguous. If AI is re-interpreting the viby ambiguous specs, then the specs are unstable which measn the final output has hard-time converging to a stable state.

I've asked this before, not knowing much about AI-sw-development, whether there is an LLM that given a set of unit-tests, will generate an implementation that passes those unit-tests? And is such practice used commonly in the community, and if not why not?

Re: The recurring dream of replacing developers

#458

Post by layer8 »

lelanthran wrote: post #420
layer8 wrote: post #229

Earlier quoted context omitted.

It happened with tools like Excel, for example, which matches your description of empowering non-developers. It happens with non-developers setting up a CMS and then, when hitting the limits of what works out of the box, hiring or commissioning developers to add more complex functions and integrations. Barring AGI, there will always be limitations, and hitting them induces the desire to go beyond.

> when hitting the limits of what works out of the box, hiring or commissioning developers to add more complex functions and integrations. You aren't going to going to do that to AI systems. If, after a couple of weeks you hit the limit of what the AI could do in a million+ LoC, you aren't going to be able to hire a human dev to modify or replace that system for you, because: 1. Humans are going to be needing a ramp…

So, what do you propose non-developers in that situation will be doing then?

Re: The recurring dream of replacing developers

#459

Post by yunohn »

godelski wrote: post #456
yunohn wrote: post #444

Earlier quoted context omitted.

I completely agree - my comment was sarcastic and in jest.

My bad. Getting hard to tell these days lol

No worries - you’ve added useful context for those who may be misguided by these greedy corporations looking to replace us all. Maybe it helps them reconsider their point of view!

Re: The recurring dream of replacing developers

#460

Post by dexdal »

davnicwil wrote: post #251

In the end, I think the dream underneath this dream is about being able to manifest things into reality without having to get into the details. The details are what stops it from working in every form it's been tried. You cannot escape the details. You must engage with them and solve them directly, meticulously. It's messy, it's extremely complicated and it's just plain hard. There is no level of abstraction that sav…

This matches what keeps repeating. Tools change where the work happens, but they don’t remove the need for controlled decisions about inputs, edge cases, and outcomes. When that workflow isn’t explicit, every new abstraction feels like noise.
Post reply on HN