LinkedIn Hiring Assistant Ate the ATS. It Still Can't See GitHub.

On September 3, 2026, LinkedIn confirmed Hiring Assistant is wiring itself into hundreds of applicant tracking systems, including Greenhouse and Workday, so its agent can read applicant and resume data alongside LinkedIn profiles. That is a big deal for inbound triage. It is also the loudest possible signal that your outbound pipeline needs to live somewhere the agent structurally cannot look.

What the Sept 3 expansion actually changes

LinkedIn Hiring Assistant is now a full-stack recruiting agent that reads your ATS, not just LinkedIn. That is a genuine capability jump from its October 2024 sourcing-only debut with AMD, Canva, Siemens, and Zurich Insurance as design partners.

Concretely, here is what shipped and what it means:

• ATS reach: integrations with hundreds of ATSs, with Greenhouse and Workday named as anchor platforms.
• Greenhouse mechanism: a gated connector called RSC+ that enables Connected Projects and applicant stage syncing.
• Access requirements: RSC+ needs an active LinkedIn Recruiter Admin, a Greenhouse Site Admin, and at least one paid Hiring Assistant seat before it will turn on.
• Revenue trajectory: on April 29, 2026, LinkedIn disclosed its agentic AI hiring products are on track for $450M in sales in the coming year, the first sales number Microsoft has broken out for a core AI product.

The framing in most coverage is "AI does the sourcing for you." The reality is narrower and more strategic. The agent is now excellent at working candidates already inside your funnel, and it deepens LinkedIn's lock on the systems around it.

Why the ATS integration is a moat, not a feature

RSC+ is a switching-cost play dressed up as an AI announcement. The three-key access requirement (Recruiter Admin, Greenhouse Site Admin, Hiring Assistant seat) is not a technical necessity, it is a commercial one.

Think about the ripcord math. If your team standardizes on Hiring Assistant inside Greenhouse, unwinding LinkedIn from the stack now means unwinding three coupled contracts and retraining the workflow of every coordinator who leans on Connected Projects. That is a very different exit than cancelling a Recruiter seat.

The UK G-Cloud pricing sheet makes the commercial pressure explicit:

That is the budget line that gets a serious look at a second sourcing tool approved, especially once the promo window closes on June 30, 2026.

The 82% dark-matter problem the agent makes worse

Hiring Assistant amplifies outreach to the exact slice of talent every other AI agent is already hammering. That is a concentration risk, not a coverage win.

Three data points from the 2025 Octoverse and Stack Overflow surveys explain the mechanism:

• Only 18% of GitHub activity is public, meaning even a perfectly capable crawler would miss 82% of the signal that tells you who actually ships code.
• 74% of developers are not actively job-hunting (Stack Overflow 2025), so the LinkedIn "Open to Work" slice is a tiny, over-fished sliver of the market.
• Only 31% of tech recruiters use GitHub regularly, which sounds like a weakness of the market but is actually the arbitrage.

82%

Layer an agent on top of LinkedIn's roughly 1 billion members and you get faster outreach to the same visible surface. The developers who matter most (the ones publishing to private orgs, contributing to niche OSS, and ignoring recruiter mail) sit outside that surface entirely.

The pool Hiring Assistant structurally can't see

Refolk's index shows a clear split between the pockets Hiring Assistant is optimized for and the pockets it structurally misses. Large ML pools are LinkedIn-native. Systems and infra pools are GitHub-native.

Here are the raw counts from Refolk's professional-network index (September 2026):

Two things jump out. First, the ML pool is 15.1x the Rust pool in the US, so LinkedIn-native workflows work well there, but every agent is chasing the same Notion and Distyl profiles. Second, the Rust pool clusters at employers like Oxide Computer, Helsing, and DeepL, all of whom are canonically GitHub-first and low-LinkedIn-noise. An agent bound to the LinkedIn identity graph gets thin, repeated matches in exactly the roles where a single hire moves a roadmap.

This is where Refolk fits: you describe the person in plain English and get a ranked shortlist that reaches across GitHub, LinkedIn, and the open web, including the unclaimed profiles Hiring Assistant will never resolve.

Applicant data is not sourcing data

RSC+ pulls resume and applicant records already in your ATS. That is triage automation, not sourcing. The distinction matters because 74% of developers never apply in the first place.

Here is the split most sourcing leaders quietly know but rarely draw explicitly:

1. Inbound triage: ranking, staging, and messaging candidates who already applied. Hiring Assistant is now genuinely strong here.
2. Warm outbound: re-engaging silver medalists and past applicants in the ATS. Also strong, because the data is already there.
3. Cold outbound to LinkedIn-visible passives: works, but concentration risk is high and reply rates decay as every team runs the same play.
4. Cold outbound to GitHub-native or unclaimed-identity passives: the agent cannot do this. Full stop.

The agent that ate the ATS is still blind to the 82% of GitHub that lives in private repos.

The fourth bucket is where hires get made in Rust, systems, embedded, GPU kernels, and any deep-tech vertical where the strongest signal is a commit history rather than a job title.

The unclaimed-profile problem is structural

LinkedIn's graph is a graph of claimed accounts. GitHub handles, personal domains, arXiv authorship, conference speaker pages, and Discord identities are the unclaimed layer, and no ATS integration changes that.

The mechanism is worth spelling out. Hiring Assistant enriches candidates by joining ATS records to LinkedIn profiles on email, name, and employer history. If a candidate never claimed a LinkedIn profile (common among European systems engineers) or maintains a deliberately sparse one (common among senior infra engineers), the join fails silently. The candidate simply does not appear in the agent's world.

Two practical consequences show up in Refolk's index:

• Rust and embedded roles suffer most. The German Rust cohort of 182 clusters at Google, Bosch, SAP, Helsing, and DeepL, employers whose engineers often keep a two-line LinkedIn or none at all.
• The US Rust pool of 985 is heavily concentrated in San Francisco, with Oxide Computer alone accounting for 3 of 25 sampled profiles. Every AI agent hitting the same LinkedIn slice is messaging the same people.

An AI sourcing agent that cannot resolve external identities to hireable people is optimizing the wrong half of the funnel for these roles.

What to build instead of ripping LinkedIn out

Do not rip LinkedIn out. Pair it with an outbound layer the agent cannot reach, and use Hiring Assistant for what it is actually good at.

A concrete stack that works in 2026:

1. Keep Hiring Assistant on inbound. Let it triage applicants, sync stages, and draft first-touch messages inside Greenhouse or Workday. The 44% higher acceptance rate LinkedIn markets for AI-assisted messaging is real for warm audiences.
2. Move cold outbound off LinkedIn for GitHub-native roles. Rust, systems, ML infra, compilers, GPU, embedded, cryptography. These are the roles where the LinkedIn slice is smallest and most over-messaged.
3. Query in plain English against a broader index. Instead of a Boolean string that only searches LinkedIn, describe the person: "staff engineers who have contributed to Tokio or Axum in the last 12 months and are not currently at AWS or Cloudflare." That is the shape of query Refolk is built for.
4. Reserve InMail for the moments it matters. With Recruiter seats at $10K+ and Hiring Assistant on top, every InMail should be a considered send, not a spray.
5. Instrument reply rates by channel. If your LinkedIn reply rate on Rust roles is under a few percent, that is not a copywriting problem. That is a pool problem, and the pool lives on GitHub.

The strategic read on Sept 3

The right way to read the September 3 announcement is as a distribution move, not a product move. LinkedIn is embedding itself deeper into the systems that hold your candidate data so that "should we renew?" becomes a harder question every year.

That is fine, as long as you do not confuse depth inside the LinkedIn perimeter with reach outside it. The 985 US Rust engineers in Refolk's index, the 182 in Germany, the deep-tech clusters at Oxide, Helsing, and DeepL: those pools do not get bigger because Hiring Assistant reads your Greenhouse pipeline. They get more valuable, because everyone else's agent is looking somewhere else.

FAQ

Does LinkedIn Hiring Assistant actually source from GitHub?

No. Hiring Assistant works from LinkedIn's own identity graph plus, as of the Sept 3, 2026 expansion, applicant and resume data inside integrated ATSs like Greenhouse (via RSC+) and Workday. It does not crawl GitHub, and even if it did, 82% of GitHub activity is private per the 2025 Octoverse, so signal coverage would still be partial. For GitHub-native roles you need a separate sourcing layer.

What is RSC+ and why does it matter?

RSC+ is the Greenhouse-side connector that lets Hiring Assistant read applicant data and sync candidate stages between Greenhouse and LinkedIn Recruiter. It requires a LinkedIn Recruiter Admin, a Greenhouse Site Admin, and at least one paid Hiring Assistant seat to activate. That three-key requirement is what makes the integration a switching-cost moat rather than a simple feature.

Is Hiring Assistant worth the price for a small team?

For inbound-heavy teams with existing LinkedIn Recruiter contracts, yes, especially during the promo window that runs through June 30, 2026 at £1,575 to £2,079 per seat. For outbound-heavy teams hiring in Rust, systems, or ML infra, the roughly $300K/year all-in cost for a 20-recruiter stack is hard to justify without a parallel tool that actually reaches those candidates.

How do I source developers who are not on LinkedIn?

Start from the signal, not the profile. Describe the person you want in plain English (framework, employer pattern, seniority, region) and query an index that spans GitHub, LinkedIn, and the open web, which is what Refolk is built for. That resolves unclaimed identities like GitHub handles and personal domains back to hireable people, which is exactly the layer any LinkedIn-bound agent structurally cannot reach.