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. Inmiddels accepteert curl wel weer bugrapporten, hoewel daar nog steeds geen beloningen voor worden uitgekeerd.

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 • Afbeelding gegenereerd door Nano Banana 2}

Reacties (226)

[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.

[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.

[hamsteg]

Ook dat kunnen unit testen zijn

Wij hebben performance metingen als unit testen draaien, evenals disk en memory consumption. Soms irritant, want als er wat toegevoegd wordt moet je weer nieuwe parameters definiëren maar heeft ons ook al vaak behoedt. Verder draaien wij sanitizers op max en en lint tooling, zeker ook gericht op leesbaarheid van de code; uit deze laatsten komt de laatste tijd steeds minder door AI als reviewer te gebruiken.

Maar je hebt gelijk, ergens is er echter een grens en zul je gewoon zelf aan het werk moeten om nut en noodzaak ter discussie te stellen.

[stefanhendriks]

yeah right, jij gaat voor elke feature die je bouwt een memory check (middels een unit test) doen? Ga je ook dan code metrics gebruiken om te checken of je cyclomatic complexity boven waarde "n" ligt om te snappen of de code "begrijpelijk" is ?

Punt blijft je hebt mensen nodig om dit te kunnen doen toch?

[hamsteg]

Ja dat doen wij, dus maak het niet belachelijk. En je tweede vraag bevestig ik toch?

[eborn]

Interessant. Over wat voor applicatie praten we dan en hoeveel FTE is daar bij betrokken als ontwikkelaar?

[hamsteg]

Medical & Food. Embedded devices dus resource kennis is key.

[stefanhendriks]

belachelijk maken? Ik vind het moeilijk te geloven, gezien de gigantische effort nodig is om voor elke feature/cross-cutting concern dit te realiseren. Jammer dat je het zo opvat.

Als je het werkelijk doet vraag ik me af hoeveel moeite het kost om dit te bouwen (en betrouwbaar uit te voeren) en vol te houden. Alleen al een "normale" unit test suite onderhouden kan een enorme uitdaging zijn. Maar wellicht is je applicatie niet zo groot en is het te overzien.

Vind je het juist geen risico door dat soort precieze kennis en kunde uit te besteden aan AI? Ik heb vaak zat met AI in rondjes zitten draaien omdat het simpelweg geen echt begrip heeft wat er in de code gebeurd.

[hamsteg]

Misschien moet je je verdiepen in Food en Medical grade software engineering (=FDA guidelines)?

Niet alles is een-beetje-testen en klaar software á la MS.

[Reactie gewijzigd door hamsteg op 23 maart 2026 14:13]

[stefanhendriks]

Elke software is anders en zonder toegang tot wat voor repo dan ook is er niets zinnigs over te zeggen. Als je verder nergens op in wil gaan dan dank ik je voor je tijd.

[hamsteg]

Waar moet ik op ingaan dan? Als jij het V model kent, weet je dat verificatie in Food en Medical grade software 50, 100% tot 200% van je pure engineering is. Nu heb je het van mij zwart op wit.

Het kost veel moeite, absoluut maar daarmee bouwen historische evidence op waardoor je bij een Notified Body makkelijker door de submissie komen. Submissies kosten ook geld dus daar zit de trade-off.

Misschien moet je eens een open mind hebben in plaats van denken dat je gelijk hebt?

Vind je het juist geen risico door dat soort precieze kennis en kunde uit te besteden aan AI? Ik heb vaak zat met AI in rondjes zitten draaien omdat het simpelweg geen echt begrip heeft wat er in de code gebeurd.

AI is een hulpmiddel, geen absolute waarheid. Wij gebruiken het niet voor trekken van conclusies maar voor ondersteuning in concept ontwikkeling, reviews en testen. Alles risico gebaseerd.

[Reactie gewijzigd door hamsteg op 23 maart 2026 14:25]

[djwice]

- 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.

Deze twee zou je wellicht met een taalmodel in de validatie flow kunnen detecteren.

De ander

- non functionele defecten. Bijvoorbeeld: te hoog memory gebruik onder load, security holes

bijvoorbeeld door een runtime waarop bijvoorbeeld een PlayWright scenario wirdr uitgevoert met meting van het mem gebruik voor en na de wijzigingen.

[Reactie gewijzigd door djwice op 17 maart 2026 17:54]

[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.

[pegagus]

Ik heb hier al eens een discussie gevoed met een universitaire docent die zelf de wet ven Bernoullie (stromingsleer) niet begrijpt en dus gebruik maakt van AI (en het ook nog de normaalste zaak van de wereld vond). Als het zo doorgaat, heeft niemand meer technische inhoudelijke kennis, laat staan creavititeit en worden we geregeerd door AI. En ergens op de achtergrond een paar mensen die aan de knoppen van AI kunnen draaien en daadwerkelijk de dienst uitmaken.

[divvid]

doe dan wel even de correcte naam van onze Daniel en geef ook wat credits aan Euler...

briljante geesten overigens

[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.

[Heedless]

Plus dat je alsnog wil kijken of het überhaupt een zinvolle aanvulling is. Misschien maakt het niks stuk, maar voegt het ook niets toe.

[Reactie gewijzigd door Heedless op 16 maart 2026 11:14]

[bewerkers]

Voorbeeld van Wet van Goodhart. Unit tests zijn geen goede maatstaf als dat de enige maatstaf is. Je kunt prima buggy code maken die slaagt voor unit tests.

[grlk]

Unit tests zijn prima, unit test coverage moet niet de enige maatstaf zijn.

[Ed Vertijsment]

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

[AlRoke]

Om nog wat extremer te zijn dan de rest: unittests zijn voor complexe systemen haast waardeloos. Het is alsof je cement over je code giet; nuttig als je code perfect is... maar als die al perfect is, dan heb je ook geen tests nodig om toekomstige aanpassingen te testen. En in de praktijk betekenen bugfixes vaak genoeg dat je simpelweg de tests ook moet aanpassen, want een bugreport is vaak een indicatie van foute aannames, en niet (enkel) simpele programmeerfouten.

Niet dat er geen code is die geweldig is voor unittests en TDD, en (gedeeltelijke) integratietests zijn geweldig om veel regressies mee af te vangen... maar unittests zijn zeker geen hulpmiddel om goede en slechte contributies van mensen en LLM's te onderscheiden. Agentic LLM's zullen altijd alle tests laten slagen, for better or worse 😅.

[drmacfaulty]

Dit is zo waar en herken ik mij helemaal in. Unittests hebben een plaats, maar het is beperkt. Integratie testprocessen zijn daarentegen veel nuttiger en haast altijd een vereiste. Ik codeer voornamelijk tegen externe APIs en databases. Een integratietest kijkt wat verder dan een unittest doet. Waar een unittest een mock gebruikt, doet een integratietest een live test naar de externe systemen (die uiteraard ook in testomgevingen staan met bijpassende logging). Zie een unittest als op je eigen terrein testen, terwijl je met een integratietest ook aanbelt bij bijv. de buren. Dat is ook de reden dat bij het meeste dat ik doe de integratietests ook leidend zijn en unittests op een tweede plaats komen.

[rko4u]

Maar daarom had ik het ook over unit en keten tests(waar ik natuurlijk de integratietest onder zie vallen). Unit tests voor de documentatie van de classes, integratie /ketentests voor het geheel.

[rko4u]

Uw reactie laat maar weer zien dat veel mensen niet door hebben dat goede unit tests ook documentatie zijn. Als je goede unit tests maakt, kan je dus uit deze precies halen welke toevoegingen er zijn gemaakt.

[DaKluit]

Dat je er al niet meer van uit kan gaan dat de ontwikkelaar alles zelf test, werd al duidelijk met de XZ backdoor. Dat is soms helaas een tekortkoming van open source.

(Niet dat het beter is bij closed source btw)

[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.

[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.

[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

[2TheMaks]

AI gaat meer en meer code maken en mensen gaan steeds minder code zien.

AI kan daarom beter direct naar machinecode decoderen i.p.v. naar bijv. Python.

[himlims_]

Ik heb afgelopen periode een firefox extentie geschreven, voor 99% via Ai gemaakt. Het biedt mij de functionliteit die ik anders niet gevonden kreeg. Dit had mij weken aan code kloppen gekost, en dan nog devraag of resultaat er zou zijn (ben geen ontwikkelaar). Met AI is dat wel gelukt in enkele werkdagen https://addons.mozilla.org/addon/vertical-bookmark-dock/

@smellysock op github kun je een losse download voor chrome bemachtigen https://github.com/HollandHards/Docked-bookmark-list/

//edit; Dikke dank voor de tweakers met de 1 ster review; "WARNING: Author has no coding skills. This is written by AI."
erg hulpzaam, top!!

Als ik niets benoemd had over AI, had je dan nog steeds negatieve beoordeling achter gelaten? :X

staat zelfs in de readme; door Ai geschreven. Kan praktisch geen een opensource project noemen wat 'garrantie' geeft [..] heb de code door bevriend programmeur laten nakijken. Hij had zaken anders gedaan, maar functioneel werkt het best goed. Alles is lokaal, er zijn geen cookies, trackers, code injects etc.

[Reactie gewijzigd door himlims_ op 16 maart 2026 20:33]

[J_van_Ekris]

Ik heb afgelopen periode een firefox extentie geschreven, voor 99% via Ai gemaakt. Het biedt mij de functionliteit die ik anders niet gevonden kreeg. Dit had mij weken aan code kloppen gekost, en dan nog devraag of resultaat er zou zijn (ben geen ontwikkelaar).

En jij staat 100% in voor de kwaliteit van deze extentie? Je weet helemaal hie deze werkt? Jij garandeert mij dat deze extentie niet per ongeluk al mijn bankgegevens lekt, of de deur openzet naar hackers? Want dat is wat het werk van een ontwikkelaar is namelijk: nadenken over wat code wel én niet moet doen.

[himlims_]

Ik garandeer helemaal niets, anders dat er geen trscking plaats vind, code is via MIT license gepubliceerd. Zie niet in hoe dit anders is dan ieder ander open source project. Volgens mij biedt geen een project; garranties, dat is iets wat je mogelijk in kunt kopen; support en ondersteuning. Dat is hoe stallman jaren terug beschreven heeft op je een inkomen kunt bouwen met opensource.

[Reactie gewijzigd door himlims_ op 16 maart 2026 10:58]

[martijnvanegdom]

Dat jij opensource software hebt laten maken door een AI agent en het gepubliceerd hebt onder een MIT license maakt het nog geen opensource project.

In veel opensource project zijn een aantal core developers die code base bewaken, een groep van bijdragers en daar omheen vaak een community. Het bekendste voorbeeld hiervan is wel Linus Torvalds. Hij bewaakt Linux zo ongeveer met zijn leven. Als jij rommel maakt dan kom je code er niet in. En hij is heel fundamenteel erin. Of als je nog een extremer voorbeeld wil Theo de Raadt van OpenBSD en OpenSSH. OpenSSH is één van de belangrijkste libraries die er is, de toegangspoort tot miljoenen server. Nee dat project bied geen garantie, alleen een erg lang track-record.

Stel je voor: jouw extensie word populair. En 100.000en mensen gaan die gebruiken. En dan komt een nieuwe aardige ontwikkelaar die jou wilt helpen. Jij bent niet in staan - je hebt namelijk geen enkele coding skill - om zijn werk te beoordelen. Maar he het werkt functioneel! En een half-jaar later hebben we een nieuw incident: de himlims-leak.

[StCreed]

Je projecteert je eigen mening nogal hierop.

Zelf heb ik de laatste week ook 3 open source projecten gepubliceerd. Eentje was grotendeels van mij, de andere twee zijn grotendeels van de AI. Vermoedelijk zal je het lastig vinden om die te herkennen als ik het er niet bij zet.

Open Source betekent: de broncode is openbaar. En verder betekent het helemaal niks. De rest is projectie.

Als er een pull request op komt dan laat ik dat beoordelen door de AI. En gebruik is op eigen risico. Net zoals bij dat beruchte OpenSSH, waar fouten in zaten die miljarden aan schade hebben veroorzaakt omdat mensen denken dat Open Source meer is dan wat de naam zegt.

[martijnvanegdom]

Gefeliciteerd. Ja je hebt code online geslingerd. En die onder een open broncode licentie openbaar gemaakt.

Maar een project.. is dat echt? Een beetje code is echt niet een software project hoor. Misschien even wat bij lezen:

Wikipedia: Open-source software

"In his 1997 essay The Cathedral and the Bazaar, open-source influential contributor Eric S. Raymond suggests a model for developing OSS known as the bazaar model. Raymond likens the development of software by traditional methodologies to building a cathedral, with careful isolated work by individuals or small groups. He suggests that all software should be developed using the bazaar style, with differing agendas and approaches."

[StCreed]

"suggests"

Tsja. Dat is dus ook maar een suggestie. En beslist niet de mening van iedereen die OS publiceert. Overigens doe ik al jaren mee aan open source. Vaak duren reacties op PRs gewoon 6 maanden of meer. Dat is inderdaad in het tempo van de kathedraal :)

Overigens geeft zelfs bovenstaande helemaal geen criteria voor wanneer iets een project is, dus daar kan ik weinig mee. Ik werk sinds 1994 in projectverband aan software, dus wat mij betreft zijn dit mijn projecten.

[PtrO]

Hoe garandeer je dat dan ?

Of wordt dat overgelaten aan (imo fout begrepen) open-source methode waar toezichthouders maar zelf moeten zien hoe ze die robot zooi moeten zien te ontwarren of fouten en misbruik ?
Open-Source is niet alleen traparantie bewerkstelligen en het zichtbaar is maar ook dat er discussie over toetsbare intentie(s), opzet en gebruik (mogelijk) is.

Ik kom vaker in aanraking met andermans gegenereerde zooi en tegenwoodig besteed ik daar geen seconde meer aan om het te willen begrijpen. Lastig is soms wel om vast te stellen of het door een AI-bot is ge(ver)maakt. een paar treffende socio-vragen maken dingen dan snel duidelijker.

[divvid]

Noem een willekeurig complex stukje OSS waarin je dat kan garanderen? Bovendien, om bankgegevens te lekken is naast, niet veel meer dan een abonnenment bij Odido, óók nog een slordige gebruiker nodig die z'n password en 2fa credentials lekt.....maar dat doet niemand....toch?

Ik snap @himlims_ wel. zelf heb ik ook een stukje extensie geschreven voor mijn favo OSS project. Zonder enige kennis van C++ is het wel gelukt in korte tijd, iets dat mij persoonlijk dan weer motivatie geeft om verder te leren. Of ik er ooit een pull request van maak, denk het niet, maar de ontwikkelaars op het forum van de tool vonden het wél een tof idee en kijken nu naar een "echte" implementatie op basis van mijn "AI slop" code.

Dat is denk ik ook de enige manier: nooit pull requests open zetten voor een "persoon" zonder een voorafgaande discussie. Geen forum topic, geen discussie, dan ook geen pull request rechten.

[Reactie gewijzigd door divvid op 16 maart 2026 12:52]

[SiErRa]

Mooi voorbeeld, maar hier heeft dus geen maintainer naar hoeven kijken. Dus dit is 1-op1 AI.
Jij hebt de functionaliteit die je zocht, en ook nog eens gedeeld voor anderen.

Als ik nu naar de pagina kijk zie ik een hele nette gedocumenteerde extension. Dat ziet er dus wel professioneel uit, en als eindgebruiker vertrouw je erop dat het door een professional gemaakt is.

Maar het is AI en bij AI staat altijd bij dat je de output moet controleren want het kan fout zijn.
Je geeft al aan geen ontwikkelaar te zijn, hoe weet je nu of de output (de code) wel goed is?

Je extension werkt, dus op functioneel vlak kan je wel beoordeling of de output goed is.
Maar het gaat vooral mis bij de non-functionals, met als belangrijk punt security. Vraag op zijn minst aan de AI of hij vanuit een security oogpunt wil kijken of er kwetsbaarheden zijn en wat typische aanvalsvectoren zijn bij Firefox extensies en of die hier van toepassing zijn.

[Heedless]

Claude heeft gewoon een /securiy command, dus zolang je die even runt is er niets aan de hand

[h3x4d3c1m4l]

Ik heb de comment voor je gereport. Hopelijk doen ze er iets mee. Ik vind het werkelijk schandalig dat een Tweakers zoiets comment eerlijk gezegd, in plaats van naar de inhoud te kijken van de addon.

[StCreed]

Kinnesinne en gatekeeping. Het is soms net een sekte in de open source "community".

[smellysock]

Cool man! Ikzelf kan niet coden en gebruik af en toe chatgpt om wat software te maken op basis van python. Ik vind het knap dat je zo'n extensie hebt kunnen maken ook al ben je geen coder.

Ik zie veel mensen altijd maar afgeven op AI en wat er allemaal zo slecht is aan de code die het genereert en waarom. Ik kijk er heel anders tegenaan. Ik zou nooit een GUI kunnen maken voor een stukje software in windows zonder hulp van een AI. Nu ik dat wel heb gedaan heb ik weer iets nieuws gedaan en geleerd.

Wat mensen ook vaak vergeten is dat als je geen basis kennis hebt van wat dan ook, je ook niet ver komt met een AI zoals chatgpt. Ik wilde graag een paar batch files laten maken om bepaalde dingen makkelijker te maken voor mijn werk en dat is prima gelukt na een beetje back en forth met de chatbot. Maar daarvoor moet je natuurlijk wel weten wat een batch file is. Ik zie mijn interacties met chatgpt als een leerproces en ik ben heel kritisch over wat de chatbot mij verteld.

Ik denk dat AI (chatbots) echt een katalysator kunnen zijn voor mensen die niet bang zijn om ergens in te duiken en te leren.

oh, en ik gebruik geen firefox dus heb je extensie helaas niet kunnen proberen :P

[FreezeXJ]

Dan gebruik je AI ook nuttig, door a. het wel te willen snappen, en b. je eigen code zelf te testen, en c. het niet als productiecode voor anderen te gebruiken. Ik kan met een pot verf en een kwast ook prima iets in de verf zetten, maar noem mezelf daarom nog geen schilder. Dan durf je namelijk ook garantie te geven. Precies dat laatste is ook wat een programmeur doet: zorgen dat het voor anderen werkt.
Als mijn hobby-projectje een fout geeft heb ik daar zelf last van, en misschien een paar vrienden die het ook gebruiken. Gaat mijn werk mis, dan heeft dat (forse) gevolgen voor (betalende) klanten. Daarom gebruik ik voor werk maar spaarzaam AI, en voor hobby zie ik er minder problemen in.

Als jij nu op basis van je AI-spoedcursus 'coden' vrolijk verder gaat met scripts (laten) bakken, prima. Als je op basis daarvan een baan als developer zoekt, ga je van een koude kermis thuiskomen.

[StCreed]

"Als je op basis daarvan een baan als developer zoekt, ga je van een koude kermis thuiskomen."

Ja dat klopt, die banen gaan zwaar in de problemen komen. Want de huidige stand van zaken is dat ik ongeveer een factor 50 sneller code kan produceren. En die kan ik ook 50x sneller laten fuzzen, unittesten, beoordelen door specialistische security AI, en nog een keer een week laten testen door 10 random "gebruikers" met Playwright en de instructie de zaak te breken. Allemaal voor minder geld en veel sneller dan jij dat kan met het handje.

Als informaticus (en als iemand die vanaf zijn twaalfde jaar al programmeert - begonnen op de Philips P2000 met 16KB cartridge) betreur ik het een beetje. Als business architect en modelleur besef ik echter dat ik dat als hobby zal houden en dat mijn werk anders gaat worden. En als ik zie dat de AI bugs uit mijn software haalt die ik in 2 dagen tijd niet vond, en hij in 2 minuten wel - plus nog wat andere - dan begrijp ik dat ik los moet laten.

[2TheMaks]

... dat ik ongeveer een factor 50 sneller code kan produceren.
[...]
En als ik zie dat de AI bugs uit mijn software haalt die ik in 2 dagen tijd niet vond ...

Mensen die om te beginnen niet al te goed zijn in hun vak kunnen i.d.d. makkelijk door GenAI vervangen worden.

[winkbrace]

50x sneller... Kun je een onderzoek overleggen dat dit bewijst? Ik hoor dit vaak (doorgaans minder overdreven, gewoon 2x sneller) en mensen kijken hierbij alleen naar het genereren van de code en niet naar de totale doorlooptijd van een project. 80% van het werk van een developer is code onderhouden. Als je dan niet weet hoe het werkt, weet je ook niet waar je moet zijn bij bugs of veranderingen.

De AI discussie begint al religieuze randjes te krijgen waarbij mensen niet naar elkaars argumenten luisteren. Ervaren devs die zich zorgen maken zijn er niet op uit om jou dwars te zitten.

[brama]

Helemaal eens met nuttig AI gebruik vs 'vibe coder'. Als je als ontwikkelaar géén ervaring hebt met AI, ga je binnenkort ook moeilijk aan een baan komen. Maar een vibe coder die geen flauw idee heeft van wat die doet, daar zit ik ook absoluut niet op te wachten.

Ik denk dat we nu in een overgangsfase zitten waarin we overdonderd worden door de megasnelle opkomst van AI. Als je mij vijf jaar geleden zou vertellen wat de nieuwste AI coding modellen nu al kunnen, dan had ik je snoeihard weggelachen.

[Henk1827]

Dit soort verhalen hoor je constant. Leuk als hobbyproject, maar ik blijf er ver uit de buurt.

[StCreed]

Ja, drie maanden geleden had je nog een beetje gelijk. Deze maand is dat echter voorbij met de nieuwe Codex, Claude en chatgpt. En wat ik zie aankomen en al in de pipeline zit gaat nog veel effectiever worden: multi-agent graph-based swarms, waarbij de leidende AI de andere AI's indeelt op basis van hun rol, kosten, resultaten in het verleden en attributen. Dat zit al ingebakken in een AI als ChatGPT, maar wordt nog weer goedkoper en effectiever dan wat we nu al zien.

Mijn beste vriend was ook niet overtuigd, want "hij kende de AI al" - ja, van vorig jaar. Twee weken geleden liet ik hem de stand van zaken zien zoals het nu is. De dag daarna heeft hij een 3D spacegame gebouwd waarin hij kon vliegen, docken bij ruimtestations, landen op planeten en handelen. In 4 uur tijd.

Als je dat afdoet als hobbyproject, dan ben je eigenlijk een Bill Gates aan het doen.

[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.

[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

[pietvelleman]

Helemaal mee eens...

We 'pip installen' vanalles en npm'en ons helemaal suf... Maar velen durven toch te beweren dat je alle code moet kennen. Heel grappig...

Toen C in de jaren '70 en '80 populair werd, was de weerstand van de puristen ook enorm.
En toen C++ opkwam, stonden de C-puristen juist op de barricades.

FastForward naar 2026...
"Piep piep.. AI is gemeen! En slecht... Boe! AI kan niks... is slechts een LLM en tokenvoorspeller...bla die bla". Ach er is niets nieuws onder de zon. Verandering is eng.. Voor velen...

AI zal veel veranderen. Wat je zegt... Wellicht komt er een standaard taal waar AI goed mee overweg kan...
En de programmeertaal-ontwikkelaars zullen geen documentatie schrijven voor mensen, maar voor AI's.
Er zal een RUST-handboek voor AI geschreven worden... En die zal er anders uitzien dan dat je voor mensen schrijft! Dito voor Python...

Ook interessant voor opensource projecten: Heb je straks wel grote communities nodig om de software up to date te houden? Kun je straks gewoon met 2 a 3 programmeurs hetzelfde bereiken als nu met 20 maintainers en tientallen (honderden!) contributors?

Een project als PHPMYADMIN heeft zo'n 5-10 maintainers en er zijn in de loop der jaren 1000 unieke contributors geweest. Hoe lang zou het tegenwoordig duren als je met AI een dergelijk project in elkaar vibe-code? En hoe zal dat over 5 jaar zijn?

Wat mij betreft zijn dat allemaal meer interessante vragen dan 'piep piep ik zie zoveel slechte ai code.'
Ik snap het probleem. Maar wat je zegt... Het heden en de toekomst is een gegeven, daar moeten we mee dealen... En de rest is geklaag van mensen die niet van AI muziek houden (om @Mathijs Kok hieronder te quoten).

[2TheMaks]

We 'pip installen' vanalles en npm'en ons helemaal suf... Maar velen durven toch te beweren dat je alle code moet kennen. Heel grappig...

Alle code hoeft niet door één persoon gekend te worden, maar alle code moet wel bekend zijn. Vandaar dat OSS een project is. Achter elk artifact dat je 'pipt' of 'npmt' zit een project daarin maintainers en developers die inderdaad alle code kennen die uiteindelijk resulteert in dat artifact.

[pietvelleman]

Sorry... maar dat is hopeloos naief van je.

Lees bijv even dit artikel:
review: Wat zijn npm-packages en waarom richten hackers zich erop?

[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?

[nandervv]

Nee, je snapt het niet. De eerste bijdragen die je doet zijn netto negatief voor het project. Het jou moeten leren hoe je aan de standaarden daar voldoet, het begeleiden door het proces, het vetten van je werk, dat kost allemaal tijd. Projecten zoeken vaak niet naar incidentele bijdragen die een stukje fixen, ze zoeken naar structurele hulp. De AI-gegenereerde dingen leveren dat niet op.

En sure, het kan zo zijn dat jij zoekt naar een feature, die mist in een bepaald project, maar dan ben je niet aan het bijdragen, dan ben je het voor jezelf aan het verbeteren. Is prima, maar doe dan niet alsof je zo'n goeie buur bent.

In de metafoor van het schuurtje van de buurman is dit alsof jij zonder overleg een half afgerond schuurtje op z'n oprit kwakt. Een schuurtje dat in de verkeerde kleuren geschilderd is, etc. etc.

Software maken is team-werk, en samenspel. Als je daarin niet wilt meedoen bij een project, blijf d'r dan gewoon bij weg.

[Mathijs Kok]

Projecten zoeken vaak niet naar incidentele bijdragen die een stukje fixen, ze zoeken naar structurele hulp.

En zou maak je plannen en geen bruikbare code. Ik zou willen dat veel projecten wat meer zouden doen aan het fixen van issues dan aan het werken aan een nieuw 'framework' waar iedereen overheen wil plassen.

Niet lang geleden heb ik enkele van mijn coders gevraagd om wat lang openstaande problemen in software die we gebruiken op te lossen. Na een week was alles gedaan, bugs opgelost. Wij blij. Maar de houding van de maintainers waren niet erg blij. Wie we waren, waarom we het deden, ze hadden nog nooit van ons gehoord. Ik schreef dat er 5 bugs waren die nu opgelost zijn, met documentatie, en dat ik niet goed begreep waarom de rest zoveel belang had (zeer vriendelijk hoor, geen onvertogen woord). Graag of niet. Het werd niet en de 5 bugs zitten er nog steeds in.

Ik snap de problematiek wel, maar het klinkt erg als de mensen die roepen dat ze AI muziek haten. Ik ben pragmatisch. Het maakt me absoluut niets uit wie de muziek maakt; het heeft geen enkele invloed op mijn waardering. Het product is het enige wat ertoe doet. Het proces mag nooit een doel zijn, slechts een middel. Bij veel OS-softwareprojecten lijkt dat vergeten te zijn. Hele zachtjes fluister ik dat je je ego bij de deur moet inleveren voor je meedoet.

[Sissors]

En sure, het kan zo zijn dat jij zoekt naar een feature, die mist in een bepaald project, maar dan ben je niet aan het bijdragen, dan ben je het voor jezelf aan het verbeteren.

Waarom ben je dan niet aan het bijdragen? Dat het voor jou een winst is, betekend toch niet dat het niet voor andere ook winst is? Juist zulk soort bijdragen lijkt mij een belangrijk gedeelte waar open source het van moet hebben.

En natuurlijk snap ik dat een lange termijn ondersteuner meer oplevert dan iemand die incidenteel wat doet. Maar tegelijk als je op zulke manier aan gatekeeping gaat doen moet je ook niet vreemd opkijken dat die incidentele committer nooit een lange termijn steun wordt, immers de incidentele commits zijn schijnbaar niet gewenst.

Het is jaren geleden voor mij dat ik aan een opensource project heb bijgedragen (ben ook geen software engineer, dus meer uit hobby). En ja dat was incidenteel, met enige regelmaat. Ik had nul behoefte om allerlei semi-verplichtingen te hebben door structureel ermee bezig te zijn, ook al was ik vanuit hobby best veel ermee bezig. Ik durf wel te stellen dat mijn bijdragen aan de source code nuttig waren. En hell ik was behoorlijk bekend met de code omdat ik het veel vanuit mijn hobby gebruikte. Maar als ik dan door allerlei hoepels had moeten springen om die code te verbeteren, dan was ik denk ik erg snel afgehaakt.

En nogmaals, ik snap prima het probleem wat je krijgt doordat je overspoelt wordt met twijfelachtige AI-slop pullrequests. Maar dat is juist wat het lastig maakt, je wil geen hoge gatekeeping drempels opwerpen (iig de meeste niet verwacht ik), maar je moet wel iets doen om de slechte pull requests te filteren op een manier die je zelf niet veel tijd kost. Alleen ik denk niet dat extra documenten vragen de oplossing is: Juist LLMs kunnen die probleemloos voor je erbij schrijven. Je voegt eisen toe die moeilijk voor mensen te doen zijn en makkelijk voor LLMs.

[nandervv]

Je draagt niet bij, omdat bij dit soort toevoegingen de hoeveelheid review- en coachwerk eigenlijk altijd groter is dan de bijdrage die je doet. Dat je bruto werk oplevert betekent niet dat je ook netto werk oplevert.

Als je direct gaat denken in het omzeilen van de hoepels die neergelegd worden, blijf dan gewoon bij dat project weg. Je hóéft niet bij te dragen, en de voorwaarden voor bijdragen liggen vólledig bij de maintainers van dat project.
Sta je niet achter het proces van een project, maak dan een fork en ga zelf ermee bezig.

[Sissors]

Je mist mijn punt aan het einde:

Als je extra eisen gaat stellen met als doel AI-slop pull requests te voorkomen, en die extra eisen zijn moeilijk voor mensen om aan te voldoen (het kost iig tijd en moeite), en ze zijn makkelijk voor een LLM om aan te voldoen, op welke manier voorkom je dan AI-slop pull requests?

[P_Tingen]

Je draagt mogelijk bij, maar mogelijk ook niet. Ik ben zelf maintainer van een tool voor Progress ontwikkelaars waarmee je gemakkelijk de inhoud van een Progress database kan bekijken. Ik heb een redelijk duidelijk beeld van dingen die ik wel en die ik niet in de tool wil hebben. Een van de zaken die ik nog wel eens krijg het verzoek om joins in te bouwen, maar dat staat zó haaks op het doel van de tool dat ik dat steeds heb geweigerd. Als nu iemand bij zichzelf denkt dat joins een goede uitbreiding zouden zijn, dan heb ik daar per saldo alleen maar meer werk aan dan dat het me wat oplevert. En de bijdrager uiteindelijk ook, want die steekt moeite in een pull request dat geweigerd wordt.

Je kan niet zomaar alles implementeren wat ergens iemand wil. Dan eindig je met een tool die alles kan maar niks echt goed en waar je als eindgebruiker in verzuipt omdat er geen structuur in zit

[stereohead]

Kort gezegt: Nee een open source project heeft niets aan jou stukkie code wat je in een avondje compilerend hebt gekregen (ongeacht of je daar een llm voor gebruik te hebt).

Want jou code zal voor jou best werken, en doen wat jij bedacht hebt. Maar past het bij de visie van het project? En heb je je aan de architectuur gehouden die het project toepast? Is de functie die je toevoegt überhaupt gewenst? Wie gaat die code in de toekomst onderhouden?

En ja dan zul je je dus moeten verdiepen, communiceren, etc, en ja dat kost tijd.

Software != code

[Sissors]

Maar geen van jouw punten los je op door extra documenten te gaan eisen! En wie zegt dat het in een 'avondje' gedaan is? Plus dat 'communiceren' kost dus helemaal geen tijd, als je gewoon een LLM het voor je laat doen. Je voegt extra stappen toe die veel tijd voor een mens kosten en weinig voor een LLM.

Voor mezelf, ik heb vroeger veel gebruik gemaakt van een opensource project. Dus ik was behoorlijk bekend met de werking ervan. Ik heb wat pull requests gedaan (dingen als overhead van interrupt handler met >10x verminderd). Die zijn geaccepteerd. Als ik daarvoor essays had moeten opstellen hoe ik nou reflecteer op de hele handel, had ik die nooit gedaan.

En zoals ik ook op een ander reageerde: Ik snap dat een long term committer meer toevoegt dan iemand die incidenteel wat doet waar hij tegenaan loopt. Maar als je op die manier gaat gatekeepen, moet je ook niet vreemd opkijken dat je daar minder van gaat krijgen.

[nandervv]

Ja, en zodra je dat doorhebt ontneem je iemand dus gewoon schrijfrechten van je project. De maintainer van het project bepaalt wie er mee mag doen, en onder welke voorwaarden. Als je daar niet in mee wilt gaan, blijf dan gewoon weg bij het project.

Op een bepaald moment heb je liever minder bijdragen van mensen die het serieus nemen, dan meer van mensen die het puur doen voor een hoger tellertje op github, of om hun eigen persoonlijke irritatie te fixen

[Sissors]

Als het zo makkelijk was, dan bestond dit hele probleem dus niet. Dan had je niet de vraag hoe je AI slop beperkt, want je haalt gewoon hun schrijfrechten wel en je bepaald wie er wel mee mag doen! Maar blijkbaar is het toch niet zo eenvoudig.

[StCreed]

Ik heb laatst 4 bugs opgelost in een python bibliotheek: 3x off by one error, 1x off by 42 (ja, typisch getal )

Het zal mij jeuken of de maintainer mijn pull request accepteert, ik heb hem geforked en daar werk ik op. En als die bugs "helemaal bij zijn visie passen" doet hij lekker zijn best maar.

Zou ik de bibliotheek compleet verbouwen (wat ik 3 jaar geleden heb gedaan) dan doe ik dat in overleg - vooraf. Via een issue die ik raise, en waar ik na discussie indien wat we hebben besproken. Ook als ik dat met AI zou doen, lijkt dat mij de weg.

Overigens kunnen open source pakketten hier veel aan doen door een "INTENT.md" document o.i.d. te maken waar de bedoeling van het project in staat. Dat zou ook veel mensen helpen. Zelf maak ik die ook voor mijn open source spul.

[PtrO]

Dan ben je dus niet aan het bijdragen in het "team" maar je eigen code op basis van andermans werk aan het vermaken. Prima natuurlijk maar het gaat imo wat voorbij aan de intentie die open-source vooral is.

[StCreed]

Ik vind persoonlijk dat programmeurs de hardware waar ze op draaien moeten kennen tot op registerniveau, maar dat standpunt is ook al een tijd geleden achter ons gelaten. En mensen die parallel programmeren en denken dat ze dat kunnen in C++... die zouden al lang werkloos zijn als het aan mij lag. De paradigma's van Tony Hoare (en daarmee Occam als enige taal die ze goed implementeert) zijn wat mij betreft de enige werkende paradigma's, maar ja, wie kent ze überhaupt?

Heel veel programmeurs zijn sowieso slecht opgeleid en begrijpen niet veel van informatica. Als AI dat nu ook nog niet doet hebben we niet veel verloren, maar bij AI is het lerend vermogen wel gigantisch veel sterker en sneller.

[Sando]

De oplossing zit volgens mij niet in AI verbieden of PR's dichtgooien, maar in het herstellen van dat leerproces.

Maar dat lost het probleem van waardevolle maintainers niet op, want die weten niet wie er iets heeft geleerd.

Ik ben zelf voor een reputatiesysteem. Alle gebruikers krijgen een score gebaseerd op hoeveel PRs geaccepteerd of afgewezen zijn. Misschien is het ook handig als ze een rating van een maintainer kunnen krijgen.

Dan kan een maintainer van een nieuw project heel makkelijk in schatten wat de kwaliteit van een onbekende bijdrager is. Je zou dit ook kunnen automatiseren; alleen PRs openen als je minstens x PRs hebt gedaan met een score van y of hoger op repositories met minstens z sterren.

[Groningerkoek]

In essentie een goed systeem, maar hoe lang zou het duren voordat AI accounts aanmaakt, projecten plaatst, en andere AI's downloaden, beoordelen en contribueren en hierdoor een goede reputatie krijgen. Je zou een hele "schaduweconomie" krijgen van alleen maar AI's in een circlejerk. En uiteindelijk denkt de AI dat de reputatie goed genoeg is om PR voor andere projecten gegaan indienen.

Het probleem is dat systemen die we vroeger hanteerden om menselijke gebruikers in toom te houden en bots herkennen veelal niet werken om AI te beteugelen.

[Rekcor]

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.

Heb tijdens mijn Ph.D. redelijk wat onderwijskunde moeten verstouwen, maar bovenstaande klinkt mij niet in de oren als een efficient leerproces. Het doet me sterk denken aan inquiry based learning:

Inquiry learning places an increased emphasis on learners discovering information for themselves rather than having the information explicitly presented to them.

Bron: https://www.cis.org.au/publication/why-inquiry-based-approaches-harm-students-learning/

Overigens: een LLM gebruiken op de manier waarom veel novices het kennelijk doen, is ook heel schadelijk voor het leerproces.

Puur vanuit het leerproces bezien, wil je waarschijnlijk een constructie waarbij de beginnende programmeur/-euze veel korte iteraties doorloopt met feedback van een dedicated LLM-agent. Deze agent moet dan niet de antwoorden geven, maar goed uitleggen wat de fouten zijn en waarom ze fout zijn, en evt. een globale oplossingsrichting suggereren. De menselijke mentor komt dan wat later in het proces aan bod: die pakt (idealiter) de diepere problemen aan in de code.

[Balance]

Het is een interessant punt, en iets waar we het eigenlijk zeker meer over moeten hebben. We schrijven wel een heel hoop documentatie, handleidingen en tutorials, zowel voor de gebruik van onze software als voor het ontwikkelen daarvan.

Je hebt gelijk dat het "worstelen" op zichzelf geen efficiënt leerproces is. Maar ons primaire doel is ook niet het opleiden van softwareontwikkelaars, het is het bouwen van krachtige, flexibele en gebruiksvriendelijke modelleersoftware die voor iedereen vrij aan te passen is.

Bij GSoC verschuift dat tijdelijk: daar investeren we bewust in het opleiden van contributors, in de hoop dat ze blijven plakken en uiteindelijk zelfstandig bijdragen. In die context is het "leerproces" dat ik beschrijf geen onderwijsmethode die we ontworpen hebben, maar een bijeffect van hoe opensource werkt: je leert door bij te dragen aan een echt project met echte reviews. In dat opzich is het een ambacht, je loopt mee, met één-op-één mentoring. En dat is toch een vrij bewezen concept.

Het probleem zit hem aan de voorkant. Als je ~120 geïnteresseerden hebben die gemiddeld 2 PRs openen, dan heb je het over 250 PRs in een paar weken tijd. Ons hele maintainersteam opend er over een jaar tijd misschien zoveel. Dus hoe filter je daar doorheen, als iedereen maar bergen gegenereerde code, PR beschrijvingen en zelfs reacties blijven sturen?

Zodra we de selectie eenmaal hebben gemaakt en een-op-een kunnen gaan mentoren werkt het systeem prima.

[Earthfinder]

Ik heb hier reeds pogingen toe gedaan. Het is voor een LLM echter bijzonder lastig om consistente feedback te geven op semantische keuzes. Regelmatig zijn er meerdere wegen die naar Rome leiden, maar de ene weg is semantisch beter dan de ander. Tot op heden kom ik er nog niet echt goed uit om LLM feedback hierop consistent te laten zijn.

Vanuit OOP bijvoorbeeld, is het voor een LLM haast niet te doen om aan te geven waarom methode x beter in class A gedefinieerd kan wordend in class B. Dan is er nog de interne logica in een methode. Een LLM lijkt moeilijk in staat om onnodige complexiteit te duiden. Laat staan daar feedback op te geven.

Wat ik bij de studenten/stagiairs constateer, die ik onder mijn hoede krijg, als docent en als begeleider, is dat er een deel is dat intrinsiek gemotiveerd is om softwareontwikkelaar te worden en het echt willen leren. Dan is er deel die het wel wil leren, maar nog wat zoekende zijn. En er is een deel dat vooral bezig is om “vinkjes” te halen. Let wel, het kan best zijn dat die laatste groep over een jaar ineens heel anders tegen de zaken aan gaan kijken. Het gebruik van LLM’s lijkt die verschillen eigenlijk alleen maar meer uit te vergroten.

De eerste groep zet LLM in om een beter begrip te krijgen. De 2e groep, probeert het zelf, maar als t een beetje moeilijk wordt -> LLM… leerrendement stokt. De Laatste groep lijkt vooral LLM first and only. Ze zijn alleen maar bezig met prompten. Ook feedback gaat de prompt in en ai genereert de oplossing die zo goed als een-op-een over wordt genomen.

[WillySis]

AI wordt binnen de wereld van programmeurs inmiddels heel veel gebruikt en maakt het werk ook een stuk gemakkelijker. Gemakkelijke zaken lost AI in seconden op, zonder dat je daar een hele dag (of meer) aan moet besteden.

AI verbieden is dus het paard achter de wagen spannen. Je mag wel van programmeurs verwachten dat ze de gegenereerde code aanpassen zodat die gewoon netjes is en daar van commentaar wordt voorzien.

[SiErRa]

Dan doe je de aanname dat degene die de AI gebruikt ook echt een programmeur is, die die gegenereerde code begrijpt. Dat is dus precies wat het probleem is. Er komt een berg code van iemand binnen met prima intenties, maar waar je dus niet van weet of de maker begrijpt wat er is gegenereerd. Voorheen kon iemand die het niet begreep die code ook niet zomaar produceren en nu wel.

Het grappige is juist dat AI vaak herkenbaar is omdat het zoveel commentaar gebruikt in code.

[StCreed]

Dan doe je de aanname dat degene die de AI gebruikt ook echt een programmeur is, die die gegenereerde code begrijpt. Dat is dus precies wat het probleem is. Er komt een berg code van iemand binnen met prima intenties, maar waar je dus niet van weet of de maker begrijpt wat er is gegenereerd. Voorheen kon iemand die het niet begreep die code ook niet zomaar produceren en nu wel.

Het grappige is juist dat AI vaak herkenbaar is omdat het zoveel commentaar gebruikt in code.

Grappig, want ik heb net 1 gigabyte aan code geproduceerd middels AI en die is nauwelijks voorzien van commentaar. Ik moet de AI echt helpen om netjes alles te documenteren. Dus als dat jouw herkenbaarheidscriterium is, dan ga je het zwaar krijgen.

[Henk Poley]

Een amusante soort (halve-)oplossing die ik gezien heb, de coding tool vragen om een quiz te maken over de code wijzigingen, die correct door de eindgebruiker beantwoord moet worden, voordat er gecommit wordt (de PR wordt doorgevoerd, etc.).

Blijft natuurlijk de vraag of 'de beginner' daar dan niet ook weer ChatGPT voor gebruikt.

Dit was dan ook meer geopperd door een ontwikkelaar zelf, hoe je de controle blijft houden over wat voor rommel je commit.

[Reactie gewijzigd door Henk Poley op 16 maart 2026 10:49]

[locke960]

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.

Je probeert gedrag te veranderen door mensen te vragen gedrag te veranderen. Dat werkt misschien voor mensen die met goede bedoelingen begonnen zijn EN zich niet realiseerden dat dit een probleem is. Die combinatie lijkt me een vrij kleine groep te zijn.

De groep die dit om alle verkeerde redenen doet gaat niet onder de indruk zijn vrees ik.

Ik hoop dat het meevalt, maar ik vrees dat het, in ieder geval eerst, alleen nog maar erger wordt.

[Reactie gewijzigd door locke960 op 16 maart 2026 13:01]

[Joppiesaus2]

Kan het zijn dat dit echt heel tijdelijk is? En dat we over wat langere periode (lees 10+ jaar ofzo) niets meer hoeven te schrijven of reviewen door mensen omdat AI gewoon superieur is? En als dat zo is, wat is de rol nog van abstracte programmeertalen...wellicht dat AI een efficiëntere taal heeft voor eigen soortgenoten of zelfs direct naar machine code gaat?

Ik kan me niet voorstellen dat dit niet gebeurd gezien auto's ook veiliger rijden nu dan mensen en video's er beter uit zien dan big budget blockbuster scenes.

Kwestie van (nog een beetje) tijd?

[drvinnie]

Dit is precies hoe het in het onderwijs ook gaat. En feedback die rechtstreeks het taalmodel in gaat: er wordt nauwelijks nog geleerd. Heel frustrerend dat mensen dan nog blijven jubelen hoe goed AI alles toch doet.

[Siaon]

Je ziet het ook in andere sectoren: de tijd die nodig is om van beginners experts te maken wordt overgeslagen met ai tools.

Em beginners worden dus geen experts...

[GigaHenk]

Overigens kun je dit probleem oplossen met Bitcoin/Lightning. Doordat emails etc bijna geen geld kosten om te versturen, worden het er gauw te veel.

Indien een bijdrage aan software zeg maar €5,-/€10,- kost dan doe je dat niet zo snel. Is het serieuze bijdrage, dan krijg je gelijk je sats/BTC terug gestort. Daarnaast kun je dan met een verdeelsleutel ook mensen makkelijker belonen met eventuele donering. Want elke donatie wordt automatisch verdeelt en op de betreffende BTC rekeningen gestort tegen parktisch nul kosten

Bij podcasting wordt dit al gebruikt bij V4V model dat geintergreerd is in Podcasting 2.0 software (Fountain, Breez, Podverse)

Misschien ook tijd voor Github 2.0

[Earthfinder]

Ik ben docent softwareontwikkeling en we runnen een leerbedrijf, dat onderwijssoftware maakt. Hoe ik het aanpak is dat code moet voldoen aan kwaliteitsattributen. Daarbij staan leesbaarheid, onderhoudbaarheid en aanpasbaarheid bovenaan.

Ik heb zelf geprobeerd om AI hiervoor in te zetten, dat lukt tot nu toe niet helemaal. Ik heb een script ontwikkeld wat code controleert op een reeks “standaard” aanpakken van AI. Die worden als feedback genoteerd voor de stagiair/student (mbo-4). Daarnaast lees ik zelf de code na, met name vanuit semantisch perspectief. AI verbieden gaat, niet. Maar op deze manier train je ze wel wat goede code is. Als ze dat willen oplossen met AI… tja je kunt ze moeilijk stoppen. Wellicht verandert het vak van softwareontwikkelaar…. De codeklopper zal worden vervangen door AI, de systeemengineers/-architecten zullen blijven bestaan.

Binnen het leerbedrijf moet ik eerlijk toegeven, dat mbv AI ook mijn productie een enorme boost heeft gekregen. Ik heb dashboards en tools kunnen inzetten waarvoor ik anders geen tijd zou hebben gehad. En die mbv ai toch configureerbaar voor mij werden binnen behapbare tijd.

[Florimon]

Wow de entitlement en afgunst druipt ervanaf. Het is niet alsof je een recht hebt op gratis afname van de creatieve output van anderen. Waar denk je trouwens dat al die AI gegenereerde content z'n oorsprong vindt? Of wat er gebeurt als de creatieve 'elite' het wel mooi vindt en besluit niks meer te produceren (not likely, het zit nu eenmaal in hun bloed), of (more likely) besluit dat alles achter slot en grendel gaat en AI scrapers nergens meer bij mogen om "trainingsdata" te vergaren, en daar met rechtszaken veel stricter de hand in gaan houden? Dan droogt de vijver waaruit de AI's kunnen vissen op en kunnen ze alleen nog maar elkaar of oude content na-apen.

[RayNbow]

Het is triest dat AI, waarvoor nul bloed is verspild

Misschien geen bloed, maar hoe denk je dat al die trainingsets zijn opgeschoond? Met moderne slavernij. Onderbetaalde mensen die de meest gruwelijke dingen onder ogen kregen.

[apulmoes]

De definitie van een "pull request" (PR) rammelt een beetje.

— Ik maak de aanname, o.a. vanwege de referenties naar projecten op GitHub dat jullie pullrequests op Git repositories (repos) bedoelen met 'standaard-instellingen' voor PRs.

"Een pullrequest is een verzoek van een programmeur om de wijzigingen … op te nemen in de 'hoofdcode' van een project."

Een PR kan als target branch iedere branch op de repository zijn — niet enkel de 'hoofdcode'. Bijvoorbeeld: sommige teams werken met feature branches waar meerdere PRs op worden gemaakt, totdat die afgeronde feature uiteindelijk via een PR naar de hoofdbranch wordt gepulled.

"… iemand … met zogenoemde pushaccess kijkt vervolgens de gemaakte wijzigingen na en voegt ze na goedkeuring van de code samen met het project."

Iedereen kan meekijken met PRs en feedback geven, maar iemand met merge rights kan de wijzigingen "pullen" (hint: pull request) vanuit de andere branch, nogmaals ongeacht of die leeft binnen dezelfde repo of een fork (kopie) vd target repo.

De wijzigingen worden vervolgens 'samen gevoegd' (gemerged). Daar zijn tal van zogenaamde "merge strategies" voor. (zie bijv. https://www.geeksforgeeks.org/git/merge-strategies-in-git/ )

Verder een interessant artikel! 🫶🏻

[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.

[BCC]

Inderdaad - je mag inderdaad best een AI je PR laten genereren, maar je bent als developer persoonlijk verantwoordelijk voor de kwaliteit.

[nandervv]

Ja, maar willekeurige contributors die met een LLM een bijdrage gegenereerd hebben zonder de context te snappen kunnen die verantwoordelijkheid niet dragen.

Uiteindelijk zijn de maintainers verantwoordelijk voor het eindresultaat. En die zien zich dus genoodzaakt om duidelijke regels te schrijven over wat wel en niet mag met AI.

[bwerg]

En zo komen we terug op de vraag "maar waarom zou het erg zijn om AI gegenereerde code te weigeren?". Als een contributor geen zak snapte van een project had die voorheen geen mogelijkheid om een goed pull request te maken, hooguit een pull request die zo slecht was dat die binnen 1 minuut werd afgeschoten. Nu kan Jan en alleman een hele lading pull requests genereren die veel lastiger als zodanig te herkennen zijn, en die dus veel meer tijd kosten.

En die zien zich dus genoodzaakt om duidelijke regels te schrijven over wat wel en niet mag met AI.

En hoe ga je forceren dat een gebruiker zich daaraan houdt?

Dat is het probleem: je kan regels opstellen wat je wil, maar uiteindelijk moet je als maintainer alsnog tijd steken in het wegfilteren van troep die ingeschoten wordt. Er zijn genoeg mensen die lak hebben aan andermans tijd, en die niet transparant zijn over of en hoe ze AI gebruiken.

[Reactie gewijzigd door bwerg op 16 maart 2026 15:19]

[nandervv]

Wat mij betreft heeft github als platform hier werk te doen, om ervoor te zorgen dat de kwaliteit van het werk van mensen kan worden gemeten.

Met misschien een soort slop-me-niet-register voor opensource projecten, waar mensen op grotere schaal timeouts kunnen krijgen als ze dat op andere projecten al doen.

Of als alternatief alternatief: een systeem waarbij een PR gewoonweg een paar euro kost om in te sturen (die je terug krijgt als hij goedgekeurd wordt, en anders gaat het naar een goed doel).

[Reactie gewijzigd door nandervv op 16 maart 2026 15:48]

[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.

[Splitinfinitive]

zeker maar als ze nu gebruik maken van coderabbit, en die constateert dat er 80% kans is dat de code AI generated is. dan filter je deze eruit? gecombineerd met een LLM om zinsopbouw en gebruik van leestekens e.d. te detecteren die vaak door AI gebruikt wordt ga je dan ook eruit filteren.

met gewoon de reden.

"het lijkt erop dat je hevig leunt op AI hierdoor ben je automatisch afgewezen ons systeem verwacht dat X% van de code door een LLM is geschreven.

mocht dit niet zo zijn vind ons op discord/slack/facebook/linkedin"

rapportje erbij van coderabbit/llm detector ofzo.

ja er zullen false positives tussen zitten, en die mensen die er echt mee gemoeid zijn zullen dan ook via een andere manier contact opnemen. maar je filtered zo wel de low effort eruit lijkt mij.

[StefanJanssen]

Daar zullen AI bedrijven blij mee zijn. Jan, Piet en Joris gebruiken AI om slop te maken, Karel moet AI gebruiken om de slop eruit te filteren.

Coderabbit heeft ook kosten, die zullen dit op termijn ook niet meer gratis doen. Tegen die tijd moet je kiezen, betaalde krachten binnen een opensource project wegbezuinigen om AI tools te kunnen betalen of de AI zijn loop laten gaan en twee fulltime medewerkers in dienst nemen die de PRs moeten checken.
In beide gevallen ben je als indiener alleen maar kosten aan het maken voor een project wat draait op donaties.

En ja, voor alsnog zijn de enige kosten misschien uitgedrukt in tijd, maar een wapenwedloop loopt voor de opensource projecten niet goed af.

[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.

[Splitinfinitive]

daar zouden dan in eerste instantie zaken zoals aangegeven in het artikel een eerste filtering kunnen gaan doen?

zie ook mijn reactie op Webgnome

[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.

[nandervv]

Idd.
De gouden regel van bijdragen aan een project: dien alleen een bijdrage in als jouw bijdrage meer oplevert dan het reviewen kost.

[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.

[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

[StefanJanssen]

Inderdaad, maar wel veel sneller dan van mensen

[sympa]

En mensen geven het wel op na op zijn hoogst een paar afwijzingen. Dat hoeft bij toepasisng van AI (agents of anders) niet zo te zijn.

[Jim de Wit]

Dat zie ik absoluut, sterker nog: het is mijn voornaamste bezwaar. Ik zeg toch ook nergens dat het niet om LLM-gegenereerde code gaat?

[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.

[StefanJanssen]

Met de hoeveelheid onderzoek die ik moet doen en noteren is het toch een stuk eenvoudiger en sneller zelf die code te schrijven is mijn ervaring

[StCreed]

Uhhuh... hou die gedachte vast :)

Ik heb net 30 GB aan geodata verwerkt tot een nette HTML-applicatie met een kaart met meerdere lagen terrein (elevatie, water, wetlands, administratieve grenzen, etc.). Dat deed hij in eerste instantie in 4 uur tijd. Daarna waren er edge cases die meer tijd vergden. Daar laat ik hem dus op een subset onderzoek doen en een rapport schrijven over wat hij vind, inclusief oplossingen met meerdere alternatieven. Aan de hand van dat rapport laat ik een andere AI dan een oplossingsvoorstel doen. En dan mag Codex dat in stapjes uitwerken.

Ongetwijfeld zijn er gevallen waarin inderdaad heel veel research nodig is en de AI die om specifieke redenen niet kan doen. Dat zal heel zeldzaam worden.

[RayNbow]

Ik heb net 30 GB aan geodata verwerkt

Moet 30 GB veel voorstellen?

Een jaargang aan Beeldmateriaal is 200+ TB en AHN gaat eveneens over terabytes.

een nette HTML-applicatie met een kaart met meerdere lagen terrein (elevatie, water, wetlands, administratieve grenzen, etc.)

Dat is... ook niet bijzonder?

[StefanJanssen]

En daar moet ik onder de indruk van zijn? Ik heb dergelijke code ook meermaals in een kleine dag geschreven.

[StCreed]

Ach ja. Ik heb de Nobelprijs ook twee keer gewonnen.

Kom toch op zeg. Je schrijft geen 10K werkende regels code in een dag.

[StefanJanssen]

Misschien begrijp ik je verkeerd maar hoezo heb je 10000 regels nodig om wat data om te zetten naar een geoformat om te tonen op een kaart?

[Bamboozled]

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.

[MadEgg]

Tja, mijn ervaringen zijn anders. Er komt werkende code uit. De code op zichzelf ziet er ook nog best prima uit. Maar als je ervaring hebt met de applicatie, de context, de frameworks die gebruikt worden en dergelijke dan zie je vaak dat dingen inefficient gebeuren, dingen over het hoofd zien, stukken code herimplementeren die al in het framework zitten, code maken die execution bottlenecks introduceren en wat al niet meer.

Deze PR's worden aangeboden met minimale checks en zeker door minder/niet ervaren ontwikkelaars kun je er niet vanuit gaan dat deze dingen opgelost zijn.

Voorheen zag ik met minder ervaren ontwikkelaars dat ze naar me toekomen met een hulpvraag voor de implementatie. Dan kun je er samen over nadenken en een ontwerp maken dat goed past bij het hele plaatje. Daar leer je beide wat van.

Nu in plaats daarvan genereren ze een oplossing die soort-van werkt maar over veel belangrijke details heenwalst. En aangezien de complexiteit van de gegenereerde code dan weer zo hoog ligt dat ze het ook niet kunnen overzien is de eigen review ook ondermaats. Dat kost mij dan weer meer tijd in de review.

Voor mezelf kan ik met heel veel details, context en dergelijke uittypen goede, efficiente code eruit krijgen. Maar het uittypen van al die details kost me regelmatig meer tijd dan het me zou kosten om het te implementeren. Uiteindelijk gebruik ik LLM-gegenereerde code vooral voor boilerplate-zaken als een REST-interface, of het schrijven van documentatie en tests. Voor de rest zie ik weinig efficientieslagen gemaakt worden.

[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

[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.

[J_van_Ekris]

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.

Als ik kijk naar onze physics engine, dan zit daar een flink stuk Theil-Sen regressie in, die qua CPU-gebruik van nature asymptotisch groeit met het aantal beschouwde datapunten (orde O(N^4)). We zijn real-time, dus die groei beheersen is echt een ding. Je ziet dat zo'n LLM daar gewoon blind inloopt, zelfs als je hele specifieke prompts geeft. Standaard oplossingen hiervoor, zoals Binairy Search Trees (zelf 30 jaar geleden nog geleerd op de uni) worden gewoon niet toegepast, tenzij heel specifiek geinstrueerd. Enige optimalisaties waar zo'n LLM mee komt zijn micro-optimalisaties zoals het cachen van een variabele die twee keer gebruikt wordt, etc.. Maar als je al zo specifiek moet instrueren, dan kun je het beter zelf bouwen.

[Reactie gewijzigd door J_van_Ekris op 16 maart 2026 10:14]

[demianmonteverd]

Dat is inderdaad een issue, ik heb een keer een spelletje proberen te maken en de rendering is inderdaad super naief, dat heb jij natuurlijk dan ook. Trees zal ie toch wel moeten kunnen toepassen, dat zit ook voldoende van de trainingsdata mag je toch verwachten inderdaad.

Overigens matchen onze ervaringen, LLM's moet je niet vragen om verbeteringen/features die performance gevoelig zijn of er mee te maken hebben (zelfs al richting database kan dat een probleem worden), dat is inderdaad vaak prut. Wat ik beschreef is het uitvullen van een specificatie, dat kunnen ze wel met wat handen en voetenwerk. Als je even snel een configuratie pagina of CLI of een stuk plumbing nodig hebt dus. Ideaal als je iets wilt 'zien' om te proberen of het een goed idee is om verder uit te werken.

[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.

[demianmonteverd]

In de reactie van 16 maart 2026 10:14 van @J_van_Ekris , de toepassing is een physics engine. Kan zeker zijn dat dat niet lekker lukt/werkt. Het voorbeeld in die comment geeft hij aan dat hij expliciet moet prompten om het bruikbaar te maken zelfs, dus @J_van_Ekris probeert echt wel meer dan de meesten. Misschien is het gewoon niet geschikt voor die use-case.

[Slyceth]

Ik ben een game met ai aan het maken. AI heeft moeite met physics? "Hey Claude, programmeer een LLM vriendelijke physics simulatie voor je jezelf zodat je het systeem kan tweaken."

AI haters hebben nooit fantasie of doorzettingsvermogen

[RayNbow]

Slechte AI is altijd een user prompt probleem

Wat nu als een taalmodel niet in staat is om het gewenste resultaat te bereiken totdat je letterlijk dicteert wat het taalmodel moet neerpennen (alsof het een ouderwetse secretaresse is)? Is het dan alsnog een prompt-probleem of kun je dan wel zeggen dat er iets schort aan het taalmodel?

Dat je namelijk met de huidige taalmodellen met de juiste prompt een gewenst resultaat X kunt krijgen is namelijk correct. De prompt is namelijk: "Geef het volgende antwoord: X".

[Slyceth]

Dus als je toilet verstopt zit huur je geen onstoppersbedrijf en ga je voor de rest van je leven terug naar het huis van je ouders om daar het toilet te gebruiken?

AI is populair omdat het zo verdraait nuttig is, en als je prompt maken 90% van het werk kost, heb je nog steeds 10% kunnen automatiseren

[RayNbow]

AI is populair omdat het zo verdraait nuttig is,

Ik beweer nergens dat AI niet populair is noch dat het niet nuttig is.

Het is echter veel te kort door de bocht om te zeggen dat bij slechte resultaten het aan de prompt ligt. Stel dat ik bijvoorbeeld de volgende vraag aan iets als ChatGPT stel:

"Hieronder staat een Commodore 64 BASIC programma. Wat is de uitvoer van dit programma als ik het draai? [...]"

Als nu ChatGPT met een incorrect antwoord komt, beweer je dan nog steeds dat het aan de prompt ligt?

[Slyceth]

Als je die vraag aan mij stelt weet ik het ook niet.

Je moet prompten "emulate a commodore 64 basic within the desktop environment you're in now. You're allowed to download an emulator for it. Then run this basic program and give me the output"

[RayNbow]

Waarom moet ik vertellen dat de chatbot een emulator moet downloaden? Waarom kan het taalmodel dat niet beredeneren? Sterker nog, de benodigde kennis zit vaak al in het taalmodel. Dit heb ik proefondervindelijk vastgesteld met losse chatsessies met specifieke vragen over Commodore 64 BASIC. Het probleem is echter dat op sommige vlakken een taalmodel scoort zoals een leerling die alleen oefententamens geoefend heeft en het prima doet als op het echte tentamen vragen voorbij komen die enorm lijkt op de oefenvragen, maar vervolgens belabberd presteert wanneer een vraag wat afwijkt van de voorbeelden.

Wat trouwens kwalijker is, is dat taalmodellen soms de prompt compleet negeren. Zie hier een voorbeeld prompt en hier het bijbehorende (incorrecte) antwoord.

[HansvDr]

Ik heb gewoon tooling gemaakt in c++ (wat ik niet beheers) met behulp van Codex.

Die haalde diverse projecten van het internet en maakte voor mij een nieuwe tool die beter deed wat ik wilde.

En aangezien het alleen voor mijzelf is is dat een prachtige toevoeging voor mij van AI om software te maken.

[aap]

Dit is een beetje het verhaal van:

"Ik heb geen rijbewijs, maar ik kocht een zelfrijdende auto en die bracht me zonder ongelukken naar waar ik heen wilde."

Dat werkte voor jou vast prima, maar dat wil niet zeggen dat diezelfde zelfrijdende auto ook geschikt is voor Max Verstappen.

[HansvDr]

Nee, het is eerder, ik heb meerdere open source tools nodig om te kunnen wat ik wil. De tools kunnen echter veel te veel en zijn totaal niet gebruiksvriendelijk.

Helaas geschreven in C++ en zo groot dat ik er zelf niet aan ga beginnen.

AI analyseert de broncode van de tools en haalt er alleen uit wat ik nodig heb. Ik zelf maak de workflow zodat ik de tool goed kan gebruiken. Klaar.

Max Verstappen moet het ook eens proberen met zijn auto....

[Slyceth]

Want de logica van jullie ai haters is dat wij allemaal Max Verstappen niveau van code nodig hebben.

Het feit dat ik in 1 zin kan zeggen: "Filter en vat samen alle mails over tweakers prijsdalingen en geef mij suggesties wat daarvan de beste deal is gebaseerd op marktdalingen" terwijl ik de afwas doe is Merlijn niveaus van magie. Ik hoef geen persoonlijke assistent in te huren!

[StCreed]

Je krijg eruit wat je er in stopt. Ik ken meerdere mensen die moeite hadden om iets zinnigs uit hun AI abonnement te halen. Maar leer de goede prompts te schrijven, dat verbetert de performance dramatisch.

Daarnaast heeft een LLM specifieke beperkingen. Timing problemen zijn geen LLM-oplosbare problemen, dus daar gaat hij niet mee helpen. Een LLM doet taalmanipulatie, dus alles wat daarmee samenhangt gaat heel goed, maar dingen die daar niets mee te maken hebben gaan niet.

Kijk trouwens ook eens naar het ATLAS framework. Dat is een aardige start (overkill voor de meeste zaken, echter) voor prompting.

[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]

[J_van_Ekris]

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.

Misschien wel een idee, om in ieder geval de AI bots de goede kant op te sturen zodat ze in ieder geval de juiste data gebruiken...

Thanks!

[Reactie gewijzigd door J_van_Ekris op 16 maart 2026 10:17]

[elmuerte]

Waarom zou ik als open source maintainer ook een llms.txt willen onderhouden en debuggen? Elke keer als je software of de LLMs veranderen moet je je llms.txt mogelijk ook aanpassen. Dat is dus een extra dependency, een dependency voor een proprietary black box.

[Stukfruit]

Dat is niet hoe het werkt. Je gebruikt een taalmodel agent voor het genereren van dat bestand op basis van je huidige codebase.

Je laat het het hele verhaal genereren op basis van een ground truth. In dit geval zijn je codebase en documentatie dat. Als je een nieuwe nodig hebt dan laat je dus een nieuwe maken.

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

[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]

[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.

[DrPoncho]

Denken in nuances is een verloren kunst.

[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.

[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.

[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?

[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.

[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.

[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.

[SG]

AI is monkey see monkey do. Dus waar is het mee getraind. Programmeurs heb verschillende kampen die discussiëren over programmeer methoden. AI gooi deze resources op hoop als training. Wat eigenlijk veel opinie is. Niet feitelijk.

[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?

[Zwatelaar]

De discussie of de persoon op voorhand kwade bedoelingen had of niet laat ik even aan me voorbij gaan.

Wat betreft je pitbull analogie:

Die beesten zijn niet selectief gefokt als schattig beest maar juist als moordmachine (sorry, bovengemiddeld agressief, als je om de hete shit wilt draaien).

Als pitbull eigenaar weet je dat en hoor je dus elke seconde alert te zijn en ten allen tijde verantwoordelijk voor de gevolgen.

[StefanJanssen]

Dat weten jij en ik, maar de gemiddelde pitbull eigenaar zegt "maar dat doet de mijne niet".
Ja je zou als eigenaar ten allen tijde verantwoordelijk moeten zijn voor de pitbull (of voor een rat, of welk ander beest dan ook), dat houd niet weg dat jan en alleman een dier kan kopen zonder ook maar iets over het dier te weten. Net zoals dat jan en alleman AI kan gebruiken zonder er maar iets van te weten.
Is iemand die niet goed voorgelicht een dier koopt die daarna iemand bijt fout bezig? Jazeker.
Heeft die persoon kwade bedoelingen? Nee, alleen erg naief.

[Zwatelaar]

Je woordkeuze lijkt de ernst te proberen downsizen. Geen kwade bedoeling, naief enz.

In geval van Pitbull gaat dat er niet zo makkelijk in bij mij. Op zijn oud Hollands gezegd: maak dat de kat wijs. Van een vuurwapen kent ook iedereen het gevaar.

Neem dan een andere analogie, niet iets wat allang illegaal verklaard had moeten zijn.

[StefanJanssen]

Ik probeer zeker niet de ernst te "downsizen" maar ook nirt groter te maken dan het is.
Wat we weten:
1. Iemand heeft iets fout gedaan
2. Iemand heeft hieronder geleden.

We weten niet wat de intenties van een persoon zijn, en dat is een van de grondpijlers van het Nederlandse rechtsysteem.
Je hebt dood door schuld en moord. Het verschil is tussen de twee is intentie.
Is iemand kwaad in de zin is in dit geval dus belangrijk en ik ben van mening dat we niet zomaar mensen moeten veroordelen voor dingen die we niet weten.

Je kan deze persoon zeker veroordelen van nalatigheid. Ongeacht de intentie heeft deze persoon fouten gemaakt.
Maar of we deze persoon kunnen veroordelen op doelbewust dit te doen vind ik erg gevaarlijk.

[SPee]

Met autorijden blijf je als bestuurder ook alsnog verantwoordelijk, ookal rij je op autopilot. Datzelfde laten doen met een AI, neemt niet weg dat jij als persoon die het allemaal heeft ingericht, niet daarvoor verantwoordelijk gehouden kunt worden. Net zoals een fileshare tool gebruiken en dan klagen dat je van Brein een boete krijgt, omdat je illegale content upload.

[StefanJanssen]

Voor de auto heb je een rijbewijs nodig, dat geeft aan dat je de nodige kennis zou moeten hebben, en dus verantwoordelijk bent (tenzij je ontoerekeningsvatbaar bent)

Ook Brein geeft geen boetes aan individuelen die eenmalig iets torrenten, maar alleen bij mensen die dit op grote schaal doen. Één individu die een keer een fout maakt kan, maar hoeft zeker niet persé kwade bedoelingen te hebben.

Een 6 jarig kind die een zak snoep in de tas stopt heeft geen kwaad in de zin. Ja het is fout, maarniet alles wat men fout doet is met kwade bedoelingen.

[SG]

Een full autonoom auto zou dan ook rijbewijs moeten krijgen. Met hooguit noodknop. Zodat iedereen erin passagier is.
Een pilot autonoom voertuig dus beta ben je tester en dus verantwoordelijk

[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.

[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.

[Snow_King]

Om jouw comment een linkje te geven naar een FD / BNR artikel: https://www.bnr.nl/nieuws...-ai-gegenereerde-adviezen

[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.

[Johannes99]

Als werkzame programmeur en hobbymatige bijdrager aan verscheidene opensource-projecten kan ik dit volledig beamen. Wanneer mensen reacties plaatsen middels overduidelijk AI-gegenereerde tekst voelt dit gewoon als een klap in je gezicht, alsof je niet waardevol genoeg bent om een menselijke reactie te ontvangen. Op die manier is de lol er snel vanaf.

[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.

[Vibonacci]

Dit ligt ook echt aan hoe nieuwe devs omgaan met door AI gegenereerde code.

Stap 1 natuurlijk de code moet draaien en kijken werkt dat is stap 1. Ik vermoed dat vele PRs nu dat niet eens doen! En dat is maar echt stap 1.

Je moet zelf toch elke regel nagaan, met debugger er langslopen / loggen, nadenken of het beter kan en sneller, minder regels. Goed opslotsen, betere naamgeving etc.

Uiteindelijk is het de devs code en niet AI.