Your Junior Dev Leans on the Agent. Good.

TL;DR: A first-time lead asked me what to do about the developer on his team — still in college — who builds almost entirely with an agent. The code works, but it’s rigid, unabstracted, and hard to read, and he’s worried the junior isn’t learning. The instinct is to make him use AI less. That’s advice with an expiry date, and it doesn’t fix the actual problem. The readability bar existed because editing code was expensive; it isn’t anymore. The bar that still holds is verification — does this do what we said it does, and does it survive being wrong. Aim him there. Then be honest about what he genuinely loses, because something real is lost and pretending otherwise doesn’t help him.

The question

Same new grad I wrote about in Every Insane Codebase Was Once Rational — a year into the industry, running a project and, for the first time, another person. His second question was about that person:

One of his developers is still in college and leans heavily on AI for his work. It works. But the lead is seeing a lack of flexibility when functions need to change, a lack of abstraction, and code that’s hard to read. He’s been trying to curb it and it isn’t landing. He’s worried the junior isn’t learning what he needs to — bad for the junior’s future, bad for the team, because the lead wants to hand him larger components without worrying about quality.

Every part of that observation is correct. The diagnosis that follows from it is the part I’d push back on.

The advice with an expiry date

The instinct is to tell him to use AI less and write more of it himself. I understand the instinct and I think it’s a losing position, for a reason that has nothing to do with whether agents are good.

It’s how he’s going to build. It’s how you’re going to build. It’s how I build — I’ve barely written a line of code by hand in the last six months, and I’ve been doing this for thirteen years. That’s not a prediction about 2030, it’s a description of a workflow that already shipped 4,154 commits in six months.

You haven’t hand-written an HTTP request in years either. Almost nobody does, outside of debugging or implementing the protocol itself, which is a different job. The abstraction moved and the skill under it stopped being load-bearing. That’s happened repeatedly — assembly, memory management, DOM manipulation — and the engineers who dug in each time didn’t preserve the craft, they just arrived late.

So “use it less” spends your authority on a rule that reality is going to overturn, in front of a junior who can see it being overturned. You get one or two of those before your feedback stops carrying weight. Spend it on something that survives.

The readability bar was a proxy for edit cost

Here’s the part worth thinking through, because it’s the actual shift and it’s easy to mistake for lowering standards.

Why did we demand readable, well-abstracted code? Not for aesthetics. Because changing code was expensive and the expense was human attention. Every future modification required a person to load the whole thing into their head, find the right place, and change it without breaking three other things. Readability was the tax we paid up front to make that cheaper later. Abstraction was insurance against having to make the same edit in nine places by hand.

The unit cost of that edit collapsed. Need to change the function? The agent changes it. Needs a refactor to accommodate the change? It does the refactor, faster than the junior would have, and faster than you would have. The rigid unabstracted code the lead is worried about is genuinely worse to hand-edit — and hand-editing is the thing that stopped happening.

That doesn’t mean structure is worthless. It means structure is no longer where the risk lives, and continuing to spend your review attention there is spending it on the cheap problem. The expensive problem moved.

Where the risk actually went

If you’re not grading style, what are you grading? Behavior. Specifically: does this do what we claimed, does it still do it after the next change, and what happens when it’s handed something we didn’t anticipate.

That’s where quality lives now, and it’s not a soft standard — it’s a harder one, because it’s falsifiable in a way “is this readable?” never was.

Concretely, what I’d ask of a junior building with an agent:

Tests the agent didn’t write from the same context as the code. An agent that writes the implementation and the test in one pass will happily write a test that passes against its own misunderstanding. Make the test come from the requirement, not from the code. Different session, or written first — TDD holds up unusually well with agents for exactly this reason.

Mutate the test and confirm it fails. This is the cheapest quality check in existence and almost nobody runs it. Break the implementation on purpose. If the suite stays green, the test is decoration. A junior who does this once will never fully trust a green checkmark again, and that skepticism is worth more than any style rule you could teach him.

Test the boundaries, not the happy path. Empty input, huge input, wrong type, the network call that hangs instead of failing, the duplicate submit. The agent’s default is the path it just imagined; the failures are always in the paths it didn’t.

Non-deterministic output needs its own approach. If any part of the product calls a model, normal assertions don’t hold — testing agent outputs is its own discipline and it’s a good, concrete thing to hand a junior who wants harder problems.

Resilience over elegance. What happens when the dependency is down, the input is malformed, the job runs twice? Those questions have real answers and reviewing them teaches systems thinking, which is the thing you actually want him to have.

Note what this does to the mentoring problem. “Make your code more readable” is taste, it’s arguable, and a junior can’t tell whether you’re right or just particular. “Break the implementation and show me the test catches it” is a task with a binary outcome. He can run it himself, and it’s either green or it isn’t. That’s a standard that teaches without requiring him to defer to you.

The honest tension

I’ve argued before that coding agents have no structural reason to write maintainable code — the training signal fires on tests going green, nothing in it grades design, and no harness moves that ceiling. That post’s prescription was to spend your reading budget asymmetrically and keep architecture human-owned. I still hold that. This post adds the other half, which is where the budget comes from: the attention you’re currently spending on readability is the attention that should be spending on verification. Not “review less.” Review the other thing.

And I have to argue against my own numbers here, because that same post cites the Faros AI study of 22,000 developers across 4,000+ teams — incidents-to-PR up 242.7%, code churn up 861%, median review time up 441.5%. That is not a picture of quality problems that stopped billing anyone. It’s a picture of them billing harder.

But look at what’s actually in that bill. Churn is code rewritten shortly after it’s merged — the cost of the edit, which is exactly the cost that collapsed. Incidents are behavior wrong in production. Review time is humans reading. Two of those three are the thing I’m telling you to aim at, and the third is the queue that broke because review time exploded until people started skipping it. None of those three lines is “the abstraction was inelegant.” The bill went up on verification and human attention, which is the argument for moving your bar there, not for holding the old one harder.

The caveat that survives all of it: the ceiling still bites where structure and correctness are the same thing. Data model, module boundaries, auth flow, anything with a public interface. There, review the design — a bad call there isn’t a style problem, it’s a one-way door.

So the rule isn’t “never review structure.” It’s: review structure where structure is load-bearing, and review behavior everywhere else. Most code is everywhere else.

What compounds: context, not keystrokes

The biggest single factor I’ve seen in whether AI-heavy development gets better or worse over time isn’t the model. It’s whether the team is accumulating anything.

At EnergyConnect we maintain what amounts to a second brain for the agents — thousands of lines of markdown the agents read and write. Not documentation for humans that agents happen to parse. Working knowledge: a file describing how our bidding process runs, a file on how the carrier-supplier relationship works, and a log. When an agent gets something wrong because it didn’t know two of those things were related, we correct it and write the correction down as an entry. Next time, it looks up “carrier,” finds the file, loads that context on demand, and doesn’t make the mistake. The learnings compound instead of evaporating at the end of every session.

That’s the difference between a team that gets faster with agents and one that just generates more code. I’ve written up how to build the wiki your agent actually reads and what belongs in CLAUDE.md after fifty commits with it, so I won’t repeat the mechanics here.

For a lead with one junior, this is the highest-leverage thing you can hand him, and it’s the answer to “he isn’t learning”: have him own the knowledge base. Every time the agent gets something wrong about your domain, he writes the entry that prevents it. To write that entry he has to actually understand the domain — which is the learning you were worried he was skipping, arriving through a door he’ll walk through voluntarily because it makes his own work easier.

The part where he’s right, and what it costs

I don’t want to wave away the worry, because underneath it is something real.

The pile of unglamorous work that used to build judgment is exactly the pile agents are best at, and that’s a problem I’ve written about at length. It hits juniors first and hardest.

The mitigation isn’t taking the tool away. It’s making him responsible for the judgment the tool can’t hold:

• He owns the domain knowledge base. Every agent mistake about your business becomes an entry he researches and writes. He can’t write it without understanding the domain, and he’ll do it willingly because it makes his own next prompt work better.
• He owns the test strategy, so he has to know what could break.
• He owns the incident when his component fails, so he learns what production does to assumptions.

None of that requires him to type the implementation. All of it requires him to understand the system, which is what “learning” actually meant the whole time.

The standard you’re enforcing might not be yours

One more thing he raised, and it’s the same problem wearing a different hat: he’s finding it hard to hold a standard he isn’t fully sure of himself, worried about whether he’s doing it the way the industry does it, while both he and his dev are new to this.

Your job as the lead is to fit the standard to your team, not to import it. A practice can be a real industry standard and still be wrong here — if it costs you more than it protects you, it’s a cost, and you’re allowed to change it. Same instinct as with the code: fix the pain point, and when something breaks, fix that. For a two-person team, less process is usually the right first guess. And a fair amount of the job is just listening — if you’ve hired well, the person doing the work will tell you what they need and how they want to build; you mostly have to ask and then actually hear it.

Read Peopleware. First edition 1987. The third, in 2013, added six chapters on leadership, meetings, and distributed teams, and otherwise left the thing alone — and there hasn’t been a fourth in the thirteen years since. You’re managing people. That part hasn’t moved nearly as much as the tooling has.

What to do this week

1. Stop asking for less AI. Ask for a broken test. Have him break the implementation and prove the suite catches it. One exercise, immediate result, teaches more about quality than a month of style review.
2. Move your review attention. Structure gets reviewed where it’s load-bearing — data model, boundaries, auth, public interfaces. Everything else gets reviewed on behavior.
3. Separate the test’s context from the code’s. Requirement first, or a different session. Same-pass tests validate the misunderstanding along with the code.
4. Hand him the knowledge base. Every agent mistake about your domain becomes an entry he writes. That’s how he learns the domain and how the team stops repeating errors.
5. Cut one process you imported because it was standard. If it’s costing more than it protects on a two-person team, it wasn’t a standard, it was a costume.

If you’re leading a small team through this shift and trying to figure out what to actually hold people to now, that’s a conversation I have often.