Ook Linus Torvalds erkent dat AI een goede tool voor programmeurs kan zijn

Ook Linux-eindbaas Linus Torvalds is om: ontwikkelaars kunnen AI prima gebruiken bij het programmeren. Torvalds schrijft in een maillijst aan kernelmaintainers dat hij en Linux 'niet anti-AI' zijn. Torvalds was aanvankelijk sceptisch over AI, maar nam de afgelopen maanden een genuanceerdere positie in en ziet AI nu als een stuk gereedschap in het arsenaal van programmeurs.

Dit nieuws in het kort

• Linus Torvalds, hoofdontwikkelaar van de Linux-kernel, heeft een uitgebreide e-mail geschreven met zijn mening over AI bij het programmeren.
• Hij noemt AI een belangrijke tool in de gereedschapskist van maintainers.
• Torvalds was aanvankelijk sceptisch over AI.

Torvalds zet die nuance uiteen in een kernelmaillijst. Hij reageert op een andere kernelontwikkelaar in een discussie over het gebruik van large language models bij programmeertaken. Torvalds is daar niet principieel tegen. Als de belangrijkste maintainer van de Linux-kernel zegt hij dat hij voet bij stuk wil houden over AI. "Linux is niet een van die anti-AI-projecten, en als iemand daar problemen mee heeft, dan kan hij de opensourceroute kiezen en de kernel forken. Of gewoon weglopen."

Torvalds noemt AI 'een tool, net als andere tools die we gebruiken'. "En het is overduidelijk een nuttige tool."

Veranderde mening

Dat is een andere mening dan Torvalds eerder nog uitdroeg. In 2024 was hij bijvoorbeeld nog sceptisch over AI. Hij noemde dat toen 'voor negentig procent marketing' en zei er ver van weg te blijven.

Tegelijkertijd gebruikte hij llm's ook om zelf te programmeren. Dat deed hij niet in kernelcode, maar in een ander opensourceproject genaamd AudioNoise. Hij zei toen ook al wel te verwachten dat zaken rondom AI zouden veranderen in de daaropvolgende maanden.

Torvalds erkent die veranderde mening. "Misschien was het een jaar geleden nog niet zo duidelijk, maar vandaag de dag is er geen twijfel meer mogelijk." Torvalds ziet nog wel problemen met AI. De financiële kant daarvan blijft volgens hem nog onduidelijk. "Maar de vraag of het nuttig is, is geen vraag meer. Iedereen die daaraan twijfelt, heeft het duidelijk niet gebruikt."

AI-slop in pullrequests

Daarnaast kan AI best problemen opleveren voor maintainers, erkent Torvalds. AI-gegenereerde pullrequests leveren steeds meer problemen op voor opensourceprogrammeurs. Tweakers schreef daar eerder dit jaar al een achtergrondartikel over.

Dat ziet Torvalds ook, naast het feit dat AI soms 'beschamende' bugs vindt. "Maar de oplossing daarvoor is niet om je kop nog langer in het zand te steken en te doen alsof je het niet hoort, zoals sommige mensen dat doen", zegt hij. In de praktijk negeert Linux pullrequests met AI-gegenereerde code dan ook niet. "We blijven beslissingen nemen op basis van technische bijdragen. Niet uit angst voor nieuwe tools."

Reacties (138)

[HarmFull]

Volgens mij is dit oud nieuws en heeft Torvalds al eerder gemeld dat AI een goede tool is? Jammer dat Tweakers dit als iets nieuws brengt terwijl afgelopen maanden Torvalds al meermaals dit gemeld heeft, waaronder op de Linux Foundation summit keynote
andere bronnen: the new stack, YouTube (savvynik)

Torvalds stelde dat hij "kwaad" wordt als hij iemand hoort zeggen dat 99% van zijn code door AI geschreven is. Volgens Torvalds is 100% van die code door compilers geschreven en dat net zoals hij niet meer machine code of assembly schrijft, zullen hedendaagse programmeurs niet meer op dezelfde manier code schrijven. Maar het vervangt niet de fundamentele principes.

Ook zit er volgens Torvalds een groot verschil tussen het vibe coderen van 'throwaway' projecten en projecten die je 35 jaar (linux ) onderhoudt. Je moet het eindresultaat snappen en niet alleen wat de prompts genereren.

[Pietopdeheuvel]

Volgens Torvalds is 100% van die code door compilers geschreven en dat net zoals hij niet meer machine code of assembly schrijft, zullen hedendaagse programmeurs niet meer op dezelfde manier code schrijven. Maar het vervangt niet de fundamentele principes.

Goed punt. Zolang je niet in assembly schrijft ben je net zo afhankelijk van de compiler dan van een AI. Laatste grote project wat ik ken wat in assembly geschreven werd door mensen was de SMSC van CMG.

[Phanthix]

En hierdoor zie je dus ook dat optimalisatie ver te zoeken is bij de meeste applicaties van nu. De gedachte "Er is nu toch meer dan genoeg rekenkracht en opslag beschikbaar in de computers van consumenten" heeft er ook toe geleid dat er onnodig veel kracht en opslag nodig is voor de meest simpele applicaties, wat ook weer impact heeft op veel dingen zoals uitstoot, kosten en verbruik, net zoals bij AI. Natuurlijk is AI wel echt een groot gebruiker, maar ik vraag me af of dat meer komt omdat het meetbaar is, doordat je het centraal hebt staan in data centers. Als je alle applicaties zo veel mogelijk zou optimaliseren, kan iedereen denk ik makkelijk met de helft van z'n RAM en CPU capaciteit voort (buiten grafische toepassingen om).

[Pietopdeheuvel]

Dat denk ik ook. Verder zijn veel applicaties zo volgepompt met features die vrijwel geen hont gebruikt.

[bramv101]

Heb het geluk gehad om in verschillende industrieën te werken (aerospace, automotive, software, semicon). En de software sector is inderdaad diegene met de meeste junk output (omwille van tijdsdruk). Als je zulke inefficiënties in andere takken zou toelaten dan krijg je (hyperbool) raketten die niet eens van de grond afraken.

De enige reden dat men in software engineering goed geld verdient is omwille van de winstmarges, alvast zeker niet om de skills of de hardship in vgl met andere engineering disciplines.

[YGDRASSIL]

Ik heb juist met AI nog flink wat juice uit mijn code kunnen persen en een factor twee sneller door in het hotpath wat leuke optimalisaties toe te passen die ik zelf niet snel gedaan had (teveel werk, niet zeker of het verschil zou maken). Dus neem in je prompts performance mee en het kan ook best performant zijn...

[Marcel--]

Ik weet niet of SMSC later was, maar vergeet ook niet de AV1-decoder in FFmpeg, zie bv. dit interview(fragment). FFmpeg heeft zelfs een cursus assembly online gezet.

[readefries]

Helemaal mee eens, het probleem is vooral onervaren ontwikkelaars die ongecontrolleerd wijzigingen voorstellen en die eigenlijk niet begrijpen wat ze daarmee voorstellen.

Al is het ook prima mogelijk om als ervaren ontwikkelaar rotzooi voor te stellen als je de tool niet begrijpt 🙃

[trayracing]

Dit is m.i. ook de clou van waar voor veel Tweakers de weerstand zit. Het is niet weerstand tegen AI an sich, maar de effecten verderop in de tijd

Ooit was ik systeem- en netwerkbeheerder. En helpdesk, en applicatiebeheerder, en Chef 'alles-waar-een-stekker-aan-zit'. Vast voor veel Tweakers wel herkenbaar...

Wanneer collega's mij iets vroegen over de Verkenner, over Office, over andere applicaties, had ik er een handje van om het 'ff snel' vóór hen te doen. Want dat was sneller

Toen ik van baan wisselde, had mijn opvolger a hell of a job om al die collega's een beetje basis ICT-vaardigheid bij te brengen

Waarom? Ze hoefden voorheen nooit zelf problemen met speciale tekens in bestandsnamen te fixen. Ze hoefden niet zelf Word-tabellen over meerdere pagina's te fatsoeneren zodat de printer niet over de zeik ging. Ze hoefden niet de schermresolutie aan te passen zodat alle tekst wat meer leesbaar werd. Het werd altijd vóór ze gedaan

Dat is met AI niet anders. Het wordt allemaal vóór je gedaan, waardoor je (als je niet uitkijkt) de meest basale dingen gewoon NIET leert, of je gaat die snel vergeten

(in het voorbeeld van programmeren zit er m.i. nog een extra probleem, namelijk de toenemende complexiteit van applicaties, met libraries, frameworks, dependencies, het is zo zachtjes aan 1 grote bij elkaar geklikte janboel dat met touwtjes, plakbandjes en elastiekjes aan elkaar zit, en dat laten we nu gezellig door vibe-coders met behulp van AI 'naar een volgend level' brengen - ik weet niet hoor, ik houd m'n hart vast... groetjes, die ene dude uit Nebraska die dat ene ultra-essentiële kernel-pilaartje in leven houdt als hobby - de ingewijden weten over wie ik het heb)

Anyway, dat is wat ik met AI als primaire bedreiging zie, zowel voor Tweakers als voor de algehele jeugd van tegenwoordig (niet de band) - en overigens elke fervent AI-gebruiker die er helemaal op los gaat. De totale aftakeling van eigen denkvermogen, brainrot-on-steroids, omdat we alleen maar in de watten worden gelegd door quick-fixes, in plaats van zelf te proberen, fouten te maken, ervan te leren, en zo kennis op te doen (wat ook daadwerkelijk beklijft in plaats van verdampt na 3 nanoseconden)

Immers: failure, the best teacher is

/Yoda-mode:off

En inderdaad. AI an sich is 'slechts een tool'. Dus er juist mee om leren te gaan, daarin zit de clou. Ook onderwijstechnisch, en vanuit opvoeding. Maar er spelen m.i. daarnaast nog meer factoren mee die het extra bedreigend maken, zoals bijvoorbeeld hoe 'n handjevol gaziljardair-AI-bedrijven zo zachtjes aan de hele boel kan manipuleren naar een nieuwe wereldorder. En het gros van 't volk het allemaal als zoete koek slikt, en 'ach, maak je niet zo druk, we rijden toch ook auto, en niet meer op paard-en-wagen?' - van die drogredenen

Sorry voor de rant

[bzuidgeest]

Maar dat is van alle tijden. Hoeveel mensen leren nog met een telegraaf omgaan? Hoeveel mensen leren nog jagen?

Geen enkele vaardigheid gaat ooit echt verloren. Er zijn altijd artisans en artiesten en hobbyisten.

Het word dommer op 1 vlak en verkrijgt een vaardigheid op een ander. Als je er maar voor inspant. Mensen die niets willen leren gaan nooit iets leren.

Ik gebruik AI en word aan een kant dommer, terwijl de AI mij ook nieuwe dingen leert om toe te passen. Dus wat is het op het totaal? Gewoon anders.

Mensen worden al eeuwen "dommer" op een hoop vlakken. AI veranderd daar niets aan. Misschien een beetje sneller.

[StrongArmLance]

Wat voor nieuwe vaardigheden heb jij van AI geleerd? Behalve hoe je AI kan gebruiken.

[bzuidgeest]

Ik begrijp nu een stuk meer van hoe ghidra werkt en dos executables zijn opgebouwd. Verschillende trucs en laad mechanismes, Hardware acces in dos. Ik had een beginnetje en word steeds beter in het herkennen van de structuren.

Verilog is ook een leuke waar de AI je meer kan leren over FPGA's en je bijvoorbeeld niet eerste uren kwijt bent om de toolchain in orde te krijgen. En fouten kan de AI ook uitleggen.

Wil je er nog meer, want ik kan zat opschrijven.

[The Realone]

De crux zit hem erin dat je dingen leert doordat jij LLMs hebt gebruikt om je aan het leren te zetten. Dus je bent bewust zelf gaan leren, maar hebt LLMs gebruikt om je over die initiële drempel heen te helpen.

Maar, al die dingen had je ook prima zonder LLM kunnen leren, misschien beter, misschien niet. Zo hebben we alles sinds jaar en dag ons eigen gemaakt, zonder LLMs.
Ik zie om mij heen mensen die iets nieuws leren, die beginnen niet met 'hello world', maar met direct een probleem op te lossen. LLM geeft hen daarbij de oplossing en tevens de uitleg die daarbij hoort. Prima, op papier leren ze daarvan. In de praktijk zie ik dat ze steeds terug moeten vallen op LLMs bij elke stap die ze verder willen maken, omdat ze niet begonnen zijn met 'hello world'.

Dit risico is inherent aan het gebruiken van een hulpmiddel. En dat risico is extra groot in omgevingen waar LLMs op grote schaal gebruikt worden, namelijk in het bedrijfsleven, waar er druk is om te leveren en waar leveren goed is voor jou als werknemer. Voor hobbyprojecten is dat toch anders.

[lighting_]

Als je vraagt mijn code werkt niet en hij corrigeert het en legt het uit, Wat leer je daar dan niet van?

[readefries]

Hahaha, geen sorry nodig. Heel herkenbaar allemaal 😄

[walteij]

Nee!!! Een RJ11 stekker is geen netwerkaansluiting!!!

[beerse]

Toch wel: De eerste internet gebruikers in Nederland hadden vaak een rj11-stekker om de modems aan het telefoonnetwerk te hangen. Toegegeven, daar zat vaak een 'telefoon-stekker' aan vast om in de muur-contact-doos-voor-de-telefoon te steken.

Een RJ11 stekker is voor een ander netwerk dan een RJ45 stekker. Er wordt een ander protocol gesproken, zowel op hardware als ook op software niveau.

[ArtyShock]

En ik denk dat iedere verkoper zit te wachten op die ene wereldorder.

[JulesMarcus]

Ik ben het grotendeels mee eens, al heb ik één aanmerking wat ik zelf op werk merk. Door het gebruik van AI maak ik juist aanzienlijk minder gebruik van externe dependencies. Waar ik vroeger een pakket zocht zodat ik het niet zelf hoefde te maken, terwijl ik daar maar 5% van het externe pakket voor nodig had om mijn doel te bereiken, bouw ik nu het stuk benodigd code juist zelf. Door middel van AI gaat het zo snel dat ik niet meer opzoek hoef te gaan naar externe dependencies. Mijn repo is de laatste maanden een stuk opgeschoond erdoor!

Verder helemaal met je eens.

[Dauthi]

Alsof je zonder AI niet gemanipuleerd werd.

Er zijn millennia over heen gegaan dat de bevolking niets wist van wat er in de wereld gebeurde. Het is pas sinds de komst van internet en social media dat de bevolking een klein beetje meer geinformeerd is over de wereld als dat ze zouden willen.

Tot die tijd werd je per definitie gemanipuleerd. De manipulatie is gemoderniseerd, veranderd en geopenbaard maar alles behalve nieuw of ontstaan.

De enige hoop die je kan hebben is dat de openbaring tot motivative leidt, dat mensen meer geinterreseerd worden in educatie, zelfontwikkeling en politiek en geïnformeerd gaan stemmen. Echter, heeft het internet en social media ook geopenbaard hoe tribalistisch mensen nog steeds zijn ingesteld en dat het beschermen van de tribe vaak belangrijker is dan logica, rationaliteit en redelijkheid.

[satya]

Ik merk dat als ik het als tool gebruik in Claude Desktop met een eigen it-support skill die zich als medior collega moet gedragen, ik er juist van bijleer.

In het verleden las en googelde ik mij bij het probleem oplossen de moeder waar je van leert, en Claude gedraagt zich als een collega die met mij mee werkt en het googelen/lezen vaak kan overslaan.

Het gekke is dat het prima is bij de triage, maar de plank misslaat bij een aan te passen of toe te voegen parameter en halicuneert.

[valvy]

Ik merk dat ik als onderwijswetenschapper en voormalig programmeur wat weerstand voel bij je rant. Je gaat ervan uit dat het denkvermogen van mensen achteruitgaat door AI, maar die zorg is niet nieuw. En hij is eerder nooit uitgekomen.

Exact dezelfde discussie speelde toen IDE's zoals IntelliJ en Visual Studio het werken in vi en Emacs verdrongen. Charles Petzold hield er in 2005 zijn beroemde lezing "Does Visual Studio Rot the Mind?" over, en Jeff Atwood besprak destijds dezelfde angst: IntelliSense en codegeneratie zouden programmeurs lui en hulpeloos maken buiten hun IDE. Twintig jaar later is daar weinig van gebleken. Sterker nog: we bouwen vandaag betere en complexere software dan ooit, gemaakt door een generatie ontwikkelaars die volledig met die "verwennende" tools is opgegroeid.

Ook je aanname dat studenten met AI geen fouten meer maken en alleen nog het kortste pad kiezen, alsof het robotjes zijn, strookt niet met wat we uit de motivatiepsychologie weten. Volgens de zelfdeterminatietheorie zijn mensen van nature nieuwsgierig en leren en groeien mensen vanuit verbondenheid, autonomie en de behoefte aan competentie, en daar horen eigen fouten bij. Wat verschuift, is het niveau waarop die fouten worden gemaakt. Ik maakte mijn fouten via man-pages in een Linux-shell, de generatie na mij maakte ze in een IDE met IntelliSense, en de volgende generatie maakt ze met AI. Het leren verdwijnt niet, het verplaatst zich naar een hogere abstractielaag. Dat is precies wat er ook gebeurde bij de overgang van assembly naar C, en van C naar talen met garbage collection.

Je helpdesk-anekdote illustreert overigens iets anders dan je denkt: daar ging het mis omdat jij het werk volledig overnam zonder uitleg. Dat is geen eigenschap van de tool, maar van de didactiek eromheen. Een student die AI gebruikt als sparringpartner en vraagt "waarom werkt dit niet?" leert wel degelijk. Een student die blind kopieert niet. Maar dat gold voor Stack Overflow-copy-paste tien jaar geleden net zo goed. De clou zit dus, zoals je zelf al zegt, in ermee leren omgaan, niet in de tool zelf.

Overigens ben ik het wél met je eens over het risico dat wij die tools niet in Europa beheren. Ik zie het een beetje als de luddites van honderd jaar geleden toen de wevingsindrustie werd geautomatiseerd. Maar de wevingsmachines zitten straks allemaal in China en de VS zonder dat wij erbij kunnen. Terwijl deze machines straks fundamenteel zijn voor het opsporen van software bugs en het maken van complexe software.

[Reactie gewijzigd door valvy op 16 juli 2026 14:37]

[telenut]

Herkenbaar, maar niet helemaal mee eens.
Ik ben niet sterk in programmeren en laat AI het ook schrijven voor me. Omdat het vooral het schrijven is dat ik me ontzie... het nalezen kan ik nog, en het aanpassen ook. Hoewel ik dit zelfs beperkt tot enkele cijfertjes en de rest ook gewoon vraag aan AI. Want als ik het zelf doe wis ik soms per ongeluk een " of een '.
Voor de rest is en blijft het inderdaad een tool, maar een handige die me al veel tijd wist te besparen!

[The Zep Man]

Helemaal mee eens, het probleem is vooral onervaren ontwikkelaars die ongecontrolleerd wijzigingen voorstellen en die eigenlijk niet begrijpen wat ze daarmee voorstellen.

Of iets opbouwen met AI wat (initieel) werkt, maar totaal niet onderhoudbaar is.

[Wouterie]

Waar dan weer een AI op ingezet wordt en zo raken we steeds een beetje meer controle kwijt.

[Quacko]

Ik verwacht dat we daar stillaan wel naartoe gaan gaan. Nu is the human in the loop nog nodig. Maar wanneer je met een degelijke harnass, en een mixture of agents voor zowel functionele analyse, technisch design, knowledgebase bijwerken, programmeren, reviewen én testen gaat werken zie je toch al wat er in de toekomst mogelijk gaat zijn en dat die human in the loop minder en minder gaat worden.

We zien dat nu zelfs al in legacy en grote codebases lukken waar we het proberen. Daar is reviewing en testen dan nu nog wel manueel, maar veel van de foutjes die je in eenr review er uit haalt zijn er ook al door de review agent uitgehaald.

Met wat wij nu zien in onze ontwikkeling ben ik zelf wel overtuigd dat human in the loop snel heel klein gaat worden. En dat gaat raar aanvoelen, want we hadden altijd controle, maar als alle testen zeggen dat het goed is en je merkt op lange termijn geen problemen, is het verlies van controle dan zo erg?

[nzall]

het lastige daarmee is dat je daardoor op vrij korte termijn heel veel programmeurs overbodig maakt, want je hebt geen team van tientallen of honderden programmeurs nodig om zo'n mixture of agents werkende te houden. Tegenwoordig heb je zelfs agents om je agents te managen. Dus dat gaat heel wat werkgelegenheid kosten, en dan vooral van hooggetraind en gespecialiseerd personeel dat niet zomaar direct ergens anders aan de slag zal kunnen gaan.

[Barsonax]

Dat is leuk in demo's maar dit gaat echt niet werken in de praktijk.

Je bent gewoon weer de zoveelste persoon die er te simpel over denkt hoe complex productie waardige applicaties tegenwoordig wel niet zijn. Je gaat heel snel vastlopen als jij zonder technische kennis aan de slag gaat.

Dit is ook precies waar denk ik de meeste mensen kritiek hebben op AI. Niet zozeer AI zelf want dat is een hele mooie tool maar op de groep mensen die denkt dat je zomaar ff complexe banen zoals software engineers of architecten kan vervangen.

[PdeBie]

Dit inderdaad. Tot op het moment dat zelfs de AI zelf er niet meer uit komt. Dan loopt je project vast.

[olafmol]

Dit is imho het echte probleem. De huidige LLM based coding tools zijn prima in staat om een greenfield versie 1.0 op te leveren, gebaseerd op de functionele en non-functionele specs die je erin stopt. Maar als je daarop gaat door-ontwikkelen merk je dat ie toch te vaak "off the rails" gaat en rare dingen begint te doen, hoeveel "guardrails" en prompt-templates etc je er ook instopt.

In weze is de discussie over het nut en de kwaliteit van AI coding tools erg verwarrend omdat er 2 scenarios vaak door elkaar lopen of worden gehaald: A) software developers die AI tools gebruiken om code te schrijven, en B ) "product owners" die functioneel weten wat ze willen en AI tools gebruiken als "software developers" die voor hen bouwen wat ze in gedachten hebben. Dat zijn twee nogal verschillende scenarios.

Linus beschrijft scenario A, maar zelf zie ik heel veel scenario B gebeuren, want vrijwel alle grote stappen op het gebied van software development gaan over het "enablen" van "de business" om zo snel mogelijk van idee naar werkend product te komen, en daarbij zo min mogelijk "last" te hebben van die "vervelende techneuten met hun lastige vragen en negatieve kan-niet/ingewikkeld houding" (aka ICT behandelen als een "cost factory").

In essentie is het gebruiken van AI tools om van idee to werkend product te komen niet heel anders dan het inhuren/inzetten van een freelancer of software-team om jouw "specs" te realiseren. Alleen ga je er wel van uit dat als je diezelfde freelancer of dat team vraagt om bugs te fixen, of nieuwe features toe te voegen, of bestaande features te verbeteren, dat ze dan nog wel weten wat ze zelf gemaakt hebben, en hoe dat werkt. Als je elke keer bij een iteratie-ronde merkt dat er andere mensen op het team zitten die weer in de interne zelfgeschreven documentatie moeten gaan spitten om erachter te komen hoe dingen ook alweer in elkaar zaten, of die issue 1 oplossen, maar vervolgens 3 nieuwe bugs creeren, of die op eigen initiatief ineens dingen gaan veranderen of toevoegen omdat ze dat wel leuk leek, dan ben je denk ik snel klaar met zo'n freelancer/team. En het wordt helemaal lastig als ze het soms wel goed doen, maar dan ineens om onverklaarbare redenen niet.

Maar zo werken de huidige generatie LLM-based AI coding tools helaas nog wel. In principe zou je dus als "product owner" niets van de code hoeven te weten, en de AI gewoon net als een software developer moeten kunnen aansturen/voeden, en dan zou hij/zij/hen/het gewoon goed moeten kunnen doorontwikkelen. Maar daar zijn we dus nog niet. En daarom praat iedereen steeds over "you're doing it wrong". Maar als je als "PO" gewoon de goede specs doorgeeft moet je "team van AI coding minions" gewoon kunnen werken als menselijke software developers die enigszins stabiel en ervaren zijn.

Voor scenario A, software developers zelf, gelden dus wel andere criteria. Daar ben je uiteindelijk altijd verantwoordelijk voor de opgeleverde en in productie genomen code, en moet je dus begrijpen wat je precies "commit" of in ieder geval alle tests en andere zaken in place hebben om met vertrouwen je code aan collegas of klant te geven, en in het weekend en/of 's nachts je pager-duty te kunnen draaien.

Eens? Oneens?

[Ras]

Oneens. 1.0 versies opleveren maar geen aanpassingen en onderhoudbaarheid, dat is een probleem van een jaar geleden.

Als je de nieuwste topmodellen gebruikt met een goede orchestratie, dan krijg je ook goede doorontwikkeling. En dat wordt ook nog steeds beter. Bovendien, de rotzooi die een eerder dommer model heeft gemaakt kan het model van morgen heel netjes herschrijven. Bewaar je plannen en requirements goed.

[Reactie gewijzigd door Ras op 16 juli 2026 12:24]

[olafmol]

Interessant, wat gebruik jij allemaal?

Ik werk bv met Kilocode/Opencode en Claude Code als "orchestrators", frameworks als SpecKit voor specs, en gebruik de nieuwste modellen, alles gaat in MD files voor "memory", ik laat overal (unit)testen voor genereren, laat ook playwright-based browser-tests maken en draaien, indexeer de git repo met een Vector DB waar de agents bij kunnen om alle code snel te kunnen scannen), en toch gaat na verloop van tijd piepen en kraken. Ook met een 1M context window.

[Reactie gewijzigd door olafmol op 16 juli 2026 12:34]

[satya]

Van een GitHub training begrijp ik dat dat daar wat anders gaat. Voor elk stuk van de gewenste functionaliteit wordt een aparte md file uitgeschreven, of nog liever Toon vanwege de betere code en minder token gebruik, voor die functie. Als die niet gaat zoals je wilt dan het of verschrijf en dat stuk en wordt daarop de code aangepast.

Ik vind het ver gaan, want het hele proces wordt in eigen regie uitgewerkt, tot aan deployment op test, acceptatie en productie omgevingen aan toe als dat de wens is. Voor mij wel hocuspocus.

[olafmol]

Ik maak ook van alle features functionele specs in MD files, precies volgens "het boekje" en toch raakt ie na een paar iteraties (lees dagen) van het padje...Nu bouw ik geen "hello world" CRUD web app, mss is dat het verschil LOL

[Ras]

Ik heb de meeste ervaring met vscode met github co-pilot. Toegang tot concurrerende modellen die elkaar kunnen reviewen.

Elk project dat groter wordt gaat piepen en kraken. Dat gebeurd ook als er mensen aan werken. Opdracht geven tot een plan voor refactoring en na goedkeuring uit laten voeren misschien?

En afgaande op jouw verhaaltje, teveel irrelevante context kan ook tegenwerken.

[olafmol]

Het gaat niet zozeer om het groter worden, het gaat om het aantal iteraties. In mijn ervaring (en ook met elkaar evaluerende LLM's) gaat het na een paar dagen gewoon niet goed meer, omdat ondanks alle "guardrails" en "scaffolding" en "templates" etc.etc. de LLM gewoon dingen begint te vergeten of negeren of zelf te verzinnen. En ik weiger te geloven dat dit "user error" is, aangezien ik sinds de jaren negentig genoeg projecten zelf heb ontwikkeld of heb gemanaged, met meer en minder succes, dus voldoende scar-tissue ;P
Ik zie en hoor het ook om me heen, dus ik vrees dat ik niet alleen ben. Ik werk zowel met jonge hele slimme engineers, als ex-FAANG engineers die alles al een keer hebben meegemaakt op Silicon Valley niveau. Ik zeg niet dat LLM's prut zijn, ik merk alleen dat ze bij mij zich niet gedragen als enigszins capabele developers, maar als een soort losgeslagen bende met dementie...

[Reactie gewijzigd door olafmol op 16 juli 2026 14:51]

[bzuidgeest]

En dat is dan het punt waarop je het zelf oppakt en in orde maakt. De echte uitdaging. Niet al het grunt werk dat de aI voor je heeft gedaan.

code is 90% grunt werk. Leer je niets van.

[Funset]

Ik (ervaren ontwikkelaar) heb voor eigen gebruik een app laten opzetten door een multi-agent workflow die in het proces de code reviewt, onderhoudt, bijwerkt, en (ondertussen incidentiele) feature-requests van mij verwerkt. De code wordt bijgehouden in een private repo, het is allemaal goed leesbaar, gedocumenteerd. Zelf alleen de repo aangemaakt en dit draait nu iets meer dan een jaar.

Maar dan komen terug op het puntje ervaring. Ik heb zelf projecten gedraaid en heb kennis van het hele proces van werving tot deployment. Zonder die kennis en ervaring had ik zoiets nooit op kunnen zetten.

[Barsonax]

Precies dit, moet alleen nog even binnenkomen bij management 🤣

[JP1980]

Aan de andere kant schrijft AI al snel betere code dan onervaren ontwikkelaars. Het is natuurlijk niet zo dat mensen altijd perfecte code schrijven. Meer niet dan wel is mijn ervaring.

Als de ervaren ontwikkelaars de code review blijven doen dan blijft de kwaliteit hopelijk in orde. Al zie ook verschuiving naar AI code review daar zou ik persoonlijk nog terughoudend in willen zijn.

[leffert]

Het probleem is natuurlijk wel, dat als onervaren developers worden vervangen door AI, het erg lastig wordt om ervaren developers te krijgen.

[c-nan]

Als AI beter wordt dan ervaren developers heb je straks veel minder ervaren developers nodig.

[JP1980]

Misschien wel. Maar AI leert door voorbeeldcode. Als ervaren developers geen voorbeeldcode meer schrijft, kan AI zich dan nog ontwikkelen?

[WouterT13]

Ik denk niet dat AI alleen nog maar van voorbeeldcode leert. Ik ga er van uit dat er ook een soort van "reinforcement learning" wordt toegepast op code die de AI zelf schrijft en de feedback die gebruiker geeft. Als dat nu nog niet gebeurt, zal dat zeker in de nabije toekomst gebeuren.

[JP1980]

Absoluut dat is een reëel probleem.

[bzuidgeest]

f iets opbouwen met AI wat (initieel) werkt, maar totaal niet onderhoudbaar is.

Ofwel hetzelfde doen als mensen al generaties aan het doen zijn?? Genoeg shit code in de wereld.

[satoer]

Ik ben geen professioneel programmeur. Ik heb er wel een opleiding voor gedaan, maar nu is het vooral een hobby voor me. In mijn ervaring is juist het onderhouden van code met AI echt een godsgeschenk. Vaak heb ik na een paar jaar echt geen idee meer hoe ik iets destijds geprogrammeerd heb. Als ik dan iets wilde wijzigen in een oudere applicatie, script of plugin, moest ik er altijd weer helemaal induiken. Het was een heel proces om uit te pluizen hoe het ook alweer werkte, wat waar stond en hoe de afhankelijkheden in elkaar staken.

AI ziet dit allemaal in één snelle oogopslag en kan wijzigingen direct doorvoeren. Of het kan me haarfijn uitleggen hoe de structuur van de code in elkaar zit. In mijn ogen is AI echt fantastisch voor onderhoud, en binnenkort eigenlijk voor alles.

Het is mij wel duidelijk geworden: binnen een paar jaar wordt er echt geen regel code meer met de hand geschreven. In het begin controleren we de gegenereerde code nog wel, maar die stap wordt er op den duur vast ook uitbezuinigd. Die check laten we dan immers ook gewoon door AI doen. En als we er eenmaal op vertrouwen dat de output klopt, dan laten we AI gewoon rechtstreeks volledige machinecode kloppen. Die hele leesbare programmeerlaag ertussen is dan toch een onnodige extra stap als niemand de code nog controleert.

AI mag nu soms nog een steekje laten vallen, maar over het algemeen maakt het betere code dan ik zelf ooit zou kunnen produceren. En wat betreft dat onderhoud waar ik op reageerde: als ik zelf iets wil aanpassen, ben ik al snel geneigd om dat op te lossen met een snelle, simpele patch. Maar als ik AI gebruik, dwing ik het systeem om geen tijdelijke patch te maken, maar om hele lappen code netjes te herschrijven. Zo wordt de nieuwe optie tenminste echt goed geïntegreerd.

[Wolfos]

Dat dacht ik aanvankelijk ook, maar ik zit nu op ruim 80,000 regels code en kan het nog steeds prima volgen en zelf debuggen of aanpassingen maken.
Je bent er namelijk gewoon zelf bij. De AI agent kan programmeren maar je bent zelf de architect. En bestaande code structuren worden gewoon gekopiëerd.

Het zijn vooral de details waar soms poep in staat. Die zie je tijdens een review ook zelf over het hoofd. Maar details zijn zo opgelost.
Ook grotere architectuurfouten zijn nu makkelijker op te lossen dan voorheen. Technical debt bleef vroeger staan, is nu één prompt om het weg te werken.

[Reactie gewijzigd door Wolfos op 16 juli 2026 14:04]

[Memori]

Ik denk dat het grootste probleem is dat beginnende ontwikkelaars zich niet ontwikkelen dankzij AI. Je leert namelijk niet heel veel als je AI veel van je werk laat doen. Een ontwikkelaar met 10 jaar ervaring zonder AI dat zijn/haar kennis werft uit referenties en stackoverflow, boeken of blogs, of code uit andermans project, zal altijd een betere ontwikkelaar zijn dan een die alles met AI heeft gedaan.

[iAR]

Ik denk dat het misverstand is dan men denkt dat AI een programmeur kan vervangen. Je kunt overal nog zulke goede tools hebben maar daarmee wordt je geen goede kok of programmeur.

Dat gezegd hebbende, ik heb als onervaren programmeur ondertussen de site Rebrickable.com volledig na laten maken door Claude. Inclusief alle feature requests die op de site nog steeds open staan of afgewezen zijn. De site draait lokaal voor eigen gebruiken en is vele vele malen sneller dat Rebrickable. Dus ja, AI is wel praktisch.

[Webgnome]

Wat dit betreft helemaal eens met Torvalds. Het is al lang niet meer zo dat AI alleen maar rommelcode genereerd. Het staat of valt met de context die je het mee geeft en als die goed genoeg is dan komt er werkbare code uit.
Neemt niet weg dat je als programmeur niet alleen maar moet vertrouwen op dat het wel goed zal zijn. Je dient altijd nog zelf de verantwoordelijkheid te dragen voor dat wat je commit. En daar zit het echte probleem. Ik merk het bij mij zelf, als rookie met 20 jaar ervaring, ook.

Door AI is het makkelijk om code te genereren maar juist door het zelf maken, bedenken, uitwerken, wijzigen en updaten krijg je feeling en onthoud je gewoon wat je hebt gedaan. En dus ben je baas over die code. Dat proces word deels verstoord door AI. Daar zit dus de echte uitdaging.

M.a.w. Ja, "een tool, net als andere tools die we gebruiken. "En het is overduidelijk een nuttige tool."

[HansvDr]

Er zijn nu ook genoege opdrachten die ik volledig met AI doe. Vooral de kleine tools. Razendsnel programmeren. Klant blij want snel klaar, ik blij want meer verdienen in minder tijd.

[Webgnome]

Ja dat doet iedereen lijkt mij. Echter moeten 'we' uitkijken dat het hier niet hetzelfde word als 'vroeger' dat je een PoC op productie zet waar je vervolgens nog jaren 'plezier' van hebt.

[cricque]

Zelfs bij kleine projecten is de code dikwijls ondermaats. En als het wat groter is, dan werkt het voor geen meter meer, zeker niet als je al veel extra dingen gebruikt zoals caching bijvoorbeeld, of dingen in het geheugen laden om sneller resultaten te heben, en zo zijn er nog een hele hoop dingen

Ik probeer al 2 jaar een "formulier" te maken met een paar extra dingen in, om de 3 maand probeer ik het opnieuw, en het is beter geworden, maar de tijd die ik er moet insteken is het nog altijd niet waard, omdat ik het zelf sneller (& beter kan)

Zelfs dikwijls een lijntje autocomplete zit er naast, al minder dan vroeger.
Gebruik ik het ... zeker, bespaar ik er tijd mee ... heel soms wel

Waar ik het voornamelijk voor gebruik is even een paar dingen in de UI proberen, dat het rommel is, maakt niet uit, maar zo kan ik een paar dingen testen. En dat is wel tamelijk snel, maar productie code is het verre van.

[hakariki]

Wat is jouw toolstack dat je zulke slechte resultaten haalt? Ik heb hele andere ervaringen. Het is meer dat ik zelf vergeet wat ik ook alweer gevraagd heb dan dat de AI zaken verkeerd oplevert. Ik gebruik Paseo met ChatGPT 5.6 sol op Medium.

[gfhoihoi72]

Dan gebruik je geen SOTA modellen lijkt me. Ik heb met veel ondersteuning van AI (Claude Code) een webapp gebouwd waarmee gebruikers gesynchroniseerd tussen verschillende apparaten video's/muziek af kunnen spelen. Bevat ondertussen ook een chat, voicechat, p2p streamen van lokale files etc etc.

Ben hier een jaar geleden mee begonnen met de modellen die toen beschikbaar waren en ondertussen is dat flink uitgegroeid dankzij de steeds slimmere modellen. Ondertussen tikt het de 20.000 gebruikers per maand aan en verdien ik er geld mee. Dus als een formuliertje al niet lukt doe je denk ik iets verkeerd

[c-nan]

Even je prompt skills bijwerken, want als het al 2 jaar niet lukt doe je iets flink fout. AI is tegenwoordig zo goed, ik heb er al heel wat mee ontwikkeld.

[cricque]

Lol, als het meer tijd kost om alles uit te schrijven dan om het zelf te maken.

Note: ik programmeer ondertussen al meer dan 30 jaar en ik ben zeker geen 10x programmeur ofzo, maar ik kan wel snel dingen bouwen

[Rhizix]

Sorry, maar dit zijn de meest basic dingen waar eender welk state of the art model absoluut geen probleem mee heeft...

Dus ofwel gebruik je oude of zeer slechte models, of doe je iets mis vrees ik

[cricque]

Nee ik gebruik dus allerhande out of the box dingen die niet conventioneel zijn

[punishedbrains]

Dat is zeker leuk, maar je moet wel opletten dat je niet allerhande code gaat genereren die alleen de AI nog snapt. Dat is namelijk op de lange termijn een issue natuurlijk.

[Glashelder]

Dat is met menselijke developers echt niet zo anders. Naar gelang een codebase groeit en er developers vertrekken is er zat code in de gemiddelde codebase die niemand nog snapt of in scope heeft.

Daarom vind ik dit een invalide argument.

[croc]

Aan AI kan je nog snel en efficient vragen stellen, aan iemand die vertrokken is niet meer. Maakt het punt nog meer invalide.

[ZinloosGeweldig]

Sterker nog, die code van vertrokken developers die niemand meer snapt, kan de AI waarschijnlijk wel begrijpen, dus AI is in veel gevallen juist een oplossing voor dat probleem.

[eborn]

Code reviewen is vele malen intensiever dan code schrijven. Dat is het grote probleem van AI. Het volume gaat omhoog, maar daarmee de review last ook. Er komt een moment dat developers dat niet meer gaan doen (als we daar al niet zijn) en dan verdwijnt inderdaad de feeling met de code.

Los van het feit dat AI er bij veel bedrijven ook voor zorgt dat er veel meer code ontstaat dan dat DevOps kan beheren. Greenfield iets neerknallen is de kunst niet. Zorgen dat zo'n project binnen de organisatie gedragen wordt en dat iemand eigenaar is van zo'n codebase. Of jet moet er weer automatische AI agents op zetten die 'blind' updates gaan doorvoeren als het nodig is.

[Webgnome]

Ja helemaal mee eens. Er kan meer code gegenereerd worden die ook weer gereviewed moet worden en uiteindelijk gebruik je daar dan ook weer copilot (oid) voor en dat zorgt er dan weer voor dat je ook weer daar feeling kwijt raakt

" Je dient altijd nog zelf de verantwoordelijkheid te dragen voor dat wat je commit. "

[Reactie gewijzigd door Webgnome op 16 juli 2026 11:23]

[Wolfos]

Ik review al lang niet meer. Ik doe een functionele check. En als ik later tegen een probleem aanloop ga ik debuggen en vind ik vanzelf de poep wel. Met een code review kijk je daar toch overheen.

[Seth_Chaos]

Daar ligt ook een struikelblok voor de acceptatie van AI. Jij zit nog steeds in de uitvoering, en niet zo zeer in de regie. Je leeft nog met de gedachte dat jij tot in de details moet weten hoe de code geschreven is, en wat het doet. De realiteit is dat, dat alleen voor jou waarde heeft. AI schrijft betere documentatie. Een beter implementatie plan. Een betere runbook. AI schrijft de code beter. AI controleert de code beter. AI security hardend de code beter. En AI optimaliseert de code beter.

Ze hebben geen programmeur nodig die het werk van een AI controleert. Ze hebben een specialist nodig die AI beter aanstuurt, en doorontwikkeld.

In een groot project programmeer jij honderden zo niet duizenden uren aan een project. En ben je honderden uren kwijt aan het nalopen van die source. AI bouwt hetzelfde in een week. En loopt de source na in minuten geen uren.

[Reactie gewijzigd door Seth_Chaos op 16 juli 2026 12:00]

[JvpCpp]

Met veel uitsparken ben ik het oneens. En de experts en literatuur over dit onderwerp zijn het met mij eens.

AI schrijft code niet beter. Verre van dat. Gegenereerde code is vaak slecht van kwaliteit en is vaak erg slecht geoptimaliseerd op resource gebruik en performance. De gegenereerde code is goed starting point, maar nooit het eind resultaat. Waarschijnlijk omdat de LLM vaak getraint is met ocde van matige tot slechte kwaliteit.

Weet niet over welke documentatie je het hebt. Design, requirement specifications, user documentation of documentation van de code. Dat laatste is een code smell. AI zou nooit documentie in source code moeten genereren. Documentatie/comment is code is alleen nodig in uitzonderingsgevallen, wanneer de code zo geschreven moet worden, dat het moeilijk te begrijpen is.

Daarbij is AI nog heel slecht in het maken van een goed design.

Ik weet niet wat je een groot project noemt. Ik werk bijvoorbeeld aan een project/product waar al voor meer dan 26 jaar voor een development team van 8 developer aan development werk in zit, en nog steeds verder ontwikkeld wordt. Dus dat is veel meer dan duizenden uren programmeren en honderden uren code review.

Juist omdat je als mens verantwoordelijk blijft voor wat AI heeft gegenereerd en in het eindproduct terecht komt, is human in the loop essential en zal essential blijven. Om de kwaliteit van de code en het eindproduct te kunnen waarborgen. Dat kan alleen wanneer de code is gereviewed net als de testen. Juist om te kunnen vaststellen dat het doet wat het moet doen, de code te begrijpen en onderhoudbaar is, design zodanig is dat er geen dependencies inzitten die je niet zou willen.

AI kan alles inderdaad erg versnellen. Ik maak daar ook gebruik van. Maar omdat je als programmeur nog steeds verantwoordelijk blijft voor de code (Of die nu door AI gegenereerd is of niet), moet de code wel gereviewed zijn.

[Seth_Chaos]

Dat hangt natuurlijk sterk af van welke literatuur jij leest, en naar welke experts jij luistert. Nog los van het gegeven dat er geen actuele literatuur van is. Zaken als afhankelijkheden en onderhoudbaarheid zit al in je design specs, nog voor er een regel geschreven is.

[JvpCpp]

Kun je dan voorbeelden geven wat er dan zoal in een desgn spec zou moeten staan?
Ook wat betreft onderhoudbaarheid?

Daarbij beschrijft/domcumenteert de code het design. Zeker wanneer je Agile werkt. Over het algemeen heb je daar alleen de user stories of enabler stories met de acceptance criteria die metname de requirements bepalen.

Het is de programmeur die het design maakt met zijn code. Dat is dus wat duidelijk moet worden gereviewed. Ook de onderhoudbaarheid van de code. Zoals, is het goed leesbaar en goed te begrijpen, zijn de namen gebruikt in de code correct. Het juiste design is ook van belang voor de onderhoudbaarheid. Een verkeerd design kan dependencies introduceren die je niet wilt tussen bijvoorbeeld diverse classes. Maar kan ook beperkingen opleggen voor toekomstige uitbreidingen.

1 van de vele voorbeelden van literatuur waarin dit haarfijn wordt uitgelegd is "Beyond Vibe Coding" van Addy Asmani. Maar dat is maar 1 voorbeeld. Er is namelijk wel actuele literatuur, aangezien daarin al rekening gehouden wordt met de snelle onwikkeling op AI gebied. Goede literatuur kijkt juist niet alleen naar het heden, maar houdt ook rekening met wat er in de toekomst mogelijk is.

Zelf ondervind ik dagelijks dat AI verre van goede code genereerd. Dat is in het nu. Ik gebruik het als een starting point, maar nooit als iets dat gelijk klaar is. Al doet het vaak wel wat het moet doen, functioneel. Het design van de code is vaak slecht. Net als de efficientie (resource gebruik/performance). Ook vaak duplicatie, dat eenvoudig kan worden geredureed. Ook zitten er vaak bad practices in de code, wat je niet zou verwachten van een LLM die juist de focus op coding heeft.

Maar dat zijn mijn ervaringen van dit moment.

[hakariki]

...juist door het zelf maken, bedenken, uitwerken, wijzigen en updaten krijg je feeling en onthoud je gewoon wat je hebt gedaan.

Daar sla je de spijker op de kop. Ik merk het de laatste tijd bij mij zelf. Hoe vaak heb ik niet tijdens een project dat ik denk. Eh, wat had ik ook al weer laten maken. In het begin dacht ik echt dat ik dommer aan het worden was. Maar het is natuurlijk gewoon zo dat ik er niet meer dezelfde moeite insteek. Maar god, wat een verademing om gewoon even dingen te kunnen proberen die anders drie dagen werk zijn. Even CUDA proberen? Geen probleem, binnen 7 minuten heb je het. In Rust, zonder 1 compilatie fout. Wow...

[Luca2112]

Persoonlijk laat ik Codex een hoop bouwen met de expliciete opdracht om bij elke sectie een comment te plaatsen met uitleg.
Vervolgens lees ik de code door en check ik alles per sectie.

Tuurlijk, het zal niet altijd 100% efficiente code zijn, maar het is voor mijn doeleinden veel belangrijker dat het werkt en op de juiste manier beveiligd is.
De beveiliging controleer ik dus met de hand en laat ik met regelmaat pen-testen.
De werking test ik door de tool te gebruiken.

Dat is ook de reden dat ik Codex expliciet vertel om bepaalde programmeertalen te gebruiken, of zelfs specifieke technieken binnen een programmeertaal. Dan snap ik het zelf ook nog

Verder is Codex er tegenwoordig aardig goed in om de code die ik met de hand geschreven heb te interpreteren en de manier van bouwen over te nemen.

[limaad2]

Tja, niet meer dan logisch. Helemaal als je refereert naar zijn eerdere mening uit 2024!

In 2024 was hij bijvoorbeeld nog sceptisch over AI

Er was toen natuurlijk ook meer dan genoeg reden om zeer sceptisch te zijn over AI.

[Steven Klink]

Er is nu ook heel veel reden om nog meer sceptisch te zijn en te blijven...

[limaad2]

Dat klopt natuurlijk. In 2024 was het echter eerder dat er ontzettend veel hallucinaties waren, en was het minder specialistisch op vlak van code ontwikkeling. Dat is nu natuurlijk wel anders!

Nu weet je dat de code die eruit komt, waarschijnlijk wel zal functioneren, en is eerder de vraag of je prompt goed genoeg was, de agent-files concreet genoeg waren en hoe je controleproces in elkaar steekt van AI output. En, is het de kunst om code beknopt te houden.. Helaas heeft AI er een handje van om ook meer te schrijven dan strikt noodzakelijk.

[Steven Klink]

Als je al te lang na moet denken over een goede prompt kun je die tijd en energie beter besteden aan je eigen kennis en kunde over wat je aflevert.

[olafmol]

Dit is wel een dingetje vind ik. Als er iemand over het algemeen extreem sceptisch is, dan is Linus het wel. Dat hij (voorzichtig) positief is, zegt best wat.

BTW, ik zou dit niet direct als een "uitgebreide e-mail" classificeren ;P

[TijsZonderH]

Hoe wel? Ik twijfel eigenlijk altijd aan hoe ik die mailinglists moet noemen...

[olafmol]

Het gaat mij vooral om "uitgebreid". Ik dacht een heel betoog te gaan lezen, maar het is gewoon een compacte reactie/post. Doet niets af aan de inhoud natuurlijk :)

[Mr-D.]

ik zal hier even een stukje delen wat op Linkedin staat.

AI bouwt snel. Maar snel ≠ veilig.

Laatst was ik op een evenement waar ze een webapplicatie hadden opgezet. Mooie interface, goed idee, en je merkte dat er enthousiasme achter zat.

Maar als Full-stack Engineer kijk ik al snel even onder de motorkap. En daar schrok ik toch van.

Twee dingen vielen direct op:
- Het admin-wachtwoord stond hardcoded in de client-side JavaScript zichtbaar voor iedereen die op "broncode bekijken" klikt
- Alle persoonsgegevens van deelnemers (naam, e-mail, telefoonnummer) waren op te halen via een volledig onbeveiligde publieke API

Ik kon zonder enige hacking bij de gegevens van alle andere deelnemers. Namen, e-mailadressen, telefoonnummers.

Dit is geen verwijt aan de makers. Ze hebben iets gebouwd met de tools die ze hadden, en dat verdient respect. Maar het illustreert een blinde vlek die ik steeds vaker zie:

AI-tools bouwen wat je vraagt. En als je niet expliciet vraagt om veiligheid, krijg je het niet altijd. De verantwoordelijkheid ligt dus mede bij de gebruiker niet alleen bij de tool.

De risico's zijn concreet: datalekken, GDPR-overtredingen, manipulatie van applicatielogica.

Als een leek AI inzetten om snel iets te bouwen? Absoluut doen. Maar zodra er persoonsgegevens in het spel zijn, is een technische blik voor livegang geen luxe het is een verplichting.

Eén simpele vraag die je AI kunt stellen vóór livegang: "Welke beveiligingsrisico's zitten er in deze code?" het antwoord zal je verrassen.

https://tweakers.net/foto...Nktr5wLJw09mXa2tJNTeK.jpg
Bron:
https://www.linkedin.com/...vity:7475981498391670784/

[Reactie gewijzigd door Mr-D. op 16 juli 2026 12:08]

[Pietopdeheuvel]

AI bouwt snel. Maar snel ≠ veilig.

Klopt, is ook mijn vrees, maaaar: Aan de andere kant, met AI worden op het moment reteveel security problemen gevonden in allerlei Applicaties en besturingssystem.

[Steven Klink]

Dit is geen verwijt aan de makers. Ze hebben iets gebouwd met de tools die ze hadden, en dat verdient respect.

Wellicht moeten de menselijke halicunatoren hier ook maar eens mee stoppen; je kunt echt geen respect hebben voor dit soort lui.

[Pietopdeheuvel]

IA tools zijn prachtig, maar ook een bedreiging voor open source, omdat er zoveel code gegenereerd kan worden die niet meer te controleren is, gewoonweg en alleen al, omdat het te veel is.

Met AI-gegenereerde code begint dat model te kraken.

In plaats van het zelf code schrijven, beschrijven ze nu vaak alleen nog  wat te bereiken is. Een AI-model kotst vervolgens in seconden duizenden regels code uit. Het probleem is niet dat AI code schrijft, maar dat niemand meer echt begrijpt wat er precies gegenereerd is, en het is zoveel dat het ondoenbaar wordt te controleren

 Code is dan wel openbaar zijn, maar als een pull request uit duizenden AI-gegenereerde regels bestaat die niemand volledig kan doorgronde.

Dat raakt ook een van de sterkste beveiligingsmechanismen van open source: "veel ogen zien meer". Dat werkt alleen als mensen daadwerkelijk tijd en capaciteit hebben om code te beoordelen. Wanneer AI complexe of onveilige logica introduceert, of zelfs een achterdeur verstopt, is het vinden daarvan een stuk lastiger. Nog een AI inzetten om de eerste AI te controleren lost dat probleem niet echt op; dan vervang je menselijke controle door vertrouwen op een tweede black box.

En dan nog: Denk aan vervuilde trainingsdata, gemanipuleerde modeluitvoer of code waarvan niemand nog weet waar die oorspronkelijk vandaan komt.

Ook de schaal verandert. Eén ontwikkelaar kan tegenwoordig in een weekend meer code produceren dan een community realistisch kan reviewen. Wat nu? code accepteren die nauwelijks gecontroleerd is, of ontwikkeling afremmen?

Natuurlijk speelt dit probleem ook bij commerciële software. Het verschil is dat bedrijven kunnen terugvallen op contracten, aansprakelijkheid en interne processen. Open source vertrouwt juist op verifieerbaarheid.

AI maakt ontwikkelen sneller, toegankelijker en goedkoper. Maar als de hoeveelheid gegenereerde code harder groeit dan het vermogen van mensen om die code te begrijpen, Dan raakt het de conceptem waarop open source gebouwd is.

[adje123]

Met alle respect, maar je moet toch wel wereldvreemd zijn om niet eerder door te hebben gehad dat AI een prima “companion” is?
AI is een teamlid net zoals een stagiaire een team lid is. Je moet alles even checken.

[bzuidgeest]

Heb je de comments recent op tweakers gelezen? Er is echt een flinke anti AI crowd die het nergens voor wil gebruiken om verschillende redenen. Sommige denken dat het alleen maar code diefstal is (alsof mensen niet leren van de code van anderen), sommigen zijn bang voor hun baan. Of denken dat het alleen maar slop kan maken. Vele hebben duidelijk nooit een high end LLM gebruikt.

Allemaal zijn ze gewoon onwetend en of onredelijk. Maar ze zijn er zat.

Wat mij betreft heeft Torvalds absoluut gelijk.

Edit: zorgen over milleu vind ik terecht, maar die groep wil typisch wel praten over AI op zonne-energie of zo. Vind AI niet erg, maar heeft terechte vragen over de impact. Dat is een andere groep en een heel belangrijke vraag.

[Reactie gewijzigd door bzuidgeest op 16 juli 2026 11:33]

[PureTryOut]

Dankjewel dat je mij onwetend en/of onredelijk noemt doordat ik AI niet gebruik vanwege de gigantische milieu en klimaatimpact die het heeft. Niet één van de argumenten die je noemde trouwens, maar een zéér relevante en zéér onderbelichte.

Werkt totaal niet polariserend zo.

[bzuidgeest]

Nee, dat argument noemde ik daar niet maar later wel in een reactie aan zepman. Het is een terechte vraag, maar die groep klaagt typisch niet als ik zeg AI van mijn eigen zonneenergie te draaien. Ze hebben terechte vragen maar kunnen in oplossingen denken als ik hun zorg meeneem. Dus die vallen uit die selectie. Ik heb daarvoor een edit gedaan in mijn originele reactie

[Reactie gewijzigd door bzuidgeest op 16 juli 2026 11:34]

[PureTryOut]

Dan is er natuurlijk ook nog het flinke water gebruik, ook in gebieden waar toch al een water tekort is, en de delving (en transport) van de edel materialen voor die gigantische hoeveelheid hardware die het nodig heeft. Maar ok, punt is duidelijk denk ik

[bzuidgeest]

Water en mineraaldelving valt toch onder de milleuvraag? In ieder geval bij mij.

En de eerste auto's waren super inefficient en vervuilend in vergelijking met heden ten dagen. Echter dat hield de ontwikkeling niet tegen en we gingen niet terug naar het paard. Het paard had zijn eigen issues. Met doorontwikkeling werd de auto steeds beter. Ik verwacht dat AI op den duur ook beter word. Er gaat bakken met geld in efficientere chips. Er gaat bakken met geld in compressie algoritmes en er worden bijna wekelijks significante verbeteringen aangebracht in dat soort dingen. We kunnen nu al meer met dezelfde hardware.

De vraag is wat mij betreft of we het niet tot dingen met bewezen nut moeten beperken. Dus niet het genereren van kattenvideos en fake news en liedjes. Maar vooral zakelijk gebruik. Het genereren van code omdat nut daar bewezen is. Of onderzoek e.d. Dat zou de druk van de ketel afhalen.

[readefries]

Je zou als ervarrn onwikkelaar AI ook kunnen gebruiken voor green-ops enzo besparen in dagelijks gebruik. Waavoor de kernel een hele goede plek zou kunnen zijn om te beaparen.

Er is inderdaad een millieu-impact (en die wil ik niet marginaliseren), maar daarnaar wijzen voelt een beetje als wijzen naar het douchen voor waterbesparing: is dat het beste watje kan doen voor 't millieu?

[PureTryOut]

Het beste? Het is één van de vele dingen die je kunt doen. Verder heb ik geen auto, vlieg nooit, eet vegetarisch (vrijwel vegan), heb een wekeliklse biologische groentepakket van een lokale boer, let ook zeker op water gebruik bij douchen, laat producten repareren zover mogelijk i.p.v. het maar te vervangen, etc. Er zijn een hele hoop dingen die je kunt doen en van AI afblijven is daar een nuttige in.

En geen zorgen, ik ben prima tevreden met mijn leven 😉 Ik kan er met mijn hoofd niet bij wat mensen er moeilijk aan vinden.

[adje123]

Klimaatimpact is voor politiek alleen van toepassing als het om de plebs gaat. Het is niet van toepassing op de mensen die aangesloten zijn bij lobby clubs. Vandaar dat ik het gehele “klimaatprobleem” niet serieus neem en dagelijks AI gebruik voor mijn werk en mijn socials.

[The Zep Man]

Allemaal zijn ze gewoon onwetend en of onredelijk. Maar ze zijn er zat.

Dat is totaal geen manier om een groep over één kam te scheren en zal echt niet polariserend werken.

[bzuidgeest]

Generalisaties zijn gewoon een ding in het leven. En ik heb geen bewijs voor iets anders gezien. Ik geeft ook twee mogelijkheden en niet allebei hoeven tegelijk waar te zijn, getuige het gebruik van OF. Er zitten wellicht ook mensen die zich zorgen maken over het milleu en zo. Een terechte zorg, maar die mensen zijn niet noodzakelijk anti AI en willen best praten erover. Of vinden het niet erg als je AI draait van je zonnepanelen.

Ik heb het echt over de groep die er totaal niet over wil praten. Die groep kan ik niet verder polariseren. Ze ontkennen gewoon de werkelijkheid door dingen te roepen die nergens op slaan. Alle feiten te negeren die ze niet passen.

[The Zep Man]

Ik heb het echt over de groep die er totaal niet over wil praten. Die groep kan ik niet verder polariseren. Ze ontkennen gewoon de werkelijkheid door dingen te roepen die nergens op slaan. Alle feiten te negeren die ze niet passen.

Gebaseerd op wat je schrijft, lijkt het erop dat jij vindt over iedereen die zich zorgen maakt over het probleem dat AI fair use ver voorbij gaat, die voor hun baan vrezen, die ervaring hebben met brak werk dat beginnende "programmeurs" opleveren met AI, of degenen die geen ervaring met high-end LLM's hebben, dat die allemaal er niet over willen praten.

Volgens mij praten ze er wel over (anders kon je niet weten wat je schrijft), maar worden ze niet overtuigd van het tegendeel.

[Reactie gewijzigd door The Zep Man op 16 juli 2026 11:24]

[Webgnome]

Heb je de comments recent op tweakers gelezen? Er is echt een flinke anti AI crowd die het nergens voor wil gebruiken om verschillende redenen. Sommige denken dat het alleen maar code diefstal is (alsof mensen niet leren van de code van anderen), sommigen zijn bang voor hun baan. Of denken dat het alleen maar slop kan maken. Vele hebben duidelijk nooit een high end LLM gebruikt.

Allemaal zijn ze gewoon onwetend en of onredelijk. Maar ze zijn er zat.

Wat mij betreft heeft Torvalds absoluut gelijk.

en dat is een terechte zorg!

[bzuidgeest]

Daar is tot nu toe niets van gebleken. Te veel mensen zijn er nodig om het werk van AI na te lopen en te veel mensen met kennis moeten dat doen. Bedrijven die eerst dachten alles met LLM's te kunnen doen zijn druk bezig met mensen terug aannemen. Zie klarna bijvoorbeeld.

[Webgnome]

Door je eigen reactie bevestig je mijn punt. Mensen worden er door AI uitgegooid en er worden ook weer mensen aangenomen omdat het niet helemaal perfect is. Dat zijn niet perse dezelfde mensen..

[bzuidgeest]

Nee, eigenlijk niet. met nieuwe technologies is er altijd grote verandering. Maar er zijn tal van oorzaken waardoor je een baan kan verliezen. Je moet je daar je hele leven rekening mee houden. En soms opnieuw solliciteren. Niet altijd leuk, maar niets bijzonders. En die bedrijven waarderen hun medewerkers beter, betalen wellicht beter om ze terug te krijgen. Als je "nodig" bent heb je een betere onderhandel positie.

[Reactie gewijzigd door bzuidgeest op 16 juli 2026 11:40]

[Webgnome]

Ja dus wel. Ja er zijn door nieuwe tech altijd veranderingen, ja er zijn altijd mensen die hun baan verliezen door diverse redenen. Dat doet niets af aan de hype die AI nu is binnen bedrijven.

Mensen worden, en voelen, zich bedreigd door AI. Hoe je daar mee om gaat maakt het verschil zoals je zelf zegt. Dat het van alle tijden is doet daar niets aan af. Nu is het gewoon AI.

[bzuidgeest]

Tja ik denk van niet. Ik denk dat mensen zich dus niet bedreigd moeten voelen. Als mensen geschiedenis beter begrepen zou het niet zo een probleem zijn.

[theduke1989]

Ik denk dat je vooral dommer er van wordt. De ouderen die de code hebben uitgevonden, wat hedendaags gebruikt wordt, is later door de mensheid verloren/vergeten.

Als je zelf niks meer moet doen, kan je beter bij een schoonmaak bedrijf zitten, je bent niet meer nodig!

Dat onzin van 1 maand werk in slechts 20 dagen, tja daarvoor wordt je betaald etc. anders kan je net zo goed iets anders zoeken!

[bzuidgeest]

Dommer? Dat excuus kwam ook met de computer, de rekenmachine, het automatische weefgetouw, draaibank, mixer etc etc en zo ongeveer elk ding dat menselijk handelen minder maakte. We kunnen wellicht minder goed rekenen, maar we kunnen geavaceerdere berekeningen doen die nieuwe dingen mogelijk maakte.

We hebben het allemaal overleeft. Want mensen passen zich aan (of kunnen dat tenminste) aan hun omgeving. We maken glas met machines, maar er zijn nog steeds glas in lood makers. We maken de kleinste transistors, maar nog steeds maken mensen vacuum buizen. We kunnen automatisch weven, maar er bestaan nog steeds wevers.

Niets van wat we ooit hadden of konden is verloren gegaan. Er zijn altijd mensen die het in ere houden. En die kunnen daar weer goed mee verdienen in sommige gevallen. En anders is het een hobby.

[Reactie gewijzigd door bzuidgeest op 16 juli 2026 12:17]

[theduke1989]

We kunnen wellicht minder goed rekenen, maar we kunnen geavaceerdere berekeningen doen die nieuwe dingen mogelijk maakte.

Nee, dat kunnen we niet. Wat je nu zegt, klopt niet. Vroeger konden we dat wel – de mensen die algebra en al die dingen hebben uitgevonden. Maar nu wordt dat allemaal voor ons gedaan.

Je ziet nu al dat kinderen moeite hebben met schrijven, lezen, rekenen, enzovoort, simpelweg omdat ze niets meer zelf doen. Nu wordt alles gewoon voor je gedaan, waardoor de mensheid echt dom wordt! Dit is een feit.

Het feit dat jij dit allemaal op school deed, was in een andere tijd.

[bzuidgeest]

Dus jij denkt dat we al die gevanceerde berekeningen in material sciences en bilogie als protien folding allemaal hadden kunnen doen zonder computers?

Nee, absoluut niet. Wij doen de basis en de computer doet het werk. Zodat niet voor 1 berekening een mensenleven nodig is. De computer laat ons nadenken over dingen waar we nooit over konden nadenken zonder dat ding.

[SPee]

Helaas dalen leerprestaties van de nieuwe generatie. Voor het eerst sinds decennia.
Dus dommer? Ja, helaas wel.

[bzuidgeest]

Maar dat was ook al voor AI. En het heeft meer te maken met een in de watten leggen cultuur van leerlingen en iedereen een mooie titel geven dan AI. Je mag tegenwoordig niet gewoon meer een vak leren.

[goarilla]

Ik ga akkoord met je algemene conclusie: industriele innovaties leiden niet
zozeer tot cogntieve achteruitgang. Maar het is niet omdat sommige nog
een oude hobby beheren dat die kennis op hetzelfde niveau is van vroeger.
En dat we nu niet met problemen zitten.

De enorme keldering van de resultaten van de schoolgaande jeugd op de PISA testen
sinds ~2008 correleren toch wel heel sterk met de "digitalisering van het onderwijs" (digisprong/smartschool, etc ...) ?

En in mijn opinie lezen, schrijven, rekenen en kritisch denken leer je toch het best
in een minimalistische omgeving waar afleiding heel moeilijk is. Zeker als
opgroeiende jongen in een middelbare school waar je, althans ik alvast destijds zo
snel mogelijk vanaf wilde geraken. En nu zetten we ze allemaal achter een afleidingsmachine met tools waarmee ze er nog vlugger vanaf kunnen zijn.

[bzuidgeest]

Zoals je aangeeft zijn die problemen van lang voor AI. Ik denk niet dat het met digitaal te maken heeft. Correlation is not causation.

Ik denk dat het meer te maken heeft met het in de watten leggen van leerlingen, te veel touchy feely en het idee van een vak leren was voor domme mensen die niets konden. Iedereen moet ergens een dokter in zijn. Getuige rommel als vrijetijdsstudies.

Sommige dingen kunnen gewoon niet zonder computer. Je kan best kritisch denken over protien folding en kernenergie processen. Als je een antwoord wil in je leven heb je toch een computer nodig voor de berekening. Zolang je de berekening maar snapt.

Ik denk dat voor kritisch denken niet het middel van belang is. Computer of pen, ik denk dat de manier van lesgeven van belang is. Veel van de docenten die ik gezien heb, zijn ondanks de beste bedoelingen soms. Niet competent genoeg om les te geven anders dan boekjes doorlopen.

Vroeger gaven de groten les en demo's Faraday, Einstein, Cury, Feynmann. Nu zijn dat soort talenten wanneer ze er zijn alleen maar bij grote bedrijven bezig.

Dat is wat onze leerprestaties afbreekt.

Ik kan zo een handvol ouder aanwijzen met hun handen in het haar omdat hun kinder enthousiast leren en al lang door het boek heen zijn terwijl klasgenoten nog niet halverwege zijn. Die willen doen en leren over techniek en over wiskunde en wat al niet.

De scholen hebben er niets voor, die kinder vervelen zich te pletter. Scholen kunnen alleen klasikaal een boekje doorwerken en de kinderen zijn daar de dupe van.

Wat leerstof betreft kunnen die kinderen vaak makkelijk een klas inhalen, vooral als ze het leuk vinden daar voor te werken. Maar zelfs als de school dat wil toestaan. Dan komen ze in een klas waar ze sociaal niet altijd aan toe zijn. Dat is gewoon dom. Ze moeten harder worden aangemoedigd terwijl de "knolraap" klasgenoten in hun eigen tempo hun ding doen. Gegroepeerd bij leeftijd en sociale ontwikkeling, niet kennis opbouwafremmen in eenheidsworst.

[Reactie gewijzigd door bzuidgeest op 16 juli 2026 14:24]

[CharlesND]

Allemaal zijn ze gewoon onwetend en of onredelijk. Maar ze zijn er zat.

Briljant argument. "Allemaal" die anders over AI denken dan ik zijn onwetend of onredelijk. Aan hun argumenten en ideeën hoeven wij wel verstandige, wel alles wetende en wel redelijke mensen dus geen aandacht te besteden.

[Scribe]

Het zal vooral gebruikt worden om bugs/vulnerabilities te scannen waarschijnlijk. De kernel is nou eenmaal zo groot, het is gewoon onmogelijk voor mensen om fatsoenlijk aandacht te geven aan elke regel code om mogelijke fouten te vinden

[overhyped]

Goed dat hij dit zo duidelijk uitspreekt. Dat er flinke problemen aan AI kleven mag duidelijk zijn, maar het nut is ook evident. Ik zie ‘in de community’ ook nog veel mensen die totaal anti zijn. Dan zit je echt op hetzelfde niveau als eind jaren 90 zeggen dat dat internet niet zo belangrijk zal worden.