There's one angle which most of these arguments miss (totally not in the scope of the article, which is fine). A couple of statements I believe are true (based on my and my network's limited experience):

1. Juniors grow. Most of them grow fast, becoming solid mid-levels in 1-1.5y (in the right environment)

2. The industry depends heavily on a wide pool of mid-levels. These are the folks who can produce decent quality solutions, and don't need hand-holding anymore. They are the “velocity” of the team. Engineers tend to spend a few years there, before they might grow into seniors.

3. Seniors will age out.

4. AI doesn't grow (as it is today), it's stuck on the low-junior level mostly. This might change, but currently there are no signs for this.

5. Seniors would need to spend _a lot_ of time fixing AI's output, and course-correcting.

Now, all of this combined: the junior --> senior transition takes say, 5+ years on average (I know, depends). If we move on with the "1/2 senior + AI agents" model, how does a company form a new team? When those seniors move away / retire, who's taking their place? What happens to the velocity of the team without mid-levels now?

If we let this go on for a couple of years before a reckoning of "oh crap" happens, it'll be very hard to come back from this --> certain "muscles" of the aforementioned seniors will have atrophied (e.g. mentoring, growing others), a lot of juniors (and mediors!) will have left the industry.

I hope companies will recognize this risk in time...

>I hope companies will recognize this risk in time... I more than wholeheartedly agree with this great analysis. But we have to ask ourselves, when have most companies (by which I mean mostly those run by the hired CEOs) ever really recognised the risks? And why should we hope for it? Those that dont will hopefully wither away, their place to be filled in by those more, for the lack of a better word, "agile" :)

One more thing to add: AI enhances capabilities of everyone, including juniors. Juniors with LLMs can do more than juniors without them could and therefore their value proposition is greater than before.

But they don't learn from that, they turn the crank of the AI tooling and once they have something that works it goes in and they move on. I've seen this directly, you can't shortcut actual understanding.

I disagree. LLM assisted coding is yet another level of abstraction. It’s the same thing as an assembly programmer saying that OOP programmers don’t learn from OOP coding.

Today’s juniors still learn the same core skill, the abstract thinking and formalization of a problem is still there. It’s just done on a higher level of abstraction and in an explicitly formulated natural language instead of a formal one for the first time ever. They’re not even leaving out the formal one completely, because they need to integrate and fine tune the code for it to work as needed.

Does it introduce new problems? Sure. Does it mean that today’s juniors will be less capable compared to today’s seniors once they have the same amount of experience? I really doubt it.

>It’s the same thing as an assembly programmer saying that OOP programmers don’t learn from OOP coding.

Not the same. Whether you are writing Assembly or Java, you have to determine and express your intent with high accuracy - that is a learned skill. Providing problem details to an LLM until it produces something that looks correct is not the same type of skill.

If that is the skill that the business world demands in 5 years, so be it, but arguing that it's simply the next step in the Assembly, C, Java progression makes no sense.

> Providing problem details to an LLM until it produces something that looks correct

If you're using LLMs to code like this, you're using them incorrectly. You need to specify your intent precisely from the start which is a skill you learn. You can use other tools like OOP languages incorrectly with "working" results as well, that's why code quality, clean code and best practices are a thing.

I'm sure many junior developers use LLMs the way you described but maybe that's exactly what the universities and seniors need to teach them?

I disagree. I use LLMs to help me like a teacher would.

The difference is that most teachers know what they are talking about. LLMs don't necessarily.

You might, just as ages ago when people were complaining about juniors c+ping stack overflow answers you might have said you used them to learn from. LLMs are a turbo charged version of the same problem, only now rather than copying a code fragment from stack overflow you can have an LLM spit out a working solution. There is no need to understand what you're doing to be productive, and if you don't understand it you have no model or reasoning to apply in the future to other problems, maybe AI will save you there too for a while, but eventually it won't and you'll find you've built your career on sand.

Or maybe I'm wrong and we're all headed for a future of being prompt engineers.

Generally the understanding happens fairly quickly just by glancing through the code.

I was a sceptic up until recently, where I failed to create a solution myself.

Since I am mostly a hobbyist programmer(for 25 years and counting) I often find I don’t have the time to sit down for prolonged periods to reason about my code.

ChatGPT helps my tired brain from work develop my code 10x quicker, easily, by removing road blocks for me.

I find it an excellent tool.

> fairly quickly just by glancing through the code.

This is a senior-level view. Juniors don't have this skill yet, and is one of the things we're concerned they won't pick up.

> AI enhances capabilities of everyone

Wildly debatable

> Juniors with LLMs can do more than juniors without them could

Except that being juniors they lack the critical skills to understand when code produced by AI is trash

Indeed. With AI juniors can create horrible software faster, and in bigger quantities. Based on my experience AI really only enhances your existing talent, and if you have none, it enhances the lack of it, since you still need to be able to know how your AI slop fits in the larger system, but if you're a junior you most likely don't know that. Couple that with skipping the step where you must actually understand what you copy and paste from the internet for it to work, you also lengthen the time it takes for a developer to actually level up, since they do much less actual learning.

That's at least my experience working with multiple digital agencies and seeing it all unfold. Most juniors don't last long these days precisely because they skip the part that actually makes them valuable - storing information in their head. And that's concerning, because if to make actually good use of AI you have to be an experienced engineer, but to become an experienced engineer you had to get there without AI doing all your work for you, then how are we going to get new experienced engineers?

I think what you’re describing is caused by the fact that people that would previously pursue law, medicine or some other high paying field now pursue software engineering because it pays well and is a pretty comfortable job overall.

The nerdy tinkerers stay the same and AI empowers them even more. Are they rare? Yes. But this shifts the topic from science/engineering to economics/sociology. Granted, that was the topic of the original submission but for me that’s the less interesting part.

Very true! But, they are also more prone to just rolling with whatever quality AI throws at them.

Remembering some PRs from before... It was always about how much attention to detail/quality the particular junior dev pays. Often times it’s not much at all which might be harder to notice now.

Juniors with LLMs can also ruin things much faster than before.

but, can they grow?

With proper guidance, of course.

If Seniors are too busy babysitting the AI, then no.

is the assumption "in order to grow you have to fail YOURSELF"?

it seems pretty obvious to me that you grow as a programmer more from "sit down and write code to do a thing" than you do from "sit down, watch an LLM shit out code and give it a pretty cursory review"

Copying my comment from above:

I disagree. LLM assisted coding is yet another level of abstraction. It’s the same thing as an assembly programmer saying that OOP programmers don’t learn from OOP coding.

Today’s juniors still learn the same core skill, the abstract thinking and formalization of a problem is still there. It’s just done on a higher level of abstraction and in an explicitly formulated natural language instead of a formal one for the first time ever. They’re not even leaving out the formal one completely because they need to integrate and fine tune the code for it to work as needed.

Does it introduce new problems? Sure. Does it mean that today’s juniors will be less capable compared to today’s seniors once they have the same amount of experience? I really doubt it.

I'm not making any pronouncement about if LLM are good things or not for juniors but your OOP analogy doesn't track.

One can be confident that they wrote correct Java code without knowing what the JVM machine code output is. But you can't know if the code outputted by an LLM is correct without understanding the code itself.

> One can be confident that they wrote correct Java code without knowing what the JVM machine code output is

I'm sure there're some pretty major bugs in production code because someone used some Java functionality intuitively without understanding it fully and in some edge case it behaves differently than anticipated.

Of course this issue is much more prominent in LLM assisted coding but we're back to square one. The higher the level of abstraction provided by the tool, the more room for mistakes it leaves but the higher the productivity is. It's easier to avoid bugs of this type when using assembly vs when using Java.

Idk if I learned more from actually typing code or debugging and looking at the output/logs, sometimes even running code in my mind to figure out the problems. Maybe it's just "cursory".

AI for coding tasks still needs a great deal of handholding. Someone senior needs to delete roughly 1/4 of the consistent garbage it currently adds to the acceptable output and still maintain the same code.

> Now, all of this combined: the junior --> senior transition takes say, 5+ years on average (I know, depends). If we move on with the "1/2 senior + AI agents" model, how does a company form a new team? When those seniors move away / retire, who's taking their place? What happens to the velocity of the team without mid-levels now?

> If we let this go on for a couple of years before a reckoning of "oh crap" happens, it'll be very hard to come back from this --> certain "muscles" of the aforementioned seniors will have atrophied (e.g. mentoring, growing others), a lot of juniors (and mediors!) will have left the industry.

> I hope companies will recognize this risk in time...

As someone in an org who has some exposure to legacy support, don't underestimate management's ability to stick its head in the sand until it's too late in order to focus on the new shiny.

I think we're down to two mainframe developers, still have a crap-ton of dependencies on it and systems that have been "planned to be decommissioned" for decades, and at least one major ticking-time bomb that has a big mainframe footprint.

"Leadership can stay irrational longer than you can stay employed"

The problem the industry faces isnt that juniors dont grow it's that they spend up to 18 months being a drain on productivity after which point they tend to leave.

Who would pay for that?

Not a lot of companies, which acts as a filter.

As it turns out, a few companies do because they are super strapped for cash. That's why a lot of junior first experiences are a trial by fire in environments that are on another level of dysfunction working with either no seniors or bottom of the barrel seniors.

This acts as another filter. Some juniors give up at this point.

These filters prevent junior engineers from becoming senior. This is actually pretty good for seniors - being a rare, in demand commodity usually is.

I dont think AI changes this calculus much except insofar as AI amplifies the capacity for juniors to build ever bigger code jenga towers.

> The problem the industry faces isnt that juniors dont grow it's that they spend up to 18 months being a drain on productivity after which point they tend to leave.

Thankfully, that's not my experience with most juniors. Again, my experience is limited (as all of ours is), but if you filter juniors well during hiring, you can get a wonderful set of high-potential learning machines, who, with the right mentors, grow like crazy.

Ive worked with a bunch of great juniors too. None of this changes the fact that they cant hit the ground running, they make mistakes which have to be unpicked and mentoring them eats up time.

>The problem the industry faces isnt that juniors dont grow it's that they spend up to 18 months being a drain on productivity after which point they tend to leave.

This is largely a result of the compensation behaviour of the industry. A junior that gets hired and grows does not get a raise in their salary to the market rate, the only way for them to get the compensation commensurate with their new skills is to leave and get hired somewhere else. Companies can avoid this problem by not doing this.

thats kind of my point. if theyre going to subsidize a junior being trained and then pay market rate at the end why not just avoid the subsidy bit and poach somebody else's pretrained junior?

It's kind of a tragedy of the commons effect except the "tragedy" is for tech employers - who are stroppy coz other companies dont have to provide their workers with a free sushi bar so why should they????

When I got into the industry (back in the early 90's), a large minority of new developers didn't study CS at University. We learned to code on the new, fun, microcomputers that were around, and then later just landed jobs as programmers almost by accident because we could already code.

I suspect this will be the future; the vast industry we're in now will shrink (as we're seeing now), and will rely on self-taught programmers more as AI removes the Junior role.

There will always be people who enjoy writing code and will do that for fun, I think. It'll be interesting to see what happens to all the other folks who never wanted to do this in the first place and only got into it because it's a good career.

I think this "self taught coder" approach has two distinct big problems over actual Computer Science graduates writing software

1. Cliffs. There are big swathes of theoretical CS where we know things can't be done, and the self-taught people would smash their faces into such problems forever because they won't even realise it's insoluble in principle rather than merely difficult, whereas with a more principled background you needn't expend this wasted effort.

2. Local Maxima. Without a principled understanding it's easier to mistake a local maximum you've stumbled into for a global maximum. After all, all the small tweaks you tried make it worse, so, how are you expected to guess that a violently different solution would be better? Theory could help but you don't have any.

Point 1 sounds interesting but I can't comment on it, because I don't remember ever having encountered it.

Point 2:

One of the most important techniques as a self-taught programmer is to develop an instinct for "foundational solution that wants to get out" so to speak. So you search for the name of the type of problem you're looking at or for the approach you half-way discovered. You don't have a tutor or professor who will tell you where you are, so you need to figure that out yourself, often by assuming that someone else already put a label on the map.

On the other hand, self-taught does not mean "you don't have theory". From my experience getting the raw knowledge is the easy part. There are a lot of excellent resources out there, from book recommendations/compilations to freely available lectures and so on.

The thing that I always missed or were generally harder to come by are far more precious than that: guidance and feedback from teachers/mentors, interaction with peers who are in the same boat and most importantly time.

These are absolutely spot on. I worked as a programmer having been a self taught coder. There were important things I just did not understand. A good example is how to gauge the runtime complexity of a program. I did not know what I did not know. Looking back at the code I wrote then—eek!

I hit another wall later in my career and that drove me to go to grad school. I met some folks there who clearly leveraged their CS knowledge (eg, people who were solving niche compiler problems “for fun”) and I realized that there was a lot more to CS than the stuff I had learned on my own. So I stuck with CS and never went back.

What makes you assume that a self taught coder would lack theoretical CS knowledge? Are you confusing bootcamp graduates with self taught coders?

With AI it's infinitely easier, but even before there have been plenty of self taught developers with good CS grounding.

> What makes you assume that a self taught coder would lack theoretical CS knowledge?

Because that's what self taught means. I would not consider myself to be a "self taught coder" for example because I have a CS degree.

The big assumption being made here is that the software work involves really coding a lot. Not it doesn't. In my company, actual coding, design, logic etc all are only about 10% the overall work. Software engineers are not employed by technology companies alone. We call these tech companies technology vendors. The situation described in this article might be a bit applicable to these technology vendor companies, but not for non-tech companies who employ the bulk of the global software workforce.

There is hardly any real logic or coding work involved. You would believe me if you work in a non-tech company. Most of your time goes into navigating the company's process, tools, and people. Yes, it is called People-Process-Technology for a reason. Even the word "Technology" here refers to engaging the tech vendors and consultants to get some work done, or just figuring out how to use a legacy software or constant chasing others to get dependencies resolved. Weeks and months pass by, waiting for a dependency to get resolved so that your last code commit could actually finish it's build. Tons of JIRA tickets and INCs would have flown around meanwhile which creates an imaginary realm of huge work and productivity - all resulting in a single line of code change getting tested. It could even be celebrated via huge email thanking every one (100s of people), making it look like a big achievement.

The point is, AI doesn't replace junior engineer roles. Junior engineers are preferred for assigning all dirty drudgery, who can be blamed if things go wrong and who can give away their credit to bosses when things work well and who kind of flexible with good attitude. That's very attractive!

Basically we hire people to own some risk and accountability. Distribution of work is primarily to distribute the risk, blame and accountability, not really to get the work done. Actual work is done by non-employee consultants in India, eastern Europe or Vietnam etc.

For example, we don't use opensource because we can't hold someone accountable. The fact that opensource simply works, doesn't count. However if some vendor offers the same opensource tech with enterprise support or as a managed SaaS, we would buy that.

I've never worked in any example of this fictitious organization where seniors are too important and well paid to write the code, so they just wave conductor's batons to orchestrate juniors into doing all the work.

It is most definitely a thing, and that is how my job worked when I was at Microsoft, in three different roles. All of the senior people I worked for definitely could code (one of them was well-known in the memory management research space), and they would occasionally do so. But largely, they focused on the big picture, and virtually all of my interactions with them was over a whiteboard. I was very surprised when I first got there that they basically never wanted to put eyeballs directly on my code; they preferred to talk to me about it. As a junior person, developing the fluency to have whiteboard conversations was difficult. But when we’d leave the meetings I would have a much clearer idea about what I should do, and perhaps more importantly, what I should not do. In all of those projects, 100% of the code was written by me and other junior people.

> 100% of the code was written by ... junior people.

No offense, but it kind of shows with every product by that company I've touched over the years. But then again they are largely not a technology company. More like a lobbying firm that happens to be very good at politicking to get their wares on every enterprise PC. The quality doesn't even matter, since most of their end users are a captive audience.

I think in hindsight it would have been amazing to have senior students in the team exercises, but really what would have been even more excellent would have been industry placement. Things like not having this is why my 1982 degree failed the bar for BCS chartered engineer status.

I continue to believe the first 12-18 months after graduation are vital. I still can't believe some of the things I thought about s/w before I entered the workforce and I can't believe some of the things I got away with over the years since.

I thought Quality Assurance was a thing! The more I fled it, the more I learnt the skills of programming. I think our kids will look at us and the way we thought filling forms was providing any assurance of quality, and perhaps by then it will be all LLM-no-forms.

The skill of breaking down the system to smaller constituant parts was formerly the domain of the Systems Analyst - an occupation now almost extinct by formal title, as the coders reached up into this role.

Presumably this occured because the Systems Analyst was virtually archtecture agnostic, but a computer person could consider both the problem breakdown and the optimal architecture to fit, juggling each a little to optimise that interface between requirements and implementation. This personage then claimed the title of "Architect".

However, I am seeing, in certain areas, a deep lack of specification skills and wonder the Systems Analyst might not partially have a resurgence as a profession.

As a senior engineer I'd much rather hand-hold a junior rather than an LLM. Junior roles aren't going anywhere.

The expectation that LLMs will multiply the output of more experienced engineers is simply ridiculous.

I work in a FAANG on one of the main teams using GenAI. The impact from GenAI we've calculated and that senior leadership is taking decision upon is an overall gain of about 5% velocity on CODING tasks, so about 2.5% on overall tasks.

If you feel like GenAI has overall doubled or tripled your productivity I'm sorry but it's a sign that you suck and are working on incredibly simple problems.

> it's a sign that you suck

Beware, your comment is likely to age incredibly poorly.

Also, I wouldn't want to work in the same team as you, if that's how you communicate.

Maybe ask your favorite LLM to explain how a comment on a state at a particular point in time cannot age.

most computer science programs in the US - are just "applied math". I'm from a 3rd world country but did CS in the US at a state school - you only do programming for the first intro programs like C then OOP that's it.

DataStructures, Databases, Operating Systems, Discreet Math etc are usually done without any programming at all. besides one or two assignments

The rest of the program it's mostly Math stuff. The only other time you do programming is if you choose an elective towards your graduation.

Well, thats the reason its called computer science, and not "computer vocational training".

Interesting. I wouldn't have thought that.

I have an MS in CS from a small Eastern-European state run university, but the curriculum looked very differently: a ton of applied math yes, but also assembly programming, graphics programming, networking, databases, programming intro I-I, advanced programming I-II, project management, artificial intelligence, all kind of specializations, algorithms and data structures I-II, etc.

Is this not how it is in the US?

Edit: and most of those courses had practical lab sections with hands-on programming

Someone with enough money and long term vision could hire them, train them and rent them out for profit.

>I believe that the response of computer science departments should be to refocus themselves on the skill abstract problem-solving.

Absolutely. The value in a CS degree is not in learning this or that language or tool. It is in being able to understand how to solve difficult problems effectively.

How can you have mature engineers... with no juniors?

in 10 years everyone will be junior

just having a brain and thinking for yourself will be a super power

half the US economy already relies on the fact that younger people dont know how to use computers

> half the US economy already relies on the fact that younger people dont know how to use computers

That sounds interesting, could you expand on what you mean by that?

Not OP but people though that GenZ would be great at using computers because they were born in it. Turns out they suck at using computers even way more than boomers because they are used to the curated interface of smartphones and can't solve any sort of problem on their own.

”… I think that at this point, you might see the problem for many junior engineers. If a senior or even lead engineer can break down his problem into the smallest pieces and task an AI coding assistant with writing those pieces, then why bother with a junior engineer at all?”

There are a lot of careers with no formal training on-ramp. If demand for software engineers continues and there’s no practical way to get enough on the job experience, there will be plenty of self taught developers that grind long enough to get the experience they need. I became a software engineer at age 40. No one would take me seriously as a junior developer, so I just kept leveling up my skills until I could get a mid-level role at a company that was desperate enough to hire me.

the senior engineers will age out, so the industry would want to make sure there's a pipeline of new software engineers

"Why should I train them up when they might leave? Let somebody else train them, then I'll hire them afterwards." — Companies, in a prisoner's dilemma.

This. So much this.

I train them for you, you train them for me, together we make a happy industry.

The juniors you train today someone will poach, surely, as you'll poach someone else's, and it levels out.

Training people is a cost, an investment, if everyone does it the cost is amortized across the industry. If I can cut that cost by using AI I'm now at a competitive advantage, everyone will look to cut that cost because the downside of paying for training juniors that may leave is worse for that company than the downside of the whole industry not training juniors any more.

That's true in the short term.

Fast forward half a decade forward, and there's no juniors or mediors to onboard, no-one to have gemeric expertise that can be fine tuned to your product.

From the individual incentive standpoint, it's not immediately clear who would make a decision to establish such a pipeline and subject their organization to short-term competitive disadvantage. A CEO of a public company can't really say "our R&D is 2x our peers because we're building a pipeline".

What I suspect is going to happen is something like the regional pilot situation, where one toils for pennies at lower levels and then gets to comfortable compensation numbers 10-15 years later.

I suspect we will continue to have junior developers, albeit the tasks they are tasked with may change. One big issue is that it is expensive to have senior devs essentially correcting AI slop. Additionally, at current prompt pricing I suspect a junior dev is a better ROI still. A more likely result is increased expenditure due to trying to keep up with the AI hype, not a reduced team size.

I have yet to hear of a productive software development shop successfully reducing staff count due to LLM usage.

Founders at AI Slop Fixers Consulting Inc will become billionaires.

I'm sure there'll be a lot of such work, but I don't think it will attract crazy investor dollars.

Millionaires, at best. :p

Every time I see a CEO say this, I think it’s time to reach out and poach their engineers.

All I have to do is show them the CEO’s quote to demonstrate what they think of their engineers. How can they see a future at that employer?

Eh, they are all hoping to make it big and bank out their paper money. As long as they are still bankrolled by the VCs, it won't change. Although the engagement of Softbank is a solid historic indicator they could eventually go bust :)

Frontend development is time consuming and difficult because it's often inherently stateful, there is typically a tension between aesthetic and functional dimensions and you're interfacing with people, who are unpredictable and varied.

From my perspective most UIs suck in the sense that they almost always can be better in some way or another.

Anything that helps speeding up feedback loops in this space will be extremely welcome. It will enable developers to push for higher quality and make room for innovation.