Forever Juniors": How Junior Engineers Beat AI Agents

The real competition for a junior engineer today isn't another junior with better AI tools - it's the question of whether they'll ever become a senior at all. A Criteo engineer argues the actual risk of AI agents isn't that software engineers disappear, but that seniors do, as an entire cohort becomes 'forever Juniors' leaning on agents without ever developing judgment of their own.

What Seniorhood Actually Requires When Agents Write the Code

The source article defines seniorhood concretely: defending shipped code, arguing design choices, detecting when an agent goes wrong, knowing when to delegate, and teaching others. None of those skills emerge automatically from using an agent - if anything, heavy agent use can route around all of them. At Criteo, engineers are asked to lean on AI agents for productivity while keeping 'a firm hand on the wheel,' which is the honest framing: the tool is mandatory, the judgment is optional and therefore at risk.

The practical takeaway is that the skills worth deliberately building are exactly the ones agents don't develop for you. That's not nostalgia for hand-written code; it's a list of what still has to be true about you when the agent finishes.

Questioning Agents Beats Trusting Them - Here's the Mechanism

The most actionable technique in the piece is Socratic questioning: demanding that an agent justify its choices instead of accepting output. The author's observation is precise - making an agent explain a flawed solution out loud is often how it catches its own mistake, and how you catch it too. This beats passive review because it converts every agent interaction into a reasoning exercise rather than a diff-approval exercise.

Review skill matters just as much. The author recommends reviewing agent output using patterns harvested from senior code comments - recurring critiques like naming, boundary, or error-handling issues - and then encoding those patterns into a skill.md file fed back to the agent. That's a compounding loop: your review taste becomes the agent's constraints.

Coding Without AI Isn't Nostalgia, It's Calibration

Occasionally coding without AI - what the author calls 'handwriting' - builds autonomy. The point isn't purity; it's calibration. If you never code unassisted, you lose the baseline needed to notice when an agent's output is subtly wrong.

The author's own skill.md makes this concrete: it forbids the agent from writing files or committing without explicit plan confirmation. That constraint does two jobs at once - it protects the codebase and forces the human to stay in the decision loop where senior judgment actually forms.

Where This Beats Doing Nothing (And Where It Doesn't)

Compared to the default path - use agents heavily, hope seniority arrives with tenure - this approach wins specifically when your job involves shipping code you'll have to defend later. It loses on raw short-term throughput; hand-writing code and demanding justifications are slower than accepting output.

Worth adopting if you're early-career and your team measures you on what you ship and can explain; skip it if your role genuinely never requires defending design choices - though in that case, my read is that the role itself is the bigger problem than any workflow choice.