翻訳待ち：How Juniors learn the trade when an agent writes the code

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

How juniors learn the trade when an agent writes the code Aug 21, 2026 In my last post I described how we structure delivery so that human judgement is spent where it matters, and I left one problem open: that model assumes seasoned judgement at the gates, and I could not say how a junior grows it inside a system that shields them from the grind that used to build it. I still would not call it solved. AI-native is a young way of working, and, as far as I know, nobody has grown a whole cohort of engineers inside it yet. But I am confident in the approach, because most of it was already there in how juniors learnt the craft before any of this existed. This is where my thinking stands today. The mechanic is older than it looks Juniors never learnt the trade by inventing everything from scratch. For the last fifteen years a large part of the job was reading: Stack Overflow, a library's source, a colleague's pull request. The snippet was rarely the hard part. The hard part was deciding whether it was correct for the problem actually in front of you, and what it would cost you in six months. How much a junior learnt from that depended on how much they put in. Copy, paste, run, move on taught nothing; the code worked, or it did not, and the engineer was no wiser. Design was the same story. Most juniors mimicked whatever the codebase already did. The ones who grew asked why the pattern had been chosen in the first place, and noticed when it did not fit their case. An AI agent is the same mechanic with the friction removed. Pressing enter until the tests go green is copy-paste without reading, at a hundred times the volume. Accepting whatever structure the agent proposes is mimicking the codebase without asking why, except that now the agent does the mimicking too. The result is familiar: working code, and an engineer no wiser for it. I have watched it happen with juniors I coached through the arrival of these tools. One junior turned in an IPv4 and IPv6 parser with subnet and mask matching, several hundred lines, neat and complete. They could walk me through parts of it, but not why we were writing our own parser at all, nor what most of those lines were for. It was plainly agent work. A few questions in, they saw it themselves: the understanding was too shallow to justify the implementation, and once we read it together, it had bugs. That conversation, and what came out of it, is the loop later in this post, in miniature. What has changed is that the mistakes got quieter. A Stack Overflow snippet that did not fit your problem usually failed loudly. An agent's implementation that does not fit your problem passes every test and is wrong in the one edge case that matters. The reading was always the job. Writing the code by hand used to force a minimum of it on you; now nothing does, and it is the one part of the job the agent cannot do for you: it can review the code, it cannot understand it on your behalf. There is one thing reading never gave a junior. Writing the code yourself meant being wrong in public, quickly: the build broke, the test failed, the design collapsed under the first real use, and you learnt what your mental model had missed. Agent code that passes every test carries no such signal, so any answer to how juniors learn now has to say where that feedback comes from. Mine is in the human loop below. It is not only a junior problem I should say where my evidence comes from. I have coached juniors through every generation of these tools since the first Copilot, and experienced engineers into working this way before the structure in the previous post existed. The pattern was clearest in the experienced engineers. Engineers with a decade or more of reading code behind them, who would never have approved a colleague's PR unread, quietly stopped reading the agent's. The output looked right and the tests were green, so the habit went. Some of them stopped one step further upstream and let the agent make the design call as well, then defended it in review without being able to say why it was the right one. One of the most experienced voices in our community says he does not read the agent's code at all. Uncle Bob Martin, who started coding in the late sixties, wrote recently that not reading is the only way to take advantage of the productivity, and that he surrounds his agents with constraints instead. I read that as an invoice, not a permission slip. He stopped reading and paid for it with a gauntlet that took him sixty years of judgement to know how to build. The engineers I watched stop reading did not pay; they built nothing in its place. Those are people with the muscle. A junior who has never built it will not find the pull easier to resist, and cannot pay the invoice either, because the constraints are the judgement and they do not have it yet. So the question in this post is not really "how do juniors learn" but "how does anyone keep thinking when the tool makes not thinking so comfortable", and juniors are simply the case with no muscle to fall back on. Watching experienced engineers stop reading is what led to the delivery structure in the previous post: it is my answer for the team as a whole, and it exists because attention alone did not hold. What follows is the part specific to people who are still building the judgement that structure relies on. The real upside is the pair I have spent a lot of words on the risk; the gain is real too. Juniors never lacked code to read. What they lacked was someone to read it with: a senior who could take any part of the system and explain what a pattern is for, why this design fits its constraints, and what would break if you changed it. Most juniors got a few hours of that a week, if they were lucky, from someone with their own deadlines. The rest of the time they were on their own with a search engine, which only helps if you already understand enough to know what you are looking at. That is a large part of what the agent now provides, on demand. A junior can point it at any module and ask why it is shaped that way, or take the implementation it has just produced and ask what the alternatives were and what each would have cost. Asking an agent to justify its own decision is the wrong question: it will rationalise fluently and the junior will learn to accept the rationalisation. Asking for the alternatives, or asking a fresh agent to pick the implementation apart, produces something worth disagreeing with. The same goes for adversarial review: an agent asked to find problems will always find some, and deciding which of them matter is the reader's job, not the agent's. Used like that, the tool is a patient pair, and a junior who works with it that way can see more explained patterns in a month than many of us did in our first year. It does not replace the senior, for two reasons. The agent can explain what a design does and why it is sound in general. It cannot explain why this team chose it, or which constraint forced the odd-looking decision, unless that was written down somewhere it can read, and in most codebases it was not. And the agent will explain anything. A junior does not yet know which explanations to trust, or when a confident answer is wrong for their context. Judging that is still the senior's job, and it has not moved at all. So what does the senior's part actually look like? The human loop The loop is the one I ran with juniors long before agents, with one adjustment. Juniors own tickets of growing complexity, and a senior keeps asking them the same question about the work: what did you decide, and what else did you consider? Sometimes that is a live coaching conversation. Most of the time it is a comment on a pull request, which means seniors have to review juniors' PRs themselves and not hand that to an agent too. That is where the time the pipeline saves should go: the grind that used to fill a senior's review queue is handled by the gates, and the attention freed is spent here. It is not a return to the old convention that review means another engineer reading your code for you; that does not scale to the volume agents produce. Nobody can read everything; you can read yours. A gauntlet of tests and constraints defends the codebase, but it says nothing about whether the right problem was solved, and it does nothing for the engineer. So my position from the previous post stands: on a product where failures are costly, a change on a critical path is read by the engineer who ships it, because that reading, with the validation behind it, is what ownership means. The senior's review of a junior's PR is a different thing: the junior's own reading and the gates are the quality control, and the senior's pass is coaching. That is why it can taper as the junior's judgement shows, and why it follows risk rather than covering everything: a change on a payment path gets read closely for a long time; a copy change in an admin screen does not. Knowing which change warrants a second pair of eyes, and being able to call on a colleague for it, is a skill juniors should be given explicitly, not one they should have to earn. Growing complexity means more ownership, not bigger tickets: a whole customer problem instead of a slice of one, more of the design decisions left to them, and eventually a problem the codebase has not solved before, where there is nothing to mimic, such as a new piece of tooling or, later and with supervision, a buy-or-build call. Alongside that, some problems a junior should implement by hand, with the agents demoted to review and test, because being wrong yourself is the lesson, and the demo and live validation from the previous post are where a junior watches their own design meet a real user rather than a green test. That is the failure signal reading cannot provide. The adjustment is that the work is still theirs even if an agent wrote the implementation. The agent is a tool. How it was used and what it produced belong to the engineer who shipped it, at every level of seniority, and that question in review is where the ownership shows. Sometimes the honest answer is "I don't know". That is the most valuable moment in the whole loop: the junior has just found the edge of their understanding, with a more senior peer right there, or one reply away, to work through it with them. The agent made the question askable at any hour. The senior is still the one who tells you whether you asked the right one. Both of the agent's limits above come back to the same gap: neither the agent's coaching nor the senior's is better than the recorded intent they can read. Which brings me to the one skill I think has to be taught on purpose. Recording the why Writing down why a decision was taken is not a new idea. Architecture decision records, commit messages that explain the reasoning: the advice has been around for twenty years and most teams have ignored it for twenty years. Two things have changed. Agents do not do it unprompted; they are excellent at describing what was done, and almost never capture why this approach and not the obvious alternative, or what was tried and abandoned. And humans do it less than they used to, because the moment of decision is exactly the moment they delegated to the agent. Agents will write a why if asked, but it will be a plausible why, not the real one, unless the engineer supplies it. It is also more achievable than it was, for two reasons. An engineer's day has a fixed length, and the hours that used to go into typing the implementation now go upstream, into the thinking, which is precisely the part the why records; there is finally time for it. And, as with everything else in the previous post, it should not rely on discipline: a PR that does not carry its reasoning does not merge, and a review agent checks that the reasoning is present and matches the diff. That is why I would have juniors practise it deliberate [truncated for AI cost control]