Only 82 Engineers List "Cursor" as a Skill. Screen Differently.

On May 5, 2026, Coinbase cut about 700 jobs (roughly 14% of its workforce) and said the survivors will be reorganized into "AI-native pods," some of which could be a single person directing agents that cover eng, design, and PM. Reporting that same week revealed Brian Armstrong had previously bought every engineer Cursor and GitHub Copilot licenses and demanded onboarding by the end of the week. Engineers who missed the deadline got fired. AI-tool fluency is now an explicit hiring and retention bar, and recruiters need a way to screen for it before a candidate ever hits the inbox.

Here is the catch. If you Boolean-search "Cursor" or "Copilot" on LinkedIn, you will miss almost everyone who actually qualifies.

The résumé signal is broken

In our internal index of public profiles, only 82 U.S.-based software engineers explicitly list "Cursor" as a skill. The top employers in that tiny set include Uber, Microsoft, Intuit, and Lockheed Martin, which tells you something on its own: the people who self-declare Cursor are mostly enterprise engineers performing the credential, not the AI-native builders Coinbase is trying to hire.

82

Meanwhile the Stack Overflow 2025 Developer Survey shows 80% of developers now use AI tools, 51% of professional developers use them daily, and Cursor adoption hit 18% on its own. Cursor (Anysphere) closed a $900M Series C at a $9.9B valuation in June 2025 with over $500M ARR and usage in more than half the Fortune 500. GitHub Copilot has crossed 20 million cumulative users and sits inside 90% of the Fortune 100. The population is huge. The self-declared subset is statistical noise.

So sourcing AI-native engineers cannot be a keyword exercise. It has to be triangulation: commit shape, repo artifacts, public writing, and how candidates talk about the tools they use.

What "AI-native" actually looks like in public

Stop searching for tool names in skills sections. Start searching for the artifacts those tools leave behind.

Repo-level signals

These are the files that show up when an engineer is genuinely living inside an AI-assisted workflow:

• .cursorrules and .cursor/rules/ directories. The engineer has tuned Cursor for their codebase. They are not just hitting Tab.
• AGENTS.md files. A growing convention for documenting how agents should operate inside a repo. Strongly correlated with Claude Code and multi-agent workflows.
• MCP server repositories. Model Context Protocol servers are how engineers extend Claude Code, Cursor, and Windsurf with custom tools. Building one is a stronger signal than using one.
• Contributions to cursor.directory or published prompt libraries. Public taste in prompts is rare and hard to fake.
• Eval harnesses. Repos with evals/ directories, LLM-as-judge scripts, or golden datasets. This is the engineer who knows when the model is wrong, which is the rarer hire.
• Commit messages that reference agent runs, PR descriptions noting "generated with Claude Code, reviewed by hand," or paired commits showing the human-in-the-loop edit.

Writing-level signals

Blog posts, conference talks, and Twitter/X threads where the candidate has an opinion about which tool to use when. The engineers worth hiring into a Coinbase-style pod will tell you, in their own words, why they prefer Cursor for greenfield TypeScript and Claude Code for refactors, or why they ripped Copilot out of a Rust project. Specificity is the tell.

Cadence signals

A genuine AI-native engineer's GitHub graph often looks different post-2024: more frequent, smaller commits; PRs that touch more files but stay coherent; an uptick in solo side projects shipped in a weekend. None of these alone prove anything. Together, against a candidate who also publishes about agent orchestration, they form a stack.

This is the work that makes a Boolean search useless and a semantic search valuable. Describing the candidate in plain English ("senior backend engineer in NYC who has shipped an MCP server and writes publicly about Claude Code") and getting a ranked shortlist back is the screening loop that matches the new bar. That is exactly what we built Malinois for.

The trust paradox sitting inside the Coinbase mandate

Armstrong is forcing daily AI use at the same moment the data is getting more skeptical, not less. Stack Overflow's 2025 survey shows trust in AI accuracy has fallen from 40% in prior years to 29%. METR ran a randomized controlled trial on 16 experienced open-source developers between February and June 2025: the half using AI tools were 19% slower, while believing they were 20% faster. Faros AI's telemetry across 10,000+ developers and 1,255 teams found AI adoption correlated with a 9% increase in bugs per developer.

The hire you want is not the prompt-spammer. It is the engineer who can tell when the model is wrong.

The takeaway for screening is sharp: "AI-native" cannot mean "uses AI for everything." It has to mean "knows when to use it and when to override it." Coinbase wants 50% of its code AI-generated by quarter-end (up from 33%). The pods that hit that target without shipping a 9% bug regression will be the ones with engineers who treat the tool with informed skepticism.

So when you build a screen, weight evidence of judgment as heavily as evidence of usage. A blog post titled "Why I turned Copilot off in our payments service" is a stronger signal than a LinkedIn endorsement for "AI tools."

19%

Cursor vs. Copilot signals different archetypes

The Coinbase license bundle was both tools, but in the wild they correlate with different workers.

For GitHub-centric enterprises, Copilot is the default and Cursor shows up for designated advanced workflows. For AI-native startups with lighter governance overhead, Cursor is the default. If you are sourcing for a Coinbase-style one-person pod, weight Cursor and Claude Code artifacts more heavily. If you are sourcing for a regulated bank with Copilot Enterprise, the opposite. Both are legitimate. They just point to different humans.

The broader landscape recruiters should be able to recognize on a profile: IDE extensions like Copilot, Cline, and Continue; dedicated AI IDEs like Cursor, Windsurf, Zed, Google Antigravity, and Kiro; CLI tools like Claude Code, Aider, Codex, Gemini CLI, and Goose; and cloud agents like Devin, OpenHands, and Jules. A candidate who has opinions across at least two of those four buckets is operating at the level Coinbase is trying to hire for.

The "AI-native pod" is a different JD, not just a different tool list

This is where most hiring teams will get it wrong. They will read the Coinbase memo, add "Cursor proficiency" to the requirements section, and otherwise leave the JD alone. That misses the structural change.

A one-person pod owns eng, design, and product. The screening signal is therefore agent orchestration, not autocomplete. Look for:

• Multi-agent OSS projects. Engineers running a planner + executor + critic loop in public.
• Custom evals. Repos that benchmark their own agents against tasks. This is the discipline that separates pod-ready engineers from prompt hobbyists.
• End-to-end shipped artifacts. Solo founders who took something from Figma-equivalent design to deployed product, often visible in YC W25-style profiles where 25% of startups report codebases that are 95% AI-generated.
• Writing about the workflow, not the tool. "How I run a three-agent loop for migration PRs" is a stronger signal than "I love Cursor."

GitClear's analysis of 211 million changed lines estimated 41% of code committed globally in 2025 was initially generated or suggested by AI. The pod-ready engineer is not the one contributing to that number. It is the one who can show, on GitHub, that their contribution to that number was deliberate and reviewed.

A practical screen you can run this week

Here is a pipeline that works against the actual signal, not the résumé keyword.

1. Define the archetype. Cursor-default startup builder, or Copilot-Enterprise regulated-shop engineer? The artifacts are different. Pick one.
2. Search by artifact, not by skill. GitHub code search for .cursorrules, AGENTS.md, mcp.json, or evals/ in repos owned by individuals (not orgs). Cross-reference with location and seniority.
3. Read the writing. Pull the candidate's last three blog posts or long-form threads. If none exist, downgrade. If they have an opinion about a tool's failure mode, upgrade.
4. Check the cadence. Has commit frequency increased since mid-2024 without a corresponding drop in PR coherence? Good. Has it increased while PRs ballooned to 4,000-line diffs of churn? Bad.
5. Open with the artifact. First-message reference rate triples when the opener cites a specific repo or post instead of a generic "saw your profile."

Running this manually for a list of 200 candidates is a week of work. Running it as a single plain-English query (Cursor proficiency hiring, GitHub Copilot screening, Coinbase AI-native pods, all in one prompt) is the loop Malinois compresses. You describe who you want, you get back the engineers whose public artifacts actually match, and you skip the 82-person self-declared trap.

The Coinbase memo is a leading edge, not an outlier

Armstrong is the named example because the firing quote ("some of them had a good reason... and some of them didn't and they got fired") is unusually blunt. But CEOs at Google, Microsoft, and Shopify have already mandated or strongly encouraged AI use across engineering. Treat Coinbase as the moment the screening bar became explicit, not as a one-off. Recruiters who get good at AI-assisted coding signals now will have a six-month head start when the next public mandate lands.

The cost of not adapting is straightforward: you will keep sourcing from a self-declared pool of 82 people, while your competitors are sourcing from the actual pool of tens of thousands.

FAQ

Should I just add "Cursor" or "Copilot" to my Boolean string?

No. The self-declared population is too small and skewed toward enterprise credential-keepers. Search for artifacts (.cursorrules, AGENTS.md, MCP servers, eval harnesses) and for public writing about specific tool tradeoffs. Tool names in a skills section are the weakest signal in the stack.

How do I tell a "prompt spammer" from a real AI-native engineer in 10 minutes?

Open their last merged PR. If the diff is coherent, the description references a workflow (not just "added feature"), and there is evidence of review or eval, you have a real one. If the PR is a 3,000-line dump with a one-line description and inconsistent style across files, you are looking at someone who lets the agent commit unreviewed.

Does this mean I should stop hiring engineers who are skeptical of AI tools?

The opposite. METR's RCT and Faros AI's bug data both suggest skepticism is the rare and valuable trait. The hire you want is the engineer who uses Cursor or Claude Code daily and can articulate when they turn it off. Screen for judgment, not enthusiasm.

What changes for sourcing if a company adopts the "AI-native pod" model?

The JD shifts from a single function to a small bundle (eng + design + PM-lite), and the screening signal shifts from autocomplete fluency to agent orchestration. Look for multi-agent OSS, custom evals, and end-to-end shipped solo projects. Weight breadth and shipping cadence more heavily than depth in any one stack.