I don't know why people don't give more credence to the argument that the exact opposite thing will happen.

Right. I don’t understand why everyone thinks this will make it impossible for junior devs to learn. The people I had around to answer my questions when I was learning knew a whole lot less than Claude and also had full time jobs doing something other than answering my questions.

It won't make it impossible for junior engineers to learn.

It will simply reduce the amount of opportunities to learn (and not just for juniors), by virtue of companies' beancounters concluding "two for one" (several juniors) doesn't return the same as "buy one get one free" (existing staff + AI license).

I dread the day we all "learn from AI". The social interaction part of learning is just as important as the content of it, really, especially when you're young; none of that comes across yet in the pure "1:1 interaction" with AI.

I learnt programming on my own, without any social interaction involved. In fact, I loved programming because it does not involve any social interaction.

Programming has become more of a "social game" in the last 15 years or so. AI is a new superpower for people like me, bringing balance to the Force.

To me, LLMs are just a different kind of social interaction I mostly don’t want, tedious and frustrating.

But it is not a social interaction. An LLM is a machine.

I think there is also a big difference between being forced to use an LLM in a certain way, and being able to completely design your interaction with the LLM yourself. The former I imagine can be indeed tedious and frustrating, the latter is just miraculous.

No one is forcing me to use LLMs, so that’s not it. The interaction is social in the sense that it is natural-language based and nondeterministic, and that LLMs exhibit a certain “character”. They have been trained to mimic certain kinds of human social interaction.

It probably also depends on what your favourite weapon of choice is. Mine was always written language, and code is just a particular manifestation of it.

Junior devs using AI can get a lot better at using AI and learn those existing patterns it generates, but I notice, for myself, that if I let AI write a lot of the code I remember and thereby understand it later on less well. This applies in school and when trying to learn new things but the act of writing down the solution and working out the details yourself trains our own brain. I'd say that this has been a practice for over a thousand years and I'm skeptical that this will make junior devs grow their own skills faster.

I think asking questions to the AI for your own understanding totally makes sense, but there is a benefit when you actually create the code versus asking the AI to do it.

I'm sure there is when you're just getting your sea legs in some environment, but at some point most of the code you write in a given environment is rote. Rote code is both depleting and mutagenic --- if you're fluent and also interested in programming, you'll start convincing yourself to do stupid stuff to make the code less rote ("DRY it up", "make a DSL", &c) that makes your code less readable and maintainable. It's a trap I fall into constantly.

> but at some point most of the code you write in a given environment is rote

"Most of the code one writes in a given environment is rote" is true in the same sense that most of the words one writes in any given bit of text are rote e.g. conjunctions, articles, prepositions, etc.

Some writers I know are convinced this is true, but I still don't think the comparison is completely apt, because deliberately rote code with modulated expressiveness is often (even usually) a virtue in coding, and not always so with writing. For experienced or enthusiastic coders, that is to say, the effort is often in not doing stupid stuff to make the code more clever.

Straight-line replacement-grade mid code that just does the things a prompt tells it to in the least clever most straightforward way possible is usually a good thing; that long clunky string of modifiers goes by the name "maintainability".

If your code is that boilerplate you can do it by rote, you need to abstract it already. Or write a generator/snippet

See, I get what you're saying, but this is my whole thing. No. Abstracting code out or building a bespoke codegen system is not always or even usually an improvement on straight-line code that just does what it says it does.

You learn by doing.. eg typing the code. It's not just knowledge, it's the intuition you develop when you write code yourself. Just like physical exercise. Or playing an instrument. It's not enough to know the theory, practice is key.

AI makes it very easy to avoid typing and hence make learning this skill less attractive.

But I don't necessarily see it as doom and gloom, what I think will happen - juniors will develop advanced intuition about using AI and getting the functionality they need, not the quality of the code, while at the same time the AI models will get increasingly better and write higher quality code.

If a junior engineer ships a similar repo to this with the help of AI, sure, I'll buy that.

But as of now, it's senior engineers who really know what they 're doing who can spot the errors in AI code.

Hold on. You said "really know what they're doing". Yes, I agree with that. What I don't buy is the coupling of that concept with "seniority".

Have a better term for "knows what they're doing" other than senior?

That's not what "senior" means.

This is not necessarily true in practical terms when it comes to hiring or promoting. Often a senior dev becomes a senior because of having an advanced skillset, despite years on the job. Similarily, often developers who have been on the job for many years aren’t ready for senior because of their lack or soft and hard skills.

Oh, that's one of the ways a senior dev becomes senior.

Maybe you could enlighten the rest of us then. According to your favorite definition, what does senior mean, what does seniority mean, and what's a term for someone who knows what they're doing?

Seniority means you've held the role for a long time.

Time is required to be a senior engineer, but time does not _make_ you a senior engineer.

You need time to accumulate experience. You need experience, time in the proverbial trenches, to be a senior engineer.

You need to be doing different things too, not just implementing the same cookie cutter code repeatedly. If you are doing that, and havent automated it, you are not a senior engineer.

There is no real definition of a senior engineer. Just looking at years served seems is wrong imho.

There's what "senior"-level developers say about themselves, and there's what's actually generally true about them. The two notions are, of course, not the same.

If I’ve learned anything from the past few decades, something completely unexpected and even weirder than both will happen.

> The argument is that this stuff will so radically improve senior engineer productivity that the demand for junior engineers will crater.

What makes people think that an increase in senior engineer productivity causes demand for junior engineers to decrease?

I think it will have the opposite effect: an increase in senior engineer productivity enables the company to add more features to its products, making it more valuable to its customers, who can therefore afford to pay more for the software. With this increase in revenue, the company is able to hire more junior engineers.