In dit artikel bekritiseert auteur Neil de trend waarbij mensen AI-tools zoals Claude gebruiken om hun GitHub-profielen te manipuleren. Omdat recruiters vaak kijken naar de bijdragegrafieken op GitHub, proberen sommige ontwikkelaars via AI-gegenereerde pull requests en beveiligingsmeldingen (CVE's) een illusie van activiteit en expertise te creëren.
Neil beschrijft hoe hij PR's die slechts kleine spellingfouten corrigeren en AI-gegenereerde beveiligingsrapporten weigert, omdat deze geen wezenlijke waarde toevoegen aan het project maar enkel dienen als 'cv-vulling'. Hij benadrukt dat open source gebaseerd is op vertrouwen en oprechte passie, en niet op het verzamelen van badges via robots.
Stop met het overspoelen van onze projecten met AI-troep om je cv op te vullen
Succesvolle bijdragen aan open source-projecten zijn een soort valuta. GitHub stimuleert dit in het bijzonder op verschillende manieren: door avatars van contributeurs op repository-pagina's te tonen, door je bijdragen aan je volgers te laten zien via de activiteitsfeed en door het aantal bijdragen per dag weer te geven in de activiteitsgrafiek van je profiel. Potentiële hiring managers letten hier vaak op. Recruiters vinden en screenen kandidaten regelmatig op deze manier. Als je een softwareontwikkelaar bent (of wilt worden) die op zoek is naar werk, kan het bijsturen van deze signalen vaak in je voordeel werken.
Als beheerder van open source-projecten is het goed merkbaar hoe het patroon van externe bijdragen het afgelopen jaar is veranderd. We ontvangen veel vaker pull requests (PR's) in plaats van issues. Als we wel issues ontvangen, zijn die vaak voorzien van een door AI gegenereerde analyse. We ontvangen meer meldingen van beveiligingskwetsbaarheden dan ooit tevoren, en vaak zitten daar zelfs door AI gegenereerde voorstellen voor oplossingen bij.
Ik betwijfel niet dat sommige van deze bijdragen komen van mensen die oprecht geïnteresseerd zijn in wat we doen, maar het cynische deel van mij gelooft dat een aanzienlijk deel hiervan voortkomt uit het besef dat AI kan worden gebruikt om GitHub in eigen voordeel te manipuleren. Het is nu eenvoudig om Claude te vragen een lijst met interessante open source-projecten te genereren, Claude vervolgens te vragen problemen in die projecten te vinden, en Claude daarna te vragen PR's in te dienen om die problemen op te lossen. Je hoeft de projecten niet eens te gebruiken of ze boeiend te vinden, maar je kunt voor buitenstaanders gemakkelijk de illusie wekken dat je betrokken bent, dat je een probleem hebt ontdekt of dat je tijd hebt gestoken in de oplossing ervan. Op het internet weet niemand dat je een hond bent, maar met de hulp van LLM's kun je moeiteloos je menselijke capaciteiten op je GitHub-profiel overdrijven.
Onlangs heeft een contributeur, die van eind 2018 tot een paar weken geleden vrijwel geen bijdragen aan GitHub had geleverd en waarvan we geen eerdere betrokkenheid bij ons project weten, drie afzonderlijke PR's ingediend om spelfouten en grammaticafouten in commentaren te corrigeren. Claude had de correcties doorgevoerd, waarschijnlijk de beschrijvingen van de PR's geschreven, zelfs de commits namens de gebruiker ondertekend en vervolgens behulpzaam zijn eigen co-auteurschap in de commit-bericht trailers geplaatst. Misschien heeft de AI de PR's zelfs zelf geopend, wie weet. Ik zou gefascineerd zijn om te weten of de prompt "zoek naar issues" was, of dat er specifiek werd gefocust op spelling- en grammaticafouten, en waarom.
De wijzigingen waren onschadelijk en correct, maar dat zorgde er niet voor dat ik me prettiger voelde bij het accepteren of samenvoegen ervan. In plaats daarvan kon ik me niet anders dan afvragen: waarom dit, en waarom nu? Waarom dienen ze dit in, van alle issues, TODO's en FIXME's in onze codebase? Toen drong het tot me door dat deze bijdragen helemaal niet over ons project gingen.
Ik heb alle drie de PR's zonder commentaar gesloten.
Misschien was dit onredelijk, maar eerlijk gezegd ben ik niet geïnteresseerd in het aanmoedigen van mensen die onze tijd verspillen aan dit soort zinloos werk. Ik wil geen precedent scheppen door PR's te accepteren die materieel niets verbeteren, noch wil ik dat onze lijst met contributeurs een beloning wordt voor het vragen aan een robot om typefouten te herstellen.
Hetzelfde patroon is verschenen bij rapporten over beveiligingskwetsbaarheden. CVE's worden traditioneel toegeschreven aan de melders, maar alle rapporten die we onlangs hebben ontvangen, waren overduidelijk door AI gegenereerd. Beveiligingsfixes zijn natuurlijk altijd belangrijk, maar opnieuw vraag ik me af of dit gebeurt omdat mensen om de fixes geven of omdat ze op zoek zijn naar een makkelijke erkenning. We zijn de laatste tijd veel selectiever geworden bij het evalueren van de ernst van dergelijke rapporten en we weigeren in sommige gevallen om CVE-meldingen uit te geven voor items met een lage ernst. Ik heb mijn bedenkingen bij het feit dat private disclosure sowieso aan het uitsterven is, waar ik een andere keer over kan schrijven, maar de inspanning die nodig is voor het coördineren van private fixes, disclosure-notificaties en releases is groot genoeg om ons te dwingen selectief te zijn.
Uiteindelijk is open source gebouwd op vertrouwen. De metriek die telt is niet hoeveel pull requests je een LLM kunt laten produceren, noch hoeveel CVE's je kunt verzamelen, maar of je een project wezenlijk beter kunt maken. Als je wilt bijdragen aan open source-projecten, doe dat dan omdat je erom geeft. Als je alleen maar op zoek bent naar een extra groen vakje of een contributor-badge, ga dan alsjeblieft ergens anders heen.
Stop met het overspoelen van onze projecten met AI-troep om je cv op te vullen
Succesvolle bijdragen aan open source-projecten zijn een soort valuta. GitHub stimuleert dit in het bijzonder op verschillende manieren: door avatars van contributeurs op repository-pagina's te tonen, door je bijdragen aan je volgers te laten zien via de activiteitsfeed en door het aantal bijdragen per dag weer te geven in de activiteitsgrafiek van je profiel. Potentiële hiring managers letten hier vaak op. Recruiters vinden en screenen kandidaten regelmatig op deze manier. Als je een softwareontwikkelaar bent (of wilt worden) die op zoek is naar werk, kan het bijsturen van deze signalen vaak in je voordeel werken.
Als beheerder van open source-projecten is het goed merkbaar hoe het patroon van externe bijdragen het afgelopen jaar is veranderd. We ontvangen veel vaker pull requests (PR's) in plaats van issues. Als we wel issues ontvangen, zijn die vaak voorzien van een door AI gegenereerde analyse. We ontvangen meer meldingen van beveiligingskwetsbaarheden dan ooit tevoren, en vaak zitten daar zelfs door AI gegenereerde voorstellen voor oplossingen bij.
Ik betwijfel niet dat sommige van deze bijdragen komen van mensen die oprecht geïnteresseerd zijn in wat we doen, maar het cynische deel van mij gelooft dat een aanzienlijk deel hiervan voortkomt uit het besef dat AI kan worden gebruikt om GitHub in eigen voordeel te manipuleren. Het is nu eenvoudig om Claude te vragen een lijst met interessante open source-projecten te genereren, Claude vervolgens te vragen problemen in die projecten te vinden, en Claude daarna te vragen PR's in te dienen om die problemen op te lossen. Je hoeft de projecten niet eens te gebruiken of ze boeiend te vinden, maar je kunt voor buitenstaanders gemakkelijk de illusie wekken dat je betrokken bent, dat je een probleem hebt ontdekt of dat je tijd hebt gestoken in de oplossing ervan. Op het internet weet niemand dat je een hond bent, maar met de hulp van LLM's kun je moeiteloos je menselijke capaciteiten op je GitHub-profiel overdrijven.
Onlangs heeft een contributeur, die van eind 2018 tot een paar weken geleden vrijwel geen bijdragen aan GitHub had geleverd en waarvan we geen eerdere betrokkenheid bij ons project weten, drie afzonderlijke PR's ingediend om spelfouten en grammaticafouten in commentaren te corrigeren. Claude had de correcties doorgevoerd, waarschijnlijk de beschrijvingen van de PR's geschreven, zelfs de commits namens de gebruiker ondertekend en vervolgens behulpzaam zijn eigen co-auteurschap in de commit-bericht trailers geplaatst. Misschien heeft de AI de PR's zelfs zelf geopend, wie weet. Ik zou gefascineerd zijn om te weten of de prompt "zoek naar issues" was, of dat er specifiek werd gefocust op spelling- en grammaticafouten, en waarom.
De wijzigingen waren onschadelijk en correct, maar dat zorgde er niet voor dat ik me prettiger voelde bij het accepteren of samenvoegen ervan. In plaats daarvan kon ik me niet anders dan afvragen: waarom dit, en waarom nu? Waarom dienen ze dit in, van alle issues, TODO's en FIXME's in onze codebase? Toen drong het tot me door dat deze bijdragen helemaal niet over ons project gingen.
Ik heb alle drie de PR's zonder commentaar gesloten.
Misschien was dit onredelijk, maar eerlijk gezegd ben ik niet geïnteresseerd in het aanmoedigen van mensen die onze tijd verspillen aan dit soort zinloos werk. Ik wil geen precedent scheppen door PR's te accepteren die materieel niets verbeteren, noch wil ik dat onze lijst met contributeurs een beloning wordt voor het vragen aan een robot om typefouten te herstellen.
Hetzelfde patroon is verschenen bij rapporten over beveiligingskwetsbaarheden. CVE's worden traditioneel toegeschreven aan de melders, maar alle rapporten die we onlangs hebben ontvangen, waren overduidelijk door AI gegenereerd. Beveiligingsfixes zijn natuurlijk altijd belangrijk, maar opnieuw vraag ik me af of dit gebeurt omdat mensen om de fixes geven of omdat ze op zoek zijn naar een makkelijke erkenning. We zijn de laatste tijd veel selectiever geworden bij het evalueren van de ernst van dergelijke rapporten en we weigeren in sommige gevallen om CVE-meldingen uit te geven voor items met een lage ernst. Ik heb mijn bedenkingen bij het feit dat private disclosure sowieso aan het uitsterven is, waar ik een andere keer over kan schrijven, maar de inspanning die nodig is voor het coördineren van private fixes, disclosure-notificaties en releases is groot genoeg om ons te dwingen selectief te zijn.
Uiteindelijk is open source gebouwd op vertrouwen. De metriek die telt is niet hoeveel pull requests je een LLM kunt laten produceren, noch hoeveel CVE's je kunt verzamelen, maar of je een project wezenlijk beter kunt maken. Als je wilt bijdragen aan open source-projecten, doe dat dan omdat je erom geeft. Als je alleen maar op zoek bent naar een extra groen vakje of een contributor-badge, ga dan alsjeblieft ergens anders heen.
Groetjes,