Gallup's 3x Layoff Gap Just Made Your Inbound a Trap

If you run inbound at a technical team in mid-2026, Gallup just told you something uncomfortable about the pile on your desk. The June 18 report (covered by Bloomberg) found that US tech workers who use AI less than monthly carry an 18% predicted layoff probability, versus 6% for monthly AI users. That 3x gap survives controls for age, education, and sector. The people you actually want are not applying. The people applying are disproportionately the ones the market just decided to let go.

The math of adverse selection

Read the Gallup numbers carefully, because the implication for sourcing is structural, not vibes.

AI non-users made up 62% of laid-off workers in the survey, compared to 50% of the currently employed. That gap is statistically significant and holds after accounting for age, education, industry, and time since layoff. Tech is also overrepresented in the unemployed pool: 13% of laid-off workers came from tech, despite tech being only 6% of currently employed workers. Roughly 2x overrepresentation.

Stack those two facts together. The unemployed pool is tech-heavy, and within that pool, the AI-non-user share is inflated. Now consider that unemployed engineers apply to jobs at far higher rates than employed ones. AIHR's sourcing benchmarks peg 70 to 75 percent of software engineers as passive: they don't update LinkedIn, don't apply to postings, don't browse boards. The active 25% to 30% is where your inbound comes from, and that slice now leans toward the 18% cohort.

3x

This is not a story about applicants being "bad." It is a story about composition. If you screen the top of your funnel the same way you did in 2023, you are screening a pool whose AI-fluency distribution has shifted left while you were not looking.

"AI proficiency" on a resume is now noise

Stack Overflow's developer survey puts overall AI tool usage above 84%. Every resume claims it. Every cover letter mentions it. As a screen, "uses AI" has the same predictive power as "uses Git."

What still carries signal is specificity: which tools, in which workflows, with what artifacts. And here the data gets interesting, because senior ICs invert what enterprise procurement reports.

JetBrains' AI Pulse (January 2026) shows GitHub Copilot leading worldwide work adoption at 29%, with Cursor and Claude Code each at 18%. But when JetBrains asked engineers with more than ten years of professional experience which AI tool they would choose for daily work, 46% picked Claude Code and 9% picked Copilot. The Pragmatic Engineer's February 2026 survey of about 906 senior engineers (median 11 to 15 years experience) confirms it: Claude Code is already #1 by mention count, 70% of respondents use 2 to 4 tools simultaneously, and 15% use five or more.

If your job description filters for "Copilot experience," you are filtering against the senior cohort you actually want.

What to ask instead

Behavior, not labels. Ask a candidate to describe a real instance where AI changed how they approached a problem. Ask which model they reach for when debugging a flaky integration test versus when writing a new service from scratch. Ask whether they keep a CLAUDE.md or .cursorrules file in their repos and what is in it. Ask what their eval harness looks like. The answers separate the 84% who "use AI" from the small minority who have actually rewired how they ship code.

The 6% cohort is on GitHub, not LinkedIn

Here is the structural problem with sourcing the AI-fluent engineer in 2026: they are employed, they are not browsing boards, and their LinkedIn says "Senior Software Engineer at Stealth Startup." A query against our internal index for US engineers with applied LLM skills (LangChain, OpenAI API) inside Software Engineer, ML Engineer, or AI Engineer titles returns roughly 2,757 matches. The top employers are Google, Meta, PostHog, SchoolAI, LightBeam.ai, and a sizable Stealth Startup cluster. That cluster is real. A meaningful share of the people you want are deliberately invisible to keyword search.

Where they are visible is in commits.

High-signal artifacts to look for

• PRs that touch agent SDKs (OpenAI Agents SDK, Pydantic-AI, CrewAI).
• Commits to anthropics/claude-code, langchain, llama-index, vLLM, Ollama.
• READMEs and repo roots that include .cursorrules, CLAUDE.md, or AGENTS.md.
• Eval harnesses: anyone who has shipped a real eval suite has done the unfun work that separates "vibe coder" with AI from engineer with AI.
• RAG pipelines with actual chunking strategy commits, not boilerplate from a tutorial.

The anthropics/claude-code repository counts 126,336 GitHub stars as of May 2026, with over 20,000 forks. Heavy issue participants and contributors there are a defensible high-signal pool. Cursor (Anysphere) has 1M+ paying customers and customers including NVIDIA (whose 40,000 engineers are assisted by AI), Coinbase (every engineer had used Cursor by February 2025), and Upwork (which reports over 25% higher PR volume and more than 100% larger average PR size). Engineers from those orgs are by definition operating in the 6% cohort, regardless of what their resume claims.

This is the core problem with sourcing AI engineers right now: the signal lives in commit graphs and repo conventions, not in titles. Boolean search over LinkedIn does not get you there. That is why we built Refolk. You describe the engineer in plain English ("US-based senior backend engineers with merged PRs in langchain or llama-index in the last 18 months, currently at series A or B startups") and you get a ranked shortlist drawn from GitHub, LinkedIn, and the open web. No string gymnastics.

Don't recreate Gallup's bad incentive at the hiring layer

Jim Harter, Gallup's chief scientist for workplace practice, dropped a warning inside the June 18 coverage that hiring teams should read twice. Employers may start paying attention to how often workers prompt a chatbot per week, he said. "I don't think that's the right direction." Tying performance evaluations to AI usage encourages employees to overuse tools to game the system.

The same logic applies one layer up, at sourcing. Counting "AI commits" without judging the quality of those commits reproduces the dysfunction at the hiring layer. A fully green contribution graph does not mean a great engineer. Some developers game contribution graphs with automated commits or trivial changes. A repo full of chore: bump dependency commits against langchain is not the same as a thoughtful PR fixing a token-counting bug in a RAG pipeline.

Counting AI commits without judging their quality reproduces the dysfunction at the hiring layer. </pull>

The right read is qualitative on top of quantitative. What did the PR change? Did it touch an eval, a prompt template, a retrieval strategy, an agent loop? Did it generate review discussion from named maintainers? Those are the signals that survive gaming.

The attribution gap is also a sourcing tell

One more number worth sitting with. Challenger, Gray & Christmas reported 52,050 US tech layoffs in Q1 2026 alone. Tom's Hardware counted 78,557 tech layoffs from January to early April 2026, with 37,638 attributed to AI and automation. Challenger said AI was the top cited reason for cuts last month, about 40 percent of announcements. But only about 1 percent of laid-off workers attributed their own job loss to AI.

That gap (40% employer attribution, 1% worker attribution) is the story underneath the Gallup number. Workers who got cut don't see AI as the cause, which is exactly why they did not change their tooling on the way out. They are now in your inbound, with the same workflow that got them displaced, and they will tell you in interviews that AI "didn't really affect" their last role. That answer is the screen. It is also a kindness to surface it quickly rather than dragging both sides through five rounds.

What to actually change this quarter

Three concrete moves.

1. Stop screening for "AI proficiency" and start screening for tool stack

Replace the AI-proficiency checkbox with a short structured question: "Walk me through the AI tools in your daily workflow and what each one is for." A good answer names 2 to 4 tools (matching the 70% senior pattern from Pragmatic Engineer), explains the split (e.g., Claude Code for refactors, Cursor for greenfield, ChatGPT for one-off research), and references artifacts (a CLAUDE.md, a prompt library, an eval suite). A weak answer says "I use ChatGPT a lot."

2. Source the 6%, do not wait for them to apply

Inbound is the wrong instrument for this cohort. They are employed and unmoved by job boards. Outbound has to start from artifacts. Pull contributor lists from the AI tool ecosystems (LangChain, LlamaIndex, vLLM, Ollama, OpenAI Agents SDK, Pydantic-AI, CrewAI) and the agent runtimes themselves. For teams that don't want to write the scrapers, this is where Refolk earns its keep: ask in plain English for "people who shipped agent SDK code at startups under 100 headcount" and get a shortlist instead of a Boolean string that has to be tuned for a week.

3. Read the contribution graph like an engineer, not a recruiter

Only 18% of GitHub activity is public (per Octoverse), there is no built-in messaging, and no "open to work" signal. That cap means you cannot scale this manually past a few dozen profiles per week. But the public 18% includes the artifacts that matter most: agent code, eval harnesses, model-provider client work. Read the PRs, not just the green squares. Look for review discussion with named maintainers. Skip the profiles where the graph is suspiciously uniform.

Gallup's 6% versus 18% number is going to get cited a lot over the next six months. The real lesson is not "hire people who use AI." It is that the funnel you built two years ago is now drawing from a structurally different distribution than the one you want. Fix the source, not the screen.

FAQ

Does the Gallup study mean I should reject candidates who don't list AI tools?

No, and that is the wrong frame. Gallup's 18% versus 6% is a population-level statistic, not a per-candidate verdict. Plenty of strong engineers have not centered AI in their workflow yet and will adapt quickly. The actionable read is that your inbound mix has shifted, so you need to look harder at behavior (which tools, in which workflows, with what artifacts) and source actively from cohorts where AI fluency is already evidenced in commits.

Why is Copilot a weaker senior-IC signal than Claude Code or Cursor?

Copilot still leads in enterprise procurement (29% worldwide work adoption per JetBrains), but enterprise procurement and senior IC preference have diverged. When JetBrains asked engineers with 10+ years of experience which tool they would choose for daily work, 46% picked Claude Code and only 9% picked Copilot. That does not make Copilot bad. It means filtering specifically for Copilot experience selects against the senior cohort, where Claude Code and Cursor multi-tool stacking dominates.

How do I source engineers hiding behind "Stealth Startup" on LinkedIn?

You cannot do it from LinkedIn alone, because the title is intentionally uninformative. The workable approach is to start from public artifacts (GitHub commits, conference talks, open-source contributions, blog posts) and use those to identify people whose current employer is opaque. Cross-referencing commit history timing with LinkedIn employment dates often surfaces the stealth employer, or at least narrows it. This kind of cross-source resolution is exactly what Refolk does in one query instead of three tools.

Is commit volume on agent repos enough of a signal?

Volume alone is gameable, as the contribution-graph problem shows. The signal you want is qualitative: PRs that touch substantive code (eval harnesses, retrieval strategy, agent loops, token-handling), review discussion with named maintainers, merged PRs rather than just opened ones, and consistency across multiple repos in the AI ecosystem. Treat the green squares as a starting filter, not a conclusion.