What junior engineers actually do now
1. The role got narrower and sharper
The 2015 junior had a wide and low role. They did a bit of everything, badly, and the variety was the point. They picked up the codebase by writing in it. They learned by typing.
The 2026 junior has a narrower and sharper role. They still do a bit of everything, but the easy parts of the work moved to the model. What's left for the human is the parts the model can't do reliably — and those parts demand more of the junior, not less.
2. The day, concretely
A junior in 2026 spends their day on a mix that looks roughly like this.
- Reading code. Theirs, the model's, the rest of the team's. More reading than any previous generation of juniors did.
- Writing small specifications. A ticket comes in. They translate it into something specific enough to give to the model.
- Driving the model. Short sessions. Precise prompts. They review what comes back before it goes anywhere.
- Verifying. Tests. Manual runs. They confirm the thing works, not just that the model said it did.
- Debugging. Reading errors. Tracing. The model is great at writing new code. It's worse at finding the bug in code it wrote three turns ago.
- Asking questions. Of teammates, of the codebase, of the model. Good juniors ask more questions, not fewer.
The mix is light on typing and heavy on judgment. That's the inversion.
3. Why "competing with the model" fails
Some juniors react to all this by trying to prove they're faster than the model at writing code. They stay late. They turn off the model on principle. They want to be the one who didn't need it.
This doesn't work. The model is faster than any junior at producing a first draft. Competing with it on speed is a category error.
The juniors who grow fastest do the opposite. They lean on the model for the parts where it's good. They use the time it saves them to read more, think more, and ask sharper questions. By month nine they've absorbed twice as much of the codebase as the junior who tried to type their way through it.
4. Learning the codebase, in the new shape
A 2015 junior learned the codebase by being the person who had to touch it. They'd be assigned a ticket, struggle through unfamiliar files, and by the third ticket they knew their way around.
A 2026 junior learns the codebase the same way, but the ratio of reading to writing is inverted. They spend an afternoon reading a service before touching it. They ask the model to explain what a file does. They write notes. They ask their teammates the questions the model couldn't answer.
This is slower in week one and much faster by week eight.
5. The mentorship pattern, updated
Senior engineers used to mentor juniors mostly by reviewing their code. The review was where the lesson lived.
Reviews still happen. What got added: seniors now also review juniors' specifications and the prompts they wrote to the model. The lesson moved one step earlier in the process. A senior can tell from reading a junior's prompt whether the junior understood the problem. That conversation happens before any code gets written.
If you're a junior, the prompt you write is now part of what your team sees. Treat it accordingly.
6. How to grow
The juniors who outpace their peers do four things.
- They read more code than they write.
- They write the specification before opening the model.
- They verify everything, by reflex.
- They ship small things, often, end to end.
That last one matters more than people admit. Shipping is the only way the abstract becomes real. A junior who ships ten small things in a quarter learns more than one who half-finishes one big thing.