> 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 GPS, not a highway. They tell you what to do and where to go, and if you follow them blindly you will not learn the layout of the city, you'll just learn how to use the GPS. I find myself unable to navigate a city by myself until I consciously force myself off of Google Maps, and I don't find that having used GPS directions gives me a leg up in understanding the city—I'm starting from scratch no matter how many GPS-assisted trips I've taken.

I think the analogy helps both in that the weaknesses in LLM coding are similar and also that it's not the end of the world. I don't need to know how to navigate most cities by memory, so most of the time Google Maps is exactly what I need. But I need to recognize that leaning on it too much for cities that I really do benefit from knowing by heart is a problem, and intentionally force myself to do it the old-fashioned way in those cases.

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.

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 to use route B which causes a jam there, and so on.

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.

Are you Theodore Kaczynski ghost? :)

Seriously what job you do that allows you to not have a smartphone ?

Not OP: I have a smartphone for my own personal use but don't use it for work at all. If my employer wants me to use specific phone apps they can provide one for me like they do a laptop.

yeah so you got a smartphone, the dude was saying he doesn't have a smartphone.

no smartphone make it a real pain in the ass to do most things nowadays, job is one of the biggest but it's not the least. to even connect to my bank account on my computer i need a phone.

Cell phones exist which are not smartphones, and everyone who uses phones for 2FA is happy to send 2FA codes to a "dumb" phone. They only have your phone number, after all.

Well my bank doesn't give me the possibility to use SMS code. It's obligatory to use the app on a verified phone and put a pin.

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

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.

> if you were driving past Palo Alto, to take a congested offramp to the onramp that faced it across the street

If you're talking about that left turn into Alma with the long wait instead of going into the Stanford roundabout and then the overpass, it still does that.

I've seen this type of thing with OsmAnd too. My hypothesis is that someone messed up when drawing the map, and made the offramp an extension of the highway. But I haven't actually verified this.

OsmAnd doesn't use traffic data. You can enable traffic map layers by feeding a reverse-engineered URL, though.

I'm not talking about use of traffic data. In the abstract, assuming you are the only person in the world who owns a car, that route would be a very bad recommendation. Safety concerns would be lower, but still, there's no reason you'd ever do that.

safety concerns would probably actually be higher since the most dangerous places on roads are areas where traffic crosses and conflicts (the road you cross to get from the offramp to onramp)

An example I notice frequently on interstate highways that go through large cities is GM suggesting you get off on an exit, take the access road and skip one of no exits, then get back on at the next ramp. It does it especially often during rush hour traffic. Denver is where I've noticed it the most, but it's not limited to that area by any means.

That already happens. Maps directs you to odd nonsense detours somewhat frequently now, that you get better results by overriding the machine. It's going down the way of web search.

> It's going down the way of web search.

This is an interesting idea. There's an obvious force directing search to get worse, which is the adversarial desire of certain people to be found.

But no such force exists for directions. Why would they be getting worse?

Probably my cynicism but its the more stores you drive past the more likely you are to stop off and buy something.

Exactly! This is an amazing observation and analogy.

The problem is now that the LLM GPS will lead you to the wrong place once a day on average, and then you still need either open the map and study where you are and figure out the route, or refine the destination address and pray it will bring you to the correct place. Such a great analogy!

Strangely this reminds me of exactly how you would navigate in parts of India before the Internet became ubiquitous.

The steps were roughly: Ask a passerby how to get where you want to go. They will usually confidently describe the steps, even if they didn't speak your language. Cheerfully thank them and proceed to follow the directions. After a block or two, ask a new passerby. Follow their directions for a while and repeat. Never follow the instructions fully. This triangulation served to naturally fill out faulty guidance and hucksters.

Never thought that would one day remind me of programming.

Indeed. My experience in India is that people are friendly and helpful and try to help you in a very convincing way, even so when they don't know the answer. Not so far off LLM user experience.

Try asking your GPS for the Western blue line stop on the Chicago L. (There are two of them and it will randomly pick one)

What is “your GPS” meant here. With Google Maps and Apple Maps it consistently picks the closest one (this being within minutes to both but much closer to one), which seems reasonable. Maybe not ideal as when either of these apps will bring up a disambiguation for a super market chain or similar, but I’m not witnessing randomness.

To be clear, above i was talking about LLMs. Randomness in real GPS usage is something I have never encountered in using Google maps already since 15 years or so. 99 percent of the time it brings/brought me exactly where i want to be, even around road works or traffic jams. It seems some people have totally different experiences, so odd.

Perhaps they have improved their heuristic for this one, though perhaps it was actually Uber/Lyft that randomly picks one when given as a destination...

I'm the kind of guy who decently likes maps, and I pay attention to where I'm going and also to the map before, during, and after using a GPS (Google maps). I do benefit from Google maps in learning my way around a place. It depends on how you use it. So if people use LLMs to code without trying to learn from it and just copy and paste, then yeah, they're not going to learn the skills themselves. But if they are paying attention to the answers they are getting from the LLMs, adjusting things themselves, etc. then they should be able to learn from that as well as they can from online code snippets, modulus the (however occasional) bad examples from the LLM.

> I do benefit from Google maps in learning my way around a place.

Tangent: I once got into a discussion with a friend who was surprised I had the map (on a car dashboard display) locked to North-is-up instead of relative to the car's direction of travel.

I agreed that it's less-convenient for relative turn decisions, but rationalized that setting as making it easier to learn the route's correspondence to the map, and where it passed relative to other landmarks beyond visual sight. (The issue of knowing whether the upcoming turn was left-or-right was addressed by the audio guidance portion.)

It's neat to hear that I'm not the only one who does this. It makes a night-and-day difference for me.

When the map is locked north, I'm always aware of my location within the larger area, even when driving somewhere completely new.

Without it, I could never develop any associations between what I'm seeing outside the windshield and a geospatial location unless I was already familiar with the area.

> LLMs are a GPS, not a highway.

I love these analogies and I think this one is apt.

To adapt another which I saw here to this RoR thread, if you're building furniture then LLMs are powertools while frameworks are ikea flatpacks.

It’s best the analogy of the month. I don’t think cab drivers today are the same cab drivers that knew the city by heart of the past.

So, it’s been a privilege gentlemen, writing apps from scratch with you.

walks off the programming Titanic with a giant violin

One small change to using a GPS radically impacts how much you know about the area -- do you use the default, always-forward view, or do you use the slightly-less-usable always-north setting? If you use the latter, you will find that you learn far more about the city layout while still benefitting from the GPS functionality itself.

I think LLMs are similar. Sure, you can vibe code and blindly accept what the LLM gives you. Or, you can engage with it as if pair programming.

> LLMs are a GPS, not a highway. They tell you what to do and where to go

It still gives you code you can inspect. There is no black box. Curious people will continue being curious.

The code you can inspect is analogous to directions on a map. Some have noted in this thread that for them directions on a map actually do help them learn the territory. I have found that they absolutely do not help me.

That's not for lack of curiosity, it seems to be something about the way that I'm wired that making decisions about where to navigate helps me to learn in a way that following someone else's decisions does not.

You have to study the map to learn from it. Zoom in and out on surroundings, look up unfamiliar landmarks, et cetera. If you just follow the GPS or copy paste the code no, you won’t learn.

The problem is that coders taking this approach are dominantly ones who lack the relevant skill - ones who are taking that approach because they lack that skill.

The ones that until now copied and pasted everything from Stack Overflow.

For now LLMs in coding are more like an LLM version of a GPS, not the GPS itself.

Like imagine you’d ask turn-by-turn directions from an LLM and then follow these directions ;). That’s how it feels when LLMs are used for coding.

Sometimes amazing, sometimes generated code is a swamp of technical debt. Still, a decade ago it was completely impossible. And the sky is the limit.

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 never gets stored in the brain, making any future learning or evolving impossible.

I've had to work with developers that are over dependent on LLM's, one didn't even know how to undo code, they had to ask an LLM to undo. Almost as if the person is a zombie or something. It's scary to witness. And as soon as you ask them to explain their rationale for the solution they came up with - dead silence. They can't, because they never actually _thought_.

> I've had to work with developers that are over dependent on LLM's, one didn't even know how to undo code, they had to ask an LLM to undo.

Some also get into a loop where they ask the LLM to rewrite what they have, and the result ends up changing in a subtle undetected way or loses comments.

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.

Abstractions on top of abstractions on top of turtles...

It'll be interesting to see what kinds of new tools come out of this AI boom. I think we're still figuring out what the new abstraction tier is going to be, but I don't think the tools to really work at that tier have been written yet.

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 production, will require skilled people to figure out how to support it.

We will see both: lots of poor code, lots of neutral code (LLMs cranking out reasonably well written boilerplate), and even some improved code (by devs who use LLMs to ferret out inefficiencies and bugs in their existing, human-written codebase).

This is no different from what we see with any tool or language: the results are highly dependent on the experience and skills of the operator.

You've missed my core point if you think those isn't different. Before AI there was always someone who understood the code/system.

In the a world where people are having machines build the entire system, there is potentially no human that has ever understood it. Now, we are talking about a yet unseen future; I have yet to see a real world system that did not have a human driving the design. But, maintaining a system that nobody has ever understood could be ultra-hardmode.

Humans will always have a hand in the design because they need to explain the real-world constraints to the AI. Sure, the code it produces may be complex, but if the AI is really as smart as you're claiming it will eventually be, then it will also have the ability to explain how the code works in plain English (or your human language of choice). Even today, LLMs are remarkably good at summarizing what code does.

Philosophical question: how is LLM-produced code that nobody has ever understood any different from human-written legacy code that nobody alive today understands?

> Philosophical question: how is LLM-produced code that nobody has ever understood any different from human-written legacy code that nobody alive today understands?

- There is zero option of paying an obscene amount of money to find the person and make the problem 'go away'

- There is a non-zero possibility that the code is not understandable by any developer you can afford. By this I mean that the system exhibits the desired behavior, but is written in such a way that only someone like Mike Pall* can understand.

* Mike Pall is a robot from the future

> Code is a liability

Another way I've seen this expressed, which resonates with me, is "All code is technical debt."

As one HNer aptly put it: coding is to SWE as cutting is to surgery.

These AI tools are also not good at answering PagerDuty to fix a production problem that is a result of the code they imagined.

> Code is a liability

This is so true! Actual writing of the code is such a small step in overall running of a typical business/project, and the less of it the better.

> more sophisticated tech stacks

Please don't do this, pick more boring tech stacks https://news.ycombinator.com/item?id=43012862 instead. "Sophisticated" tech stacks are a huge waste, so please save the sophisticated stuff for the 0.1% of the time where you actually need it.

Sophistication doesn't imply any increase or decrease in "boringness".

No, this is not "the" dictionary definition.

This definition is obsolete according to Wikitionary: https://en.wiktionary.org/wiki/sophisticated (Wikitionary is the first result that shows when I type your words)

That is an extremely archaic definition that's pretty far from modern usage, especially in a tech context

No clue what dictionary you looked at but this is not at all what dictionaries actually say.

An edge case in startups is something that provides a competitive advantage. When you run a startup, you have to do something different from the way everyone else does, or you’ll get the same results everyone else does. My theory is that some part of a startup’s operations should be cutting edge. HR processes, programming stack, sales cycle, something.

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 your engineers hours and your company 10s of millions. Or just: when the boring tech doesn't actually do the things you need it to do.

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

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 said to have 'stood the test of time' like most boring tech has. (And I would include things like eBPF in that by now.)

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.

Today I learned that some tech stacks are sophisticated, I suppose those are for the discerning developer.

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.

How? Students now are handing out LLM homework left and right. They are not nurturing the resolve to learn. We are training a cohort of youngs who will give up without trying hard, and end learning nothing

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

> "But it's not satisfying to stay at that level of ignorance very long"

It's not about satisfaction: it's literally dangerous and can bankrupt your employer, cause immense harm to your customers and people at home, and make you unhirable as an engineer.

Let's take your example of "an S3 avatar upload system", which you consider finished after writing 2 lines of code and a couple of packages installed. What makes sure this can't be abused by an attacker to DDOS your system, leading to massive bills from AWS? What happens after an attacker abuses this system and takes control of your machines? What makes sure those avatars are "safe-for-work" and legal to host in your S3 bucket?

People using LLMs and feeling all confident about it are the equivalent of hobby carpenters after watching a DIY video on YouTube and building a garden shed over the weekend. You're telling me they're now qualified to go build buildings and bridges?

> "It's like presuming that StackOverflow will keep you as a question-asker your whole life when nobody here would relate to that."

I meet people like this during job interviews all of the time, if I'm hiring for a position. Can't tell you how many people with 10+ years of industry experience I met recently that can't explain how to read data from a local file, from the machine's file system.

At present, LLMs are basically Stack Overflow with infinite answers on demand... of Stack Overflow quality and relevance. Prompting is the new Googling. It's a critical base skill, but it's not sufficient.

The models I've tried aren't that great at algorithm design. They're abysmal at generating highly specific, correct code (e.g. kernel drivers, consensus protocols, locking constructs.) They're good plumbers. A lot of programming is plumbing, so I'm happy to have the help, but they have trouble doing actual computer science.

And most relevantly, they currently don't scale to large codebases. They're not autonomous enough to pull a work item off the queue, make changes across a 100kloc codebase, debug and iterate, and submit a PR. But they can help a lot with each individual part of that workflow when focused, so we end up in the perverse situation where junior devs act as the machine's secretary, while the model does most of the actual programming.

So we end up de-skilling the junior devs, but the models still can't replace the principal devs and researchers, so where are the principal devs going to come from?

>The models I've tried aren't that great at algorithm design. They're abysmal at generating highly specific, correct code (e.g. kernel drivers, consensus protocols, locking constructs.) They're good plumbers. A lot of programming is plumbing, so I'm happy to have the help, but they have trouble doing actual computer science.

I tend towards tool development, so this suggests a fringe benefit of LLMs to me: if my users are asking LLMs to help with a specific part of my API, I know that's the part that sucks and needs to be redesigned.

>Why wouldn't this be the case for people using LLM like it was for everyone else?

Because of the mode of interaction.

When you dive into a framework that provides a ton of scaffolding, and "backfill your knowledge over time" (guilty! using Nikola as a SSG has been my entry point to relearn modern CSS, for example), you're forced to proceed by creating your own loop of experimentation and research.

When you interact with an LLM, and use forums to figure out problems the LLM didn't successfully explain to you (about its own output), you're in chat mode the whole time. Even if people are willing to teach you to fish, they won't voluntarily start the lesson, because you haven't shown any interest in it. And the fish are all over the place - for now - so why would you want to learn?

>It's like presuming that StackOverflow will keep you as a question-asker your whole life when nobody here would relate to that.

Of course nobody on HN would relate to that first-hand. But as someone with extensive experience curating Stack Overflow, I can assure you I have seen it second-hand many times.

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

The article is right in a zoomed-in view (fundamental skills will be rare and essential), but in the big picture the critique in the comment is better (folks rarely start on nand gates). Programmers of the future will have less need to know code syntax the same way current programmers don't have to fuss with hardware-specific machine code.

The people who still do hardware-specific code, are they currently in demand? The marketplace is smaller, so results will vary and probably like the article suggests, be less satisfactory for the participant with the time-critical need or demand.

> The article is right in a zoomed-in view.

First of all, I think the problems of the industry were long overdue. It started with Twitter and it proved it can be done. AI just made it easier psychologically because it's much easier to explore and modify existing code and not freak out "omg, omg, omg, we've lost this guy and ony he understands the code and we're so lost without him". AI just removes the incentives to hoard talent.

I also think of excel/spreadsheets and how it did in fact change accounting industry forever. Every claim the author makes about software developers could have been made about accounting after the advent of electronic spreadsheets.

I don't want to even get started on the huge waste and politics in the industry. I'm on the 3rd re-write of a simple task that removes metrics in Grafana which saves the team maybe 50$ monthly. If the team was cut in half, I'm sure we'd simply not do half the bullshit "improvements" we do.

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.

This is a great point. I remember my first computer programming class was Java. The teacher said “just type public static void main( string[] args) at the top”. I asked why and he said it didn’t matter for now just memorize that part. That was great advice. At that point it was more important to get a feel for how computers behave and how programs are structured on a high level. I just kept typing that cryptic line mindlessly on top of all my programs so that I could get to the other stuff. Only many months later I looked into the mysterious line and understood what all the keywords meant.

It’s funny now that I haven’t programmed Java for more than a decade and the “public static void main” incantation is still burned into my memory.

I agree, and I also share your experience (guess I was a bit earlier with PHP).

I think what's left out though is that this is the experience of those who are really interested and for whom "it's not satisfying" to stay there.

As tech has turned into a money-maker, people aren't doing it for the satisfaction, they are doing it for the money. That appears to cause more corner cutting and less learning what's underneath instead of just doing the quickest fix that SO/LLM/whatever gives you.

I'm not so sure, I think a junior dev on my team might be being held back by AI, he's good at using it. However he was really struggling to do something very basic. In my view he just needs to learn that syntax and play around with it in a throw away console app. But I think AI is crutch that may distract from doing that. Then again it is utterly fantastic at explaining small bits of code so it could be an excellent teacher too.

Who the hell, in today's market, is going to hire an engineer with a tenuous grasp on foundational technological systems, with the hope that one day they will backfill?!

Yeah, my recollection of the past couple decades is many companies felt like: "Someone else will surely train up the junior developers, we'll just hire them away after they know what they're doing." This often went with an oddly-bewildered: "Wow, why is it so hard to find good candidates?"

I don't see how that trend would change much just because junior developers can use LLMs as a crutch. (Well, except when it helps them cheat at an interview that wasn't predictive of what the job really needed.)

> And then they backfill their knowledge over time.

If only. There are too many devs who've learnt to write JS or Python, and simply won't change. I've seen one case where someone ported an existing 20k C++ app to a browser app in the most unsuitable way with emscripten, where a 1100 lines of typescript do a much better job.

> But it's not satisfying to stay at that level of ignorance very long

That's the difference. This is how you feel because you like programming to some extent. Having worked closely with them, I can tell you there are many people going into bootcamps that flat out dislike programming and just heard it pays well. Some of them get jobs, but they don't want to learn anything. They just want to do as much that doesn't get them fired. They are not curious even with tasks they are supposed to do.

I don't think this is inherently wrong, as I don't feel like gatekeeping the profession if their bosses feel they add value. But this is a classic case of losing the junior > expert pipeline. We could easily find ourselves in a spot in 30 years where AI coding is rampant but there's no experts to actually know what it does.

There have been people entering the profession for (purported) money and not love of the craft for at least as long as the 20 years I've been in it. So long as there are also people who still genuinely enjoy it and take pride in doing the job well, then the junior->expert pipeline isn't lost.

I buy that LLMs may shift the proportion of those two camps. But doubt it will really eliminate those who genuinely love building things with code.

I'm not sure it takes more than a shift, though. There aren't 0 people in training to be a doctor, but we have a shortage for sure and it causes huge problems.

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

Well put. There’s a similar phenomenon in industrial maintenance. The “grey tsunami.” Skilled electricians, pipefitters, and technicians of all stripes are aging out of the workforce. They’re not being replaced, and instead of fixing the pipeline, many factories are going out of business, and many others are opting to replace equipment wholesale rather than attempt repairs. Everybody loses, even the equipment vendors, who in the long run have fewer customers left to sell to.

I very much relate to the sentiment of starting out with simple tools and then backfilling knowledge gaps as I went. For me it was Excel -> Access shared DB forms -> Django web application framework -> etc. From spreadsheets, to database design, to web application development, to scaling HTTP services, and on and on it goes.

> But it's not satisfying to stay at that level of ignorance very long

I agree, but have found that for a lot of people that is totally satisfying enough. Most people don't care to really understand how the code works.

That's fine and all but I'm not sure the nand-gate folks are out of a job either.

Or assuming software needs to be of a certain quality.

Software engineers 15 years ago would have thought it crazy to ship a full browser with every desktop app. That’s now routine. Wasteful? Sure. But it works. The need for low level knowledge dramatically decreased.