Code review is where senior engineers spend a significant portion of their time in most organizations. It's also where the clearest record of junior engineer skill gaps accumulates — not in survey responses, not in performance reviews, but in the actual comments left on actual pull requests, attached to specific code, from specific engineers, in specific domains.
Most L&D teams never see any of this data. It lives in GitHub or GitLab, behind technical tooling that the learning function rarely accesses. The engineering team sees it — individual engineers receive feedback, senior reviewers have a general sense of where people are struggling — but the pattern-level view rarely gets synthesized, and it almost never reaches the people responsible for planning training investments.
What Review Comments Actually Record
A pull request review comment is a specific claim about a specific piece of code. When a reviewer writes "this doesn't handle the case where the lock acquisition fails," that comment records two things simultaneously: a gap in the submitted code, and an implicit claim about what the author didn't consider. When the same category of comment — concurrency handling, error propagation, resource cleanup, security input validation — appears on multiple PRs from the same engineer across different contexts, it's no longer individual feedback. It's a pattern.
The pattern is meaningful because it's behavioral. The engineer submitted code that reflected their mental model at the time. The model didn't include the edge case the reviewer flagged. That's a competency gap — not a character flaw, not a motivation issue, but a specific technical knowledge gap that structured learning can address.
At scale, these patterns become a team-level competency map. If ten engineers across three squads are receiving consistent feedback about error handling in async contexts, you have a systemic gap in asynchronous programming patterns. If review comments about database query performance are concentrated in one service area where a new team recently took ownership, you have an onboarding gap in query optimization for that specific data layer.
Categories of Signals in Review Data
PR review patterns tend to cluster into a few categories that have direct L&D implications:
Domain-specific gaps. The same category of technical feedback appearing across multiple PRs from the same engineer. Security edge cases, concurrency primitives, specific API contracts, infrastructure-specific patterns. These map to discrete learning objectives that can be addressed with targeted content or structured pairing.
Architecture understanding gaps. Comments that reference system-level context the author didn't account for — "this will cause a thundering herd problem against the rate limiter," "this call pattern will break if the downstream service is in the second availability zone." These indicate that the engineer's mental model of the broader system is incomplete. The gap isn't in a skill per se; it's in architectural exposure. The learning path here is different: less structured course content, more guided exploration of the system they're operating in.
Review thoroughness patterns in senior engineers. When senior engineers are leaving unusually large numbers of detailed review comments, that's a signal too — just in a different direction. It might indicate review bottleneck, which is a bus factor risk. It might indicate that juniors in that area are further behind than assumed. Both of these have L&D implications.
Repeated feedback that doesn't stick. The most actionable signal is when a reviewer leaves the same category of feedback on multiple PRs from the same engineer, separated by weeks. This suggests the engineer received the feedback but the learning didn't transfer. That's not a motivation problem in most cases — it's a signal that the feedback mechanism alone isn't sufficient for that particular gap, and a different learning modality may be needed.
A Concrete Pattern: Security Review at a Growing Platform Team
An engineering team of about 55 people building a developer tools platform noticed a pattern when they started analyzing review comment data more systematically. A subset of engineers — largely those who had joined in the past eighteen months — were receiving consistent review feedback about input validation and authentication edge cases in API endpoint code. The feedback came from multiple reviewers, across multiple PRs, and the individual engineers were responsive to it — they fixed the flagged issues in each PR. But the gaps reappeared in the next PR in a different context.
The pattern indicated something specific: these engineers understood the feedback they received on individual PRs, but hadn't internalized the underlying mental model of where authentication and validation failures occur in their API architecture. Each piece of feedback was local. The mental model transfer wasn't happening from isolated reviews.
The team ran a targeted internal session — not a general "security fundamentals" course, but a structured walkthrough of how their specific API gateway and auth service interact, what the actual attack surface looks like in their system, and what categories of input validation matter for their specific data types. The session was three hours. The PR review feedback patterns shifted noticeably over the following two months.
The point isn't that the session was magical. It's that the learning investment was pointed at the right gap, in the right way, because the PR data had made the gap specific and visible.
Why This Data Doesn't Usually Reach L&D
The gap between this data existing and it being used for L&D planning is mostly organizational. Engineering reviews PR data in the context of individual code quality and team process. L&D plans training based on survey data and leadership priorities. These two workflows rarely intersect.
There's also a legitimate privacy concern here that deserves direct acknowledgment. PR review data is identifiable — it's tied to specific engineers. Using it to build competency models requires a clear, explicit, and principled approach to what gets aggregated, what stays individual, and how the data is used. We'll address this in more depth in a separate post on responsible data usage. The short version: the appropriate framing is organizational skill gap identification and directed learning investment, not individual performance ranking or surveillance. Engineers are more comfortable with their workflow data being used to improve their learning paths when they understand what's being collected and why.
Connecting Review Signal to Learning Paths
The practical application isn't to build a surveillance dashboard of review comments. It's to identify the categories of feedback that appear most frequently across your team, map them to learnable competency clusters, and use that mapping to prioritize L&D investment.
The questions you're trying to answer are organizational: What skill gaps are showing up most often in review? In which service areas are the patterns most concentrated? Are there gaps appearing across multiple squads that suggest a systemic training need, versus gaps concentrated in one team that suggest onboarding or team-specific context?
When the answers to those questions come from behavioral data rather than surveys, the training priorities they produce have something that survey-derived priorities rarely have: direct traceability to actual code quality outcomes. An L&D manager who can walk into a budget conversation and say "we've identified a gap in observability patterns that appears in 23% of backend PRs over the past quarter, and here's the targeted learning path we're proposing to address it" is in a fundamentally different position than one proposing a training program based on self-reported low-confidence ratings.
Your senior engineers are already doing the work of identifying skill gaps — in every review comment they write. The question is whether you're reading what they've written at the scale and resolution needed to act on it.
