Junior software developer — tasks, one by one

Writing routine code

Well-specified, heavily represented in training data, and immediately checkable by running it. This is the strongest case for code generation and it happens to be most of what juniors were hired to do.

Generating it is not the same as owning it. Someone still has to decide it is correct, and that someone has historically learned to judge by writing it first.

Debugging unfamiliar systems

Tools are genuinely good at suggesting hypotheses and reading stack traces. They are much weaker at the part that requires holding a model of a specific system in your head and knowing which observation would be decisive.

This is where the ceiling on generated code shows up most clearly, and it is the skill that separates a junior from someone who can be left alone.

Reviewing generated code

Volume of code produced went up sharply; the need to verify it went up with it. Reviewing fluent-but-wrong code is a distinct and newly central skill.

Reviewing well requires having written the thing being reviewed. If the writing work that trained that judgement is the work being automated, this task has a supply problem within a few years.

Turning a vague request into a spec

Requires context about users, the business and what has already been tried. Generation is downstream of this and amplifies a wrong spec faster than a human would have.

This is normally a senior responsibility; listing it as a junior task describes where the role is heading, not where most junior jobs are today. The intermediate rungs are what disappeared.

Deciding how pieces fit together

Trade-off decisions depend on constraints that live outside the codebase — team size, timeline, what the business will need next. This is what senior means, and it is the destination juniors used to reach by writing routine code for two years.

Saying seniors are safe is not a statement about entry. The path to senior ran through two years of routine code, and nothing has replaced that path.