Home   2026-10-22 19:56:51

←

Debian staat generatieve AI toe voor bijdragen aan Linux-distro

Original article

Ontwikkelaars mogen generatieve AI gebruiken voor hun bijdragen aan Debian. Dat heeft de gemeenschap achter de Linux-distro besloten. Daarbij geldt wel de voorwaarde dat de bijdrager verantwoordelijk blijft voor de kwaliteit van de code.

Het gekozen beleid is vrij neutraal. Debian moedigt het gebruik van generatieve-AI-tools niet aan, maar verbiedt het ook niet, schrijft The Register. Verder erkent het dat AI-tools de productiviteit van bijdragers aanzienlijk kunnen verbeteren, 'wanneer ze op verantwoorde wijze worden gebruikt', zegt het beleid.

Maar de ontwikkelaar blijft dus wel verantwoordelijk voor de code. 'AI maakte een foutje' is dan ook geen excuus voor slechte codekwaliteit, benadrukt Debian in zijn nieuwe beleid. "Het gebruik van een generatieve AI-tool doet niets af aan de verantwoordelijkheid van de bijdrager voor het werk dat zij aanleveren. Van bijdragers wordt verwacht dat ze de door AI ondersteunde output begrijpen, beoordelen, testen en, waar nodig, aanpassen voordat ze deze in Debian integreren."

Debian moedigt ontwikkelaars verder aan om te vermelden wanneer een bijdrage met AI is gemaakt. Het is echter niet verplicht om dat aan te geven.

De leden van de Debian-gemeenschap kozen zelf het beleid. Zij werden vorige week via een peiling naar hun mening over een AI-beleid gevraagd. Deelnemers kregen acht beleidsvoorstellen voorgelegd, elk met een ander uitgangspunt voor AI. Zo waren er voorstellen die het gebruik van AI helemaal verbieden binnen Debian, maar ook voorstellen die voorzichtig gebruik toestaan. In totaal kwamen 450 geldige stemmen binnen.

Debian 13 "trixie"
Logo van Debian 13: Trixie. Bron: Debian

Door Eveline Meijer

Nieuwsredacteur

Feedback • 31-08-2026 14:58 91

31-08-2026 • 14:58

91

Lees meer

Reacties (91)

Ik vindt het niet hoeven te vermelde van ai gebruik niet echt een top beslissing, nou snap ik het wel i.v.m. heksenjachten te voorkomen
En wanneer houdt het op: als ik een vraag stel aan chatgpt en het antwoord inspireert mij tot de oplossing moet ik chatgpt dan bedanken? Waarom dan ook niet melden dat je naar stackoverflow gekeken hebt?
En wanneer houdt het op: als ik een vraag stel aan chatgpt en het antwoord inspireert mij tot de oplossing moet ik chatgpt dan bedanken? Waarom dan ook niet melden dat je naar stackoverflow gekeken hebt?
Als je slechte programmacode laat zien, zegt een LLM dat je een genie bent omdat je deze geweldige code hebt bedacht. Dus push je dat meteen naar git. Op StackOverflow word je tot op de grond toe afgebrand. En dan delete je stilletjes de code en je gaat iets beters verzinnen.
"Als je slechte programmacode laat zien, zegt een LLM dat je een genie bent"

Welke LLM gebruik jij? Ik krijg altijd een hele andere reactie op slechte programmacode.

Of was het gewoon grappig bedoeld?
Het was grappig bedoeld, want het deed mij denken aan https://programmerhumor.io/stackoverflow-memes/why-would-you-even-want-to-do-that-h4pe

LLMs staan bekend om hun sycofantisme.

Ik weet niet uit eigen ervaring wat een LLM doet met slechte code. :*)
Wel weet ik wat Gemini, Copilot en Mistral doen met slechte HAProxy configuraties. Ik ben meer dev dan ops, dus mijn HAProxy configs zijn niet echt geweldig. Meestal maakt de LLM die configuraties slechter, maar geeft het mij ook een idee wat ik dan wel moet doen.
Omdat dat iets heel anders is dan gegenereerde code gebruiken. Een meer passende vergelijking zou zijn om een heel blok code van Stack Overflow te kopiëren en plakken; kan zijn dat je die goed gelezen hebt en weet wat het doet, maar de kans dat je weet wat het doet en verantwoordelijkheid kunt dragen over die code is aanzienlijk minder dan wanneer je het zelf schrijft.

Dat is ook waarom instanties als Codeberg termen als 'voor het merendeel geschreven met AI-tools' gebruiken om dat type gebruik aan te duiden.
En wanneer houdt het op: als ik een vraag stel aan chatgpt en het antwoord inspireert mij tot de oplossing moet ik chatgpt dan bedanken?
Aub niet bedanken. Dat bedanken van LLM kost teveel stroom :+
zelfde moment dat je zou zeggen det je code niet jouwe is maar van wie je het overgekopieerd of laten maken. mijn punt was ook meer dat ik een harde stand zou willen zien in het wel of niet moeten zeggen, want het optioneel maken doet niks behalve het tegen de regels maken om boos op iemand erover te worden
Ik vind het juist opmerkelijk dat ze vragen het wel aan te geven. Ik lees voornamelijk meer "je mag het gebruiken zolang het ons maar niet opvalt". En met "niet opvalt" dan omdat de code "zo goed is dat het lijkt alsof je het zelf geschreven hebt" (+ je voor testen verantwoordelijk blijft etc).
ja dat was ook eigenlijk meer mijn punt, nu is het gedoogd om het te verbergen, en kan er volgens de regels niks meer over gezegd worden waneer iemand zijn werk wat met/door ai gemaakt is verbergt
Je kunt er niks van zeggen dat het door AI is gemaakt. Je kunt diegene wel nog steeds aanspreken op dat het "niet goed" is. Zonder dat diegene zich kan verweren met "het is door AI gemaakt". Want diegene had het werk gewoon goed moeten controleren en blijft verantwoordelijk ervoor.

De vermelding "is door AI gemaakt" is dan ook irrelevant in dat geval. Je mag toch niet naar de AI wijzen. En zo zijn er natuurlijk wel meer dingen irrelevant. Als je het in een IDE maakt en vervolgens een verkeerde auto-complete (non-AI-based) toepast is dat ook irrelevant om te vermelden dat je auto complete gebruikt hebt. Je hebt de output van het hulpmiddel niet goed gecontroleerd, en dat is eigen verantwoording. En ook al die hulpmiddelen die je gebruikt hebt hoef je niet te vermelden.
aan de andere kant levert AI ook wel wat op. Ik liep onlangs bij een FOSS project tegen een logische bug aan (0,1 index dingetje) dat geen foutmelding gaf, maar wel een foutieve plaatsing van een lijn (1 pixel shift). Niks schokkends, maar Claude opus vond wel een aantal gerelateerde logisch bugs en suggereerde een versimpeling van de code.

Omdat ik zelf geen C coder ben en de code ook niet geschreven had, was ik daar best blij mee en heeft mij ook meer inzicht gegeven in het project.

Uiteraard gedeeld met het project, men was er blij mee en na review gecommit.
Maar als je aangeeft "ik heb deze big opgelost en Claude vond een soortgelijke bug hier hier en hier en ondanks dat ik geen C dev ben lijkt deze constatering, en aangedragen oplossing, mij correct en heb ik deze ook getest en werkt het". Dat is natuurlijk heel wat anders dan "eey Claude, herschrijf de halve codebase en dan maak ik een PR alsof ik het zelf gemaakt heb", zonder ook maar iets te controlen of te testen.

En voornamelijk dat laatste is een (zeer) groot probleem voor OSS projecten. Er wordt iets aan AI gevraagd en zonder degelijk testwerk over de lijn gegooid waarbij de maintainer(s) het zich maar mogen uitzoeken op correctheid, testen, .... En dus ook maar er achter mogen komen dat AI er een grote shitshow van gemaakt heeft "en niks klopt". Daarom dus ook dat meerdere projecten het beleid hebben "controleer en test de code alsof je het zelf geschreven hebt, het resultaat is jou verantwoording, niet dat van de AI". Zodat, hopelijk, de submitter (/schrijver) meer dan 5 minuten er aan spendeert om een prompt in een AI te gooien en verder niks.

En AI echt verbieden kun je toch niet. Want als zoals nu gevraagd, de kwaliteit van de code is alsof die zelf geschreven is, herken je het als maintainer toch niet. En dan maakt het natuurlijk ook niet uit dat het uit een AI is gerold.
maar waarom is het dan een probleem om het toe te voegen als het in principe ook niet veel weg haalt? ik kan ook niet zeggen dat een product vegan is als ik toch maar even boter ivm margerine heb gepakt, dus waarom is dat zo veel anders voor ai? en het enigste verschil met dat sociale controle en het verplichte is alleen dat er makkelijker consequenties gesteld kunnen worden voor liegen en mensen voor de gek te houden in een project wat alleen om samenwerking draait.
Als je weet wat je aan het doen bent, en je gebruikt AI juist als tool, dan toch alleen maar goed? Je krijgt echt geen leeken die maar code gaan schrijven voor debian, dit zijn vaak al doorgewintererde ontwikkelaars. Tevens wordt de code al door meerdere reviewers nagekeken en zelfs automatisch.
Juist het gebruik van AI verlaagd de drempel om bij te dragen aan projecten waar je voorheen "expertise" voor nodig had. Immers doet die LLM prima of die die expertise heeft.

En vervolgens heb je zelf weer niet de expertise om de output van die LLM te controleren. En daarom dat Debian nu wil (/eist) dat de code doe je bijdraagt op basis van een LLM dus wel (grondig) door je beoordeeld is. Dus je je op z'n minst bekend hebt gemaakt met de wijziging en omringende code, én je dus ook uitleg er over kunt geven. Dan heeft de LLM je wellicht wel geholpen om de wijziging te maken, maar heb je wel ook expertise er over en als het goed is om de volgende keer een soortgelijke wijziging te doen zonder een LLM te vragen.
Sommige andere proposals in de Debian Vote haalden ook ook dat AI overwegend slecht is, onder andere omdat (1) de kennis van de modellen in vele (als niet alle) gevallen tot stand is gekomen door inbreuk op de intellectuele eigendomsrechten van zowat de hele wereld, en (2) het gebruik van AI bijzonder veel resources vergt, en dus een hele grote ecologische voetafdruk met zich meebrengt.

Functioneel leun ik aan bij jouw gevoel, nl. dat je AI juist kunt gebruiken en dat het dan alleen waarde toevoegt (en nooit wegneemt), maar in het grotere plaatje is de situatie natuurlijk veel grijzer dan dat.
Het probleem is dat de code van vibecoders en de code van senior programmers vrijwel hetzelfde kan lijken. Dat kan negatief uitdraaien omdat je als reviewer de skill van een auteur ook in acht neemt bij een review. Als je er van uitgaat dat iemand weet wat hij doet dan dan ga je kleine fouten minder snel opmerken.
Ik ben al meer dan 25 jaar voltijdsprogrammeur, maar ik heb nog nooit de skills van een developer meegenomen in een review. Ik voer een review uit alsof het mijn eigen code zou zijn. Code in een PR moet gewoon goed zijn, het maakt daarbij niet uit of je slechts 1 dag in dienst bent of al 10 jaar.

Code moet goed zijn en voldoen aan de company standards.
En dat is mijn punt dus. LLM code "lijkt goed" waardoor je dus sneller een fout gaat missen. De code van een junior ga je immers niet 1, niet 2, maar 3 keer herbezien, en dat doe je minder snel bij een senior. De code van een LLM daarintegen is eerder zoals die van een junior maar die dan op die van een senior lijkt. Je krijgt code die lijkt te kloppen met een uitleg die lijkt te kloppen maar dat ding heeft geen begrip van wat er staat.
Jammer, dat betekent dus ook Proxmox.
We moeten het maar een kans geven denk ik, het is toch de toekomst totdat het tegendeel bewezen is.

Overigens valt op die productiviteit best wat af te dingen volgens Wikipedia:

In July 2025, METR, an organization that evaluates frontier models, ran a randomized controlled trial to see how AI tools affect developer productivity. The researchers found that using AI tools made developers 19% slower, despite developers believing that AI tools would make them 24% faster before the tasks and still believed AI tools made them 20% faster afterwards.

Bron: Wikipedia: Vibe coding

[Reactie gewijzigd door xxs op 31 augustus 2026 15:14]

het is toch de toekomst totdat het tegendeel bewezen is.
Wat is dit dan van uitspraak?

Ik word zo ontzettend moe van iedereen die constant zit te schreeuwen dat AI de toekomst is en dat alles en iedereen het nu moet gaan gebruiken want "het is de toekomst".

Ten eerste werd dit de afgelopen jaren constant gezegd over technologie dat uiteindelijk niks is geworden, zie NFT's of de Metaverse.

Ten tweede is dit gewoon een self-fulfilling prophecy. Bedrijven als Nvidia, OpenAI en Anthropic wedden hun hele bestaan op de voorspelling dat AI de toekomst zal zijn, dus doen ze er alles aan om te forceren dat het de toekomst wordt.
Je klinkt als mijn overgrootvader die vond dat kunstmest nergens voor nodig is. :+
Al die vergelijken met vroeger slaan stuk omdat AI iets is wat ons denken uitschakelt . Dat is überhaupt de reden dat we als mens zover zijn gekomen . Als denken niet meer beloont wordt wat heeft studeren dan nog voor zin ?
ligt er aan. Wij gebruiken AI tools om project voorstellen te verbeteren. Diverse keren komt een AI tool met dingen waar we tot nu toe niet aan gedacht hadden. Wat ik zie in nieuwe projectvoorstellen is dat juist die aspecten nu direct toegevoegd worden (dus niet door AI) omdat mensen van de AI evaluatie geleerd hebben.
Natuurlijk liggen er ook met AI gevaren op de loer en ik ben ook terughoudend met het gebruik ervan. Toch denk ik dag er een onomkeerbare trend in gang gezet is.

Hoe e.e.a. uit gaat pakken weten we geen van allen.
Nee dat klopt niemand kan de toekomst voorspellen. Maar veel mensen met name jongeren kiezen tijdens het leren de weg van de minste weerstand . Dit zie je op werk ook veel gebeuren en op korte termijn lijk je daardoor productiever. Maar wat heb je effectief geleerd met al die prompts ? Wat beklijft er .
Als jouw voorouders vandaag zouden terugkomen, zou er in hun ogen veel zijn dat jij niet kan. Wat jij nu denkt over jongeren die AI gebruiken dacht men vroeger over jou. Is AI fundamenteel anders?
"het is toch de toekomst totdat het tegendeel bewezen is." gaat misschien wat ver, maar AI vergelijken met NFT’s of de Metaverse is het andere uiterste.

AI is veel meer dan alleen snelle code genereren ("bouw dit voor mij" of "los deze bug op"). Denk aan de gezondheidszorg, waar het al helpt bij operaties, of de ruimtevaart, waar onlangs een raket grotendeels door AI is ontworpen.

Ik zeg niet dat ons hele bestaan nu al compleet verandert door AI, maar stellen dat het net zo’n gefaalde hype is als de Metaverse of NFT's? Daar ben ik het absoluut niet mee eens.
Ze hebben er zoveel geld ingepompt dat het wel een succes moet worden.
Van de NFT's en Metaverse heb ik echt moeite om aan te geven welk nut ze hebben. Ik kan een dag doorlullen over de voordelen van LLM's en AI. En natuurlijk ook over de gevaren en nadelen. Maar goed, dat geeft goed aan dat dit geen vergelijkbare technologieën zijn. En de bedrijven zijn duidelijk nog hard aan het experimenteren hoe de tech het beste te ingegreren is.
Ik word zo ontzettend moe van iedereen die constant zit te schreeuwen dat AI de toekomst is en dat alles en iedereen het nu moet gaan gebruiken want "het is de toekomst".
Het is niet de toekomst, het is nu. Ik wordt ook moe van de discussie, maar dan van de andere kant. Ons hele leven zit vol met slimme algoritmes, oftewel AI. LLMs zijn de volgende stap in neurale netwerken, een techniek die al 50 jaar met veel succes wordt gebruikt. Ik gebruik de term AI persoonlijk niet omdat mensen dat een science-fiction term vinden terwijl het vakgebied net zo oud is als informatica zelf, zo niet ouder.
Ten eerste werd dit de afgelopen jaren constant gezegd over technologie dat uiteindelijk niks is geworden, zie NFT's of de Metaverse.
Dat is geen argument, zo kun je wel tegen alles zijn.
Met dat verschil dat AI/LLMs wél leveren. Natuurlijk het is nooit zo mooi als in het reclamepraatje, maar het is zonder meer krachtig gereedschap. Wie dat nu nog niet ziet heeft imho nogal zitten slapen.
Ten tweede is dit gewoon een self-fulfilling prophecy. Bedrijven als Nvidia, OpenAI en Anthropic wedden hun hele bestaan op de voorspelling dat AI de toekomst zal zijn, dus doen ze er alles aan om te forceren dat het de toekomst wordt.
1. Dat is niet hoe een self-fulfilling prophecy werkt. Hard werken om een doel te bereiken is geen self-fulfulling prophecy. Een SFFP is iets dat waar wordt dóór het te voorspellen.
2. Wat voor invloed hebben deze bedrijven om anderen te forceren om hun spullen te gebruiken? In het geval van MS/Google/Apple zou ik er in mee kunnen gaan omdat die gebruikers kunnen forceren om bepaalde techniek te gebruiken, maar niet NVidia, OpenAI of Anthropic. Zeker die laatste twee hebben niks buiten AI om iets mee te forceren.
Ik moet zeggen dat de modellen uit 2026 echt wel een enorme stap voorwaarts zijn. Vooral sonnet 5 is echt wel goed. Ik heb zo’n 25 jaar ervaring als professioneel programmeur. En het valt me op dat ik de afgelopen maanden nog maar enkele regels code schrijf, en de llm heel goed resultaat geeft. Dat was in 2025 echt wel anders.
Ik heb zo’n 25 jaar ervaring als professioneel programmeur. En het valt me op dat ik de afgelopen maanden nog maar enkele regels code schrijf
Even een serieuze vraag, maar bied jij jouw werkzaamheden nu ook goedkoper aan dan dat je voorheen deed?
waarom zou die dat doen? Sonnet 5 moet ook betaald worden :)
Als Sonnet 5 het zo goed kan, waarom zou een client dan extra betalen voor een tussenpersoon, die naar eigen zeggen bijna niks toevoegd aan de code, in plaats van zelf te betalen voor Sonnet 5?
Omdat ik met mijn ervaring weet wat ik van sonnet moet vragen en kan beoordelen wat er geproduceerd wordt. De voorgestelde wijzigingen kan ik goed op waarde schatten. Door de juiste dingen te vragen en een goed ontwerp te maken voorkom je enorm veel fouten en lever je kwalitatief goede code op.

ik ben geen tussenpersoon, sonnet is een tool voor code analyse en generatie. Heel handig. Maar voor nu moet je wel enige kennis hebben om die goed te kunnen inzetten
Kortom nieuwe populatie aan developers kunnen nooit die groei meemaken want beginnen al met llm tools. Wie gaat over 20-25 jaar beoordelen of de code nog goed is ? En kom niet aan met ai gaat exponentieel schalen , want de reden dat het nu zo goed is komt door de vele jaren aan "menselijke" input.
over 20-25 jaar doet AI dat. Er zullen tegen die tijd wel andere banen verdwijnen dit is geen een constante cyclus. Zo verdwijnt er weer wat en komt er weer wat terug.
Experten gaan we blijven nodig hebben.
Ze gaan gewoon steeds minder belangrijk worden.
ik ben geen tussenpersoon, sonnet is een tool voor code analyse en generatie
Tsja, dat jezelf gewoon wijs blijven maken totdat Claude nog veel beter wordt en jij toch echt wel die tussenpersoon bent geworden.
Tuurlijk kan dat. Wat Claude nu vooral mist is ontwerpen maken. Uitdenken hoe je problemen het best oplost. Het is een llm een hele goede llm, oftewel hij berekend welk woord het beste volgt op de vorige woorden. Dus code schrijven is die heel goed in. Maar goede oplossingen bedenken minder. Daar kun je wel degelijk in sturen. Geen idee hoe dat gaat verlopen en ja ik vind het wel spannend of ik dit werk kan blijven doen. Maar voor nu is het echt een tool
Tsja, in 2024 was het een veredelde zoek engine die het vaker mis dan goed had. In 2025 kwam het met oplossingen die best wat hadden.

Nu in 2026 in een project met miljoenen regels code gaat er een unit test fout na een update en patched ie zelfstandig aan de hand van die foute test de pom (maven project) aan, checked ie zelfstandig dat alle andere testen nog draaien, checked ie zelfstandig een oudere versie van de code uit en test die, schakelt weer terug naar de huidige versie en past de code overal aan om een paar verdwenen features in de laatste versie van de dependency die de code gebruikte op een alternatieve wijze te implementeren, en runt daarna weer alle testen om te controleren dat alles nu werkt.

En dat is zeer complexe low level networking code.

Wat gaat 2027 en 2028 doen als dit zo blijft groeien? Wat is mijn aandeel nog?
Misschien is het wel een logistische groei en zitten we nu al in het vlakke stuk. Als alle code door mensen ooit geschreven er al in gegooid is dan houdt het een keer op. En het is waarschijnlijk al niet meer zo dat er zo veel geniale code meer voorhanden is om nog op te trainen.

[Reactie gewijzigd door RoelRoel op 31 augustus 2026 23:08]

Ik heb hetzelfde. Ik ben een bieb aan het maken met tools die buiten de runtime leven. De AI ging er echter gewoon van uit dat de Java classes gewoon beschikbaar waren in het classpath. Dus de tools runden prima in het project zelf waarbij de tests in hetzelfde project zaten, maar ze werkten niet daarbuiten. Dat soort fouten maakt een persoon niet. En nog lastiger, de AI vergeet gewoon dat je dat vraagt en kan zomaar weer je design aanpassen. Dus dat soort regels moet je het ding expliciet ergens (laten) opschrijven want anders gaat het gegarandeerd fout.

Maar goed, uiteindelijk kan ik me nog meer met het probleem zelf bezig houden en veel minder met de saaie implementatie en met de testen, de maven setup enzovoort.
Ik ben momenteel een bibliotheek aan het schrijven, nou ja, de IDE doet het. Af en toe moet ik bijsturen of iets laten herschrijven, maar op zich doet de AI het heel behoorlijk en ik had zelf nooit in zo'n korte tijd zoveel regels kunnen schrijven. Het ding is ook superhandig voor rubber-ducking of het uitzoeken van mogelijkheden.

Ik merk wel dat het ding erg snel context kwijtraakt en niet helemaal beseft wat ik belangrijk vind en wat niet. Wat ik ook mis is dat de AI uit zichzelf vragen stelt. Ik ben een tijdje lead-programmeur geweest van een paar programmeurs die zichzelf ook prima konden aansturen, en die stellen vragen in plaats van iets zonder meer te programmeren.

Ik gebruik momenteel Codex met een plus abo en ben echt onder de indruk. Ben nu een set van regels aan het maken om de AI beter te laten programmeren. Grappig genoeg vraag ik ook aan de AI of de regels goed te verstaan zijn.
codex kun je zo instellen dat hij eerst analyses maakt, dan voorstellen doet en dan pas code maakt. doe het in kleine blokken en je hebt controle.
Dank! Ik ga even door de settings heen, misschien heb ik hem iets te voorzichtig gemaakt. Ik kan altijd aan hem vragen om eerst een ontwerpt te presenteren immers. Sterker nog, ga ik nu even doen denk ik.
Ik ben gewoon in dienst dus ja en nee. Ik ben productiever.
In dat geval kan je "client" vervangen met "werkgever".

Waarom zou jou werkgever jou hetzelfde salaris moeten blijven betalen terwijl je minder eigen werk oplevert?
Natuurlijk. Ik krijg toch ook niet minder salaris omdat ik nu visual code gebruik ipv kladblok. Of een compiler gebruik ipv assembly schrijf. Etc etc. Het zijn tools.

Het blijft mijn werk. Ik lever alleen meer eigen werk op

[Reactie gewijzigd door air2 op 31 augustus 2026 18:55]

Het "probleem" is dat Eclipse ipv TextEdit nog steeds heel veel expertise, kennis en talent vraagt. Jouw vergelijking is meer zoals een timmerman die een spijker met de blote hand in hout probeert te krijgen vs eentje die een hamer gebruikt.

AI gaat langzaam naar de situatie waar je heel high level zonder kennis van zaken het iets kan laten doen. Dat is meer zoals ik bij de Ikea een kast bestel. Ben ik dan opeens een timmerman?
Omdat je nog steeds even veel werk levert.
Waarom zouden zij korting moeten krijgen omdat jij jouw werkmanier efficiënter maakt?
Waarom zou ik een restaurant hetzelfde blijven betalen als ze mijn eten kant en klaar uit het pakje halen en in de magnetron stoppen?
Natuurlijk niet. Een developer wordt voor zijn uren en expertise betaald, niet voor het aantal regels code wat ie maakt. En dat geldt voor wel meer beroepsgroepen. Een machine-operator produceert helemaal niks, hij maakt het alleen maar mogelijk dat die machine blijft draaien, maar daar krijgt ie wel voor betaald. Een manager dito. Maakt zelf niks, maar wordt doorgaans goed betaald.
En wat is die expertise nog waard als een AI het sneller en goedkoper kan doen, terwijl het een kwalitatief gelijkwaardig product oplevert?

Dat is natuurlijk totdat we een paar jaar verder zijn en alles wordt uitbesteedt naar een Amerikaans AI model, maar ja, waarom zou je nadenken over lange termijn gevolgen voor iets waar je nu ontzettend veel geld mee kan verspillen?
Omdat de developer (als het goed is) nog steeds expertise inbrengt. Het werk is niet beperkt tot code kloppen. De reden is dezelfde als waarom nog niet alle development naar landen als India is geoutsourced. Omdat je vaak de expertise nodig hebt van mensen die dicht bij de eindgebruiker en de bedrijfsprocessen staan, en die ook voldoende begrijpen om goede requirements op te stellen. Want zonder goede requirements wordt het garbage in, garbage out voor een AI.
De reden is dezelfde als waarom nog niet alle development naar landen als India is geoutsourced
Dat was mede omdat ook India slechts een X percentage aan mensen heeft met genoeg talent, en die mensen op een gegeven moment gewoon op waren (lees, werkend voor met name de grotere bedrijven). De rest kreeg de ongetalenteerde Indieers met de bekende slechte output.

Pas als AI qua compute ook “op” is, en we alleen nog de beschikbare veel slechtere modellen kunnen gebruiken in instant mode, dan zal die vergelijking meer op gaan.

Maar “helaas” er komen nog steeds dagelijks vele duizenden compute nodes bij in massive data centers, en met nieuwe neural engines en GPUs wordt het ook nog steeds efficiënter.
Daarom nu het nog kan doen wij niets anders dan meters maken en geld binnenhalen. Ook dat is ondernemen.
Waarom denk jij dat AI expertise kan vervangen?
Het is juist heel duidelijk niet het geval op dit moment.

Maar dat betekend natuurlijk niet dat AI nutteloos is, integendeel.
Ook in een bedrijf heb je junior en senior developers.
Ik produceer meestal negatief aantal regels code. Laatst ook weer zo'n project. En ik was niet goedkoop per uur, verre van. Maar ook voor die uren betaal je niet echt, je betaald voor de oplossing.
De kwaliteit is inderdaae enorm veel beter. In 2025 stelde het nog code voor die keer op keer gewoon niet compilede, en waar methods werden aangeroepen die niet bestonden en parameters werden meegegeven die ter plekker bedacht waren.

In 2026 is dat een stuk minder.

Grote nadeel blijft dat je zelf steeds minder feeling krijgt met wat er onder die bekende motorkap nu precies gebeurd. Daarom blijf ik soort hybrid achtige methode gebruiken, zodat ik zelf nog grotendeels weet wat er gebeurd. Hoe lang dat vol te houden is als alles en iedereen de code volledig laat genereren?
Waarom is dat jammer? De devs blijven eindverantwoordelijk, dus er verandert niet zoveel. De tooling van de devs veranderd, that's all.

[Reactie gewijzigd door sky- op 31 augustus 2026 15:04]

Er veranderd wel iets. AI genereert erg graag code. Vaak word er niet voor slimme generieke de code gegaan, maar voor meer code. Dat betekent vaak meer code om te reviewen. En die code is vaak van gemiddelde kwaliteit (van de corpus van de trainingsset, waar wellicht een bias in zit).

De kosten (in vorm van tijd) van de PR verkleint aan de developer kant en word hoger bij de review kant. Ik kan mij voorstellen dat dat voor maintainers niet heel fijn is, vooral als er meer code van matige kwaliteit tussen zit.
Niet alleen code, ook commit messages met slop. Het record wat ik nu heb gezien is bijna duizend regels slop voor 12 LoC change met triviale aanpassingen, voornamelijk omdat alles overgecompliceerd uitgelegd word en de gebruiker niet echt wist waar die mee bezig was. De bot-commits (vraag claude om iets aan te passen en te pushen) zijn het ergste.

Ze verbannen de bot-commits niet dus ik wens ze success met rejecten van slop.
Ik hoop niet dat je nu gaat beweren dat mensen zulke goede commit messages maken. En ja, slechte commit messages zijn vervelend, maar die van de AI zijn in ieder geval compleet. Ik laat de AI graag commit messages schrijven maar kopieer ze daarna zelf naar het veldje in mijn IDE. Als ze te groot zijn of (onwaarschijnlijk) niet compleet of incorrect dan pas ik ze aan.
Nou dat vraag ik me af.
Ik ben toch wel bang dat er best het een en ander aan AI zooi doorheen kan glippen wanneer een dev het niet begrijpt of niet goed checked. En ja, dat wordt later dan vast wel wel weer gepatcht, maar dan ben je wel al te laat en heb je wel al een leuke hoge CVE gehad.

Aan de andere kant, Debian bestaat net zoals alle Linux distro's toch voornamelijk uit 3rd party/upstream code, waar ze toch al niks over te zeggen hebben.
Natuurlijk zou het beter zijn wanneer Debian dit in zijn geheel zou weren, maar je kunt het niet afdwingen, en ook niet voorkomen dat een een of andere jodokus van het KDE project of iets alsnog wel die hele repo vol stort met AI slop...
De devs blijven eindverantwoordelijk, dus er verandert niet zoveel.
Meh, ben bang van wel. Je gaat niet elke request van de AI of elke regel code doorlezen. Het is te veel, te veel overload, te... te veel gewoon. Het is ook extreem saai en werk enorm burn out in de hand.

Eigen code die complex is snap je, omdat je zelf er mentaal eerst doorheengegaan bent, de verbanden kent, de context kent. Enorme lappen code, van honderden, duizenden regels, die als een snelvuur kanon op je afgeschoten worden allemaal doorlezen EN doorgronden...

Sorry, maar ook de betere coders met enorme ervaring gaan dat niet volhouden.

En de nieuwe generatie die op deze manier nooit zal leren om code te schrijven gaat dat al helemaal niet doen.

Dingen gaan dus EXTREEM veranderen op deze manier.
Het grootste probleem is wat mij betreft dat die eindverantwoordelijkheid en het begrepen hebben van de code niet te toetsen is. Als je "toetst" op basis van of de code werkt, dan gaat het heel lang goed totdat het een keer heel erg misgaat.
Linus Torvalds is zelf al aan het experimenteren met AI, en staat het gewoon toe in de kernel. Je ontkomt er dus sowieso niet aan.
Zelfs het inrichten van Linux is nu met AI een makkie. Voor het eerst dat ik het nu fatsoenlijk kan gebruiken. Ik laat AI gewoon al die commandos sturen 😃
Jammer, dat betekent dus ook Proxmox.
Ja maar ook nee, dit beleid zegt namelijk niks over hoe Proxmox om gaat met hun eigen code.

Dat Proxmox gebruik maakt van Debian als onderlaag maakt wel dat er een kans is dat er AI-code zit in de Debian-codebase. Nu heb ik er niet diep in gedoken, maar voor de Linux-kernel zijn er ook al richtlijnen voor opgesteld, zie: https://docs.kernel.org/process/coding-assistants.html.
Is dit niet een typisch geval van "uiteindelijk gaat het allemaal op deze manier"? Het klinkt een beetje als "Logistiek Bol.com staat doe dat in voorraad- en distribitiecentra wordt gewerkt met vorkheftrucks in plaats van met de hand orderpicken". Ik vind AI ook echt meer slécht dat goed nieuws voor mensheid, maar als je dit blijft weigeren... tja... stuur dan maar een fax naar de klachtendesk.
Ik ben het niet met deze vergelijking eens. Een vorkheftruck geeft je exact hetzelfde resultaat. Bol blijft een doorgeefluik en creëert zelf niets.

Wat denk je van "BAM laat technische ontwerpen van bruggen door een LLM doorrekenen om de productiviteit te verhogen"?
Wellicht is dat een goed idee gezien de fouten die BAM maakte in Eindhoven.

https://www.cementonline.nl/artikelen/oorzaken-instorting-parkeergarage-eindhoven
Het grote verschil zit hem in het feit of een developer de prompts schrijft of een leek. Iedereen kan iets bouwen met AI, maar slechts developers weten waar ze mee bezig zijn omdat ze begrijpen wat er gebeurt en wat er moet gebeuren.
"Make me this application and don't make mistakes. Write perfect code"
Dat zou heel naïef zijn.
Tsja, AI is here to stay, of je het nou wil of niet. En AI kan oprecht heel handig zijn, waarbij coding wel een van de gebieden is waar het sterk in is.

Ik denk dat Debian hier wel een goede stap maakt, vooral met de juiste randvoorwaarden zoals het expliciet maken dat de indienende developer zelf verantwoordelijk blijft.
Je krijgt echt geen leeken die maar code gaan schrijven voor debian
Nou, met de opkomst van AI wel dus, en dat ("Junk AI pull-request") is juist een belangrijke overweging om het niet toe te laten. Want met AI wanen meer mensen zich in staat om PRs te maken die iets zouden toevoegen.

(EDIT: Dit moest een @Jorah_Newstone zijn, maar het systeem zei, "nee")

[Reactie gewijzigd door Luminair op 31 augustus 2026 15:22]

Het grootste probleem dat ik hier zie zijn toch de licenties.

Hoe kan Debian netjes onder de GPL blijven vallen, als er code in zit die gemaakt is met AI-modellen getraind op code waarvan het op zijn best onduidelijk is hoe het met de licentie zit? (en op zijn slechts zou je het kunnen omschrijven als gestolen code)
Benieuwd of het aantal bug en lekken gaat toenemen of afnemen hierdoor.
Ik denk een onvermijdelijke keuze omdat AI gebruikt wordt bij het programmeren maar zoals met alle AI of het om teksten, code of agents op een kwaadaardig model vrolijk hackend in de rondte gaan zoals bij OpenAI: je (individu, bedrijf) bent en blijft zelf verantwoordelijk en aansprakelijk voor wat je met die AI doet.

EDIT Ben en blijf een blije debian gebruiker, een prachtsysteem.

[Reactie gewijzigd door wimdebok op 31 augustus 2026 17:31]


Om te kunnen reageren moet je ingelogd zijn