Live data from Hacker News

Firing programmers for AI is a mistake

defragzone.substack.com

431–440 of 886 posts

Re: Firing programmers for AI is a mistake

#431

Earlier quoted context omitted.

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…

Isn’t this kind of thing the story of tech though? Languages like Python and Java come around, and old-school C engineers grouse that the kids these days don’t really understand how things work, because they’re not managing memory. Modern web-dev comes around and now the old Java hands are annoyed that these new kids are just slamming NPM packages together and polyfills everywhere and no one understands Real Software…

LLMs are a much bigger jump in productivity than moving to a high level language.

Re: Firing programmers for AI is a mistake

#432
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 of it as an enabler that reduces my dependency on junior developers. Instead of delegating simple stuff to them, I now do it myself with about the same amount of overhead (have to explain what I want, have to triple check the results) on my side but less time wasted on their end.

A lot of micro managing is involved either way. And most LLMs suffer from a severe case of ground hog day. You can't assume them to remember anything over time. Every conversation starts from scratch. If it's not in your recent context, specify it again. Etc. Quite tedious but it still beats me doing it manually. For some things.

For at least the next few years, it's going to be an expectation from customers that you will not waste their time with stuff they could have just asked an LLM to do for them. I've had two instances of non technical CPO and CEO types recently figuring out how to get a few simple projects done with LLMs. One actually is tackling rust programs now. The point here is not that that's good code but that neither of them would have dreamed about doing anything themselves a few years ago. The scope of the stuff you can get done quickly is increasing.

LLMs are worse at modifying existing code than they are at creating new code. Every conversation is a new conversation. Ground hog day, every day. Modifying something with a lot of history and context requires larger context windows and tools to fill those. The tools are increasingly becoming the bottleneck. Because without context the whole thing derails and micromanaging a lot of context is a chore.

And a big factor here is that huge context windows are costly so there's an incentive for service providers to cut some corners there. Most value for me these days come from LLM tool improvements that result in me having to type less. "fix this" now means "fix the thing under my cursor in my open editor, with the full context of that file". I do this a lot since a few weeks.

Re: Firing programmers for AI is a mistake

#433
post #333

Earlier quoted context omitted.

I love that you brought no-code tools into this because I think it's interesting it never worked correctly. My guess is: on one side, things like squarespace and wix get super super good for building sites that don't feel like squarespace and wix, (I'm not sure I'd want to be a pure "website dev" right now - although I think squarespace squashed a lot of that long ago) - and then very very nice tooling for "real engi…

Excel is a "no-code" system and people seem to like it. Of course, sometimes it tampers with your data in horrifying ways because something you entered (or imported into the system from elsewhere) just happened to look kinda like a date, even though it was intended to be something completely different. So there's that.

> Excel is a "no-code" system and people seem to like it.

If you've found any Excel guru that don't spend most of their time in VBA, you have a really unusual experience.

Re: Firing programmers for AI is a mistake

#434

Earlier quoted context omitted.

Yea, every progeammer should write at least a cpu emulator in their language of choice, its such a undervalued exercise that will teach you so much about how stuff really works.

You can go to the next step. I studied computer engineering not computer science in college. We designed our own CPU and then implemented it in an FPGA. You can go further and design it out of discrete logic gates. Then write it in Verilog. Compare the differences and which made you think more about optimizations.

"in order to bake a pie you must first create the universe", at some point, reaching to lower and lower levels stops being useful.

Re: Firing programmers for AI is a mistake

#435

Earlier quoted context omitted.

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 we who are already in tech have this gleeful fantasy that new tools impair newcomers in a way that will somehow serve us, the incumbents, in some way. But in reality pretty much anyone who enters software starts off cutting corners just to build things instead of working their way up from nand gates. And then they backfill their knowledge over time. My first serious foray into software wasn't even Ruby. It wa…

Great points. I see my journey from an offshore application support contractor to full time engineer and learning a lot along the way. Along the journey I've seen folks who held good/senior engineering roles just stagnated or moved to management role.

Industry is now large enough to have all sort of people. Growing, stagnating, moving out, moving in, laid off, retiring early, or just plain retiring etc.

Re: Firing programmers for AI is a mistake

#436

Earlier quoted context omitted.

I don't think my comment read as snarky but I was surprised to see the immediate downvote which presumably came from you so I only added the last sentence. This is a stupid way of disagreeing and attempting to shut down the discussion without merits. > It doesn't work. Even the models that claim to have really large context windows get very distracted if you don't selectively pick relevant context. I thought Devon is…

> I don't think my comment read as snarky but I was surprised to see the immediate downvote which presumably came from you so I only added the last sentence. I can't downvote you because you are downthread of me. HN shadow-disables downvotes on all child and grandchild comments. I'm the one who upvoted you to counteract the downvote. :)

Ok, sorry about that.

Re: Firing programmers for AI is a mistake

#437
Today AI can generate code. Sometimes it's even correct.

AI is a useful aid to software developers, but it requires developers to know what they're doing. We need developers to know more, not less, so they can review AI-generated code, fix it when it's wrong, etc.

Re: Firing programmers for AI is a mistake

#438

Earlier quoted context omitted.

Yea, i agree fully. real programming of course wont go away. But in the public eye it lost its mysticism as seemingly anyone can code now. Of course that aint true and noone managed to create anything of substance by prompting alone.

How do we define real programming? I'm working on python and JS codebases in my startup. So very high level stuff. However to reason well about everything that goes on in our code is no small feat for an LLM (or a human), if its able to take our requirements , understand the business logic and just start refactoring and creating new features on a codebase that is quite big, well yeah, that sounds like AGI to me. In t…

The fact that you don't see why is the issue. Both python and JS are very permissive and their runtime env is very good. More often than not, you're just dealing with logic bugs and malformed domain data. A kernel codebase like Linux is one where there are many motivated individual trying every trick to get the computer to do something. And you're usually dealing with leaner abstractions because general safety logic is not performant enough. It's a bit like the difference between a children playground and a construction site.

Re: Firing programmers for AI is a mistake

#439

Earlier quoted context omitted.

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 we who are already in tech have this gleeful fantasy that new tools impair newcomers in a way that will somehow serve us, the incumbents, in some way. But in reality pretty much anyone who enters software starts off cutting corners just to build things instead of working their way up from nand gates. And then they backfill their knowledge over time. My first serious foray into software wasn't even Ruby. It wa…

[dead]

Re: Firing programmers for AI is a mistake

#440
post #412

Earlier quoted context omitted.

> Why wouldn't this be the case for people using LLM like it was for everyone else? I feel like it's a bit different this time because LLMs aren't just an abstraction. To make an analogy: Ruby on Rails serves a similar role as highways—it's a quick path to get where you're going, but once you learn the major highways in a metro area you can very easily break out and explore and learn the surface streets. LLMs are a G…

I think also a critical weakness is that LLMs are trained on the code people write ... and our code doesn't annotate what was written by a human and what was suggested by a tool. In your analogy, this would be like if your sat nav system suggests that you turn right where other people have turned right ... because they were directed to turn by their sat nav.

In fact, I'm pretty sure this already happens and the results are exactly what you'd expect. Some of the "alternate routes" Google Maps has suggested for me in the past are almost certainly due to other people making unscheduled detours for gas or whatever, and the algorithm thinks "oh this random loop on a side street is popular, let's suggest it". And then anyone silly enough to follow the suggestion just adds more signal to the noise.
Post reply on HN