Splash's "No Cursor" JD Is a GitHub Problem. Only 62 Engineers Signal It.

A single line in a July 2026 Hacker News "Who is hiring?" post cracked open a hiring problem nobody has tooling for. Splash (splash.tech) told applicants: "AI assistance is fine, but you must be able to produce all your work independently. No Cursor." The filter is real, the pipeline pain is real, and no ATS on the market can execute it.

Why "No Cursor" showed up in a JD at all

Splash isn't anti-AI. It's anti "candidate whose skill collapses when the assistant is off." The JD is a reaction to a specific pipeline failure mode: engineers who pass a take-home with Cursor and then can't reason about a stack trace in a pair session.

The context makes the filter rational:

• Cursor has captured 28% of the professional developer market, per aiexposure.org, with users reporting 2.1x productivity gains over Copilot-in-VS Code setups.
• 84% of developers use or plan to use AI tools (Stack Overflow Developer Survey 2025), 51% daily, and only 29% trust the output to be accurate.
• GitHub Copilot's own share among professional developers fell from 67% to 51% as Cursor and Claude Code ate into it (Stack Overflow, late Dec 2025).
• Andrej Karpathy coined "vibe coding" on February 2, 2025, describing the practice of "fully giving in to the vibes" and forgetting the code exists. That's the behavior Splash is filtering against.

When 51% of pros use an assistant every day and 29% trust the output, "senior engineer" and "can debug without an assistant" are no longer the same set. That's the gap the "No Cursor" line is trying to name.

The filter is unenforceable in any ATS. That's the point.

You cannot boolean-search your way to "engineers who can code without Cursor." The public signal doesn't exist at scale, so Splash pushed the filter to self-selection at the JD layer instead of screening at the ATS layer.

Here's the count from Refolk's index of U.S. professional profiles:

The 62 engineers who publicly claim Cursor as a skill cluster at Chewy, Snowflake, Klaviyo, Extend, DroneDeploy, Verizon, and Branch, concentrated in Boston, NYC, and Denver. That's the entire visible surface area for LinkedIn-style filtering in a country with 347,804 backend engineers.

1,500x

The mechanism is simple. Skill tags on LinkedIn are performative and lag reality. Engineers tag "Kubernetes" and "TypeScript" because recruiters search for those; nobody has been trained yet that "Cursor" is a searched term. So the ratio between actual adoption (28%) and public claim (0.018%) is roughly 1,500 to 1. Any recruiter using skill filters to either include or exclude AI-native candidates is looking at noise.

What the real signal looks like

The real filter isn't "does the profile say Cursor." It's meaningful public commits from 2018 to 2022, before Copilot GA in June 2022 and before Cursor's rise. That's a GitHub question, not a LinkedIn question.

Concretely, the signals that correlate with "can produce work independently":

1. Commit density predating June 2022. Not just one repo. A pattern of small, coherent commits across side projects and OSS contributions.
2. Low-dependency projects. A CLI written in Go with three imports beats a Next.js app with a bloated transitive tree every time.
3. Contributions to compilers, runtimes, or protocol implementations. These are the projects where you can't fake understanding by pasting a diff. In Refolk's index, only 3 U.S. engineers carry both "compilers" and "systems programming" in headline or keywords, at Meta, NSite.ai, and DST Output. The signal is real but too sparse to source from directly.
4. Issue comments and code review history. Reading someone's PR reviews on a mid-sized OSS project tells you more in ten minutes than any take-home.
5. Non-LLM-adjacent OSS. Contributions to Postgres, LLVM, CPython, Zig, or Nix are much harder to vibe-code than yet-another-RAG-wrapper.

Splash gets this. Their JD asks for "a git/bitbucket/source-forge project representing the candidate's coding, or a small test project." They're explicitly routing around the ATS and looking at the repo.

The problem is doing that at pipeline scale. You can inspect 5 candidates' GitHub history manually. You cannot inspect 500. This is the exact gap Refolk closes: describe the engineer you want in plain English, and get a ranked shortlist that reads GitHub, LinkedIn, and the open web together instead of one at a time.

The bifurcation inside the same HN thread

The July 2026 "Who is hiring?" thread contains both poles of the market, and that's the actual news. Splash sits at one end. We The Flywheel sits at the other, hiring "AI-Native Engineers & Operators" with the framing "AI does the heavy lifting here, but it's the leverage, not the point." PlantingSpace and Airspace Intelligence sit in between, emphasizing hard problems without picking a side.

The market isn't consolidating on either side. Two hiring funnels are forming inside the same talent pool.

Founders should read this correctly. It is not a values war. It is a bet on which cohort will be more valuable in 2028:

• The "No Cursor" bet. Junior hiring is down 35% from 2023, bootcamp enrollment is down 40%, and 77% of pros now use AI assistants daily. The mid-level pool three to five years out will be structurally thin on engineers who trained on fundamentals. If that thesis is right, "No Cursor" hires get scarcer and more valuable every year.
• The "AI-native" bet. AI engineer roles have grown 300% in the same period. If leverage compounds faster than fundamentals decay, the Flywheel cohort wins.

Neither bet is obviously wrong. But they require different sourcing motions, different interview loops, and different comp bands. Treating them as one pipeline is how you end up with a JD that lists "No Cursor" and a take-home that anyone can vibe-code in an hour.

How to actually source the "No Cursor" pool

Stop searching skill tags and start scoring GitHub histories. The signal is in commit patterns from 2018 to 2022, OSS depth, and dependency minimalism. Here is a concrete motion.

1. Anchor on pre-Copilot commit density

Copilot went GA in June 2022. Any candidate with a sustained pattern of meaningful commits across 2018 to 2022 has demonstrated independent problem-solving on the record. This is the closest thing to a verifiable "can code unaided" signal that exists.

2. Score dependency graphs, not stars

A small Rust project with a handful of dependencies is a stronger signal than a 4,000-star Next.js template. LLM-assisted code tends to over-import. Manual code tends to reach for the standard library first. You can score this at scale.

3. Use OSS review history as the interview

Every serious OSS contributor has left review comments on other people's PRs. Those comments are the most honest possible signal of how someone thinks about code. They are also invisible to LinkedIn and every ATS. Reading three of a candidate's reviews on Postgres beats a leetcode question as a screen.

4. Reject the skill filter, keep the JD filter

Splash's approach is right: put the filter in the JD ("No Cursor," "produce all your work independently") to shape self-selection, then verify at the repo layer. Do not try to reproduce it as a boolean in Greenhouse. It will not work.

5. Build a second, parallel funnel for the AI-native pool

If you also want Flywheel-style engineers, do not run them through the same loop. Different signals (agent orchestration, eval harnesses, prompt discipline), different interview, different offer letter. Trying to hire both from one pipeline is what produced the "No Cursor" line in the first place.

62

What this means for cursor ban job postings going forward

Expect more of them, and expect most of them to be badly written. The "No Cursor" line in a JD is a legitimate self-selection tool, but only if the rest of the process actually verifies the claim. A JD that says "No Cursor" followed by a take-home that any Cursor user can complete in 40 minutes is worse than no filter at all, because it filters out honest candidates and keeps dishonest ones.

The founders and eng leaders getting this right are doing three things in combination:

1. Naming the filter in the JD to shape the top of the funnel.
2. Asking for a repo (Splash's exact move) instead of a take-home that can be vibe-coded.
3. Sourcing on GitHub history, not on skill tags, to actively pull candidates who signal the trait without needing to be told to.

That third step is the one every team underinvests in. Ask Refolk for senior backend engineers with sustained pre-2022 OSS contributions and no LLM-wrapper projects, and you get the pool that would pass Splash's filter without ever seeing the JD.

The Splash listing is a leading indicator, not a fringe post. When 51% of your competitors' engineers use an assistant daily and only 29% trust the output, a "can code unaided" filter is not nostalgia. It is risk management. The teams that can source for it before the phrase becomes standard JD boilerplate will have a head start on a pool that is getting structurally scarcer.

FAQ

Is "No Cursor" actually a growing trend or a one-off?

The July 2026 Splash listing is the earliest widely-shared explicit instance, but the underlying pipeline problem is old. With 77% of pros using AI assistants daily and junior hiring down 35% from 2023, more companies will name the filter explicitly in JDs. Expect the phrasing to standardize the way "no take-homes" and "async-first" did before it.

Can I just search LinkedIn for engineers who don't list Cursor as a skill?

No. Only 62 U.S. engineers out of 347,804 publicly claim Cursor as a skill, against real adoption of roughly 28%. The gap between usage and public signal is about 1,500 to 1, so "no Cursor listed" tells you essentially nothing. The signal you actually want is GitHub commit density before mid-2022 and depth in non-LLM OSS, which requires reading repos, not skill tags.

What's the fastest way to score a candidate for "can code without an assistant"?

Open their GitHub, filter commits to 2018 through mid-2022, and read three of their PR review comments on any project they contributed to. Ten minutes of that gives you more signal than a 90-minute interview. If they have no pre-2022 history, that is not disqualifying, but it does move the burden of proof to the live pairing session.

Should I run one hiring pipeline or two?

Two. The July 2026 HN thread shows Splash ("No Cursor") and We The Flywheel ("AI-Native") hiring in the same window with opposite criteria. They require different sources, different interviews, and different comp structures. Trying to serve both funnels with one loop is what produces the pipeline pollution that made "No Cursor" a JD line in the first place.