GitHub Contributions Are Now a Broken Hiring Signal

GitHub contributions are no longer a reliable hiring score. The activity graph adds up unlike events; it does not measure engineering quality, and AI makes visible activity cheaper to produce. Use GitHub to find one or two artifacts, then score relevance, understanding, verification, review response, impact, and ownership. Offer an equivalent route for candidates whose best work is private.

The green square is not dead. The shortcut is.

Why did GitHub contribution counts stop working as a hiring shortcut?

GitHub contribution counts stopped working as a hiring shortcut because producing visible activity became cheaper while reviewing its value remained expensive. That change amplified a flaw that was always present: the count measures actions, not whether those actions made a project better.

Neil Alexander captured the tension in a June 2026 post about three Claude-coauthored pull requests. A contributor corrected spelling and grammar in code comments. The changes were harmless and correct, but Alexander closed them because they consumed review time without materially improving the project. He suspected the activity was meant to pad a CV.

That last part is an inference, not a fact. The contributor did not confirm a career motive. When the post reached Hacker News, commenters challenged the decision, argued that correct typo fixes still have some value, and pointed out that contribution spam predates generative AI. Those objections matter. A fair hiring process cannot infer dishonesty from a small patch or punish a candidate merely for using an assistant.

The broader problem of limited attention is real. In January 2026, GitHub said maintainers were facing a growing volume of low-quality contributions, including submissions that ignored project guidelines, were abandoned, or were AI-generated. In May, GitHub described the bottleneck more precisely: generating pull requests, issues, comments, and reports had become much easier, while review still depended on scarce human attention. GitHub explicitly said the challenge was broader than AI.

The company then shipped controls to disable or restrict pull requests and to cap concurrent pull requests from contributors without write access. Product changes do not prove that applicants are padding their CVs. They do show that contribution volume can impose a real cost before anyone knows whether a change is useful.

The strongest recent evidence from the ecosystem points in the same direction, with important limits. A July 2026 preprint studied 294 popular, active repositories and more than 1.2 million pull requests. Compared with a modeled counterfactual, the authors estimated that 2025 pull-request volume rose 6.80%, while the overall merge ratio fell 1.06%. Pull requests from one-time contributors rose 5.84%, and their merge rate fell 18.18%.

Those figures do not prove that AI caused the change. The researchers used 2025 as a proxy for widespread AI adoption, did not observe individual tool use, and could not rule out platform growth or other ecosystem shifts. Their sample also favors popular, newcomer-oriented repositories. The safe conclusion is narrower: in that sample, more visible activity said less about whether a pull request would merge.

Spam itself is not new. DigitalOcean’s Hacktoberfest 2020 recap recorded 621,104 pull requests, including 9,598 marked spam or invalid and 34,595 not accepted. Organizers made the event opt-in after a surge of poor-quality submissions. AI did not invent the incentive problem. It lowered the cost of exploiting it.

What does a green square actually measure?

A GitHub green square measures qualifying activity under GitHub’s display rules. It does not measure difficulty, correctness, usefulness, authorship, or job performance. Two identical-looking graphs can represent very different work, and two equally capable engineers can have completely different graphs.

GitHub’s contribution reference makes the mismatch plain. Creating a repository or fork always counts. Issues, pull requests, reviews, discussions, answers, and commits count only when they meet specific conditions. A pull request does not need to merge to appear. Some displayed event types are capped.

Commit visibility has its own constraints. The commit email must connect to the account. The work must be in a standalone repository, usually on the default or gh-pages branch, and the person must meet an additional relationship condition. Private work can appear as a number with no inspectable detail. When accounts are merged, attribution for issues, pull requests, and discussions can be lost. Rebasing can credit both the original author and the person who performed the rebase.

That creates two errors if you use the graph as a screening score:

• False positives: a dense graph can contain forks, unmerged pull requests, automated activity, cosmetic changes, or work whose value you have not inspected.
• False negatives: a sparse graph can hide years of private company work, security restrictions, disconnected commit emails, work on branches GitHub does not count, or simply no desire to volunteer in public.

More activity can still point you toward useful evidence. It just cannot be the evidence itself. Do not count stars, repositories, commits, streaks, or merged pull requests and turn the total into a candidate rank. Even a small numeric weight turns a non-comparable activity display into a hiring score.

Older hiring research shows why the shortcut persists. In a 2016 study, nine participants assessed five developer profiles. Eight used commit number or frequency during initial screening because those cues were easy to compare. Participants from larger companies were more likely to inspect contribution type and quality later; participants from smaller companies relied mostly on breadth and project reputation. The study is tiny and does not test later job performance, but it exposes a familiar failure: what is easiest to count displaces what you actually need to know.

No study located for this article establishes that GitHub contribution volume predicts on-the-job performance. Public work can reveal valuable behavior. The count cannot tell you which behavior occurred.

Does AI-assisted open-source work still count?

Yes. AI-assisted open-source work can be strong portfolio evidence when the candidate understands, verifies, and owns it. The useful dividing line is accountable work versus output the candidate does not understand, not human typing versus machine generation.

A 2026 study of contribution guidelines reviewed 1,000 popular GitHub repositories and found 118 explicit AI policies. Of those policies, 78% allowed AI-assisted work, 51% required disclosure, and 74% required a human in the loop. The sample does not represent every repository, but it directly contradicts the idea that established projects generally reject AI use.

Across projects, current policies ask for similar observable evidence:

• LLVM asks contributors to read, review, and explain generated work. It calls a contribution “extractive” when the expected review cost exceeds the benefit to the project.
• Linux requires a human sign-off. AI-assisted bug findings should include a reproducer, a fix, build or test evidence, and an honest account of anything not verified.
• pytest welcomes AI assistance but closes fully agentic submissions when no human can participate meaningfully in review.
• OpenXLA accepts labeled AI-generated work tied to a real problem, test, or benchmark when the author understands it.
• curl accepts AI-assisted pull requests under its normal standards for code quality, tests, and documentation.

curl also offers a useful counterpoint. Its bug-bounty program saw the confirmed-report rate fall from above 15% historically to below 5% in 2025 amid AI-heavy and reward-seeking submissions, contributing to the decision to end cash bounties. By April 2026, maintainer Daniel Stenberg reported that volume had doubled and the confirmed-report rate had recovered to 15–16%, even though almost every report appeared AI-assisted.

That is one project’s experience, not a universal rate. Still, it shows why “Was AI used?” is a weak hiring question. Incentives, verification, relevance, and human ownership determined whether the output helped. Your portfolio review should test the same things.

If you want to assess how someone works with AI during a live exercise, that is a separate design problem. Our guide to AI-enabled technical interviews covers it. For portfolio review, do not attempt AI detection. Ask the candidate to explain and defend the artifact.

How should you review a developer’s GitHub portfolio?

Review one or two role-relevant artifacts with the same six-part rubric for every candidate. A focused sample reveals more than a profile-wide count and keeps the workload small enough for careful review.

Start by choosing an artifact with enough context to inspect. It might be a pull request, a design discussion, a bug report with a reproducer, a release the candidate maintained, or a repository they own. Prefer work relevant to the role, but do not assume famous projects produce better evidence. A modest patch can show excellent judgment.

Then score these six criteria:

Do not treat a merged pull request as automatic proof of quality. Merge decisions reflect project scope, maintainer availability, timing, and social context as well as code. A rejected proposal can still be strong evidence if the candidate found a real problem, tested a defensible approach, responded well to feedback, and can explain why the project chose another path.

The reverse is also true. A merged typo fix may be useful to the project but tell you little about systems-level judgment. Score what the artifact demonstrates for this role, not the badge attached to it.

Ask every candidate the same three questions:

1. What problem were you solving, and how did you know it mattered?
2. What evidence would prove your change wrong?
3. What changed after review, and what would you do differently now?

These questions make it harder to fake authorship. A person who copied an answer they do not understand will struggle to connect the problem, evidence, and revision history. A person who used AI responsibly can explain the same chain of decisions clearly. A beginner can also score well on a small contribution because the rubric rewards judgment and learning rather than size.

Record the artifact, the answers, and the evidence for each score. The point is not to turn qualitative work into fake precision. It is to stop reputation, streak length, employer brand, or the first reviewer’s enthusiasm from silently changing the standard.

What should you do when a candidate has no public GitHub work?

Give candidates without useful public work an equivalent way to demonstrate the same competencies. A GitHub profile should be optional because absence of public activity is not evidence of low skill.

Ask for one artifact from any acceptable source:

• public open-source work;
• private professional work the candidate can describe without exposing confidential details;
• a school, volunteer, or hobby project;
• an architecture note, incident retrospective, or technical decision they can discuss;
• a short equivalent exercise supplied by your team.

Let candidates redact names, metrics, and proprietary details. You need the problem, their specific action, the verification method, the outcome, and what they learned. You do not need their former employer’s source code.

When no existing artifact works, use a representative task that tests a critical entry competency. Keep it short, avoid free product work, and do not test something the person would reasonably learn after joining. Our guide to structuring code assignments covers task scope, candidate instructions, and review mechanics. The assignment is an access route, not a punishment for having private work.

Use the same core rubric for every route. Verification in public OSS may appear as a reproducer and maintainer review. Verification in a private project may be a test plan and incident outcome. Verification in a short exercise may be a regression test and explanation. The artifacts differ, but the competency does not.

This equivalence also prevents spare time from becoming a hidden merit test. Public contribution favors people with permission, spare time, and work they are allowed to show. A fair process does not require unpaid public labor to make private experience count.

How do you turn portfolio evidence into a defensible hiring decision?

Convert the artifact review into a structured evidence record, then keep it in proportion. Portfolio evidence should answer a specific question about work the candidate can demonstrate. It should not become a general character judgment or decide the hire by itself.

Have reviewers score independently before discussing the candidate. Require a short evidence note for each criterion. During debrief, focus on meaningful score differences. Ask which artifact detail one reviewer saw that another missed, and whether the anchor needs clarification.

This is where portfolio review connects to the rest of the hiring process without taking it over. A strong artifact can shape a focused follow-up. It should not excuse weak evidence in role-critical areas the artifact does not cover. A backend pull request might reveal debugging and review behavior while saying nothing about stakeholder communication or operational ownership.

Broad selection research favors structure over improvisation. A 2023 synthesis estimated corrected operational validity at .42 for structured interviews, .33 for work samples, and .19 for unstructured interviews. Those are broad occupational estimates with substantial variation, not software-specific guarantees. They support a design principle, not a promise about your particular rubric.

Define the criteria before reviewing candidates. Ask consistent questions. Train reviewers on the anchors. Preserve independent scores before the debrief. Our guide to structured interview scorecards explains the wider scoring system. The portfolio rubric should feed that system as one evidence source, not sit beside it as an informal veto.

Audit the process after several hires. Check whether reviewers apply the anchors consistently, whether one route advances candidates more often than equivalent routes, and whether portfolio scores align with evidence from later stages. Do not claim predictive validity you have not measured.

How can Kit run the evidence trail without pretending to verify authorship?

Kit can standardize the evidence trail: a private assignment repository, a clear deadline, named reviewers, blind scorecards, and an attributed human decision. It does not detect AI, capture prompts, or prove who wrote the code.

When a candidate needs the equivalent-work route, Kit’s GitHub integration can create a private repository from your template, invite the candidate, track the deadline and extensions, add eligible reviewers, and archive the repository after completion. Candidate-facing instructions appear in the portal and assignment materials. Kit creates the repository, not a pull request.

Pair the code-assignment stage with a team-review stage. Put the six criteria into that review, ask reviewers to score independently, and discuss the evidence only after scores are submitted. Kit supports blind-until-submitted reviews, weighted criteria, comments, thresholds, and an attributed human decision. It does not place structured criteria directly on the code-assignment stage, so the two-stage pairing matters.

Keep the AI rule in the candidate-facing instructions. Ask candidates to disclose the tools they used if that context helps your review, but do not present disclosure as authorship verification. The evidence still comes from what they can explain, test, revise, and own.

GitHub remains useful because public code and review history can make real engineering behavior inspectable. What is broken is treating accumulated activity as a score. Sample the work, apply the same six criteria, offer an equivalent route for private experience, and carry the evidence into a structured decision.

To run the same evidence trail for every engineering candidate, start a free Kit trial and build the portfolio or assignment review into your hiring pipeline.