Hacker News

It's interesting that the same dynamic is playing out on a much larger scale with children. A child is far more helpless than a junior engineer - at least a junior engineer can feed themselves, wipe their own butt, avoid destroying the room, and generally keep themselves alive. Everybody wants to offload the cost of raising children to parents, because the economic benefits aren't realized for 25+ years yet the costs are very substantial (frequently, at least one parent's full-time attention, costing them an income). Prospective parents are saying "fuck that shit" and simply choosing not to have children.

The long-term effects are going to be much like the effect of the software industry turning away from juniors: total collapse. When you have no workforce, you'll do no work - hell, there is just...nothing, nonexistence, no consumers either. But the fertility bust operates on a longer timescale (I think the software industry will start feeling the dearth of juniors in ~5 years, the economy as a whole won't feel the dearth of children for ~5), and it's far more fundamental. Rather than one industry disappearing, all industries will disappear, likely refactored into something that looks far different.

It also reminds me of those ecological predator/prey/locust models that I studied in calculus class, where population dynamics for many species have a tendency to overshoot the carrying capacity of the environment. Each individual in the population makes their own reproductive & survival decisions, but the sum total of them leads to population collapse and a near total extinction, followed by recovery once the survivors find resources abundant again.

I’ve had some who are useful almost out of school. The amount of tickets is always growing and have someone pick up those “when things calm down I swear I’ll address this” tickets is always helpful. If they can’t get anything done by themselves in the codebase then it gets much harder. I do also think that some people have completely forgotten all the context they didn’t have when they started off xx years ago so mentoring is not always very good

> Junior devs have always been useless

> The same ethos makes sense with AI, it's just that every company is trying to avoid paying that training tax.

Last time when a junior dev was added to my team I had a similar thought. But then talking with management I was informed that things went beyond just training.

The company had a social responsibility pledge and understanding with the local educational institutions. They had to pledge to be part of the internship and hiring activities every year. The company could not chose to be fair weather friends and try to recruit people only when they saw fit.

The other aspect was cost. A team made of only senior engineers was costly.

The last aspect was leveling up. Unless the company has lots of levels the team might end up lots of engineers at the same level. And with the inverted funnel nature of promotions it meant some engineers might end up waiting years for the promotion.

So, it was better to have teams with some junior, intermediate and experienced engineers. That way costs and promotion flows were controlled.

Now with AI the impact might go beyond junior devs. I see even the intermediate devs being impacted. It is more likely that companies think they can replace say 1 junior + 1 intermediate with 1 junior dev with AI. Or something along those lines.

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.

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.

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.

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.

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.

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

I think the idea of 'junior' needs to be refined a bit. By the time I got my first job I've been coding for years, and have built rather substantial things. In fact, in terms of pure coding ability, I was probably past the initial, fast part of my growth.

As should have others, which the university education system should have made sure.

The fact that some people come out of 4+ years of software engineering education utterly clueless means that they somehow managed to dodge having to build anything, I think means that they will never get good at any point in time, as they either were very talented at dodging having to build things, and I don't think that talent is going to abandon them, or they couldn't really grasp the basics in an environment designed for just that.

With that said, I think you can see for most juniors, what you can expect out of them in terms of pure coding ability - sure a lot of them have room to grow, but I've met so many great people who were very young, yet were useful from day one.

In fact, if you have the willingness to grind away at some problem, that puts you ahead of a significant amount of the pack. I have had the misfortune of working with people who lacked any demonstrable skill, and had coping strategies for having to deal with any sort of hardship. Getting useful work out of them was a challenge in of itself.

These people managed to get the years in to be considered senior, and are probably dispensing their wisdom 'mentoring' juniors somewhere else, and are no longer expected to actually contribute to meaningful issues.

Why? Because I learn every time I do.

Many juniors are actually very experienced but the industry can’t see that on paper.

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

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

everyone was junior at one point, everyone. “junior” is just age mate, just age…

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

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.

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.

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

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.

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.

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.

It already happened. The old timers correctly observe that modern applications are bloated and inefficient because of all the heavyweight frameworks, excessive abstraction layers, and "left-pad culture" where external dependencies are pulled in to do the most trivial things but that these things enabled less capable developers to effectively build software to fulfill industry demand. LLM-only coders are just the next step in the devolution.

That's literally what https://news.ycombinator.com/item?id=47157039 seems to be about, and I had the same reaction as you

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

I think the issue is they used to make progress at a snails pace and you had plenty of teachable moments.

Now anybody can vibe code something that seems to work with a million landmines.

How can they develop the intuition around this given that they don't know what they don't know? How can we review it and help them get there?

Maybe we can figure it out, but I'm not sure it's easy or obvious.

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 think so. Just go to the homepage, all of the thumbnails are AI generated with clickbaity titles.

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.

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's the opposite. The less competent the average developer the more valuable coding LLMs become (as the only way for those bad developers to generate ok code). Eliminate the good developers and even bad coding LLMs become valuable.

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

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.

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.

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.

Adam, can you please share, how in the world, this junior dev got hired with you?

I'm self-taught dev with multiple years of experience. I choose the hard route, even after AI. For me, programming is theory building, so I always choose understanding above all else.

Rock solid understanding of TypeScript, frontend and backed.

I have sent 100s of CVs. For Juniors, Mids and Seniors. Not even a single interview.

I will be glad for your thoughts on the matter.

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

> I hired a junior "dev" who literally hadn't even completed an HTML course.

I mean, I'm a fairly senior dev, and have literally never completed, or indeed really heard of, a html course. Is that, eh, part of your average CS degree these days?

>> who literally hadn't even completed an HTML course.

so what is their value? proxy your requests to ai?

Why are you paying them instead of running the AI yourself?

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.

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

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

Objectively speaking, students that use AI score more than a full grade point below their peers not using AI.

AI makes students dumber, not smarter.

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?

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.

Idk, anyone who wants to understand and apply the most powerful and transformative technology in human history…?

I understand that but try getting hired in industry as a PhD with that argument.

Back to fuedalism we go!

I've seen a lot of hot takes on HN but faulting streamers for the inability of Hollywood to adapt to cultural and technological change is gonna require oven mitts. The rise of streaming is a win for the little guy and the viewers against Hollywood's capitalist entertainment oligopoly.

I hope you don’t have actual users.

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.

"juniors are useless": Maybe y'all should consider updating this hyberbolic language. Nobody is born a "senior developer", so surely all of your training as a "junior" is not useless. There is always a disconnect between what younger people know and what older people expect them to know, so training is required almost universally.

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.

Yeap, and people are still forcing juniors to make small code changes when they should be learning by creating entire apps on their own, deploying them, etc. WITH a senior giving them feedback occasionally. I think people are going to take a while to catch on though, for better or worse....