LinkedIn's June 18 Connected Apps Killed the Skills Filter. Boolean Is Next.
LinkedIn's Connected Apps replaces self-declared skills with verified tool usage. What sourcers and engineering managers should change this week.
On June 18, 2026, LinkedIn shipped Connected Apps, a feature that auto-generates uneditable descriptions of how a member actually uses tools like Replit, Lovable, Relay.app, and Descript, based on activity data from the connected app itself. GitHub and GitHub Copilot are on the roadmap but not live yet. If you source engineers, the Skills section you've been Booleaning against for a decade is about to mean something different, and the people who adjust this week will eat the people who don't.
What actually changed on June 18
The mechanic is simple and the implications are not. A candidate clicks Add section > Connected apps, authorizes an integration, and the platform writes a structured, data-backed description of what they do inside the tool. They get notified when the summary is added or updated. They cannot edit it.
LinkedIn's own example for HubSpot is "creates and sends segmented email campaigns in HubSpot's Marketing Hub." Not "uses HubSpot." Not a tag. A behavioral sentence pulled from product telemetry. CEO Dan Shapero framed it as "new ways for members to show real, credible proof of what they're capable of, right on their LinkedIn profile."
The launch partner list is narrow on purpose: Descript, Duolingo, Lovable, Relay.app, and Replit. The next wave adds Air, Base44, Beehiv, Buffer, Fiverr, Gamma, HeyGen, HubSpot, JetBrains, Magic Patterns, Mirage/Captions, Pictory AI, Profound, and Wispr Flow. After that: Adobe, Fullcast, GitHub, GitHub Copilot, Gong, OpusClip, Riverside, Sprinklr, Webflow, and Zapier.
Read that list twice. At launch, "verified tool usage" for engineers means the vibe-coding stack. The enterprise codebase signal, the one your hiring committee actually trusts, is still a roadmap item.
Why your Boolean string is now a liability
Two things were already wrong with Boolean against LinkedIn's Skills section, and Connected Apps makes both worse.
First, the Skills section was chronically underused. Sourcing playbooks have been telling people to lean on Keywords over Skills for years, because Keywords catches mentions across the summary, job descriptions, and project details. A candidate who shipped three Replit apps last quarter probably never typed "Replit" into the Skills field. Your Boolean string never saw them.
Second, LinkedIn Recruiter caps Boolean strings at roughly 2,000 characters and does not rank results by how well they match the string. The most relevant profile might be on page 30. You've been triaging a randomly ordered list of self-claimed skills and calling it a pipeline.
Connected Apps doesn't fix Boolean. It bypasses it. The new primitive is a structured, verified field with a behavioral sentence and, in some cases, a proficiency tier. You can't AND your way to that. You have to filter on it directly, or you have to source somewhere that already does.
The proficiency tier is the new shortlist primitive
This is the part most posts about Connected Apps are missing. Early rounds showed real ranking:
- Replit assigns numerical proficiency levels.
- Lovable awards a "bronze" in vibe coding.
- Relay.app tags users as "intermediate AI Agent Builder."
Levels update dynamically as people gain experience. TechCrunch describes the verification mechanism as platforms using AI to assess skills during use and generating a certificate based on usage patterns, product outcomes, and proficiency within the tools.
For the first time on LinkedIn, you have a rank-able integer attached to a skill. Boolean can't sort. Verified levels can. The next sourcing query isn't a string, it's a threshold: Replit >= level 4 AND Relay.app >= intermediate AND location = SF Bay. That query did not exist on June 17.
For the first time on LinkedIn, you have a rank-able integer attached to a skill. Boolean can't sort. Verified levels can.
If you run an engineering org and your sourcing team is still writing two-thousand-character Boolean strings against self-declared skills, they're operating on a feature LinkedIn just deprecated in spirit, if not in code.
The selection bias nobody is naming
Here is the contrarian piece. The Next Web flagged it carefully: if recruiters start filtering by verified tool usage rather than self-reported skills, every professional who does not connect their apps is at a disadvantage. That's how a feature becomes a requirement.
Who connects first? Indie builders. Solo founders. Creators. Engineers whose identity is tied to the tools they ship in public. Who connects last, or never? Senior ICs at FAANG. Engineers on regulated infrastructure where third-party OAuth is prohibited by policy. The exact people most hiring managers say they want.
Your first Connected Apps shortlist will skew toward AI-native builders, vibe-coders, and creators. If you're hiring a staff engineer for a payments platform, that shortlist is not your pool. If you're hiring the first three engineers for an AI-native seed-stage product, it might be the only pool that matters.
Name the bias on the intake call, before you build the filter.
What to do this week if you're sourcing engineers
Three concrete moves, in order of leverage.
1. Stop appending AND Replit to existing Boolean strings
The instinct is to bolt the new tool names onto your current keyword soup. Don't. The leverage of Connected Apps is the structured field with the proficiency tier, not the keyword. If you treat verified usage as a string match, you'll catch the same self-declared population you already had, plus a sliver of people who happened to type the same word into their summary.
Run two searches, not one. The first is your old string, scoped to the population that hasn't opted in. The second is a structured filter on Connected Apps tiers, scoped to people who have. Compare the overlap. It will surprise you.
2. Cross-reference the verified population against the platform your hiring committee actually respects
Until GitHub ships its integration, "verified developer" on LinkedIn means a Replit user, a Lovable user, or a Relay.app user. That's signal, but it's not the signal your CTO wants. They want commits, repos, language breakdowns, review velocity. They want GitHub.
This is the gap Refolk was built for. You describe the person in plain English ("ex-Stripe senior, shipped an AI agent on Relay.app in the last 90 days, active on GitHub in Go or Rust") and you get a ranked shortlist that joins LinkedIn signals to public GitHub activity and the open web. The Connected Apps integration tells you they vibe-coded. GitHub tells you whether they can also ship the boring half of the system. You need both, and you need them joined.
3. Build a shortlist of people who probably will opt in next
If Connected Apps is going to become a default, the audience that adopts in the next 60 days is predictable. They're already loud about the tools. Refolk's index shows roughly 13,066 US-based engineers list both Replit and GitHub as skills today, concentrated at Amazon, Ramp, Instagram, and Udemy, and clustered in San Francisco, Boston, LA, and Austin. That's your pre-opt-in cohort. You can reach them this week, before their profile gets a verified summary and twenty other recruiters notice.
Why LinkedIn shipped this now
The business logic is unsubtle. LinkedIn has 1.3 billion members and grew revenue 12% year-over-year last quarter, even after cutting roughly 5% of staff in May. Skills-first hiring is the pitch that lets them defend the moat against GitHub, Wellfound, and every AI-native sourcing tool eating their flank. Their cited research claims skills are five times better at predicting job performance than education alone, with an 89% improvement in retention among high performers.
Whether or not those numbers survive scrutiny, the strategic move is clear. By making the description uneditable and the source data first-party, LinkedIn moves from a self-reported resume layer to a verified credentials layer. That's a different product. It's also a product that makes Boolean less useful and structured filters more valuable, which conveniently makes Recruiter seats more sticky.
You don't have to like the strategy to act on it.
The fairness tail
One last thing engineering managers should think about before the eng-leadership Slack channel gets loud about it. Candidates have to grant these apps access. People who don't use supported platforms, or who decline to connect them, will end up disadvantaged in any pipeline that filters on verified usage. That's not a hypothetical. It's the design.
If your shortlist criteria includes "verified Replit level" and your role is open to senior engineers from regulated industries, you've just written a filter that excludes a chunk of the qualified population for reasons unrelated to skill. Document the carve-out. Run a parallel search that doesn't require opt-in. This is exactly the kind of plain-English query Refolk handles well: "senior backend engineers from financial-services infra, fluent in event-driven systems, regardless of LinkedIn verification status." Don't let a new field do your thinking for you.
The short version
Connected Apps replaces a typed skill with a behavioral sentence and, in some cases, an integer. Boolean against the old Skills field is now searching a shrinking, lower-signal population. The new primitive is a threshold filter on verified tiers. GitHub isn't live yet, so the early-verified cohort is vibe-coders and creators, not staff engineers on regulated infra. Sourcers who lean in early will win the AI-native shortlist and lose the enterprise one, unless they join LinkedIn signals to GitHub and the open web themselves.
The recruiters still typing AND "Replit" into a 2,000-character string this week are going to lose the next quarter to the ones who stopped.
FAQ
Does Connected Apps replace LinkedIn Recruiter's Boolean search entirely?
No, and LinkedIn hasn't said it will. Boolean still works against Keywords, titles, companies, and the rest of the profile. What changed is that the Skills section, which was already underused by candidates, now has a parallel structured field generated from real product usage. The smart move is to keep Boolean for everything except tool proficiency, and use the new verified field for tool proficiency. Two searches, joined manually or by a sourcing tool that does it for you.
When will GitHub integration ship, and what will it actually verify?
LinkedIn has confirmed GitHub and GitHub Copilot are on the roadmap but hasn't published a date. Based on the HubSpot and Replit examples, expect a behavioral sentence ("contributes to TypeScript repos and reviews pull requests in production codebases") rather than a raw commit count. Until it ships, you have to source against GitHub directly. Refolk pulls public GitHub activity alongside LinkedIn, which is how you get the signal your engineering committee wants today, not next quarter.
Won't senior engineers just refuse to opt in?
Many will, especially at companies where third-party OAuth is restricted or where engineers don't want product telemetry feeding a public profile. That's the selection bias to name on every intake call. Your verified-usage shortlist will skew toward indie builders, creators, and engineers at AI-native startups. If you're hiring for those roles, that's perfect. If you're hiring staff engineers for enterprise infra, you need a parallel pipeline that doesn't depend on opt-in.
How should I write a sourcing query that uses Connected Apps without over-indexing on it?
Treat verified tool usage as one signal among several, weighted by role. For an AI engineer hire, a verified Relay.app or Replit tier is high-signal. For a staff backend engineer, it's a tiebreaker at best. Write the query in plain English first ("senior engineer who shipped a production AI agent in the last six months, comfortable with Go, based in Austin"), then map each clause to the right source: Connected Apps for tool proficiency, GitHub for code, LinkedIn for tenure and title, and the open web for the rest.