Maintainer open source: AI generuje PR-y tylko dla ozdoby CV

Neil Alexander, programista i maintainer projektów open source, opublikował 30 czerwca 2026 roku wpis na swoim blogu, w którym opisuje niepokojący trend: zalew jego repozytoriów sztucznie wygenerowanymi wkładami, które mają jeden cel — upiększenie profilu GitHub autora, a nie realną pomoc projektowi. Autor apeluje, by przestać wykorzystywać sztuczną inteligencję do „gamingu” systemu reputacji open source.

Kluczowe wnioski

• Wkłady w projekty open source (pull requesty, zgłoszenia błędów) działają jak swoista walutą reputacyjną — GitHub pokazuje avatary kontrybutorów, aktywność w feedzie i wykres commitów, co śledzą rekruterzy i menedżerowie ds. rekrutacji.
• Autor zauważa, że w ostatnim roku wzorzec kontrybucji zmienił się drastycznie: więcej pull requestów niż zgłoszeń problemów, a te zgłoszenia, które się pojawiają, coraz częściej mają dołączoną analizę wygenerowaną przez AI.
• Opisany jest konkretny przypadek: kontrybutor bez praktycznie żadnej aktywności na GitHubie od końca 2018 roku do niedawna złożył trzy osobne PR-y poprawiające literówki i błędy gramatyczne w komentarzach — poprawki, opisy PR-ów i podpisy commitów wygenerował Claude, dodając nawet swoje współautorstwo w metadanych commitów.
• Rośnie liczba raportów o podatnościach bezpieczeństwa (CVE), z których wiele jest ewidentnie generowanych przez AI — projekt stał się bardziej selektywny w ocenie ich powagi i w niektórych przypadkach odmawia wydawania powiadomień CVE dla drobnych problemów.
• Autor zamknął wszystkie trzy PR-y bez komentarza, argumentując, że open source jest budowany na zaufaniu, a nie na liczbie PR-ów wyciągniętych z modelu językowego.

Jak AI zmieniła krajobraz kontrybucji w open source

Neil Alexander opisuje, jak łatwo dziś zbudować fałszywy wizerunek zaangażowanego programisty. Wystarczy poprosić model, na przykład Claude, o wygenerowanie listy interesujących projektów open source, a potem zlecić mu znalezienie w nich problemów i przygotowanie pull requestów naprawiających te problemy. Jak pisze autor, „nie musisz nawet używać tych projektów ani się nimi interesować, ale możesz łatwo stworzyć u osób z zewnątrz wrażenie, że ci na tym zależy, że znalazłeś problem albo że poświęciłeś czas na jego naprawę”.

To zjawisko nabiera znaczenia, bo — jak zauważa Alexander — „na internecie nikt nie wie, że jesteś psem”, ale dzięki modelom językowym można bez wysiłku zawyżyć swoje ludzkie umiejętności na profilu GitHub. Sygnały te mają realne konsekwencje zawodowe: potencjalni pracodawcy i rekruterzy śledzą listy kontrybutorów, aktywność commitową i liczbę zielonych kwadratów na wykresie profilu, traktując je jako dowód kompetencji.

Przypadek trzech pull requestów i problem z raportami CVE

Kluczowym punktem wpisu jest opisany szczegółowo incydent. Kontrybutor, który praktycznie nie miał żadnej historii aktywności na GitHubie od końca 2018 roku do kilku tygodni przed wydarzeniem i nie miał wcześniejszego kontaktu z projektem, złożył trzy osobne PR-y korygujące literówki i błędy gramatyczne w komentarzach kodu. Poprawki wykonał Claude, który — jak przypuszcza autor — napisał także opisy PR-ów, podpisał commity w imieniu użytkownika i dołożył swoje współautorstwo w trailerach commitów. Alexander przyznaje, że nie wie, czy sam model otworzył PR-y, i zastanawia się, czy prompt brzmiał „znajdź problemy”, czy konkretnie dotyczył literówek i gramatyki.

Zmiany były niegroźne i poprawne, ale to nie uspokoiło autora. Jak pisze: „nie mogłem oprzeć się pytaniu: czemu to, czemu teraz? Czemu, ze wszystkich issues, TODO-ów i FIXME-ów w naszej bazie kodu, zgłaszają właśnie to?”. Doszedł do wniosku, że te kontrybucje w ogóle nie dotyczyły jego projektu — zamknął wszystkie trzy PR-y bez komentarza, nie chcąc tworzyć precedensu akceptowania wkładów, które niczego materialnie nie poprawiają.

Podobny wzorzec dotyczy zgłoszeń podatności bezpieczeństwa. Tradycyjnie CVE są przypisywane osobom, które je zgłosiły, ale ostatnio wszystkie otrzymane raporty były ewidentnie generowane przez AI. Projekt zaczął być znacznie bardziej selektywny przy ocenie powagi takich zgłoszeń, a w niektórych przypadkach odmawia wydawania powiadomień CVE dla problemów o niskiej istotności. Autor zaznacza, że koordynacja prywatnych ujawnień, poprawek i powiadomień wymaga sporego wysiłku, co dodatkowo wymusza selektywność.

Zaufanie jako fundament open source

Alexander podsumowuje swój wpis jasnym przesłaniem: open source jest zbudowany na zaufaniu. Metryką, która się liczy, nie jest liczba pull requestów wyciągniętych z modelu językowego ani liczba zebranych CVE, ale to, czy dany wkład realnie ulepsza projekt. Autor apeluje do potencjalnych kontrybutorów: jeśli chcesz pomagać projektom open source, róbcie to, bo wam na tym zależy — a jeśli chodzi wyłącznie o kolejny zielony kwadrat albo znaczek kontrybutora na profilu, proszę, szukajcie tego gdzie indziej.

Ten problem wpisuje się w szerszy trend wykorzystywania agentów AI do automatyzacji pracy programistycznej — podobne napięcia między automatyzacją a rzeczywistą wartością widać choćby w rozwoju persystentnego, proaktywnego agenta Codex testowanego przez OpenAI czy w nowych modelach rozwoju oprogramowania opartych na agentach, takich jak SDAD.

Wpis Neila Alexandra jest głosem sprzeciwu wobec traktowania kontrybucji open source jako łatwej do zhakowania metryki CV, a nie realnego zaangażowania w rozwój oprogramowania.