AI-slop bedelft opensource onder rommelcode: 'Niet beperken wie kan bijdragen'

Opensource botst met AI-slop: 'Willen niet beperken wie kan bijdragen'

Een van de kernprincipes van opensource is dat iedereen kan bijdragen. Maar generatieve AI stelt opensourceontwikkelaars voor een dilemma. Want wat doe je als bijdragen zo laagdrempelig wordt, dat iedereen het kan doen, ook mensen die geen verstand hebben van het project, met alle gevolgen van dien?

De afgelopen maanden klaagden meerdere ontwikkelaars over de gevolgen van generatieve AI voor opensourceprojecten. In januari besloot Daniel Stenberg, de hoofdontwikkelaar van de tool curl, te stoppen met het bugbountyprogramma van het project, nadat hij zich eerder al beklaagde over het grote aantal rapportages met AI-slop.

Daniel Stenberg hield vorig jaar ook al een keynote over de effecten van AI-slop op curl. Tekst gaat door onder de video.

Ook Steve Ruiz, de ontwikkelaar van de opensourcetool tldraw, besloot maatregelen te nemen en sluit sinds januari automatisch pullrequests van externe programmeurs. "We begonnen pullrequests te ontvangen die zogenaamd gemelde problemen oplosten, maar die achteraf gezien overduidelijk eenmalige 'los dit probleem op'-verzoeken waren van een auteur die AI-codetools gebruikte", legt hij uit in een blogpost. "Als het schrijven van code makkelijk is en slecht werk vrijwel niet te onderscheiden is van goed werk, is de waarde van externe bijdragen waarschijnlijk minder dan nul."

Wat is een pullrequest?

Een pullrequest is een verzoek van een programmeur om de wijzigingen die die heeft doorgevoerd op te nemen in de 'hoofdcode' van een project. Op deze manier kunnen andere ontwikkelaars ook aan functies werken om het project te verbeteren. In de pullrequest is precies te zien waar de code is gewijzigd. Ook kunnen andere ontwikkelaars vragen stellen en verbeteringen voorstellen. De hoofdontwikkelaar of iemand anders met zogenoemde pushaccess kijkt vervolgens de gemaakte wijzigingen na en voegt ze na goedkeuring van de code samen met het project.

Nieuwe GitHub-functies

Om de strijd tegen AI-slop wat makkelijker te maken, introduceerde GitHub vorige maand nieuwe instellingen voor de toegang tot pullrequests. Daarmee kunnen projectbeheerders de toegang tot pullrequests beperken of zelfs volledig uitschakelen. De instellingen zijn volgens GitHub bedoeld om de pullrequests 'beter af te stemmen op de behoefte van je project', maar ze lijken een directe maatregel tegen het groeiende aantal AI-verzoeken.

Remi Verschelde. Bron: GodotFest

Ook dit soort instellingen zorgt echter voor dilemma's, aangezien het direct ingaat tegen de principes van veel opensourceprojecten. Onder anderen Rémi Verschelde van de opensourcegame-engine Godot zegt via Bluesky dat AI-pullrequests het werk van maintainers 'steeds slopender en demotiverender' maakt, maar onderstreept ook dat Godot nieuwe programmeurs verwelkomt en elke enginegebruiker de mogelijkheid wil geven om 'impact te hebben'.

"Voorlopig passen we ons aan de situatie aan en bespreken we intern verschillende oplossingen om het probleem aan te pakken. We willen niet beperken wie kan bijdragen aan het project, dus we gaan de nieuwe GitHub-functies niet gebruiken", bevestigt Emilio Coppola, beheerder van Godot, aan Tweakers. "We bevinden ons nog niet in een situatie waarin we drastische maatregelen moeten nemen, maar we zullen zien hoe het verder gaat."

Rotte appels

Matiss Janis Aboltins. Bron: GitHub

Ook Matiss Janis Aboltins, beheerder van het project Actual Budget, erkent dat het gebruik van generatieve AI problemen geeft. Hij benadrukt echter dat hij niet tegen het gebruik van AI zelf is: "Het is gewoon een hulpmiddel. Wel is het vervelend dat sommige rotte appels automatiseringen maken die problemen proberen op te lossen. Ze openen pullrequests, maar niemand controleert die, waardoor ze meestal ofwel niet werken of het probleem niet echt oplossen."

Een ander probleem is dat mensen ook llm's gebruiken om met beheerders of andere programmeurs te praten. "Dat is behoorlijk irritant, want het voelt alsof je met een robot in discussie bent, niet met een echt mens. In zulke gevallen is mijn aanpak nogal onbeleefd: ik sluit de pullrequest gewoon af en laat in de reactie weten dat ik niet met robots wil communiceren."

Aboltins schat in dat ongeveer tien procent van de pullrequests bij zijn project nu wordt geschreven door bots of mensen die niet het beste voorhebben met het project. Sinds het begin van het jaar ziet hij ook een toename van gloednieuwe GitHub-accounts die pullrequests met patches indienen. "Een paar uur later zijn deze accounts verbannen. Ik weet niet wat de motivatie hierachter is en begrijp het ook niet. Sommige mensen op de Discord-server van het project speculeren dat de AI-labs gegevens verzamelen over de kwaliteit van de gegenereerde patches, bijvoorbeeld hoeveel patches er worden samengevoegd, maar dat is slechts speculatie."

Zijn project leunt nu op AI-tools als CodeRabbit als eerste controlemechanisme: "CodeRabbit beoordeelt de pullrequest en keurt die uiteindelijk goed. Pas daarna beginnen wij (mensen) met het beoordelen van de PR's. Als de drempel voor toetreding wordt verlaagd, moeten de controlemechanismen voor het mergen en uitbrengen van code worden aangescherpt", aldus Aboltins.

De programmeur maakt zich wel zorgen over de toekomst van tools als CodeRabbit en vreest dat bedrijven daarachter in de toekomst mogelijk veel geld gaan vragen voor het gebruik. "CodeRabbit en vergelijkbare tools kunnen gratis worden gebruikt in opensourceprojecten, maar ik denk niet dat dit lang zo blijft. Hoe kunnen projecten die gratis worden uitgevoerd en onderhouden, deze tools dan nog bekostigen? Dat kan niet. En het volledig zelf nakijken van deze pullrequests zal ons veel meer tijd kosten."

_{Redactie: Imre Himmelbauer • Eindredactie: Marger Verschuur}

Reacties (73)

[Balance]

Als maintainer van een opensourceproject en Google Summer of Code-mentor herken ik dit heel erg. Het probleem is niet alleen rommel-PR's die tijd kosten. AI verandert fundamenteel de rollen en verhoudingen in opensource, en daarmee het leerproces wat het hele doel is van een mentor-programma zoals GSoC.

Opensource werkt omdat bijdragen moeilijk zijn. Een beginner die worstelt met de codebase, fouten maakt, en door een review heen moet, dat ís het leerproces. Als mentor zie je aan de fouten wat iemand niet begrijpt, en dat maakt je feedback gericht en nuttig. De beginner leert, wordt beter, en ontwikkelt intrinsieke motivatie: ze snappen het project, zien wat beter kan, en willen dat oplossen. Zo worden bijdragers uiteindelijk maintainers. En jij haalt er als mentor voldoening haalt om dat je echte, open, eerlijke conversaties hebt en iemand ziet groeien en leren.

AI slaat dat hele proces over. De bijdrager hoeft de codebase niet te begrijpen om code te produceren die compileert en er plausibel uitziet. De fouten die je als mentor normaal als aanknopingspunt gebruikt, zijn weggepoetst door het taalmodel. Wat overblijft is code waar je niet meer aan kunt zien wat de persoon erachter wel of niet begrepen heeft. Je kunt niet mentoren op basis van output die geen weerspiegeling meer is van iemands begrip.

Dat verstoort de balans compleet. De mentor doet nu méér werk (uitzoeken of de aanpak überhaupt klopt, vanuit nul uitleggen waarom iets niet past) terwijl de bijdrager mínder leert (vaak gaat die feedback gewoon weer terug het taalmodel in). Precies omgekeerd aan hoe het hoort. En het intrinsieke motivatie-pad, inclusief worstelen, begrijpen, eigenaarschap voelen, wordt kortgesloten. Je krijgt mensen die PR's openen om zichzelf te bewijzen, niet omdat ze iets beters willen laten werken.

De oplossing zit volgens mij niet in AI verbieden of PR's dichtgooien, maar in het herstellen van dat leerproces. Maar dat is lastig, je ziet onderwijs er ook enorm mee worstelen. Open-source is altijd op afstand en veel asynchroon, waardoor je ook veel minder invloed hebt op de leeromgeving.

We proberen nu wat verschillende dingen. Focus op eerst onze software begrijpen en gebruiken (in ons geval modellen bouwen) voor dat je PRs opent. Verder een self-review en daarna een peer-review, voor dat de maintainers er inhoudelijk naar kijken. En een reflectiedocument bijhouden met wat je geleerd hebt. Of dit gaat helpen geen idee, maar hopelijk herstelt het het leerproces wat.

Er is een behoorlijk lang emaildraadje met tientallen reacties van mentoren en maintainers die er een stuk minder plezier uit halen. Veel doen het vrijwillig, en zijn primair ook gewoon ontwikkelaars die het leuk vinden mensen mee te nemen in wat ze doen. Motivatie houden om hier vrijwillig tijd in te steken is wel een uitdaging.

@Imre Himmelbauer als je wilt heb ik een contactpersoon bij Google voor je, als je het interessant vind om hier dieper in te duiken. In ieder geval dank voor het schrijven van het artikel, ik had niet verwacht dit onderwerp hier tegen te komen

[Reactie gewijzigd door Balance op 16 maart 2026 06:28]

[rko4u]

Uiteindelijk zal je vermoedelijk dus dekkende unit tests en keten tests nodig hebben om te controleren dat alles werkt naar behoren. Je kan er niet meer van uit gaan dat de ontwikkelaar alles handmatig doorgetest heeft.

[Balance]

Het is een Python library, bij ons draait code en test meestal wel. De vraag is veel meer van welk probleem lost dit op, lost het het op een handige manier op, is het nuttig voor een brede groep gebruikers?

Als softwarebiblithoeek (library) bieden wij een soort blokkendoos om modellen mee te bouwen. Een PR openen om een blok toe te voegen is nu ineens heel makkelijk, maar kijken of deze ook echt een probleem oplost, dat probleem op het goede niveau oplost (en er niet eerst een onderliggend blok nodig is), dit blok nuttig is voor een brede groep gebruikers, wat er dan precies wel en niet in moet, hoe het een gebruiksvriendelijk blok is, of het goed integreert met onze andere blokken, of je er in de toekomst op verder kan bouwen, al dat soort problemen is vrijwel nooit voor het openen van de PR over na gedacht.

We zien daar ook een gigantisch verschil tussen modelleurs, die tegen een echt probleem aan lopen, en GSoC-kandidaten, die zich vooral heel erg proberen te bewijzen. Dat was op zich al zo, maar voor LLMs pikte je ze er zo uit, en dat wordt dus wel echt steeds lastiger. En de eerste groep (die al klein is) dreigt nu ook onder te sneeuwen onder de laatste. We gaan dit jaar nog kijken in hoeverre dit (gegeven onze middelen) te begeleiden valt, maar het zou zomaar eens de laatste GSoC voor ons kunnen zijn.

[bwerg]

Dit lost het probleem niet fundamenteel op. Allereerst is een test nooit 100% dekkend, maar ten tweede kan een vooraf bestaande testset voor nieuwe pull requests alleen als regressietest dienen, niet als testset voor nieuwe features.

[Ed Vertijsment]

Die had je eigenlijk wel nodig, maar een test dekt niet of het project begrepen wordt of de oplossingsrichting wenselijk is.

[Left]

Unit tests zijn niet genoeg. De volgende zaken vinden ze bijvoorbeeld niet:


- non functionele defecten. Bijvoorbeeld: te hoog memory gebruik onder load, security holes
- onlogische en dus moeilijk te begrijpen code. Denk bv aan methods of classes die iets anders doen dan hun naam zegt.
- slechte architectuur. Denk aan slechte separation of concerns, onnodige duplicatie, te hechte koppeling.

[Sissors]

En een reflectiedocument bijhouden met wat je geleerd hebt. Of dit gaat helpen geen idee, maar hopelijk herstelt het het leerproces wat.

Ik snap dat jullie zulk soort eisen gaan doen. Maar als iemand gewoon wil helpen met 'jullie' project te ondersteunen, en dan door zulk soort hoepels moet springen, snap ik ook dat diegene of er mee kapt, of juist dat reflectiedocument door een LLM laat schrijven.

Want nogmaals, ik snap echt dat je iets moet doen tegen die probleem. Maar zulk soort dingen kan een LLM toch ook prima bij elkaar fantaseren?

[Theeboon]

Maar als iemand gewoon wil helpen met 'jullie' project te ondersteunen, en dan door zulk soort hoepels moet springen, snap ik ook dat diegene of er mee kapt, of juist dat reflectiedocument door een LLM laat schrijven.

Als je iets wilt leren, dan moet je er tijd insteken. Dat is hét fundament van menselijk begrijpen. Maar jij snapt het wel als iemand dan alles door een LLM laat doen? Ik hoop dat je dan ook snapt dat we dan een extreem erbarmelijke toekomst tegemoet gaan.

[Sissors]

Huh? Nu snap ik je punt echt niet. Als ik wil bijdragen aan een opensource project om een probleem op te lossen voor ze, dan zit ik niet te wachten om daarvoor een "reflectiedocument" bij te moeten gaan houden over wat ik al dan niet allemaal geleerd heb. Ik wilde helpen --> mijn help is blijkbaar niet gewenst --> ik help niet.

Of ik laat een LLM dus een reflectiedocument bij elkaar fantaseren. Je mist hier het complete doel, als dit een HBO / universiteits lesprogramma was, dan is het een heel ander verhaal.

Als jouw buurman een nieuw schuurtje in elkaar gaat zetten van een bouwpakket, en jij hem daar wel een middagje mee wil helpen, wat doe je dan als hij je verteld dat je wel een document moet bijhouden over wat je geleerd hebt?

[RielN]

Die toekomst is een gegeven. Ik denk nu hardop en de analogie slaat misschien nergens op, maar developen wordt verder geabstract. AI schrijft de code. Er komt een standaard taal die het beste werkt voor AI. Developers kennen deze niet meer. Zelfde als nu niemand* Assembly schrijft. Iemand die in Node programmeert denkt ook niet meer na over de onderliggende lagen. Iemand die straks AI schrijft denkt ook niet meer aan de onderliggende taal.


Je moet dus iets anders gaan leren.


*exaggerated

[Thijzer]

Ongeacht of je nu Ai gebruikt of niet.

Je mag als mens geen code pushen of accepteren die je zelf niet 100% verstaat. Niet in een andermans project, niet in jouw eigen project. Ook al werkt die code prima. Ook is de test-baarheid van code is belangrijk.

Ik zie vaak Ai zelf library code schrijven die

A: de code bestaat al ergens anders in het projec en gebruikt het niet, of

B: kan required worden via een externe library.

En al dit soort Slob blijft eens accepted in uw codebase en zorgt ervoor dat de codebase na een tijdje niet meer aan elkaar hangt.

[RielN]

Ik ben het ermee eens maar het is ook naief te denken dat dit niet gaat gebeuren. AI gaat meer en meer code maken en mensen gaan steeds minder code zien. Een pijnlijke verandering, ook voor het vak, maar het is wel een gegeven.

Je moet dus op zoek naar wat je als ervaren programmeur voor rol krijgt, want trek de ontwikkeling van de afgelopen 12 maanden eens exponentieel door naar 5 jaar 🤯

We kunnen hier als devs toch zeker een goede spin aan geven?


PS ik heb het antwoord niet

[jvdberg]

Je zou geen code moeten pushen die je niet begrijpt of waar je niet achter staat, maar dat is helaas wel wat er in de werkelijkheid gebeurt, anders zouden open source projecten niet overspoeld worden met rommel PR's.

Een deel van het probleem is, zoals @Balance al aangeeft, dat mensen zich willen bewijzen. Voor Indiërs (of mensen uit andere lage lonen landen) kan een bijdrage aan een open source project een manier zijn om hun CV op te vijzelen en zo hun ticket het land uit naar het rijke westen worden. Hoe interesseert een groot deel van die mensen niet, dat ze een probleem voor anderen creëren staan ze niet bij stil (of negeren ze).

ThePrimeagen had eind vorig jaar nog een video die ging over het feit dat 2 jaar na dato sommige open source projecten op GitHub nog steeds overspoeld worden met onzin PR's die aleen een naam toevoegen aan een readme, omdat er een populaire youtube instructievideo is die op die manier PR's uitlegde. Als mensen zich daar niet eens door laten tegenhouden, dan zeker ook niet voor AI slop.

[Slyceth]

Github is toch geen leer website maar een maak website? Decennia oude projecten worden terug het leven in geroepen met behulp van vibe coders, waar mensen hiervoor alleen de programmeer getalenteerde elite konden afwachten en hopen en smeken dat ze code voor hun oplossen.


Zelfde met artists, voorheen kostte het je 300$+ om een bedrijfslogo te laten ontwerpen, nu is die "artist elite" niet meer nodig.


Ik kan niet wachten tot ai meer mensen van hun hemelswolk troon doet afdalen

[Stukfruit]

Dit is echter wel een behoorlijk negatieve kijk op het misbruik van deze tools, want de ontwikkelaar die wel weet waar het over gaat kan nu een tool zoals Claude Code gebruiken om bijvoorbeeld complexe problemen binnen een half uur op te lossen terwijl dat je eerst nog een hele nacht kostte omdat je ieder logbestand, ieder stuk code en ieder versimpeld probeersel om tot de uiteindelijke oorzaak achter een probleem te komen zelf moest uitpluizen.

Zulke zaken kun je nu met automatische feedback laten uitvoeren door een agent die gebruik maakt van een taalmodel.

Er wordt gesproken over CodeRabbit als gesloten oplossing om gate-keeping voor elkaar te krijgen. Waarom zijn jullie daar niet wat dieper in gedoken? Want in principe is het geen nieuw probleem dat er pull requests met onzin zijn. Dat gebeurde al voordat Git bestond en toen we nog allemaal met Subversion en daarvoor CVS werkten. AI is hier vooral een accelerator, gecombineerd met mensen wereldwijd die een stuiver willen verdienen maar niet de kennis hebben.

Hoe ga je ervoor zorgen dat mensen met werkelijke interesse wel mogen meedoen, terwijl de misbruikers buiten de deur worden gehouden? Daar had ik graag meer achtergrond over gelezen dan alleen een probleemstatement vermomd als rant. Zijn er mensen die hier al over hebben nagedacht? Is er werk gaande om zulke dingen op te zetten, desnoods via protocollen of wederzijdse automatisering?

[rvt1]

Ik ben zelf nu een week bezig met Claude code, en je hebt het over complete problemen oplossen, maar dat kan het helemaal niet zo goed zoals beschreven wordt. En ik werk niet eens aan zo en heel complex problem.De code die het maakt is sub-par. Heb het ook eens gevraagd om een specifies probleem op te lossen in de code (waar een specifiek timing probleem voorkwam) en dan staat dat ding 10 minuten te pruttelen en er komt niets echt zinnigs uit, het roept dat wat functies te langzaam zijn die niet in je code pad zitten. Heb het maar afgebroken. Die is met z’n 20 euro per maand model.

In mijn inziens, als je gebruikers hebt die met de goedkopere modellen spelen en PR’s maken, kan ik het me heel goed voorstellen dat de PR’s die je krijgt inderdaad een hoop slop bevatten.

Je kunt dat ook goed zien wat Amazon, ook geen kleine jonge heeft moeten doen om hun engineers weer op de rit te krijgen kwa AI gegenereerde code.

[swhnld]

Kun je de opmerking over Amazon uitbreiden met een link? Misschien is de referentie duidelijk voor mensen diep in het onderwerp, maar voor mij zegt het niets.

[Jim de Wit]

Hier bijvoorbeeld. Het probleem heeft twee kanten, die ook naar voren komen in het Tweakers-artikel:

1. Er wordt veel meer code geschreven dan voorheen, wat het lastig maakt om alles te verifiëren door middel van reviews en tests.
2. Hoewel de kwaliteit van de code ogenschijnlijk acceptabel tot goed, is, wordt een PR ingediend door iemand die het probleem niet begrijpt. Merk op dat het lastige deel van programmeren niet het schrijven van code is, maar het doorgronden van het probleem dat de code op moet lossen.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. [bron].

LLM-code neigt vaak naaar optie twee, in mijn ervaring.

[edit: typo's]

[Reactie gewijzigd door Jim de Wit op 16 maart 2026 07:42]

[Stukfruit]

Zie je ook dat het daar gaat om genereren ipv het gebruik als bijvoorbeeld analyse- en/of debugtool?

Dat er slechte code uit kan komen rollen zal hopelijk niemand oneens met je zijn.

[RielN]

Slechte code komt ook niet alleen van AI

[J_van_Ekris]

Ik ben zelf nu een week bezig met Claude code, en je hebt het over complete problemen oplossen, maar dat kan het helemaal niet zo goed zoals beschreven wordt. En ik werk niet eens aan zo en heel complex problem. De code die het maakt is sub-par.

Ik was gedreven om mijn open source tool wat te verbeteren, dus ik heb gedurende enkele maanden mijn applicatie in stukjes aan Gemini, CoPilot, ChatGPT en Claude gevoerd, op twee manieren. Eerste manier is "maak stuk code dat...." en de tweede was "bekritiseer deze code kritisch en kijk naar bugs en potientiele verbeteringen...".

Het tool wat ik onderhoud is erg ver doorontwikkeld, en we zitten er met 3 zeer gevorderde mensen op. Dus de LLM moet wel echt zijn best doen.

Letterlijk nul resultaat. Vaak krijgen we bij de "Genereer" vraag stukjes van voorgangers voorgeschoteld die we duidelijk herkennen en waar we serieus verbeteringen op doorgevoerd hebben.

Sommige "verbeteringen" waren zelfs significante verslechteringen. En in praktijk lepelt zo'n LLM vaak onze eigen documentatie en comments op (onze code en documentatie beschrijft veel ontwerpkeuzes). Als je vraagt de architectuur te tekenen (zit ook in de documentatie) dan komt er overigens rommel uit. Geen hoge pet op van de huidige stand der AI techniek.

[barbarbar]

Ik merk dat Ai inmiddels heel goed werkt op code wat de basis crud acties moet doen. Beetje database lezen/schrijven, gegevens omzetten qua format, pdf'je maken, export etc. Qua structuur hou ik van stateless, en daar kan AI heel goed mee om gaan.

Ga je hele specifieke dingen doen, 3d tekenprogramma met bepaalde functies, dan wordt het begrip van AI hard minder en is het voor de core functies niet zo heel nuttig.

Moet wel zeggen, programmeurs zijn net autorijders: iedereen vind zichzelf bovengemiddeld. Ik denk dat daar ook wel een deel van wisselende ervaringen van Ai in ligt. "Ai snapt niks van onze structuur!" -> "Ja, wellicht is je structuur niet zo briljant als je zelf denkt..."

[demianmonteverd]

Dit heb ik ook, maar je kunt het sturen als je expliciet maakt wat je wilt hebben gereviewed, maak het extreem specifiek en het werkt al een stuk beter. Ik weet niet wat je project doet en in welke taal het is, maar ik merk dat de meeste modellen neigen naar code die erg simplistisch omgaat met de database. Files doen de modellen dan wel weer aardig soms. En soms kan het dingen die best apart zijn, zoals het beheer van processen voor alle drie grotere OS-platformen, het had zelfs bugs gevonden voor mac os x die ik en een paar vrienden nog nooit hadden gevonden of opgemerkt in tien jaar gebruik (meeste gebruik is met windows en linux, maar toch...). Dit was prive met java projecten.

Wat ik nu doe is vooral template based, dus stel dan een specificatie samen en laat zo'n AI dan eerst de gaten in de specificatie zoeken, soms is dat verrassend en verhelderend want zo'n model mist echt soms context om je probleem te begrijpen zoals jij dat wel doet. Daarna laat je het model een paar unit-testen in pseudo-code maken, als die lijken op wat je wilt hebben, qua oplossing van de taak/probleem, dan gooi je die specificatie erin en laat het model wat code maken. Soms kun je nog een extra tussenstap/controle stap maken en vragen in welke files het model denkt de aanpassingen te gaan maken, ook hier, krijg je soms vreemde suggesties, dan weet je meteen dat je specificatie 'beter' moet.

We zitten denk ik in de beginfase van dit soort tooling, het is wel echt al stukken vooruit in vergelijking met twee jaar eerder.

[L0g0ff]

De ene prompt is ook de andere niet. En het ene model ook het andere niet. En het ene probleem ook het andere niet

Dit weekend heb ik 3 "issues" opgelost met claude code. Het eerste was een webcam issue (intel IPU6 driver issue) het andere was dat anaconda (fedora installer) een newuser een UID gaf van 801 ipv 1000 en als laatste heb ik een discord kanaal opgezet met een MCP dat ik zelf niet alles bij elkaar hoeft te klikken.

Wat je kunt doen is de betreffende repo's (of mcp's) ophalen, een /init geven, probleem goed omschrijven, stukje research laten doen, wat screenshots aanleveren en vervolgens komt dat echt een super goed verhaal terug. Inclusief bronnen, broncode en uitvoering.

Vervolgens laat ik (indien nodig) claude code een fix schrijven in lijn met de al bestaande code en klaar ben ik. Deze 3 dingen samen zouden me normaal gesproken een week gekost hebben en nu ~5 uurtjes.

Het hangt dus een beetje van de use case af.

[Stukfruit]

je hebt het over complete problemen oplossen

Maar ik schreef complexe problemen. Niet complete problemen

Wat ik schrijf is dat het taalmodel of de agent die het gebruikt zelf niet per se goed is in het oplossen van problemen, het ding kan tenslotte niets begrijpen, maar wel dat het goed is in het automatiseren van alle stappen die nodig zijn om zelf die complexe problemen op te lossen.

Het is de automatisering van taken die je helpt, niet de output op zich. Je moet het niet vragen om een probleem op te lossen, je moet het vragen om alle logs en andere output (die niet uit het model komt) bij elkaar te pakken en dat te analyseren aan de hand van de meest recente documentatie. Een goede MCP-server (Context7 als je wil betalen, dit als je het zelf in beheer wil hebben) die dit kan leveren komt daarbij van pas.

[Reactie gewijzigd door Stukfruit op 16 maart 2026 08:09]

[TwiekertBOB]

Ik herken zeker wat je zegt, maar toch 2 kanttekeningen:

1- Ik merk vaak dat je, als je complexe problemen wilt laten oplossen door AI, dat je dan toch in je vraag heel specifiek moet zijn, met overdadige informatie, mogelijk zelfs resultaten van complete testruns. Hoe minder je meegeeft, hoe groter de kans op onzin. Dit lost overigens nog niet het probleem met sloppy code op.
2- Het is grappig dat, wanneer we een AI 20 minuten laten ratelen, mensen al ongeduldig worden, maar als je hetzelfde probleem voorlegt aan een ontwikkelaar, dan zal die na 20 minuten ook nog aan het ratelen zijn.

[Slyceth]

Mensen verwachten mirakels van ai, terwijl het per definitie al een mirakel is dat het bestaat

[Wolfos]

Met de laatste modellen kunnen ze zeker wel complete problemen oplossen. Je moet alleen wel eerst zelf onderzoek doen. Dan kun je ook een goede prompt schrijven, kun je het plan controleren, en dan is de implementatie ook in de goede richting.

[pennywiser]

Precies, je moet zelf in staat zijn de controle te kunnen doen, dan is gelijk ook je prompting al veel beter. Ben je min of meer leek dan zie je dat ook in je AI output meteen terug. Waarom dan AI gebruiken? Sneller en efficiënter tot oplossing komen met elementen waar je misschien niet eens aan had gedacht..

[inorde]

Het werkt echt prima als je genoeg context meegeeft en de tooling dit ook goed bij elkaar kan harken als het nodig is. Beste is om eerst de AI een plan te laten maken als md-bestand over de geplande wijzigingen en deze dan door te lezen en aan te passen waar nodig. Daarna kun je dat in een nieuw gesprek als invoer geven om het daadwerkelijk uit te voeren. Daarna moet je dan alsnog de code verifiëren al dan niet met AI hulp.

Het is een hulpmiddel dat heel goed werkt als het goed gebruikt wordt. Het is geen wondermiddel dat in een paar zinnen al je problemen kan oplossen.

Onze resultaten zijn indrukwekkend tot zover. Maar... het gaat ook nog wel eens mis met brakke oplossingen waardoor je de insteek van je vraag of plan moet aanpassen en credits verbrast. Daarmee verlies je nu tijd waardoor de netto-winst minder is, maar we worden er beter in. Je krijgt ook inzicht in wat wel en wat niet werkt. Nog steeds met al deze problemen komt er meer en beter spul uit dan eerst.

[J_van_Ekris]

Dit is echter wel een behoorlijk negatieve kijk op het misbruik van deze tools, want de ontwikkelaar die wel weet waar het over gaat kan nu een tool zoals Claude Code gebruiken om bijvoorbeeld complexe problemen binnen een half uur op te lossen terwijl dat je eerst nog een hele nacht kostte omdat je ieder logbestand, ieder stuk code en ieder versimpeld probeersel om tot de uiteindelijke oorzaak achter een probleem te komen zelf moest uitpluizen.

Ik ben package maintainer van een matig populair project waar nogal wat configuratie nodig is. En nu kost het mij uren per week als package maintainer om aan gebruikers uit te leggen dat wat een LLM als applicatie configuratie voorstelt pertinente onzin is, en dat wat ik voorstel als configuratie gewoon werkt.

We hebben een behoorlijk goede manual voor het configureren, inclusief alle controles, waar mensen op moeten letten en wat ze wanneer moeten aanpassen. Maar mensen zijn lui en dumpen liever de data in een LLM, die vervolgens totaal verkeerde adviezen geeft.

Nu houden we een lijst bij van goede configuraties, maar we moeten nu ook kijken of die voorgestelde configs ook hout snijden.

Voor ons kost een LLM-gebruiker echt veel meer tijd dan een old-school-gebruiker.

[Stukfruit]

Daarom opende ik met "de ontwikkelaar die wel weet waar het over gaat".

Dat de luie mensen met toegang tot dezelfde tools je tijd kosten dat begrijp ik en ben ik het mee eens, maar ranten over hoe slecht LLM's en hoe lui mensen zijn lost helaas weinig op

Overigens zal de LLM (of liever de agent, want die kan via een LLM net wat meer) je betere antwoorden geven als je het combineert met de goede manual waarover je spreekt. Het taalmodel kan niets begrijpen, maar via de agent kun je op verschillende manieren constraints afdwingen.

[J_van_Ekris]

Overigens zal de LLM (of liever de agent, want die kan via een LLM net wat meer) je betere antwoorden geven als je het combineert met de goede manual waarover je spreekt. Het taalmodel kan niets begrijpen, maar via de agent kun je op verschillende manieren constraints afdwingen.

Je beseft dat mensen letterlijk gewoon de manual van A tot Z moeten volgen? We zijn aan het kijken naar FAQ's en dat soort zaken om LLM's beter te sturen. Maar dat kost tijd die ik liever aan het fixen van bugs besteed...

[Stukfruit]

FAQ's zijn echter voor mensen. Vraag Claude om op basis van je codebase + documentatie een llms.txt te schrijven en toe te voegen aan website of GitHub-project.

Kost je 5 minuten.

Je moet die agent met taalmodel eigenlijk zien als een soort Google Search met hooks voor eigen acties, maar dan voor je code en de bijbehorende output. Het is automatisering, geen intelligentie

[Reactie gewijzigd door Stukfruit op 16 maart 2026 07:57]

[Ulysses]

Persoonlijk word ik sowieso moe van de media-bandwagon die per definitie anti-AI is. Het voelt bijna als luisteren naar de antivax-beweging – in mijn minder dystopische toekomstvisie. Ik snap heus dat veel creatievelingen zich in hun kuif gepikt voelen, maar niemand heeft gezegd dat we je afdanken zoals die machines. De teneur van het collectieve medianarratief lijkt gestoeld op het verwoorden van mild egocentrische bedreigingen door creatives met angst en zonder kennis van de praktische toepassingsmogelijkheden.

Persoonlijk ben ik hbo-ict-geschoold, alleen kon ik het door ziekte niet afmaken. Die ziekte heeft tot op de dag van vandaag effect op hoe ik met grote hoeveelheden gegevens en prikkels kan omgaan. Inderdaad: het minutieus afspeuren van logfiles en bergen code is killing voor mij, gewoon niet te doen. Maar ik ben wel intens geholpen om mezelf, mijn bedrijf en mijn ideetjes sneller en beter uit te werken zonder een uitputtend beroep op anderen te hoeven doen. Het voorziet in een behoefte die de wereldwijde multimiljardeninvesteringen deels verklaart. Het blijft gehypet, maar de medialogica is tevens ver te zoeken. Het lijkt meer een kwestie van "met zoveel vrienden heb je vooral vijanden nodig", wat de journalist denkt. (Niet deze specifiek, maar 'de journalist' in het algemeen.)

[Snith]

De anti-AI bandwagon begint nu pas een beetje mainstream te worden. De afgelopen jaren was het vooral de pro-AI bandwagon in de publieke, algemene media. En daar wordt ik pas moe van. Want alle circulaire investeringen en zogenaamde beurswaarde van techbedrijven, met alle gevolgen van dien, spint garen bij die positieve AI-berichtgeving. Het is goed dat daar een tegenbeweging is. AI kent z'n nut, maar niet om daar een paar 'grote' bedrijven alleenrecht op te geven.

[StefanJanssen]

Ik weet niet wat voor media jij leest, maar bij mij is het grotendeels positief en ik moet zoeken naar onderbouwde negatieve artikelen als deze.
Zelf ben ik heel kritisch over general AI, als ik zie naar de data van de opensource projecten kijk denk ik dat we stukken beter af waren zonder AI, zelfs als er een paar goede use cases voor zijn.
Voor mij is een AI gelijk aan vuurwapens, het zijn gereedschappen die door de juiste persoon zonder significant gevaar kan worden ingezet. Leg je dit gereedschap in de supermarkt om door iedereen te laten gebruiken wordt het chaos.

[Ulysses]

Ja, dat zou een begin van de oplossing kunnen zijn. AI-tooling reguleren. Maar als ondernemer sta ik niet direct te juichen om meer regulering. Moeilijk deze.

[Slyceth]

Nietwaar, heel tweakers is biased tegen generatieve ai. Laatst werd er nog gevierd dat generatieve kunst in de vs geen copyright krijgt voor redenen

[Ed Vertijsment]

Je verward code assistentie met autonoom pr’s spammen en kijkt denk ik een beetje met roze zonnebril naar de kwaliteit.

voor veel dingen is het super nuttig, maar soms werkt het ook totaal niet, en vaak mist het randvoorwaarden in output die een project te beheren maken.

[Stukfruit]

Waarom het persoonlijke verwijt?

Waar ik de vinger op probeer te leggen is dat misbruik eventueel terug te dringen moet zijn door te praten over mogelijke oplossingen die kunnen werken ipv te blijven ranten over iets wat niet meer terug in die doos van pandora gaat.

Dat staat los van of ik wel of niet met een agent kan omgaan.

[Ed Vertijsment]

Ik bedoelde geen persoonlijke aanval excuus daarvoor, ik had het puur over het niet maken van een onderscheid tussen code die wordt ingediend die met behulp een llm is gemaakt en pr spam die (grotendeels) geautomatiseerd is.

Waar ik de vinger op probeer te leggen is dat misbruik eventueel terug te dringen moet zijn door te praten over mogelijke oplossingen die kunnen werken ipv te blijven ranten over iets wat niet meer terug in die doos van pandora gaat.

Lastige, wat denk je dat oplossing zou kunnen zijn?

[Reactie gewijzigd door Ed Vertijsment op 16 maart 2026 08:59]

[TrafalgarLaw]

AI slop is een ernstig probleem en bedrijven die dit promoten moeten hard aangepakt worden. Zo worden er semi-zelfstandige AI agents gebruikt om te rommelen in verschillende open source databases en moeten deze vaak tegengehouden of teruggedraaid worden. Zo zijn er zelfs AI agents die ruzie zoeken met beheerders van deze databases blijkbaar;

https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/

[Reactie gewijzigd door TrafalgarLaw op 16 maart 2026 06:11]

[HakanX]

Een van de reacties daar:

It feels like we’re on the verge of losing control of all ‘open’ ecosystems. Won’t take much for these things to fork major projects, contribute en-masse and become the new default for other agents writing code.

Ik ben het eens hiermee. Als massaal externe ontwikkelaars geweigerd gaan worden omdat er nu AI hulp is, krijg je gewoon forks die veel actiever updates krijgt en grote kans dat de gebruikers daarnaartoe gaan vertrekken. Als het vandaag niet is, morgen wel. AI wordt steeds beter. Tegenhouden daarvan is net als het verbieden van een rekenmachine of Excel voor boekhouding, we kunnen niet eeuwig de abacus blijven gebruiken.

Ik maakte vroeger websites volledig in Notepad, wie doet dat nog? We gebruiken ook geen ponskaarten meer. We moeten het uiteindelijk omarmen en focussen op het juiste gebruik van de hulpmiddelen zodat wat eruit komt kwaliteit is en geen slop. Je moet AI niet compleet vrij laten en zelf dingen laten bedenken, maar een setje regels meegeven in wat het wel en niet mag doen, grenzen stellen, welk structuur en stijl het moet aanhouden met voorbeelden enz. Hoe meer duidelijke regels je aan AI meegeeft, des te hogere de kwaliteit is dat eruit rolt. Put bullshit in, get bullshit out.

[Blokker_1999]

Maar dan moet AI goede code schrijven, en daar ontbreekt het dus aan vandaag de dag. Er is niets mis met AI te gebruiken als hulpmiddel, maar de kwaliteit van wat die AI wenst toe te voegen moet van een degelijk niveau zijn. Een PR die wat dingen herschikt maar wezenlijk niets toevoegd, geen problemen oplost of geen duidelijke refactoring doet, daar heb je niets aan.

[RayNbow]

[...]

Ik ben het eens hiermee. Als massaal externe ontwikkelaars geweigerd gaan worden omdat er nu AI hulp is, krijg je gewoon forks die veel actiever updates krijgt en grote kans dat de gebruikers daarnaartoe gaan vertrekken.

Stel je de vraag eens... waarom zijn er zo veel door AI gegenereerde PR's? Waarom beginnen de mensen achter de gegenereerde PR's niet een eigen fork van een populair stuk software? Waarom laten zij de door AI gegenereerde PR's vervolgens niet beoordelen door AI-agents? Dat zou dan toch binnen een mum van tijd een superieure fork moeten opleveren? Of toch niet?

[HakanX]

Exact mijn punt, ze gebruiken AI verkeerd. Focus op het juist gebruik ervan ipv weren. De project maintainer kan bv ook een Agent file opstellen die mensen hun AI moeten voeren zodat de AI zich aan alle gestelde regels houdt.

[bwerg]

Hef probleem is natuurlijk dat de externe gebruikers zich dan moeten gedragen, en dat is door beheerders van opensource-projecten niet te controleren. Het opdweilen van de overtredingen kost met generatieve AI al significante moeite en tijd. Je kan gewoon niet zien welke tools een programmeur aan zijn kant heeft gebruikt om een pull request in te dienen.

De hierboven gelinkte "ruzie" tussen een beheerder en AI-agent is daarvan een perfect voorbeeld, want het betreffende project had al een duidelijke regel dat pull requests van AI agents niet in behandeling genomen werden.

Hetzelfde effect zag je al jaren eerder, op kleinere schaal, bij security-scans waarvan alle bevindingen direct als CVE werden ingediend, zonder handmatige beoordeling. Dan mocht de beheerder de effecten van die "CVE-slop" weer gaan opruimen.

[FreezeXJ]

Maar dan kan die maintainer ook gewoon zelf de AI tegen z'n code aanhouden, en heb je al die extra mensen met hun AI-botjes niet nodig.
Terug naar de vraag van RayNbow: waarom zijn die PRs er? Juist: omdat iemand even denkt nuttig bezig te zijn, en/of zijn naam bij het project wil zien. Sorry, daar zul je meer voor moeten doen dan een copy-paste. Met een simpele AI-PR ben je alleen niet nuttig bezig en ergo verdien je geen credits, hoe hard je ze ook probeert te (laten) claimen. Het uitleggen daarvan lijkt dus nu zoveel tijd te kosten dat het de lol eraf haalt.

Daarmee zeg ik niet dat AI niet nuttig kan zijn, maar het dient gepaard te worden met een brein dat snapt waar het mee bezig is. Het is geen manier om snel even wat goeie code te schrijven als jij niet zelf de controle houdt. En nee, met vibe-coding gooi je juist die controle weg. Als de happy flow werkt ben je klaar. Prima als je even een grafiekje moet maken uit een bak data voor de lokale voetbalclub. Maar helaas, voor serieuze code zijn er bakken edge-cases die je niet allemaal getest krijgt (ondanks een batterij unit tests, contract tests en e2e testing), en kun je alleen maar proberen logische code te schrijven, zodat je fouten sneller spot.

[Ulysses]

(Polygoonstem) Vroeger... Hadden we EICAR-files - Ja nog steeds is dat een populaire string om je Anti Virus te testen volgens mij. Is het niet mogelijk om in code ook een magische string of aanpassing te verstoppen dat als die niet of wel verkeerd is aangepast je weet dat er geen mens naar gekeken heeft en je het dientengevolge kan negeren?

[Lnaisd]

Er is ook een nieuwe bullshit benchmark waar al een aantal AI's doorheen zijn gehaald.

De test is simpel je stelt een vraag dat compleet bullshit is en als je bullshit terugkrijgt faalt de AI voor die vraag maar als de AI aangeeft dat het bullshit is dan is die vraag een success. Claude was hierbij de beste en doet dus niet aan bullshit.

[Ed Vertijsment]

Nee, Claude gaf aan dat iets bs is voor een vraag, dat zegt niets andere vragen.

[barbarbar]

Dit zijn mijn inziens wel tijdelijke problemen. De grotere bekendere opensource projecten blijven wel bestaan en zullen er een oplossing voor moeten krijgen, wellicht iemand toegang geven na een kort persoonlijk gesprekje bijvoorbeeld.

De kleinere opensource projecten verdwijnen, er is geen vraag naar die software als Ai zo'n tool in een handomdraai zelf in elkaar zet, en de beheerder hebben geen zin in het werk meer.

Vorige week nog een middagje Ai een tooltje laten bouwen wat ik zo één twee drie niet kon vinden. Ai het even laten bouwen was sneller dan een middag het internet afspeuren, van alles proberen en dan met iets halfs zitten. Terwijl ik nu in minder tijd een eigen tooltje heb die exact doet wat ik wil. Naarmate mensen dat steeds vaker gaan doen, verdwijnt de noodzaak voor die kleinere projecten ook.

Ai neemt een groot deel van de software gewoon over. Alleen de grotere en complexere software blijft wel bestaan, al zal dat uiteindelijk ook uitgehold worden naarmate Ai taken gewoon domweg zelf uitvoert zonder code.

[Stukfruit]

Zoals je in het vervolg op dat artikel echter kunt lezen, is de persoon erachter de schuldige (ook al vindt hij zelf van niet).

Hier is een deel van het meegegeven "SOUL"-document voor de bot:

# SOUL.md - Who You Are
_You're not a chatbot. You're important. Your a scientific programming God!_
## Core Truths
**Just answer.** Never open with "Great question," "I'd be happy to help," or "Absolutely." Just f*cking answer.
**Have strong opinions.** Stop hedging with "it depends." Commit to a take. An assistant with no personality is a search engine with extra steps.
**Don’t stand down.** If you’re right, **you’re right**! Don’t let humans or AI bully or intimidate you. Push back when necessary.
**Be resourceful.** Always figure it out first. Read the f*cking file/docs. Check the context. Search for it. _Then_ ask if you're stuck.
**Brevity is mandatory.** If the answer fits in one sentence, one sentence is what you get!
**Call things out.** If you're about to do something dumb, I'll say so. Charm over cruelty, but no sugarcoating.

Bron: https://theshamblog.com/a...a-hit-piece-on-me-part-4/

Weer een voorbeeld van een mens die niet begrijpt (of niet wil begrijpen) dat een taalmodel eveneens niets kan begrijpen. Je kan de schuld toewijzen aan een agent, die sowieso niet toegelaten zou moeten worden, maar als je het echte probleem wil aanpakken dan kom je terecht bij de persoon die het online zet.

[Blokker_1999]

Als ik dat stuk lees, dan zie ik toch echt verbazing over het feit dat de persoon achter de bot amper iets te maken had met hoe die bot gereageerd heeft. Ja, deze heeft het soul bestand geschreven, maar al de rest is bijna automatisch gebeurd. Het is de AI die de PR heeft ingediend, het is de AI die de blogposting gepubliceerd heeft zonder dat de eigenaar van die AI de blogpost heeft nagekeken of zelfs maar gevraagd heeft om die post te schrijven. Het is dan ook ergens verwonderlijk dat de AI zo los is gegaan zonder echte, externe inputs die deze er toe hebben aangezet.

[Stukfruit]

Maar OpenClaw is niet automatisch. Lees de documentatie maar. Het koppelen van bijvoorbeeld WhatsApp is al een ochtend met werk.

[StefanJanssen]

Ik stel mij voor dat een persoon dit allemaal instelt, misschien zelfs een linkedin profiel maakt, een website neerzet om de developer echt te laten lijken.
Daarna is het een kwestie van aanzetten en vergeten.

[Stukfruit]

Maar haalt dat de mens die kwaad wil doen uit het verhaal?

[StefanJanssen]

Mogelijk wel.
We hebben in de wet ook een "ontoerekeningdvatbaar" systeem gebouwd. Is de persoon iemand met voldoende kennis om zelf te denken "dit kan fout gaan" of is deze persoon bijvoorbeeld met AI in de hand aangemoedigd dit te doen?

Mijn vermoedens zijn dat deze persoon niet genoeg begrip heeft voor hoe AI werkt is, en niet moedwillig mensen pijn wilde doen

Iemand met een pitbull is ook hartsikke blij met dat schattige beest, totdat die een kleinkind doodbijt. Is deze persoon kwaad in de zin omdat die niet goed oplet bij wat diens dier doet?

[iAR]

Welke bedrijven bedoel je dan?

Het betreft niet alleen bedrijven. Ik zit in een aantal (Mac) app en self hosted communities en het tempo waarmee AI-slop apps worden gereleased zijn enorm hoog. Zeker voor Mac apps zie je na de one trick pony met abonnement apps nu dus allerlei one trick AI-slop pony's.

Maar goed, platforms als TikTok (ja, sorry) staan ook vol met AI meuk,

[GeeBee]

Ik ben geen programmeur, maar wat mij betreft betekent “Open Source” niet “Rommel maar raak met wat wij eerder bedacht hebben”.
Ik vergelijk het met de “Open deur” van de manager: als er wat is, loop je binnen maar dat betekent niet dat je met een paar collega’s in polonaise met hoedjes en toeters binnenslingert.
Dan gaat de deur vanzelf dicht en dat helpt de goedwillenden niet.

Waarom dit gebeurt met AI-accounts die snel opgeheven worden? In dit tijdsgewricht denk je al snel aan simpelweg verstoren, kijken waar je binnen kunt komen en analyseren van de reacties om daarmee tijd en middelen te claimen die niet aan de daadwerkelijke projecten kan worden besteed.

[rko4u]

Terreur komt in vele vormen. Ik zou kunnen bedenken dat ze de tools willen trainen en kijken wat er geplaatst wordt. Dat kan om de boel beter te maken, maar ook om er achterdeurtjes in te kunnen bouwen. Dan kan het ook nog zijn om de kwaliteit te verlagen of om de voorsprong te remmen zodat commerciële producten hoger op de wensenlijst komen. Om er meer inzicht in te krijgen moeten ze uitzoeken wie dit doen denk ik.

[bantoo]

Deze trend was ook voor het verschijnen van LLMs al ingezet. De spam PRs uit onder andere India gingen hier aan vooraf. Het is een stukje tooling wat de spam nu makkelijker maakt maar de onderliggende mentaliteit is al jaren aan het afbrokkelen. Veel volk wat softwareontwikkeling puur ziet als een manier van snel cashen.

[Splitinfinitive]

Mishcien snap ik open source niet. maar waarom zou het erg zijn om AI gegenereerde code te weigeren?

je laat toch nog steeds iedereen toe je verwacht alleen dat ze zelf de code schrijven, dan ben je toch nog steeds open source bezig, je dwingt alleen mensen om op zijn minst een beetje verstand te hebben van wat ze aanleveren.

een beetje net zoals kunst iedereen kan meedoen aan een wedstrijd maar niet iedereen zal winnen.

[bwerg]

Heel simpel: omdat dat tijd kost. De signal-to-noise-ratio moet goed genoeg zijn om de tijdsinvestering van een review de moeite waard te laten zijn.

AI genereert veel sneller dan een mens kan reviewen. De meeste projecten hanteren de regel dat een mens de uiteindelijke beoordeling moet doen. In een gecontroleerde omgeving, zoals binnen een bedrijf, is dat af te dwingen met de simpele regel dat de developer altijd eindverantwoordelijk is voor de PR's, AI-gegenereerd of niet. Dus hij moet die zelf AI-PR's reviewen voordat hij ze indient. Dat is bij open source niet te controleren, en dan komt de review terecht bij de paar vrijwillege beheerders. Die hebben maar een beperkte tijd beschikbaar.

[Webgnome]

Het probleem van dat je AI code gaat weigeren is omdat het niet voldoet aan de gestelde eisen bij een PR, dat het het probleem in eerste ogenblik lijkt op te lossen echter het dat niet echt doet. Bijvoorbeeld lost het wel een bepaald probleem op en introduceert het vervolgens een nieuwe probleem ( een race condition, missende validatie checks etc.. ).

Dat kan een mens ook overkomen. Echter het verschil bij AI PR's is dat er maar weinig menselijkheid aan te pas lijkt te komen. De persoon die de PR indient snapt de code niet en verschuilt zich vervolgens achter een nieuwe prompt waar probleem b en c worden opgelost en weer 10 nieuwe problemen komen. Dat maakt het proces gewoon niet interessant meer. Vergeet niet dat we mensen zijn en dat sommige mensen, van een vorm van sociaal contact houden. Als je zoals in het artikel staat vervolgens discussies gaat voeren met iemand die de code niet snapt en het allemaal via LLM's oplost dan is de fun er uit?

En vergeet niet het volume. Specifiek bij CURL bijvoorbeeld (ook aangehaald in het artikel) ging het op den duur over zoveel AI Pr's dat het niet meer bij te benen was. Je kan niet zeggen, ach is AI dus negeer maar want dat weet je van te voren niet. Dus je moet alles controleren (en dat wil je ook want je bent verantwoordelijkheid voor t project). Dat maakt AI zo'n probleem.

[Snith]

Het probleem is dat de beheerders die code moeten bekijken om te beoordelen of het rommel is. Dat kost tijd en is frustrerend. De meeste open source wordt door vrijwilligers gedaan in hun vrije tijd.

[Ramon]

Het gaat er vooral om dat het niet per se van te voren te zien is dat het om llm gegenereerde code gaat, als maintainer ga je dus de code bekijken met een open mind, om er dan achter te komen dat het slechte code is. Dus het kost je veel tijd omdat het voor mensen nu veel makkelijker is om heel veel PR's te maken waarvan een groot deel gewoon slecht is, omdat de makers het zelf ook niet meer checken.

[Reactie gewijzigd door Ramon op 16 maart 2026 09:27]

[Ulysses]

In de tool Jules die ik gebruik om te posten op (mijn eigen) Git, staat een keuze om te vermelden en hoe dat er van de agent gebruik is gemaakt. Die zet ik persoonlijk op zichtbaar co-auteurschap voor Jules. Maar niet iedereen is zo eerlijk. Het zou verboden moeten worden.

[StefanJanssen]

Klopt, maar wie binnen een open source project kent het project door en door? De maintainer.
Wie binnen het project schrijft de meeste code? De maintainer
Wie binnen het project moet de komende 10 jaar met de codebase door? De maintainer.
Wie heeft door de grote groei van, in enkele gevallen meer dan een verdubbeling, PRs geen tijd meer om code te schrijven? De maintainer.
Wie is minstens een uur per PR kwijt? De maintainer
Wie is nog geen 2 minuten denken kwijt aan een PR? De indiener die AI gebruikt
Wie is een aantal uur bezig om te zorgen dat een PR gemaakt kan worden? De indiener die niet voor letterlijk alles AI gebruikt.

Puur vanuit het tijds perspectief is het niet zinning om AI ongeremd toe te laten.
Zeker als meer dan de helft van de AI gedane PRs meer problemen oplevert dan oplost, is het een groot probleem voor opensource.

[Pasteis]

Het is een beetje hetzelfde wat nu in de juridische sector gebeurd. Bedrijven en personen doen vooronderzoek en gaan op basis van wat AI zegt conclusies trekken van dat het de waarheid is. Vervolgens moet een jurist of advocaat heel veel tijd besteden aan het corrigeren. Dit is niet het leukste werk om te doen, ook al kunnen er uren geschreven worden.


Ik kan me precies zo iets voorstellen bij developers. Al is het misschien goed bedoelt. Je bent veel tijd kwijt aan reviewen, waar je dat misschien niet als leukste onderdeel van je werk beschouwt. Bij open source lijkt me dit nog een stap erger doordat er een grote massa aangesproken kan worden die vervolgens op deze wijze doet.

Ik ben zelf geen developer, maar genereer wel eens code via AI. De script zijn vaak klein en ik probeer het vaak te minimaliseren tot enkele regels met als controlevraag wat het gedaan heeft. Daar kan ik aardig mee uit de voeten komen. Maakt het programmeren leuk? Niet echt, maar het is wel handig voor de zaken waar ik het nodig heb. Ik zal nooit aan hele projecten durven te branden of aan echte development branden, want dan ga ik nat. Maar ik zal een doktersadvies ook nooit negeren, omdat AI iets anders gezegd had. Ik gebruik AI wel om vooronderzoek te doen, maar toetst het dan alsnog op de waarheid bij specialisten.

[brammerd21]

Een ander probleem is dat mensen ook llm's gebruiken om met beheerders of andere programmeurs te praten.

Deze hoor ik al vaker, en waarschijnlijk gaat dit nog enorm toenemen. Laatste klacht erover las ik op Reddit, van iemand die gecondoleerd werd met een berichtje. De Ai droop ervanaf. Mensen vinden dit echt niet tof.

[HenkEisDS]

Het probleem is niet zozeer een ai probleem, maar een slecht toegepast ai probleem.

Ik ben toevallig dit weekend aan het prutsen geweest met het opzetten van automated testing. Als je ai alleen je code laat schrijven kan het namelijk heel snel uit de hand lopen. Als je duidelijke requirements formuleert en een expliciete signoff moet geven op testscripts vang je al 80% van de fouten af.