On AI killing junior devs and pair programming
Last week we ran a networking event with 60 engineering leaders. Two things stuck with me.
First, a phrase I heard more than once: juniors are burning out the seniors. Huge PRs trusting the LLM blindly, hoping the senior's code review will fix it all.
Second: I ran a live poll on pair programming. Almost nobody promotes it anymore. Several used to, and stopped.
So I've been chewing on two questions.
Do we still need juniors? A senior who understands product, code and architecture (basically, a good product engineer) augmented with AI can do 10x the work of a junior. And juniors aren't just less productive (the tasks they used to do are now automated with AI); they can be net negative, dragging seniors down for a long time.
There's an obvious problem with not hiring juniors, though: talent pipeline. Seniors are just juniors with 5 years on top. If your team is 100% senior, each of them owns you. No negotiating power when they ask for a 40% raise or walk away. And it gets much worse long term if no company hires juniors (fewer seniors down the line, i.e. more expensive).
My take: startups with fewer than 6-7 devs, don't hire juniors, the opportunity cost of a senior mentoring is brutal when that same senior with AI does the work of three. Bigger companies, yes. Pipeline matters, and you've got room to absorb the ramp-up.
And pairing? There have always been camps. I've always sat in the middle: pair in specific situations, with specific people (hunt a nasty bug, make an architecture call, align on product). Now with AI, traditional pair programming doesn't make much sense to me anymore, and where it does, it's closer to just mentoring than to a real strategy for shipping better. What I do think works is a new shape of pairing: pair early, on the thinking: research, product refinement, specs, implementation plans. Then pair with the AI for the actual implementation. And close the loop with a human code review at the end, ideally with the same person you paired with at the start. That's the winning strategy.
Originally published in CTO Circle Issue 005.