Your junior engineers are getting faster but are they getting better?

Estimated reading time: 7 minutes

Key takeaways:

• Velocity can hide a comprehension gap: 14 features shipped, zero mental models built.
• The fix comes down to restructuring onboarding, not restricting AI.
• Changes do cost time, but less than the alternative!

---

Ask your junior engineers to explain how a service they shipped features against three months ago actually works. No laptop. No tools. Not what they built, but how the system itself behaves.

I did this after six months of mandatory AI-coding tools on my team. Velocity was up. Cycle time was down. Every metric looked like a win.

What I heard was mostly silence. Then some guessing. Then a description of one function, not the system. All in all, 14 features were shipped. Zero mental models were built.

That moment showed me I had been measuring the wrong thing. Our junior engineers were shipping faster than ever, but they were not building the understanding that turns a junior engineer into a senior one.

Over the following six months, we redesigned our onboarding process to rebuild that understanding without giving up the speed. This article covers what went wrong, what we changed, and what it cost.

Why speed and comprehension are different things

I have spent over a decade building engineering teams across banking, fintech, insurance, and e-commerce, and I have onboarded engineers at every level.

In that time, junior engineers grew in a predictable way: they got stuck, pushed through, and slowly built an intuition for how systems behave. The struggle was slow and uncomfortable, but it did the work.

AI-coding tools did not just speed that process up. They bypassed it.

When my team adopted AI tools, every measurable output improved. Pull requests merged faster. Cycle time dropped. New joiners made their first meaningful commit within weeks instead of months. On paper, it looked like exactly what we had hoped for.

What the metrics did not show was that junior engineers were shipping code they did not understand. They were checking diffs instead of making decisions. They were approving code that worked without knowing why it worked, or what would break if something around it changed. 

Software engineering is not really about writing code. It is about thinking, and the code is what comes out at the end. That thinking grows the hard way: you get stuck, you look things up, you ask someone, and you go back and work it out yourself. AI tools removed that friction, which is exactly what they are built to do. The problem is that the friction was doing real work. 

The cost became visible four months into our transition, when a junior engineer was pulled into a production incident involving a race condition in our order processing service. He had written a feature against that same service two months earlier, yet he had no idea where to start looking. 

He was not careless or disengaged. When he built that feature, the AI tool generated the logic. He reviewed the output, confirmed it looked right, and moved on. The reasoning never passed through him.

This is not a story about a bad engineer. It is a story about an onboarding process that had silently stopped doing its job.

The changes we made to rebuild understanding in junior engineers

None of what we changed requires restricting AI tools or rolling back adoption. The tools are genuinely useful. The issue was how we used them during the period when junior engineers are building their foundation.

Separating output tasks from learning tasks

We created two categories of work during onboarding and named the difference honestly. Output tasks are tickets where shipping is the goal. AI tools are fully encouraged, speed is valued, and review is lightweight. Learning tasks are tickets where the goal is building a mental model.

For these, we ask junior engineers to attempt the problem without AI assistance first, then use the tool, and write a short paragraph explaining what was different about the AI’s approach and why. A senior engineer reviews those paragraphs weekly. The ratio starts at 50/50 and shifts toward 80% output by month three.

The structure matters less than the honesty. We tell every engineer at the start that some of their work is about shipping, some is about learning, and the two have different success criteria. What junior engineers resist is not constraint. It is an unexplained constraint. When they understand the reason, they engage with it.

Adding decision walks alongside code review

Standard code review asks whether the code is correct. In an AI-first team, the answer is almost always yes, so correctness has stopped being a useful signal of comprehension. Once a week, every junior engineer picks one merged pull request and walks a senior engineer through it verbally. Not the code, but the decisions. Why is this method here and not in the service layer? What assumption does this code make about the upstream API? What would break if the cache expiry changed?

Each decision walk takes 15 minutes, and it surfaces something a diff never shows. It also changed how junior engineers used AI tools. Knowing they would need to explain decisions out loud, they started asking the tool to explain tradeoffs between approaches instead of simply requesting working code. That shift in behavior was the most valuable outcome of everything we changed.

Starting onboarding with a codebase read

New engineers now spend their first two weeks answering a set of questions through code exploration, documentation, and their own testing, without AI tools. Where does a request enter the system, and what happens before it reaches the database? Which service has the most visible technical debt, and how can you tell? What would fail first if the message queue went down?

The answers go into writing, and a senior engineer reviews them through a conversation rather than a correction session. The goal is to understand what mental model the engineer is forming, not to grade them. The process is intentionally slow, but it means engineers start writing code with a map of the terrain. AI tools become far more useful to someone who already has a map, because that person can judge whether a suggestion fits this specific system.

Teaching debugging as a skill

Debugging is how junior engineers have historically built deep system intuition: tracing behavior through a running system, forming hypotheses, and reading logs to compare what is happening against what the code implies should happen.

AI tools now handle much of that automatically, so the intuition never gets built. We run a monthly session using real, anonymized production incidents, facilitated by a senior engineer in a question-driven format. What does this log line tell you? What does its absence tell you? What would you look at next? The goal is to build the habit of reasoning about a system when you do not know what is wrong, which is what every incident eventually requires.

The results and the costs

Six months after making these changes, our time to meaningful contribution fell from seven months to four. I define that as the first incident a junior engineer can work through independently, not just the first feature shipped.

The change in how people talked mattered more. Senior engineers stopped saying juniors were fast but needed help with anything hard. What I heard instead was “they ask better questions now.” Not fewer questions, but better ones, about why the system works the way it does rather than how to write a line of code. 

The costs were real. The codebase read adds two weeks to onboarding. The decision walks add 30 minutes of senior engineer time each week. The debugging sessions require preparation. 

However, the alternative cost is higher, and it shows up later: in incidents where no one knows where to look, in code that passes review but cannot be maintained, and in senior engineers who find they cannot delegate anything that requires judgment. None of that appears on a dashboard, and by the time you can see it, it has been compounding for months.

Start with one question

In your next 1-to-1 with a junior engineer, ask them to explain how a service they shipped features against three months ago actually works. No laptop, no tools, just the question.

If you hear a description of the system, including how it takes requests, how it handles failures, and what it depends on, you are in good shape. If you hear a description of one function they wrote, you have a comprehension gap that your velocity metrics are not showing you.

The junior engineers on your team today are your senior engineers in four years. Whether they will be able to make architectural decisions, lead incident responses, and grow the engineers who join after them depends on the foundation they are building now.

Speed helps you this quarter. Understanding helps you for years.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.