The recurring dream of replacing developers • Hacker News Board

Re: The recurring dream of replacing developers

#311

Post by gtowey » Sun, Jan 18, 2026, 6:26 AM UTC

fragmede wrote: post #275

lazypenguin wrote: post #256

Earlier quoted context omitted.

Yes! I love this framing and it’s spot on. The successful projects that I’ve been involved in someone either cares deeply and resolves the details in real time or we figured out the details before we started. I’ve seen it outside software as well, someone says “I want a new kitchen” but unless you know exactly where you want your outlets, counter depths, size of fridge, type of cabinets, location of lighting, etc. ad…

Is your kitchen contractor an unthinking robot with no opinions or thoughts of their own that has never used a kitchen? Obviously if you want a specific cabinet to go in a specific place in the room, you're going to have to give the kitchen contractor specifics. But assuming your kitchen contractor isn't an utter moron, they can come up with something reasonable if they know it's supposed to be the kitchen. A sink, a…

You kitchen contractor will never cook in your kitchen. If you leave the decisions to them, you'll get something that's quick and easy to build, but it for sure won't have all the details that make a great kitchen. It will be average.

Which seems like an apt analogy for software. I see people all the time who build systems and they don't care about the details. The results are always mediocre.

Re: The recurring dream of replacing developers

#312

Post by cik » Sun, Jan 18, 2026, 6:34 AM UTC

I don't think the dream of replacing developers, in particular exists. Specialization of labour leads to increased costs, due to value placed on said specialized labour. Software development, is one form of specialized manufacturing, and hence is more costly. Within software development, similar strata exists, leading to increased value on increased specialization, and hence the pyramid effect. The same is true within any field.

Similarly, one might argue as increased capital finds its way to a given field, due to increased outcomes, labour in turn helps pressure pricing. Increased "sales" opportunity within said field (i.e people being skilled enough to be employed, or specialized therein) will similarly lead to pricing pressure - on both ends.

Re: The recurring dream of replacing developers

#313

Post by fc417fc802 » Sun, Jan 18, 2026, 6:35 AM UTC

mkleczek wrote: post #307

fragmede wrote: post #275

Earlier quoted context omitted.

Is your kitchen contractor an unthinking robot with no opinions or thoughts of their own that has never used a kitchen? Obviously if you want a specific cabinet to go in a specific place in the room, you're going to have to give the kitchen contractor specifics. But assuming your kitchen contractor isn't an utter moron, they can come up with something reasonable if they know it's supposed to be the kitchen. A sink, a…

At least in case of the kitchen contractor, you can trust all the electrical equipment, plumbing etc. is going to be connected in such a way that disasters won't happen. And if it is not, at least you can sue the contractor. The problem with LLMs is that it is not only the "irrelevant details" that are hallucinated. It is also "very relevant details" which either make the whole system inconsistent or full of security…

The login page example was actually perfect for illustrating this. Meshing polygons? Centering a div? Go ahead and turn the LLM loose. If you miss any bugs you can just fix them when they get reported.

But if it's security critical? You'd better be touching every single line of code and you'd better fully understand what each one does, what could go wrong in the wild, how the approach taken compares to best practices, and how an attacker might go about trying to exploit what you've authored. Anything less is negligence on your part.

Re: The recurring dream of replacing developers

#314

Post by quick_brown_fox » Sun, Jan 18, 2026, 6:36 AM UTC

gregfjohnson wrote: post #296

This all reminds me of one of the most foundational and profound papers ever written about software development: Peter Naur's "Programming as Theory Building". I have seen colleagues get excited about using Claude to write their software for them, and then end up spending at least as much time as if they had written it themselves trying to develop a theory the code that was produced, and an understanding sufficient t…

+1 on programming as theory building. If it wasn’t already, the bottleneck has shifted from code generation to understanding & reasoning.

Re: The recurring dream of replacing developers

#315

Post by AstroBen » Sun, Jan 18, 2026, 6:39 AM UTC

gtowey wrote: post #311

fragmede wrote: post #275

Earlier quoted context omitted.

Is your kitchen contractor an unthinking robot with no opinions or thoughts of their own that has never used a kitchen? Obviously if you want a specific cabinet to go in a specific place in the room, you're going to have to give the kitchen contractor specifics. But assuming your kitchen contractor isn't an utter moron, they can come up with something reasonable if they know it's supposed to be the kitchen. A sink, a…

You kitchen contractor will never cook in your kitchen. If you leave the decisions to them, you'll get something that's quick and easy to build, but it for sure won't have all the details that make a great kitchen. It will be average. Which seems like an apt analogy for software. I see people all the time who build systems and they don't care about the details. The results are always mediocre.

Do all details matter equally? Maybe only 3/10 of them you really care about and you can leave the rest up to the contractor

Re: The recurring dream of replacing developers

#316

Post by utopiah » Sun, Jan 18, 2026, 6:49 AM UTC

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…

> the dream underneath this dream is about being able to manifest things into reality without having to get into the details.

Yes, it has nothing to do with dev specifically, dev "just" happens to be how to do so while being text based, which is the medium of LLMs. What also "just" happens to be convenient is that dev is expensive, so if a new technology might help to make something possible and/or make it unexpensive, it's potentially a market.

Now pesky details like actual implementation, who got time for that, it's just few more trillions away.

Re: The recurring dream of replacing developers

#317

Post by imiric » Sun, Jan 18, 2026, 7:05 AM UTC

threethirtytwo wrote: post #299

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…

The argument is empty because it relies on a trope rather than evidence. “We’ve seen this before and it didn’t happen” is not analysis. It’s selective pattern matching used when the conclusion feels safe. History is full of technologies that tried to replace human labor and failed, and just as full of technologies that failed repeatedly and then abruptly succeeded. The existence of earlier failures proves nothing in…

> “We’ve seen this before and it didn’t happen” is not analysis. It’s selective pattern matching used when the conclusion feels safe.

> If you want to argue seriously, you have to start with ground truth. What is happening now. What the trendlines look like. What follows if those trendlines continue.

Wait, so we can infer the future from "trendlines", but not from past events? Either past events are part of a macro trend, and are valuable data points, or the micro data points you choose to focus on are unreliable as well. Talk about selection bias...

I would argue that data points that are barely a few years old, and obscured by an unprecedented hype cycle and gold rush, are not reliable predictors of anything. The safe approach would be to wait for the market to settle, before placing any bets on the future.

> 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.

What is hypothetical is what will happen to all this software and the companies that produced it a few years down the line. How reliable is it? How maintainable is it? How many security issues does it have? What has the company lost because those issues were exploited? Will the same people who produced it using these new tools be able to troubleshoot and fix it? Will the tools get better to allow them to do that?

> The reason this argument keeps reappearing has little to do with tools and everything to do with identity.

Really? Everything? There is no chance that some people are simply pointing out the flaws of this technology, and that the marketing around it is making it out to be far more valuable than it actually is, so that a bunch of tech grifters can add more zeroes to their net worth?

I don't get how anyone can speak about trends and what's currently happening with any degree of confidence. Let alone dismiss the skeptics by making wild claims about their character. Do better.

Re: The recurring dream of replacing developers

#318

Post by yunohn » Sun, Jan 18, 2026, 7:14 AM UTC

TeMPOraL wrote: post #274

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…

Counterpoint: perhaps it's not about escaping all the details, just the irrelevant ones, and the need to have them figured out up front. Making the process more iterative, an exploration of medium under supervision or assistance of domain expert, turns it more into a journey of creation and discovery, in which you learn what you need (and learn what you need to learn) just-in-time. I see no reason why this wouldn't b…

> no programming language supports the notion of "just do the usual" or "I don't care, pick whatever, we can revisit the topic once the choice matters"

Programming languages already take lots of decisions implicitly and explicitly on one’s behalf. But there are way more details of course, which are then handled by frameworks, libraries, etc. Surely at some point, one has to take a decision? Your underlying point is about avoiding boilerplate, and LLMs definitely help with that already - to a larger extent than cookie cutter repos, but none of them can solve IRL details that are found through rigorous understanding of the problem and exploration via user interviews, business challenges, etc.

Re: The recurring dream of replacing developers

#319

Post by yunohn » Sun, Jan 18, 2026, 7:16 AM UTC

christophilus wrote: post #279

fragmede wrote: post #276

Earlier quoted context omitted.

Can you give an example of an "other stuff"?

I once wrote software that had to manage the traffic coming into a major shipping terminal- OCR, gate arms, signage, cameras for inspecting chassis and containers, SIP audio comms, RFID readers, all of which needed to be reasoned about in a state machine, none of which were reliable. It required a lot of on the ground testing and observation and tweaking along with human interventions when things went wrong. I’d gues…

Don’t you understand? That’s why all these AI companies are praying for humanoid robots to /just work/ - so we can replace humans mentally and physically ASAP!

Re: The recurring dream of replacing developers

#320

Post by yunohn » Sun, Jan 18, 2026, 7:19 AM UTC

fenwick67 wrote: post #214

jackfranklyn wrote: post #52

[flagged]

The honest truth is it can go either way, really. Just ask all the sign-painters and portrait artists how their career is going

Well, if we’re comparing all jobs to all other jobs - then you may have a valid point. Otherwise, we should probably focus on comparing complexity and supply/demand for the skills and output being spoken about.