Refolk
November 12, 2026·9 min read

Octoverse's 8x Is a Selection Effect. Git Blame Who Wrote AGENTS.md

Agents started over 40% of GitHub PRs in Octoverse 2026, so commit counts lie. Here's how to git-blame AGENTS.md files to source the engineers who wrote them.

how to hire AI-native engineersAGENTS.mdGitHub Octoverse 2026source engineers on GitHubfind developers who use coding agents
Octoverse's 8x Is a Selection Effect. Git Blame Who Wrote AGENTS.md

GitHub's Octoverse 2026 says agents started more than 40% of pull requests by September. If you source engineers on GitHub by reading contribution graphs and PR counts, a machine now writes a large part of what you're reading. One file in an agent-heavy repo is still mostly written by a person, and that person is the one you want to hire.

What Octoverse 2026 did to GitHub activity as a hiring signal

Octoverse 2026 made commit and PR volume close to meaningless as a hiring signal, because agents started more than 40% of GitHub pull requests in September 2026, up from 17% in March. A busy contribution graph now tells you about someone's tooling at least as much as it tells you about their judgment.

GitHub EVP Jay Parikh presented the report at Universe on October 28, 2026. It counted about 110 million agent-started pull requests in September alone, roughly six times March's volume. An agent-started pull request is one whose first draft came from an agent GitHub can detect.

Two caveats make the signal weaker than it looks:

  • Detected use is a floor. Agents GitHub can't identify don't count, so the true share is likely higher than 40%.
  • GitHub measured merges, not correctness. A merged PR proves somebody clicked approve. It doesn't prove the code was good.

The graph measures throughput, and throughput is exactly what agents add.

40%+
Share of GitHub pull requests started by an agent, September 2026
Up from 17% in March, and GitHub counts only the agents it can detect.

Why the 8x commit figure is a selection effect, and why that helps you

The 8x figure compares averages across new repos only, so it mostly shows that repos with an agent config file are already busy repos, not that the file causes the commits. For a sourcer, that's the useful part. The file filters for a type of engineer.

GitHub's wording is precise: among repositories created this year, the average repo with an agent configuration file logged eight times as many commits as the average new repo without one. GitHub defines an agent configuration file as a repository file that sets up or directs an AI coding agent. It also calls it an AI configuration file or agentic file. The common ones are:

  • AGENTS.md
  • CLAUDE.md
  • .github/copilot-instructions.md
  • .cursorrules

A selection effect is when the group you measure was already different from the comparison group before the thing you're studying happened. Commenters call the 8x a selection effect, and because it compares averages across new repos only, they have a point.

So don't read the 8x as a performance metric. Read it as a filter. Agents inflate the commits. The thing that doesn't inflate is the decision someone made about what the agent should and shouldn't do. The person who made that decision is the signal.

Why a hand-written AGENTS.md shows judgment that commits no longer do

An ETH Zurich study found developer-written context files significantly outperform LLM-generated ones, so a specific, well-kept AGENTS.md is evidence that a person understood how their codebase breaks.

The paper is arXiv:2602.11988 by Gloaguen et al. at ETH Zurich and LogicStar. In the revised version, developer-provided context files improved agent performance by 2.4% on average (p=21%) and significantly outperformed LLM-generated ones (p=3.8%). The first version reported +4% for developer-written files and −3% for generated ones. The revision says neither result is significant on its own. The honest takeaway is about the gap between the two: human-written beats machine-written.

The paper also explains why. Between 95% and 100% of LLM-generated context files included repository overviews, yet agents with those files found relevant files no faster. An overview is inferable, because the agent can read the file tree itself. The paper recommends that human-written files stick to "non-inferable details."

Non-inferable details are things like:

  • A build quirk that only shows up in one environment
  • A pattern or internal API the agent must never use
  • A directory nobody touches without a second reviewer
  • A test that should be retried, not "fixed"

You usually learn rules like these by getting burned. That's why an engineer who writes them down is worth a call.

An agent can read your file tree. It cannot read the outage that taught you to leave billing migrations alone.

Not everyone agrees. Some senior engineers treat any AGENTS.md as a "dark signal" that the code behind it is low quality. Josh Mock, an open-source maintainer, argues the opposite: an AGENTS.md might also be the best protection you have against agent mistakes that slip through review. I side with Mock, with one caveat. Having the file proves nothing. What's written in it is the evidence.

How many of these files exist, and which ones to look for

Few repos have one: an independent GitHub sample found AGENTS.md in 6.2% of active repos, and GitHub code search returns roughly 96,600 root-level AGENTS.md files as of June 2026.

Here's how that dev.to sample broke down across active repos:

  • AGENTS.md: 6.2%
  • CLAUDE.md: 5.4%
  • .github/copilot-instructions.md: 1.1%
  • .cursorrules: 0.7%

The sample's author puts the honest overall answer at roughly 2 to 6%. The official AGENTS.md site still says 60K+ non-fork projects. Its reference spec repo, agentsmd/agents.md, is now governed by the Linux Foundation's Agentic AI Foundation.

The file name is a clue to who wrote it. A CLAUDE.md points to a Claude Code user, copilot-instructions to Copilot, and .cursorrules to Cursor. One change muddies this. Since Claude Code 2.1.277 (September 18, 2026), Claude Code reads AGENTS.md in any project that has no CLAUDE.md. A repo with only an AGENTS.md can't be read as "not Claude" anymore. Posts from August that say Claude Code has "no support" for AGENTS.md were written before that changelog entry and are out of date.

Why searching profiles for "AI-native" finds almost nobody

Keyword searches miss these engineers because almost nobody self-labels: of 7,102 US profiles in Refolk's index that list Claude Code as a skill, only 8 also mention agents in their headline.

Signal (US)CountSource
"GitHub Copilot" listed as a skill9,554Refolk's index
"Claude Code" listed as a skill7,102Refolk's index
Claude Code skill + agent keywords in headline8Refolk's index
Claude Code ÷ Copilot0.74xDerived
Founder titles in a 25-profile Claude Code sample24% (6/25)Derived, small sample

Those 8 profiles are spread across Oracle, Brown Brothers Harriman, Nimbalyst and others. They aren't a talent pool. They show how few people self-label.

0.11%
Claude Code users in Refolk's US index who call themselves agent specialists
8 of 7,102 profiles. Almost nobody puts their agent work in the headline.

The 25-profile samples are directional only, but they hint at who's who. On the Copilot side, titles include CTO (3), Principal Software Engineer (2) and one "Head of Agentic Engineering." On the Claude Code side, 6 of 25 are Founder or Founder/CEO.

Most people seem to list a coding agent the way they list Git: as a skill, not an identity, so it never makes the headline. If you're working out how to hire AI-native engineers, title and headline filters will miss most of them.

That leaves the slow method: read config files, read their commit history, and match handles to people, one repo at a time. Every repo is a separate search and every handle a separate lookup, which is why this kind of search rarely scales past a few candidates.

How to find, read, and git-blame an AGENTS.md: a five-step workflow

Search GitHub code for the config file and read it for non-inferable rules. Then run git log and git blame on it to see who wrote the rules and who keeps them current.

  1. Search for the file. In GitHub code search, query path:AGENTS.md, then repeat for CLAUDE.md, .github/copilot-instructions.md and .cursorrules. Narrow it with org: or with a term your stack would put in the file.
  2. Start from known-good examples. Real AGENTS.md files live in OpenAI Codex, Sentry, Apache Airflow, Temporal, Cloudflare's Workers SDK and Coder. Read a few so you can tell a serious file from boilerplate.
  3. Read the content. Use the table below to sort strong files from weak ones.
  4. Run git log --follow -p AGENTS.md. This lists every change to the file with its diff. It also follows renames, which catches a CLAUDE.md that later became an AGENTS.md.
  5. Run git blame AGENTS.md. Git blame shows, line by line, who last changed each line and in which commit. Check whether the specific, non-inferable rules trace back to one person or several.
Looks generated (weak signal)Looks hand-written (strong signal)
Opens with a repo overviewOpens with rules and constraints
Restates the README and file treeNames specific build quirks
Generic "write clean code" adviceBans named patterns or APIs
One commit, never touched againEdited after incidents and refactors

Step five is where most sourcing stalls. A blame line gives you a commit email or a handle like jdoe-dev, not a person you can pitch. Refolk closes that gap: you describe the engineer in plain English and get back a ranked shortlist that connects the GitHub identity to a real profile.

How to tell a maintained spec from a one-time /init

Look at the file's history over time. In one sample, 50.1% of AGENTS.md files hadn't changed in over 30 days, so a file that keeps changing after incidents and refactors points to someone actively maintaining a spec.

The same dev.to sample found that 9.9% of active repos hadn't touched their AGENTS.md in over 180 days. The repo was moving and the rules for the agent weren't. /init is the command that generates a starter config file from the repo's contents. A single commit containing /init-style output means someone ran a command once.

How to read the history:

  • One commit with an overview-heavy body: a generated file nobody revisited. Weak.
  • Edits that land in the same week as an incident fix or a large refactor: someone is updating the agent's rules as the system changes. Strong.
  • Lines removed over time: pruning inferable content, which fits what the ETH Zurich paper recommends. Strong.
  • Several authors editing the rules: a team practice, and possibly more than one person worth contacting in the same repo.

This is where human judgment shows up in an agent-heavy repo. Agents can produce the commits. Deciding which mistakes to prevent next time is still a person's job.

When you reach out, quote the rule. Name the line in their AGENTS.md, say why the same failure mode matters on your team, and ask for a short conversation about how they run agents on a real codebase rather than sending a job description. Keep a note per candidate with the repo, the line, and the commit date so every message stays specific.

FAQ

What is AGENTS.md?

AGENTS.md is a file in a repository that sets up or directs an AI coding agent: build commands, conventions, banned patterns and files to leave alone. GitHub's Octoverse 2026 groups files like it, CLAUDE.md, Copilot instructions and .cursorrules under "agent configuration files." The reference spec lives at agentsmd/agents.md under the Linux Foundation's Agentic AI Foundation.

Does having an AGENTS.md mean an engineer is good?

No. Most of these files are generated, and 95% to 100% of generated files include a repository overview that doesn't help agents find relevant files any faster. What signals skill is a file full of non-inferable rules that its author keeps updating. Use git blame to see who wrote those rules, then judge the person, not the fact that the file exists.

Is CLAUDE.md a different signal from AGENTS.md?

Somewhat. CLAUDE.md points to a Claude Code user, and in a small sample from Refolk's index, Claude Code users skewed toward founder titles (6 of 25). But since Claude Code 2.1.277 on September 18, 2026, Claude Code reads AGENTS.md when there's no CLAUDE.md, so an AGENTS.md-only repo can belong to a Claude user too.

How do I find developers who use coding agents if they don't list it?

Search the code, not the profiles. Only 8 of the 7,102 US profiles in Refolk's index that list Claude Code mention agents in their headline. Search GitHub for agent config files, read their commit history to find the authors, and match those handles to real profiles. That turns a keyword search with almost no results into a shortlist of people who have shown how they work with agents.

The data behind this

Try it on the search you came here for

Stop building boolean strings. Just describe the person.

Type one sentence. I plan the search, read GitHub, public LinkedIn and Crunchbase records, and the open web as it is right now, and hand back a ranked list with the reason next to every name.

  1. 01Describe them

    One plain sentence. Role, city, stack, stage, whatever matters to you.

  2. 02I read the web live

    GitHub, public LinkedIn and Crunchbase records, the open web. Not a database that went stale last quarter.

  3. 03You read the shortlist

    Ranked, with the reasoning under every name. Open a profile, ask a follow-up, narrow it down.

  • No boolean, no filters, no seat to buy. One box.
  • Read at search time, so a profile updated yesterday counts today.
  • Every step visible as it runs, every name with its reason.

500 free credits on sign-up. No card, no demo call. See real searches.

Read next