We hired a junior engineer in the autumn, mostly to see what the role looks like now that a coding agent can produce a working first draft of most tickets. The risk we worried about was obsolescence. The risk that actually showed up was different: an engineer who could ship plausible-looking code quickly, without yet having the judgement to know when it was wrong.
Speed without judgement is a specific danger
A junior engineer working alone, slowly, tends to get stuck on things they don't understand, which is uncomfortable but visible — someone notices, and helps. A junior engineer working with an agent gets unstuck immediately, every time, because the agent will always produce something. The code looks finished. Whether it's correct is a separate question that speed does not answer, and a newer engineer has less instinct for when to ask it.
What we changed about how we onboard
- The agent drafts, the engineer explains, before either is reviewed by us. If the junior engineer cannot describe why the code is shaped the way it is, that is the actual finding, not the code itself.
- Pairing sessions moved from "watch a senior engineer work" to "watch a senior engineer question an agent's output", which turned out to be the more transferable skill to observe.
- We assign tickets slightly below what the agent alone could produce competently, so there is always a gap the junior engineer has to close by understanding the problem rather than just accepting output.
The thing that actually built judgement fastest
Deliberately assigning tickets where the obvious agent-generated approach was subtly wrong — a plausible solution that missed a constraint stated elsewhere in the codebase — and having the junior engineer find that on their own before we pointed it out. It felt slow at the time. Three months on, that engineer catches those cases unprompted, at a rate closer to our senior engineers than we expected this early.
An agent will always give you an answer. Whether that's good news depends entirely on whether the person reading it can tell a good answer from a confident one.
What we would not do again
Handing over full features immediately with only agent assistance and a final review. The final review caught the bugs, but it did not build the underlying judgement, because the engineer had not had to sit with the uncertainty of not knowing the answer. That sitting-with-uncertainty turns out to be most of what the early part of the job is actually for.
Where this leaves hiring
We are not hiring fewer junior engineers because of agents. We are being more deliberate about what we ask them to do in the first six months, because the easy path — let the agent do the work, review the diff — quietly skips the part of the job we most need them to learn.