GitHub-Beiträge sind kein verlässliches Einstellungskriterium mehr

GitHub-Beiträge sind kein verlässlicher Maßstab mehr für Einstellungsentscheidungen. Das Beitragsdiagramm erfasst die Menge verschiedenster Vorgänge, nicht die Qualität der Entwicklungsarbeit. KI macht es zudem leichter, sichtbare Aktivität zu erzeugen. Nutzen Sie GitHub als Verzeichnis für ein oder zwei Arbeitsproben. Bewerten Sie dann Relevanz, Verständnis, Überprüfung, Reaktion auf Rückmeldungen, Wirkung und Verantwortung. Bieten Sie Kandidatinnen und Kandidaten, deren beste Arbeit nicht öffentlich ist, einen gleichwertigen Weg an.

Das grüne Kästchen ist nicht tot. Die Abkürzung über die reine Zahl schon.

Warum taugen GitHub-Beitragszahlen nicht mehr als Abkürzung bei der Einstellung?

GitHub-Beitragszahlen haben als Abkürzung ausgedient, weil sichtbare Aktivität immer billiger zu erzeugen ist, während ihre Bewertung aufwendig bleibt. Dadurch tritt ein alter Fehler deutlicher hervor: Die Zahl erfasst Handlungen, aber nicht, ob sie ein Projekt tatsächlich verbessert haben.

Neil Alexander beschrieb dieses Spannungsfeld im Juni 2026 anhand von drei gemeinsam mit Claude verfassten Pull Requests. Ein Mitwirkender korrigierte Rechtschreibung und Grammatik in Code-Kommentaren. Die Änderungen waren korrekt und harmlos. Alexander schloss sie dennoch, weil ihre Prüfung Zeit kostete, ohne das Projekt wesentlich zu verbessern. Er vermutete, dass die Aktivität den Lebenslauf aufwerten sollte.

Der letzte Punkt ist eine Vermutung, keine Tatsache. Der Mitwirkende bestätigte kein berufliches Motiv. Als der Beitrag Hacker News erreichte, widersprachen Kommentatoren der Entscheidung. Sie hielten auch korrekte Tippfehlerkorrekturen für nützlich und wiesen darauf hin, dass Spam-Beiträge schon vor generativer KI existierten. Diese Einwände sind wichtig. Ein faires Einstellungsverfahren darf aus einem kleinen Patch weder Unehrlichkeit ableiten noch einen Kandidaten allein für den Einsatz eines Assistenten bestrafen.

Das grundsätzliche Problem knapper Aufmerksamkeit ist dennoch real. Im Januar 2026 berichtete GitHub von einer wachsenden Zahl minderwertiger Beiträge, die Maintainer belasteten. Darunter waren Einreichungen, die Projektregeln missachteten, aufgegeben oder mit KI erzeugt wurden. Im Mai beschrieb GitHub den Engpass genauer: Pull Requests, Issues, Kommentare und Berichte ließen sich viel leichter erzeugen, doch die Prüfung beanspruchte weiterhin knappe menschliche Aufmerksamkeit. GitHub betonte ausdrücklich, dass das Problem über KI hinausgeht.

Anschließend führte das Unternehmen Funktionen ein, mit denen sich Pull Requests deaktivieren oder beschränken lassen. Außerdem können Repositories begrenzen, wie viele Pull Requests Personen ohne Schreibzugriff gleichzeitig offen haben dürfen. Diese Produktänderungen beweisen nicht, dass Bewerber ihre Lebensläufe aufpolstern. Sie zeigen aber, dass Beitragsmengen echte Kosten verursachen können, noch bevor jemand ihren Nutzen beurteilt hat.

Die derzeit stärkste Untersuchung auf Ökosystemebene weist mit wichtigen Einschränkungen in dieselbe Richtung. Ein Preprint vom Juli 2026 untersuchte 294 populäre, aktive Repositories und mehr als 1,2 Millionen Pull Requests. Im Vergleich zu einem modellierten kontrafaktischen Verlauf schätzten die Autoren, dass die Zahl der Pull Requests 2025 um 6,80 % stieg, während die gesamte Merge-Quote um 1,06 % sank. Pull Requests von Personen mit nur einem Beitrag nahmen um 5,84 % zu; ihre Merge-Quote fiel um 18,18 %.

Diese Zahlen beweisen nicht, dass KI die Entwicklung verursacht hat. Die Forschenden verwendeten das Jahr 2025 als Näherungswert für die weite Verbreitung von KI, beobachteten aber nicht den individuellen Werkzeugeinsatz. Auch Plattformwachstum und andere Veränderungen im Ökosystem konnten sie nicht ausschließen. Ihre Stichprobe bevorzugt zudem populäre Repositories, die sich an neue Mitwirkende richten. Zulässig ist daher nur ein enger Schluss: In dieser Stichprobe sagte mehr sichtbare Aktivität weniger darüber aus, ob ein Pull Request zusammengeführt würde.

Spam ist ebenfalls kein neues Phänomen. Der offizielle Hacktoberfest-Rückblick 2020 von DigitalOcean verzeichnete 621.104 Pull Requests. Davon waren 9.598 als Spam oder ungültig markiert, weitere 34.595 wurden nicht angenommen. Nach einer Welle minderwertiger Einreichungen stellten die Veranstalter das Programm auf freiwillige Teilnahme der Projekte um. KI hat den Fehlanreiz nicht erfunden. Sie hat nur seine Ausnutzung verbilligt.

Was misst ein grünes Kästchen tatsächlich?

Ein grünes GitHub-Kästchen misst Aktivitäten, die nach GitHubs Anzeigeregeln als Beiträge zählen. Es misst weder Schwierigkeit noch Korrektheit, Nutzen, Urheberschaft oder Arbeitsleistung. Zwei gleich aussehende Beitragsdiagramme können völlig unterschiedliche Arbeit abbilden. Umgekehrt können zwei gleich fähige Entwickler vollkommen verschiedene Beitragsdiagramme haben.

GitHubs Referenz zu Beiträgen macht die Diskrepanz deutlich. Das Erstellen eines Repositorys oder Forks zählt immer. Issues, Pull Requests, Reviews, Discussions, Antworten und Commits zählen nur unter bestimmten Bedingungen. Ein Pull Request muss nicht zusammengeführt sein, um zu erscheinen. Bei einigen angezeigten Vorgangsarten begrenzt GitHub zudem die Anzahl.

Für die Sichtbarkeit von Commits gelten eigene Regeln. Die Commit-E-Mail muss mit dem Konto verknüpft sein. Die Arbeit muss in einem eigenständigen Repository liegen, in der Regel im Standard- oder gh-pages-Branch. Außerdem muss eine weitere Bedingung zur Beziehung der Person mit dem Repository erfüllt sein. Private Arbeit kann nur als Zahl ohne prüfbare Details erscheinen. Beim Zusammenführen von Konten kann die Zuordnung von Issues, Pull Requests und Discussions verloren gehen. Ein Rebase kann sowohl dem ursprünglichen Autor als auch der Person angerechnet werden, die den Rebase ausgeführt hat.

Wenn Sie das Beitragsdiagramm als Kennzahl für das Screening verwenden, entstehen zwei Arten von Fehlern:

• Falsch positive Bewertungen: Ein dichtes Beitragsdiagramm kann Forks, nicht zusammengeführte Pull Requests, automatisierte Aktivität, kosmetische Änderungen oder Arbeit enthalten, deren Nutzen Sie nicht geprüft haben.
• Falsch negative Bewertungen: Hinter einem dünnen Beitragsdiagramm können sich Jahre privater Unternehmensarbeit, Sicherheitsvorgaben, nicht verknüpfte Commit-E-Mails oder Arbeit in Branches verbergen, die GitHub nicht zählt. Vielleicht hat die Person auch schlicht kein Interesse an unbezahlter öffentlicher Mitarbeit.

Mehr Aktivität kann Sie weiterhin zu nützlichen Nachweisen führen. Sie ist aber nicht selbst der Nachweis. Zählen Sie keine Sterne, Repositories, Commits, Aktivitätsserien oder zusammengeführten Pull Requests, um daraus eine Rangfolge der Kandidaten zu bilden. Selbst ein geringes numerisches Gewicht macht aus einer nicht vergleichbaren Aktivitätsanzeige scheinbar belastbare Entscheidungsdaten.

Ältere Forschung zur Personalauswahl zeigt, warum diese Abkürzung so hartnäckig ist. In einer Studie von 2016 beurteilten neun Teilnehmende fünf Entwicklerprofile. Acht nutzten zunächst die Zahl oder Häufigkeit von Commits, weil sich diese Merkmale leicht vergleichen ließen. Teilnehmende aus größeren Unternehmen prüften später eher Art und Qualität der Beiträge. Teilnehmende aus kleineren Unternehmen blieben meist bei der Breite der Aktivität und dem Ruf der Projekte. Die Stichprobe ist sehr klein und untersucht keine spätere Arbeitsleistung. Sie zeigt dennoch einen vertrauten Fehler: Leicht zählbare Merkmale verdrängen die eigentlich relevante Information.

Keine für diesen Artikel gefundene Studie belegt, dass die Menge der GitHub-Beiträge die spätere Arbeitsleistung vorhersagt. Öffentliche Arbeit kann wertvolles Verhalten sichtbar machen. Die Zahl verrät Ihnen nicht, welches Verhalten dahintersteckt.

Zählt KI-gestützte Open-Source-Arbeit weiterhin?

Ja. KI-gestützte Open-Source-Arbeit kann ein aussagekräftiger Nachweis im Portfolio sein, wenn die Kandidatin oder der Kandidat sie versteht, prüft und verantwortet. Entscheidend ist die Trennlinie zwischen verantworteter Arbeit und Ergebnissen ohne ausreichendes Verständnis, nicht zwischen menschlicher Eingabe und maschineller Erzeugung.

Eine Studie zu Beitragsrichtlinien aus dem Jahr 2026 untersuchte 1.000 populäre GitHub-Repositories und fand 118 ausdrückliche KI-Richtlinien. Von diesen erlaubten 78 % KI-gestützte Arbeit, 51 % verlangten eine Offenlegung und 74 % einen Human-in-the-Loop. Die Stichprobe steht nicht für alle Repositories. Sie widerspricht jedoch direkt der Vorstellung, etablierte Projekte würden KI-Einsatz im Allgemeinen ablehnen.

Aktuelle Projektrichtlinien stimmen bei den beobachtbaren Nachweisen weitgehend überein:

• LLVM verlangt, dass Mitwirkende generierte Arbeit lesen, prüfen und erklären. Als „extraktiv“ bezeichnet das Projekt einen Beitrag, dessen erwarteter Prüfaufwand den Nutzen für das Projekt übersteigt.
• Linux verlangt eine menschliche Freigabe. KI-gestützte Fehlersuche sollte einen Reproduktionsfall, eine Korrektur, Build- oder Testnachweise und eine ehrliche Darstellung aller nicht geprüften Punkte enthalten.
• pytest begrüßt KI-Unterstützung, schließt aber vollständig agentengesteuerte Einreichungen, wenn kein Mensch sinnvoll an der Prüfung teilnehmen kann.
• OpenXLA akzeptiert gekennzeichnete KI-generierte Arbeit, die sich auf ein echtes Problem, einen Test oder einen Benchmark bezieht, sofern die verantwortliche Person sie versteht.
• curl akzeptiert KI-gestützte Pull Requests nach den üblichen Standards für Codequalität, Tests und Dokumentation.

curl liefert zugleich ein wichtiges Gegenbeispiel. In seinem Prämienprogramm für Sicherheitslücken fiel der Anteil bestätigter Meldungen von historisch mehr als 15 % auf unter 5 % im Jahr 2025. KI-lastige und auf Belohnungen ausgerichtete Einreichungen trugen zur Entscheidung bei, Geldprämien abzuschaffen. Im April 2026 berichtete der Maintainer Daniel Stenberg, dass sich das Volumen verdoppelt hatte und der Anteil bestätigter Meldungen wieder auf 15–16 % gestiegen war, obwohl fast jede Meldung offenbar KI-gestützt war.

Das ist die Erfahrung eines einzelnen Projekts, keine allgemeingültige Quote. Sie zeigt trotzdem, warum „Wurde KI eingesetzt?“ für die Einstellung wenig taugt. Anreize, Prüfung, Relevanz und menschliche Verantwortung entschieden darüber, ob das Ergebnis einen Nutzen hatte. Genau diese Punkte sollte Ihre Portfolio-Bewertung erfassen.

Wenn Sie beurteilen möchten, wie jemand in einer live durchgeführten Aufgabe mit KI arbeitet, brauchen Sie ein anderes Prüfungsdesign. Unser Leitfaden zu KI-gestützten technischen Interviews behandelt dieses Thema. Versuchen Sie bei der Portfolio-Bewertung nicht, den Einsatz von KI aufzuspüren. Lassen Sie die Kandidatin oder den Kandidaten die Arbeitsprobe erklären und verteidigen.

Wie prüfen Sie das GitHub-Portfolio eines Entwicklers?

Prüfen Sie bei allen Kandidatinnen und Kandidaten ein oder zwei für die Rolle relevante Arbeitsproben mit derselben Scorecard aus sechs Kriterien. Eine gezielte Auswahl zeigt mehr als die Gesamtsumme im Profil und bleibt klein genug für eine sorgfältige Prüfung.

Wählen Sie zunächst eine Arbeitsprobe mit ausreichend prüfbarem Kontext. Das kann ein Pull Request, eine Diskussion über den Entwurf, eine Fehlermeldung mit Reproduktionsfall, ein von der Person betreutes Release oder ein eigenes Repository sein. Bevorzugen Sie Arbeit, die zur Rolle passt. Unterstellen Sie aber nicht, dass bekannte Projekte bessere Nachweise liefern. Auch ein bescheidener Patch kann ausgezeichnetes Urteilsvermögen zeigen.

Bewerten Sie anschließend diese sechs Kriterien:

Behandeln Sie einen zusammengeführten Pull Request nicht automatisch als Qualitätsnachweis. Entscheidungen über die Zusammenführung hängen außer vom Code auch vom Projektumfang, von der Verfügbarkeit der Maintainer, vom Zeitpunkt und vom sozialen Kontext ab. Auch ein abgelehnter Vorschlag kann einen starken Nachweis liefern. Dafür muss der Kandidat ein echtes Problem erkannt, einen vertretbaren Ansatz geprüft, gut auf Rückmeldungen reagiert und die Entscheidung des Projekts verstanden haben.

Auch das Gegenteil gilt. Eine zusammengeführte Tippfehlerkorrektur kann dem Projekt nützen, sagt aber wenig über das Urteilsvermögen bei Systemfragen aus. Bewerten Sie, was die Arbeitsprobe für diese Rolle belegt, nicht den Status ihrer Zusammenführung.

Stellen Sie allen Kandidaten dieselben drei Fragen:

1. Welches Problem wollten Sie lösen, und woran erkannten Sie seine Bedeutung?
2. Welcher Nachweis würde belegen, dass Ihre Änderung falsch ist?
3. Was hat sich nach der Prüfung geändert, und was würden Sie heute anders machen?

Diese Fragen machen es weniger nützlich, Urheberschaft bloß zu inszenieren. Wer eine unverstandene Antwort kopiert hat, wird Problem, Nachweise und den Verlauf der Überarbeitungen nur schwer schlüssig verbinden können. Wer KI verantwortungsvoll eingesetzt hat, kann dieselbe Kette klar erklären. Auch Einsteiger können mit einem kleinen Beitrag gut abschneiden, weil die Scorecard Urteilsvermögen und Lernfähigkeit statt Größe belohnt.

Dokumentieren Sie die Arbeitsprobe, die Antworten und den Nachweis für jede Bewertung. Es geht nicht darum, qualitative Arbeit in eine Scheingenauigkeit zu pressen. Vielmehr dürfen Ruf, Länge einer Beitragsserie, Arbeitgebermarke oder die Begeisterung des ersten Prüfers den Maßstab nicht unbemerkt verschieben.

Was tun Sie, wenn ein Kandidat keine öffentliche GitHub-Arbeit hat?

Geben Sie Kandidatinnen und Kandidaten ohne brauchbare öffentliche Arbeit eine gleichwertige Möglichkeit, dieselben Kompetenzen nachzuweisen. Ein GitHub-Profil sollte freiwillig sein, denn fehlende öffentliche Aktivität belegt keine geringe Qualifikation.

Bitten Sie um eine Arbeitsprobe aus einer beliebigen zulässigen Quelle:

• öffentliche Open-Source-Arbeit;
• private berufliche Arbeit, die sich ohne vertrauliche Details beschreiben lässt;
• ein Schul-, Ehrenamts- oder Hobbyprojekt;
• eine Architekturnotiz, eine Rückschau auf einen Vorfall oder eine technische Entscheidung, die sich besprechen lässt;
• eine kurze gleichwertige Aufgabe aus Ihrem Team.

Erlauben Sie, Namen, Kennzahlen und geschützte Details zu schwärzen. Sie benötigen das Problem, die konkrete Handlung der Person, das Prüfverfahren, das Ergebnis und die gewonnenen Erkenntnisse. Den Quellcode des früheren Arbeitgebers brauchen Sie nicht.

Falls keine vorhandene Arbeitsprobe passt, verwenden Sie eine repräsentative Aufgabe, die eine für den Einstieg entscheidende Kompetenz prüft. Halten Sie sie kurz, vermeiden Sie unbezahlte Produktarbeit und testen Sie nichts, was die Person vernünftigerweise erst nach dem Einstieg lernen würde. Unser Leitfaden zum sinnvollen Aufbau von Code-Aufgaben behandelt Umfang, Anweisungen für Kandidaten und Prüfablauf. Die Aufgabe schafft Zugang, sie ist keine Strafe für private Arbeit.

Verwenden Sie über alle Wege hinweg dieselbe Systematik von Bewertungskriterien. Bei öffentlicher Open-Source-Arbeit können ein Reproduktionsfall und die Prüfung durch einen Maintainer als Nachweis dienen. In einem privaten Projekt können ein Testplan und das Ergebnis eines Vorfalls diesen Nachweis liefern. Bei einer kurzen Aufgabe können es ein Regressionstest und eine Erklärung sein. Die Arbeitsproben unterscheiden sich, die Kompetenz nicht.

Diese Gleichwertigkeit verhindert außerdem, dass Verfügbarkeit mit Leistung verwechselt wird. Öffentliche Mitarbeit bevorzugt Menschen, die dafür eine Erlaubnis, freie Zeit und vorzeigbare Arbeit haben. Ein faires Verfahren verlangt keine unbezahlte öffentliche Arbeit, um private Erfahrung beurteilen zu können.

Wie wird aus Portfolio-Nachweisen eine belastbare Einstellungsentscheidung?

Überführen Sie die Bewertung der Arbeitsprobe in eine strukturierte Nachweisdokumentation und geben Sie ihr das richtige Gewicht. Portfolio-Nachweise sollen eine klar begrenzte Frage zur gezeigten Arbeit beantworten. Sie dürfen weder zu einem allgemeinen Charakterurteil werden noch allein über die Einstellung entscheiden.

Lassen Sie Prüferinnen und Prüfer ihre Bewertungen unabhängig abgeben, bevor sie über den Kandidaten sprechen. Verlangen Sie zu jedem Kriterium einen kurzen Nachweis. Konzentrieren Sie sich im Auswertungsgespräch auf bedeutsame Abweichungen: Welches Detail der Arbeitsprobe hat eine Person gesehen, das einer anderen entgangen ist? Muss ein Bewertungsanker klarer formuliert werden?

An dieser Stelle fließt die Portfolio-Bewertung in das übrige Einstellungsverfahren ein, ohne es zu dominieren. Eine starke Arbeitsprobe kann eine gezielte Nachfrage anstoßen. Sie darf jedoch schwache Nachweise in Bereichen nicht ausgleichen, die für die Rolle entscheidend sind und von der Arbeitsprobe gar nicht abgedeckt werden. Ein Backend-Pull-Request kann Fehlersuche und Verhalten bei der Codeprüfung sichtbar machen, sagt aber womöglich nichts über die Kommunikation mit anderen Beteiligten oder die betriebliche Verantwortung aus.

Breite Forschung zur Personalauswahl spricht für Struktur statt Improvisation. Eine Synthese von 2023 schätzte die korrigierte operative Validität auf 0,42 für strukturierte Interviews, 0,33 für Arbeitsproben und 0,19 für unstrukturierte Interviews. Diese Werte stammen aus verschiedenen Berufen und weisen erhebliche Streuung auf. Sie sind keine Garantie für die Softwareentwicklung. Sie stützen ein Gestaltungsprinzip, aber kein Versprechen für Ihre konkrete Scorecard.

Legen Sie die Kriterien fest, bevor Sie Kandidaten prüfen. Stellen Sie durchgängig dieselben Fragen. Schulen Sie die Prüfer anhand der Bewertungsanker. Halten Sie die unabhängigen Bewertungen vor dem Auswertungsgespräch fest. Unser Leitfaden zu Scorecards für strukturierte Interviews erklärt das übergeordnete Bewertungssystem. Die Portfolio-Scorecard sollte als eine Nachweisquelle in dieses System einfließen, statt als informelles Veto daneben zu stehen.

Prüfen Sie das Verfahren nach mehreren Einstellungen. Wenden die Prüfer die Anker einheitlich an? Führt ein Weg Kandidaten häufiger weiter als gleichwertige Alternativen? Stimmen Portfolio-Bewertungen mit Nachweisen aus späteren Phasen überein? Behaupten Sie keine Vorhersagekraft, die Sie nicht gemessen haben.

Wie bildet Kit die Nachweiskette ab, ohne Urheberschaft vorzutäuschen?

Kit kann die Nachweiskette standardisieren: ein privates Repository für die Code-Aufgabe, eine klare Frist, benannte Prüfer, verdeckte Scorecards und eine namentlich dokumentierte menschliche Entscheidung. Kit erkennt keine KI, erfasst keine Prompts und beweist nicht, wer den Code geschrieben hat.

Wenn eine Kandidatin oder ein Kandidat eine gleichwertige Arbeitsprobe benötigt, kann Kits GitHub-Integration aus Ihrer Vorlage ein privates Repository erstellen, die Person einladen, Fristen und Verlängerungen verfolgen, berechtigte Prüfer hinzufügen und das Repository nach Abschluss archivieren. Die Anweisungen für Kandidaten erscheinen im Portal und in den Aufgabenunterlagen. Kit erstellt das Repository, keinen Pull Request.

Kombinieren Sie die Phase für die Code-Aufgabe mit einer Phase für die Teambewertung. Hinterlegen Sie die sechs Kriterien in dieser Bewertung, lassen Sie die Prüfer unabhängig bewerten und besprechen Sie die Nachweise erst nach Abgabe der Bewertungen. Kit unterstützt bis zur Abgabe verdeckte Bewertungen, gewichtete Kriterien, Kommentare, Schwellenwerte und eine namentlich dokumentierte menschliche Entscheidung. Strukturierte Kriterien liegen nicht direkt auf der Phase für die Code-Aufgabe. Deshalb ist die Kombination beider Phasen wichtig.

Nehmen Sie die KI-Regel in die Anweisungen für Kandidaten auf. Bitten Sie Kandidaten bei Bedarf um die Offenlegung der verwendeten Werkzeuge, wenn dieser Kontext bei der Prüfung hilft. Stellen Sie die Offenlegung aber nicht als Beweis für die Urheberschaft dar. Der Nachweis entsteht weiterhin dadurch, was die Person erklären, prüfen, überarbeiten und verantworten kann.

GitHub bleibt nützlich, weil öffentlicher Code und der Verlauf von Codeprüfungen echtes Verhalten bei der Entwicklungsarbeit prüfbar machen können. Fehlerhaft ist nur, angesammelte Aktivität als Punktwert zu behandeln. Wählen Sie gezielt Arbeitsproben aus, wenden Sie dieselben sechs Kriterien an, bieten Sie für private Erfahrung einen gleichwertigen Weg und lassen Sie die Nachweise in eine strukturierte Entscheidung einfließen.

Wenn Sie diese Nachweiskette bei allen Kandidaten für technische Stellen einheitlich abbilden möchten, testen Sie Kit kostenlos und verankern Sie die Portfolio- oder Aufgabenbewertung in Ihrer Pipeline.