# The cost of a junior waiting for a senior, and what an LLM can — and can't — do about it. > A junior's 30-minute change ties up six hours of a senior's time. The LLM isn't a mentor, but it can be the assistant that frees senior time for actual mentorship. Published August 29, 2026 by Muhammet Şafak (https://www.muhammetsafak.com.tr) Canonical URL: https://commitbrief.com/blog/junior-senior-review-loop/ Tags: mentorship, junior, team --- Early in my career I asked a senior engineer to review a 30-line change. He got to it six hours later, left two comments, and one of them was "fix the import order." I remember the exact mix of feelings: gratitude that he took the time, embarrassment that I'd needed his attention for something that obvious, and a quiet frustration that the actual interesting question — whether my approach was right — had to wait another day because of how the review queue had shaped up. That moment is a microcosm of a problem every team with both juniors and seniors deals with. The junior's fear of "wasting" the senior's time creates a hesitation to ask for review at all, which delays the work. The senior, meanwhile, spends a non-trivial share of their day on comments that don't require their seniority. Both sides leave the interaction slightly worse off than they should be. An LLM doesn't solve this. It changes the shape of the problem in a way that lets both sides spend their attention better. ## What an LLM can do for the junior The junior can run `commitbrief --staged` before they ever open the PR. The mechanical findings — the import order, the missing error check, the inconsistent logging pattern — come back in seconds. The junior addresses them privately, on their own machine, and submits a PR that doesn't have those issues anymore. That's the surface-level value. The deeper value is what it does to the junior's experience of review. They're no longer worried that the senior will turn around for something basic, because the basic things are gone before the PR opens. They can ask for review with confidence, knowing that the conversation is going to be about substance, not about whether they remembered to run `gofmt`. I've watched juniors who started using this workflow visibly relax about asking for code review. The transformation is psychological as much as technical. The fear of "wasting" senior time was always disproportionate to the actual cost, but it shaped behavior. Removing the fear changes how often juniors ask, what they ask about, and how much they learn from each interaction. ## What an LLM can do for the senior The senior gets PRs that don't have the obvious problems. Their review time is spent on the questions only they can answer: whether the approach is right, whether the abstraction is in the right place, whether the implications of a change have been thought through. I would frame this not as "the senior does less work" but as "the senior does higher-leverage work." The time on the PR stays roughly the same. The questions they ask are deeper. The conversation that follows is more substantive. And — crucially — the junior is learning something from those conversations that they couldn't have learned from a mechanical finding. A senior who used to write "fix the import order" now writes "you used `context.Background()` here instead of the incoming `context.Context` — did you think through the cancellation behavior?" The first comment teaches nothing. The second comment teaches a concept the junior will carry with them for years. ## What an LLM cannot do for the relationship I want to spend a paragraph being honest about the limits, because this is exactly the place where the "LLM as replacement" narrative goes wrong. An LLM cannot mentor. It can flag a finding, even explain a finding, but it cannot decide _which_ finding to lead with based on what would best serve this particular junior at this particular stage of their development. It cannot notice that a junior has now hit the same conceptual misunderstanding three times in different forms and that what they actually need is a 30-minute whiteboard conversation. It cannot judge when "good enough" is genuinely good enough versus when the junior would benefit from being pushed harder on this one. These are human-mentor jobs. The senior is still on the hook for them. The LLM doesn't make these jobs go away; it makes them more visible by clearing the noise around them. A senior who was previously spending half their review time on mechanical comments will, after the team adopts a pre-PR LLM review pattern, suddenly have time and headspace for the actual mentoring. The mentoring may not have been happening before because the senior's attention was being consumed by the small stuff. ## The terminal renderer as a teaching surface A small product detail that has mattered more than I expected: CommitBrief's default terminal renderer outputs findings as colored markdown with severity tags, file links, and short explanations. It's intentionally a little verbose by default. I made that choice with juniors in mind. The terminal output is structured to be _read_, not just glanced at. A finding shows up with its severity in color, a one-line summary, the file and line, and a couple of sentences of explanation. A junior reading their own pre-PR review is getting a mini-lesson on each finding, not just a list of things to fix. Pairing this with `--verbose` shows the cost and provider information at the bottom — useful for a junior to develop an intuition for what's expensive and what isn't. A small thing, but the kind of small thing that adds up across a career. ## A workflow recommendation for teams If you're a tech lead with juniors on your team, the highest-leverage thing you can do this quarter is: 1. Write a `COMMITBRIEF.md` that captures the things you find yourself repeatedly commenting on. 2. Ask the juniors to run `commitbrief --staged` before opening any PR. 3. Notice what changes in your review comments. The ones that stop happening are the ones the LLM has absorbed. The ones that remain are the ones that needed your seniority. This is the same workflow [the pre-push post](/blog/review-before-the-push) laid out, applied with intention to the junior-senior relationship. And it's the same pattern that helps async teams in [the timezone-lag post](/blog/cross-timezone-review-lag) — by removing the mechanical work from the critical path so the higher-value conversation can happen faster. The next post turns to architecture: why CommitBrief talks to four different LLM providers, and why a single-provider tool is making a reliability trade-off whether it acknowledges that or not.