Live data from Hacker News

The recurring dream of replacing developers

caimito.net

71–80 of 535 posts

Re: The recurring dream of replacing developers

#71
post #70

Can semi-technical people replace developers if those semi-technical people accept that the price of avoiding developers is a commitment to minimizing total system complexity? Of course semi-technical people can troubleshoot, it's part of nearly every job. (Some are better at it than others.) But how many semi-technical people can design a system that facilitates troubleshooting? Even among my engineering acquaintanc…

Remains to be seen for production settings.

My guess is no. I’ve seen people talk about understanding the output of their vibe coding sessions as “nerdy,” implying they’re above that. Refusing the vet AI output is the kiss of death to velocity.

Re: The recurring dream of replacing developers

#72

Earlier quoted context omitted.

>every "no-code will replace developers" wave actually creates more developer jobs, not fewer you mean "created", past tense. You're basically arguing it's impossible for technical improvements to reduce the number of programmers in the world, ever. The idea that only humans will ever be able to debug code or interpret non-technical user needs seems questionable to me.

This doesn’t seem immediately false. Industrial society creates more complexity and specializations. There is more work to do all the time.

Actual AI seems like a possibility here.

Also the percentage of adults working has been dropping for a while. Retired used to be a tiny fraction of the population that’s no longer the case, people spend more time being educated or in prison etc.

Overall people are seeing a higher standard of living while doing less work.

Re: The recurring dream of replacing developers

#73
post #21

Earlier quoted context omitted.

Who fixes the unmaintainable mess that the AI created in which the vibe coder prompted? The Vibe Coder? The AI? Take a guess who fixes it.

The real question is, do you even need to fix it? Does it matter? The reason those things matter in a traditional project is because a person needs to be able to read and understand the code. If you're vibe coding, that's no longer true. So maybe it doesn't matter. Maybe the things we used to consider maintenance headaches are irrelevant.

The reason those things matter in a traditional project is because the previous developers fucked up, and the product is now crashing and leaking money and clients like a sinking Titanic.

Re: The recurring dream of replacing developers

#74

It's not so much about replacing developers, but rather increasing the level of abstraction developers can work at, to allow them to work on more complex problems. The first electronic computers were programmed by manually re-wiring their circuits. Going from that to being able to encode machine instructions on punchcards did not replace developers. Nor did going from raw machine instructions to assembly code. Nor di…

The goal of AI companies is to replace all intellectual labor. You can argue that they're going to fail, but it's very clear what the actual goal is.

Re: The recurring dream of replacing developers

#75

> We’re still in that same fundamental situation. We have better tools—vastly better tools—but the thinking remains essential. But less thinking is essential, or at least that’s what it’s like using the tools. I’ve been vibing code almost 100% of the time since Claude 4.5 Opus came out. I use it to review itself multiple times, and my team does the same, then we use AI to review each others’ code. Previously, we whit…

You made the choice to change your development workflow to that. You chose to abdicate thinking to the LLM.

If it’s working for you, then great. But don’t pretend like it is some natural law and must be true everywhere.

Re: The recurring dream of replacing developers

#76

It's not so much about replacing developers, but rather increasing the level of abstraction developers can work at, to allow them to work on more complex problems. The first electronic computers were programmed by manually re-wiring their circuits. Going from that to being able to encode machine instructions on punchcards did not replace developers. Nor did going from raw machine instructions to assembly code. Nor di…

I think one thing I've heard missing from discussions though is that each level of abstraction needs to be introspectable. LLMs get compared to compilers a lot, so I'd like to ask: what is the equivalent of dumping the tokens, AST, SSA, IR, optimization passes, and assembly?

That's where I find the analogy on thin ice, because somebody has to understand the layers and their transformations.

Re: The recurring dream of replacing developers

#77
post #69

[flagged]

This suggests that the latent demand was a lot but it still doesnt prove it is unbounded. At some point the low hanging automation fruit gets tapped out. What can be put online that isnt there already? Which business processes are obviously going to be made an order magnitude more efficient? Moreover, we've never had more developers and we've exited an anomalous period of extraordinarily low interest rates. The party…

Look at traditional manufacturing. Automation has made massive inroads. Not as much of the economy is directly supporting (eg, auto) manufacturers as it used to be (stats check needed). Nevertheless, there are plenty of mechanical engineering jobs. Not so many lower skill line worker jobs in the US any more, though. You have to ask yourself which category you are in (by analogy). Don’t be the SWE working on the assembly line.

Re: The recurring dream of replacing developers

#78
post #70

Can semi-technical people replace developers if those semi-technical people accept that the price of avoiding developers is a commitment to minimizing total system complexity? Of course semi-technical people can troubleshoot, it's part of nearly every job. (Some are better at it than others.) But how many semi-technical people can design a system that facilitates troubleshooting? Even among my engineering acquaintanc…

Remains to be seen for production settings. My guess is no. I’ve seen people talk about understanding the output of their vibe coding sessions as “nerdy,” implying they’re above that. Refusing the vet AI output is the kiss of death to velocity.

> Refusing the vet AI output is the kiss of death to velocity.

The usual rejoinder I've seen is that AI can just rewrite your whole system when complexity explodes. But I see at least two problems with that.

AI is impressively good at extracting intent from a ball of mud with tons of accidental complexity, and I think we can expect it to continue improving. But when a system has a lot of inherent complexity, and it's poorly specified, the task is harder.

The second is that small, incremental, reversible changes are the most reliable way to evolve a system, and AI doesn't repeal that principle. The more churn, the more bugs — minor and major.

Re: The recurring dream of replacing developers

#79

Earlier quoted context omitted.

Which is why quiet quitting is the logical thing. Managers and business owners shouldn't take it personally that I do as little as possible and minimize the amount of labor I provide for the money I receive. Hey, it's just business.

And you do this honestly, by negotiating reduced hours for the same pay or by negotiating piecework rather than time-based pay. Right?

What does the term mean? I think the answer to your question is obvious.

Re: The recurring dream of replacing developers

#80

It's not so much about replacing developers, but rather increasing the level of abstraction developers can work at, to allow them to work on more complex problems. The first electronic computers were programmed by manually re-wiring their circuits. Going from that to being able to encode machine instructions on punchcards did not replace developers. Nor did going from raw machine instructions to assembly code. Nor di…

I think one thing I've heard missing from discussions though is that each level of abstraction needs to be introspectable. LLMs get compared to compilers a lot, so I'd like to ask: what is the equivalent of dumping the tokens, AST, SSA, IR, optimization passes, and assembly? That's where I find the analogy on thin ice, because somebody has to understand the layers and their transformations.

“Needs to be” is a strong claim. The skill of debugging complex problems by stepping through disassembly to find a compiler error is very specialized. Few can do it. Most applications don’t need that “introspection”. They need the “encapsulation” and faith that the lower layers work well 99.9+% of the time, and they need to know who to call when it fails.

I’m not saying generative AI meets this standard, but it’s different from what you’re saying.

Post reply on HN