Replacing juniors with AI is stupid because who will be the next senior? AI won't learn anything while performing inference only.
Firing programmers for AI is a mistake
571–580 of 886 posts
Re: Firing programmers for AI is a mistake
#572Earlier quoted context omitted.
Sophistication doesn't imply any increase or decrease in "boringness".
The dictionary definition of 'sophisticated' is "changed in a deceptive or misleading way; not genuine or pure; unrefined, adulterated, impure." Pretty much the polar opposite of "boring" in a technology context.
No clue what dictionary you looked at but this is not at all what dictionaries actually say.
Re: Firing programmers for AI is a mistake
#573If you are a junior engineer who just graduated, what would you do to ensure that you learn the needed skills and not be overly reliant on AI?
Well before AI, us old guys had to google our own issues and copy/paste from stackoverflow. When I was a junior I never thought about being overly reliant on "google or stackoverflow", but LLMs are slightly different. I guess it would be like if I googled something and always trusted the first result. Maybe for your question it means not copying/pasting immediately what the LLM gives you and have it explain. Wasting a few mins on asking the LLM to explain, for the sake of learning, still beats the amount of time I used to waste scanning google results.
Re: Firing programmers for AI is a mistake
#574Earlier quoted context omitted.
That's great advice when you're building a simple CRUD app - use the paved roads for the 10^9th instance. It's terrible advice when you're building something that will cause that boring tech to fall over. Or when you've reached the limits of that boring tech and are still growing. Or when the sophisticated tech lowers CPU usage by 1% and saves your company millions of dollars. Or when that sophisticate tech saves you…
"Boring" tech stacks tend to be highly scalable in their own right - certainly more so than the average of trendy newfangled tech. So what's a lot more likely is that the trendy newfangled tech will fail to meet your needs and you'll be moving to some even newer and trendier tech, at surprisingly high cost. The point of picking the "boring" choice is that it keeps you off that treadmill.
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 you -
a) buy more servers and network gear to spread your packets across more machines? (boring and expensive and introduces new ongoing costs of maintenance, datacenter costs, etc).
b) Write a kernel module to process your packets more efficiently? (a boring, well known solution, introduces engineer costs to make and maintain as well as downtime because the new shiny module is buggy?)
c) Port your whole stack to a different OS (risky, but choosing a different boring stack should suffice... if youre certain that it can handle the load without kernel code changes/modules).
d) Write a whole userspace networking system (trendy and popular - your engineers are excited about this, expensive in eng time, risks lots of bugs that are already solved by the kernel just fine, have to re-invent a lot of stuff that exists elsewhere)
e) Use ebpf to fast path your packets around the kernel processing that you don't need? (trendy and popular - your engineers are excited about this, inexpensive relative to the other choices, introduces some new bugs and stability issues til the kinks are worked out)
We sinned and went with (e). That new-fangled tech met our needs quite well - we still had to buy more gear but far less than projected before we went with (e). We're actually starting to reach limits of ebpf for some of our packet operations too so we've started looking at (d) which has come down in costs and risk as we understand our product and needs better.
I'm glad we didn't go the boring path - our budget wasn't eaten up with trying to make all that work and we could afford to build features our customers buy instead.
We also use postgres to store a bunch of user data. I'm glad we went the boring path there - it just works and we don't have to think about it, and that lack of attention has afforded us the chance to work on features customers buy instead.
The point isn't "don't choose boring". It's: blindly choosing boring instead of evaluating your actual needs and options from a knowledgeable place is unwise.
Re: Firing programmers for AI is a mistake
#575This is missing the fact that budding programmers will also embrace these technologies, in order to get stuff done and working and fulfill their curiosity. They will in fact grow up to be much more "AI native" than current more senior programmers, except that they are turbocharging their exploration and learning by having, well, a full team of AI programmers at their disposal. I see it like when I came of age in the…
AI native like recent digital natives, who have more time using software but far less time exploring how it works and less overall success at using digital tools? AI reminds me of calculators. For someone who is proficient in math, they boost speed. For those learning math, it becomes a crutch and eventually stops their ability to learn further because their mind can't build upon principles fully outsourced to the ma…
Yet calculators don't seem to have reduced the number of people in mathematics, engineering and other mathematics heavy fields. Why would it be any different with people using AI to learn coding?
Re: Firing programmers for AI is a mistake
#576Earlier quoted context omitted.
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…
Long before any use of LLMs, OsmAnd would direct you, if you were driving past Palo Alto, to take a congested offramp to the onramp that faced it across the street. There is no earthly reason to do that; just staying on the freeway is faster and safer. So it's not obvious to me that patently crazy directions must come from watching people's behavior. Something else is going on.
In Australia the routes seem to be overly influenced by truck drivers, at least out of the cities. Maps will recommend you take some odd town bypass when just going down Main Street is easier.
I imagine what you saw is some other frequent road users making choices that get ranked higher.
Re: Firing programmers for AI is a mistake
#577Earlier 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 think we're gonna need more SW devs, not fewer Code is a liability. What we really care about is the outcome, not the code. These AI tools are great at generating code, but are they good at maintaining the generated code? Not from what I've seen. So there's a good chance we'll see people using tools to generate a ton of instant legacy code (because nobody in house has ever understood it) which, if it hits product…
> Code is a liability
Another way I've seen this expressed, which resonates with me, is "All code is technical debt."
Re: Firing programmers for AI is a mistake
#578This 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 quality of code produced by AI will improve dramatically as model evolves.
That's a very bold claim. We are already seeing plateu in LLM capabilities in general. And there is little improvement in places where they fall short (like making holistic changes in a large codebase) since their birth. They only improve where they are already good at such as writing small glue programs. Expecting significant breakthroughs with just scaling without any fundamentally changes to the architecture seems like too optimistic to me.
Re: Firing programmers for AI is a mistake
#579Earlier 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…
I don't think the value of senior developers is so much in knowing how more things work, but rather that they've learnt (over many projects of increasing complexity) how to design and build larger more complex systems, and this knowledge mostly isn't documented for LLMs to learn from. An LLM can do the LLM thing and copy designs it has seen, but this is cargo-cult behavior - copy the surface form of something without understanding why it was built that way, and when a different design would have been better for a myriad of reasons.
This is really an issue for all jobs, not just software development, where there is a large planning and reasoning component. Most of the artifacts available to train an LLM on are the end result of reasoning, not the reasoning process themselves (the day by day, hour by hour, diary of the thought process of someone exercising their journeyman skills). As far as software is concerned, even the end result of reasoning is going to have very limited availability when it comes to large projects since there are relatively few large projects that are open source (things like Linux, gcc, etc). Most large software projects are commercial and proprietary.
This is really one of the major weaknesses of LLM-as-AGI, or LLM-as-human-worker-replacement - their lack of ability to learn on the job and pick up a skill for themselves as opposed to needing to have been pre-trained on it (with the corresponding need for training data). In-context learning is ephemeral and anyways no substitute for weight updates where new knowledge and capabilities have been integrated with existing knowledge into a consistent whole.
Re: Firing programmers for AI is a mistake
#580There'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…
> younger programmers skip straight into prompt engineering and never develop themselves technically beyond the bare minimum needed to glue things together
This was true before LLMs though. A lot of people just glue javascript libraries together