Live data from Hacker News

Firing programmers for AI is a mistake

defragzone.substack.com

711–720 of 886 posts

Re: Firing programmers for AI is a mistake

#711
There's also the issue of a company doesn't own the copyright to a codebase generated primarily through prompts.

So anyone can copy it and reproduce it anywhere. Get paid to prompt ai by a company. Take all code home with you. Then when your tired of them use same code to undercut them.

Re: Firing programmers for AI is a mistake

#712
post #554

Earlier quoted context omitted.

Google Maps has some strange feedback loops. I frequently drive across the Bay Bridge to Delaware beaches. There are 2 or 3 roughly equal routes with everyone going to the same destination. Google will find a "shorter" route every 5 minutes. Naturally, Maps is smart enough to detect traffic, but not smart enough to equally distribute users to prevent it. It creates a traffic jam on route A, then tells all the users t…

It hadn't even occurred to me that there are places where enough people are using Google Maps while driving to cause significant impact on traffic patterns. Being car-free (and smartphone-free) really gives a different perspective.

This is also problematic in cases where navigation apps are not updated and drivers start taking routes they are no longer authorized to take.

Re: Firing programmers for AI is a mistake

#713

Earlier quoted context omitted.

Difference here being that you actually learned the information about Ruby on Rails, whereas the modern programmer doesn't learn anything. They are but a clipboard-like vessel that passes information from an LLM onto a text editor, rarely ever actually reading and understanding the code. And if something doesn't work, they don't debug the code, they debug the LLM for not getting it right. The actual knowledge here ne…

Difference here being that you actually learned the information about computers, whereas the modern programmer doesn't learn anything. They are but a typist-like vessel that passes information from an architect onto a text editor, rarely ever actually reading and understanding the compiled instructions. And if something doesn't work, they don't debug the machine code, they complain about the compiler for not getting…

No, it really isn't at all comparable like that (and other discussion in the thread makes it clear why). Users of high-level languages clearly still do write code in those languages, that comes out of their own thought rather than e.g. the GoF patterns book. They don't just complain about compilers; they actually do debug the high-level code, based on the compiler's error messages (or, more commonly, runtime results). When people get their code from LLMs, however, you can see very often that they have no idea how to proceed when the code is wrong.

Debugging is a skill anyone can learn, which applies broadly. But some people just don't. People who want correct code to be written for them are fundamentally asking something different than people who want writing correct code to be easier.

Re: Firing programmers for AI is a mistake

#714

Earlier quoted context omitted.

I think you're right; I can see it in the accelerating growth curve of my good Junior devs; I see grandOP's vision in my bad Junior devs. Optimistically, I think this gives more jr devs more runway to advance deeper into more sophisticated tech stacks. I think we're gonna need more SW devs, not fewer, as these tools get better: things that were previously impossible will be possible.

I agree with this stance. Junior developers are going to learn faster than previous generations, and I'm happy for it. I know that is confronting for a lot of people, but I think it is better to accept it, and spend time thinking about what your experience is worth. (A lot!)

>Junior developers are going to learn faster than previous generations, and I'm happy for it.

I would have agreed, until I started seeing the kinds of questions they're asking.

Re: Firing programmers for AI is a mistake

#715

Earlier quoted context omitted.

> The second assumption is also wrong, intelligent companies will not layoff en masse to use AI only, they will most likely slow hiring devs because their existing enhanced devs using AI will suffice enough to their coding related needs After 20 years in tech, I can't think of a single company I've worked for/with that would fit the profile of an "intelligent" company. All of them make poor and irrational decisions r…

> After 20 years in tech, I can't think of a single company I've worked for/with that would fit the profile of an "intelligent" company. All of them make poor and irrational decisions regularly. I think you over-estimate the intelligence of leadership whilst simultaneously under-estimating their greed and eventual ability to self-destruct. Says nothing about companies and everything about you > you also over-estimate…

I'm happy you've only worked for altruistic, not-for-profit minded companies that care about employee growth and takes pride in their tach stack above all else. I have not had as fortunate an experience.

>I expect that once many begin to do this, there will be some who do use it for productivity and they will set the bar.

Yeah, probably. I've had companies so pinpointed on "velocoity" instead of quality. I imagine they will definitely try to expect triple the velocity just because one person "gets so much done". Not realizing how much of that illusion is correcting the submissions.

Re: Firing programmers for AI is a mistake

#717

Earlier quoted context omitted.

he's not, just another delusional venture capitalist that hasn't bothered to look up the counter arguments to his point of view, done by mathematicians

> he's not, just another delusional venture capitalist that hasn't bothered to look up the counter arguments to his point of view, done by mathematicians Don’t hate on it, just spin up some startup with “ai” and LLM hype. Juice that lemon.

Sadly my goals are more more ephemeral than opening up a lemonade stand.

Re: Firing programmers for AI is a mistake

#718

When the AI dust settles, I wonder who will be left standing among the groups of developers, testers, scrum masters, project leaders, department managers, compliance officers, and all the other roles in IT. It seems the general sentiment is that developers are in danger of being replaced entirely. I may be biased, but it seems not to be the most likely outcome in the long term. I can't imagine how such companies will…

Please take the scrum masters first.

Re: Firing programmers for AI is a mistake

#719
post #144

There's such a huge disconnect between people reading headlines and developers who are actually trying to use AI day to day in good faith. We know what it is good at and what it's not. It's incredibly far away from doing any significant change in a mature codebase. In fact I've become so bearish on the technology trying to use it for this, I'm thinking there's going to have to be some other breakthrough or something…

They all sounds like crypto bros talking about AI. It's really frustrating to talk to them, just like crypto bros.

They're the same people in my experience.

Re: Firing programmers for AI is a mistake

#720
post #144

There's such a huge disconnect between people reading headlines and developers who are actually trying to use AI day to day in good faith. We know what it is good at and what it's not. It's incredibly far away from doing any significant change in a mature codebase. In fact I've become so bearish on the technology trying to use it for this, I'm thinking there's going to have to be some other breakthrough or something…

I dunno if it's always good at explaining code. It tends to take everything at face value and is unable to opinionatedly reject bs when it's presented with it. Which in the majority of cases is bad.

this is also my problem. When I ask someone a technical question, and I did not provide context on some abstractions. Usually this is common because abstractions can be very deep. "Hmm, not sure.. can you check what's this supposed to do?"

LLMs don't do this, it confidently hallucinate the abstraction out of thin air or uses their outdated knowledge store. Sending wrong use or wrong input parameters.

Post reply on HN