Live data from Hacker News

The recurring dream of replacing developers

caimito.net

321–330 of 535 posts

Re: The recurring dream of replacing developers

#321
post #317

Earlier quoted context omitted.

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

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

If past events can be dismissed as “noise,” then so can selectively chosen counterexamples. Either historical outcomes are legitimate inputs into a broader signal, or no isolated datapoint deserves special treatment. You cannot appeal to trendlines while arbitrarily discarding the very history that defines them without committing selection bias.

When large numbers of analogous past events point in contradictory directions, individual anecdotes lose predictive power. Trendlines are not an oracle, but once the noise overwhelms the signal, they are the best approximation we have.

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

These are legitimate questions, and they are all speculative. My expectation is that code quality will decline while simultaneously becoming less relevant. As LLMs ingest and reason over ever larger bodies of software, human oriented notions of cleanliness and maintainability matter less. LLMs are far less constrained by disorder than humans are.

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

The flaws are obvious. So obvious that repeatedly pointing them out is like warning that airplanes can crash while ignoring that aviation safety has improved to the point where you are far more likely to die in a car than in a metal tube moving at 500 mph.

Everyone knows LLMs hallucinate. That is not contested. What matters is the direction of travel. The trendline is clear. Just as early aviation was dangerous but steadily improved, this technology is getting better month by month.

That is the real disagreement. Critics focus on present day limitations. Proponents focus on the trajectory. One side freezes the system in time; the other extrapolates forward.

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

Because many skeptics are ignoring what is directly observable. You can watch AI generate ultra complex, domain specific systems that have never existed before, in real time, and still hear someone dismiss it entirely because it failed a prompt last Tuesday.

Repeating the limitations is not analysis. Everyone who is not a skeptic already understands them and has factored them in. What skeptics keep doing is reciting known flaws while refusing to reason about what is no longer a limitation.

At that point, the disagreement stops being about evidence and starts looking like bias.

Re: The recurring dream of replacing developers

#322
post #311

Earlier quoted context omitted.

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

That still requires you to evaluate all the details in order to figure out which you care about. And if you haven't built a kitchen before you, won't know what the details even are ahead of time. Which means you need to be involved in the process, constantly evaluating whether what is currently happening and if you need to care about it.

Re: The recurring dream of replacing developers

#323
post #280

Earlier quoted context omitted.

>COBOL was supposed to let managers write programs. VB let business users make apps. Squarespace killed the need for web developers. And now AI. The first line made me laugh out loud because it made me think of an old boss who I enjoyed working with but could never really do coding. This boss was a rockstar at the business side of things and having worked with ABAP in my career, I couldn't ever imagine said person wr…

Many business people I've worked with are handy with SQL, but couldn't write e.g. go or python, which always surprised me. IMO SQL is way more inconsistent and has a mental model far more distant from real life than common imperative programming (which simply parallels e.g. a cookbook recipe).

>Yes I have seen this as well.

I find SQL becomes a "stepping stone" to level up for people who live and breathe Excel (for obvious reasons).

Now was SQL considered some sort of tool to help business people do more of what coders could do? Not too sure about that. Maybe Access was that tool and it just didn't stick for various reasons.

Re: The recurring dream of replacing developers

#324
post #158

Earlier quoted context omitted.

This project is completely built using claude code: https://github.com/ako/backing-tracks Most of the features take less than 30 minutes.

This isn't that impressive when there are mountains of training data dealing with exactly this... how about something truly unique and not something already available to the masses in hundreds of different forms? Like cool, you killed boiled a few gallons of the ocean but are you really impressed that you made a basic music app that is extremely limited?

So we’re now in a world where this isn’t impressive anymore? How quickly expectations change. Having started with basic and then 6502 assembly over 40 years ago, this still feels like science fiction to me.

But most enterprise software does not need to be innovative, its needs to be customizable enough that enterprises can differentiate their business. This makes existing software ideas so much more configurable. No more need for software to provide everything and the kitchen sink, but exactly that what you as a customer want.

Like in my example, I don’t know of any software that has exactly this feature set. Do you?

Re: The recurring dream of replacing developers

#325

Earlier quoted context omitted.

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…

From my experience the issue really is, unfortunately, that it is impossible to tell if a particular detail is irrelevant until after you have analyzed and answered all of them. In other words, it all looks easy in hindsight only.

I think the the most coveted ability of a skilled senior developer, is precisely this "uncanny" ability to predict beforehand if some particular detail is important or irrelevant. This ability can only be obtained through years of experience and hubris.

Re: The recurring dream of replacing developers

#326
post #53

I've watched this pattern play out in systems administration over two decades. The pitch is always the same: higher abstractions will democratise specialist work. SREs are "fundamentally different" from sysadmins, Kubernetes "abstracts away complexity." In practice, I see expensive reinvention. Developers debug database corruption after pod restarts without understanding filesystem semantics. They recreate monitoring…

Where have you worked? I have seen this mentality among the smartest most accomplished people I've come across who do things like debug kernel issues at Google Cloud. Yes, those people need to really know fundamentals. 90% of people building whatever junk their company needs does not. I learned this lesson the hard way after working at both large and tiny companies. Its the people that remain in the bubble of places…

I haven’t worked anywhere special.

The issues I’m talking about are: “we can’t debug kernel issues, so we run 40 pods and tune complicated load balancers health-check procedures in order for the service to work well”.

There is no understanding that anything is actually wrong, for they think that it is just the state of the universe, a physical law that prevents whatever issue it is from being resolved. They aren’t even aware that the kernel is the problem, sometimes they’re not even aware that there is a problem, they just run at linear scale because they think they must.

Re: The recurring dream of replacing developers

#327

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 rings true and reminds me of the classic blog post “Reality Has A Surprising Amount Of Detail”[0] that occasionally gets reposted here. Going back and forth on the detail in requirements and mapping it to the details of technical implementation (and then dealing with the endless emergent details of actually running the thing in production on real hardware on the real internet with real messy users actually using…

  > Reality Has A Surprising Amount Of Detail
Every time we make progress complexity increases and it becomes more difficult to make progress. I'm not sure why this is surprising to many. We always do things to "good enough", not to perfection. Not that perfection even exists... "Good enough" means we tabled some things and triaged, addressing the most important things. But now to improve those little things now need to be addressed.

This repeats over and over. There are no big problems, there are only a bunch of little problems that accumulate. As engineers, scientists, researchers, etc our literal job is to break down problems into many smaller problems and then solve them one at a time. And again, we only solve them to the good enough level, as perfection doesn't exist. The problems we solve never were a single problem, but many many smaller ones.

I think the problem is we want to avoid depth. It's difficult! It's frustrating. It would be great if depth were never needed. But everything is simple until you actually have to deal with it.

Re: The recurring dream of replacing developers

#328
post #319

Earlier quoted context omitted.

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!

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 slave class of artificial life forms.

Re: The recurring dream of replacing developers

#329
post #311

Earlier quoted context omitted.

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

Which three? To which people? Congrats, you've discovered integration hell

Re: The recurring dream of replacing developers

#330

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…

It's a cliché that the first 90% of a software project takes 90% of the time and the last 10% also takes 90% of the time, but it's cliché because it's true. So we've managed to invent a giant plausibility engine that automates the 90% of the process people enjoy leaving just the 90% that people universally hate.
Post reply on HN