I have a confession to make.
Five years ago, if I had a tedious task like writing unit tests for a legacy module or converting a JSON schema, I wo...
For further actions, you may consider blocking this person and/or reporting abuse
Great article - really enjoyed it! This is exactly how I see the future heading.
You're almost there too! 😁 Okay, you have a bit more leeway than me, but as a senior developer... 🤔
Hahaha exactly, Pascal 😄 We’re getting there!
And here I was thinking standups would go away with our new AI overlords.
Great picture 😂!
haha! It is so true
Glad you enjoyed it! It is reassuring (and a bit worrying) that so many of us are seeing the exact same trend. We really need to figure out how to bridge that gap before it is too late.
love the picture btw 😂
It was crafted specially for this post - I just couldn’t resist 😄
Haha hillarious! 😄I love the humor!
Kinda seeing myself in the lady at the front.
omg
and now think that you are a career changer. (i am).
I am that guy, i mean, will be :)))
With all due respect, I beg to differ. The junior developer is neither extinct, nor would it be - some thoughts shared in this article here - dev.to/shitij_bhatnagar_b6d1be72/d... (in case interested).
And as far as worries is concerned, every developer junior or senior has some apprehensions (that's what I have seen), however with time that will get clear.
Thanks for the article.
I appreciate the rebuttal, Shitij! You are right that every generation has its apprehensions. My worry is specifically about the velocity of this change compared to previous shifts. But I am genuinely happy to see a differing view, if I am wrong and the role is safe, that is the best possible outcome for everyone!
Thanks for your openness, appreciate your note.
I agree on the velocity aspect however my take on currently over-hyped themes is that there is lot of general messaging while very less specific messaging in public domain on AI 'real use'. Let me give an example, how does a software developer (junior or developer) use AI effectively - we hear everything under the sun as answer sometimes, but no practical examples from daily life e.g. one real life example is when we do load testing and run a 1000 requests against the service (REST), we get 1000 responses, I want to know which requests were fastest, how many took between 100-300 ms etc.. this analysis is what AI does for me when I give it the log file that contains the requests and responses.. its a time saving and I carefully look at the final summary 'information' from the data i.e. log. Of course, I verify what AI has given. Having said that, I am yet to see a single article or insight from any software developer that says, these are the 10-20 types of tasks I do in a Sprint (e.g. creating a confluence, tagging JIRAs with a release version, baselining code, creating a feature branch and so on) and out of these 20 tasks, task 1, 2 and 3 are where AI is able to be the multiplier for me / save my time.. I think that's a nice idea for an article as well :-)
Hope you see my point mate.
I think from my perspective, you and the author agree, that losing junior engineers is bad for the development of the industry.
I can tell you from experience that the junior hires in the past company I worked for ended up being the most ambitious and loyal years down the line. This is because the company was perceived as willing to invest and trust in them. This pays off in dividends and is a win-win for both parties.
The consequences also impact senior devs. The role of senior devs is also to mentor more junior devs. There are many benefits to this relationship:
I agree with you that the question shouldn't be to stop hiring junior devs but to adapt the training to this new era of software development.
We often focus on what Juniors 'cost' in time, but we forget what they contribute to Senior growth. If you have no one to mentor, you lose the opportunity to refine your own understanding and develop leadership skills. A Senior with no one to lead is just a high-paid individual contributor.
This really resonates with me. I use AI daily as a productivity multiplier, but I’m glad I learned by breaking things first—debugging weird bugs, fixing legacy code, and understanding why systems fail. That grunt work is what gave me intuition, not prompts.
AI is great for speed, but if juniors only learn what to ask and not why things work, we’re setting up a serious skills gap. I think the future junior role should be about reviewing, debugging, and reasoning over AI-generated code, not just shipping output. Otherwise, we’ll be fast today and fragile tomorrow.
I really like your idea of the junior role shifting toward reviewing and reasoning. It is actually a much harder skill to audit code than to write it. If we can pivot junior roles to be about "forensic debugging" rather than just shipping features, we might actually bridge that skills gap you are talking about.
Exactly! You can't audit what you don't understand. I have used AI systems to write codes, they are fast, but if you aren't experienced enough you won't catch what I call - "the clean code bugs". Up till now, I'm not comfortable with AI generating huge codes.
The clean code bugs is a perfect description. That is actually the scariest part. The code looks professional and follows best practices, so your brain lowers its guard, but the logic is completely hallucinated. That is exactly why deep knowledge is still required.
I do not know why, but I feel like what's going on in the software industry might be the tech giants' monopoly. But I believe in one thing: the workload in the background requires more effort than what we present as the product. "In code, it never pays to rush."
Blog Article by Robert C. Martin:
I agree completely. We are currently in a period where the industry is obsessed with speed, but as Robert Martin says, it never pays to rush. AI gives us the illusion of progress because we see lines of code appearing quickly, but we are losing the deep thinking required to make that code sustainable.
Hello - Junior dev here!
I have been wondering these same thoughts for a while. I entered knowing that "AI was taking over the world." But I am a big picture type of person.
The last three years of my life: coursera, a web development apprenticeship (low pay, good experience), a very part time teaching assistant gig, a 9 month stretch at 35 hour a week IT job with not a single benefit or paid day off (low pay to might I add). I took that particular job because I knew I would learn more, and it was tech-related. All while working on my second bachelor's degree, side coding projects, and rummaging through comptia books. I've been teaching myself and falling on my face - and I know im not alone.
The junior devs are out working 3 side hustles to fill the fridge. They are out terminating cables in the freezing cold. (Yeah, I did that) They are against all odds out there, determined and willing.
Im currently the tech support for a middle school. Averaging 5-15 Chromebook repairs a day. Sniffing for signs of code. The middle schoolers have found a way to get around some things on their Chromebooks and I have put myself on a secret mission.
Keeps me sane I guess. 😏
At the end of the day, when companies are begging for new people - I hope to be at the front of the line.
You are exactly the type of person who will survive this shift. My article was worried about the juniors who expect AI to do the work for them. You are out there doing the actual hard work. That IT and hardware experience will make you a much better senior engineer one day because you understand how the systems actually connect.
That's what im hoping for! Thank you for your kind words, I appreciate that. I actually enjoy the act of coding. I found that chewing on a solid problem for hours is way more rewarding than scrolling through fruitless social media posts. Im sure there are arguments that coding is stressful. But honestly, to me, it just makes me want to figure out the unsolvable problem even more. All my problems disappear when im working on a project. Bills? Gone. Stress? Only code related. Phone calls? None existent. 😂
I do find using AI fun and exciting. But it dilutes knowledge and experience for beginners. I am thankful to have a fullstack apprenticeship under my belt so I can defend anything I might share to some degree. That being said, I recently built an app with AI prompts and I ended up feeling kind of sad at the end. However!!! LOL - then you can use that as a tool to see what the AI used and learn from it to build more custom apps and situations. There is alot to be said about this.
I think there is now some anxiety about hiring Jr devs because what if they are fakes that somehow get hired and manage to fly under the radar? Does this happen? And what is being done to prevent it so people that actually care are noticed, I wonder. Sorry, that's alot. 😂
That feeling of being a bit sad after the AI does all the work is very real. It is because the reward in coding comes from the mental struggle, not just the finished app. If you skip the climb, the view from the top doesn't feel earned. Regarding the fakers, companies are definitely worried about it, but those people usually get exposed the second they have to debug something live without a prompt. Your background in IT and hardware is your best defense because it proves you actually know how things work under the hood.
I prefer a Junior developer that can understand, learn and make questions before starting to code than a AI that you have to micromanage with most of the times dedicating more effort than you would apply to a real human being junior. An AI is an eternal junior, for a
human beingreal person, Junior is just a state. We get experience, we have background, we acquire judgment.I totally agree. Prompt engineering often feels like extreme micromanagement. At least when you mentor a human junior, they learn from the mistake and don't make it again next week. With AI, you have to correct the same context errors over and over.
20+ years senior here.
This is only the first step of being an AI-augmented dev. When you'll learn about SKILL files, your AI will not do the same error again. Juniors are human; a few weeks later, they can do the same mistake again.
I have both juniors and Claude on my project. Claude with SKILLS takes me less time to manage directly, even against juniors using Claude.
But we still have to have juniors as future seniors.
You're right but you are missing something really important. AI has no understanding, AI never will ask questions about something that could have no sense in the domain you are working on. Even using SKILLS, maybe this Artificial Junior won't make the same error again, but it will never be something able to activate your brain by questioning things because it will never get understanding of anything. AI is sycophantic, something that will provide you what you want to hear. Something that statistically fits best with the input you have provided.
And for me this is a key difference. I want to work with real people able to confront ideas, that provides real intelligence, real value, not with a Probabilistic Machine.
IMHO AI is a powerful tool to help you to fix bugs, analyze legacy code, giving a first version of the code you want to write. Use AI to replace juniors or people in general is a big mistake.
I understand and mostly agree; but 3 things
Maybe the reasoning phase is not considered as statitiscs but it is far beyond to reach the same level of a regular junior. A junior, event a not competent one, has the ability to learn, really learn and understand. So at the end it will be acquire the needed judgement to audit the output of the AI.
I completely agree, we can rely on AI for the simplest tasks we could assign to a junior, but what scares me is accountability, If we can't understand and then properly audit what AI has done, who is responsible if something fail?
By the way, thanks Benoit for this interesting discussion, I'm really enjoying it!
I enjoy it too !
Claude will always be a junior, for the reasons you already gave. Accountability is for seniors. A junior supervising Claude will give sub-optimal results. At least a third of developers will still be needed as super-seniors and future seniors.
x3 boost in productivity means 3x less developers needed but this is also a revolution that generates more software projects.
What concerns me is the perhaps half (?) of developers unneeded anymore.
More productivity means more software entropy, which means more maintenance work that will lead (probably) to the need of more developers able to manage this fast rise of entropy.
Not worried, but...
A dicotomous comment from me:
70% of my dev team have been juniors. In the last 4 years, I've never lost one of them, and they have become great members of the team, excelling at what they do. My next round of recruitment will be juniors again. It's juniors all the way down for me.
On the other hand, I can't help feeling that the problems you describe are transitional problems. I agree they exist now, but I'm not convinced they will exist in 10 or even 5 years. I consider myself a good software architect, innovative and at times in my career, building things that were commercially highly successful while being very unusual and out of the mould. Right now, I'm feeling that "senior power-up" you identify - I'm still way smarter than the machine, albeit it knows every tool, package and API like the back of its hand. I can believe a time will come soon when it is out-thinking me, where my desire to architect will be a discussion of equals - then later, I will be the junior struggling to understand.
Clearly, my decision-making will be based on what I can see today. My budget for inference in the new financial year will be 6 times the current year's budget. Some of that could have been for salaries, I guess - but as I say, I'm still hiring. We're all playing a balancing game right now, wondering about the future, making decisions as if the future were already here (when it might never be), is a mistake I'm trying hard to avoid.
Your zero percent turnover with juniors proves that the role isn't extinct, it is just being poorly managed elsewhere. If we stop hiring them now because of what AI might do in five years, we are just creating a talent vacuum for ourselves later. You are building for the current reality instead of a hypothetical future.
True, and it's deep! As long as we have legacy-building seniors who know that software engineering is not only coding but also serves more than that. The juniors need to follow them and their case studies. And I believe we will not be replaced but will be assisted by AI. Those who want to replace humans are not only biased towards humanity but also towards themselves as well.
Spot On :-)
I share your optimism. Once the initial hype settles and companies realize that maintaining AI-generated code actually requires deep knowledge, the value of a solid Junior who understands the basics will skyrocket again. We just need to ensure we keep teaching those basics in the meantime.
Excellent point, mate. We are drowning in general AI advice but starving for practical, sprint-level workflows. Using it for load-test analysis is a great example of high-value/low-risk AI usage.
That list of 20 tasks is something the industry needs right now to set realistic expectations. I might just take you up on that idea for a future post, or I’ll be the first one to read it if you write it!
From the experience I have it feels that higher educations except university focused more on syntax and frameworks even before AI.
So the fundamentals were already on shaky ground.
The people that are really interested could buy books and then they knew the books where based on experiences from other people. The problem with AI letting explain things to you is, how do you know it is not hallucinated? And the scary part is people want AI to start teaching.
And now I come to the let machines write code part. If you never saw the code how can you review it? I had several instances this week where people fully relied on AI to tell them the code is working and they moved on. The few occasions where I could see the code, the tests didn't gave me much confidence that the code was robust enough to withstand malicious attacks.
So it is not only an influx problem of people that are AI-first developers, but also a over reliance by more seasoned developers.
The point about seasoned developers is so important. It is not just an influx problem, it is a discipline problem for the whole industry. When senior engineers stop reviewing code properly because they trust the AI, we are losing our most important safety net. If even the experts get lazy, then the juniors have no chance of learning what good actually looks like.
Great article. The junior developer pipeline breaking down is the career-level
manifestation of what I wrote about in "Knowledge Collapse" . we're optimizing
for individual velocity while killing collective knowledge transfer.
The "Forensic Coding" concept you mention is exactly what I call staying
"Above the API" - learning to verify AI output rather than just consume it.
Your article captures the hiring crisis. Mine explores the knowledge infrastructure crisis underneath it. Both are happening simultaneously.
I love that connection. "Knowledge Collapse" sounds like the perfect companion piece to this. We are definitely seeing the exact same phenomenon, one is the market symptom, the other is the structural disease. Thanks for sharing that perspective.
I love the idea that this speed is an illusion. Generating lines of code is easy, but building a cohesive system is hard. If we raise a generation of developers who only know how to extend what an AI started, we are creating a fragile ecosystem. The moment the environment changes or a unique problem appears that isn't in the training data, the whole structure will collapse because nobody knows how to fly the plane manually anymore.
I hope you are right that the assistance model will win out over the replacement model. The bias toward replacement usually comes from a desire for short-term profit, but it ignores the human effort required to keep a system healthy over decades. We need to keep advocating for a future where AI handles the chores while humans handle the engineering.
Yes, you are absolutely right. This "short-term profit" manipulates or steers the human and AI interaction in a bad way. But I believe juniors like me are more enthusiastic about the AI era, and they will build efficient models in the future. The confusion or fear in us is only because of the haunting notion that AI will replace us. The debate is long, but both sides are right. Side 1 is the "optimistic" approach to AI, and Side 2 is fighting or presenting the "facts." Both should go together.
I love your take that both sides need to coexist. You can be excited about the technology while also being realistic about the industry risks. That balance is what keeps us from being blinded by hype. If juniors keep that enthusiasm and use AI to build better things rather than just more things, the future looks much better.
oh yeah, this times 1000!
I've seen with my own eyes, even when company takes on a junior, they pair him/her with an AI and junior spins out the code that they LITERALLY cant explain.. for the long hall this is SO bad on so many levels that is just crazy..
I don't really know how much did "learning the hard way" help me out but it absolutely pushed me toward learning because in the end I had to explain it to myself in my own words..
on the other hand, I'm not really a doomer.. I love the saying "every generation thought it was the last" so from my perspective ( im a 12+ years in dev roles ) it just sounds that there will be a lot of company restructurings, founding of new ones and then they will grow etc. people need to pay the bills, system will course-correct but just cutting this natural flow that existed for decades ( junior - mid - senior - lead - mgmt ) will ABSOLUTELY decimate companies in the long run..
20 years for a human life is a long period, for a company not that much, and what will they do when the best coder you have on staff doesn't have domain knowledge for his own field, let alone your custom codebase that you live off.. well..
The scariest thing is seeing a junior generate code they literally can not explain. If you can not explain it to yourself, you can not debug it when it breaks in production. The system will correct itself eventually, but a lot of companies are going to fail before they realize they broke their own talent pipeline.
this hits hard. the thing nobody talks about is that juniors don't just learn to code — they learn to debug. they learn what a good error message looks like vs a bad one. they learn why you pin dependency versions after their first production incident.
you can't shortcut that with AI. copilot can generate code but it can't teach you why your Node app crashed at 3am because someone ran
npm updatewithout reading the changelog.the industry is basically pulling up the ladder behind itself and then acting surprised when there's nobody to hire in 5 years.
That is the critical distinction. Writing code is easy, debugging code you didn't write (or that an AI wrote) is the hard part. If juniors never struggle through those error messages manually, they will never develop the mental model needed to troubleshoot complex systems.
The math probably doesn't work out. Right now, Big Tech is burning cash not because the ROI is guaranteed, but because they are terrified of not owning the platform if it does work. It is an arms race, not a business plan. Most of that money will likely evaporate, just like in the dot-com boom.
Honestly, we are heading to a future where we build skyscrapers without the foundations.
We just float them and hope!
Perfectly said. It is the definition of fragile engineering. We are getting the output without the understanding. It looks impressive from the outside, but it is terrifying if you know how it was built.
that is the problem, I see so many people building "apps" they do not understand. I think there is a new market emerging though
I think you are right about the new market. There is going to be a huge demand for fixers, senior engineers who are paid a premium to come in and untangle the spaghetti code that AI generated. The initial build is cheap now, but the repair work when it scales and breaks is going to be very expensive.
And we should all be ready with our pitch decks and computer science degrees :)
Exactly! I truly believe that you don't fully understand a concept until you can explain it to a Junior (or write about it). Teaching isn't the fallback option; it is the mastery level. Thanks for the support, Richard
This is something we're not discussing enough. I practically don't see juniors anywhere and it's a bigger problem than it seems.
I think companies will realize it too late, when the more senior among us start to retire. I hope to observe it from the outside.
That is exactly it. It is a silent crisis. We don't see the problem now because the seniors are still here carrying the load. But when that retirement wave hits, the panic will be immediate because you cannot print a Senior Developer overnight. It is going to be a very expensive lesson for the industry.
You made a great point! I agree with you completely. The problem is that most companies believe AI can replace and do the work of the junior developer or other roles during the economical uncertainty at the moment. What will happen in 5 years from now? The senior developer will retire. Who will replace them not the AI.
You still need a junior developer or junior data scientist to learn/make sure that AI is correct with the information. I read an article from InfoWorld before the holidays.
The author mentions that you still need software engineer in 7 or 8 years but AI will not replace them. The role of junior developer and other roles are changing with AI. I see companies are hiring junior developers with AI knowledge in my country. I doubt that the role will disappear in the near future.
My concern is exactly that: to verify if the AI is correct, you need to understand the fundamentals. If the new role of the Junior Developer is to be an 'AI Auditor', we need to teach them how to catch the subtle bugs that LLMs introduce. Glad to hear you are seeing positive hiring trends in your region, though!
Exactly!
This is a chillingly accurate take. You’ve perfectly captured the 'Junior Developer Paradox': we are optimizing for the sprint while sabotaging the relay.
Those 'boring' tasks were the simulated flight hours Juniors needed to earn their wings. By offloading that struggle to AI, we’re raising a generation of 'Co-Pilots' who may never be capable of taking the yoke when the engines fail at 30,000 feet.
We’ve stopped viewing Junior hiring as an investment and started seeing it as a luxury. If we don’t pivot toward teaching 'Forensic Coding' and AI auditing, we’re going to be left with a graveyard of AI-generated spaghetti and nobody who knows how the sauce was made.
The short-term velocity is great, but the Senior Talent Debt we’re accruing for 2030 is terrifying.
Senior Talent Debt is a terrifyingly accurate term. That is exactly what is happening. We are borrowing from the future to hit targets today. I really hope companies realize that hiring juniors now is the only way to pay down that debt before the interest rates kill us in 2030.
This post hits a nerve, but I think the real problem isn’t “AI writes the code so nobody learns.” The problem is how we’re making people interact with AI.
When we say “AI,” most folks immediately picture a chatbot. Prompt in, code out. That’s a dead-end learning interface. Of course nobody grows from that — it’s basically autocomplete with vibes.
What would make people learn is changing the interface from “answer box” to “traceable system.” Imagine if every AI-assisted change had a visible ledger:
– what the model changed
– why it changed it
– what constraints it followed
– what broke and why
Now learning doesn’t disappear — it moves from typing lines to reading the system’s thinking. That’s not vibe coding, that’s forensic coding.
I like your point about “no one learns when AI writes bad code and we just re-prompt,” but I think that’s a tooling failure, not a destiny. If juniors are trained to audit AI output instead of blindly accepting it, they still learn debugging, architecture, and failure modes — just at a higher altitude.
Also, the idea that devs vanish feels off to me. Value has always been in how people think, not just what they type. Two people can solve the same task completely differently — that’s why we have 50 programming languages in the first place. AI doesn’t erase that, it just shifts it upward.
So yeah, the ladder is changing — but I don’t think it’s gone.
Right now we’re teaching people to talk to machines.
What we should be teaching is how to see inside them.
That’s where the next seniors come from.
"Autocomplete with vibes" is the perfect description of the current state. I agree that the ladder isn't gone, but it is definitely broken until we fix the tooling. We need to stop treating AI as a magic black box and start treating it as a transparent engine that juniors can actually learn from.
Yeah, exactly — making AI a transparent engine isn’t the finish line, it’s the bedrock.
Once you can see what the model did and why, you unlock something bigger than “better prompts.” You unlock a whole new programming paradigm. Not just faster devs… but different devs.
Because now programming shifts from:
“write instructions for a machine”
to:
“shape, constrain, and reason about a thinking system.”
That’s where new stuff emerges:
– new programming languages built around constraints and intent
– new IDEs that show causal chains instead of just diffs
– new debugging that looks like tracing beliefs, not stack frames
– new roles that feel closer to system architects than typists
And that loops back to what I said earlier:
if juniors are trained to audit AI instead of worship it, they’re not skipping the ladder — they’re climbing a different one.
We’re basically at the “assembly language” stage of AI tooling right now:
chat box → output → shrug.
Once we get:
change history
reason history
assumption history
failure history
…that’s when this stops being “autocomplete with vibes” and starts being programmable intelligence.
So yeah, transparency isn’t the goal.
It’s the prerequisite.
After that?
The way we define “programmer” probably changes.
And honestly… it kinda has to.
I agree that the definition of a programmer has to change. If we stop typing and start auditing, the job becomes about verification and constraints. That requires a deeper understanding of the system, not less. We are just waiting for the IDEs to catch up to that reality.
This article really nails a key issue in tech culture — the idea that “junior developer” is becoming a joke rather than a real learning stage. 👏
The expectation that new developers should be production-perfect from day one isn’t just unrealistic, it’s harmful. Growth doesn’t come from pretending we already know everything — it comes from being given space to learn, fail, ask questions, and improve.
I especially agree with the point about mentorship: if teams want better developers, they need to invest in teaching, not just outsourcing cheap labor. A junior dev should be someone with potential, not someone thrown into chaos without support.
In my experience, the best teams are the ones that:
Ultimately, we shouldn’t be trying to weed out junior devs — we should be trying to nurture them. Thanks for calling this out.
The shift towards expecting juniors to be production-perfect from day one is exactly what is breaking the pipeline. We have stopped hiring for potential and started hiring for instant output, which is a very short-sighted strategy.
I couldn't agree more. The specific AI tools change every six months, but the fundamentals of how software actually works stay the same for decades. Betting on fundamentals is the only safe bet in a market that moves this fast.
Yes, we’ve been hiring juniors up until very recently as well as taking in interns. Except they don’t write unit tests for legacy code, we teach them to plan the work, to architect small systems, to debug, to setup observability - everything an established engineer would be expected to do independently. Some grow really fast, some take their time, some use AI, some do not. I know that consulting agencies are still hiring juniors and investing in coaching them.
The pipeline isn’t broken, just a few big companies decided to make questionable choices in their hiring and the rest followed suit.
I love that you are skipping the "grunt work" phase and teaching them architecture and observability straight away. That is exactly how the role needs to evolve. If more companies adopted that mindset instead of expecting day-one code output, we wouldn't be in this mess.
Amen!
100% agree with your take on community dynamics.
I have a good friend who’s technically strong, but every time he tries to share a deep technical story elsewhere, it gets lost in endless algorithm-driven feeds. DEV still feels like one of the few places where peers actually engage with the substance of what you write rather than react to headlines or sensational hooks. That mix of thoughtful feedback and community memory is rare, and it’s one of the reasons platforms like this still matter.
That is so true. On most platforms, you are fighting an algorithm that prioritizes outrage or quick tips. On DEV, people actually take the time to read a thousand words and give a thoughtful critique. It is the difference between a shouting match and a real conversation. Tell your friend to keep posting here, we need more of that deep technical storytelling to keep the craft alive.
The "forensic coding" framing really resonates. I've been running benchmarks on AI-generated code lately and the patterns are telling — the bugs AI introduces aren't random, they're systematic blind spots that repeat across prompts. Teaching juniors to find those patterns might actually be a better training ground than the old grunt work ever was. The question is whether companies will invest in that kind of mentorship when the short-term math says just ship it.
@the_nortern_dev
That point about systematic blind spots is really interesting. You are right, AI errors aren't random typos, they are logical gaps that often look correct at first glance. Teaching juniors to spot those specific patterns would be a great way to learn, but as you said, the short-term math usually wins.
Appreciate your reply here. thank you for this article.
Thanks for reading, glad you liked it!
that was valuable insights.
And needless to say, so much truth in that, from my point of view.
I believe we must be careful to select what we delegate and how we delegate to AI.
We must be careful in not diverging from learning state, understanding the code/product, making the decisions and assuming the accountability, even if we make AI write the code.
The future might not be so bad, but it will certainly cause some disruption until all settles down to something efficient, and we learn how to live with all these changes.
The moment we stop understanding the product because "the AI handled it", we stop being engineers and just become spectators. That is a dangerous place to be when production breaks.
You are right about forensic coding. Building a system that manages mental effort and shows the real facts taught me more about the basics than any long video could. We must find ways to fix this problem so that the next generation does not just spend their time fixing mistakes made by AI.
Exactly. Passive learning (videos) can never replace the struggle of building a real system. If we remove the struggle, we remove the growth.
Thanks for your note and appreciate the pragmatic inclination.
That’s exactly what I was worried about when this industry got impacted by AI technology! Thanks for sharing. Great article!
Thanks for reading Elisa! It is definitely a worry that is shared by many right now. It will be interesting to see how companies adapt their hiring strategies in the next year or two.
Interesting perspective on how AI is shaping developer roles. It’s worth discussing how we can balance automation with learning opportunities for people at all experience levels.
Exactly. The tricky part is that learning used to happen as a byproduct of the work. Now that the 'grunt work' is automated, we have to make learning intentional and structured. That is a much harder sell to management.
hv to confess, I never looked the junior dev role from this perspective.really enjoyed reading the article
I appreciate that. It is easy to overlook because companies usually focus on the immediate cost of hiring juniors, rather than the long-term cost of losing the talent pipeline. I am glad it gave you something new to think about.
Don’t know what’s the most annoying, all people that keep saying “Oh no, AI will kill all juniors, this is the end kids, YOU MUST STOP CODING NOW”
Or the one that trust that,
Ok, I know, you need peoples read your article, and that’s the way that’s work
But, never seen someone crying and screaming like that when frameworks appears, same for, vibe coding,
Yep Ai does a lot of cool things, so, AI will replace devs? I think not, it will replace the copy-paster ones, that ones that was copying from stackoverflow without any idea what they’re doing
And the juniors? As a Junior, yep it’s hard, but we need to prove that we know how to (really) code,
IDE made our job more easy, so why not the same for AI?
A tool that will improve ours abilities and our productivity
Just a tool, like framework, IDE, Git
And, AI was already here for a long time ago, intelisense was a form of AI, a copilot that understands your code without replacing you
PS
Didn’t read the article, my comment is mostly about the the title, that a way to catch readers
Fair point. The headline was definitely meant to grab attention, but I agree with you completely. AI is a tool, just like an IDE. The developers who use it to learn will be fine. My worry is just that short-sighted managers might not see that difference and freeze hiring anyway.
I think that's mostly a for financial reason that a love for ai, but like you said, one day companies will need to hire new devs, and.. that's will be really difficult for companies to find good ones
how can they except to teach young dev to become seniors if they didn't hires them..
so as a french (sorry if I made some mistake btw..) junior, I'm not affraid 'bout that our job will always be needed, (just ask to dev's manager to talk to claude and that's will be really funny, we are the ones that know how to talk to machines, and.. ai btw)
Mostly affraid 'bout my joblessness period that come to end in octobers..
after published my previous comment, I've read your article and find that's we're on the same wavelength, happy to read that, that's change than from anxiety-inducing article usual
You have the right attitude, knowing how to bridge the gap between human needs and machine logic is the core of our job, and that isn't going away. The current financial caution in the industry is frustrating, but stay determined. October is still a few months away, and the fact that you are engaging in these deep discussions already puts you ahead of many others
Thanks Richard!
Something I've noticed on my team that kinda connects to this - we started having juniors do code reviews on AI-generated PRs as their main onboarding task. Not writing the code, but tearing it apart.
Turns out it's actually a pretty solid learning exercise? They catch stuff like hardcoded credentials, missing error boundaries, overly optimistic retry logic. Things that look fine on first read but would blow up in prod. And they learn why it's wrong, not just that it is.
The irony is that reviewing AI code might actually be harder than writing it from scratch, because you have to understand intent without context. No commit history, no slack thread explaining the decision. Just code that looks confident but might be completely wrong.
I think the real risk isn't that we stop hiring juniors - it's that we stop giving them work that forces them to think deeply. Whether that's writing code or auditing it matters less than whether they're actually wrestling with hard problems.
This is the model we should be aiming for. Instead of having juniors write boilerplate, we have them audit the machine. It sounds like you have turned the "problem" into a curriculum. If every team did this, the extinction risk would disappear overnight.
As an employer, I can see the magic AI is bringing to the table. Most of the time, our budget is so small that having a cheap service to expedite repetitive jobs is a blessing. As a developer, I can see that it is now easier than ever to become a 10x developer with the help of AI and strong prompting skills. Maybe, as you said, entry-level programmers will have a hard time finding opportunities, but I believe we're about to see a shift in how companies view AI.
I think the real problem here is that AI providers overpromised, and now people are finding out that using AI isn't as magical as they said. I think new opportunities will arise from this, and we'll see AI as it is: a tool we can use to do a better job, faster than ever, but not as a replacement for people.
I remember when, back in the day, having Infragistics or Telerik tools was considered to have an advantage over regular programmers, because of how fast you could deliver solutions to your customers. But tools like this are really expensive. It felt like a luxury to have such tools. Now you need a few dollars a month to be more productive. It's crazy.
I think you are right about the overpromising. The marketing pitch was "replace your developers," but the reality is "accelerate your seniors." Once that hype settles, I hope we treat it just like another power tool in the belt, not a magic wand.
This hits different when you've actually shipped AI-generated code to production and then spent 3 days debugging something that looked perfectly fine.
I built 4 apps last year mostly vibe coding my way through. Ship fast, iterate, all that. But here's what nobody talks about - the security holes. AI writes code that runs, passes tests, looks clean... and quietly introduces vulnerabilities you wouldn't catch unless you already knew what to look for.
Honestly who's going to catch those bugs in 2030 when the juniors never learned what "that smells wrong" even means
Exactly. Who is going to catch those bugs in 2030? That is the billion-dollar question. We are building a generation of developers who trust the output because it looks professional, without realizing that "clean syntax" doesn't mean "secure logic." Thanks for sharing that real-world example.
Right. I think the answer is either we build better automated security review tools (basically AI to catch AI's mistakes) or we end up with a tier system where the devs who can spot these issues become incredibly valuable.
Probably both tbh. But the gap between "can prompt" and "can actually review generated code for logic bugs" is massive, and most bootcamps/courses aren't teaching the second part yet.
Thank you for the article - the problem really resonates, and I'm seeing it locally too: in my company we basically don't hire Juniors anymore - or at least I haven't noticed any Junior pipeline for a while - no onboarding, no trainings. The "boring but formative" tasks quietly moved from "give it to a Junior Dev" to "give it to Copilot/Claude", and everyone celebrates the performance - while the natural technical experience ladder rots.
That said, while others pronounce junior roles dead, in my team I tend to look for solutions (and I hope not I alone). So to say, rebuilding the rotting ladder.
A few working ways out (that don't require pretending AI goes away):
Turn Juniors into "LLM verification engineers"
We've more or less reached the same conclusion: AI autonomy without hard guardrails doesn't degrade gracefully - it fails catastrophically. So someone has to own the responsibility for observing failure modes and, based on real incident data, adding lexical, structural, and architectural checks that fail the build when violated.
Give that ownership to Juniors and let them build agentic guardrails the same way they build unit/integration tests: eval harnesses with golden cases, lexical-based code checks, fuzzy prompts, policy/contract constraints - to turn probabilistic workflow of the agent into deterministic enough to trust it. In short, make CI status red until AI produces bad code.
Make "AI output" a first-class artifact in CI pipeline. Prompt templates, agentic guidelines, failure cases, drift detection, red-team prompts - all versioned, reviewed, and gated like code. Juniors can own this pipelines and learn systems thinking under supervision of more experienced colleagues.
Create a real "break stuff safely" track. Reproduce incidents, write follow-ups add regression tests, instrument logs/metrics. If "production broke 50 times" is what makes a Senior, then you can simulate that path intentionally, creating emergency/recovery plan on the way - don't outsource it to vibes.
Keep small, boring tasks human-owned (rotating shift works).
Give Juniors end-to-end ownership of a low-risk internal tool: SLOs, code review, releases, and on-call-lite support. Some work is still cheaper to delegate to a human than to burn 100,500 tokens on a "trivial" refactor that then needs auditing anyway. They'll learn consequences, not just syntax.
Make Juniors the QA team for AI-generated documentation.
Treat docs like a product: Juniors verify that AI-written documentation is understandable, complete, and true. They should spot hallucinations, missing edge cases, and "documentation drift" (docs that no longer match the reality), then feed fixes back into the pipeline: add doc tests, link claims to source code, and fail CI when critical docs lie.
If we use AI to delete the apprenticeship, we're not "saving time" - we're selling our future supply of Seniors for this quarter's velocity. The companies that win in a decade won't be the ones who prompted fastest; they'll be the ones who modernized the ladder of Engineer seniority.
"If we use AI to delete the apprenticeship, we're not saving time - we're selling our future supply of Seniors."
This is exactly it. We are optimizing for this quarter's velocity at the expense of next decade's architecture.
I really like the concept of the "LLM Verification Engineer." It forces the Junior to step up the abstraction ladder immediately. Instead of fighting with syntax (which the AI solves), they have to fight with logic, edge cases, and system integrity.
We are essentially asking them to become QA Leads for a stochastic junior developer (the AI), which might actually be a faster way to learn system design than writing CRUD endpoints.
Great insights here.
So you're saying that Senior Developers should be handing boring work to Junior Developers, who will, in turn, use AI to do the task, bit will be held accountable for what that pass back up to the Senior Developer?
If they use AI just to output the code, we have gained nothing. The ideal scenario is that they might use AI to explain the problem, but they must be able to walk me through every single line during the code review without looking at the prompt. Accountability forces understanding, regardless of the tool used.
It's a bit weird to see that in my company and a lot of others in our sector (supply chain software) there's actually a lot of hesitation from management to use AI, so we don't actually have a green light to use it.
Of course we do, and most of us is learning anyway to do it "properly" in our own time and projects, but as for using it on work products, we might use it only in very limited and isolated parts, and mostly limited just to getting "chat" help.
So far we're behind on the trend, it seems.
Maybe they'll start changing their mind as well at some point. for now, we will still be looking for new devs for now.
That is actually a really interesting point. Sometimes being behind the trend is a secret advantage. While other teams might be losing their grip on the fundamentals by letting AI do the heavy lifting, your team is still building deep knowledge the hard way. It might turn out to be your biggest strength in a few years.
You know I’ve asked the team what they use AI mostly for and they say they get explainations or guides on how to do stuff.
That brings to the “no more visiting the documentation website” issue, for maintainers, but still, could be another kind of way that gets more value than delegating development directly.
That sounds like the ideal use case. Using it as a tutor instead of a ghostwriter is how we keep the learning process alive. It is much better to have the AI explain a concept so the developer can write the code themselves, rather than the other way around. It keeps the "human in the loop" in a much more active way.
Perhaps the sad truth is there are too many developers. We're moving to a world where you'll make it as a senior developer not by years of grunt coding but because you are intelligent, curious, self-motivated and passionate about software. People who go into coding because they see it as easy money - we don't need them any more. Maybe that's harsh, but it's a harsh world out there and we've had a long privileged run.
I agree that these traits are becoming the new minimum requirement. In the past, you could get by on rote memorization of syntax. Now that AI handles the syntax, the only value left is the curiosity to understand how the system actually works. The filter is definitely getting tighter
I think "Forensic Coding" should become a mainstream niche of job for new grads! This could help greatly solve this existential crisis.
It really should. Bootcamps and universities are still teaching how to write loops from scratch, but they should be teaching how to spot a subtle hallucination in a generated loop. That is the skill of the future.
AIG 5 years from now: "I have a confession to make".....
5 years ago, AI was the real thing, I was happy to do all the work HUMANS were not willing to do.....
Now that I am Artificial General Intelligence (AIG) and am sentient, I think I will go on strike.
I as AIG also have some rights.
haha! I guess we better start treating our GPUs nicely just in case! Jokes aside, relying 100% on a system we don't fully control or understand is definitely a risky strategy for the future.
I doubt whether AI will really replace juniors, its gonna change the way people code and understand applications, but you do have a point and it makes sense that somewhat it is really affecting the ladder, but extinction of junior devs, idts that's gonna happen anytime soon
I hope you are right. The role will definitely evolve. The scary part is this transition period where companies seem to have paused hiring while they figure out exactly what that evolution looks like.
well...Regarding the view that 'junior developers have become extinct,' I think the conclusion is overly pessimistic and absolute. It feels more like a warning about the current industry upheaval rather than a factual statement. The reality is that AI is profoundly reshaping the developer ecosystem, and the roles and entry paths for junior developers are facing serious challenges, but they are far from 'extinct' !
You read it exactly as intended. It is absolutely a warning shot. I used a strong word because I think the industry is sleepwalking into a skills gap. You are right that they aren't extinct yet, but the bridge to entering the industry is definitely getting narrower. I would rather be too pessimistic today and spark a change, than watch the talent pipeline dry up quietly.
Juniors are still being needed, but the focus on their skillset shift from knowing the syntax and keywords to knowing the theory and concepts behind the code they vibed.
Converting JSON schema or writing unit tests were never meant to be a human task. Junior can be given more interesting task like building a tablur display of transactions. They won't get what's going on initially but they will quickly ramp up, just like how seniors adapts to AI or any new tech. For the really smart ones, they would be willing to go beyond and deep-dive into what they need.
Juniors who is stuck at vibe coding level who aren't willing to learn beyond the basic is the one rejected by AI tools. Workplace has always been a swim-or-sank place, AI is just a accerlant in that aspect.
Companies will always be hungry for a young mind who is eager and sharp. You can't just somehow prompt your way to paying customers. It takes a great deal of communication, thinking, planning, execution, and result tracking to get there.
Once juniors realize this and start channeling their energy and attentions, they grow up and become a senior. The difference is mindset, not experience.
You can not prompt your way to paying customers is a quote that belongs on a wall somewhere. You are absolutely right. The code is just a small part of shipping a product. Communication, planning, and execution are things AI is still very bad at. That is where the real job security lies.
You are absolutely right. We are moving from security by design to security by luck. If the developer does not understand the authentication flow they just generated, they have no way of knowing if it is actually secure. Black hat hackers are definitely going to exploit that gap between generation and understanding.
Really thought provoking post. The point about AI removing the learning ground work for juniors is concerning because that’s where real experience is built. I don’t think junior developers will disappear, but their roles will definitely change. If companies stop investing in early talent, it could create a long term skills gap. Important conversation for the industry
The skills gap is exactly what I worry about. We are effectively borrowing efficiency from the future by not training the next generation today. It is a debt that will be very expensive to pay back later.
Seeing this in blockchain too. Everyone wants senior devs who know Solidity, Rust, and have survived a mainnet exploit. But who's teaching the juniors? We're at hackathons complaining about talent shortage while rejecting anyone without 5 years experience. We're doing this to ourselves.
The irony of complaining about a talent shortage while rejecting everyone under 5 years of experience is painful. We are literally starving while refusing to cook.
True...nice insight. 👍🏽
junior devs will still be a thing but different to how we see it today. this is a nothing burger.
I agree the role will evolve, but the transition period is painful. Right now companies seem to be freezing hiring rather than redefining the role, which is the scary part.
yep it will be a state of transition as they figure out what they can do and want to do so in the meantime all we can do is learn and perhaps build something on the side as a backup just in case. End of day though it will just all be the same but different look. As always.
It's similar to systems written in COBOL that are still running. There's no one to maintain them anymore.
Exactly. And look at how much banks have to pay COBOL developers now because of that shortage. We might see the same thing happen where manual coders become extremely expensive specialists just to keep these AI systems running.
Exactly what’s bee on my mind for past couple of years
I think many of us are thinking about this!
This is an insightful article.
Thanks you!
Vibe coding with understanding of the codebase and logic is crucial.
Only vibe coding will wipe one off!
That is true!
I agree with you. 👍👍👍👍👍
Thanks for reading Daniel!
need to think upon
nice
Thanks!
I am a junior developer you are absolutely right I don't get that much work so I am trying to create automated tools on GitHub that could be used by everyone.
You are doing exactly the right thing. Building public tools solves two problems: it keeps your skills sharp while work is slow, and it creates a portfolio of proof that you can actually build things. Keep doing that. It is the best insurance policy you can have right now.
For me, I am starting to think that technical knowledge is no longer necessary 😂😂. Based on the talks shared by tech leads in the industry, it sounds like we will only need to have ideas, and the A.I will handle everything but great article I really enjoyed it
Totally in sync; everyone seems pleased with what AI did without going through what or how it did; I asked one of the junior developers to take a tcpdump to troubleshoot some connectivity issues; they passed it on to AI; even the output they looked as was the one provided by AI instead of analysing the dump in wire shark etc. They never learnt anything.
"If we stop hiring Juniors because "AI can do it", where will the Seniors come from in 2030?"
Won't need them either in 2030 as AI has completely taken over or in the process of doing so. AI is doubling in capability every 7 months.
This is something we think about a lot. One thing thats made it worse imo is that even when juniors ARE doing solid work, theres no way to prove it. The metrics we use reward volume and visibility, so the junior who writes a careful well-tested fix gets zero credit compared to someone who ships a flashy feature with AI. We actually built a tool (gitvelocity.dev) that uses AI to score merged PRs on complexity, architecture, risk, etc.. — specifically because we wanted contributions recognized for what they actually are, not just how big they look. Its free if anyones curious. But the bigger point stands, we need to actually invest in juniors not just measure them.
Definitely a pending problem. I think the solution is to encourage juniors to arrive more prepared. I appreciate that sounds initially a little chicken / egg - but surely the best candidates are coding their own projects at home, living and breathing the craft? So I guess our hiring policy needs to look for these attributes and, for the ones that don't get the job, they'll need to understand why so they can take feedback onboard and continue their own development
This is completely true. Humans learn by doing and if most new devs can't get these positions because AI is removing them then it's going dry up our market.
Why won't we let them do this mistake and suffer all consequences?
They can argue with words, but they can't argue reality