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 (204)

[eric.1]

And no, AI isn't perfect. But Christ, anybody who points to the
problems at AI had better be looking in the mirror and pointing at
themselves at the same time.

Because it's not like natural intelligence is always all that great either.

Het lijkt me duidelijk dat AI een degelijke tool is (geworden). En ik snap best dat Linus' mening serieus wordt genomen wereldwijd. Maar dit punt is wel een beetje treurig te noemen...

Volgens mij weet iedereen met een degelijke opleiding dat er gaten in ons kennis zitten. En daar zijn we ons van bewust, wat ons over het algemeen wat terughoudender maakt wanneer we rond die gaten werken - want dan zijn we niet geheel zeker. AI is altijd 'zeker' van zijn zaak, als in bijzonder zelfverzekerd in zaken waar veel bij elkaar is geschraapt om tot een antwoord te komen.

En dat is best een verschil. Zeker als mensen van de daken schreeuwen dat AI zo geweldig is en AI ontwikkelaars vervangt. Laten we het, zoals Linus het zegt, gewoon als tool beschouwen.

En laten we alsjeblieft kritisch zijn op de tools die de wereld in worden geslingerd. Zeker tools die een serieuze en significante impact hebben op werkgelegenheid, economie, klimaat, enz. En ja, dat staat los van onze beperkte natuurlijke intelligentie.

[walteij]

AI is helemaal niet altijd zeker van zijn zaak, tenminste, niet als je de juiste context mee levert aan de vragen die je aan je AI stelt. Als ik aangeef dat ik wil dat het antwoord wordt voorzien van bronvermeldingen en een geschat percentage hoe zeker AI is van zijn antwoord (en als dit minder dan 70% is, ik wil dat hij verder gaat denken) krijg ik regelmatig terug dat er geen bronnen zijn die het AI generated antwoord kunnen onderbouwen zodat hij 70% zekerheid heeft.

De fout is niet dat AI zeker van zijn zaak is, de fout is dat mensen een AI gegenereerd antwoord lezen als iets dat onderbouwd is met feiten, in plaats van een serie tokens die bij elkaar passen.

[MSalters]

Ik geloof niet dat je weet hoe een LLM ( of een AI agent rondom een LLM) werkt, als je serieus aan een LLM vraagt of die 70+% zeker is van z'n antwoord. Dat is niet het soort berekening wat een "reasoning LLM" kan maken. Met andere woorden, een 80% "geschatte zekerheid" is 100% een hallucinatie.

Dat is overigens niet AI eigen. Als iemand mij vraagt om uitspraken met tenminste 70% zekerheid dan ga ik er ook niet van uit dat die persoon statistieken snapt.

[walteij]

Daarom dus de bronvermelding erbij, aangeven dat hij meerdere bronnen moet vinden die hetzelfde vertellen. Ik heb Copilot dusdanig geconditioneerd, dat hij quotes oplevert, de bronnen erbij geeft, aangeeft of er nog andere onafhankelijke bronnen zijn, maar ook of er bronnen zijn die dit tegenspreken. En dit gebruik ik dus niet altijd, maar als ik iets goed moet uitzoeken, is een dergelijk gewenst antwoord van een LLM een van de startpunten.

En dan gaat het dus niet over goed gedocumenteerde programmeertalen waar terabytes aan code van zijn gebruikt om het LLM mee te trainen .

[MSalters]

"Bronvermelding" is zeker een goede maatregel die hallucinaties actief voorkomt.

Dat is echter een kwalitatieve maatregel die los staat van een onmeetbare kwantiteit zoals "70% zeker". Door jouw gebruik van dergelijke betekenisloze taal vergroot je alleen maar de risico's dat de AI ook betekenisloze taal produceert. Een LLM past zich in taalgebruik aan aan jouw taal, dat is wat die geleerd heeft. Wil je een precieze AI? Wees dat zelf dan ook.

[Mellow Jack]

Dan praat je al lang niet meer over een LLM. Dat is gewoon een applicatie (CoPilot) die het LLM voed met "relevante" bronnen

[eric.1]

Dat snap ik, vandaar de aanhalingstekens. Het is niet dat AI zeker is van zijn zaak, maar in de standaard prompts doet AI altijd alsof het erg zeker is van wat het als antwoord formuleert. En velen trappen hier gewoon in.

Daarnaast is het natuurlijk ook gewoon aangeleerd om standaard in vrij formele en zelfverzekerde vorm te schrijven, ook al is de zekerheidsgraad eerder een 50-50 coin-toss. Daar zou je geen bijzondere prompts of contexts voor nodig moeten hebben, om dat af te leren...

[walteij]

Eens, maar dit ga je dus niet op lossen door de LLM's beter te maken, maar door mensen te dwingen om toch na te denken. AI en een LLM is geen "Computer says yes" of "Computer says no" en dat blind opvolgen, het mag nooit leidend zijn, alleen adviserend, waarbij er een gedegen, doordachte, menselijke analyse op losgelaten moet worden om te zien of het door het LLM gegenereerde antwoord juist is of niet. Als je dit niet doet, krijg je binnen no-time de toeslagen-affaire maar dan een factor 100 keer zo ernstig.

Wat dat betreft dus eens met Linus, het is een hulpmiddel, maar zeker geen gouden sleutel en al helemaal geen 42.

[Mellow Jack]

En met mensen krijg je geen toeslagenaffaires? Ik vind het altijd grappig dat we praten in absoluten als het gaat over AI en praten in nuances als het over mensen gaat. Terwijl een mens blijkbaar ook wel eens een brug open doet terwijl iemand op de burg staat. Mensen zijn eigenlijk ook best wel slecht

[walteij]

Als je je een beetje verdiept in de toeslagen affaire, weet je dat het probleem was dat er een algoritme was, waarmee 'potentiele frauders' werden gemarkeerd en in plaats van een gedegen onderzoek te doen (wat de bedoeling was), vonden de mensen bij de belastingdienst het makkelijker om te besluiten dat de computer gewoon gelijk had.

[goarilla]

De fout is niet dat AI zeker van zijn zaak is, de fout is dat mensen een AI gegenereerd antwoord lezen als iets dat onderbouwd is met feiten, in plaats van een serie tokens die bij elkaar passen.

En als ik het goed begrepen heb als effect van het RLHF netwerk dat de AI boeren er hebben bij opgezet om ergens ook gewoon "aangenamer" te kunnen chatten met mensen. Niet ?

[Calypso]

En nu het probleem wat ik met AI heb. En met tools in het algemeen. Het zorgt ervoor dat kennis en vakmanschap verloren gaat.

Met de komst van een rekenmachine is de hoeveelheid mensen die kan hoofdrekenen drastisch afgenomen. Sinds spellingscontrole gemeengoed geworden is zie je de hoeveelheid taalfouten exploderen. En het grote probleem van AI in mijn ogen is niet dat het geen goede tool zou kunnen zijn, maar dat het begrip hoe je moet programmeren gaat verdwijnen. En vooral dat het voor creatief bedoelde zaken toegepast wordt waardoor de kans heel erg groot is dat ook dat gaat uitsterven - en dat is toch voor een deel wat onze diersoort "mens" maakt.

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

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

[freaq]

Dit zeer zeker. Je kan heel Makkelijk 2-3 verschilende opties testen, en je kan mits je goede benchmarks hebt het zelfs redelijk autonoom laten zoeken voor optimalisaties.

Lastigste is gewoon eerst een goede architectuur opzetten, als de architectuur verkeerd gaat dan is er bijna geen terugkomen meer aan, niet dat dat anders is met normale projecten, maar daar heb je meer tijd voor reflectie.

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

[Pietopdeheuvel]

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

[Zeerob]

Zoals spell-check?

[Onoffon]

[mrfeet]

[Pietopdeheuvel]

Hont, Kad, is een grapje voor degene die het begrijpen. Net als Pasta in blauwe verpakking.

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

[Borgia]

Maar wat vindt Ja Rule van AI?

[HarmFull]

Ja Rule? Of ik snap je niet of je verwijst cynisch naar de rapper met die naam.

Torvalds is vooraanstaand in de open-source/IT wereld. Linux en GIT hebben een onmiskenbare gigantische impact gehad dus ja zijn mening is zeer relevant en interessant.

Alleen jammer dat NU het als nieuws brengt terwijl het al eerder door hem gezegd is.

[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

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

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

[bzuidgeest]

Maar, al die dingen had je ook prima zonder LLM kunnen leren,

Er is niet genoeg tijd in de wereld of een mensenleven om alle dingen die ik interessant vind te leren. Met AI kan ik in veel meer dingen rondkijken. Is dat perfect nee, maar al jij mij een duizend jaar kan garanderen en dat ik niet hoef te werken voor mijn geld, wil ik het best zonder AI proberen.

Dus je bent bewust zelf gaan leren,

Niet zozeer ik ken veel gebieden waar ik gewoon niet de tijd voor heb om helemaal zelf te doen. Nu heb ik een hulpje zonder opinie. Ik ga er niet van uit dat ik de gebieden "goed" leer, dat is niet het doel. Ik heb nu een gids en onderweg leer ik ook nog wat.

Mensen moeten willen leren en dat willen ze met of zonder AI niet meer. Ons onderwijs is ook waardeloos. Ooit hadden we groten in het onderwijs. Einstein, Faraday, Feynmann, Curie. Dat waren docenten. Kijk naar wat we nu docenten noemen. Gadverdarrie. Het is nu meer those who can't teach. De kwaliteit van leraren is abominabel. De mogelijkheid om flexibel om te gaan met leerlingen die graag leren is nul, want dan kan de rest niet meekomen. What the fuck maakt dat nou uit. Als er eentje hard wil dan moet die de kans krijgen hard te gaan en hard te falen als ze hun grens vinden. Maar nee, eenheidsworst. Heb je enig idee hoeveel gefrustreerde ouders er zijn waar hun leergierige kind onvoldoende word aangemoedigd? Die ouders kunnen ook niet alles. Kinderen vervelen zich te pletter en leren nooit hard werken, nooit tegenslag tot het eigenlijk te laat is.

[The Realone]

Huh? Gaat het goed met je?

[bzuidgeest]

Ja prima, alhoewel het een grote frustratie is niet alles te kunnen leren en doen wat interessant is. En ik vind ook dat de problemen in het onderwijs op computers schuiven gewoon een bagger actie is. De problemen in het onderwijs liggen niet aan computers en worden niet opgelost met computers, computers zijn tools, AI zijn tools. De kwaliteit van onderwijs hangt af van hen die het geven en de vorm waarin de overheid het afdwingt. Dat is het echte probleem. De rest is een slap excuus.

[The Realone]

AI gaat je niet helpen om alles te leren wat interessant is. De limiet ligt bij de mens en dat zal altijd zo blijven. Dat moet je kunnen accepteren, anders heb je een ander probleem. En nogmaals, AI is leuk voor die hobbyprojecten waar jij duidelijk grenzen aan kunt geven en waar je je kost niet mee hoeft te verdienen. Zodra er een baas over je schouder meekijkt, die wil dat jij levert, gaan de vangrails om AI enkel te gebruiken voor "het leren" al gauw de deur uit, want er moet geleverd worden. Dus dan wordt het jammer dat ik AI mij niet laat vertellen hoe ik bij "hello world" kom, maar ik wil direct het product afgeleverd hebben. En dat moeten we niet willen.

Je relaas m.b.t. het onderwijs begrijp ik niet. Het onderwijs is er om je "te leren om te leren". En grappig genoeg gaat AI er verantwoordelijk voor zijn om precies dat stuk over te slaan.
Onderwijs moet iedereen dienen, maar kan niet iedereen 100% dienen. Daar zijn genoeg andere methoden voor.

[bzuidgeest]

Het onderwijs leert tegenwoordig niemand leren. Al jaren niet meer. Rijtjes maken , opzitten en een boekje doorwerken met een stropop aan de voorkant die weinig meer weet dan het boek. Of soms minder. Je hebt gelijk dat een school er ook is om te leren leren, maar in de praktijk komt daar weinig van terecht. Het is gewoon een bedrijf dat zo veel mogelijk personen met een papiertje moet producten zodat ze geld krijgen. Als het niveau daarvoor omlaag moet dan gaat het omlaag. Het is schrikbarend wat een incompetentie je daar tegenkomt.

En wat is er erg aan om voor de baas er gewoon no nonsense productie me te draaien? Heb je enig idee hoe goed het is voor mijn RSI om gewoon te kunnen prompten?

Leren doe ik wel in mijn vrije tijd. Leren wat ik leuk vind. Voor de baas is het gewoon productie. En met wat ik leer en blijf leren blijf ik altijd voorop lopen.

[Reactie gewijzigd door bzuidgeest op 16 juli 2026 23:32]

[The Realone]

Je klaagzang over scholen is zwaar overdreven. Er zijn zeker op- en aanmerkingen te maken, maar Nederland bevindt zich nog altijd aan hoog in de lijstjes als het om kwaliteit en beschikbaarheid van onderwijs aankomt. Ik heb ook geen idee wat dit met AI te maken heeft, maar wat ik wel weet is dat we AI ver uit die klaslokalen moeten houden.

Voor wat betreft "prompten voor de baas", het is prima als jij en jouw baas daar content mee zijn, er zijn immers veel mensen die graag lopendeband werk doen zonder teveel hoeven na te denken. Maar ik probeer te groeien in mijn carrière en daar mag AI mij best in assisteren, maar zodra het de boventoon gaat voeren simpelweg omdat mijn baas wil dat ik "meer produceer", houdt het voor mij op. En dat is wel precies de trend die je ziet.

[bzuidgeest]

Voor wat betreft "prompten voor de baas", het is prima als jij en jouw baas daar content mee zijn, er zijn immers veel mensen die graag lopendeband werk doen zonder teveel hoeven na te denken.

Je ziet het te negatief. Ik prompt de saaie dingen weg en hou daardoor meer tijd over voor de echt leuke dingen, voor innovaties, experimenten en zo. En mijn baas kan dat ook zien.

Ik denk dat als jij het lopende band werk met de hand gaat doen, terwijl je het op de AI lopende band kan zetten, je jezelf te kort doet. Je zou intelligentere dingen in die tijd kunnen doen.

nog altijd aan hoog in de lijstjes

En we zakken al jaren in die lijstjes. We glijden af.

Ik heb ook geen idee wat dit met AI te maken heeft, maar wat ik wel weet is dat we AI ver uit die klaslokalen moeten houden.

Je hebt geen idee wat het met AI te maken heeft en geeft dan zelf de relatie aan???? De AI kan prima in een klaslokaal als tool bij verschillende lessen. Soms met, soms zonder. Het is niet AI dat je moet verbannen. Het is de manier van lesgeven die moet verbeteren. Want die is te slecht om de aanwezigheid van AI in te passen. Voeg een paar lesopdrachten toe die leerzaam zijn maar niet door een AI gedaan kunnen worden. Het is niet moeilijk. Voeg presentatie en demonstratie toe, zonder hulp van de AI en je weet zo wie echt geleerd heeft. Toetsing en examinering is ook zonder AI. Het echte probleem is dat docenten simpele opdrachten die makkelijk zijn na te kijken op standaard papier dat ze al 10 jaar gebruiken gemakkelijker vinden. Iets praktisch doen en een punt voor geven is te veel moeite. Dat is het probleem en het is niet veroorzaakt door AI. AI is het probleem niet.

[lighting_]

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

[StrongArmLance]

Wat leer je daar dan niet van?

Weet ik niet? Wat leer je daar niet van?

[lighting_]

In mijn voorbeeld geef ik dat aan maar je blijft ontkennen. Dus je bent gewoon anti AI. Wat doe je dan op deze tech forum?

[Reactie gewijzigd door lighting_ op 16 juli 2026 17:38]

[StrongArmLance]

Volgens mij sla je de plank een beetje mis. Ik ontken niets (en 'blijf zeker niets ontkennen'), jij reageert alleen nogal defensief en vraagt aan mij waar je dan niets van leert. Dat weet ik uiteraard niet. Ik gebruik zelf afdoende AI naar mijn mening, maar leer er weinig van.

[graey]

Ik spreek beter Frans, ben beter in Flutter omdat mijn hobbyprojectjes meer van de grond komen, en mijn daytime programmeerwerk is ook naar een hoger plan. Je moet het goed gebruiken, maar als je nog steeds de output controleert en het grotere ontwerp zelf maakt en als randvoorwaarde aanhoudt, wordt je absoluut geen slechtere programmeur door AI.

[StCreed]

De afgelopen twee weken heb ik mij verdiept in een niche methode voor informatiemodellering omdat ik een viewer voor een populair pakket bouw. Inmiddels wordt ik door mensen op 3 continenten beschouwd als expert omdat ik nu op niveau vragen stel en kan meepraten. Ik had er natuurlijk al een achtergrond in dit gebied maar nu heb ik het flink verdiept.

Maar je kan een paard wel naar water leiden, je kan het niet laten drinken.

Negeer AI vooral. Minder concurrentie voor mij en dus een hoger tarief

[markg85]

🤔 Dit leest mij als een ai-papegaai verhaal. Je hebt anderen gehoord over AI kritiek en gaat daar vrolijk in mee. Vooral je "aftekeling van denkvermogen".

Je hebt altijd mensen op de intelligentie ladder die meer aan de onderkant zitten en door andere in generieke zin vaak toch snel worden weggezet als dom. Dat zijn ze niet, ze zijn op specifieke gebieden juist heel goed. Voor je AI had kon die doelgroep naar alle waarschijnlijkheid niet een applicatie bouwen of meekomen in die technische wereld. Dat was meer een hocus pocus ver van hun bed show.

De lat om wel mee te komen in die technische hoek (waar ik me nu specifiek richt op sites/tools en code) is al decennia lang geleidelijk omlaag aan het gaan. Dat komt door het bestaan van frameworks die het maken van dergelijk spul steeds simpeler en breder toegankelijk maakt. Kijk maar naar hoe je voor AI al het gruwelijke electron (of tauri) kon gebruiken om een "desktop" programma te maken wat op elk platform werkt en er nog mooi it kan zien ook.

De komst van AI, en dan met name vibe coding, heeft die technische lat een vrije val naar beneden gegeven. Het is hierdoor nu heel eenvoudig voor - bij wijze van, de tandarts assistent - om een gaaf mooi uitziend product te maken waar diegene echt 0,0 snapt van hoe het werkt. "Dat vraag je dan aan AI" is dan het antwoord.

Het nadeel is dat zulke producten helemaal naar inzicht van de AI gemaakt worden en die neemt, net als wij mensen, ook echt de makkelijke "oh dit werkt, prima" oplossingen eerst. Het is letterlijk "crap in, crap out". Maar als je niet van de technische kant weet kan die "crap out" voor jou ogen als "oh wauw, gaaf, dit kan ik verkopen als product!" Heb je een probleem in je product dan zal AI zeker eerst proberen dat probleem minder zichtbaar te maken in plaats van de onderliggende oorzaak op te speuren en te fixen. Met developer achtergrond prik je hier wel doorheen en stuur je rustig bij. Zonder die achtergrond krijg je steeds erger monster.

Ik denk dat AI precies het tegenovergestelde doet van wat jij beweert met aftakeling denkvermogen. Dat weer erg aan de persoon liggen die het gebruikt. Ik heb zelf ~15 jaar developer ervaring in C++ en heb me toch nooit gebrand aan dingen grafische rendering (OpenGL, Vulkan) of uberhoupt C code. Met AI krijg ik me toch een interessante grafische dingen werkend die me eerder nooit waren gelukt, hoe gaaf is dat? Voor mij leer ik nu in een noodvaart nieuwe tools en talen (C, maar ook zeker Rust) via AI waar ik eerst jaren voor nodig had gehad. Ik hoef een taal nu niet meer door en door te kennen om er nog steeds behoorlijk goed en effectief in te zijn. Een tool in Rust maak ik nu zo maar heb er wel AI bij nodig om dat tot een goed einde te brengen. Wil dat zeggen dat ik pruts code maak? Nee, helemaal niet. Juist door die lange geschiedenis zie je wel wat mogelijk raar is (de zogenaamde "code smell") en wat "wel goed zit". En als het goed is pak je, als developer, dat ook langzaam op en leer je de taal zo ook kennen. Het is een andere manier van leren maar voor mij veel sneller en beter.

Oftewel, ik denk dat het gebruik van AI je juist in een noodvaart dingen kan leren op een manier die voor jou lekker werkt. Dingen waar je zonder AI niet aan was begonnen. Of iedereen dit doet, geen idee. Maar denk wel dat het beeld vertekend omdat de groep mensen die AI kan gebruiken vele malen groter is dan de groep techneuten/developers.

[The Realone]

Ik licht even het allerbelangrijkste stuk uit jouw reactie eruit, en de reden waarom ik AI-skeptisch ben. Niet anti-AI, dat is niet hetzelfde.

Met developer achtergrond prik je hier wel doorheen en stuur je rustig bij. Zonder die achtergrond krijg je steeds erger monster.

Senior devs worden niet geboren. Junior devs worden senior devs. Wat je ziet gebeuren is dat organisaties veel heil zien in het besparen op junior devs en die vervangen met AI toepassingen. Dat past helemaal in jouw verhaal en zal dit vaak ook bevestigen, maar dat is wel allemaal leuk voor de korte-termijn.

[markg85]

Ja klopt. Maar ik merk ook dat als iets nieuws leren met AI veel en veel sneller en makkelijker gaat dan zonder AI. Een voorbeeld met het begin van rust, nu een klein jaar geleden. Ik wou dat leren maar de syntax viel bij mij niet helemaal lekker, de logica in de taal ontbrak me een beetje. Dus ik heb aan AI gevraagd om stukken rust code aan mij uit te leggen in C++ principes omdat ik die wel ken en begrijp. Dat leert echt als een trein! Nou kan ik dit zo op deze manier doen maar elk ander kan dit op een vergelijkbare manier doen door het aan iets te relateren wat je al wel kent. Geen forum of persoon had het je op zo'n manier begrijpelijk kunnen maken, AI wel.

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

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

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

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

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

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

[StCreed]

Dit zie ik bij collega's die niet erg van het documenteren zijn. Laatst was ik bij een club waar elke change een jaar kost, minimaal, omdat er geen actuele documentatie is. En die gaan ze ook niet maken.

Ik heb nu een stevig project. Maximale ontkoppeling, welke feature op basis van een ontwerp, overkoepelende coherentie bewaakt in intent.md. Taken netjes opgesplitst per onderwerp met synchronisatie tussen agents. ADR voor elke feature met alle ontwerpbesluiten.

Mijn "hobbyprojecten" zijn professioneler ingericht dan 90% van de projecten waar ik op heb gezeten.

[Barsonax]

Mijn ervaring is eigenlijk ook dat als je de scope te groot maakt AI teveel gaat hallucineren. Hoeveel guardrails, testen, instructies etc je er ook tegenaan gooit het blijft gebeuren.

Human in the loop blijft gewoon belangrijk.

[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

[satya]

Is dat dan toch iets met "geheugen" waar sommigen het over hebben en die als een laag tussen de het lokale ontwikkel mechanisme en de AI service bouwen?

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

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

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

[Quacko]

Hoi,

Daar vul je iets te snel in denk ik. Wij maken enterprise applicaties voor business kritische processen en ik zeg niet dat the human in the loop verdwijnt, ze gaat gewoon snel kleiner worden. Onze resultaten so far (half jaar aan data) zijn dat we gemiddeld 250% meer opleveren met dezelfde mensen. Dit is in een grote bestaande enterprise codebase voor een kritisch business process met enorm zware business logica en vele integraties.

We zien het nu gewoon al in de praktijk lukken bij ons. Human in the loop voor reviews, technisch design en nakijken van analyses en harnass en knowledgebase toevoegingen nakijken.

Ik denk wel dat als de evolutie van llms nog 3 jaar op deze snelheid vooruit gaat dat human in the loop misschien wel heel klein gaat worden.

Ik spreek ook nergens over mensen zonder technische kennis, de human in the loop moet kennis hebben. Maar als het zo blijft gaan als nu, dan gaat de rol en tijdsinvestering zeer klein worden. En daar hoort sowieso bij dat je controle verliest, maar als het blijft vooruit gaan zoals nu, dan gaat dat ook kunnen. Je gaat niet meer alle code moeten gezien hebben als je de harnass en architectuur maar hebt mee uitgewerkt en nakijkt bijvoorbeeld. Maar voor de duidelijkheid, daar zijn we nu alleszinds nog niet en gaan we maar geraken als er geen stagnatie van vooruitgang komt met de llms's, wat zou kunnen natuurlijk.

Uw reactie is eentje die ik veel hoor door mensen die het nog niet serieus hebben zien werken met professionele organisatie en werking er rond met solide processen en opzet met mixture of agents en zelfs een overkoepelende agent die alles opvolgt en aanstuurt. Ben niet zeker of dat voor u geldt, maar het is in ieder geval een bekende reactie. Onze mensen, en ik ook, waren op het begin sceptisch, maar door de hype en opgeblazen verwachtingen van klanten moesten wij dit kunnen aanbieden. We zijn enorm verschoten van het resultaat wat nu al vandaag kan.

[Reactie gewijzigd door Quacko op 17 juli 2026 10:46]

[Barsonax]

Wat voor business kritische applicaties maken jullie dan? 250% meer wat? Lines of code?

Als engineers weg zijn gaat de business in de toekomst dan zelf dat bouwen? Dat klinkt eerder als shadow IT in het kwadraat. Ik zie dat niet goedkomen. Het hele besef van software lifecycle is er al niet. Wie is er accountable überhaupt dan? Anthropic?

Ik zie AI ter ondersteuning van maar echt niet als vervanging van complexe banen. Call center mensen vervangen is echt wat anders dan engineers vervangen.

[StCreed]

Joh, hou deze houding vooral vol. Negeer de mensen met een codebase van 50 jaar oud waar duizenden mensen aan hebben gewerkt. Wat weten die nou? Je hebt vast je eigen onderzoek gedaan, dus je bent een expert.

[Barsonax]

Misschien even beter lezen. Ik zeg niet dat AI nutteloos is maar het is ook weer niet zo dat het alle engineers kan vervangen. Linus zegt dat ook niet.

[StCreed]

Niet alle, maar wel een hoop mensen die zich engineer noemen. Dat is eigenlijk een beschermde titel maar de meesten zijn geen ir. of ing. - of drs. - in de informatica. Als informaticus zie ik het verschil tussen de wannabe groep en de echte deskundigen.

Al die wannabes zonder basiskennis kunnen er straks uit, en dat lijkt mij prima.

[Barsonax]

Lijkt mij ook prima dat alle wannabes eruit gaan. Betwijfel wel of dat echt gaat gebeuren. Denk eerder dat we gaan puinruimen. Je blijft toch heel wat bedrijven hebben waar kwaliteit gewoon niet zo belangrijk is tja tot dat het ineens wel zo is.

Genoeg werk voor de komende tijd iig.

[Quacko]

Nee, wij schatten nog altijd al het werk in alsof we het helemaal zelf zouden bouwen. We zien dat onze velocity met 250% gestegen is sindsdien. We bouwen alongside ook nog af en toe dingen zelf om te zorgen dat die inschattingen niet bloated worden, het verschil tussen zelf bouwen en AI is dus 250%. Velocity is dus maal 2,5 gegaan. Maar vergis u niet, momenteel is in elke stap nog een expert betrokken, van analyse, tot knowledgebase, tot architectuur, technisch design, tot harnass, tot code, tot testing. Maar wel allemaal slechts in validerende en corrigerende rol.

Business kritisch, van ziekenhuizen tot overheden tot internationle logistieke bedrijven, auto industrie en meer.

Liability, het blijven tools, niemand zegt dat je ze moet gebruiken. Die discussie doet weinig ter zake lijkt me. Je mag gerust altijd human in the loop houden, niemand houd je tegen. Maar ga je dat blijven doen als het 10j aan een stuk blijkt (nu is dat dus zeker nog niet mogelijk) dat alles perfect loopt? Dat vind ik een beetje raar.

Engineers weg zijn spreek ik niet over hoor, hun rol gaat gewoon heel klein worden qua tijdsbesteding als het zo voort gaat (is maar een voorspelling op basis van wat ik nu al zie). En dit heeft als gevolg ofwel een explosie van veel meer opleveren of minder werk. Maar gezien de vraag denk ik eerder het eerste.

En als het langer dan 3 jaar aan deze snelheid vooruit gaat, pakweg 10 jaar, dan zie ik het nog wel gebeuren dat de mens er nagenoeg helemaal uit gaat en je enkel eens bij onverklaarbare dingen een expert in AI troubleshooting nodig gaat hebben. Of dat het werk van een software bouwer vooral heel goed opzetten is van de AI en bij enterprise architectuur eens mee nadenken (alhoewel) en dat dan analisten, of dat soort profielen verder kunnen.

Maar dat is al heel verre extrapolatie, dus ben ik nu zelf nog niet helemaal overtuigd van. Ik zie het ook heel erg mogelijk dat we over enkele jaren het maximum uit llm's hebben gehaald en dan stopt het bij wat we nu al kunnen. Who knows.

Over sdlc, dat kan je ook echt gewoon opzetten hé, sdlc is uiteindelijk maar een gedegen proces. Een belangrijk proces met veel facetten, maar ook maar dat. Dat trouwens bij veel bedrijven, ook grote, heel heel slecht gedaan wordt hé. Hoeveel legacy codebases tjokvol kwetsbaarheden die wij al zijn tegengekomen, het zou beter geautomatiseerd zijn, dan gebeurt het gewoon ipv dat het een budget beslissing wordt waarmee klasse 4 data van mensen voor het grijpen ligt.

En ja in de komende jaren ga je nog steeds heel wat technisch experten nodig hebben, al gaat de tijdsbesteding per oplossing sterk verkleinen, maar over pakweg 10j? Ik ben daar niet zo zeker van...

Maar we hebben allebij recht op onze mening natuurlijk en geen van ons heeft een glazen bol. Mijn mening is louter gebaseerd op een paar jaar extrapoleren van wat we nu al kunnen.

[StCreed]

Duh. Coping much? Ik ken de IB- systemen van de Belastingdienst, INDigo, het SVB mainframe, en nog wel wat grotere systemen. En ik kan je nu al zeggen dat die gewoon prima te doen zijn met AI. Er is namelijk veel bullshit omheen geschreven voor eenmalige use cases, batches die in 20 jaar nooit lopen, dubbele code omdat er 400 devs op zitten, etc. etc.

Ik denk dat ik maar eens een aanbod aan de SVB of BD moet doen. Ik kan heel wat devs vrij gaan maken voor nuttiger werk.

[Barsonax]

En hoezo zou AI dan ineens niet het probleem hebben van features bouwen die niet nodig zijn of dubbele code schrijven? Dat eerste is geen code probleem en die tweede doet AI ook maar al te vaak.

Zie het dus niet gebeuren dat een non technisch iemand zo'n systeem van scratch gaat opzetten.

Maar goed als jouw werk echt bestaat uit puur alleen code kloppen dan zou ik mij idd zorgen maken. Dan zat je echter sws al aan de onderkant van de markt te klooien.

[StCreed]

Ik zit juist aan de architectuurkant. Maar ik heb (sinds ik mij in februari op AI heb gestort toen het duidelijk werd dat het volwassen genoeg was) in al die tijd maar een of twee keer iets dubbel gebouwd zien worden zonder instructie. Dat kun je echt voorkomen.

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

[CAPSLOCK2000]

het lastige daarmee is dat je daardoor op vrij korte termijn heel veel programmeurs overbodig maakt,

Gelukkig is de behoefte aan code enorm, veel groter dan waar onze huidige programmeurs in kunnen voorzien. Ik zie AI niet als volledige vervanging voor programmeurs, ik zie het als gereedschap dat programmeurs effectiever maakt. Als code ook nog eens goedkoper wordt door AI dan zal de markt voor code alleeen maar groter worden.
Wel zal het werk verschuiven van handmatig code kloppen in de richting van architectuur en structuur. Eerlijk gezegd vind ik dat toch al het belangrijke en interessante deel van het werk.

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

[JP1980]

Absoluut dat is een reëel probleem.

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

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

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

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

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

[Wolfos]

Ik review al lang niet meer. Ik bepaal vooraf de architectuur en doe achteraf een functionele check. 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.

[Reactie gewijzigd door Wolfos op 16 juli 2026 15:10]

[StCreed]

Inderdaad. De intentie, testsuite en acceptatie worden terecht het belangrijkste deel van het proces.

[eborn]

Wie bepaald of de testsuite ook test wat echt getest moet worden? Ik heb vaak genoeg gegenereerde tests gezien die eigenlijk helemaal niets testen.

[StCreed]

Ja, dat bepaal ik inderdaad zelf aan de hand van de beschrijving, plus ik vraag bij gevoelige stukken of dingen die een keer mis zijn gegaan of de AI daar specifieke tests op wil maken en vraag ook naar een verslag. Meestal niet, hij heeft een goed dekkende set. Maar soms gaat het mis. Ook bij grote wijzigingen moet ik echt wel expliciet vragen om ook de tests opnieuw te bekijken en overbodige tests te verwijderen en ontbrekende toe te voegen. Maar fable 5 is eerlijk gezegd behoorlijk goed daarin.

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

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

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

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

[Webgnome]

Met pijn en moeite kunnen menselijke programmeurs dat ook. Echter is het vaak de angst voor het niet snappen die het hem doet een andere factor is tijd. Dat je geen tijd krijgt van je manager(s) om er in te komen. Daar kan AI helpen echter kan het er ook voor zorgen dat je juist meer troep toevoegd.
Het voordeel van AI is zoals @croc aangeeft dat je het vragen kan stellen over die codebase. Echter de antwoorden zijn ook aan de nodige halucinaties onderhevig dus daar zul je altijd rekening mee moeten houden.

[Reactie gewijzigd door Webgnome op 16 juli 2026 16:14]

[croc]

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

[punishedbrains]

Je kan software prima goed indelen en leesbaar houden, mits je niet met de constante push en sprints van managers zit zoals tegenwoordig. Ik heb ook gewerkt aan een spaghetti codebase, dat echt nooit meer. Ik zet mijn projecten dan ook zo netjes mogelijk op en houdt me aan standaarden, bedoelt om het inzichtelijk te houden en testbaar. Mocht AI ooit totaal niet te betalen zijn, danwel falen, dan heb ik gewoon nog een weg vooruit.

[Glashelder]

Ik denk dat je de essentie van mijn boodschap gewoon gemist hebt.

Leesbaar wil niet zeggen dat er mensen rondlopen die het in scope hebben.

[HansvDr]

Zolang de klant tevreden is en betaalt is het mij om het even. Als ik het niet doe doet een ander het. Ik wil graag door met mijn bedrijf dus is AI een must.

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

[HansvDr]

Zolang ik er geld mee kan verdienen doe ik het.

[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

[c-nan]

Het kost niet meer tijd om het uit te schrijven. Ja, het kost even tijd. Als je prompt onvolledig is dan krijg je ook onvolledige code. Ik heb een applicatie in Go laten ontwikkelen aan Claude. Mijn initiële prompt was ~400 regels.

Versie v0.1 werkte direct, inclusief tests, ci pipelines, etc. Als ik dit door een team zou laten ontwikkelen had het zo 2-3 sprints gekost (dus een maand of meer).

[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

[StCreed]

Ik weet niet welk rottig open source model je gebruikt, maar dat is niet mijn ervaring met ChatGPT en Claude.

Laatst nog een website volledig door AI laten bouwen in een weekeinde. Werkt prima.

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

[StCreed]

Actuele literatuur ouder dan 1 maand is geen actuele literatuur.

Weet je wie de experts zijn op gebruik van AI in grote code bases? Linus Torvalds en Daniel Stenberg. Niet allerlei zelfbenoemde profeten. En die twee zien het heel scherp. Inmiddels gebruiken ze beide AI - bij cURL inmiddels een stuk of 5.

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

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

[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

[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 :)

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

[StCreed]

Ik vind het meer lijken op shell vs X11 Windows debatten. Die waren ook vrij erg.

[sdziscool]

AI bij mij is gewoon gaan betekenen: er kan veel meer geprogrammeerd worden, maar alle code is effectief extern dus moet ook extra gecontroleerd worden.
Uiteindelijk ben je alleen sneller klaar als je de AI echt vertrouwd, als je echt wil verifieren dat de AI goed werk aflevert, dan is de werkdruk verandert van programmeren naar verifieren, een hoop saaier en mentaal uitputtend werk jammergenoeg.

[Steven Klink]

Dus ga je toch lekker zelf weer devven ?

[sdziscool]

ligt aan de verwachtingen, als deadlines kort zijn moet je soms vertrouwen in de AI hebben om zo deadlines te halen, zou het zelf liever anders zien, maar fout is het NOG niet gegaan.

[Steven Klink]

Jij liever dan ik waarbij ik vrij zeker ben dat jij een andere deadline tegenkomt dan ik die zijn skills en inschattingsvermogen goed kan benutten.