Live data from Hacker News

The recurring dream of replacing developers

caimito.net

491–500 of 535 posts

Re: The recurring dream of replacing developers

#491
post #372

Earlier quoted context omitted.

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

> 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. I'm confused. So you're agreeing with me, up unti…

>I'm confused. So you're agreeing with me, up until the very last part of the last sentence...? If the "noise overwhelms the signal", why are "trendlines the best approximation we have"? We have reliable data of past outcomes in similar scenarios, yet the most recent noisy data is the most valuable? Huh?

Let me help you untangle the confusion. Historical data on other phenomenons is not a trendline for AI taking over your job. It's a typical logical mistake people make. It's reasoning via analogy. Because this trend happened for A, and A fits B like an analogy therefore what happened to A must happen to B.

Why is that stupid logic? Because there are thousands of things that fit B as an analogy. And out of those thousands of things that fit, some failed and some succeeded. What you're doing and not realizin is you are SELECTIVELY picking the analogy you like to use as evidence.

When I speak of a trendline. It's deadly simple. Literally look at AI as it is now, as it is in the past and use that to project into the future. Look at exact data of the very thing you are measuring rather then trying to graft some analogous thing onto the current thing and make a claim from that.

>What you're doing is similar to speculative takes during the early days of the internet and WWW. How it would transform politics, end authoritarianism and disinformation, and bring the world together. When the dust settled after the dot-com crash, actual value of the technology became evident, and it turns out that none of the promises of social media became true. Quite the opposite, in fact. That early optimism vanished along the way.

Again same thing. The early days of the internet is not what's happening to AI currently. You need to look at what happened to AI and software from the beginning to now. Observe the trendline of the topic being examined.

>I think neither of these viewpoints are worth paying attention to. As usual, the truth is somewhere in the middle. I'm leaning towards the skeptic side simply because the believers are far louder, more obnoxious, and have more to gain from pushing their agenda. The only sane position at this point is to evaluate the technology based on personal use, discuss your experience with other rational individuals, and wait for the hype to die down.

Well if you look at the pace and progress of AI, the quantitative evidence points against your middle ground opinion here. It's fashionable to take the middle ground because moderates and grey areas seem more level headed and reasonable than extremism. But this isn't really applicable to reality is it? Extreme events that overload systems happen in nature all the time, taking the middle ground without evidence pointing to the middle ground is pure stupidity.

So all you need to look at is this, in the past decade look at the progress we've made until now. A decade ago AI via ML was non-existent. Now AI generates movies, music and code, and unlike AI in music and movies, code is being in actuality used by engineers.

That's ZERO to coding in a decade. What do you think the next decade will bring. Coding to what? That is reality and the most logical analysis. Sure it's ok to be a skeptic, but to ignore the trendline is ignorance.

Re: The recurring dream of replacing developers

#492

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 looks there's a difference this time: copying the details of other people's work has become exceedingly easy and reliable, at least for commonly tried use cases. Say I want to vibe code a dashboard, and AI codes it out. It works. In fact, it works so much better than I could ever build, because the AI was trained with the best dashboard code out there. Yes, I can't think of all the details of a world-class dashboa…

But the dashboard is not important at all, because everyone can have the same dashboard the same way you have it. It's like you are generating a static website using Hugo and apply a theme provided on it. The end product you get is something built by a streamline. No taste, no soul, no effort. (Of course, the effort is behind the design and produce of the streamline, but not the product produced by the streamline.)

Now, if you want to use the dashboard do something else really brilliant, it is good enough for means. Just make sure the dashboard is not the end.

Re: The recurring dream of replacing developers

#493

Earlier quoted context omitted.

I still think it's more likely to be more of the same thing but with less people. One man shops being the ideal, and I don't think there will be proportionately more of them

This doesn't mesh with anything that has happened in the development of computing, or technology in general.

I dispute technology in general. There are plenty of examples where industrialisation led to a drop in quality, a massive drop in price, and a displacement of workers.

It hasn't happened in software yet. I suppose this has to do with where software sits on the demand curve currently.

I'm imagining a few more shifts in productivity will make the demand vs price derivative shift in a meaningfully different way, but we can only speculate.

Re: The recurring dream of replacing developers

#494
post #492

Earlier quoted context omitted.

It looks there's a difference this time: copying the details of other people's work has become exceedingly easy and reliable, at least for commonly tried use cases. Say I want to vibe code a dashboard, and AI codes it out. It works. In fact, it works so much better than I could ever build, because the AI was trained with the best dashboard code out there. Yes, I can't think of all the details of a world-class dashboa…

But the dashboard is not important at all, because everyone can have the same dashboard the same way you have it. It's like you are generating a static website using Hugo and apply a theme provided on it. The end product you get is something built by a streamline. No taste, no soul, no effort. (Of course, the effort is behind the design and produce of the streamline, but not the product produced by the streamline.) N…

Dashboard is just an example. The gist is how much of know-how that we use in our work can be replaced by AI transforming other people's existing work. I think it hinges on how many new problems or new business demands will show up. If we just work on small variations of existing business, then quickly our know-hows will converge (e.g. building a dashboard or a vanilla version of linear regression model), and AI will spew out such code for many of us.

Re: The recurring dream of replacing developers

#495

Earlier quoted context omitted.

This doesn't mesh with anything that has happened in the development of computing, or technology in general.

I dispute technology in general. There are plenty of examples where industrialisation led to a drop in quality, a massive drop in price, and a displacement of workers. It hasn't happened in software yet. I suppose this has to do with where software sits on the demand curve currently. I'm imagining a few more shifts in productivity will make the demand vs price derivative shift in a meaningfully different way, but we…

I think you are misunderstanding the point I'm making. I agree that "writing code" is likely to be commoditized by AI tools, much like past industrialization disruptions. But I think there is going to be more things to do in the space of "doing useful things with computers", analogous to how industrialization creates new work further up the value chain.

Of course it often isn't the same people whose jobs are disrupted who end up doing that new work.

Re: The recurring dream of replacing developers

#496

Earlier quoted context omitted.

> perhaps it's not about escaping all the details, just the irrelevant ones But that's the hard part. You have to explore the details to determine if they need to be included or not. You can't just know right off the back. Doing so contradicts the premise. You cannot determine if a detail isn't important unless you get detailed. If you only care about a few grains of sand in a bucket you still have to search through…

Right. But that's where tight feedback loop comes into place. New AI developments enable that in at least two ways: offloading busywork and necessary but straightforward work (LLMs can already write and iterate orders of magnitude faster than people), and having a multi-domain expert on call to lean on. The thing about important details is that what ultimately matters is getting them right eventually , not necessaril…

  > and having a multi-domain expert on call to lean on.
I don't feel like this is an accurate description. My experience is that LLMs have a very large knowledge base but that getting them to go in depth is much more difficult.

But we run into the same problem... how do you evaluate that which you are not qualified to evaluate? It is a grave mistake to conflate "domain expert" with "appears to know more than me". Doesn't matter if it is people or machine, it is a mistake. It's how a lot of conartists work, and we've all seen people who are in high positions and we're all left wondering how in the world they got there.

  > The real cost limiting creative and engineering efforts isn't the one of making a bad choice, but that of undoing it.
Weird reasoning... because I agree and this is the exact reason I find LLMs painful to work with. They dump code at you rather than tightening it up, making it clear and elegant. Code is just harder to rebase or simplify when there are more lines. Writing lines has never been and never will be the bottleneck because the old advice still holds true that if you're doing things over and over again, you're doing it wrong. One of the key things that makes programming so amazing is that you can abstract out repetitive tasks, even when there is variation. Repetition and replication only make code harder to debug and harder to "undo bad choices".

Also, in my experience it is even difficult to get LLMs to simplify, even when explicitly instructing them to and pointing them to specific functions and even giving strong hints of what exactly needs to be done. They promptly tell me how smart I am and then fail to do any of that actual abstraction. Code isn't useful when you have the same function written 30 different places and 20 different files. That's way harder to back out of decisions. They're good at giving a rough sketch but it still feels reckless to me to let them actually write into the codebase where they are creating this tech debt.

Re: The recurring dream of replacing developers

#497
post #384

Earlier quoted context omitted.

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

> Experienced developers know what subsets of tests are critical, avoiding much work. And, they do know this for the programs written by other experienced developers, because they know where to expect "linearity" and were to expect steps in the output function. (Testing 0, 1, 127, 128, 255, is important, 89 and 90 likely not, unless that's part of the domain knowledge) This is not necessarily correct for statisticall…

That depends a bit on whether you view and use unit-tests for

a) Testing that the spec is implemented correctly, OR

b) As the Spec itself, or part of it.

I know people have different views on this, but if unit-tests are not the spec, or part of it, then we must formalize the spec in some other way.

If the Spec is not written in some formal way then I don't think we can automatically verify whether the implementation implements the spec, or not. (that's what the cartoon was about).

Re: The recurring dream of replacing developers

#498

Earlier quoted context omitted.

Of course that is true. The nuance here is that software isn’t just getting cheaper but the activity to build it is changing. Instead of writing lines of code you are writing requirements. That shifts who can do the job. The customer might be able to do it themselves. This removes a market, not grows one. I am not saying the market will collapse just be careful applying a blunt theory to such a profound technological…

> The customer might be able to do it themselves Have you ever paid for software? I have, many times, for things I could build myself Building it yourself as a business means you need to staff people, taking them away from other work. You need to maintain it. Run even conservative numbers for it and you'll see it's pretty damn expensive if humans need to be involved. It's not the norm that that's going to be good ROI…

You are missing the point. Who said anything about turning what they make into a “business”. Software you maintain merely for yourself has no such overhead.

Re: The recurring dream of replacing developers

#499

Earlier quoted context omitted.

There are also technical requirements, which, in practice, you will need to make for applications. Technical requirements can be done by people that can't program, but it is very close to programming. You reach a manner of specification where you're designing schemas, formatting specs, high level algorithms, and APIs. Programmers can be, and are, good at this, and the people doing it who aren't programmers would be g…

I think it's like super insane people think that anyone can just "code" an app with AI and that can replace actual paid or established open-source software, especially if they are not a programmer or know how to think like one. It might seem super obvious if you work in tech but most people don't even know what an HTTP server is or what is pytho, let alone understanding best practices or any kind of high-level thinki…

I think this comment will not age well. I understand where you are coming from. You are missing the idea that infrastructure will come along to support vibe coding. You are assuming vibe coding as it stands today will not be improved. It will get to the point where the vibe coder needs to know less and less about the underlying construction of software.

Re: The recurring dream of replacing developers

#500

Earlier quoted context omitted.

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.

>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. OK, for me it is the last 10% that is of any interest whatsoever. And I think that has been the case with any developer I've ever worked with I consider to be a good developer. OK the first 90% can have spots of enjoyment, like a nice gentle Sunday drive stoppin…

Sorry, I don't buy it. I'm an ops guy, and devs who say they like the integration stage mean they like making ops play a guessing game and clean up the mess they left us.
Post reply on HN