The case against hiring juniors is easy to make right now, and that’s what worries me. Agents scaffold a project, wire up an API, and draft a function faster than any new grad. That used to be junior work, so the logic goes: don’t hire the junior. Clean. Tidy. Wrong.

I want to push back on that, because I think the conclusion is wrong and the reasoning is lazy. The grunt work didn’t define the junior’s value. It was just the on-ramp we happened to have. The agents took the on-ramp. They didn’t take the destination.

But here’s the part nobody wants to say out loud. If you take away the on-ramp and change nothing else, you do end up with juniors who can’t drive. The doom story is wrong about the cause and right about the risk. The risk is real, and it’s a training problem, not a hiring problem.

So here’s what we’re actually seeing at Groxio, and what we’re changing in response. It’s a little chaotic out there. I don’t think anyone has this fully figured out, but I’d rather show you our working draft than pretend we have a clean answer.

What the junior’s day actually looks like now

A year ago, a junior spent the bulk of their time producing. Writing the function, fixing the syntax, getting the thing to compile. The skill we were implicitly building was fluency, the ability to turn an idea into working code without fighting the keyboard.

That’s not where the time goes anymore. The agent produces the first draft. The junior’s day is increasingly about exercising three different muscles:

Deciding what to ask for. Portioning the work into pieces an agent can actually execute well, and knowing which pieces to hand over versus keep.

Knowing whether the answer is any good. An agent will hand you confident, plausible, wrong code all day long. The junior who can’t tell the difference is dangerous. The junior who can is suddenly worth a great deal.

Holding the shape of the system in their head. Agents are great in the small and lost in the large. Someone has to own the boundaries, the layering, the contracts between parts. That someone used to be senior-only. Now it has to start earlier.

Notice what all three have in common: none of them are production skills. They’re judgment skills. The job moved up the stack, from making the thing to directing and verifying the thing. That’s a more senior posture than we used to expect on day one, and it’s exactly why training has to change.

What we spend less time on, and what replaced it

Here’s the counterintuitive part. We spend less time teaching juniors to write the functional core by hand. The agent is good at that, and it doesn’t need much help.

What we spend much more time on is the reasoning around it: that you need a functional core at all, what each layer above it is doing, and why it’s there. The shift is from production to comprehension. A junior used to earn that understanding slowly, by building everything by hand. We don’t have a year to wait, and we don’t need to spend it on keystrokes. We need them to understand the architecture early, because the architecture is what the agent can’t be trusted to hold.

The Elixir stack is a gift here, because the layers carry real meaning. Clean functional designs in the core. Reliability through supervision. Well-established patterns a junior can learn to recognize and guide. Each layer exists for a reason, and once you know the reasons, you can tell when an agent has violated them.

That’s where the reasoning stops being abstract and becomes a verification skill. Take a concrete one: you expect tagged tuples at the boundary but not in the core. Why? Because failure happens at the boundary. That’s where the messy outside world gets in. It doesn’t happen in the core, which is pure. A junior who understands that can look at agent output and immediately see whether it got the shape right. Tagged tuples bleeding into the core, or a boundary that pretends nothing can fail, is a red flag you can spot in seconds. The reasoning is the red/green indicator. It tells the student, at a glance, whether the agent has it right or wrong.

This is the whole game now. When an agent writes most of the code, a junior’s value is the ability to evaluate it. Evaluation runs on exactly this kind of load-bearing understanding. You cannot bluff it. The agent will happily generate code that looks idiomatic and is quietly wrong about where failure lives or what belongs in which layer. The only defense is a developer who knows what right looks like and has fast signals for spotting wrong.

What we’re accelerating

Everything that used to feel “too early” for a junior, we now teach early on purpose because the job demands it on day one.

Boundary contracts and behaviours. If your job is to hold the shape of a system while an agent fills in the middle, you need to think in interfaces, contracts, and layers long before you’d have gotten there organically. Where does this code belong? What does it depend on? Juniors used to absorb that slowly, by osmosis, over a year of code review. We can’t wait a year, and the agent will cheerfully scatter logic across every layer if no one is holding the architecture. So we front-load it.

How to effectively partition pull requests. In the past juniors couldn’t over-produce because they physically couldn’t write that much code. These same developers now have to exercise a new critical skill: restraint. How do you break a feature into agent-sized pieces? When do you let it run versus drive manually? How do you keep a long task from drifting? This work takes practice, and our courses build in time to do so.

Here’s the pattern that ties it together. We’ll have folks build a small system by hand: a counter with reducers, then a GenServer and LiveView around it, until they understand every layer and why it’s there. Then that becomes the pattern the agent follows. The human owns the shape; the agent fills it in. It works remarkably well, but only because the human actually understands the shape first.

What this means if you’re hiring

The junior who’s worth hiring in 2026 doesn’t look like the junior from 2022. They may write less code from scratch. That’s fine. That was never the point. Here’s what you want to see instead.

Can they tell good output from plausible-but-wrong output? Do they reach for contracts and boundaries naturally, or do they just want to make it work? Can they break a problem into pieces and direct work, rather than only execute it? Do they live in a tight verification loop, or do they trust and hope?

Those are learnable. That’s the whole point of this post. The skills moved, the training has to move with them, and at Groxio we’re moving it. Less hand-building of the core, more on the reasoning and the layers, hard focus on directing and verifying agent work. None of this is settled. We’re revising it constantly. But the one thing I’m confident about is that “AI ate the junior” is the wrong story. The junior’s job got harder and more interesting, earlier.

There’s a longer game here too. A company that stops hiring juniors because agents do entry-level work is eating its own seedcorn. The seniors you’ll need in five years are the juniors you train today, and you don’t get them by skipping the years in between. The lazy conclusion saves you a salary now and costs you a bench later. We’re choosing the other way: invest in the people, train them for the job as it actually is, and grow the seniors instead of assuming they’ll appear. The teams that make that choice are going to have a real edge while everyone else is busy not hiring.

We’re figuring it out in the open. Happy to compare notes with anyone else in the weeds on this.

— Bruce