Hiring Assistant 2 Badges: Only 1 in 450 US Engineers Lists Copilot

If you source engineers with LinkedIn's Hiring Assistant, Connected Apps "capability statements" from Replit, Lovable and, soon, GitHub Copilot are about to sit in the same candidate view you use to build shortlists. Those statements prove someone used a tool. They don't prove that person shipped anything, and if you filter on them you throw away most of the market.

LinkedIn announced Hiring Assistant 2 at Talent Connect in New York at the end of September, and existing English-language Hiring Assistant customers get it automatically starting in November. Here is what the new signals actually prove, and how to keep them from steering your shortlists.

What does Hiring Assistant 2 change for engineering sourcing?

Hiring Assistant 2 puts verification and work-experience signals into one candidate view, so a Replit or Lovable statement now shows up right next to job history in your shortlist. On paper that's a display change. In practice it changes ranking, because whatever sits in that view shapes what recruiters click on.

Here are the facts, with dates corrected from early coverage:

• Announcement: Dan Reid (VP of Product) and Prashanthi Padmanabhan (VP of Engineering) of LinkedIn Talent Solutions published the post on September 29, 2026. The launch happened on stage at Talent Connect on September 30.
• Rollout: existing English-language Hiring Assistant customers get the new capabilities automatically starting in November 2026.
• Access: you need a Recruiter Corporate or Recruiter Professional Services Plus contract with the Hiring Assistant add-on.
• What it combines: verification data alongside ATS data, pre-screening answers and work history, which together build a fuller candidate picture and flag inconsistencies.
• Scale: LinkedIn says 115 million members have verified their identity.
• Named customers: AMD, Cisco, Palo Alto Networks and Zillow.

The verification signals in Hiring Assistant 2 fall into two groups, and they need very different handling. Identity and employer checks answer "is this person real, and did they work where they say?" Connected Apps answer "did this person use a vendor's product?" Showing both in one view makes them look equally trustworthy. They aren't.

What is a Connected Apps capability statement?

A capability statement is a locked summary that a partner app writes from a member's usage data, describing how that member uses the tool. Members opt in, they can't edit it, and it only measures activity inside that one vendor's product.

The feature has changed names quickly:

1. January 2026: launched as Verified Skills. Early partners were Descript, Lovable, Relay.app and Replit.
2. June 2026: expanded, and LinkedIn started using the term "capability statement."
3. Announced but not live: upcoming integrations include Adobe, Fullcast, GitHub Copilot and Gong.

Lovable's version makes it clear what's being measured. A user clicks "connect to LinkedIn," and the resulting score appears on their profile. That score comes from inside Lovable. No one reviewed the code behind it. Even explainers that are friendly to the feature admit a capability statement can't show the quality of the work produced.

That is the core problem: the badge measures the wrong thing. Here's how it compares with the signals that actually involve a reviewer:

Only the last row involves another engineer reading the work.

How many engineers would a Copilot badge filter keep?

A Copilot filter would keep about 1 in 450 US software engineers, and that's before anyone has to connect an account. In Refolk's index, 1,248 of the 563,590 US engineers titled Software Engineer, Senior Software Engineer or Staff Software Engineer list "GitHub Copilot" as a skill. That's 0.22%.

0.22%

These are self-listed skills, not Connected Apps badges. I use them as a proxy for how willing engineers are to advertise tool use at all, and the answer is barely. Typing "Copilot" into a skills field costs nothing. A Connected App asks for more: you have to deliberately connect an account. More friction means fewer people do it, so the badge pool will probably be smaller than 1,248. And since the Copilot integration isn't live yet, the badge pool today is essentially zero.

The "GitHub" row matters more. Only 5.0% of these engineers list GitHub as a skill, which is 22.5 times the Copilot count but still a small slice. That gap says more about how rarely engineers maintain a skills section than about who uses GitHub. Any signal that depends on engineers curating their profile will undercount them, and a shortlist filtered on a badge never shows you the other 95%.

Why does a usage badge say so little about the engineer?

AI coding tools are becoming standard, and the employer may pick the tool as often as the engineer does. Once nearly everyone uses some assistant, a badge for one vendor's tool sorts people by who their employer bought from and how tidy their profile is. It doesn't sort them by ability.

The numbers point that way:

• Reach, not depth. GitHub Copilot had 50 million users in July 2026, but Microsoft counts free, student and paid accounts together. That number measures how widely the tool is distributed, not how skillfully anyone uses it.
• Not the default at work. JetBrains' May to July 2026 developer survey put workplace Copilot adoption at 21%. The other 79% aren't using Copilot at work.
• Agents are everywhere. About one in three pull requests on GitHub now involves an agent. When a behavior is nearly universal, it can't separate one candidate from another.

There's also an employer effect. In a 25-profile sample of engineers who list Copilot, the top employers included FedEx, JPMorganChase, Walgreens and a California state agency. The base sample, by contrast, was led by Meta, Google and Figma. That pattern fits large organizations rolling out licenses to every developer (Copilot is used across roughly 140,000 organizations). Twenty-five profiles is a tiny sample, so treat this as a hint, not proof. Still, it suggests a Copilot signal partly measures procurement.

A Copilot badge tells you which IT department bought licenses, not which engineer you should call.

How does Hiring Assistant 2's memory make badge bias stick?

Hiring Assistant 2 learns from every requisition, candidate and hire. So if your team advances badged profiles in November, the agent learns that badges predict what you want and shows unbadged engineers less often. You never see the candidates it stops surfacing, which is why the bias builds up without anyone noticing.

A badge is visible and new, and it gives a recruiter an easy reason to pick one similar profile over another. Each of those small picks becomes training data, and the agent can't tell "advanced because of the badge" apart from "advanced because they were the best fit." After a few requisitions, a feature with almost no supply (0.22% even before the OAuth friction) is steering which candidates you see first.

The cost shows up later. Senior and staff requisitions stay open longer because each shortlist narrows toward the same small group of opted-in profiles. Hiring managers ask where the strong candidates went, and someone ends up paying an agency to find engineers your own tool quietly ranked lower.

Before November, run an audit. Take a requisition you've already filled and run the same brief two ways: once inside Hiring Assistant, and once as an open search across GitHub, LinkedIn and the open web. Then compare who appears in each. If the engineers you actually hired rank much lower in the agent's results than in the open search, you have a baseline for spotting drift later.

How do you verify software engineer skills when sourcing?

Look at the work behind a profile, not the badges on it. That means merged pull requests, code review comments and issues filed in projects the candidate doesn't control. Other people reviewed that work. Nobody reviews usage telemetry.

A practical sequence:

1. Find the GitHub account. Match name, location, employer and any personal site linked from LinkedIn. Don't expect it in the skills section - 95% of these engineers don't list GitHub at all.
2. Look for merged PRs in repos they don't own. A pull request accepted by outside maintainers is the closest thing to a free code review you'll get.
3. Read their review comments. How someone critiques other people's code tells you more about seniority than the code they write themselves.
4. Check recency and language. Recent contributions in the stack you're hiring for beat an old, popular repo in a language you don't need.
5. Read the issues they file. Clear reproduction steps and well-scoped bug reports show debugging skill you can't fake.
6. Account for private work. Plenty of strong engineers ship almost entirely in private repositories. For them, use talks, papers, published design docs and referrals, not a public graph.

Doing this by hand for a full shortlist eats days, which is why recruiters are tempted to use a badge as a shortcut. Refolk handles this step instead: you describe the engineer you want in plain English, and you get back a ranked shortlist with each person's GitHub evidence next to their LinkedIn profile.

Where should verification signals sit in your workflow?

Use verification as a minimum bar, not as a ranking factor. Identity checks and inconsistency flags should knock fake profiles off a shortlist. They shouldn't push real candidates up it, and Connected Apps statements shouldn't affect ranking at all.

LinkedIn's own research says 64% of US TA professionals find it harder to know who to trust when assessing candidates. That's a real problem, and identity verification across 115 million members is a reasonable answer to it. But trust and skill are separate questions, and the new view tends to blur them.

How to weight each signal:

• Gate on identity for roles where fraud risk is high (remote, contract, high-access infrastructure). An unverified profile isn't disqualified, but it gets a closer look.
• Investigate inconsistency flags. If the agent finds a mismatch between ATS data and work history, check it before outreach.
• Exclude Connected Apps from ranking. Don't add a Replit, Lovable or Copilot statement as a requisition criterion, and don't let it break ties.
• Use statements to start conversations. A Lovable score is a fair opener ("what did you build with it?"), and the answer will tell you more than the score.
• Check what you advance. Every month, compare the share of badged profiles you move forward with the share in the overall pool. If it's far higher, you're training the agent on the badge.

FAQ

Will GitHub Copilot badges show up in Hiring Assistant 2 in November?

Probably not many. GitHub Copilot is listed as an upcoming Connected Apps integration alongside Adobe, Fullcast and Gong, but it isn't live yet. Replit, Lovable, Descript and Relay.app have been partners since the January 2026 Verified Skills launch. Even after Copilot goes live, the opt-in step means only a small slice of engineers will connect it. In Refolk's index, just 0.22% of US engineers list Copilot as a skill, and that doesn't even require connecting an account.

Should I filter on LinkedIn verified skills for GitHub Copilot?

No. A Copilot statement shows that someone used the tool, possibly because their employer licensed it for everyone. It says nothing about the quality of their code. Filtering on it removes the large majority of engineers who never opted in, and Hiring Assistant 2's memory can turn that one-off filter into a lasting ranking bias.

Who gets Hiring Assistant 2?

Existing English-language Hiring Assistant customers get it automatically starting in November 2026. That requires a Recruiter Corporate or Recruiter Professional Services Plus contract with the Hiring Assistant add-on. Recruiters on other plans won't see the combined verification view through this rollout.