Short answer
Resumes have lost reliability in 2026 because LLM-assisted rewrites, keyword optimization, and inconsistent titles have flattened the signal a recruiter used to read. Public commits, pull requests, and repository maintenance are more reliable because they are artifacts that cannot be faked in a few minutes. The modern technical-recruiting workflow sources candidates from GitHub activity, triangulates seniority from contribution patterns, and uses LinkedIn only for the contact step.
TL;DR
- LLM polishing has flattened the prose signal recruiters once read on resumes.
- Keyword optimization has made job titles and skill sections unreliable.
- Public commits are the clearest signal of current skill and seniority.
- GitHub contribution cadence is a better seniority indicator than years of experience.
- Maintainer status on widely-used libraries is a strong credibility signal.
- Sourcing happens on GitHub; contact happens on LinkedIn or verified email.
- Respect public availability signals (ForHire flag, contact preferences) to keep reply rates viable.
Contents
Why resumes degraded as a signal
A resume is a self-reported summary, and self-reported data has always been noisy. What changed in 2026 is not the direction of the noise but its volume. Three trends have combined to reduce the information content of the average technical resume.
LLM polishing has flattened voice
Ten years ago, experienced recruiters could read a resume and form a reasonable prior about the candidate's communication style, attention to detail, and depth of thought. Today, the same resume has been rewritten by an LLM into smooth, generic, confident prose. The style signal is gone — not because candidates are worse writers, but because the document reflects the tool, not the author.
Keyword optimization has distorted job descriptions
Applicant-tracking systems parse for specific terms. Candidates know this. The result is resumes that list every framework, language, and tool the candidate has ever touched, weighted by parser-friendliness rather than actual expertise. A resume that lists React, Vue, Angular, Svelte, Ember, and Solid in the same skills section is not telling you the candidate is fluent in six frontend frameworks — it is telling you they want to pass the parser.
Job titles are inconsistent across companies
The same technical role carries wildly different titles across companies: "Software Engineer" at one firm means what "Senior Engineer II" or "Staff Developer" means at another. The resume's job-title column has become nearly useless as a seniority filter, especially for candidates who have worked at more than two companies.
Public code activity resists all three of these degradations because the artifact itself — the actual commits and PRs — is the signal. You cannot LLM-polish a year of consistent contributions to a serious open-source project.
What commits and PRs reveal
A commit is a timestamped statement of work. It is attributed, diffable, and usually paired with a message that reflects the author's intent. Commits and pull requests reveal things that resumes cannot.
Current skill, not historical skill
A resume that lists Kubernetes expertise may reflect a single project three years ago. A commit history that shows active Kubernetes work in the last three months is evidence of current fluency. Technical skills decay fast; commit recency is the right proxy for current capability.
Actual stack, not claimed stack
Developers list stacks they have touched. Their commit history reveals stacks they actually work in day-to-day. The two sets overlap imperfectly, and the commit-derived set is the one that matters for matching candidates to roles.
Code review and maintenance behavior
Reviewing PRs, triaging issues, and maintaining libraries that others depend on are higher-order technical activities than writing new code. A developer who shows up consistently in the reviewers column of a non-trivial repo is signaling a specific kind of seniority that rarely shows up on a resume.
A GitHub-first seniority model
A reasonable seniority signal is a combination of four GitHub features:
- Account age — the floor. Does not distinguish active engineers from dormant ones.
- Contribution consistency — density of the contribution graph over the last 12 months. Distinguishes real practitioners from sporadic participants.
- Repository ownership — projects the developer created and maintains. Higher weight if they have external contributors.
- External PR footprint — merged contributions to repos the developer does not own, weighted by repo significance.
This model is not as clean as years-of-experience filtering, but it is substantially more predictive for engineering roles. A 4-year GitHub account with dense activity, three small maintained libraries, and a handful of merged PRs to serious upstream projects is usually a mid-level engineer; a 10-year account with the same footprint is usually senior. Years-of-experience alone tells you neither.
A modern technical sourcing workflow
The workflow that works in 2026 follows four steps.
Step 1 — Identify the right repos
The repos to watch depend on the role. For a hire working on a specific technology — a Rust systems engineer, a React Native specialist — the right starting point is the top 10 to 20 repos in the relevant ecosystem plus the most active community tools. Developers who show up as contributors or long-term users of those repos are your candidate pool.
Step 2 — Build the profile
From each candidate's GitHub profile, derive: primary languages, recency of activity, repository ownership, review and issue behavior, and estimated seniority. GitHub data for this is public; the work is in the aggregation.
Step 3 — Enrich to a verified contact
GitHub profiles have verified emails on only a portion of accounts. The rest require enrichment — matching the developer's name, location, and employer to LinkedIn, and looking up a verified work email through standard contact databases. This is where GitHub-native sourcing plugs into the same infrastructure that powers contact enrichment for technical roles.
Step 4 — Qualify against the role
Before outreach, confirm that the candidate's recent activity matches the role's stack and seniority target. Mismatches at this stage are the main source of low reply rates in technical recruiting — a senior Kubernetes engineer does not want a lead for a junior full-stack role, however well-written the pitch.
Outreach that engineers will actually read
The developer outreach playbook applies: reference something specific about the candidate's recent work, keep the first message short, and do not pretend to be a technical peer if you are not. A recruiter message that mentions a specific PR the candidate merged to a relevant repo will outperform a message that pretends to have read the candidate's entire GitHub history.
Three patterns that reliably underperform:
- Generic "impressive background" opener — every recruiter sends these. They carry no information and signal that the message is mass-dispatched.
- Over-claiming the role — "this opportunity has been built specifically for someone with your exact profile" trains developers to distrust you.
- No role specifics in the first message — engineers respond better to concrete details (team size, technology, compensation band) than to vague invitations to chat.
Limits of GitHub-based recruiting
GitHub is not universally useful. Developers who work exclusively in private monorepos, who do not maintain personal projects, or who contribute under anonymous accounts leave limited public traces. For these candidates, traditional sourcing — LinkedIn, referrals, conference participation — remains the primary channel.
The right framing is that GitHub is the most reliable signal layer in 2026 for the portion of the engineering market that uses it. That portion is large, especially in infrastructure, developer tools, ML, and open-source-adjacent work. For other segments, GitHub is one input among several rather than the primary source. A tool like the technical recruiting tool is useful for the GitHub-visible portion of the pool but should be complemented for the rest.
Frequently asked questions
Why are resumes weaker signals in 2026?
LLM polishing flattened voice, keyword optimization distorted skills, and job titles diverged across companies. The result is lower information per word.
What GitHub activity reveals real skill?
Recent commit cadence, merged PRs to non-trivial repos, code review activity, and the structure of personal projects. All four resist faking.
Is GitHub sourcing ethical?
Yes. The data is public by GitHub ToS. Ethics attaches to the outreach — relevance, respect for availability flags, and reasonable volume.
How do you tell senior from junior via GitHub?
Combine account age, contribution consistency, repository ownership, and external PR footprint. No single axis is sufficient.
Which engineers are most reachable?
Developers with verified emails, recent activity, and personal projects. Passive candidates with sparse profiles require other channels.
Does this work for non-OSS developers?
Partially. GitHub covers most professional engineers but not all. Combine with LinkedIn and referrals for the private-repo portion of the market.
Recruit from commits, not claims
LeadCognition surfaces engineers by what they build, enriches to verified contact, and lets your team reach the right person first. Free to start.
Start free →