Junior Extinction
At the speed of iteration
There has been a lot of discussion about whether junior engineering roles of all kinds will disappear completely.
You may have read some of my recent posts and thought that my point of view was that they would disappear, but it’s not quite so binary as that. I can see that high-growth early-stage companies may never hire junior engineers again, but they are quite small companies and didn’t really hire juniors much anyway, because they didn’t have the bandwidth to train them.
The other driving force is that large tech companies are laying off and not hiring as many engineers, and they are definitely not hiring juniors in the same way anymore. Previously, graduates from Stanford, Berkeley, MIT, Oxford, Cambridge, Imperial, etc in CompSci didn’t have to look hard for work after graduating, if they had to look at all. The big tech companies would look to hire as many of these graduates as possible to enter their graduate schemes and fill the pipeline of future labour they would need. This is clearly no longer happening, mostly because tech companies don’t believe they will need as many humans in the future.
However, I doubt they aren’t hiring any junior engineers at all... They’re probably still hiring at least 10% of the graduates they used to, and perhaps these are the very best who, during their time in education, had already built a lot of things and contributed meaningfully to open source software, etc. In traditional industries, this reduction in hiring is probably not nearly as severe. I doubt large banks have significantly changed their hiring practices in the past year. In traditional industries, I think at least 50% of junior engineering positions in a given year would still exist.
So, clearly, this is not an extinction. It’s a reduction. One thing that I think we are very close to achieving is having AI-augmented engineers capable of handling a significantly larger volume of work than engineers of 4 years ago.
Others have argued that we’re creating a significant problem for ourselves by not hiring junior engineers. Now, we’re not talking about none at all - let’s say 50% of what we used to across all industries at worst case, which is still a lot, given how many we used to hire across the world. Junior engineers typically spend about 5 years advancing to mid- to senior-level engineers. Five years from now, the level of AI-augmentation in engineering will be inconceivable compared to what we see today with market-leading tools like Claude Code. I think if we even have half the pipeline of engineering talent come through at that time, we will have more than enough human labour to do all the engineering work we need to with AI Assistance.
This also doesn’t mean there is no work at all for graduates who no longer have traditional engineering jobs to pursue. Charlie Graham’s post, which I linked above, shared some ideas about what the new important skills would be, and I agree with them:
Today, companies hire for coding chops, writing skills, or analysis ability. Those roles will shrink and be replaced by people who can become experts at:
Prompting and directing AI agents precisely
Clear communication, turning complex ideas into effective prompts
Multi-tasking expertise, quickly and constantly context-switching and responding to different AIs at their stopping points
AI orchestration, using different AI agents and having them check each other
Managing AI workflows and knowing when to intervene
Native AI intuition, an intuitive understanding of how AI works, where it is likely to go wrong, and how to keep it on track
The skillset that Charlie describes is a mixture of Product Manager, Architect and Engineering Manager in today’s roles, in addition to AI specialism, which will diminish over time as we need to compensate less for AI's rough edges. I also think architecture skills are incredibly useful in this new world, too.
While not nearly as good as the top talent I have worked with, these agents have the advantage of being <10% the cost, available 24/7, and responding with results in a few minutes instead of hours or days.
This speed of iteration is something I’ve been thinking about a lot. Right now, if you want a human engineer to make a change, regardless of size, you have to follow a process:
Get that engineer’s attention. You might be able to ping them on Slack and get them to drop what they’re doing immediately, but often you need to have what you want prioritised through backlog grooming and scheduled into a sprint sometime this quarter.
Then, once you have the engineer’s attention for the task at hand, you would typically discuss it with them on a call or face-to-face to ensure maximum context sharing, and perhaps send at least a few messages over Slack or on your Jira ticket if there is already a lot of shared context.
Then the engineer might go home and then to sleep because it’s the end of the working day, and they had meetings and other tasks to attend to before working on what you wanted.
Then they’ll spend something like half a day getting their head into the context, asking clarifying questions once they fully understand the situation and any unseen tradeoffs.
Then they might spend another half a day making the change, writing tests, etc.
Finally, you have something to see in a demo environment.
The day I suggested the engineer would spend on the small change includes all the human-related activities like getting coffee, going to the bathroom, having lunch, chatting with Mike about the upcoming Neuromancer TV adaptation, responding to significant other’s Whatsapp messages, catching up with Substack and HackerNews... It could be a bit shorter or much longer.
If you had asked Claude Code to make the change, it would have made an attempt, and if it was allowed to keep iterating without intervention, would make a “boop” sound from your terminal a few minutes later, in less than the time it took you to read this far in this post.
It may then need you to unblock it by providing an API key or some kind of direction, or allow it to run main.py on your machine. You may need to go through a handful more iterations than this, but within some time that is probably less than half an hour, you will have something that does what you want unless you have been far too ambitious or unclear.
Then you can taste test and iterate. Within a day, you can have what would have taken weeks with other humans. Yes, there still needs to be oversight and strong review processes for merging anything, and maybe a level of rewrite required to meet specific company code standards. This is where you have true production with paying customers - where you don’t yet, you can YOLO and merge. The speed at which new products can be created and released has increased by 10 to 100 times in just three years.
Startups that aim to fail fast can build in a week, attempt to sell the following week, and choose to pivot within a month of product idea inception.
We’re also seeing that the successful products of this generation are not expensive SaaS tools with enterprise sales cycles. They are cheap subscription-based products which cost $10 to $201 per user per month. These products ship updates daily; they aren’t overly concerned with shipping a few bugs because their customers don’t pay enough to complain very loudly. The key is taste - does the product work well enough to please their customer, does the velocity in releases keep the product ahead of the competition sufficiently that customers don’t jump ship2.
Although I have been tempted to upgrade to Claude Code Max… what do I do with the part of my day when I’m over my usage limits? I was weighing up whether I would use it enough to warrant going for the $200 tier, just based on need… there was no question of value.
Look at what happened with me and Cursor: it didn’t do something I needed and I switched to Windsurf. I still pay for Windsurf, but there will come a time soon, now that I’ve been using Claude Code in a terminal in Windsurf, that I may realise that I haven’t used Cascade in Windsurf for a while and therefore stop paying for Windsurf and switch to using Claude Code in VS Code. Maybe I should even learn Vim? If I only use Claude Code, terminal and Vim on a machine… do I need a Mac? Could I just have a very basic Linux Distro with no GUI at all?