Who do I talk to about this part of the codebase, without maintaining an org chart?
Infer it from the work instead of writing it down. The people who recently changed, reviewed and discussed a part of the code are the people who know it. CODEOWNERS and git blame give a first guess, but they go stale or point at the wrong person. A context engine reads PRs, reviews, tickets and Slack together and names the current expert with links.
Work out who to talk to about the codebase from the work itself, not from a list someone has to keep current. The engineers who recently changed a module, reviewed changes to it, and answered questions about it in Slack or a ticket are the ones who know it. Expertise inference is the practice of naming those people from that activity, with recent work weighted above old work. Ownership files and git history are useful inputs. On their own, each one answers a narrower question than the one you asked.
People are still the first place developers look. In the 2026 Stack Overflow survey, the top sources for work answers were "the people you work with (72%), the code (63%), and documentation (60%)" (Stack Overflow, October 2026). The same write-up notes that senior developers "spend half their day answering DMs." Finding the right person fast saves time on both ends.
What CODEOWNERS tells you, and where it stops#
A CODEOWNERS file is a list in the repository that maps file paths to the people or teams who own them. On GitHub, "code owners are automatically requested for review when someone opens a pull request that modifies code that they own" (GitHub docs). GitLab describes the same feature as a way to "define who has expertise for specific parts of your project's codebase" (GitLab docs).
That is a good start, and it is also a small org chart. Someone has to edit it when people move teams or leave. GitHub's rules show how it fails quietly. Owners need explicit write access to the repository, and if a listed user or team lacks it, no owner is assigned. A line with invalid syntax is skipped, and a file over 3 MB is not loaded at all. The file tells you who is supposed to approve changes. It does not tell you who answered the last three questions about the retry logic, or who rewrote it in March.
What git blame and git shortlog miss#
Git history is accurate, but it answers a different question. git blame is the command that shows, for each line, the last commit that touched it. The docs say it "annotates each line in the given file with information from the revision which last modified the line" (git-blame). The last person to touch a line may have renamed a variable or run a formatter. Git has options to soften this. -w ignores whitespace, -M and -C follow moved and copied lines, and --ignore-rev skips commits such as a mass reformat. You have to know to use them, and someone has to keep the ignore list.
git shortlog -ns ranks people by commit count (git-shortlog). Counts favor people who commit often in small pieces, and bot accounts can top the list. Review work is mostly invisible. The --group=trailer:reviewed-by option counts reviewers, but only if your team writes that trailer into commit messages. Commits without it are not counted. Most teams review in pull requests, so that signal lives on GitHub or GitLab.
AI-written code makes authorship weaker still. A June 2026 preprint notes that "software engineering has long inferred where a system's knowledge resides from who authored its code." It argues that AI code generation breaks that link. Any replacement, it says, "must be grounded in evidence of comprehension rather than authorship" (Wheeler, arXiv, 2026). For example, if an agent wrote 80 lines and an engineer accepted them, blame names someone who may never have read them closely.
Inferring who knows a module from PRs, reviews, tickets and Slack#
Better answers come from combining signals, each weighted by how recent it is. Here is what each one tells you, and where it misleads.
| Signal | What it tells you | Where it misleads |
|---|---|---|
| Merged PRs in the area | Who changed the behavior | Big refactors and renames look like expertise |
| Reviews | Who checks changes there, even with few commits | Rubber-stamp approvals count the same as close reads |
| Tickets | Who fixed and triaged bugs in that component | Tickets filed against the wrong component |
| Slack or Teams answers | Who people already ask, and who replies | Loud people rank above quiet experts |
| Recency | Whether the knowledge is still current | Cutting old work off entirely hides the person who built it |
This is how we built the expert graph inside Unblocked. It is drawn "primarily from pull request activity and commit history," and review activity counts alongside authorship. Both signals decay over time. Contributions cluster into topic areas, "so expertise attaches to concepts, not just file paths" (inside the Unblocked context engine). A simplified version built only on git and PR data is open source if you want to run it on your own repos (engineering-social-graph). For how this people layer differs from a knowledge graph of code entities, see knowledge graphs for engineering teams.
Asking the question where you already work#
With that graph in place, nobody maintains a list. You ask. Unblocked's own docs give example questions such as "Who knows the most about 'FooService'?" and "Who do I talk to about code signing?" (Unblocked docs). Answers link the sources they used (cited sources), so you can check why someone was named before you send a DM. It works from Slack, the web, or a coding agent over MCP: Claude Code, Cursor, or GitHub Copilot in VS Code and JetBrains. With Data Shield turned on for a source, answers only include material from it that the asker is authorized to see.
Often the better outcome is not needing the person at all. If the expert explained the decision in a PR thread last spring, the answer can cite that thread directly. That is the case covered in why was this built this way. Olli Draese, Technical Architect at Cribl, put it this way: "Unblocked is our number one tool to find information we should know but don't."
When a CODEOWNERS file is enough#
You do not need inference everywhere. A small team with a few repos and low turnover can keep CODEOWNERS accurate with a quarterly pass, and the file still earns its place for review routing. Keep it either way. The signal to add inference is when the answers start to drift: new hires asking in the wrong channel, review requests going to someone who moved teams, or one senior engineer fielding every question about a service. That last one is also your bus-factor warning. New engineers feel it first, which is the gap covered in our guide to developer onboarding tools.
