LinkedIn's $450M Hiring Assistant Is Blind to GitHub Signal

If you hire engineers, two facts from Q1 2026 sit on top of each other and point at the same problem. LinkedIn's AI recruiting agents crossed a $450M annualized run rate, and in the same quarter LinkedIn sued Proxycurl out of the market and deleted HeyReach's company page. February 2026's Hiring Assistant update wired the agent into Microsoft Teams with AI-Assisted Search, AI Follow-Ups and AI Applicant Targeting. The agent is getting faster, the moat around LinkedIn's data is getting higher, and neither move touches the signal that actually predicts who ships code.

Why a $450M product still cannot see a commit

LinkedIn Hiring Assistant evaluates candidates almost entirely through self-reported LinkedIn profile text, which means commits, repo ownership, contribution graphs and maintainer status are structurally invisible to it. That is not a bug in the current release. It is the shape of the underlying dataset.

The Information reported roughly $450M ARR for LinkedIn's agentic hiring products by April 2026, the first time the company has ever broken out revenue for one of its AI tools. General availability shipped at the end of September 2025 with an 8,000+ user early cohort. Charter customers include AMD, Canva, Siemens and Zurich Insurance. None of those are OSS-native software shops, and that is not an accident: the product works best where candidates already maintain LinkedIn as their primary professional artifact.

For engineering roles, that assumption breaks. The maintainer of tokio does not update their headline. The Rust engineer at Oxide got hired through a written application, not an InMail. The staff engineer at Ramp lists "Software Engineer" and calls it a day. Hiring Assistant sees a title. It does not see the commit history.

$450M

What the agent measures, and what it quietly excludes

Every efficiency number LinkedIn cites for Hiring Assistant measures speed on the declared pool, not accuracy against the real one. That distinction is the whole article.

LinkedIn's public numbers for the product are real and worth respecting:

• 4 hours saved per role on average for Hiring Assistant users.
• 62% fewer profiles reviewed to fill an equivalent shortlist.
• 18% higher InMail acceptance in AI-Assisted Search sessions vs manual filters.
• 30 days off time-to-hire at Expedia Group, LinkedIn's headline customer story.

Those are speed metrics on a candidate set that opted into being findable on LinkedIn. The mechanism behind the InMail lift is a selection effect: the agent preferentially surfaces candidates whose profile text is dense, whose skills are declared, and whose past behavior includes replying to recruiters. Strong engineers who treat LinkedIn as a resume graveyard are excluded from both the numerator and the denominator. The acceptance rate goes up because the pool shrinks toward LinkedIn-native people.

That is fine for sales, marketing, and operations hiring. It is a serious problem for staff-level infra, systems, ML, and OSS-adjacent roles, where the correlation between "great engineer" and "well-maintained LinkedIn" is roughly zero.

The 12,823 number that reframes the debate

In Refolk's index of professional profiles, only 12,823 US software engineers list "GitHub" or "Open Source" as a skill on their LinkedIn. That is a small fraction of the working US software engineer population on the platform, and it is the entire universe Hiring Assistant can reason about when a recruiter types "engineer with strong open source background."

The top employers in that declared cohort are Coinbase, Meta, Google, Ramp, Udemy, and Pindrop. Useful list. Also a narrow one. Most engineers who actually contribute to open source do not put "Open Source" on their profile, because they assume anyone serious will look at their GitHub. Hiring Assistant does not.

Compare the declared pools:

The Rust row is the punchline. A Hiring Assistant search for "Rust engineer" in the US and Germany returns something close to 690 candidates. The actual population of production Rust engineers is many multiples of that. The gap lives on GitHub, in RustConf talks, in crates.io ownership, and in commit history at Oxide, Helsing, and half a dozen infra-native shops that hire through OSS reputation.

LinkedIn's enforcement wave killed the workaround

The obvious hack, "just scrape GitHub URLs off LinkedIn profiles and enrich," is now a dead strategy, because LinkedIn spent 2026 systematically dismantling the vendors that made it possible. Any 2024-era playbook that assumed you could stitch the two graphs together via a Chrome extension needs to be retired.

The receipts from Q1 2026 alone:

1. HeyReach, roughly 30,000 active users, had its company page (about 16,400 followers) permanently deleted in March 2026, and founder Nikola Velkovski's personal profile banned.
2. Proxycurl / nubela.co, the enrichment API most sourcing tools quietly ran on, was sued by LinkedIn in 2026.
3. LinkedIn's March 2026 Transparency Report reported 78.2 million fake accounts blocked and 23.5 million automated sessions flagged in a single quarter.
4. Industry reporting puts Q1 2026 restriction rates for cloud-proxy automation tools at roughly 4 in 10 accounts.

The agent got faster hands in February 2026. It did not get better eyes.

The takeaway is not "LinkedIn is winning." It is that the arbitrage of treating LinkedIn as a base graph and bolting GitHub on top through scraping is closing. If you want commit-level signal in 2026, sourcing has to start on GitHub and the open web, then match back to LinkedIn for context. Not the reverse.

This is the exact gap Refolk is built to close. You describe the person in plain English, and Refolk searches GitHub, LinkedIn, and the open web in one pass, ranking on the signal that survives the LinkedIn crackdown: actual code.

The Teams integration is a distribution move, not a signal move

February 2026's Hiring Assistant update added Microsoft Teams collaboration, AI Follow-Ups, AI Applicant Targeting and Verified Applicant Spotlight. Not one of those widens the input data. They widen the surface area LinkedIn owns inside your workflow.

That is a fair enterprise strategy. It is also why the $450M ARR number should not be read as validation of the agent's technical recruiting quality. The revenue is coming from:

• Bundling with existing Recruiter seats. UK G-Cloud pricing pins Hiring Assistant at £6,350 per seat/year at low volumes, sliding to £1,575 at 101 to 250 seats, on top of Recruiter seats running £6,750 to £8,925.
• Workflow lock-in through Teams, calendar and inbox integrations.
• Enterprise procurement inertia at logos like AMD, Canva, Siemens, Zurich Insurance and Biocon Biologics.

None of that changes what the model can see. A Teams-native agent that reads only self-reported profile text is still an agent that reads only self-reported profile text. Faster hands, same eyes.

78.2M

What actually works for technical recruiting in 2026

The durable stack for technical recruiting in 2026 is GitHub-first sourcing, matched back to LinkedIn for context and outreach, with Hiring Assistant used only where it plays to its strengths. That means changing the order of operations, not adding another tool to the pile.

A practical operating model:

1. Start with the artifact, not the profile. For engineering roles, define the search in terms of code: language, repo ownership, contribution frequency, maintainer status, conference talks, RFC authorship.
2. Search across GitHub, LinkedIn and the open web in one query. Handling this by hand is a full-day job per role. You want a paragraph of English in, a ranked shortlist out, without stitching three tools together.
3. Use Hiring Assistant where the pool is LinkedIn-native. Sales, GTM, marketing, ops, some product roles. It genuinely saves 4 hours per role there. Do not deploy it as your primary channel for staff infra, ML systems, or OSS-heavy roles.
4. Kill the scraper dependency. If any part of your workflow depends on Proxycurl-style enrichment or a HeyReach-style automation, assume that path has a 12-month expiration date and rebuild around first-party open web signal.
5. Score on evidence, not declaration. Treat "Rust" on a profile as one weak signal, and a merged tokio PR as a strong one. The 18.6x gap between declared and actual is where your competitive advantage lives.

The reason the 12,823 US GitHub-declaring engineers matter is not that they are a bad pool. Coinbase, Meta, Google, Ramp all hire well from it. The reason they matter is that this is roughly the ceiling of what a LinkedIn-only AI sourcing tool can conceive of when you ask for "open source engineers." Everyone else, including most of the people you actually want, is visible only if your tools read GitHub natively.

Hiring Assistant is a good product for the roles it is good for, and the $450M ARR is real revenue solving a real problem. But it is not a technical recruiting tool. It is a LinkedIn-native shortlisting tool that happens to sell into technical recruiting orgs. Plan for 2026 on that basis, not on the demo.

FAQ

Is LinkedIn Hiring Assistant worth the £6,350 per seat add-on?

For roles where candidates maintain rich LinkedIn profiles (sales, marketing, ops, generalist PM), yes, and the 4-hours-per-role and 62%-fewer-profiles numbers hold up. For staff engineering, ML systems, and OSS-heavy roles, you are paying premium pricing for an agent that cannot see the signal that decides the hire, which makes the effective cost per qualified engineer much higher than the sticker.

Can I just scrape GitHub links off LinkedIn profiles and get the best of both?

Not durably. LinkedIn spent 2026 killing that path: Proxycurl was sued, HeyReach's page was deleted and its founder banned, 78.2M fake accounts were blocked in a single quarter, and cloud-proxy automation restriction rates hit roughly 4 in 10. Any workflow that assumes you can enrich LinkedIn with GitHub through a scraper should be treated as having a 12-month shelf life.

What does GitHub-first sourcing actually look like day to day?

You define the role as a code artifact (language, ownership, contribution pattern, maintainer status), run that query across GitHub, LinkedIn and the open web in one pass, and only use LinkedIn for context and outreach. The point is that a two-person recruiting team can cover a search space that used to require a dedicated technical sourcer, because the ranking is done on code, not on how well the candidate maintains their profile.

Why does the 690-engineer Rust pool matter if we are not hiring Rust engineers?

Because Rust is the clearest illustration of a pattern that also applies to Zig, ML compilers, kernel work, and any niche where the community lives on GitHub instead of LinkedIn. In Refolk's index, declared-Rust engineers are 18.6x rarer than declared-GitHub engineers, so a LinkedIn-only agent underestimates the real pool by roughly that factor. Whatever niche you hire in, assume the same shape and design your sourcing stack accordingly.