Junior devs have always been useless. You used to give them tasks that take them a week or two even though a senior engineer could do it in a couple hours, not because you wanted them to contribute, but because you wanted them to learn to contribute.
The same ethos makes sense with AI, it's just that every company is trying to avoid paying that training tax. Why turn a junior into a senior yourself if you can get the competition to pay for it instead.
Strongly disagree with this. Bad junior devs might be useless, but I’ve seen good ones absolutely tear through features. Junior devs fresh out of school typically have tons of energy, haven’t been burned out, and are serious about wanting to get work done.
Yep. This is why many companies have a terminal level with “up or out “ rules. Before that level you are not fully independent and require too much supervision. No one wants a Jr engineer with 10 years of experience.
I see a lot of Sr engineers get very frustrated by how much time they have to spend helping Jr engineers. But, that’s the job, or at least a big part of it.
I burnt out helping a junior on my team for the past few months. It was just terribly obvious she was feeding my responses directly into a chatbot to fix instead of actually understanding the issue. I can’t really even blame her, there isn’t much incentive to actually learn
I’ve gotten plenty of use out of junior devs. The critical bit is what makes anyone a useful worker. I’ve found anyone that’s both dedicated and meticulous is worth the investment.
Sure there’s a wide range of skills and you can’t just hand any task to anyone and expect it to work out but some fresh collage graduates are more capable than the average person with 5 years of professional experience. At the other end you need to focus on whatever they actually are capable of doing. 40+ hours a week can slowly expand even an extremely narrow skillet as long as they’re a hard worker.
Agreed. We are still in a capital crunch so overhiring is out of fashion. People don’t remember the early 90s or the dot.bust when the same things were said.
Kraft 1977 Programmers and Managers talked about this if I recall. Still the best alternate take on our industry I have ever read.
What’s the importance of then learning to contribute if they will probably jump ship anyway when they get good enough? Your HR department is not going to give them a market rate raise to keep them - see salary compression and inversion. A junior developer just isn’t worth the investment.
I have never once told my manager “it would be really nice to have a few junior developers. It would really help us get this project done on time”. They do “negative work”.
Yes not having juniors become seniors is an industry problem. But my goal is to reach my company’s quarterly and anual goals - not what’s going to happen 10 years from now.
> I have never once told my manager “it would be really nice to have a few junior developers. It would really help us get this project done on time”. They do “negative work”.
I have. A good junior can do in a week what a senior with domain knowledge can do in a half day, with only an hour of mentoring along the way. This isn’t a great exchange rate per dollar (juniors are cheaper than seniors, but not that much cheaper) — but seniors with domain knowledge are a finite resource, you can’t get more of them for love or money, while juniors are fresh-minted every semester. The cheapest way to shipping may not go through juniors, but the fastest way usually does; and that’s completely ignoring the HUGE side benefit of building seniors “the hard way,” which is still easier than hiring.
>What’s the importance of then learning to contribute if they will probably jump ship anyway when they get good enough? Your HR department is not going to give them a market rate raise to keep them - see salary compression and inversion.
Obviously that hasn't historically been true, else there wouldn't be any senior developers as companies would have wised up to that and nobody would hire them as juniors.
- Not everybody is a job hopper (even in Silicon Valley one sees that most junior FAANG devs stick around for a good while).
- The HR department is absolutely going to give junior developers that pass the cut after a year or so a market rate raise.
- In limited hiring periods, they'd be grateful to have the chance to stick around, while in bullish "boom" periods companies can afford to spend to keep people, expand and give them bigger roles, and so on. It's in the in-between that it becomes more problematic, but now we're in a "limited hiring" era.
>Yes not having juniors become seniors is an industry problem. But my goal is to reach my company’s quarterly and anual goals - not what’s going to happen 10 years from now.
That's how companies fail.
It's also not a good strategy at the personal level. If you command more devs, you get more leverage.
This is the difference between being an engineer and being a clock puncher. You don't care about the business, you don't care about the product, you don't care about society as a whole. So long as you get your paycheck and your annual pay bump, fuck absolutely everyone and everything else, right?
Don't worry, just leave all your problems for someone else to fix. I'm sure that won't have any lasting consequences at all.
> Junior devs have always been useless. You used to give them tasks [...] not because you wanted them to contribute, but because you wanted them to learn to contribute.
Junior devs are by your own explanation not useless. They are the most important human investment in your project.
I mean, if we’re doing this, let’s be honest and go as far as mid-level engineers whose work needs constant correction, as well as the many, many senior engineers out there who are senior only because they lucked out in getting the title during the artificial dev scarcity of the ZIRP eras.
> Junior devs have always been useless. You used to give them tasks that take them a week or two even though a senior engineer could do it in a couple hours
We havent dont it and I never seen something like that.
The challenge is to get cost sensitive businesses to support this. Juniors are a cost and when trained move on, thats the fundamental problem. Retention only works with smart companues, for most other companies its a revolving door.
On the plus side, as a dev with 30+ years of experience, I am commanding a very good contract salary these days. Revolving door companies stuck in process hell and product rot, and cannot deliver new value, so they’re scrambling to find experienced devs that cost a premium. My salary today makes up for peanuts at the start of my career.
1) People hearing "an LLM is as smart as a junior" and actually opting for the LLM subscription price instead of hiring a junior
2) The gap between senior and junior in terms of performance has become larger, since the senior devs had their hands get dirty for years typing stuff out manually AND also tackling challenges.
This generation of junior-mid developers will have a significant portion of the "typing stuff" chopped off, and we're still pretending that this will end up being fine.
The real question will be; Do we need to pay the juniors to write code to become seniors?
If coding is an art then all the juniors will end up in the same places as other struggling artists and only the breakout artists will land paying coding gigs.
I'm sitting here on a weekend coding a passion project for no pay so I have to wonder.
> Seniors come from juniors. If you want seniors, you must let the juniors write the code.
Companies know this as well, but this is a prisoner dilemma type situation for them. A company can skip out on juniors, and instead offer to pay seniors a bit better to poach them from other companies, saving money. If everyone starts doing this, everyone obviously loses - there just won't be enough new seniors to satisfy demand. Avoiding this requires that most companies play by the rules so to say, not something that's easily achieved.
And the higher the cost of training juniors relative to their economic output, the greater the incentive to break the rules becomes.
One alternative might just be more strict non-competes and the like, to make it harder for employees to switch companies in the first place. But this is legally challenging and obviously not a great thing for employees in general.
It’s already getting harder to find juniors willing to write the code and harder to discern whether someone is as willing as they say. And I feel like asking junior to make this decision and just have self control is a tricky double edged sword. Even if I want them to (and I do!) the competitive and ambitious juniors I suspect will still lean into AI code gen heavily as it makes them look better and seem more productive. Seniors probably need to do more than let them write the code, we probably need to figure out ways to encourage, require, or even enforce it at some level, if we want it to happen.
I agree with the sentiments here. But, I’m less hopeful about the presented solutions.
I think my argument against humans still needing to know how to manage complexity, is that the models will become increasingly able to manage that complexity themselves.
The only thing that backs up that argument is the rate of progress the models have made in the last 3 years (ChatGPT turned 3 just 3 months ago)
I think software people as a whole need to see that the capabilities won’t stop here, they’re going to keep growing. If you can describe it, an LLM will eventually be able to do it.
Ok but even pre ai I felt like each years interns wanted to take as many shortcuts as possible and not learn.
I think the allure of high TC (150k base or more for entry level) led to many non engineer brained people to enter tech.
Many people can do rote memorization, it’s even ingrained heavily in some cultures iykyk. However they can’t come up with much original or out of the box thinking.
I can't wait until the AI people realize that without developers' original ideas, AI has nothing new to steal from. We don't create, AI will spit out the same old concepts. What, you're gonna create the next generation of AI by training it on what the very same AI has already produced? C'mon now.
You don't get technical creativity reflexes by using AI. This is technical stagnation in the making. By cannibalizing its own sources, AI is ensuring that future generations are locked-in subscription models to do the most basic technical tasks. This is all obvious, yet we speed up every chance we get.
Maybe there aren’t that many new/necessary ideas that can be mined from the fundamental building blocks of software development (languages, syntax, runtimes, static analyses, type checking, etc). Maybe people will continue to innovate by instructing models to build novel things out of those building blocks? Perhaps things we would not have thought of building before due to the effort required without LLM assistance.
It might be a mistake to assume tomorrow’s training looks like today’s. Unsupervised learning is a thing and a very hot research topic, precisely because it avoids some of today’s big problems with acquiring the vast amounts of training data necessary.
Technically all the problems that almost any given business needs to be solved today has already been solved umpteen times over the years. There are no new problems that can't be solved by porting and/or combining old solutions.
This is fine. How else do you learn but by taking things apart and rebuilding them? This obsession with productivity is incompatible with onboarding new talent. Having 1000 versions of the same concept is exactly what progress is.
Why would there be a lack of original ideas? People who are born to code so to speak will do it. Information wants to be free as the saying goes. It only takes one time for an innovation for it to be to copied everywhere.
We don’t need the same volume of developers to have the same or faster speed of innovation.
And conversely if there is stagnation there is a capital opportunity to out compete it and so there will be a human desire to do the work.
Tl;Dr. People like doing stuff and achieving. They will continue to do stuff.
ps it’s too much to claim other people don’t experience creative ideas using AI. You don’t really know that’s true. It hasn’t been my experience as I have had the capability and capacity to complete ideas on my back burner for decades and move onto the next thing.
That’s the big scary point at the crux of all of this - you’ve had decades without the tooling to develop instincts. Nobody knows whether it’s possible to develop instincts with the tooling or what those instincts will look like. Creativity takes a degree of skill to execute on and the concern is that we’re potentially graduating people to painting the ceiling of the Sistine chapel before they’ve even learned to sketch.
At minimum, our current generation of leaders will have to get much better at managing resources and building people up. We have to up our games and build environments where the pursuit of deep understanding is permissible. Unfortunately with the current hiring issues, it’s totally understandable that young developers are scared to take time on tickets.
Innovation is irrelevant to pushing up this quarter's numbers. No one actually values unique and novel ideas. The only thing that matters is shipping something right now that can make an impact on this quarter's numbers.
Who cares if it's derivative slop or a straight up bootleg of something else so long as the number goes up
It isn’t about training anymore. It is about harnesses.
Just look at new math proofs that will come out, as one example. Exploration vs Exploitation is a thing in AI but you seem to think that human creativity can’t be surpassed by harnesses and prompts like “generate 100 types of possible…”
You’re wrong. What you call creativity is often a manual application of a simple self-prompt that people do.
One can have a loop where AI generates new ideas, rejects some and ranks the rest, then prioritizes. Then spawns workloads and sandboxes to try out and test the most highly ranked ideas. Finally it accretes knowledge into a relational database.
Germans also underestimated USA in WW2, saying their soldiers were superior, and USA just had technology — but USA out produced tanks and machinery and won the war through sheer automation, even if its soldiers were just regular joes and not elite troops.
Back then it was mechanized divisions. Now it is mechanized intelligence.
While Stalin said: Quantity has a quality all its own.
What I am excited about is the possibility of LLMs to draw conclusions from the last 150years of scientific papers.
There have been lots of instances of knowledge being rediscovered even when it was previously published but sitting on some shelf forgotten. LLMs ability to digest large volumes of data will I think help with this issue.
We will still need to reproduce and verify conclusions but will be interesting to see what might come from this.
While that’s kind of true in some sense, I think there’s an argument to be made for the contrary: that the mechanism for generating new ideas in humans is not quite as special as we would like to think.
In other words, creativity in humans is arguably just as derivative as in machines.
I think this can be falsified by just considering the history of humanity. It wasn't that long ago that human language literally did not even exist. And our collective knowledge wasn't all that much more than 'poke him with the pointy end'. Somehow we went from that to putting a man on the Moon, unlocking the secrets of the atom, and more. And if you consider how awful we are at retaining/sharing information and just general inefficiencies due to the fact that we're humans and not just logical information processing machines, we did all of this in little more than the blink of an eye. This is something that seems to certainly be rather special.
All that humanity has achieved happened due to the simple loop of identifying a desire/need and finding a way to satisfy it. Also known as reinforcement learning. The only thing that really differentiates humans from machines is... history. We've been learning and passing on our knowledge to successive generations over millennia. Nothing really special there; give the machines a few years to learn and see what happens.
i don't think all sides of this discussion agree on what a "new idea" is. i am a very creative person but i've never had a truly original thought and i don't know how having one would be possible
If AI could innovate it wouldn't be a public product. It would be a cash cow. Why give your customers the ability to come up with new and amazing ideas when you can just keep it for yourself and launch a thousand products? USA is a capitalist society. It doesn't share profitable ideas.
And if AI was really about productivity they'd be talking about doing more faster with the same workforce, not reducing the workforce.
My nightmare scenario (which might start to materilize) is that our last years in the industry will be becoming prompt monkies / agent "managers" working on codebases we barely understand in such velocity there's no way we can gain real understanding. Whenever something breaks (and it will , a lot) A.I will fix it - or so we'll hope. And the sad thing is - this might work; you'll get more stuff done with fewer people. Sure, we didn't sign up for this, it's not a fun job what I've described, but why should management care? They have their own problems and A.I is threatening their jobs as well.
At work we build enterprise software with stuff like Kotlin+Spring + multiple NextJS apps + Microservices + Rust CAD engine.
I haven’t have written code aside from tweaking stuff here and there in probably 3 or 4 months. Before that I wrote code by hand every day for many years.
I’ve found a lot of fun parts of my new workflow that I enjoy. I still miss being fully immersed in a problem deep in the files… and sometimes it feels like homework reading so many implementation summaries from Claude because the feature spans 4 repos and is too much code to read. But I do love shaping the code into different solutions exploring in a way that is unique to ai native workflows. And I love building agent skills and frameworks with/around them and expanding it out to more aspects of the company or life — there’s deep work to be had that still feels like hacking in the trenches. I get a lot of the same satisfaction in different ways, and there’s a lot of exciting novelty to explore that was previously out of reach due to time and energy constraints.
Also I don’t like our backend stack and I hate React / NextJS to the degree of derangement syndrome — I am so happy that I don’t have to write it and I can just focus on UX, making customers happy / lives easier / shaping the software into better and better versions of itself at such a faster pace.
People who learned good software engineering intimately before the inflection point are extremely lucky right now. Existential dread and the stages of grief have been a part of the journey for me too sadly, but there’s a lot to celebrate and explore with the right attitude.
> My nightmare scenario (which might start to materilize) is that our last years in the industry will be becoming prompt monkies / agent "managers" working on codebases we barely understand in such velocity there's no way we can gain real understanding.
It will always be preferable to work on an understandable codebase, because that maximizes the AI's affordances too. And then the AI can explain things to you. A skilled human will always have a lot of solid knowledge relating to their hyper-specific niche that isn't part of your average general purpose AI, so humans will obviously have a key role to play still.
I'm already seeing this in the company I recently joined: 80-90% of code is generated/prompted. Big PRs, very little review or oversight. Absolutely nobody considering long-term architecture (and IMO nobody capable of such). In general, there's very little critical thinking involved at any stage, just throw error messages back into the LLM, rinse and repeat.
I'm hoping there's a world where people with skills are useful in getting these projects back on track, but perhaps as a society we're learning to accept this reduction in quality.
And how do u sum up the tradeoffs so far, or is it too early to tell ? Do u see lots of unacceptable shit making into production that wouldn't have before A.I for example ?
Actually the truth is that a lot of senior devs are not very good either, and have negative value. But they have an inflated value of themselves that does not reflect reality.
Pretty much all software projects seem to peak, and then decline in quality. There are only a handful of senior devs in the world who are actually good programmers.
I agree. But it’s not about that they have inflated value but it comes down to how “modern” software producing organizations work. Product managers and C-level people do not know what they are doing either. Most people are part of the “software engineering” theater, recruiters are recruiting, manager are managing, software developers are developing software, all of them just to get paid or gain status in the org. Most of the values come from that handful people who can really deliver.
I can't seem to get the article to load, but I think I get the gist from the title.
I hired a junior "dev" who literally hadn't even completed an HTML course. Before AI I could not have hired them because they literally did not know how to dev. After AI, anyone with a little grit can push themselves into the field pretty easily.
As with everything in life: you can choose to hard route or you can choose the easy route and your results will follow accordingly.
I recently read a similar discussion in the context of AI in science and PhD students. And the point the author was making that the goal of having PhD students is NOT to produce academic research, but to train people. I think the same idea applies here.
Somebody still needs to train people, and the companies will probably need to ensure that they have resources for that, as there will not be enough senior people for all the tasks.
I think this concern is overblown. AI is an incredible teaching tool. It's probably better for teaching/explaining than for writing code. This will make the next generation of junior devs far more effective than previous generations. Not because they're skipping the fundamentals...because they have a better grasp of the fundamentals due to back-and-forth with infinitely patient AI teachers.
Unless your company is investing in actually teaching your junior devs, this isn't really all that different than the days when jr devs just copied and pasted something out of stack overflow, or blindly copied entire class files around just to change 1 line in what could otherwise have been a shared method. And if your company is actually investing time and resources into teaching your junior devs, then whether they're copying and pasting from stack overflow, from another file in the project or from AI doesn't really matter.
In my experience it is the very rare junior dev that can learn what's good or bad about a given design on their own. Either they needed to be paired with a sr dev to look at things and explain why they might not want to something a given way, or they needed to wind up having to fix the mess they made when their code breaks something. AI doesn't change that.
I always say "own the output". No need to do it by hand but you better damn well research _why_ the AI chose a solution, and what alternatives there are and why not something else, how it works and so on. Ask the AI, ask a seperate agent/model, Google for it, I don't care, but "I don't know the LLM told me" is not acceptable.
As a junior, my top issue is finding valuable learning material that isn't full of poor or outright wrong information.
In the best and most generous interpretation of your statement, LLM's simply removed my need to search for the information. That doesn't mean it's not of poor quality or outright wrong.
I suspect that the quality is ironically correlated with the expertise of the user, which puts you in a conundrum (I can report that with a couple decades of experience, LLMs are giving me high quality, correct results, but I can already see that it somehow doesn't work as well for some of my less experienced colleagues. A lot of what I've been doing over the last couple months is trying to find how to make it "just work" for them.).
As a general principle, take advantage of the fact that it can easily generate stuff. If you don't know whether something is true, have it prove it. Make a PoC/test/benchmark to demonstrate what it's saying. Create feedback loops (or rather, ask it to create feedback loops). They're very good at reasoning given access to the ground truth, so give them more ability to ground themselves.
They also have fantastic knowledge of public things, but no knowledge of your company, so your instructions should mostly be documentation of what's unique to your company. If it can write an instruction on its own (e.g. how to use git or kubernetes), it is a useless instruction; it already knows that. What it doesn't know is e.g. where your git server is. It also doesn't know what matters to your company: are you a startup trying to find product market fit? Are you an established company that is not allowed to break customer setups? etc.
This is the dumbest thought that proliferates this website.
Super great that it’s used to pump out tons of code because upper management wants features released even faster than before. I’m sure the junior devs who don’t know a for loop from their ass will be able to learn and understand wtf Claude is shitting out
> AI is an incredible teaching tool. It's probably better for teaching/explaining than for writing code.
It is but how do you teach to people who think their new profession is being a "senior prompt engineer" (with 4 months of experience) and who believe that in 12 months there won't be any programmer left?
And how many will not?
For mist people it’s just a job to get money, they will put exactly as much effort in it as is necessary to produce an acceptable result
Only for people who wants be taught, this argument keeps coming up again and again but people in general doesn’t want to learn how to fish, they want the fish on a plate ready to eat, so that they can continue scrolling.
I see this a lot in juniors, they are solution seekers, not problem solvers, and AI makes this difference a lot worse.
I do agree it’s a great tool, so much better than trying to hope and pray someone on the internet can help you with “I don’t understand this line of code.”
It's interesting to watch industry after industry hollow itself out from the inside then inevitably die long after all the financial people, investment bankers and management consultants have all cashed their checks.
Steve Jobs famously accurately called this out years ago [1].
Xerox, Boeing, PC manufacturers (who basically created the Taiwanese makers through a series of short-term outsourcing steps), etc. But there are two examples I want to talk about specifically.
First, one lasting impact of the 2008 GFC was that entry-level jobs disappeared. This devastated a generation of millenial college graduates who suddenly had a mountain of student loan debt (thanks to education costs outpacing inflation by a lot) but suddenly no jobs. It became a bit of a joke to poke fun at such people who had a ton of debt and worked as baristas but this was a shallow "analysis". It was really a systemic collapse. Those entry-level workers are your future senior workers and leaders. Those jobs have never come back.
The rise of DVR/TiVo and ultimately streaming brought on a golden age of TV in the 2000s. It was kind of the last hurrah for network shows that produced 22 episodes a year before streamers instead produced 8 episodes every 4 years.
But what made this system work was an ecosystem. Living in LA, Atlanta and a few other places was relatively cheap so aspiring actors and writers and entertainmnet professionals could get by with secon djobs and relatively low income. These became the future headline actors and senior professionals. Background work and odd jobs were sufficient. Background work also taught people how to be on a set.
Studios still had large writing staffs. Some writers would be on set. Those writers were your future producers and showrunners.
Part of what supported all of this was syndication. That is, networks produced shows and basic cable channels would pay to rerun them. Syndicating some shows was incredibly profitable in some cases (eg Seinfeld).
So the streamers came along and stripped things down. They got rid of junior positions. They adopted so-called "mini writing rooms". Those writers didn't tend to ever be on set. The runs were shorter and an 8 episode series couldn't support a writer in the same way a 22 episode series could. The streamers then were largely showing just their own content so residuals and syndication fees just went away.
All of this is short-term thinking. Hollywood has been both a massive industry and a source of American soft power internationally by spreading culture, basically.
I think the software engineering space is going through a similar transformation to what happened to the entertainment industry. A handful of people will do very well. AIs will destroy entry-level jobs and basically destroy that company and industry's future.
I predict in 10-20 years we'll see China totally dominating this space and a bunch of Linkedin "thought leaders" and politicians will be standing around scratchin their heads asking "what happened?"
Yes and no. Often times managers are now asking ask Claude code to write it but I want it delivered tomorrow. This leads to us forcing to use LLM generated code without enough time to review or understand it.
Junior devs: you have an oracle you can pester incessantly. Make the most of it so you can learn to detect its mistakes, know when to push back, and what to ask of it. That's when you are in the clear. Juniors who merely parrot the LLM get fired.
You don't have to take 5 years off for it. Just continue same old business (assuming you don't have outside pressure to use this slop-machine) and keep your skills and judgment sharp until the tools and workflow stabilizes, and most of all, the money to fuel this hype runs out.
"AI is making junior devs useless" is a dangerous and incorrect conclusion. If this idea is repeated too often, people may start to believe it and even quit studying computer science altogether.
First of all, developers who only learn to code in a short bootcamp are often not well prepared — but that was already true before AI. In the past, many junior developers were students who were learning programming while studying, not just people who took a quick Python course on Udemy.
Instead of declaring junior developers useless, we should raise the standard: learn how to code properly, how to maintain code, understand networks, and build strong foundations in math and computer science. A well-trained junior developer is still extremely valuable and will always be needed.
I assume junior devs can at least search. AI often doesn't even do that. That's why there are things like context7, which in a narrow context helps but not perfect.
There are lots of ambiguous situations where a search and human "inference" can solve that AI still can't.
I can tell the AI to do something, it uses the worst approach, I tell it a better way exists, it says it validated it does not, I link to a GitHub issue saying it can be done via workarounds and it still fails. It's worse for longer tasks where it always shortcuts to if it fails pick a "safe" approach (including not doing it).
Companies will continue to demand it (I know people working at companies that are literally looking at AI usage as an individual performance metric, puke emoji), and probably 95% of humans using pretty understandable human logic aren’t going to work harder than they need to on purpose.
I wish I had a solution. I think the jury is still out on whether programming will be a dead profession in a short number of years, replaced by technical protect operators.
> If I’m reviewing your code and I ask you why you went with a certain approach, and you tell me “the AI suggested it”, I’ve immediately lost confidence in you.
I’ve experienced similar things and so understand the feeling, but this is poor leadership. If someone on your team makes it all the way to a code review and still thinks ‘the AI suggested it’, you failed to train them, failed to set expectations and they have justifiably lost more confidence in you than vice versa.
If we analyze the rest of the article through the lens of weak leadership, it sounds less like an AI problem and more like a corporate leadership problem.
The cost of generating code is now laughable, so that's not the economic value brought to the table by a junior engineer, or really, any engineer. The value is now generated by knowing what code is good code. You're going to have to have talks, book clubs, hackathons, and the like to get your juniors to know what good code is. Do they know what design patterns are? How about good architecture? If they can't name a few design patterns, you're not investing enough.
This is ridiculous. New developers will learn a completely different skill path from what we learned, and they will get where we are faster than we did.
When I started my career I heard people say almost verbatim "Stack overflow is making junior devs useless", with the idea all we did was copypaste scripts over. The same people failed, and the same people who can use the tools will succeed now.
You definitely did see a difference between people who just copy pasted from stack overflow, and from people with good fundamentals. The uncomfortable truth though, is that the industry didn't need good coders, it needed a bucket load of basic web apps and it needed bums in seats.
I think the irony of AI is going to be that it will make the remaining software jobs properly hard again, and implementers (ex coders) will be able to succeed with even less code knowledge than before.
I worked under people who started as juniors that way but were politically savvy. Or just ruthless. And pushed their way to the top by stealing projects, lying through their teeth, and other such tactics.
They were slowing down progress because their methods involved sabotaging the progress of others because it might make their own contributions shine a little less.
They were the cause of using libraries like leftPad all through business critical code, and cutting anyone down who dared to simply question why.
These things cause ripples. The smartest and most capable staff leaves, what results is a churn of the same kind.
But hey, they get a trip to Mexico every year and burn through millions every two years. Profit any day now.
I did my first completely vibe coded not looking at a line of code implementation last year and my second this year.
I could care less about why either Claude, Codex or before that a developer was using a for loop or a while loop. I did and do care about architecture.
I’m no more going to review every line of code with AI than I am when I was delegating to more junior developers. I’m going to ask Claude Code about how it implemented something where I know there is an efficient way vs naive way, find and test corner cases via manual and automated tests and do the same for functional and non functional requirements.
The "Junior Trap" is real: if you offload your thinking to Claude or GPT-4, you’re hitting "Done" for the day, but you’re accruing massive Learning Debt. You aren't building the failure-pattern recognition that actually makes an engineer valuable.
In a world where "Code is no longer a skill," the only way to survive is to stop being a "Prompt Operator" and start being a "System Auditor." If you can’t explain the trade-offs of the architectural pattern the AI just gave you, you aren't an engineer, you're just the person holding the screwdriver while the machine builds the house.
Junior devs have always been useless. You used to give them tasks that take them a week or two even though a senior engineer could do it in a couple hours, not because you wanted them to contribute, but because you wanted them to learn to contribute.
The same ethos makes sense with AI, it's just that every company is trying to avoid paying that training tax. Why turn a junior into a senior yourself if you can get the competition to pay for it instead.
Strongly disagree with this. Bad junior devs might be useless, but I’ve seen good ones absolutely tear through features. Junior devs fresh out of school typically have tons of energy, haven’t been burned out, and are serious about wanting to get work done.
Yep. This is why many companies have a terminal level with “up or out “ rules. Before that level you are not fully independent and require too much supervision. No one wants a Jr engineer with 10 years of experience.
I see a lot of Sr engineers get very frustrated by how much time they have to spend helping Jr engineers. But, that’s the job, or at least a big part of it.
Or at least it was.
I burnt out helping a junior on my team for the past few months. It was just terribly obvious she was feeding my responses directly into a chatbot to fix instead of actually understanding the issue. I can’t really even blame her, there isn’t much incentive to actually learn
I’ve gotten plenty of use out of junior devs. The critical bit is what makes anyone a useful worker. I’ve found anyone that’s both dedicated and meticulous is worth the investment.
Sure there’s a wide range of skills and you can’t just hand any task to anyone and expect it to work out but some fresh collage graduates are more capable than the average person with 5 years of professional experience. At the other end you need to focus on whatever they actually are capable of doing. 40+ hours a week can slowly expand even an extremely narrow skillet as long as they’re a hard worker.
Agreed. We are still in a capital crunch so overhiring is out of fashion. People don’t remember the early 90s or the dot.bust when the same things were said.
Kraft 1977 Programmers and Managers talked about this if I recall. Still the best alternate take on our industry I have ever read.
What’s the importance of then learning to contribute if they will probably jump ship anyway when they get good enough? Your HR department is not going to give them a market rate raise to keep them - see salary compression and inversion. A junior developer just isn’t worth the investment.
I have never once told my manager “it would be really nice to have a few junior developers. It would really help us get this project done on time”. They do “negative work”.
Yes not having juniors become seniors is an industry problem. But my goal is to reach my company’s quarterly and anual goals - not what’s going to happen 10 years from now.
> I have never once told my manager “it would be really nice to have a few junior developers. It would really help us get this project done on time”. They do “negative work”.
I have. A good junior can do in a week what a senior with domain knowledge can do in a half day, with only an hour of mentoring along the way. This isn’t a great exchange rate per dollar (juniors are cheaper than seniors, but not that much cheaper) — but seniors with domain knowledge are a finite resource, you can’t get more of them for love or money, while juniors are fresh-minted every semester. The cheapest way to shipping may not go through juniors, but the fastest way usually does; and that’s completely ignoring the HUGE side benefit of building seniors “the hard way,” which is still easier than hiring.
>What’s the importance of then learning to contribute if they will probably jump ship anyway when they get good enough? Your HR department is not going to give them a market rate raise to keep them - see salary compression and inversion.
Obviously that hasn't historically been true, else there wouldn't be any senior developers as companies would have wised up to that and nobody would hire them as juniors.
- Not everybody is a job hopper (even in Silicon Valley one sees that most junior FAANG devs stick around for a good while).
- The HR department is absolutely going to give junior developers that pass the cut after a year or so a market rate raise.
- In limited hiring periods, they'd be grateful to have the chance to stick around, while in bullish "boom" periods companies can afford to spend to keep people, expand and give them bigger roles, and so on. It's in the in-between that it becomes more problematic, but now we're in a "limited hiring" era.
>Yes not having juniors become seniors is an industry problem. But my goal is to reach my company’s quarterly and anual goals - not what’s going to happen 10 years from now.
That's how companies fail.
It's also not a good strategy at the personal level. If you command more devs, you get more leverage.
Treat your employees well and they won't jump ship.
This is the difference between being an engineer and being a clock puncher. You don't care about the business, you don't care about the product, you don't care about society as a whole. So long as you get your paycheck and your annual pay bump, fuck absolutely everyone and everything else, right?
Don't worry, just leave all your problems for someone else to fix. I'm sure that won't have any lasting consequences at all.
Welcome to capitalism. Hire seniors and pay them 400k
Until there are no more "seniors"...
> Junior devs have always been useless. You used to give them tasks [...] not because you wanted them to contribute, but because you wanted them to learn to contribute.
Junior devs are by your own explanation not useless. They are the most important human investment in your project.
Why? Because I learn every time I do.
> ...not because you wanted them to contribute, but because you wanted them to learn to contribute.
Rather because you want them to go away, because management conveniently forgot to reduce your load to account for time spent on mentoring.
I mean, if we’re doing this, let’s be honest and go as far as mid-level engineers whose work needs constant correction, as well as the many, many senior engineers out there who are senior only because they lucked out in getting the title during the artificial dev scarcity of the ZIRP eras.
> Junior devs have always been useless. You used to give them tasks that take them a week or two even though a senior engineer could do it in a couple hours
We havent dont it and I never seen something like that.
As I tell my students: juniors, you must write the code
https://htmx.org/essays/yes-and/
Everyone else: we must let the juniors write the code.
Seniors come from juniors. If you want seniors, you must let the juniors write the code.
> Seniors come from juniors. If you want seniors, you must let the juniors write the code
The average tenure of a person in engineering role is so short that very few employers are thinking about developing individuals anymore.
The actual way this gets approached is "If you want seniors, you must hire seniors".
I'm not sure how this plays out now. But it's easy to imagine a scenario like the COBOL writers of the last generation.
The challenge is to get cost sensitive businesses to support this. Juniors are a cost and when trained move on, thats the fundamental problem. Retention only works with smart companues, for most other companies its a revolving door.
On the plus side, as a dev with 30+ years of experience, I am commanding a very good contract salary these days. Revolving door companies stuck in process hell and product rot, and cannot deliver new value, so they’re scrambling to find experienced devs that cost a premium. My salary today makes up for peanuts at the start of my career.
The issue stems from 2 things:
1) People hearing "an LLM is as smart as a junior" and actually opting for the LLM subscription price instead of hiring a junior
2) The gap between senior and junior in terms of performance has become larger, since the senior devs had their hands get dirty for years typing stuff out manually AND also tackling challenges.
This generation of junior-mid developers will have a significant portion of the "typing stuff" chopped off, and we're still pretending that this will end up being fine.
The real question will be; Do we need to pay the juniors to write code to become seniors?
If coding is an art then all the juniors will end up in the same places as other struggling artists and only the breakout artists will land paying coding gigs.
I'm sitting here on a weekend coding a passion project for no pay so I have to wonder.
So non technical business people will hire vibe coded seniors?
Not every career path starts at a software first company. Not every software first company works on the most intense codebase.
And therefore in my experience not every senior engineer would hack it as a senior engineer at a more intense company myself included.
This isn’t a software unique experience. It’s life.
> Seniors come from juniors. If you want seniors, you must let the juniors write the code.
Companies know this as well, but this is a prisoner dilemma type situation for them. A company can skip out on juniors, and instead offer to pay seniors a bit better to poach them from other companies, saving money. If everyone starts doing this, everyone obviously loses - there just won't be enough new seniors to satisfy demand. Avoiding this requires that most companies play by the rules so to say, not something that's easily achieved.
And the higher the cost of training juniors relative to their economic output, the greater the incentive to break the rules becomes.
One alternative might just be more strict non-competes and the like, to make it harder for employees to switch companies in the first place. But this is legally challenging and obviously not a great thing for employees in general.
The way other professions do this is by burying trainees with debt and then writing off debt if they stay.
It’s already getting harder to find juniors willing to write the code and harder to discern whether someone is as willing as they say. And I feel like asking junior to make this decision and just have self control is a tricky double edged sword. Even if I want them to (and I do!) the competitive and ambitious juniors I suspect will still lean into AI code gen heavily as it makes them look better and seem more productive. Seniors probably need to do more than let them write the code, we probably need to figure out ways to encourage, require, or even enforce it at some level, if we want it to happen.
I agree with the sentiments here. But, I’m less hopeful about the presented solutions.
I think my argument against humans still needing to know how to manage complexity, is that the models will become increasingly able to manage that complexity themselves.
The only thing that backs up that argument is the rate of progress the models have made in the last 3 years (ChatGPT turned 3 just 3 months ago)
I think software people as a whole need to see that the capabilities won’t stop here, they’re going to keep growing. If you can describe it, an LLM will eventually be able to do it.
> If you want seniors, you must let the juniors write the code.
I do not want more juniors, because given time they will be my competition.
before you had a lesson that every engineer has to start with writing C, yet most of modern devs never did.
Seniors should be prepared that Seniority will mean different thing and path of getting there will be different too.
Just like there was a shift from lower lvl languages to high level
Ok but even pre ai I felt like each years interns wanted to take as many shortcuts as possible and not learn.
I think the allure of high TC (150k base or more for entry level) led to many non engineer brained people to enter tech.
Many people can do rote memorization, it’s even ingrained heavily in some cultures iykyk. However they can’t come up with much original or out of the box thinking.
I can't wait until the AI people realize that without developers' original ideas, AI has nothing new to steal from. We don't create, AI will spit out the same old concepts. What, you're gonna create the next generation of AI by training it on what the very same AI has already produced? C'mon now.
You don't get technical creativity reflexes by using AI. This is technical stagnation in the making. By cannibalizing its own sources, AI is ensuring that future generations are locked-in subscription models to do the most basic technical tasks. This is all obvious, yet we speed up every chance we get.
Maybe there aren’t that many new/necessary ideas that can be mined from the fundamental building blocks of software development (languages, syntax, runtimes, static analyses, type checking, etc). Maybe people will continue to innovate by instructing models to build novel things out of those building blocks? Perhaps things we would not have thought of building before due to the effort required without LLM assistance.
It might be a mistake to assume tomorrow’s training looks like today’s. Unsupervised learning is a thing and a very hot research topic, precisely because it avoids some of today’s big problems with acquiring the vast amounts of training data necessary.
Technically all the problems that almost any given business needs to be solved today has already been solved umpteen times over the years. There are no new problems that can't be solved by porting and/or combining old solutions.
I don't expect them to realise that until some time after it actually happens. When it remains a future hypothetical, it won't be accounted for.
https://en.wikipedia.org/wiki/Profession_(novella)
fwiw 90% of software is reinventing the wheel. 80% of devs have an itch to "rewrite from scratch".
AI will deduplicate all of this
My experience is that 100% of AI devs are reinventing the wheel, most of the time for no better reason than "I can do it" or "not invented here"
This is fine. How else do you learn but by taking things apart and rebuilding them? This obsession with productivity is incompatible with onboarding new talent. Having 1000 versions of the same concept is exactly what progress is.
> 1000 versions of the same concept
That sounds beyond wasteful.
Why would there be a lack of original ideas? People who are born to code so to speak will do it. Information wants to be free as the saying goes. It only takes one time for an innovation for it to be to copied everywhere.
We don’t need the same volume of developers to have the same or faster speed of innovation.
And conversely if there is stagnation there is a capital opportunity to out compete it and so there will be a human desire to do the work.
Tl;Dr. People like doing stuff and achieving. They will continue to do stuff.
ps it’s too much to claim other people don’t experience creative ideas using AI. You don’t really know that’s true. It hasn’t been my experience as I have had the capability and capacity to complete ideas on my back burner for decades and move onto the next thing.
That’s the big scary point at the crux of all of this - you’ve had decades without the tooling to develop instincts. Nobody knows whether it’s possible to develop instincts with the tooling or what those instincts will look like. Creativity takes a degree of skill to execute on and the concern is that we’re potentially graduating people to painting the ceiling of the Sistine chapel before they’ve even learned to sketch.
At minimum, our current generation of leaders will have to get much better at managing resources and building people up. We have to up our games and build environments where the pursuit of deep understanding is permissible. Unfortunately with the current hiring issues, it’s totally understandable that young developers are scared to take time on tickets.
Innovation is irrelevant to pushing up this quarter's numbers. No one actually values unique and novel ideas. The only thing that matters is shipping something right now that can make an impact on this quarter's numbers.
Who cares if it's derivative slop or a straight up bootleg of something else so long as the number goes up
It isn’t about training anymore. It is about harnesses.
Just look at new math proofs that will come out, as one example. Exploration vs Exploitation is a thing in AI but you seem to think that human creativity can’t be surpassed by harnesses and prompts like “generate 100 types of possible…”
You’re wrong. What you call creativity is often a manual application of a simple self-prompt that people do.
One can have a loop where AI generates new ideas, rejects some and ranks the rest, then prioritizes. Then spawns workloads and sandboxes to try out and test the most highly ranked ideas. Finally it accretes knowledge into a relational database.
Germans also underestimated USA in WW2, saying their soldiers were superior, and USA just had technology — but USA out produced tanks and machinery and won the war through sheer automation, even if its soldiers were just regular joes and not elite troops.
Back then it was mechanized divisions. Now it is mechanized intelligence.
While Stalin said: Quantity has a quality all its own.
There is no "new ideas" with AI. Claiming the opposite is a fundamental misunderstanding of the technology.
What I am excited about is the possibility of LLMs to draw conclusions from the last 150years of scientific papers.
There have been lots of instances of knowledge being rediscovered even when it was previously published but sitting on some shelf forgotten. LLMs ability to digest large volumes of data will I think help with this issue.
We will still need to reproduce and verify conclusions but will be interesting to see what might come from this.
While that’s kind of true in some sense, I think there’s an argument to be made for the contrary: that the mechanism for generating new ideas in humans is not quite as special as we would like to think.
In other words, creativity in humans is arguably just as derivative as in machines.
I think this can be falsified by just considering the history of humanity. It wasn't that long ago that human language literally did not even exist. And our collective knowledge wasn't all that much more than 'poke him with the pointy end'. Somehow we went from that to putting a man on the Moon, unlocking the secrets of the atom, and more. And if you consider how awful we are at retaining/sharing information and just general inefficiencies due to the fact that we're humans and not just logical information processing machines, we did all of this in little more than the blink of an eye. This is something that seems to certainly be rather special.
All that humanity has achieved happened due to the simple loop of identifying a desire/need and finding a way to satisfy it. Also known as reinforcement learning. The only thing that really differentiates humans from machines is... history. We've been learning and passing on our knowledge to successive generations over millennia. Nothing really special there; give the machines a few years to learn and see what happens.
i don't think all sides of this discussion agree on what a "new idea" is. i am a very creative person but i've never had a truly original thought and i don't know how having one would be possible
that's only partially true.
AI can innovate in synthetic-realm of novel ideas, while real-world novelty will remain untouched.
There are different types of novelties
What is a "real-world novelty" and what prevents AI from touching it?
If AI could innovate it wouldn't be a public product. It would be a cash cow. Why give your customers the ability to come up with new and amazing ideas when you can just keep it for yourself and launch a thousand products? USA is a capitalist society. It doesn't share profitable ideas.
And if AI was really about productivity they'd be talking about doing more faster with the same workforce, not reducing the workforce.
if you like, the business model is called Innovation-as-a-Service :)
That's perfectly aligned with capitalistic motivations
My nightmare scenario (which might start to materilize) is that our last years in the industry will be becoming prompt monkies / agent "managers" working on codebases we barely understand in such velocity there's no way we can gain real understanding. Whenever something breaks (and it will , a lot) A.I will fix it - or so we'll hope. And the sad thing is - this might work; you'll get more stuff done with fewer people. Sure, we didn't sign up for this, it's not a fun job what I've described, but why should management care? They have their own problems and A.I is threatening their jobs as well.
At work we build enterprise software with stuff like Kotlin+Spring + multiple NextJS apps + Microservices + Rust CAD engine.
I haven’t have written code aside from tweaking stuff here and there in probably 3 or 4 months. Before that I wrote code by hand every day for many years.
I’ve found a lot of fun parts of my new workflow that I enjoy. I still miss being fully immersed in a problem deep in the files… and sometimes it feels like homework reading so many implementation summaries from Claude because the feature spans 4 repos and is too much code to read. But I do love shaping the code into different solutions exploring in a way that is unique to ai native workflows. And I love building agent skills and frameworks with/around them and expanding it out to more aspects of the company or life — there’s deep work to be had that still feels like hacking in the trenches. I get a lot of the same satisfaction in different ways, and there’s a lot of exciting novelty to explore that was previously out of reach due to time and energy constraints.
Also I don’t like our backend stack and I hate React / NextJS to the degree of derangement syndrome — I am so happy that I don’t have to write it and I can just focus on UX, making customers happy / lives easier / shaping the software into better and better versions of itself at such a faster pace.
People who learned good software engineering intimately before the inflection point are extremely lucky right now. Existential dread and the stages of grief have been a part of the journey for me too sadly, but there’s a lot to celebrate and explore with the right attitude.
> My nightmare scenario (which might start to materilize) is that our last years in the industry will be becoming prompt monkies / agent "managers" working on codebases we barely understand in such velocity there's no way we can gain real understanding.
It will always be preferable to work on an understandable codebase, because that maximizes the AI's affordances too. And then the AI can explain things to you. A skilled human will always have a lot of solid knowledge relating to their hyper-specific niche that isn't part of your average general purpose AI, so humans will obviously have a key role to play still.
I'm already seeing this in the company I recently joined: 80-90% of code is generated/prompted. Big PRs, very little review or oversight. Absolutely nobody considering long-term architecture (and IMO nobody capable of such). In general, there's very little critical thinking involved at any stage, just throw error messages back into the LLM, rinse and repeat. I'm hoping there's a world where people with skills are useful in getting these projects back on track, but perhaps as a society we're learning to accept this reduction in quality.
And how do u sum up the tradeoffs so far, or is it too early to tell ? Do u see lots of unacceptable shit making into production that wouldn't have before A.I for example ?
Actually the truth is that a lot of senior devs are not very good either, and have negative value. But they have an inflated value of themselves that does not reflect reality.
Pretty much all software projects seem to peak, and then decline in quality. There are only a handful of senior devs in the world who are actually good programmers.
I agree. But it’s not about that they have inflated value but it comes down to how “modern” software producing organizations work. Product managers and C-level people do not know what they are doing either. Most people are part of the “software engineering” theater, recruiters are recruiting, manager are managing, software developers are developing software, all of them just to get paid or gain status in the org. Most of the values come from that handful people who can really deliver.
Yeah read Software and Mind by Andrei Sorin
I can't seem to get the article to load, but I think I get the gist from the title.
I hired a junior "dev" who literally hadn't even completed an HTML course. Before AI I could not have hired them because they literally did not know how to dev. After AI, anyone with a little grit can push themselves into the field pretty easily.
As with everything in life: you can choose to hard route or you can choose the easy route and your results will follow accordingly.
> As with everything in life: you can choose to hard route or you can choose the easy route and your results will follow accordingly.
Hard agree, but probably not in the way you're implying.
It's the difficult things that make life fun and interesting. A life spent going from one easy thing to another is a life barely lived at all.
Why are you paying them instead of running the AI yourself?
>> who literally hadn't even completed an HTML course.
so what is their value? proxy your requests to ai?
I recently read a similar discussion in the context of AI in science and PhD students. And the point the author was making that the goal of having PhD students is NOT to produce academic research, but to train people. I think the same idea applies here. Somebody still needs to train people, and the companies will probably need to ensure that they have resources for that, as there will not be enough senior people for all the tasks.
Back to fuedalism we go!
This post, ironically, seems very likely to have been written by an LLM :/
"it's not x, but y", with bonus em-dash:
> your value as a developer is not in your ability to ship code. It’s in your ability to look at code
"But here’s the thing."
"And honestly?"
Copying homework and cheating at exams don't make student learn.
It takes time to become a junior too. Emerging tech landscape could affect skills and knowledge that is expected from entry level job applicants.
I think this concern is overblown. AI is an incredible teaching tool. It's probably better for teaching/explaining than for writing code. This will make the next generation of junior devs far more effective than previous generations. Not because they're skipping the fundamentals...because they have a better grasp of the fundamentals due to back-and-forth with infinitely patient AI teachers.
Not in my experience. They just regurgitate code, and juniors don’t know if/why it’s good or bad and consequently can’t field questions on their PR.
“It’s what the LLM said.” - Great. Now go learn it and do it again yourself.
Unless your company is investing in actually teaching your junior devs, this isn't really all that different than the days when jr devs just copied and pasted something out of stack overflow, or blindly copied entire class files around just to change 1 line in what could otherwise have been a shared method. And if your company is actually investing time and resources into teaching your junior devs, then whether they're copying and pasting from stack overflow, from another file in the project or from AI doesn't really matter.
In my experience it is the very rare junior dev that can learn what's good or bad about a given design on their own. Either they needed to be paired with a sr dev to look at things and explain why they might not want to something a given way, or they needed to wind up having to fix the mess they made when their code breaks something. AI doesn't change that.
I always say "own the output". No need to do it by hand but you better damn well research _why_ the AI chose a solution, and what alternatives there are and why not something else, how it works and so on. Ask the AI, ask a seperate agent/model, Google for it, I don't care, but "I don't know the LLM told me" is not acceptable.
>AI is an incredible teaching tool.
As a junior, my top issue is finding valuable learning material that isn't full of poor or outright wrong information.
In the best and most generous interpretation of your statement, LLM's simply removed my need to search for the information. That doesn't mean it's not of poor quality or outright wrong.
I suspect that the quality is ironically correlated with the expertise of the user, which puts you in a conundrum (I can report that with a couple decades of experience, LLMs are giving me high quality, correct results, but I can already see that it somehow doesn't work as well for some of my less experienced colleagues. A lot of what I've been doing over the last couple months is trying to find how to make it "just work" for them.).
As a general principle, take advantage of the fact that it can easily generate stuff. If you don't know whether something is true, have it prove it. Make a PoC/test/benchmark to demonstrate what it's saying. Create feedback loops (or rather, ask it to create feedback loops). They're very good at reasoning given access to the ground truth, so give them more ability to ground themselves.
They also have fantastic knowledge of public things, but no knowledge of your company, so your instructions should mostly be documentation of what's unique to your company. If it can write an instruction on its own (e.g. how to use git or kubernetes), it is a useless instruction; it already knows that. What it doesn't know is e.g. where your git server is. It also doesn't know what matters to your company: are you a startup trying to find product market fit? Are you an established company that is not allowed to break customer setups? etc.
Research [0] from Anthropic about juniors learning to code with AI/without:
>the AI group averaged 50% on the quiz, compared to 67% in the hand-coding group
And why would they do better? There's less incentive to learn because it's so easy to offload thinking to AI.
[0] https://www.anthropic.com/research/AI-assistance-coding-skil...
This is the dumbest thought that proliferates this website.
Super great that it’s used to pump out tons of code because upper management wants features released even faster than before. I’m sure the junior devs who don’t know a for loop from their ass will be able to learn and understand wtf Claude is shitting out
> AI is an incredible teaching tool. It's probably better for teaching/explaining than for writing code.
It is but how do you teach to people who think their new profession is being a "senior prompt engineer" (with 4 months of experience) and who believe that in 12 months there won't be any programmer left?
A teacher who just gives you the solution isn’t a good teacher.
You can use AI as a teacher but how many will do that?
Highly motivated people will use whatever tools they have to get better at something, whether they have a textbook, the internet or a LLM to use.
The skill of the very top programmers will continue to increase with the advent of new tools.
And how many will not? For mist people it’s just a job to get money, they will put exactly as much effort in it as is necessary to produce an acceptable result
Only for people who wants be taught, this argument keeps coming up again and again but people in general doesn’t want to learn how to fish, they want the fish on a plate ready to eat, so that they can continue scrolling. I see this a lot in juniors, they are solution seekers, not problem solvers, and AI makes this difference a lot worse.
I do agree it’s a great tool, so much better than trying to hope and pray someone on the internet can help you with “I don’t understand this line of code.”
However, it’s got a lot of downsides too.
It's interesting to watch industry after industry hollow itself out from the inside then inevitably die long after all the financial people, investment bankers and management consultants have all cashed their checks.
Steve Jobs famously accurately called this out years ago [1].
Xerox, Boeing, PC manufacturers (who basically created the Taiwanese makers through a series of short-term outsourcing steps), etc. But there are two examples I want to talk about specifically.
First, one lasting impact of the 2008 GFC was that entry-level jobs disappeared. This devastated a generation of millenial college graduates who suddenly had a mountain of student loan debt (thanks to education costs outpacing inflation by a lot) but suddenly no jobs. It became a bit of a joke to poke fun at such people who had a ton of debt and worked as baristas but this was a shallow "analysis". It was really a systemic collapse. Those entry-level workers are your future senior workers and leaders. Those jobs have never come back.
The rise of DVR/TiVo and ultimately streaming brought on a golden age of TV in the 2000s. It was kind of the last hurrah for network shows that produced 22 episodes a year before streamers instead produced 8 episodes every 4 years.
But what made this system work was an ecosystem. Living in LA, Atlanta and a few other places was relatively cheap so aspiring actors and writers and entertainmnet professionals could get by with secon djobs and relatively low income. These became the future headline actors and senior professionals. Background work and odd jobs were sufficient. Background work also taught people how to be on a set.
Studios still had large writing staffs. Some writers would be on set. Those writers were your future producers and showrunners.
Part of what supported all of this was syndication. That is, networks produced shows and basic cable channels would pay to rerun them. Syndicating some shows was incredibly profitable in some cases (eg Seinfeld).
So the streamers came along and stripped things down. They got rid of junior positions. They adopted so-called "mini writing rooms". Those writers didn't tend to ever be on set. The runs were shorter and an 8 episode series couldn't support a writer in the same way a 22 episode series could. The streamers then were largely showing just their own content so residuals and syndication fees just went away.
All of this is short-term thinking. Hollywood has been both a massive industry and a source of American soft power internationally by spreading culture, basically.
I think the software engineering space is going through a similar transformation to what happened to the entertainment industry. A handful of people will do very well. AIs will destroy entry-level jobs and basically destroy that company and industry's future.
I predict in 10-20 years we'll see China totally dominating this space and a bunch of Linkedin "thought leaders" and politicians will be standing around scratchin their heads asking "what happened?"
[1]: https://www.youtube.com/watch?v=K1WrHH-WtaA
Yes and no. Often times managers are now asking ask Claude code to write it but I want it delivered tomorrow. This leads to us forcing to use LLM generated code without enough time to review or understand it.
I hope you don’t have actual users.
Don't worry, he works for the DoW.
Junior devs: you have an oracle you can pester incessantly. Make the most of it so you can learn to detect its mistakes, know when to push back, and what to ask of it. That's when you are in the clear. Juniors who merely parrot the LLM get fired.
It’s gonna take a long time for that to become the norm I think. I really wish I could take 5 years off while everyone figures this out.
You don't have to take 5 years off for it. Just continue same old business (assuming you don't have outside pressure to use this slop-machine) and keep your skills and judgment sharp until the tools and workflow stabilizes, and most of all, the money to fuel this hype runs out.
"AI is making junior devs useless" is a dangerous and incorrect conclusion. If this idea is repeated too often, people may start to believe it and even quit studying computer science altogether.
First of all, developers who only learn to code in a short bootcamp are often not well prepared — but that was already true before AI. In the past, many junior developers were students who were learning programming while studying, not just people who took a quick Python course on Udemy.
Instead of declaring junior developers useless, we should raise the standard: learn how to code properly, how to maintain code, understand networks, and build strong foundations in math and computer science. A well-trained junior developer is still extremely valuable and will always be needed.
Just another silly uninformed take.
Problem is not making juniors useless. They kind of are by definition. Problem is that now they have very little chance to become seniors.
I assume junior devs can at least search. AI often doesn't even do that. That's why there are things like context7, which in a narrow context helps but not perfect.
There are lots of ambiguous situations where a search and human "inference" can solve that AI still can't.
I can tell the AI to do something, it uses the worst approach, I tell it a better way exists, it says it validated it does not, I link to a GitHub issue saying it can be done via workarounds and it still fails. It's worse for longer tasks where it always shortcuts to if it fails pick a "safe" approach (including not doing it).
Funny enough we need the junior to guide the AI.
This is going to be music to deaf ears.
Companies will continue to demand it (I know people working at companies that are literally looking at AI usage as an individual performance metric, puke emoji), and probably 95% of humans using pretty understandable human logic aren’t going to work harder than they need to on purpose.
I wish I had a solution. I think the jury is still out on whether programming will be a dead profession in a short number of years, replaced by technical protect operators.
> If I’m reviewing your code and I ask you why you went with a certain approach, and you tell me “the AI suggested it”, I’ve immediately lost confidence in you.
I’ve experienced similar things and so understand the feeling, but this is poor leadership. If someone on your team makes it all the way to a code review and still thinks ‘the AI suggested it’, you failed to train them, failed to set expectations and they have justifiably lost more confidence in you than vice versa.
If we analyze the rest of the article through the lens of weak leadership, it sounds less like an AI problem and more like a corporate leadership problem.
Useless? Where do they expect the senior engineers to come from in the future?
AI made juniors without potential useless, not all juniors.
This is good advice for seniors too.
Eg. When using Ai Deep Research for hard to debug issues, asking for the why makes for a much better response.
You're going to have to do the unthinkable:
Invest in the training of your junior employees.
The cost of generating code is now laughable, so that's not the economic value brought to the table by a junior engineer, or really, any engineer. The value is now generated by knowing what code is good code. You're going to have to have talks, book clubs, hackathons, and the like to get your juniors to know what good code is. Do they know what design patterns are? How about good architecture? If they can't name a few design patterns, you're not investing enough.
This is ridiculous. New developers will learn a completely different skill path from what we learned, and they will get where we are faster than we did.
tl;dr ask why
When I started my career I heard people say almost verbatim "Stack overflow is making junior devs useless", with the idea all we did was copypaste scripts over. The same people failed, and the same people who can use the tools will succeed now.
You definitely did see a difference between people who just copy pasted from stack overflow, and from people with good fundamentals. The uncomfortable truth though, is that the industry didn't need good coders, it needed a bucket load of basic web apps and it needed bums in seats.
I think the irony of AI is going to be that it will make the remaining software jobs properly hard again, and implementers (ex coders) will be able to succeed with even less code knowledge than before.
I'm not sure sure.
I worked under people who started as juniors that way but were politically savvy. Or just ruthless. And pushed their way to the top by stealing projects, lying through their teeth, and other such tactics.
They were slowing down progress because their methods involved sabotaging the progress of others because it might make their own contributions shine a little less.
They were the cause of using libraries like leftPad all through business critical code, and cutting anyone down who dared to simply question why.
These things cause ripples. The smartest and most capable staff leaves, what results is a churn of the same kind.
But hey, they get a trip to Mexico every year and burn through millions every two years. Profit any day now.
I did my first completely vibe coded not looking at a line of code implementation last year and my second this year.
I could care less about why either Claude, Codex or before that a developer was using a for loop or a while loop. I did and do care about architecture.
I’m no more going to review every line of code with AI than I am when I was delegating to more junior developers. I’m going to ask Claude Code about how it implemented something where I know there is an efficient way vs naive way, find and test corner cases via manual and automated tests and do the same for functional and non functional requirements.
The "Junior Trap" is real: if you offload your thinking to Claude or GPT-4, you’re hitting "Done" for the day, but you’re accruing massive Learning Debt. You aren't building the failure-pattern recognition that actually makes an engineer valuable.
In a world where "Code is no longer a skill," the only way to survive is to stop being a "Prompt Operator" and start being a "System Auditor." If you can’t explain the trade-offs of the architectural pattern the AI just gave you, you aren't an engineer, you're just the person holding the screwdriver while the machine builds the house.