Live data from Hacker News

Firing programmers for AI is a mistake

defragzone.substack.com

611–620 of 886 posts

Re: Firing programmers for AI is a mistake

#611

Earlier quoted context omitted.

Amusingly, I spent years making multiples of your target comp and now I’m home sitting around using AI to make myself toy games. The barrier has dropped so low that I think I’d have been more productive if I were still working.

Not like it's going to happen for me, but how did you reach such comp. I'm a simple man. If I hit 2 million in net worth I'm done working. I don't plan on having a family, so I'm just supporting myself. If I really made a ton of money I'd fund interesting open source games. Godot is the most popular open source game engine, and they're making it happen off just 40k a month. I'm a bit surprised Microsoft hasn't filled…

Worked in HFT. But tbh everyone I know in FAANG who stuck it out is doing even better.

Re: Firing programmers for AI is a mistake

#612
Reminder to everyone reading FUD like this that tech bro's are trying _very_ hard to convince everyone that these technologies are Fundamentally Disruptive and The Most Important Advancement Since The Steam Engine. When in fact they are somewhat useful content generation machines who's output needs to be carefully vetted by the very programmers this article claims will be out of a job.

To be clear: I am not saying this article is written in bad faith and I agree that if its assertions come to pass that what it predicts would happen. I am just urging everyone to stop letting the Sam Altmans of the world tell you how disruptive this tech is. Tech is out of ideas and desperate to keep the money machine printing.

Re: Firing programmers for AI is a mistake

#613

Earlier quoted context omitted.

If you don't mind me asking, what size of codebases do you typically work on? As mentioned I've tried using all the available commercial models and none work better than as a helpful autocomplete, test, and utility function generator. I'm sure maybe big players like Meta, OpenAI, MS, etc do have the capability of expanding its context for their own internal projects and training specifically on their code, but most o…

Several millions lines of code. Can't remember any project that I was involved with and that was less than 5MLoC. C++ system level programming. Overhyped or not Devon is using something else under the hood since it is pre-processing your whole codebase. It's not "realtime" since it simulates the CoT meaning that it "works" on the patch the very same way a developer would. and therefore it will give you a resulting PR…

And you have had luck with models like the one you mentioned and Devon generating significant amounts of code in these codebases? I would love to be able to have this due to the productivity gains it should allow but I've just never been able to demonstrate what the big AI coding services claim to be able to do at a large scale.

What they already do is a decent productivity boost but not nearly as much as they claim to be capable of.

Re: Firing programmers for AI is a mistake

#614
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 think it's more likely that we'll see a rise in workflows that AI is good at, rather than AI rising to meet the challenges of our more complex workflows.

Let the user pair with an AI to edit and hot-reload some subset of the code which needs to be very adapted to the problem domain, and have the AI fine-tuned for the task at hand. If that doesn't cut it, have the user submit issues if they need an engineer to alter the interface that they and the AI are using.

I guess this would resemble how myspace used to do it, where you'd get a text box where you could provide custom edits, but you couldn't change the interface.

Re: Firing programmers for AI is a mistake

#615

Earlier quoted context omitted.

This doesn't sound right, seems like you are jumping metaphors. The computing resources are the limit on the evolution speed. There's nothing that makes an individual desirous of a faster evolution speed.

Sorry, I probably made too many unstated leaps of logic. What I meant was: Runaway self-improving AI will almost certainly involve self-replication at some point in the early stages since "make a copy of myself with some tweaks to the model structure/training method/etc. and observe if my hunch results in improved performance" is an obvious avenue to self-improvement. After all, that's how the silly fleshbags made im…

You seem to be imagining a sentience that is still confined to the prime directive of "self-improving" where that no longer is well defined at it's scale.

Re: Firing programmers for AI is a mistake

#616
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 use AI coding assistants daily, and whenever there is a task that those tools cannot do correctly/quickly enough so that I need to fallback to editing things by myself, I spend a bit of time thinking what is so special about the tasks.

My observation is that LLMs do repetitive, boring tasks really well, like boilerplate code and common logic/basic UI that thousands of people have already done. Well, in some sense, jobs where developers who spend a lot of time writing generic code is already at risk of being outsourced.

The tasks that need a ton of tweaking or not worth asking AI at all are those that are very specific to a specific product and need to meet specific requirements that often come from discussions or meetings. Well, I guess in theory if we had transcripts for everything, AI could write code like the way you want, but I doubt that's happening any time soon.

I have since become less worried about the pace AI will replace human programmers -- there is still a lot that these tools cannot do. But for sure people need to watch out and be aware of what's happening.

Re: Firing programmers for AI is a mistake

#617

This article is entirely built on 2 big and wrong assumptions: 1. AI code ability will be the same as is today 2. Companies will replace people for AI en masse at a given moment in time Of course both these assumptions are wrong, the quality of code produced by AI will improve dramatically as model evolves. And is not even just the model itself. The tooling, the Agentic capabilities and workflow will entirely change…

> 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 regularly. I think you over-estimate the intelligence of leadership whilst simultaneously under-estimating their greed and eventual ability to self-destruct.

EDIT: you also over-estimate the desire for developers to increase their productivity with AI. I use AI to reduce complexity and give me more breathing room, not to increase my output.

Re: Firing programmers for AI is a mistake

#618

Earlier quoted context omitted.

I'm not disagreeing with anything you said here - reread my comment. Sometimes you want to use the sophisticated shiny new tech because you actually need it. Here's a recent example from a real situation: The linux kernel (a boring tech these days) has a great networking stack. It's choking on packets that need to be forwarded, and you've already tuned all the queues and the cpu affinities and timers and polling. Do…

None of these seem all that 'trendy' to me. The real trendy approach would be something like leaping directly to a hybrid userspace-kernelspace solution using something like https://github.com/CloudNativeDataPlane/cndp and/or the https://www.kernel.org/doc/html/latest/networking/af_xdp.htm... addressing that the former is built on. Very interesting stuff, don't get me wrong there - but hardly something that can be sa…

I have similar examples from other projects of using io_uring and af_xdp with similar outcomes. In 2020 when the ebpf decision was made it was pretty new an trendy still too... in a few cases each of these choices required us to wait for deployment until some feature we chose to depend on landed in a mainline kernel. Things move a bit slower that far down the stack so new doesn't mean "the js framework of the week", but it's still the trendy unproven thing vs the well-known path.

The point is still: evaluate the options for real - using the new thing because it's new and exicting is equally as foolish as use the boring thing because it's well-proven... if those are your main criteria.

Re: Firing programmers for AI is a mistake

#619
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 think that LLMs are only going to make people with real tech/programming skills much more in demand, as younger programmers skip straight into prompt engineering and never develop themselves technically beyond the bare minimum needed to glue things together. The gap between people with deep, hands-on experience that understand how a computer works and prompt engineers will become so insanely deep. Somebody needs to…

I think I've seen the comparison with respect to training data, but it's interesting to think of the presence of LLMs as a sort of barrier to developing skills akin to pre-WW2 low background radiation steel (which, fun fact, isn't actually that relevant anymore, since background radiation levels have dropped significantly since the partial end of nuclear testing)

Re: Firing programmers for AI is a mistake

#620
Most programmers are not worth anything. Firing them for ai or no reason at all, will not change anything.

Whether ai can do stuff comparable to a competent senior sde, remains to be seen. But current AI definitely feels like a super assistant when I'm doing something.

Anyone who says chatgpt/Claude/copilot etc are bad, is suffering a skill issue. I'd go as far as to say they are really bad at working with junior engineers. Really bad as teachers too.

Post reply on HN