# Sourcing a Deep-Specialty Engineer From Public Code

*You will turn a rare capability into a ranked shortlist of engineers who provably authored the hard subsystem, each row backed by named repos, commits, and pull requests.*

- Canonical URL: https://www.refolk.ai/guides/sourcing-deep-specialty-engineer-public-code
- Pillar: Engineering and open source
- Format: Playbook
- Published: 2026-10-12
- Last reviewed: 2026-10-12
- Reading time: 16 min
- Keywords: sourcing niche software engineers, find engineers by github contributions, verify individual contribution github, source engineers by capability not keyword, boolean search for rare developers

## Key takeaways

- In Refolk's index, a Rust storage-engine capability returns one person in the United States and zero in Germany, while the bare keyword returns thousands - roughly a 99%+ collapse that only code-reading can resolve.
- Across 2,496 GitHub projects, more than 88% have fewer than 16 core developers, so enumerating named maintainers and CODEOWNERS of a few canonical repos bounds the pool better than any contributor graph.
- Git attribution is spoofable because it keys on commit email, so require GPG-verified commits before you trust a name tied to a diff.
- 29 AI coding tools leave machine-readable traces and fingerprint models hit 97.2% F1, which makes discounting AI-assisted commits a scripted filter step rather than a judgment call.
- Ranking on merged-PR counts compounds a documented bias: women are 5.2% of four million GitHub users and face a 4.1% lower acceptance chance when their gender is visible, so weight authored code, not acceptance.
- A thin public pool is not a thin talent pool - finance, defence, and health engineers leave no public trace, so a low single-digit result means state the limit and widen outreach.

You have a rare technical requirement - a storage-engine, consensus, compiler, or GPU-kernel specialist - and you need the handful of engineers who have provably built it, not the thousands who list the keyword. This playbook is for engineering managers, technical founders, developer-relations leads, and technical sourcers who are willing to read code to confirm authorship. It takes you from a plain-language capability to a ranked shortlist where every row is backed by the specific repositories, commits, and pull requests that prove the person did the hard part.

Generic sourcing playbooks start from a role brief or a known repo's contributor list and stop at a ranked table. This one starts from a capability that resists keyword matching, carries the engineering-manager lens of reading the actual code, and treats contributor-list membership and AI-assisted commits as overstatements to be discounted. It also tells you when the provable pool is simply too small to hire from public evidence alone.

## Why keyword search fails for a rare capability

A rare capability lives in a few files owned by a few people, so any honest filter must end at code, not profiles. The gap between a keyword match and a provable author is not a rounding error; it is roughly 99% of the result set.

In Refolk's index, a strict skill-plus-keyword intersection for a Rust storage engine returns a single person in the United States and zero in Germany. An LLVM compiler intersection returns zero in the United States, and a CUDA GPU-kernel intersection returns three. The same bare keywords return thousands of profiles. The mechanism is simple: "distributed systems" or "compilers" appears on resumes for proximity, teamwork, and aspiration, while the compaction loop in a log-structured merge tree was written by one or two named people.

**0-3 - People returned by strict skill-plus-keyword capability intersections per market**

In Refolk's index, Rust storage engine (US) returned 1, LLVM compiler (US) returned 0, CUDA GPU kernel (US) returned 3.

That collapse is the entire justification for code-reading. When a filter narrows thousands to single digits, you cannot ship the result on keyword trust; each surviving name has to be confirmed against the diff that proves it. The rest of this guide is how you earn that confirmation and how you avoid the traps that fake it.

> **Rule:** End at code, not at a profile
>
> A profile keyword is a claim. A blame line on the hard path is evidence. If you cannot trace a candidate to a commit that implements the difficult subsystem, you have not sourced them, you have found them.

## The four artifacts that separate an author from a contributor

Four retrievable layers tell you who authored a subsystem versus who merely appears in its contributor list. Each answers a different question, and each lies in a specific way if you read it naively.

The layers, from most to least granular:

- **Line-level authorship.** `git blame` on a file reveals each line's originating commit, author, date, and line number, so you can trace who wrote each modification. For fair attribution, run it move- and whitespace-robust: `git blame -w -M -C -C --line-porcelain`.
- **Directory and subsystem history.** `git log <pathname>` shows only the revisions that touched that file or subdirectory, and the `-S` "pickaxe" option shows only commits that changed the number of occurrences of a given string - ideal for tracing a named function or type.
- **PR-merge and review role.** The GitHub CLI supports qualifiers such as `is:merged author:monalisa` and `--reviewed-by` to filter pull requests by who wrote or who reviewed them.
- **Code ownership.** `CODEOWNERS` names the individuals responsible for specific files or directories, who are auto-requested to review changes there. There is no single REST endpoint for code owners, so you cross-reference requested reviewers against the CODEOWNERS file via the Get Contents API.

#### The authorship evidence stack

1. **Line-level blame** - Who wrote each line of the hard file, robust to reformatting
2. **Subsystem log and pickaxe** - Which commits touched the path or the named symbol
3. **PR author and reviewer role** - Who authored versus who merely reviewed the merge
4. **CODEOWNERS and maintainers** - Who the project formally holds responsible for the directory

*Read from the top layer down; each narrows a contributor list toward a provable author.*

What each layer proves and how it lies: blame proves line authorship but reassigns every line to whoever last reformatted the file; the subsystem log proves a commit touched the path but not that it touched the hard logic; PR authorship proves who opened the merge but a merged-PR count encodes an acceptance bias; CODEOWNERS proves formal responsibility but names can be stale. You use all four because no single one survives on its own.

## Mapping a plain-language capability to repos and paths

Translate the capability into its canonical open-source implementations and the specific subdirectory that embodies the hard part, then read that path's history. This is the step most sourcers skip, and it is the one that makes everything downstream possible.

Deep specialties cluster around a small number of reference repos. Storage engines: RocksDB is a high-performance embeddable engine, a 2012 Facebook fork of LevelDB, built on log-structured merge trees and optimised for flash - the hard subsystem is compaction and the write path. Consensus: the Raft ecosystem, including etcd/raft, TiKV, and lol-core, a Raft implementation in Rust, where the hard part is leader election and log replication. Compilers: LLVM, a toolchain built around a language-independent intermediate representation optimised across passes, where the hard part is a pass or a backend target. GPU kernels: Triton, a language and compiler for custom deep-learning primitives, where the hard part is a backend.

| Specialty | Canonical repo | Hard subsystem |
|---|---|---|
| Storage engine | RocksDB | compaction / write path |
| Consensus | raft / lol-core | leader election, log replication |
| Compiler | LLVM | IR passes / backend target |
| GPU kernel | Triton | NVIDIA / AMD backend |

Once you are inside the repo, narrow to the owned module. Triton's in-tree modules name individual owners - for example Lei Zhang owns the AMD backend and Keren Zhou owns the Interpreter and Profiler. A capability that reads as "GPU kernel engineer" becomes a named person the moment you read the governance file. That is the whole move: a vague skill resolves to a small set of owners of a specific directory.

> **Tip:** Read the governance doc first
>
> Before you run a single git command, open CONTRIBUTING.md, the Maintainers file, and CODEOWNERS. On well-governed projects these name individual owners of exactly the subsystem you care about, and they save you hours of blame.

## Bounding the pool before you reach out

The provable pool is bounded by governance, not popularity, and it is smaller than any contributor graph suggests. No one has published a definitive count per specialty, so the honest method is to count the core team and intersect across the canonical repos.

The literature is consistent on how small core teams are. Across 2,496 GitHub projects, more than 88% have fewer than 16 core developers, and roughly 80% of contributions come from 20% of active developers. Open collaboration more broadly follows the "1-9-90 rule": only 1% actively produce content, 9% are somewhat active, and 90% are passive. So the enumerable universe for a deep specialty is the named module and core maintainers of three to six canonical repos, intersected - typically a double-digit list at most, and often lower.

| Metric | Value | Source |
|---|---|---|
| Projects with fewer than 16 core devs | 88%+ | Coelho / Joblin core-developer study |
| Contribution share from top 20% | ~80% | same study |
| Women among 4M GitHub users | 5.2% | large-scale GitHub gender study |

Treat the CODEOWNERS and maintainers list as your upper bound, then expect the verified-author pool to be smaller still once you discount impersonation and AI commits. Sizing the pool this way, before outreach, prevents two mistakes: pretending the market is large because the keyword count is large, and abandoning the search because the keyword count is small when the governance list actually holds the right names.

I ran this search: `Named module maintainers or CODEOWNERS of a distributed storage engine, based in Germany or remote-friendly.` - [see the full result list](https://www.refolk.ai/s/dxcn2qp17q).

*Returns the people a project formally holds responsible for the storage subsystem, filtered to a market, so you start from owners rather than a contributor graph.*

When you want this bounding step to run across the public GitHub graph and professional profiles at once, rather than cloning each repo by hand, [Refolk](/) resolves a capability phrase into the small owner set directly, which is the part of the job that is slow to do manually.

## The procedure, start to finish

Run these seven steps in order. The timings assume one specialty and three to six canonical repos; a broader brief multiplies the authorship-pull and code-reading stages.

#### Capability to ranked, evidence-backed shortlist

1. **Translate capability to repos and paths** - Name the three to six reference implementations and the specific subsystem directory that proves the capability, such as RocksDB compaction, an LLVM pass, or a Triton backend. Done when you hold a list of repo-plus-path targets, not a keyword. (~2-4 hrs, sourcer/EM)
2. **Bound the pool before outreach** - Read the Maintainers file, CODEOWNERS, and the governance doc of each canonical repo to list named owners; expect fewer than sixteen core people per repo. Done when the universe is sized by governance, not a contributor count. (~1-2 hrs, sourcer)
3. **Pull per-path authorship** - Run git log on the path, git blame -w -M -C, and the -S pickaxe on the identifying symbols; on GitHub use gh search prs with author: and --reviewed-by. Done when you have ranked authors per subsystem with commit evidence. (~2-3 hrs, sourcer)
4. **Verify identity and discount impersonation** - Prefer GPG-verified commits, because email-based attribution is spoofable and a push can contain commits the pusher did not write. Done when each candidate is tied to a real, verified account. (~1 hr, sourcer/EM)
5. **Discount AI-assisted and superficial commits** - Strip bot logins and Co-authored-by trailer commits, flag large single-commit files and style mismatches, and keep only incremental human authorship. Done when you hold a cleaned evidence set. (~2-3 hrs, EM)
6. **Read the actual code** - Open the diffs that implement the difficult logic and confirm the person authored the hard part, not tests, docs, or formatting. Done when you have a yes or no authorship verdict per candidate. (~3-6 hrs, EM)
7. **Rank and flag pool-too-small** - Produce the ranked shortlist; if verified authors number in low single digits, state plainly that public evidence alone cannot fill the role and widen to adjacent repos or private-signal outreach. Done when the list is ranked and its limit is declared. (~1 hr, EM)

One sequencing disagreement is worth naming. Some practitioners verify identity (step four) before pulling authorship (step three): the git-community approach treats attribution as a prerequisite, while blame-first guides reverse it. Either order works; if you expect impersonation in your target repos, verify first so you do not waste blame time on spoofed accounts.

Here are the exact commands for the authorship-pull step, ready to adapt to your path and symbol:

**Per-path authorship pull**

```
# Who touched the hard subsystem, and in which commits
git log --follow -- src/compaction/

# Blame the hard file, robust to whitespace and moved/copied code
git blame -w -M -C -C --line-porcelain src/compaction/compaction_job.cc

# Find every commit that added or removed a specific symbol
git log -S "PickCompaction" --oneline -- src/compaction/

# On GitHub: PRs this person authored and that merged, plus ones they reviewed
gh search prs --repo facebook/rocksdb is:merged author:LOGIN
gh search prs --repo facebook/rocksdb --reviewed-by LOGIN
```

*Replace the path and the symbol with your subsystem directory and the function or type that names the hard part.*

## How this goes wrong: failure modes and false positives

The value of this method is in what it refuses to count. Each failure mode below produces a plausible-looking candidate who did not do the work, and each has a specific check.

- **Contributor-tab inflation.** Appearing in the Contributors graph counts docs, typo, and CI commits equally. The false positive is a one-line fixer ranked as an author. Check: blame the hard path, not repo-wide totals.
- **Attribution spoofing.** Git assigns credit by commit email, and a push can contain commits the pusher did not author. The false positive is an impersonated contributor. Check: require GPG-verified commits.
- **Reformatting steals blame.** A single whitespace or reformat commit reassigns every line to the reformatter. The false positive ranks a janitor above the subsystem's author. Check: blame with `-w -M -C`.
- **AI commits masquerading as depth.** Bot or trailer-tagged commits can look like subsystem work. The false positive credits an agent's output to a human. Check: strip Co-authored-by and bot logins, and flag large single commits.
- **AI absence misread as skill.** Clean code with no red flags may simply be reviewed-and-corrected AI output. Check: look for incremental human history rather than treating "no AI signal" as proof.
- **Public-only filter encodes visibility bias.** When gender is visible, women's contributions are about 15% less likely to be accepted, so merged-PR counts understate some strong engineers. Check: weight authored code, not acceptance rate.
- **Private and regulated blind spot.** Finance, defence, and health engineers leave no public trace, so a thin public pool is not a thin talent pool. Check: state the limit and widen outreach.
- **Bus-factor illusion.** Many projects are susceptible to the bus factor, where a single core developer carries a subsystem, so one name may be the only provable author. Check: confirm whether the pool is truly greater than one.

> **Watch out:** The reformat-blame trap inverts credit
>
> A naive blame can rank the person who ran the formatter over the person who wrote the algorithm, because one reformat commit reassigns every line. Always blame with -w -M -C. This single flag is the difference between finding the author and finding the janitor.

### Discounting AI commits is a scripted step, not a vibe

AI detection is now metadata-first. Detection rules key on actor logins such as `copilot-swe-agent[bot]`, author emails such as `noreply@anthropic.com`, author names such as `Cursor Agent`, and `Co-authored-by` trailers; 29 AI coding tools leave identifiable traces. Beyond metadata, fingerprint models reach a 97.2% F1-score flagging AI-generated PRs using agent-specific signatures, such as Cursor's bullet-heavy descriptions and Claude Code's dense comments. In the diff, watch for idiomatic-but-contextually-wrong choices, mismatched sophistication where junior-looking naming pairs with an advanced algorithm, and a 500-line file landed in one commit with a generic message, often followed immediately by small correction commits.

#### From keyword to verified author

| Stage | Figure | Note |
| --- | --- | --- |
| Keyword matches | thousands | bare skill or keyword on a profile |
| Core maintainers / CODEOWNERS | under 16 per repo | named owners of the subsystem |
| Provable capability intersection | 0-3 | Refolk strict skill-plus-keyword, per market |
| Verified, de-spoofed, AI-discounted authors | low single digits | the hirable shortlist |

*Each stage removes candidates who look qualified but cannot be tied to the hard subsystem.*

The caveat matters: absence of AI signals is not absence of AI, because a developer may have reviewed and corrected the output. So the scripted filter removes the obvious cases and the human reads the diff for the rest. The final arbiter is always the code.

> A merged-PR count ranks acceptance; a blame line on the hard path ranks authorship, and only one of those is the job.

## Verifying before you call the shortlist done

Run this checklist against every row before you send the shortlist. A row that fails any item is a lead, not a confirmed author.

#### Shortlist readiness

- [ ] Each candidate is tied to a specific repo and subsystem path, not a repo-wide contributor count.
- [ ] The hard subsystem was blamed with -w -M -C so reformatting did not steal credit.
- [ ] Commits are GPG-verified, so the name is not spoofed by a pushed email.
- [ ] Bot logins and Co-authored-by trailer commits have been stripped from the evidence set.
- [ ] At least one diff implementing the difficult logic was read and confirmed as the candidate's work.
- [ ] Ranking weights authored code, not merged-PR acceptance counts.
- [ ] If the verified pool is low single digits, the shortlist states that public evidence alone cannot fill the role.

Account for the bias the public graph carries. Women are 5.2% of four million GitHub users, and when gender is visible they face a 4.1% lower PR-acceptance chance than men and about a 15% lower acceptance likelihood overall. If you rank on merged-PR counts, you compound that documented penalty. Author-side blame evidence is the corrective, because it credits the code a person wrote regardless of whether a maintainer accepted it. This is also why a thin result is not a verdict on the market: regulated and private work is invisible here by construction.

## What to do when the provable pool is too small

State the limit, then widen. A low single-digit verified pool is a common and honest outcome of this method, not a failure of it, and the worst response is to pad the list with contributor-tab names you could not confirm.

When the pool is one, two, or three verified authors, do three things. First, widen to adjacent repos and forks: RocksDB forks, other Raft implementations, sibling LLVM backends, and parallel GPU-kernel projects hold authors who did the same hard work elsewhere. Second, move to private-signal outreach: the people doing storage-engine or consensus work inside finance, defence, and health leave no public trace, so reach them through talks, patents, and warm paths rather than the git graph. Third, confirm whether the pool is truly greater than one before you build a role around it, because a single provable name is a bus-factor signal about the ecosystem, not just your search.

Keep the shortlist current by re-running the authorship pull on a cadence. Canonical repos gain and lose maintainers, governance files are updated, and a new backend or pass brings new authors into scope. A capability map that named three repos and five owners last quarter may name six repos and nine owners now. The method is evergreen; the owner list is not, so re-check the governance docs and re-blame the hard paths whenever the role reopens.

> **Note:** A thin public pool is not a thin talent pool
>
> Finance, defence, and health engineers do exactly this work behind private repos. When public evidence runs out at two or three names, that is a signal to change channels, not to lower your authorship bar.

## Frequently asked questions

### How is this different from just using the GitHub contributors graph?

The contributors graph counts every merged commit equally, so a one-line typo fix and a rewritten compaction engine sit side by side. This method ignores repo-wide totals and reads line-level authorship of the specific hard path with git blame, then confirms the person wrote the difficult logic by reading the diff. The contributor tab tells you who touched the repo; blame on the subsystem tells you who built it.

### How do I verify an individual actually wrote the code on GitHub?

Git assigns attribution by commit email, which is spoofable, so start by preferring GPG-verified commits that show as verified in the interface. Then run git blame with -w -M -C on the hard files to defeat reformatting that steals credit, and open the diffs to confirm the person authored the core logic rather than tests or formatting. Identity verification and code-reading together are what make a row defensible.

### What if only one or two people provably built the thing?

That is a real and common outcome: more than 88% of studied projects have fewer than sixteen core developers, and some rely on a single person. When your verified pool is low single digits, state plainly that public evidence alone cannot fill the role, then widen to adjacent repos, forks, and private-signal outreach. A thin public pool is not proof of a thin talent pool, because regulated and private work leaves no trace.

### Can I trust merged pull-request counts as a skill ranking?

No. Women are 5.2% of four million GitHub users and face a 4.1% lower acceptance chance than men when their gender is visible, so merged-PR counts encode a documented acceptance bias. Rank on authored code evidence from blame and the diff, not on how often a person's PRs were accepted. Weighting authorship rather than acceptance is the corrective.

### How do I tell an AI-assisted commit from genuine subsystem work?

Start with machine-readable metadata: 29 AI coding tools leave traces such as bot actor logins, agent author emails, and Co-authored-by trailers, and fingerprint models reach 97.2% F1 on agent-specific signatures. Then read the diff for idiomatic-but-wrong choices and large single commits followed by small corrections. Note the caveat: clean code with no red flags may be reviewed-and-corrected AI output, so the final arbiter is still reading the code.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/sourcing-deep-specialty-engineer-public-code*