Training Engineering Judgment When AI Writes the Code

Don't Rush to Judge "Can They Use AI"

In the past, juniors learned by writing small features — APIs, database queries, exception handling — and iterating through test failures. That slow process built experience. Now an Agent can produce a runnable version quickly. The delivered code looks more complete, but it's harder to see how much the junior actually understands. Projects also don't allocate extra time for mentoring.

Simply checking whether a junior can prompt an Agent to finish a task doesn't reveal whether they can spot problems in the solution or handle exceptions. Conversely, forcing them to write everything by hand with AI turned off turns training into an artificial exam disconnected from real work.

The goal is to see if, while allowed to use AI, the junior can make judgments at critical points: where duplicate writes might happen, which conclusions lack evidence, why a failure shouldn't be immediately retried. Basic skills can be checked with short independent tasks, but the whole project need not revert to pre-AI workflows.

Ask What Will Happen, Then Run It Together

Using the earlier example of customer data import: the backend write succeeded but the response was lost in the network, showing a timeout on the page. Before introducing terminology or letting the Agent fix code, ask the junior to predict: what happens if the user clicks again? How many records should be in the database? Where would you look to confirm? After the prediction is clear, introduce idempotency — the principle that processing the same business request repeatedly produces no extra effect.

Then reproduce the scenario in an isolated environment and let the junior compare prediction with actual result. Discrepancies are the most valuable learning moments. The test may reveal a system defect or expose the junior's misconception that timeout equals failure.

AI can help design failure scenarios, explain logs, and generate tests. But the mentor should first hear the junior's own prediction, then hear them explain the actual outcome. If the answer is presented upfront, it's easy to nod and say "understood" without discovering what was misunderstood.

Change a Condition, See If Understanding Holds

Memorizing "duplicate requests need idempotency keys" is easy. Change the conditions: process restart, batch number change, or the same file belonging to another customer. Can the junior still judge correctly?

Asking AI for the new answer is fine; the key is whether the junior can evaluate if that answer applies. If they can't articulate why, walk through the code together: where is the batch identifier generated? Where are records stored? Which state survives a process restart? Grounding questions in concrete code paths gives something tangible to analyze.

Reading code remains valuable. Instead of requiring a junior to read an entire open-source project first, start from a specific execution path. Books like Code Complete , Refactoring , and Clean Architecture can be read alongside the immediate problem, not just kept as a mandatory reading list.

Exercise Table: What to Observe and What to Check Next

Reproduce a duplicate import — Observe: can they form a hypothesis and locate evidence of write vs. response? Next: change the failure condition, can they still judge?

Review a piece of AI-generated code — Observe: can they use counterexamples or tests to show problems? Next: beyond naming and formatting, did they check business consequences?

Explain and adjust a design — Observe: can they state constraints and trade-offs, and revise when conditions change? Next: can actual validation support their explanation?

Track an exception to closure — Observe: can they distinguish temporary recovery from root-cause fix? Next: how much help will they need next time a similar situation arises?

The purpose of recording is to decide the next task and the level of support needed, not to turn the learning process into another scoring competition.

Learning in Real Delivery Is Harder to Schedule Than Extra Homework

The biggest practical resistance isn't unwilling juniors — it's that experienced engineers using AI can often deliver faster in the short term. If management only accepts current sprint velocity and doesn't allocate mentor time, mentoring becomes an after-hours personal obligation. Such arrangements don't sustain and can't be fixed by merely "valuing talent."

Start with a few small, well-bounded real tasks. Schedule prediction, implementation, review, and feedback together. The mentor checks key judgments without hovering over every step; the junior organizes encountered problems and verification evidence to reduce collaboration overhead.

These time investments must be agreed with stakeholders upfront: which tasks can run slower, how the mentor's original work is covered. If the schedule doesn't include this investment, mentoring is usually the first thing dropped when things get busy.

Let Feedback Follow Results

Code merge shouldn't be the end of learning. Post-release rework, user misunderstandings, and whether predicted risks materialized all become inputs for the next discussion cycle.

Google SRE advocates blameless postmortems, focusing on how the problem occurred and how to reduce recurrence. The same applies to mentoring juniors. If saying "I'm not sure" invites criticism, next time the junior may just bring a more convincing AI-generated report. Surfacing doubts is what creates the opportunity to clarify together.

Over several tasks, watch for whether the junior asks better questions independently, seeks help proactively when needed, and adapts designs to new conditions. Eloquence, code volume, and prompt length alone cannot answer these questions.

How well these approaches work still needs ongoing exploration in practice. But I don't want to assume that stronger tools automatically teach judgment. People willing to mentor also need time to mentor; how that work is recognized in the team deserves continued discussion.

References

Google SRE Book, Postmortem Culture: Learning from Failure: https://sre.google/sre-book/postmortem-culture/