Linux Foundation wil opensource beschermen tegen stortvloed aan AI-bugmeldingen

De Linux Foundation wil ontwikkelaars van opensourcesoftware beschermen tegen een stroom aan bugmeldingen die steeds vaker AI‑gegenereerd zijn. De financiering hiervoor bedraagt 12,5 miljoen dollar en komt van Anthropic, AWS, GitHub, Google, Microsoft en OpenAI.

Het nieuwe project moet de beveiliging van opensourcesoftware verbeteren, stelt de Linux Foundation. Cybersecurity wordt steeds complexer, geeft de stichting aan. Dat komt ook door vooruitgang in AI. Dat verhoogt de snelheid en de schaal waarop kwetsbaarheden in opensourcesoftware worden ontdekt.

Ontwikkelaars die opensourcecode maken en onderhouden, worden bedolven onder een 'ongeëvenaarde toestroom' van meldingen van beveiligingsontdekkingen. Veel van die binnenkomende bugs zijn gevonden door geautomatiseerde systemen. Daarbij ontbreekt het aan de menskracht en technische middelen om al die meldingen te beoordelen en aan te pakken.

Onduidelijk

Twee beveiligingsinitiatieven binnen de Linux Foundation, Alpha-Omega en de Open Source Security Foundation (OpenSSF), willen dit nijpende probleem aanpakken. Zij krijgen daarvoor 12,5 miljoen dollar van bigtechbedrijven Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft en OpenAI.

Het is niet duidelijk wat Alpha-Omega en OpenSSF concreet gaan doen met die financiering. De Linux Foundation spreekt van 'het ontwikkelen van duurzame securityoplossingen' voor de lange termijn. Deze nog niet gespecificeerde tools moeten opensourcegemeenschappen wereldwijd ondersteunen bij het omgaan met binnenkomende bugreports.

Door Gemini gegenereerde afbeelding over AI-slop

Reacties (65)

[jeroen3]

Kan github geen chapta toevoegen aan de PR knop?

[wiseger]

Als de bug gevonden is door een AI tool en een menselijke gebruiker doet een pull request om deze bug op te lossen, dan zal het toevoegen van een chapta niet veel uitmaken.

Het probleem zit hem in de aantallen gevonden bugs en aantallen pull requests waar men mee te maken krijgt.

[pizzafried]

Zolang een captcha niet is op te lossen door AI, heb je in ieder geval een mens geforceerd om er naar te kijken.

De aantallen zijn inderdaad meer het probleem. Lijkt me dan dat mensen die een pull request doen eerst zich moeten verifiëren, waarna er een logisch limiet zit op het aantal meldingen per bijvoorbeeld uur, of op basis van je gemiddelde met een limiet. Een beheerder kan dan alsnog een gebruiker blokkeren als die daar misbruik van lijkt te maken.

[wiseger]

Vroeger moest je toch een aardig wat kennis hebben en een goede programmeur zijn, wilde je bugs in open source vinden en oplossen.

Tegenwoordig is dat niet meer zo, bijna iedereen kan open source code door een AI tool halen die dan met een lijst gevonden bugs en zelfs oplossingsvoorstellen komt. Het aantal gebruikers dat nu bugs rapporteert en pull requests doet, is zeer sterk toegenomen. De beheerders van open source projecten worden daardoor bedolven onder het aantal verzoeken. Ze kunnen het gewoon niet meer aan om alle verzoeken te beoordelen.

[Ablaze]

Ik mis alleen wat daar erg aan is.

Bugs zijn bugs. Je kunt ze klassificeren en op volgorde afhandelen. Er mag best een backlog zijn

[martijnvanegdom]

Als je ook de gebeurtenissen rondom curl en andere projecten volgt dan zie dat er wel een groot probleem aan het ontstaan is:

• De influx dreigt zo groot te raken dat het 'klassificeren en op volgorde afhandelen" eigenlijk niet meer te doen is. Er komt gewoon te veel binnen. Dat klassificeren en afhandelen kost namelijk gewoon veel tijd. Tijd die vroeger bij degene lag die de PR maakte.
• De kwaliteit van wat er binnenkomt er relatief laag. En bij curl werd bijvoorbeeld opgemerkt dan veel van de bugs helemaal geen bugs waren. En ja, N=1, maar als ik aan AI vraag om een security scan te doen van mij code dan is echt een heel deel van meldingen zijn of 1) geen bugs. 2) zijn zo minor dat het absoluut niet waard is om daar tijd in te steken. Ik heb letterlijk het comment van AI gehad: "je gebruikt ?id= is je query string, dit maakt het makkelijk om voor hackers te raken waarvoor dat veld gebruikt word.."
• Veel van de AI heeft vaak maar een klein inzicht in de code base. Dus er vaak te weinig contextueel begrip van wat er in de verschillende lagen gebeurd. Zo vertelde AI mij dat de er een groot gevaar was op SQL injection, omdat de input in mijn repository classes niet gecontroleerd werden. Echter, AI had niet de laag er boven bekeken of niet opgewerkt dat regel 1 in het dit project: Je valideert input daar waar het binnen komt en dat de input dus al gevalideerd naar de SQL class gaat. En het is niet efficiënt om dingen op 10 plekken te controleren.

Ik zeer zeker niet perse tegen AI. Maar je moet het controleren en verifiëren en dus weten wat het doet. En ik denk dat we aan het begin van een revolutie staan. Maar wat AI uit spuit is nog niet (voldoende) betrouwbaar).

Maar mensen die met weinig kennis software met AI maken en het vervolgens het de wereld in slingeren, dat is hetzelfde als met een LLM een brief sturen in een taal die je niet beheerst er blind verwachten dat het volledig correct is en dat je vervolgens krijgt wat je verwacht.

[Firestorm666]

Probleem is inderdaad eigen kennis.
De oorzaak hiervoor is (deels) ook te wijten aan het feit dat AI de grootste onzin kan uitkramen op een erg geloofwaardige manier.

[ElCondor]

Het zit hem juist in het feit dat AI het meestal verkeerd heeft en dat er onterecht bugs gemeld worden.

Dit is omdat er dan een bounty voor te verdienen valt. Als developer moet je dan toch aan de slag om een 'potentiële' bug door te kijken om na te gaan of het echt om een bug gaat, of dat het om een false 'positive' gaat. DIT proces kost veel tijd en dat is een groot probleem.

[Ablaze]

Aan de andere kant zou je kunnen stellen dat het beter is om 100 bugmeldingen te krijgen waarvan driekwart een false positive is, dan dat je ze niet kreeg.

Dat het werk kost om bug reports te klassificeren is duidelijk, maar uiteindelijk is er ook baat bij.

Ik denk dat je niet zou moeten "beschermen" maar juist de processen rondom het invoeren, klassificeren en verwerken van bugs beter en efficiënter moet maken.

[youridv1]

Aan de andere kant zou je kunnen stellen dat het beter is om 100 bugmeldingen te krijgen waarvan driekwart een false positive is, dan dat je ze niet kreeg.

Oneens. Zo veel ruis wil je niet en heeft vaak het gevolg dat de maintainers door de bomen het bos niet meer zien en de ontwikkeling daardoor vertraagt.

Als je dit zijn vrije loop laat, gaan er vanzelf een hoop maintainers gewoon stoppen met PR's accepteren.

[Reactie gewijzigd door youridv1 op 19 maart 2026 14:22]

[Zarhrezz]

Precies dit, het "boy who cried wolf effect" gaat er simpelweg voor zorgen dat alle PRs genegeerd gaan worden.

Heel veel open source is vrije tijd / hobby. Die tijd gaan maintainers echt niet gebruiken aan het beoordelen van een paar procent van de berg AI-PRs die heel misschien een echt probleem aankaarten. Een paar procent, want voor meer dan dat zullen heel veel maintainers simpelweg geen tijd hebben.

[ronansoleste]

Als je dit zijn vrije loop laat, gaan er vanzelf een hoop maintainers gewoon stoppen met PR's accepteren.

Dat zie je inderdaad nu al langzaam gebeuren.

[jaxxil]

Als maintainers betaalde medewerkers waren, dan was dat misschien zo. Maar dat zijn ze niet, het zijn vrijwilligers. Vrijwilligers die voor elk rapport moeten gaan zitten om uit te pluizen of het ergens uberhaupt wel ergens over gaat.

[SunnieNL]

Behalve dan dat die driekwart false positives zoveel tijd vergen dat er grote kans is dat een echte positive high prio te laat aandacht krijgt en het kwaad al is geschied.

[qlum]

Zeker niet het geval. Als open-source hobbyprojectje waar je bij wijze van spreken een vrijdagmiddag te besteden hebt. kun je die besteden aan 15 normale bugs waarvan er misschien 5 niet echt belangrijk zijn. Dus los je er 10 op.
Nu komen er 100 extra ai bugmeldingen binnen waarvan 75 troep, betekend dat je nog steeds 15 bugs onderzoekt, maar in plaats van 10 bugs los je er nu nog maar 5 op.

Het beste wat in in dit geval kan doen is ai bugmeldingen zo efficient mogelijk detekteren en niet ontvankelijk verklaren zonder menselijke uitleg. Kost wat tijd maar dan houd je misschien nog 8 bugs over die je oplost.

Dit is een beetje de realiteit voor veel van de open-source projecten. Tuurlijk cijfertjes zijn iets anders maar het aantal bugs dat binnenkomt is meestal niet de beperkende factor. Er zijn meestal meer bugs dan tijd om ze op te lossen. dus als er lagere kwaliteit reports bij komen doet dat meer kwaad dan goed.

[jaapsh]

Ik denk dat AI meestal gelijk heeft. Ik lees ook niets in het artikel dat het gaat om een grote instroom van foutive bug meldingen.

Dus eens met @Ablaze
Ik denk dat het positief is. En denk dat meer (valide) bugmeldingen alleen maar bijdragen tot betere software. Alleen de backlog voor een mens die ze moet controleren is inderdaad een issue.

[demianmonteverd]

Helaas. Heb je het zelf al eens geprobeerd? LLM's geven vaak verkeerde / suboptimale oplossingen. Ook SOTA modellen (ik schrijf dit in maart 2026).

[Barsonax]

Nou AI heeft het toch echt vaak goed mis. Al helemaal als de gebruiker zelf weinig kennis heeft want die kunnen het niet eens checken, laat staan de juiste vragen stellen.

Ik heb weinig keren dat ik met 1 prompt gelijk de goede oplossing eruit krijg. Ja ook met de beste modellen zoals Claude opus 4.6. Wie anders beweert weet gewoon niet waar hij het over heeft.

Kan mij helemaal voorstellen dat vrijwilligers bij opensource er echt helemaal klaar mee zijn.

[Firestorm666]

Ik dacht eerder deze week een artikel op tweakers te hebben gelezen hierover... of het was elders geweest.

Anyway..in dat artikel werdt aangegeven dat dit nu exact het probleem is:

PR van ontwikkelaar die feitelijk niks van het project afweet, gewoon wat in z'n AI gegooit heeft. De maintainer moet dan tijd en moeite steken in de grootste onzin. Vervolgens gaat die AI "ontwikkelaar" de feedback gewoon terug in z'n AI agent gooiden en........repeat.

AI is een krachtig hulpmiddel, maar het wordt nog altijd teveel gebruikt alsof het onfeilbaar is. Waardoor je op het einde van de rit meer tijd hebt gestoken dan als je het gewoon zelf had gedaan en dan tenminste zelf de kennis opgedaan over ontwikkelen en op die manier het project in kwestie leert kennen.

Als servicedesk medewerker gebruik ik ook maar al te graag AI, maar ik zie collega's soms klommelen en prutsen met AI over dingen die echt binnen 5 minuten opgelost kan worden als er de moeite wordt gedaan om eens ZELF iets op te zoeken.

AI is wat dat betreft niet anders dan ouderwets zoeken op forums/websites/social media: als je weet waar je mee bezig bent, kan het heel accuraat zijn omdat je dan zelf eruit kan filteren wat zever is en wat niet. Probleem met AI is dat het de grootste onzin erg geloofwaardig kan uitkramen.

[Ian Fox]

Wij gebruiken ook AI Copilot in onze GitHub repositories.


De rotzooi van suggesties die daar uit komt is fenomenaal. Zeker in combinatie met de "zekerheid" die vanaf de commentaar spat. Als je dan niet goed weet waarover het gaat...

Ik kan me inbeelden dat iets complexer als de Linux kernel nog meer BS geeft.

[NoTechSupport]

Bugs zijn geen bugs. Sommige dingen die als bug gemarkeerd worden zijn geen bug. Waar vroeger een mens met kennis van zaken nadacht over de "bug" en hoe die te rapporteren doet AI dat niet (goed genoeg). Bovendien zijn de rapporten zelf vaak door AI geschreven met veel ruis op de boodschap. Waar je vroeger aan iemand zijn schrijfstijl al een indicatie had van wie de bug rapporteerde en of die ziet waar hij/zij het over had moet nu eerst al die ruis weggefilterd worden. Dit vraagt veel energie (van echte mensen) die de de code onderhouden.

[pizzafried]

Het zijn er zoveel, en je moet dus prioriseren. Als de helft hetzelfde is maar anders omschreven, moet je veel werk doen om al die PR's of bug reports door te lezen, te begrijpen en bepalen wat er mee moet gebeuren. Dat is niet echt effectief te noemen...

[bouwfraude]

23000 Dezelfde meldingen gaat wat tegenwerken

[Olaf van der Spek]

Het probleem zit hem in de aantallen gevonden bugs

Probleem is vooral de aantallen gevonden non-bugs / false-positives..

[Meg]

Die werken vaak ook maar tijdelijk, tot een AI ze kan oplossen.

[IJsbreker]

Dit gaat via api's of de gh-tool via de cli. Dus het vermoeden is dat het AI is, maar het kan ook een mens zijn. Dat probleem kan je niet zo maar tackelen.

[Dala]

Als een van de pushers van genAI zou me dat verbazen.

[jprommen]

Een ai is niet gelijk aan een bot, mijn openclaw setup heeft gewoon captcha skill en als dat niet lukt, opent het een browser en lost die het daar op.

[cdwave]

Heel veel opensource sites zijn er al toe overgegaan om een soort "AI blokkade" voor hun sites te zetten.

De reden hiervoor was dat de "crawlers" die de AIs trainen idioot veel load veroorzaken omdat ze in tegenstelling tot de gewone zoekengines ook elk knopje en dingetje afstruinen ook als de site expliciet zegt dat ze deze link niet moeten volgen.

Waarschijnlijk gaat er nu gefilterd worden op "zal wel door AI gemaakt zijn" en alle PRs die van AI komen zullen zonder verdere actie de prullenbak in gaan.

[Exhonor]

Ben ik de enige die het redelijk toondoof vind dat er in artikelen over onderwerpen als overmatig AI gebruik en de overlast die het veroorzaakt alsnog dingen als AI-gegenereerde slop afbeeldingen worden gebruikt?

Het argument dat AI slop niet iets is wat we willen hebben wordt behoorlijk onderuit gehaald als je een AI slop afbeelding erbij zet die geen toegevoegde waarde heeft.

[bzuidgeest]

Het is alleen slop als het niets toevoegt, de afbeelding lijkt mij toepasselijk voor het artikel en is in mijn definitie geen slop. Alleen maar met AI gegenereerd en het is misbruik van de slop term om alles dat AI maakt zo te noemen.

Als een AI een arts helpt jou MRI te beoordelen en zo je leven red is het toch ook geen slop? Slop hangt af van de vraag, het resultaat en het doel.

[Exhonor]

AI een MRI laten beoordelen is echt totaal niet te vergelijken met het genereren van een plaatje als een plaatje niet eens noodzakelijk is om toe te voegen.

Wat mis je als dat plaatje er niet was geweest?

[bzuidgeest]

Wat verlies je als het plaatje er wel is. Opmaak en versiering is normaal in artikelen en website. Maakt de ervaring prettiger. De hele site hangt van "nutteloze" css aan elkaar. Zonder dat verlies je geen inhoud, maar het maakt de gebruikservaring minder prettig. Een beetje humor toevoegen met een plaatje kan de toon lichter maker, een beetje leuker. Als ze het een menselijke tekenaar hadden gevraagd had je niets gezegd. Dus wat is het probleem dat een AI dezelfde toevoeging heeft gemaakt voor tweakers?

[Exhonor]

Als ze het een menselijke tekenaar hadden gevraagd had je niets gezegd

Nee, klopt. Dan had ik er niks van gezegd, want mijn hele punt is dat het redelijk hypocriet is dat je een artikel schrijft waarin het gebruik van AI wordt bekritiseerd maar vervolgens wel doodleuk gebruikmaakt ervan om een plaatje te genereren.

Als ik naar een restaurant ga en een goedkope magnetronmaaltijd krijg voorgeschoteld en als ik erover klaag dat de ober zegt "Ja, maar als een kok dit had bereid dan had je niks gezegd"... Ja, dat is juist het hele punt.

[bzuidgeest]

Waarom is het hypocriet? Het gaat om twee heel verschillende gebruiksvormen van AI. Het ene is het automatisch genereren van PR's met nutteloze changes die developers overweldigen. Het andere is een plaatje genereren waar niemand last van heeft onder een artikel dat het artikel illustreert.

Je voorbeeld zou eerder moeten lezen als je krijgt een goedkope maaltijd in het restaurant van de robot en gaat dan klagen over de kleur van de muur omdat die ook door een robot geschilderd is.....

Gewoon omdat het ene gebruikt problematisch is, moet je niet alle gebruik ineens problematisch noemen.

En dat is precies mijn punt. Je noemt alles slop omdat 1 ding slop is.

[Dwarrelegel]

Eens.

Maar het is een artikel van Tweakers over dat Linux foundation geen AI wil. Iets oudere discussie: Tweakers beleid omtrent gebruik AI voor illustraties Maar volgens mij vind de redactie het prima om AI illustraties te gebruiken. Hier word zelfs nog gezegd dat ze transparantie willen aanhouden door zowel de LLM en prompt er bij te noemen. Iets wat bij het huidige plaatje dus alleen nog maar het merk is. Bij het oorspronkelijke artikel van dit plaatje hebben ze in elk geval nog de versie en exacte LLM staan.

De normalisering van AI.

[locke960]

Niet echt, dat is ironie en waarschijnlijk bewust gedaan.

[Exhonor]

Ik snap dat er bewust is gekozen om zo'n afbeelding toe te voegen.

Ik trek dit besluit alleen in twijfel. Als je een artikel schrijft over hoe slecht voedselverspilling wel niet is en vervolgens een hele maaltijd in de ton flikkert om er een foto van te maken 'ter illustratie' dan is dat toch ook niet de verenigen met de inhoud van de tekst?

Het is niet alsof dat plaatje essentieel is om het artikel te begrijpen.

[kdekker]

Ik heb zelf een keer gehad dat CoPilot zelf voorstelde een issue aan te maken (voor een Microsoft project). Kortom: het wordt ook wel heel makkelijk gemaakt om zoiets te doen. Als het de spuigaten uitloopt, zullen er vanzelf tegenmaatregelen genomen worden.

Mijn ervaring tot nu toe is dat agentic coding varieert van geweldig-wat-een-oplossing (die je zelf niet snel had verzonnen of zo snel opgelost) tot wat-stupide (een triviale fout niet eens meenemen in de denkrichting, maar veel complexere hallucinaties uitvoert).

[jeroen3]

Het genereert ook best wel vaak heel veel code die compleet overbodig is voor zijn eigen geboden oplossing.

[kdekker]

Klopt. Kun je wel een beetje tunen met instructies. Alleen: als je CoPilot inzet op een terrein waar je zelf geen specialist in bent, dan is dat al redelijk lastig te controleren.

Net nog even een simpele opdracht: controleer de indenting van files en of dit consistent tabs zijn ipv een mix van tabs en spaties. Wat gebeurde er: alle spaties werden vervangen door `t (backtick t, niet \t). Dat zit dan weer meer in de categorie stupide. Aan de andere kant: een veel complexere opdracht als: zorg dat de unittests gaan werken (ik had oude in/expected unittest resultaten en de backend vervangen). En dat lukte CoPilot ook. Iets wat ik zelf met veel meer tijd en moeite voor elkaar had gekregen.

[Louw Post]

Kan me nog herinneren van jaren terug dat mensen met standaard tooltjes je website gingen scannen en dan 'serieuze' problemen gingen melden en er soms ook nog geld voor wilden (zal vast nog steeds gebeuren).

Kan me goed voorstellen dat het met AI nog erger geworden is.

[braboman]

Dat gebeurt helaas nog steeds via serieus klinkende sites als openbugbounty.org

[jip_86]

Langzaamaan gaat het hele internet ten onder aan AI slop. Je ziet het overal dichtslibben.

Youtube is ook complete troep met AI videos. Plaatjesgenerators overal met dezelfde AI stijl. Games, DLSS5 word tot de grond afgebrand. Teksten allemaal met emojis en ga zo maar door.

Hopelijk komt er snel een grote ommekeer. Je ziet het al een klein beetje met bijvoorbeeld Microsoft die al aan het dimmen is, dat mag wel bij veel meer bedrijven.

[Schway]

met alles wat nieuw is zal het zijn plek moeten vinden, in het begin is het een stort vloed en na verloop van tijd gaat het settelen en vindt het zijn plaats. en als het onderdeel van regulier bestaan wordt, dan moeten we er mee leren leven over we het leuk vinden of niet.

[_FlasH_]

De meest simpele oplossing lijkt me een financiële drempel inbouwen voor het doen van een melding. In de orde van grootte van 1 euro bijvoorbeeld. Houdt de spammers buiten en is minimaal voor de goedwillende.

[SinergyX]

Oplossing is toch simpel? Zet AI in die bugs en PR's gaat beoordelen

[- peter -]

Dat is wat ze gaan doen denk ik eerlijk gezegd.

[smiba]

Ik mag toch echt hopen van niet, want dan krijg je de zelfde frustratie als bij de klantenservice van praktisch ieder bedrijf op het moment

Je komt met een duidelijk issue, duidelijke beschrijving en misschien zelfs een solution en dan krijg je zo'n koud dom AI antwoord die compleet de plank misslaat

Denk dat als AI PRs moet gaan beoordelen het echt de laatste spijker in de kist van open source is

[lappro]

Ze kunnen ook een stuk beter zijn dan die support chat bots.

Ik denk dat het best wel eens kan helpen. Heb zelf ook die AI reviews op merge requests. Alhoewel ik het geen volledige vervanging voor een menselijke controle vindt, helpt het wel als extra controle om er dingen uit te halen. En vindt ie dingen die nergens opslaan, kan je nog steeds makkelijk die comment gewoon sluiten.

Of het de hele oplossing is voor dit AI slop probleem, zal vast ook niet, maar het kan wel helpen denk ik.

[smiba]

Ze kunnen ook een stuk beter zijn dan die support chat bots.

Bron: Mijn onderbuik gevoel ?

Het feit dat de huidige modellen nog steeds niet eens een normale support chat kunnen hebben, geeft me absoluut nul hoop dat ze wel normaal complexe computer code kunnen reviewen. Eentje is praktisch gezien waar een LLM voor gemaakt is, de andere een technische computer instructie taal.

AI heeft zover m'n leven alleen maar lastiger gemaakt, ik kom meer slop code tegen in reviews, ik kom onmogelijk frustrerende AI support chats tegen, mensen om me heen raken uitgebrand door de extreme influx van spam geschreven door AI wat ze tijd kost.

Helaas is pandora's doos al geopend, maar van mij had deze dicht mogen blijven betreft AI.

[lappro]

Bron is dat ik het gebruik op mn werk. Worden regelmatig goede opmerkingen op de merge requests gezet. Zijn private projecten dus is niets om naar te linken.

[demianmonteverd]

Een aantal projecten doet dat inmiddels met coderabbit.

[kdekker]

Dat gebeurt al of gaat gebeuren. Je ziet nu al in de release notes van visual studio 2026 dat er speciale agents komen. Bijv. review agents.

Ik denk zelfs dat de AI (gekte?) zover gaat dat functioneringsgesprekken en sollicitaties door AI beoordeeld zullen gaan worden. Nu nog hopen dat iemand gaat beseffen dat de meeste mensen het niet leuk vinden dat AI henzelf (indirect) beoordeelt. Ik vermoed dat weinig mensen echt beseffen wat de impact is van AI. En zeker onoordeelkunding gebruik nog lelijke missers zal gaan veroorzaken.

De filosofische vraag: hoe ver zal AI gaan, als mensen steeds luier/dommer/efficienter/slimmer/gemakzuchtiger (doorstrepen wat niet van toepassing is) worden en AI geen menselijke feedback meer krijgt, maar doen moet met de informatie die (andere) AI agents bakken. Wat krijg je als je lucht met lucht bakt? Je zou zeggen dat het op een zeker moment AI aan z'n max zit, tenzij - en die mensen zijn er - denken dat AI zelfstanding denkvermogen heeft (a la een mens).

[demianmonteverd]

Ook dit gebeurd al, code reviews voor OSS projecten zie je nu al door coderabbit gaan. Sollicitaties worden al door AI beoordeeld inmiddels met agents in de VS. Functioneringsgesprekken, ik heb gewerkt bij een bedrijf waar men uitgebreide word macros gebruikte om een leidraad te genereren. Die werd dan voor elke afdeling aangepast. Elk jaar kregen alle afdelingen een paar aanpassingen vanuit HR. Dus... het zal al wel gebeuren inmiddels.

Over je tweede stukje, ja dit is heel gevaarlijk. Je ziet dat er op internet ook vaak onzinnige rommel word geplaatst met als doel AI modellen in de war te krijgen met mis- en desinformatie. Dat gebeurde al met wikipedia, maar nu is het echt los aan het gaan. Hier op tweakers zijn er ook wel een paar geweest waarvan je kunt vermoeden dat de accounts gebruikt worden om desinformatie te verspreiden, maar die vermoedens kun je natuurlijk lastig hard maken. Op deze site valt het gelukkig nog mee, maar kijk eens om je te ergeren op MSN... Heel gevaarlijk, als die rommel in de trainings data voor toekomstige LLM's gebruikt gaat worden.

[willemoldemans]

Hoeveel procent van de PR zijn ook daadwerkelijk kritische bugs? Als dit voldoende hoog is dan heeft het beperken van de PR’s niet persé het gewenste effect. Helemaal als de AI tools of developers straks de bugs niet meer doorgeven aan de foundation maar aan kwaadwillende partijen

[starfight]

Als maintainer van een paar opensource projecten, ENORM veel, op 1 van de projecten zijn 80% PR's AI slop PR's die bugs fixen die geen bugs zijn.
AI heeft gewoon inherent het probleem dat ze niet de volledige codebase kennen, en tools als GitNexus helpen daar wel wat bij, maar het is geen geen geval een vervanging van iemand die even de moeite neemt om te kijken wat de AI wil aanpassen, of of dit niet intended is.

[demianmonteverd]

Deze mensen krijgen vaak niet betaald hiervoor of doen het erbij. Het is al een karwei om zonder AI PR's bij te blijven, nu gaat het nog meer van ze vragen. Dat zal problemen gaan geven.

[starfight]

https://aiforautomation.io/news/2026-03-20-half-github-pull-requests-ai-bots-prompt-injection-trap

[xoniq]

Je ziet het al een klein beetje met bijvoorbeeld Microsoft die al aan het dimmen is

Is dat zo? Ze hebben niks afgeremd. Ze hebben alleen aangegeven de doorvoer van AI in Windows minder opzichtig te maken omdat ze merken dat er steeds meer weerstand komt van de Windows gebruikers en men steeds meer bereid is alternatieven te zoeken.

Er is niks gerept over verwijderen / minderen van daadwerkelijke AI.

[Skit3000]

Wat is het probleem bij een bugmelding als die feitelijk correct is, of die nu door AI of een mens is gevonden? Hoe meer hoe beter lijkt mij zelfs, al moet je dan inderdaad wel meer tijd stoppen in uitvogelen welke bugs het belangrijkste zijn om snel te verhelpen.

Krijg je consistent AI-gegenereerde bugmeldingen die niet kloppen, zou je natuurlijk een soort van "three strikes and you are out"-principe toe kunnen passen en niet meer naar bugs van die melder kunnen kijken (of pas op een later moment), maar dat hoeft geen samenwerkingsverband tussen alle genoemde grote softwarepartijen van 12 miljoen te zijn.

[Reactie gewijzigd door Skit3000 op 19 maart 2026 13:36]

[demianmonteverd]

Er moet iemand naar kijken. Als je honderd keer waardeloze rommel krijgt, dan begint het minder hobby en meer werk te worden. Wie wil dat nu onbetaald volhouden?