Aktywność na GitHubie to dziś zawodny sygnał w rekrutacji

Aktywność na GitHubie przestała być wiarygodną miarą w rekrutacji. Wykres zlicza różne rodzaje zdarzeń, a nie jakość pracy inżynierskiej. AI dodatkowo obniża koszt tworzenia widocznej aktywności. Potraktuj GitHub jak katalog, w którym znajdziesz jedną lub dwie konkretne próbki pracy. Następnie oceń znaczenie problemu, zrozumienie tematu, weryfikację, reakcję na uwagi, wpływ i odpowiedzialność. Kandydatom, których najlepsza praca jest poufna, zapewnij równoważny sposób oceny.

Zielony kwadrat nadal ma znaczenie. Nie nadaje się już tylko na skrót myślowy.

Dlaczego liczba aktywności na GitHubie przestała działać jako rekrutacyjny skrót?

Licznik aktywności na GitHubie przestał być użytecznym skrótem w rekrutacji, bo tworzenie widocznych śladów stało się tańsze, a ocena ich wartości wciąż jest kosztowna. To tylko uwydatniło wadę, która istniała od zawsze: licznik mierzy działania, nie to, czy dzięki nim projekt stał się lepszy.

Neil Alexander uchwycił ten problem w tekście z czerwca 2026 roku o trzech pull requestach napisanych wspólnie z Claude. Jeden ze współtwórców poprawił pisownię i gramatykę w komentarzach w kodzie. Zmiany były poprawne i nieszkodliwe, ale Alexander je zamknął, bo wymagały czasu na review, a nie wnosiły istotnej wartości do projektu. Podejrzewał, że chodziło o uzupełnienie CV.

Ostatnie zdanie jest wnioskiem, nie faktem. Autor zmian nie potwierdził zawodowej motywacji. Gdy tekst trafił na Hacker News, komentujący kwestionowali tę decyzję, przekonywali, że poprawne korekty literówek też mają pewną wartość, i przypominali, że spam w projektach open source istniał przed generatywną AI. Te zastrzeżenia są ważne. Uczciwy proces rekrutacji nie może na podstawie małej poprawki wnioskować o nieuczciwości ani karać kandydata za samo użycie asystenta.

Szerszy problem z ograniczoną uwagą jest jednak realny. W styczniu 2026 roku GitHub poinformował, że opiekunowie projektów mierzą się z rosnącą liczbą słabych zgłoszeń, w tym z propozycjami ignorującymi zasady projektu, porzuconymi albo wygenerowanymi przez AI. W maju GitHub opisał wąskie gardło dokładniej: tworzenie pull requestów, issue, komentarzy i zgłoszeń stało się znacznie łatwiejsze, ale review wciąż wymagało uwagi ludzi, której nie da się dowolnie zwiększać. GitHub wyraźnie zaznaczył, że problem jest szerszy niż AI.

Firma wprowadziła następnie ustawienia, które pozwalają wyłączyć lub ograniczyć pull requesty, oraz limit jednocześnie otwartych pull requestów od osób bez uprawnień do zapisu. Zmiany w produkcie nie dowodzą, że kandydaci sztucznie rozbudowują CV. Pokazują jednak, że sama liczba zgłoszeń może generować realne koszty, zanim ktokolwiek zdąży ocenić przydatność zmiany.

Najmocniejsze dostępne dziś dane z ekosystemu wskazują ten sam kierunek, choć mają istotne ograniczenia. Preprint z lipca 2026 roku objął 294 popularne, aktywne repozytoria i ponad 1,2 miliona pull requestów. W porównaniu z modelowanym scenariuszem kontrfaktycznym autorzy oszacowali, że w 2025 roku liczba pull requestów wzrosła o 6,80 %, a ogólny odsetek scaleń spadł o 1,06 %. Liczba pull requestów od jednorazowych współtwórców wzrosła o 5,84 %, a odsetek ich scaleń spadł o 18,18 %.

Te dane nie dowodzą, że przyczyną była AI. Badacze potraktowali 2025 rok jako przybliżenie okresu powszechnego wykorzystania AI. Nie obserwowali, kto korzystał z jakiego narzędzia, i nie mogli wykluczyć wzrostu platformy ani innych zmian w ekosystemie. Próba faworyzuje też popularne repozytoria otwarte na nowych współtwórców. Można więc wyciągnąć tylko węższy wniosek: w tej próbie większa widoczna aktywność mówiła mniej o szansie na scalenie.

Sam spam nie jest nowością. W podsumowaniu Hacktoberfest 2020 DigitalOcean odnotował 621 104 pull requesty, w tym 9 598 oznaczonych jako spam lub nieprawidłowe oraz 34 595 niezaakceptowanych. Po napływie słabych zgłoszeń organizatorzy zmienili wydarzenie tak, by uczestniczyły w nim tylko projekty, które wyraźnie się na to zgłosiły. AI nie stworzyła tej szkodliwej zachęty. Obniżyła tylko koszt jej wykorzystywania.

Co właściwie mierzy zielony kwadrat?

Zielony kwadrat na GitHubie oznacza aktywność spełniającą reguły wyświetlania GitHuba. Nie mierzy trudności, poprawności, użyteczności, autorstwa ani wyników w pracy. Dwa identycznie wyglądające wykresy mogą opisywać zupełnie inną pracę. Dwóch równie dobrych inżynierów może też mieć całkowicie odmienne wykresy.

Dokumentacja GitHuba dotycząca aktywności jasno pokazuje to niedopasowanie. Utworzenie repozytorium lub forka liczy się zawsze. Issue, pull requesty, review, dyskusje, odpowiedzi i commity liczą się tylko pod określonymi warunkami. Pull request nie musi zostać scalony, żeby się pojawił. Liczba wyświetlanych zdarzeń niektórych typów jest ograniczona.

Widoczność commitów ma osobne ograniczenia. Adres e-mail użyty w commicie musi być powiązany z kontem. Praca musi znajdować się w samodzielnym repozytorium, zwykle na gałęzi domyślnej lub gh-pages, a dana osoba musi dodatkowo spełnić warunek dotyczący relacji z projektem. Prywatna praca może być widoczna jako liczba bez szczegółów, które da się sprawdzić. Połączenie kont może usunąć przypisanie issue, pull requestów i dyskusji. Rebase może przypisać aktywność zarówno pierwotnemu autorowi, jak i osobie, która go wykonała.

Traktowanie wykresu jako wyniku na etapie screeningu prowadzi do dwóch rodzajów błędów:

• Fałszywie pozytywne oceny: gęsty wykres może obejmować forki, niescalone pull requesty, automatyczną aktywność, kosmetyczne zmiany lub pracę, której wartości nikt nie sprawdził.
• Fałszywie negatywne oceny: rzadki wykres może ukrywać lata poufnej pracy w firmie, ograniczenia bezpieczeństwa, niepowiązane adresy e-mail w commitach, pracę na gałęziach, których GitHub nie liczy, albo zwykły brak chęci do publicznej pracy bez wynagrodzenia.

Większa aktywność nadal może naprowadzić na przydatne dowody. Sama nie jest jednak dowodem. Nie zliczaj gwiazdek, repozytoriów, commitów, serii aktywności ani scalonych pull requestów, żeby zamienić sumę w ranking kandydatów. Przypisanie jej choćby niewielkiej wagi wprowadza do decyzji rekrutacyjnej pozorną porównywalność danych, których porównać się nie da.

Starsze badania nad rekrutacją wyjaśniają, dlaczego ten skrót wciąż kusi. W badaniu z 2016 roku dziewięciu uczestników oceniało pięć profili programistów. Ośmiu podczas pierwszego screeningu brało pod uwagę liczbę lub częstotliwość commitów, bo te dane łatwo porównać. Uczestnicy z większych firm częściej sprawdzali później rodzaj i jakość aktywności. Osoby z mniejszych firm opierały się głównie na różnorodności aktywności i reputacji projektu. Badanie jest bardzo małe i nie sprawdza późniejszych wyników w pracy, ale pokazuje znaną pułapkę: to, co najłatwiej policzyć, wypiera informację, której naprawdę potrzebujesz.

Żadne badanie znalezione na potrzeby tego artykułu nie wykazało, że liczba zdarzeń widocznych na GitHubie pozwala przewidzieć wyniki w pracy. Publicznie dostępne materiały mogą pokazać cenne zachowania. Licznik nie wskaże, które z nich wystąpiły.

Czy praca open source wspomagana przez AI nadal się liczy?

Tak. Praca open source wspomagana przez AI może być mocnym dowodem w portfolio, jeśli kandydat ją rozumie, weryfikuje i bierze za nią odpowiedzialność. Liczy się różnica między pracą, za którą ktoś odpowiada, a wynikiem bez zrozumienia, nie między kodem wpisanym przez człowieka a wygenerowanym przez maszynę.

Badanie zasad współtworzenia projektów z 2026 roku objęło 1000 popularnych repozytoriów na GitHubie i znalazło 118 wyraźnych zasad dotyczących AI. Spośród nich 78 % dopuszczało pracę wspomaganą przez AI, 51 % wymagało jej ujawnienia, a 74 % wymagało nadzoru człowieka. Próba nie reprezentuje wszystkich repozytoriów, ale bezpośrednio przeczy tezie, że dojrzałe projekty zazwyczaj odrzucają użycie AI.

Obecne zasady projektów skupiają się na widocznych dowodach:

• LLVM wymaga, by współtwórcy czytali, sprawdzali i wyjaśniali wygenerowaną pracę. Projekt uznaje taki wkład za „eksploatujący”, gdy spodziewany koszt review przewyższa korzyść dla projektu.
• Linux wymaga zatwierdzenia przez człowieka. Debugowanie z pomocą AI powinno obejmować sposób odtworzenia problemu, poprawkę, dowody z kompilacji lub testów oraz uczciwy opis wszystkiego, czego nie zweryfikowano.
• pytest dopuszcza pomoc AI, ale zamyka w pełni autonomiczne zgłoszenia, jeśli żaden człowiek nie potrafi sensownie uczestniczyć w review.
• OpenXLA przyjmuje oznaczoną pracę wygenerowaną przez AI, która dotyczy realnego problemu, testu lub benchmarku, o ile autor ją rozumie.
• curl przyjmuje pull requesty wspomagane przez AI na zwykłych zasadach jakości kodu, testów i dokumentacji.

curl dostarcza też przydatnego kontrprzykładu. W jego programie nagród za błędy odsetek potwierdzonych zgłoszeń spadł z historycznych ponad 15 % do mniej niż 5 % w 2025 roku. Stało się to w czasie napływu zgłoszeń powstałych w dużej mierze z pomocą AI i nastawionych na nagrody, co przyczyniło się do decyzji o zakończeniu wypłacania nagród pieniężnych. W kwietniu 2026 roku opiekun projektu Daniel Stenberg poinformował, że liczba zgłoszeń się podwoiła, a odsetek potwierdzeń wrócił do 15–16 %, chociaż niemal każde zgłoszenie wyglądało na wspomagane przez AI.

To doświadczenie jednego projektu, nie uniwersalny wskaźnik. Pokazuje jednak, dlaczego pytanie „Czy użyto AI?” niewiele wnosi do rekrutacji. O przydatności wyniku decydowały bodźce, weryfikacja, znaczenie problemu i odpowiedzialność człowieka. Właśnie to powinna sprawdzać ocena portfolio.

Jeśli chcesz ocenić pracę z AI podczas etapu prowadzonego na żywo, trzeba ten etap zaprojektować osobno. Opisaliśmy to w przewodniku po rozmowach technicznych z użyciem AI. Przy ocenie portfolio nie próbuj wykrywać AI. Poproś kandydata o wyjaśnienie i obronę materiału.

Jak oceniać portfolio programisty na GitHubie?

Oceń jedną lub dwie próbki pracy związane ze stanowiskiem, stosując tę samą kartę oceny z sześcioma kryteriami dla każdego kandydata. Celowo wybrana próbka mówi więcej niż licznik z całego profilu, a jej rozmiar pozwala na uważne review.

Najpierw wybierz materiał z kontekstem wystarczającym do oceny. Może to być pull request, dyskusja o architekturze, zgłoszenie błędu ze sposobem odtworzenia, wydanie utrzymywane przez kandydata albo repozytorium, za które odpowiada. Preferuj pracę związaną ze stanowiskiem, ale nie zakładaj, że znany projekt automatycznie daje lepsze dowody. Niewielka poprawka może pokazać świetny osąd.

Następnie oceń sześć kryteriów:

Nie traktuj scalonego pull requestu jako automatycznego dowodu jakości. Na decyzję o scaleniu wpływa zakres projektu, dostępność jego opiekunów, moment i kontekst społeczny, a nie tylko kod. Odrzucona propozycja nadal może być mocnym dowodem, jeśli kandydat znalazł realny problem, przetestował uzasadnione podejście, dobrze zareagował na uwagi i potrafi wyjaśnić, dlaczego projekt wybrał inną drogę.

Działa to też w drugą stronę. Scalona poprawka literówki może pomóc projektowi, ale niewiele powiedzieć o umiejętności oceny całych systemów. Oceniaj to, co dany materiał pokazuje w kontekście stanowiska, a nie jego status w GitHubie.

Każdemu kandydatowi zadaj te same trzy pytania:

1. Jaki problem miała rozwiązać ta praca i skąd było wiadomo, że ma znaczenie?
2. Jaki dowód wykazałby, że zmiana jest błędna?
3. Co zmieniło się po review i co dziś warto byłoby zrobić inaczej?

Przy takich pytaniach trudniej stwarzać pozory autorstwa. Osobie, która skopiowała odpowiedź bez jej zrozumienia, trudno będzie połączyć problem, dowody i historię zmian. Ktoś, kto odpowiedzialnie korzystał z AI, potrafi jasno wyjaśnić ten sam tok rozumowania. Początkujący może też uzyskać dobry wynik za niewielkie zgłoszenie, bo karta oceny premiuje osąd i uczenie się, a nie rozmiar pracy.

Zapisz materiał, odpowiedzi i dowody uzasadniające każdą ocenę. Nie chodzi o zamianę jakościowej pracy w pozornie precyzyjną liczbę. Chodzi o to, żeby reputacja, długość serii aktywności, marka pracodawcy lub entuzjazm pierwszego recenzenta nie zmieniały po cichu kryteriów.

Co zrobić, gdy kandydat nie ma publicznej pracy na GitHubie?

Daj kandydatom bez przydatnej publicznej pracy równoważny sposób pokazania tych samych kompetencji. Profil na GitHubie powinien być opcjonalny, ponieważ brak publicznej aktywności nie świadczy o niskich umiejętnościach.

Poproś o jeden materiał z dowolnego akceptowanego źródła:

• publiczna praca open source;
• poufna praca zawodowa, którą kandydat może opisać bez ujawniania tajemnic;
• projekt uczelniany, wolontariacki lub hobbystyczny;
• notatka architektoniczna, analiza incydentu lub decyzja techniczna, o której można porozmawiać;
• krótkie równoważne zadanie przygotowane przez zespół.

Pozwól ukryć nazwy, wskaźniki i zastrzeżone szczegóły. Potrzebne są: problem, konkretne działanie kandydata, sposób weryfikacji, wynik i wyciągnięte wnioski. Kod źródłowy poprzedniego pracodawcy nie jest potrzebny.

Jeśli żaden istniejący materiał się nie nadaje, użyj reprezentatywnego zadania, które sprawdza kluczową kompetencję potrzebną od pierwszego dnia pracy. Niech będzie krótkie, nie służy jako bezpłatna praca nad produktem i nie sprawdza czegoś, czego można rozsądnie nauczyć się po dołączeniu. Nasz przewodnik po konstruowaniu zadań programistycznych omawia zakres zadania, instrukcje dla kandydata i sposób review. To równoważna droga przez rekrutację, nie kara za poufną pracę.

Niezależnie od wybranego rozwiązania stosuj ten sam zestaw kryteriów. W publicznym projekcie open source weryfikacją może być sposób odtworzenia problemu i review opiekuna projektu. W prywatnym projekcie może to być plan testów i wynik incydentu. W krótkim zadaniu może to być test regresji i wyjaśnienie. Materiały są różne, ale kompetencja ta sama.

Dzięki temu dostępność nie zostanie omyłkowo potraktowana jako miara kompetencji. Publiczna aktywność faworyzuje osoby, które mają na nią pozwolenie, wolny czas i pracę możliwą do pokazania. Uczciwy proces nie wymaga bezpłatnej pracy publicznej tylko po to, żeby można było ocenić poufne doświadczenie.

Jak przełożyć dowody z portfolio na uzasadnioną decyzję rekrutacyjną?

Zamień ocenę materiału w uporządkowany zapis dowodów i nadaj mu odpowiednią wagę. Dowody z portfolio powinny odpowiadać na konkretne pytanie o pokazaną pracę. Nie mogą zmienić się w ogólną ocenę charakteru ani samodzielnie rozstrzygać o zatrudnieniu.

Niech recenzenci ocenią materiał niezależnie od siebie, zanim zaczną omawiać kandydata. Przy każdym kryterium wymagaj krótkiej notatki z dowodem. Podczas wspólnego uzgadniania ocen skup się na znaczących różnicach: jaki szczegół materiału dostrzegła jedna osoba, a pominęła druga, i czy opis poziomu oceny wymaga doprecyzowania?

W ten sposób ocena portfolio łączy się z resztą procesu rekrutacji, ale go nie dominuje. Mocny materiał może podsunąć precyzyjne pytania na kolejnym etapie. Nie może jednak kompensować słabych dowodów w kluczowych obszarach, których nie obejmuje. Pull request dotyczący backendu może pokazać umiejętność debugowania i zachowanie podczas review, ale nic nie powiedzieć o komunikacji z interesariuszami ani odpowiedzialności operacyjnej.

Szerokie badania nad metodami selekcji przemawiają za strukturą zamiast improwizacji. Synteza z 2023 roku oszacowała skorygowaną trafność operacyjną na 0,42 dla ustrukturyzowanych rozmów, 0,33 dla próbek pracy i 0,19 dla nieustrukturyzowanych rozmów. To szacunki dla wielu zawodów o dużym zróżnicowaniu, a nie gwarancje dotyczące programistów. Wspierają zasadę projektowania procesu, nie obietnicę skuteczności tej konkretnej karty oceny.

Ustal kryteria przed oceną kandydatów. Zadawaj spójne pytania. Naucz recenzentów korzystać z opisów poziomów. Zachowaj niezależne oceny przed wspólnym uzgadnianiem wyników. Nasz przewodnik po kartach oceny do ustrukturyzowanych rozmów opisuje szerszy system. Karta oceny portfolio powinna być w nim jednym ze źródeł dowodów, a nie działać obok jako nieformalne weto.

Po zatrudnieniu kilku osób przeprowadź audyt procesu. Sprawdź, czy recenzenci spójnie stosują opisy poziomów, czy jedna z równoważnych dróg częściej pozwala kandydatom przejść dalej i czy oceny portfolio wiążą się z dowodami z późniejszych etapów. Nie przypisuj procesowi trafności prognostycznej, której nie udało ci się zmierzyć.

Jak Kit może prowadzić zapis oceny bez udawania, że weryfikuje autorstwo?

Kit może ujednolicić dokumentowanie dowodów: prywatne repozytorium do zadania programistycznego, jasny termin, wyznaczeni recenzenci, ukryte karty oceny i decyzja przypisana do konkretnej osoby. Nie wykrywa AI, nie zapisuje promptów i nie potwierdza, kto napisał kod.

Gdy kandydat potrzebuje równoważnego zadania, integracja Kit z GitHubem może utworzyć prywatne repozytorium z szablonu, zaprosić kandydata, śledzić termin i jego przedłużenia, dodać uprawnionych recenzentów oraz zarchiwizować repozytorium po zakończeniu. Instrukcje dla kandydata pojawiają się w portalu i materiałach do zadania. Kit tworzy repozytorium, nie pull request.

Połącz etap zadania programistycznego z etapem oceny zespołu. Dodaj do niej sześć kryteriów, poproś recenzentów o niezależne oceny i omawiaj dowody dopiero po ich wysłaniu. Kit obsługuje oceny ukryte do chwili wysłania, kryteria z wagami, komentarze, progi i decyzję przypisaną do konkretnej osoby. Ustrukturyzowane kryteria nie znajdują się bezpośrednio na etapie zadania programistycznego, dlatego połączenie obu etapów ma znaczenie.

Zasadę korzystania z AI umieść w instrukcjach dla kandydata. Poproś o ujawnienie użytych narzędzi, jeśli ten kontekst pomaga w review, ale nie przedstawiaj deklaracji jako weryfikacji autorstwa. Dowody nadal wynikają z tego, co kandydat potrafi wyjaśnić, przetestować, poprawić i za co potrafi odpowiadać.

GitHub pozostaje przydatny, bo publiczny kod i historia review mogą pokazać rzeczywiste zachowania inżynierskie. Błąd polega na traktowaniu sumy aktywności jak punktacji. Wybierz próbkę pracy, zastosuj te same sześć kryteriów, zapewnij równoważny sposób oceny osobom z poufnym doświadczeniem i uwzględnij zebrane dowody w ustrukturyzowanej decyzji.

Jeśli chcesz dokumentować ocenę każdego kandydata do zespołu inżynierskiego w taki sam sposób, wypróbuj Kit za darmo i dodaj ocenę portfolio lub zadania do procesu rekrutacji.