Cariére perspectief software development in AI revolutie

[Apollyon]

Iedereen in de IT weet dat AI onze banen veranderd. Sommige mensen zijn bang hun baan te verleizen. Die angst had ik neit tot vandaag. Ik maak als medior software engenier al lang gebruik van AI coding support. Mijn werk is daardoor beter en sneller af. Saai typwerk doet de AI ook beter. Iedereen blij.

Vandaag heeft management medegedeeld dat software development gaat veranderen. We stoppen met zelf code schrijven. Met nieuwe AI tooilng schrijven we alleen nog maar prompts en requierments. De AI implement dat en wij moeten dan alleen het merge request reviewen. Na de zomer is het al zo ver.

Ik ga mij zorgen maken voor de teokomst. Het moet allemaal nog sneller gaan. We moeten 10x meer output gaan leveren. Er wordt developer ervaring verwacht maar hoe dan als ik geen code meer maar alleen prompts schrijf. Ik vind het helemaal niet leuk want ik heb ernstige dyslexie en ben bang snel kennis te verliezen als ik neit meer mag programeren.

Wat is het toekomsperspectief voor software developers? Ik snap dat veel banen veranderen door invleod van AI maar wat betekent het voor mijn carrière? Gaan de lonen omlaag omdat onze kennis minder waard wordt? Overstappen naar een andere werkgever kan op de korte termijn helpen maar andere bedrijven zullen dit vast ook wel gaan doen dus loop ik dan weer tegen problemen aan.

Zijn er software developers die alleen prompts willen tukken en AI gegenereerde merge requests reviewen?
Ik ben niet bang voor verandering. Ik heb wel angst voor de impact op mijn carrière perspetief en financiele zkeerheid. Wie heeft hier al over nagedacht?

[itons]

Joh, bij ons doen ze al SDD. Het gaat langzamer voor de meesten ipv sneller. Kleine changes worden opgeblazen met gigantische requirements documenten die niemand meer volledig kan en wil lezen. Grote changes passen niet in de context en zijn incompleet.

We zijn voorlopig nog wel zoet.

[Oon]

Tja, een werkgever zoeken die hun werk wél serieus neemt?

AI is nog heel lanng niet zo ver dat je er met alleen prompts en requirements komt, en 10x meer output is écht niet reëel. Veel grote bedrijven die hard hebben ingezet op AI zijn nu aan het terugkrabbelen omdat de meest recente cijfers heel duidelijk maken dat AI vaak hetzelfde of zelfs duurder uit komt. Als je nog een beetje kwaliteit overhoudt ben je vaak langer bezig met vechten met je code agent dan als je het zelf doet.

Ik denk dat je kennis juist meer waard wordt in een wereld waar de gemiddelde kennis keldert. Iemand die zélf weet waar hij mee bezig is gaat steeds relevanter zijn, want met overal brakke AI software door dit soort managementacties is juist iemand die hier op een gezonde manier mee om kan gaan en een LLM terug kan fluiten héél belangrijk.

Uiteindelijk maakt het niet uit of je zelf de code schrijft en of je alle oplossingen zelf bedenkt, maar je moet de code wel kunnen lezen en kunnen bijsturen.

[wiemelen]

En hoe verwacht het management dat iemand de juiste inzichten, proces kennis en technische kennis heeft om de prompts op te stellen. Maar nog belangrijker, hoe verwacht het management dat iemand de juiste inzichten, proces kennis en technische kennis heeft om de door AI opgeleverde code te reviewen en bij te sturen waar nodig?

Ik heb toevallig afgelopen vrijdag 2 programma's laten genereren door AI. Resultaat was ongestructureerde code, met tal van syntax fouten, dat maar bij benadering deed wat ik wilde.
Uiteindelijk zelf de code geschreven. Resultaat was gestructureerde slimmere, generieke code die exact deed wat gevraagd werd ... én ik was minder tijd kwijt het zelf te schrijven dan de gegenereerde troep te corrigeren.

Ik hou mijn hart vast voor bedrijven die denken dat AI alles gaat oplossen. Wie gaat de code schrijven waar AI geen oplossing voor heeft? En de code die vandaag wel door AI geschreven wordt, is vaak nog zo brak dat die spaghetti over een tijdje oncontroleerbaar wordt, zeker als er later nog wijzigingen op doorgevoerd worden.

[ouweklimgeit]

Nou, devops hier, ik kan Claude niet meer wegdenken uit mijn werk hoor. Een klus waar ik normaal een half jaar over deed, is nu binnen een week afgerond. Dat geleuter over spaghetti-code is complete onzin, de goede AI tools kennen de volledige codebase van elke programmeertaal en onleesbare code ben ik het afgelopen jaar niet meer tegengekomen. Alles wordt gedocumenteerd en tot in de puntjes uitgezocht op complicaties in andere delen van je code. Dus bijv. een bepaalde class/functie aanpassing doet hij alleen als hij zeker weet dat het óveral goed gaat.

Het enige wat er voor jou als developer gaat veranderen; je gaat van typgeit naar projectmanager waarbij je de AI-tooling aanstuurt op hun werk. Jij behoudt het overzicht, AI doet het werk voor je.

Ga er gewoon een paar weken mee aan de slag, omarm het, en dan kijken hoe je het zo efficiënt mogelijk kunt inzetten. Want geloof mij, ik dacht ook dat mijn 20+ jaren Python en PHP zouden uitstijgen boven de kennis en kunde van AI, maar damn, wat was dat een naïeve gedachte.

[Expecho]

Als ontwikkelaar kan je juist nu het verschil maken. Leer de tool (Claude Code, Cursor or whatevever) goed kennen en bouw een set aan skills/commands/hooks etc. op die aantoonbaar de gegenereerde code verbeteren. Dat kan alleen als je weet hoe je goede software bouwt.

Ik zie zelf de verschuiving naar meer tijd nemen om het plan wat door AI gemaakt is te verbeteren. Als de standaard plannen van je tool je niet de juiste inzichten geven schrijft dan je eigen skill. Alle effort die je in het plan stopt scheelt weer in het corrigeren van de gegenereerde code. Je zal zien dat je werk verschuift van focus op code naar focus op architectuur.

Krijg je rommel als ouput? Schrijf dan AI niet af meer investeer in het juist opzetting van de tooling en de instructies. Zorg bv dat de AI de resultaten van je static code analyser meeneemt om de code te verbeteren. Zo zijn er nog heel veel tips.

Ik zie vaak mensen om me heen afhaken omdat ze te weinig tijd investeren in het aanleren van de skills die je nodig hebt om je AI omgeving goed op te zetten en dan te vaak tegen rommelige output aanlopen.

[LED-Maniak]

Tegenwoordig bluft iedereen zich door meetings omdat Claude ze iets verteld heeft.
Mensen zonder enig verstand van linux worstelen zich vol vertrouwen door terminals heen en denken nu een software engineer te zijn.

Ik heb al een collega gehad die blind sudo rm -rf / heeft uitgevoerd 'omdat AI dat zei en ze er samen niet uit kwamen' waardoor een productiemachine stil is komen te staan.

Requirements en mails worden onleesbare ellipsels van pagina's lang en tickets die normaal gezien maar een fatsoenlijke zin nodig hebben, zijn nu 'smart'.

Voorlopig hebben we nog wel werk genoeg gok ik.

[ Voor 14% gewijzigd door LED-Maniak op 09-06-2026 11:17 ]

[Jorizzz]

Werk zal gaan verschuiven. Minder daadwerkelijk bouwen, meer requirements engineering en meer testen. Maar tegelijkertijd gaan de verlaagde drempel en de verlaagde kosten alleen maar voor méér vraag naar software zorgen. Ik zie het allemaal helemaal niet somber in. En die AI bubbel kan nog steeds barsten. Als wat we nu kunnen gebruiken ineens een veelvoud duurder wordt, dan valt in veel gevallen de business case om iets AI-assisted te doen ook gewoon weg.

[chime]

De management dromen van 10 x meer output leveren gaan wel niet uitkomen.
Dat halen de amerikaanse bedrijven die er langer mee bezig zijn ook niet.

Men is bij het bedrijf waar ik nu zit aan het ontdekken dat AI toch niet zo goedkoop is.
Elke developer heeft nu AI credits, budget van een 300 usd ... we zijn nu een week verder en honderden zitten daar al door.

Ook zal de business moeten kunnen volgen.

Een idioot kan met AI wel 10 x zo snel idiote code eruit kakken.

De mogelijke problemen dat ik nu wel zie met AI zijn:

• Het wordt lastiger voor junior developers om ervaring op te doen en ook inhoudelijk te begrijpen hoe alles werkt. Als je die kennis niet hebt wordt het lastig om te evalueren of AI goed bezig is of niet.
• Bij requirements of project schattingen gaat men soms nogal kort door de bocht, men wilt heel snel antwoorden krijgen, want met AI krijg je wel iets snel terug dat goed lijkt, maar of het altijd juist is

Voor offshore developers waarvoor je alles moet voorkauwen gaat het wel heel snel heel pijnlijk worden, want je bent met een agent vele malen productiever.
Dat ding heeft minder context nodig dan die ontwikkelaar aan de andere kant van de wereld, begrijpt de codebase beter en maakt betere code.

[NiGeLaToR]

Je kunt ook een vibe-code-fixer worden, ik begrijp dat er groeiende behoefte is.

Wat vooral lastig is, is dat de mensen die er over gaan doorgaans weinig kennis hebben van hoe dingen werken en nu eerst door de 'we gaan over op AI'-trein stappen en daarna de onherroepelijke 'dit werkt niet meer' en 'tokens zijn ook best duur geworden' alvorens er rationalisering intreedt. Hoopte een beetje richting dat laatste te gaan de komende tijd.

[107mb]

LED-Maniak schreef op dinsdag 9 juni 2026 @ 11:16:
Ik heb al een collega gehad die blind sudo rm -rf / heeft uitgevoerd 'omdat AI dat zei en ze er samen niet uit kwamen' waardoor een productiemachine stil is komen te staan.

dat lijkt mij een broodje aap verhaal.

[Dido]

Tsja...
Eerst ging al het ontwikkelwerk naar India, want dat was goedkoper.
Toen moest alles naar de cloud, want dat was goedkoper.
Toen moest alles in containers, want dat was goedkoper.
En nu moet alles met AI, want dat is goedkoper.

Intussen verdienen ze in India vergelijkbare salarissen als hier (en dat is leuk voor hun, maar Nederlandse bedrijven sourcen bijna niks meer naar ze uit), blijkt dat "de cloud" in de praktijk betekent dat de VS bij je data wil kunnen (of jouw toegang tot je data kan blokkeren!), blijken containers ingewikkelder dan gedacht (en duurder, tenzij je dure mensen inzet die wel weten hoe het goedkoper kan).

En AI zal echt nog wel kwalitatief beter worden dan nu, maar gaat natuurlijk lijnrecht in tegen de realiteit van energietransitie en -besparing. En dat betekent dat het op termijn niet goedkoper wordt, maar alleen maar duurder (want de stroom waarop de datacentra draaien wordt gewoon steeds duurder).

Waar je vroeger terecht kon stellen dat het goedkoper om langzame software software te "optimaliseren" door er meer ijzer tegenaan te gooien dan om een dure programmeur de zooit te laten verbeteren, gaat dat met AI de andere kant op: het "ijzer" gaat alleen maar duurder worden, of in ieder geval de energie die erin moet.

Uiteindelijk zal de wal het schip ook hier wel weer keren.

Intussen werk ik bij een overheidsorganisatie waar we überhaupt geen AI mogen gebruiken, want stel je voor dat Trump een stuk van onze sourcecode zou kunnen zien!

Sowieso wel een aanrader voor IT-ers die meewarig kijken naar de hypes in de IT-wereld: de overheid loopt jaren achter die hypes aan, en mist ze over het algemeen volkomen. En dat is niet omdat de overheid dom is, maar omdat ze andere prioriteiten stellen dan "we moeten de geilste, nieuwste technologieën implementeren" - proven technologie, stabiliteit en betrouwbaarheid zijn vele malen belangrijker.

Voor iemand die met cutting-edge technologie wil werken is dat niet leuk, voor iemand die zenuwachtig wordt van weer een nieuwe hype is het best relaxt...

[Dido]

107mb schreef op dinsdag 9 juni 2026 @ 11:53:
dat lijkt mij een broodje aap verhaal.

Ach, als je ziet hoe goed een terloopse "wat doet ALT-F4 ook alweer?" het deed op IRC... er zijn meer dan genoeg mensen die er geen enkele moeite mee hebben om botweg iets uit te voeren als ze daartoe worden aangespoord, zonder eerste na te denken wat ze doen.

[ouweklimgeit]

chime schreef op dinsdag 9 juni 2026 @ 11:40:

Een idioot kan met AI wel 10 x zo snel idiote code eruit kakken.

De mogelijke problemen dat ik nu wel zie met AI zijn:

• Het wordt lastiger voor junior developers om ervaring op te doen en ook inhoudelijk te begrijpen hoe alles werkt. Als je die kennis niet hebt wordt het lastig om te evalueren of AI goed bezig is of niet.

Eens, dit is een van de sleutels tot succes. In mijn ervaring doet Claude het in 95% van de gevallen uitstekend. Maar juist die 5% kunnen catastrofaal zijn en je zult zelf de taal machtig moeten zijn om dat eruit te pikken.

[LED-Maniak]

107mb schreef op dinsdag 9 juni 2026 @ 11:53:
[...]

dat lijkt mij een broodje aap verhaal.

Dat zou je denken.
Kwam er op neer dat er al eea. veranderd was en de machine al in de soep liep waardoor hij "helemaal overnieuw wilde beginnen". Het heeft er voor gezorgd dat we nu stricte guidelines hebben tav. het gebruik van AI.

Het zal je werkelijk verbazen wat sommige lui blindelings overtypen omdat ze er geen kaas van hebben gegeten en dan bij je langskomen "het werkt niet"

[ Voor 16% gewijzigd door LED-Maniak op 09-06-2026 12:00 ]

[diondokter]

10x is trouwens onzin. Dat betekent dat je in 2 dagen het werk van een hele maand kan doen (een maand heeft immers ~21 werkdagen). No way dat mensen in 2 dagen genoeg context kunnen verzamelen om een hele maand aan beslissingen te maken. En stel je hebt dat gedaan, dan moet je de 2 dagen daarna ook weer door. In een week moet je dus 2.5 maand aan werk hebben opgeleverd van dezelfde kwaliteit.

Als het bedrijf zo gebottleneckt is door het typen, dan wil eigenlijk niet eens weten wat ze daar doen.

Maar goed, de token subsidies worden langzaam minder nu. Je werkgever zal ondervinden dat het allemaal toch meer gaat kosten dan gedacht.

[TheGhostInc]

Apollyon schreef op maandag 8 juni 2026 @ 21:57:
Wat is het toekomsperspectief voor software developers?

Dat 'ondergemiddelde' programmeurs niet alleen maar een tijd en geldverspilling zijn, maar gewoon dadelijk niet meer bestaan. Ik doe al flink wat jaren typen en misschien geld wel "it takes one to know one", maar ik heb een partij kneuzen, prutsers en andere ellende langs zien komen die dadelijk echt geen werk meer hebben. Dat waren al dinosauriers, maar zijn nu gewoon prehistorie geworden.

(In 99% van de gevallen:)
Software is een middel om een doel te bereiken. Een programmeur is weer een middel om software te verkrijgen. (Je hebt nog dingen als low-code en je kunt het ook inkopen).
Als je niet snapt wat je schrijft, dan heb je nul toegevoegde waarde, dat was vroeger al, alleen nu wordt dat zo duidelijk dat het (bijna) pijnlijk wordt.

Daarnaast bouwen de meeste bedrijven voor een groot deel gewoon hetzelfde. "Account management', aanmelden, wachtwoord vergeten, super user of diverse rollen. Dat voegt technisch weinig toe aan de business, maar moet wel gebouwd en onderhouden worden. AI kan zeker generieke dingen vaak nog beter dan iemand die dat voor de eerste keer doet.

En nog los van dit alles:
De gemiddelde software ontwikkelomgeving is 'ok'.
Loop bij een gemiddeld bedrijf naar binnen en vraag de quick start guide voor developers (die hebben we bij de vorige starter gelukkig nog bijgewerkt, loopt maar een paar maanden achter), de documentatie (de gezichten worden zuurder) en daarna hangt het een beetje af van de organisatie, maar zodra je richting Non functionals gaat wordt het meestal al snel pijnlijk. Performance testen komen er bij performance problemen, security mist ook regelmatig, privacy is leuk, maar de developer kan gewoon bij de hele DB en ga zo maar door.

We zien AI ook bij autonome auto's, waarbij die bijna vergelijkbaar zijn met de gemiddelde bestuurder.
Als we de track record van een software ontwikkelaar zouden nemen als benchmark voor autonome auto's, dan mag je elke dag nieuwe bumpers erop zetten, omdat stoppen ook gebeurd als je op je voorganger botst. En de kleine kinderen rijdt hij wel aan, maar niet dood, want hij kan niet harder dan stapvoets, 'dus dan valt de schade nog best mee'.

Dus @Apollyon, ik zou me niet teveel zorgen maken:
Of je bedrijf doet zulke simpele dingen dat het sowieso een zware dobber gaat krijgen om te overleven, of je wordt nu gedwongen om veel verder te begrijpen wat het bedrijf nu exact doet en waar er geld mee verdient wordt.
De tijd is dadelijk wel voorbij dat je lekker 36 uurtjes, met je koptelefoontje op, een vorstelijk salaris binnen harkt 'omdat niemand precies begrijpt wat je doet'.

[Drardollan]

Hoewel AI echt wel een gamechanger is lijkt mij de beslissing van jullie management zo ongeveer de domste denkbaar. AI is een prachtig hulpmiddel, zeker voor ontwikkelaars en ander IT personeel, maar zonder de juiste input en kennis doet het niks.

Mooi voorbeeld is een klant van mij, die denkt ook het wiel uitgevonden te hebben. Heeft middels ChatGPT en Vibecoding een simpele tool geprobeerd te bouwen. Uren tijd ingestopt. Nu moet het uitgerold worden en blijkt dat het misschien toch niet zo handig is dat iedereen NodeJS moet installeren, local admin moet zijn, er maar 1 persoon in de tool kan werken omdat er een file op Sharepoint bijgewerkt wordt met alle gevolgen van dien en de boel vaak niet start omdat de OneDrive -> Sharepoint koppeling er nog niet is.

Top opgelost hoor. Zonde van je licentiekosten en uren zinloos kloppen van prompts. Dat krijg je zonder kennis van zaken.

Daarom denk ik dat het allemaal wel meevalt, het werk veranderd (net als dat al honderden jaren gebeurd door allerlei uitvindingen) maar verdwijnt niet. Meegaan met de tijd is prima, maar net als je nu ziet dat het elektriciteitsnet vol is omdat simpele zielen maar elektrische auto's, warmtepompen en kookplaten blijven pushen vanuit de overheid gebeurd dat met AI. Je kan alles omgooien, over 12 maanden blijkt er geen zak meer te werken en al je goede personeel is of afgestompt of allang vertrokken. Wat heb je dan gewonnen?

Ik zou het even aanzien om te zien wat er gebeurd, en anders: hop hop!

[Drardollan]

TheGhostInc schreef op dinsdag 9 juni 2026 @ 12:38:
[...]

Dat 'ondergemiddelde' programmeurs niet alleen maar een tijd en geldverspilling zijn, maar gewoon dadelijk niet meer bestaan. Ik doe al flink wat jaren typen en misschien geld wel "it takes one to know one", maar ik heb een partij kneuzen, prutsers en andere ellende langs zien komen die dadelijk echt geen werk meer hebben. Dat waren al dinosauriers, maar zijn nu gewoon prehistorie geworden.

En waar gaan programmeurs dan leren programmeren? Als je niet aan de basis kan beginnen, wat ga je dan krijgen? Juist bij de basis vind er normaal een schifting plaats.

Het tweede stuk is nonsens. Ik kan mij herinneren dat er precies zo over Cobolt/Pascal/Delphi (en meer) programmeurs gedacht werd. Ondertussen zijn die schatjehemeltje rijk geworden omdat niemand hun werk kon doen

[DjoeC]

In de 80er jaren had IBM een 4/5G produkt in ontwikkeling waar je functionele specificaties in kon stoppen waarna er een complete applicatie aan de achterkant kwam uitrollen. Specificatiewijziging betekende dat de totale applicatie opnieuw gestructureerd en uitgegenereerd werd. Ben daar ooit voor bij IBM Atlanta geweest. De naam ben ik kwijt - het is ook nooit iets geworden - maar m'n geheugen blijft "Signon" oid aangeven.

Fast forward vandaag AI: AI kan een prima tool zijn om code te (laten) genereren. Maart, zoals al sinds het begin van automatisering en administratieve organisatie: Alles hangt af van de kwaliteit van de vraagstelling.

Software developer is in mijn beleving iets heel anders dan programmeur/codeklopper. Een software developer zorgt dat de vraagstelling correct is, dat de functionele specificaties en de technische eisen - inclusief de uitzonderingen/bijzondere situaties - correct en compleet zijn en bij AI vertaalt naar de correcte prompts. Daarnaast zal de software developer voldoende kennis hebben om het gegenereerde te kunnen beoordelen op kwaliteit en eventuele ongewenste toevoegingen - ja, ik verwacht dat er op enig moment ongewenste code injectie mee zal komen, en is in staat om het gegenereerde voldoende inhoudelijk te testen.

Ben je nu alleen een codeklopper dan is er (en was er al) geen toekomst meer voor je. ZOrg dat je naar boven beweegt in de waardeketen. AI snapt je bussiness case niet als je die niet aan de AI meld. Zorg dat jij die wel snapt.

AI kan nog steeds niets meer dan worden (code) in een bepaalde volgorde zetten. AI kan nog niet nadenken - dat moet jij nog steeds blijven doen. En hoe het er over 10 jaar uitziet? Niemand die het weet.

Overigens verwacht ik dat op zeer korte termijn banen waar handwerk bij komt kijken (installatie, timmerman, onderhoud) veel beter in de markt komen te liggen dan welke kantoorbaan die een PC vereist dan ook.

[wiemelen]

Dido schreef op dinsdag 9 juni 2026 @ 11:54:
Intussen werk ik bij een overheidsorganisatie waar we überhaupt geen AI mogen gebruiken, want stel je voor dat Trump een stuk van onze sourcecode zou kunnen zien!

Sowieso wel een aanrader voor IT-ers die meewarig kijken naar de hypes in de IT-wereld: de overheid loopt jaren achter die hypes aan, en mist ze over het algemeen volkomen. En dat is niet omdat de overheid dom is, maar omdat ze andere prioriteiten stellen dan "we moeten de geilste, nieuwste technologieën implementeren" - proven technologie, stabiliteit en betrouwbaarheid zijn vele malen belangrijker.

Voor iemand die met cutting-edge technologie wil werken is dat niet leuk, voor iemand die zenuwachtig wordt van weer een nieuwe hype is het best relaxt...

Niet alleen de overheid loopt (ver) achter op dat gebied.
Talloze bedrijven, van MKB tot grote(re) bedrijven zijn hier nog niet (voldoende) mee bezig.
Laat staan dat ze gelijk goed geschoolde werknemers hebben die dit trekken.

De AI lead van mijn bedrijf had een mooie omschrijving voor AI: "AI is de automatisering van de automatisering".
Best leuke verwoording ... maar te bedenken dat er talloze bedrijven zijn die nog niets/niet veel/niet alles geautomatiseerd hebben. Die zie ik nog niet zo snel succesvol op de AI trein springen.

[Drardollan]

wiemelen schreef op dinsdag 9 juni 2026 @ 15:04:
[...]

Niet alleen de overheid loopt (ver) achter op dat gebied.
Talloze bedrijven, van MKB tot grote(re) bedrijven zijn hier nog niet (voldoende) mee bezig.
Laat staan dat ze gelijk goed geschoolde werknemers hebben die dit trekken.

De AI lead van mijn bedrijf had een mooie omschrijving voor AI: "AI is de automatisering van de automatisering".
Best leuke verwoording ... maar te bedenken dat er talloze bedrijven zijn die nog niets/niet veel/niet alles geautomatiseerd hebben. Die zie ik nog niet zo snel succesvol op de AI trein springen.

Je vergeet voor het gemak ook even dat AI nog bijzonder nieuw en duur is. Voordat de mainstream bedrijven op een trend springen ben je wel een paar jaar verder. De grote bedrijven kunnen wat makkelijker experimenteren, meer mensen - meer kennis - meer geld - meer tijd. Ik denk dat het gemiddelde bedrijf afwacht tot de trein voorbij geraasd is. Laat het zich eerst maar bewijzen. Het zal niet de eerste hype zijn die (grotendeels) overwaait.

[Widow]

Ik zou mij er geen zorgen over maken, verandering is van alle tijden. Ergens in de jaren 50 gingen koekjesfabrieken niet meer met de hand het deeg mixen, maar gingen grote machines dat doen. Het was niet dat er daardoor geen werk meer was, het werk veranderde van deeg kneden naar machines aansturen want de vraag naar koekjes is niet veranderd. Hetzelfde toen paard & wagen werd vervangen voor de auto 100 jaar geleden. Er was minder behoefte aan paarden en meer aan mensen die autos kunnen onderhouden, maar de behoefte aan vervoer bleef.

Als je die lijn doortrekt denk ik dat de vraag naar IT oplossingen niet zal verminderen, maar de manier waarop we die leveren wel. Dan kan management wel denken dat ze ineens 10x meer output hebben, maar is er ook 10x meer vraag? Heb je na de zomer ineens 10x zoveel klanten of komen bestaande klanten met 10x zoveel vragen? Waarschijnlijk niet dus neem het met een korrel zout. Persoonlijk zou ik geneigd zijn het management een beetje te plagen met "En als we straks 10x zoveel output kunnen leveren he.. zorg jij dan voor 10x zoveel klanten/producten?" om te laten merken dat 10x zoveel capaciteit niks betekend als niemand op de output zit te wachten.

Als je geen zin hebt om AI gegenereerde MR's te checken zou ik kijken of je elders in de waardeketen je kennis/inzicht/ervaring kwijt kan. Een jaar of zes geleden ben ik uit de techniek gestapt, mn laatste project was met Azure. Leuk spul maar ik zag er geen uitdaging in en was daarnaast ook klaar met MSFT. Ik was altijd de IT-er die graag met de klant praatte en ook geen moeite had met dingetjes presenteren, dus daar heb ik mn werk van gemaakt nu.

[Zebby]

Dido schreef op dinsdag 9 juni 2026 @ 11:54:
Tsja...
Eerst ging al het ontwikkelwerk naar India, want dat was goedkoper.
Toen moest alles naar de cloud, want dat was goedkoper.
Toen moest alles in containers, want dat was goedkoper.
En nu moet alles met AI, want dat is goedkoper.

Intussen verdienen ze in India vergelijkbare salarissen als hier (en dat is leuk voor hun, maar Nederlandse bedrijven sourcen bijna niks meer naar ze uit), blijkt dat "de cloud" in de praktijk betekent dat de VS bij je data wil kunnen (of jouw toegang tot je data kan blokkeren!), blijken containers ingewikkelder dan gedacht (en duurder, tenzij je dure mensen inzet die wel weten hoe het goedkoper kan).

En AI zal echt nog wel kwalitatief beter worden dan nu, maar gaat natuurlijk lijnrecht in tegen de realiteit van energietransitie en -besparing. En dat betekent dat het op termijn niet goedkoper wordt, maar alleen maar duurder (want de stroom waarop de datacentra draaien wordt gewoon steeds duurder).

Waar je vroeger terecht kon stellen dat het goedkoper om langzame software software te "optimaliseren" door er meer ijzer tegenaan te gooien dan om een dure programmeur de zooit te laten verbeteren, gaat dat met AI de andere kant op: het "ijzer" gaat alleen maar duurder worden, of in ieder geval de energie die erin moet.

Uiteindelijk zal de wal het schip ook hier wel weer keren.

Intussen werk ik bij een overheidsorganisatie waar we überhaupt geen AI mogen gebruiken, want stel je voor dat Trump een stuk van onze sourcecode zou kunnen zien!

Sowieso wel een aanrader voor IT-ers die meewarig kijken naar de hypes in de IT-wereld: de overheid loopt jaren achter die hypes aan, en mist ze over het algemeen volkomen. En dat is niet omdat de overheid dom is, maar omdat ze andere prioriteiten stellen dan "we moeten de geilste, nieuwste technologieën implementeren" - proven technologie, stabiliteit en betrouwbaarheid zijn vele malen belangrijker.

Voor iemand die met cutting-edge technologie wil werken is dat niet leuk, voor iemand die zenuwachtig wordt van weer een nieuwe hype is het best relaxt...

Even een stukje context, ik zit toevallig in de selectiefase voor een ontwikkelclub dus heb wat frisse kijk op dit soort verhalen.

Nederlandse partijen vragen ~120-150 euro per uur voor hun mensen afhankelijk van de rol. Al werken ze veelal agile, ze vragen veel tijd voor de opdracht (ruim 3-4x zo lang) en willen niet echt flexibel meewerken. Ze zeggen te werken met AI, maar niet leidend.

Polen en Tsjechië zitten rond de ~40-60 euro per uur, werken flexibel en denken mee, pakken door vanuit bestaande templates en zijn zo ruim 2x+ zo snel als NL.

India kosten de programmeurs 25-35 euro per uur, looptijd vergelijkbaar met NL, maar dan voor dus een fractie van het geld. Zorgen over de kwaliteit weten ze niet weg te nemen.

Nu is dit nog steeds een N=~10, maar dat India vergelijkbaar is met hier kan ik op geen enkele wijze beamen, en er is zeker nog werk voor programmeurs.

[Standeman]

chime schreef op dinsdag 9 juni 2026 @ 11:40:
De management dromen van 10 x meer output leveren gaan wel niet uitkomen.
Dat halen de amerikaanse bedrijven die er langer mee bezig zijn ook niet.

Men is bij het bedrijf waar ik nu zit aan het ontdekken dat AI toch niet zo goedkoop is.
Elke developer heeft nu AI credits, budget van een 300 usd ... we zijn nu een week verder en honderden zitten daar al door.

Ook zal de business moeten kunnen volgen.

Een idioot kan met AI wel 10 x zo snel idiote code eruit kakken.

De mogelijke problemen dat ik nu wel zie met AI zijn:

• Het wordt lastiger voor junior developers om ervaring op te doen en ook inhoudelijk te begrijpen hoe alles werkt. Als je die kennis niet hebt wordt het lastig om te evalueren of AI goed bezig is of niet.
• Bij requirements of project schattingen gaat men soms nogal kort door de bocht, men wilt heel snel antwoorden krijgen, want met AI krijg je wel iets snel terug dat goed lijkt, maar of het altijd juist is

Voor offshore developers waarvoor je alles moet voorkauwen gaat het wel heel snel heel pijnlijk worden, want je bent met een agent vele malen productiever.
Dat ding heeft minder context nodig dan die ontwikkelaar aan de andere kant van de wereld, begrijpt de codebase beter en maakt betere code.

Tijdje geleden een presentatie gezien van dev-werk bij een vrij groot bedrijf waar ze nu experimenteren alles door AI te laten schrijven en alleen maar PR's reviewen. Moet eerlijk zeggen dat ik onder de indruk was en het echt hard gaat (tegen de 10x) qua development. Echter verbanden ze per developer er wel $5000 aan tokens er door heen.

En dan te bedenken dat AI subscriptions nog in de super goedkope (en verlieslijdende!) fase zit om betalende klanten binnen te halen. Ik gok dat die prijs ook wel x5 zal gaan binnen nu en een paar jaar. En dan wordt het allemaal niet zo rendabel meer.

[djluc]

Ik ben vooral benieuwd hoeveel bedrijven ook echt op het level zitten dat complexe software correct geschreven wordt op basis van de prompts. Met Claude max loop ik er toch vaak tegenaan dat er "gefantaseerd" wordt waarbij de AI denkt iets moois gemaakt te hebben maar het toch niet 100% blijkt te kloppen.

Afhankelijk van wat je maakt natuurlijk is dat in de meeste gevallen zeer onwenselijk. Er zit naar mijn idee dan ook heel veel werk om het daadwerkelijk aansturen en controleren van de AI resultaten.

En inderdaad als je er onbeperkt tokens tegenaan gooit kan je 2-3 implementaties van hetzelfde laten maken, cross laten checken en zo met een grote hoeveelheid cash tot snellere resultaten komen. Maar dan nog vraag ik het me af eerlijk gezegd.

Tegelijkertijd lees je dan de posts en interviews met de mensen van bijvoorbeeld Anthropic en dan zou er al veel meer mee moeten kunnen dan mij in elk geval lukt.

Maar gezien je rol als developer denk ik dat er heel veel werk blijft zijn. Het zal zeker veranderen. Het structureren van vraagstukken als developer is echt niet snel overgenomen. Vaak ook omdat je informatie over werkprocessen, eisen uit regelgeving etc moet structureren. Een bepaalde analytische blik is daarbij nog steeds nodig.

[diondokter]

djluc schreef op dinsdag 9 juni 2026 @ 16:18:
Tegelijkertijd lees je dan de posts en interviews met de mensen van bijvoorbeeld Anthropic en dan zou er al veel meer mee moeten kunnen dan mij in elk geval lukt.

De mensen van WC-Eend zeggen dat hun toiletten erg schoon zijn?

[olafmol]

My 2 cents: code schrijven is niet het probleem. Het bedenken en uitwerken van de functionele en technische specificaties, de edge-cases, de "wat als" scenarios, de lastige vragen etc. Dat is waar de tijd, ervaring en complexiteit in gaan zitten. En die gaan AI niet voor ons oplossen. En "de business" of PO oid kan vaak maar tot op een bepaald (high)level specificaties aanleveren.

Wat daarnaast ook "interessant" begint te worden met de adoptie van AI-coding agents: drift explodeert. In complexere architecturen met veel lagen en moving parts zijn coordinatie en integratie van levensbelang. En dat was uberhaupt op "human velocity" al een uitdaging om de boel geintegreerd te krijgen en te houden, maar nu losse developers en teams ineens 10x zo snel code opleveren, zie je dat ze nog veel sneller en verder uit elkaar beginnen te bewegen. Tegen de tijd dat de integratie-issues boven water komen is iedereen alweer kilometers verder, en wordt het dus steeds duurder en complexer om de boel weer te repareren.

En dan komen we bij het laaste punt: context en geheugen. Ja, dat groeit en er komen steeds meer hulpmiddelen voor, maar bij voldoende scope en complexiteit komt er geheid een moment dat de AI agents gaan compressen of nog maar een beperkte scope van het landschap en de codebase hebben, en/of hun "train of thought" verliezen. Combineer dit met andere teams die andere onderdelen van je applicatie-landchap of architectuur (door)ontwikkelen of onderhouden, en je krijgt echt een clusterfuck.

Als je dan de AI de boel moet laten fixen, omdat je zelf niet meer op code-level kan overzien wat er nu allemaal gegenereert is (want velocity, dus geen tijd om er zelf nog diep in te duiken, kortom: knowledge debt ipv technical debt) is de kans dat je AI agent probleem A fixed, maar nieuwe problemen B, C en D introduceert, die ook nog eens bij teams X, Y en Z additionele integratie issues creeren, heel serieus aanwezig. En kom daar nog maar eens uit.

Kortom: AI agents hebben zeker waarde, en ze zullen niet meer verdwijnen uit onze toolkits, maar momenteel zijn het nog vrij onbetrouwbare collegas, en als je ze aanspreekt op hun fouten leren ze daar ook niet van. De vraag is of en wanneer dat wel goed gaat komen, bij voorkeur voordat de lucht uit de AI bubbel loopt omdat bedrijven niet of niet genoeg ROI kunnen vinden.

Dus toch nog ff met de handjes aan het stuur blijven, en AI als die junior stagiaire benaderen, die je wel kan ondersteunen maar die je echt goed in de gaten moet houden en waarvan je al het werk moet controleren.

[locke960]

Standeman schreef op dinsdag 9 juni 2026 @ 16:08:
[...]

Tijdje geleden een presentatie gezien van dev-werk bij een vrij groot bedrijf waar ze nu experimenteren alles door AI te laten schrijven en alleen maar PR's reviewen. Moet eerlijk zeggen dat ik onder de indruk was en het echt hard gaat (tegen de 10x) qua development. Echter verbanden ze wel per developer er wel $5000 aan tokens er door heen.

Dat is dus een goede deal. 10x de output voor slechts $5000 meer. 10 developers meer zijn heel wat duurder. Die tokens mogen dus nog fors duurder worden voordat dit niet meer rendabel is.

Dan gaan we er wel vanuit dat alles goed gaat en goed blijft gaan. "De echte prijs betaal je later" is een bekend verschijnsel bij nieuwe technologieën.

[olafmol]

diondokter schreef op dinsdag 9 juni 2026 @ 16:20:
[...]

De mensen van WC-Eend zeggen dat hun toiletten erg schoon zijn?

idd Anthropic is vooral heel goed in (guerilla) marketing. Desalnietemin steekt Claude wel met kop en schouders boven de concurrentie uit in mijn ervaring.

[djluc]

diondokter schreef op dinsdag 9 juni 2026 @ 16:20:
[...]

De mensen van WC-Eend zeggen dat hun toiletten erg schoon zijn?

Hahaha ja dat zeker

Maar aan de andere kant zie je bedrijven serieuze bedragen investeren in deze workflows dus er zullen ook resultaten behaald worden. Als ik zie wat ik er nu uit krijg vind ik het ook zeker al knap wat kan maar kost het nog relatief veel begeleiding. Is het sneller dan handmatig coden, ja denk het wel. Maar je moet strak sturen lijkt het om het ook een logisch en correct geheel te maken.

[olafmol]

djluc schreef op dinsdag 9 juni 2026 @ 16:33:
[...]

Hahaha ja dat zeker

Maar aan de andere kant zie je bedrijven serieuze bedragen investeren in deze workflows dus er zullen ook resultaten behaald worden. Als ik zie wat ik er nu uit krijg vind ik het ook zeker al knap wat kan maar kost het nog relatief veel begeleiding. Is het sneller dan handmatig coden, ja denk het wel. Maar je moet strak sturen lijkt het om het ook een logisch en correct geheel te maken.

Nee dat is (nog?) niet zo. Ik werk voor een Silicon Valley bedrijf dat midden in de "AI-storm" zit en wij doen ook heeel veel met Antrophic, zowel intern, als op ons platform, als voor onze klanten. Het is nu 100% FOMO, maw "dit moeten we doen, anders missen we mss de boot straks" en ook een stukje AI-psychose. Voeg daarbij de druk van VC investeerders op leadership bij (iedereen doet het, dus moeten jullie dit ook doen, anders zijn we straks toast) en we hebben een leuke mix.

Echt niemand kan momenteel de ROI van AI investeringen en token-budgets berekenen. Dat kon al niet met engineering-hours, laat staan met "tokens".

[Harm_H]

"We stoppen met zelf code schrijven... Na de zomer 🤣 "

Dit gaat nu nog niet gebeuren. Al deze AI chaos gaat zorgen voor een wildgroei aan bugs. AI is leuk voor prototypes, boilerplate code en 20% meer productiviteit.

Verder voorzie ik meer burnout want code reviews zijn 3 keer meer intensief dan zelf schrijven.

Ten slotte, je salaris vraag. De samenleving zoekt nu vaklui die werken met de handen. Het IT vak is nu niet meer voor de generieke 'hbo rechten' die ergens inrolt.

[Sissors]

Zebby schreef op dinsdag 9 juni 2026 @ 15:44:
[...]

Even een stukje context, ik zit toevallig in de selectiefase voor een ontwikkelclub dus heb wat frisse kijk op dit soort verhalen.

Nederlandse partijen vragen ~120-150 euro per uur voor hun mensen afhankelijk van de rol. Al werken ze veelal agile, ze vragen veel tijd voor de opdracht (ruim 3-4x zo lang) en willen niet echt flexibel meewerken. Ze zeggen te werken met AI, maar niet leidend.

Polen en Tsjechië zitten rond de ~40-60 euro per uur, werken flexibel en denken mee, pakken door vanuit bestaande templates en zijn zo ruim 2x+ zo snel als NL.

India kosten de programmeurs 25-35 euro per uur, looptijd vergelijkbaar met NL, maar dan voor dus een fractie van het geld. Zorgen over de kwaliteit weten ze niet weg te nemen.

Nu is dit nog steeds een N=~10, maar dat India vergelijkbaar is met hier kan ik op geen enkele wijze beamen, en er is zeker nog werk voor programmeurs.

Maar zijn die 1 op 1 te vergelijken? Als ik kijk wat het gewoon kost aan salarissen bij de multinational waar ik werk, dan kosten juniors in India geen drol. Seniors zijn nog wel wat goedkoper, maar verschil wordt beperkter (wat vooral hier helpt ook is dat ze veel lagere lasten hebben, hun bureau kost een hoop minder, de schoonmaakster is effectief gratis, werkgeverslasten zijn veel lager, etc). Principals wordt het redelijk gelijk, daarboven wordt Nederland goedkoper (eg Vice Presidents enzo).

[fockarty]

107mb schreef op dinsdag 9 juni 2026 @ 11:53:
[...]

dat lijkt mij een broodje aap verhaal.

Nou geloof me ze zijn maar dat gaat dan net zo fout als een dba'er een document opstelt wat niet helemaal klopt. Keer meegemaakt dat een collega iets van rm -rf inno* intikte want ja het stond er zo..

[Furion2000]

Dido schreef op dinsdag 9 juni 2026 @ 11:54:
Tsja...
Eerst ging al het ontwikkelwerk naar India, want dat was goedkoper.
Toen moest alles naar de cloud, want dat was goedkoper.
Toen moest alles in containers, want dat was goedkoper.
En nu moet alles met AI, want dat is goedkoper.

Intussen verdienen ze in India vergelijkbare salarissen als hier (en dat is leuk voor hun, maar Nederlandse bedrijven sourcen bijna niks meer naar ze uit), blijkt dat "de cloud" in de praktijk betekent dat de VS bij je data wil kunnen (of jouw toegang tot je data kan blokkeren!), blijken containers ingewikkelder dan gedacht (en duurder, tenzij je dure mensen inzet die wel weten hoe het goedkoper kan).

En AI zal echt nog wel kwalitatief beter worden dan nu, maar gaat natuurlijk lijnrecht in tegen de realiteit van energietransitie en -besparing. En dat betekent dat het op termijn niet goedkoper wordt, maar alleen maar duurder (want de stroom waarop de datacentra draaien wordt gewoon steeds duurder).

Waar je vroeger terecht kon stellen dat het goedkoper om langzame software software te "optimaliseren" door er meer ijzer tegenaan te gooien dan om een dure programmeur de zooit te laten verbeteren, gaat dat met AI de andere kant op: het "ijzer" gaat alleen maar duurder worden, of in ieder geval de energie die erin moet.

Uiteindelijk zal de wal het schip ook hier wel weer keren.

Intussen werk ik bij een overheidsorganisatie waar we überhaupt geen AI mogen gebruiken, want stel je voor dat Trump een stuk van onze sourcecode zou kunnen zien!

Sowieso wel een aanrader voor IT-ers die meewarig kijken naar de hypes in de IT-wereld: de overheid loopt jaren achter die hypes aan, en mist ze over het algemeen volkomen. En dat is niet omdat de overheid dom is, maar omdat ze andere prioriteiten stellen dan "we moeten de geilste, nieuwste technologieën implementeren" - proven technologie, stabiliteit en betrouwbaarheid zijn vele malen belangrijker.

Voor iemand die met cutting-edge technologie wil werken is dat niet leuk, voor iemand die zenuwachtig wordt van weer een nieuwe hype is het best relaxt...

Wel gek dan dat een ex-collega nu PO is van een AI team bij een overheid en bij mijn overheidsklus gratis Claude tokens beschikbaar zijn.

Veel mensen in mijn netwerk zitten/zaten bij overheden en de verspilling van resources (geld) zou menig mens doen laten huilen. Er zit > 50% helemaal ingebed met Microsoft/Redhat of andere Amerikaanse partijen. Is de schijnzelfstandigheid misschien gedaald, maar zijn er in de plaats gedetacheerde mensen gekomen.

Er zijn afdelingen die 'goed' presteren, maar over het algemeen is het drama. Ik hoorde laatst van iemand die 4x in een meeting zat van een uur waarin ze zaten te kijken naar een firewall change die steeds faalde. Het duurt al >6 maanden omdat afspraken met de externe partij lastig zijn. Want firewall management was natuurlijk outsourced.

Overheid verschuilt zich achter stabiliteit en betrouwbaarheid, maar het is gewoon angst en bureaucratie en gaat minstens zo vaak op zijn gat als een commerciële partij.

(mini rant ri de overheid, niet per se ri jou )

on topic:
AI voelt als de eerste keer in een ferrari rijden. Je rijdt al snel te hard (pompt er erg snel shit code uit) en hebt echt wel die gordels nodig (guardrails). Maar eenmaal wat training en er komt wel degelijk uit wat ik wil in hoog tempo. Het moeilijkste van alles vind ik de agent in bedwang houden. In minder woorden hetzelfde zeggen en niet 100 tests laten schrijven voor iets wat ook met 2 tests gedaan kan worden.

Ik ben niet zo bang voor mijn baan en er ontstaan sowieso volgende bottlenecks waardoor x10 productiviteit niet zomaar mogelijk is.

[Liegebeest]

chime schreef op dinsdag 9 juni 2026 @ 11:40:
Voor offshore developers waarvoor je alles moet voorkauwen gaat het wel heel snel heel pijnlijk worden, want je bent met een agent vele malen productiever.

Ha! Maar wat nu als ze de onshore mensen alsnog vervangen met offshore en hen de AI tools geven? Was het nou Accenture of Cognizant die hun medewerkers afrekent op hoe veel ze AI toepassen?

Dat heb ik nl ook al gezien als management strategie.

[ Voor 5% gewijzigd door Liegebeest op 10-06-2026 06:17 ]

[Bryan Vreijsen]

Mooi om te zien dat de consensus hier de spijker op z'n kop slaat: het management van TS vaart blind op een hype, maar de technische realiteit gaat ze na de zomer keihard inhalen. Volledig overstappen op prompten en alleen nog merge requests reviewen klinkt leuk voor de ROI-sheets, maar in de praktijk creëer je een gigantische knowledge debt en architectural drift waar een development-team uiteindelijk op leegloopt—code reviewen van een onbetrouwbare AI-agent is immers vaak vele malen intensiever en frustrerender dan het zelf schrijven van logica.

Je waarde als software developer verschuift simpelweg van puur syntax typen naar het bewaken van de overkoepelende systemen en architectuur, en die diepgaande kennis wordt straks juist exclusiever en waardevoller wanneer dit soort rigide 'vibe coding'-projecten onvermijdelijk vastlopen.

[Glashelder]

Standeman schreef op dinsdag 9 juni 2026 @ 16:08:
[...]


Tijdje geleden een presentatie gezien van dev-werk bij een vrij groot bedrijf waar ze nu experimenteren alles door AI te laten schrijven en alleen maar PR's reviewen. Moet eerlijk zeggen dat ik onder de indruk was en het echt hard gaat (tegen de 10x) qua development. Echter verbanden ze per developer er wel $5000 aan tokens er door heen.

En dan te bedenken dat AI subscriptions nog in de super goedkope (en verlieslijdende!) fase zit om betalende klanten binnen te halen. Ik gok dat die prijs ook wel x5 zal gaan binnen nu en een paar jaar. En dan wordt het allemaal niet zo rendabel meer.

Ik begrijp echt niet hoe je als developer er zo krankzinnig veel tokens er doorheen kan jassen. Wij zitten zelf bij ons bedrijf op een Claude Teams abo en ik haal daar eigenlijk nooit de limiet van, tenzij ik met 3 projecten tegelijkertijd bezig ben. Van die context switching wordt je echter helemaal krankjorum. Dat is mentaal echt niet gezond dus daar ben ik mee gestopt.

Maar als je tegen de 5000 dollar aan extra usage per maand erdoorheen brast dan ben je naar mijn mening niet heel efficiënt bezig met AI. Veel te grote codebases laten inladen en te vaak is my best guess.

Harm_H schreef op dinsdag 9 juni 2026 @ 16:37:
"We stoppen met zelf code schrijven... Na de zomer 🤣 "

Dit gaat nu nog niet gebeuren. Al deze AI chaos gaat zorgen voor een wildgroei aan bugs. AI is leuk voor prototypes, boilerplate code en 20% meer productiviteit.

Verder voorzie ik meer burnout want code reviews zijn 3 keer meer intensief dan zelf schrijven.

Ten slotte, je salaris vraag. De samenleving zoekt nu vaklui die werken met de handen. Het IT vak is nu niet meer voor de generieke 'hbo rechten' die ergens inrolt.

CodeRabbit.

Is ook nog eens veel beter in reviews dan mensen. Je moet niet de illusie hebben dat je als mens die snelheid kan bijhouden. De mens is de zwakste schakel in deze keten: door alles met de hand te reviewen breng je je velocity terug tot wat het was of dichtbij daar.

Nee code reviews laat je doen door een andere AI. Dat klinkt belachelijk, maar werkt verrassend goed.

Wat de rest van je reactie betreft: waar komt toch dat idiote idee vandaan dan wij mensen zoveel beter zijn in programmeren dan AI? Als we juist iets bewezen hebben de afgelopen 50 jaar, is dat wij mensen belachelijk slecht zijn in softwareontwikkeling. Zoveel bugs als we achterlaten..

[NiGeLaToR]

@Glashelder op wiens programmeerwerk is die AI getraind dan dat die geen fouten meer maakt?

[Glashelder]

NiGeLaToR schreef op woensdag 10 juni 2026 @ 07:35:
@Glashelder op wiens programmeerwerk is die AI getraind dan dat die geen fouten meer maakt?

AI is getraind op codebases met menselijke fouten maar men vergeet nog wel eens dat de fixes voor die fouten veelal ook in de trainingsdata zitten.

[Liegebeest]

djluc schreef op dinsdag 9 juni 2026 @ 16:33:
[...]

aan de andere kant zie je bedrijven serieuze bedragen investeren in deze workflows dus er zullen ook resultaten behaald worden.

Hoho, dat is een omgekeerde argumentatie. Jij gaat er van uit dat bedrijven dit soort trajecten alleen starten wanneer ze bewijs hebben dat t voor hen kosteneffectief werkt. Dat is lang niet altijd zo.

Case in point, bedrijf in mijn netwerk gooit bijna honderd man tegen een project aan om een volledig AI-driven delivery pipeline te maken. Dus inderdaad dat de developer alleen context en design levert, waarna de AI alles doet tot en met deployment (met HitL). Zij hebben geen business case met bewezen ervaringen op kleine schaal. Ze varen op het geloof dat het gaat werken.

[ Voor 3% gewijzigd door Liegebeest op 10-06-2026 10:10 ]

[Strawberry_1985]

_{@Apollyon Niet inhoudelijk, maar: Haal je post even door een spellingscontrole. Niet onaardig bedoeld, maar het staat vol met foutjes.}

[JJ Le Funk]

is het nog wel een hype te noemen als je de succesvolle toepassing ervan ziet bij met name startups?
de angst van TS lijkt mij reëel, 't wordt een stuk saaier. en door AI ontstaat er de verwachting dat 1 developer veel meer werk kan verstouwen met onrealistische verwachtingen tot gevolg.
ik voorzie toename voor burnouts door deze 2 factoren: minder arbeidsvreugde en meer werkdruk.

[djluc]

Liegebeest schreef op woensdag 10 juni 2026 @ 08:50:
[...]

Hoho, dat is een omgekeerde argumentatie. Jij gaat er van uit dat bedrijven dit soort trajecten alleen starten wanneer ze bewijs hebben dat t voor hen kosteneffectief werkt. Dat is lang niet altijd zo.

Case in point, bedrijf in mijn netwerk gooit bijna honderd man tegen een project aan om een volledig AI-driven delivery pipeline te maken. Dus inderdaad dat de developer alleen context en design levert, waarna de AI alles doet tot en met deployment (met HitL). Zij hebben geen business case met bewezen ervaringen op kleine schaal.

Haha, ja die kant van het verhaal is ook waar. Er zijn meerdere scenario's waaronder: het werkt niet, het werkt een beetje autonoom en het werkt turbo autonoom, beetje goedkeuren en 10x performance.

Er is nog weinig concrete info buiten organisaties heb ik het idee over of het echt werkt.

[Jobjl]

Even een andere blik van een devver die bij een MKB werkt.
Wij zijn sinds vorig jaar begonnen met AI, inmiddels schrijven we voor het grotere werk vaak uitgebreide specs. De AI bouwt het en wij reviewen het. Het kleine spul wat snel te coden is doen wij nog steeds zelf.

Waar ik echter een verschuiving in zie is bij het business gedeelte. Wij hebben nog steeds een afdeling dat klanten binnenhaalt. Echter het stukje waar een bestaande klant wat wil veranderen (oa RFC's), dat doen inmiddels de "technische" teams zelf. Business team is inmiddels iets gekrompen en wij hebben vaker contact met de klant.

[HenkEisDS]

Drardollan schreef op dinsdag 9 juni 2026 @ 14:39:
[...]

En waar gaan programmeurs dan leren programmeren? Als je niet aan de basis kan beginnen, wat ga je dan krijgen? Juist bij de basis vind er normaal een schifting plaats.

Je doet hierbij de aanname dat er over 5 a 10 jaar uberhaupt nog programmeertalen nodig zijn. Ik denk dat het veel waarschijnlijker is dat er een programmeertaal / framework ontstaat specifiek gemaakt voor bots.

djluc schreef op dinsdag 9 juni 2026 @ 16:18:
Ik ben vooral benieuwd hoeveel bedrijven ook echt op het level zitten dat complexe software correct geschreven wordt op basis van de prompts. Met Claude max loop ik er toch vaak tegenaan dat er "gefantaseerd" wordt waarbij de AI denkt iets moois gemaakt te hebben maar het toch niet 100% blijkt te kloppen.

Ik hoor dit vaak, maar dat fantaseren ligt toch echt aan je eigen gebrekkige input. Als jij, met behulp van AI, in meerdere iteraties, je specs helemaal uitwerkt en AI deze specs naar tests laat omzetten is er NUL (ok misschien 0,0000001) procent kans dat het eindresultaat niet precies is zoals in jouw specs. Mijn eigen setup is nog niet 100% waterdicht en er valt nog een hoop te verbeteren, maar als je een beetje een beeld wilt krijgen voel je vrij eens te klooien met mijn setup: https://github.com/bbjwz/agentstandards

[edie]

Totdat het model een update krijgt en er andere statistieken in de dataset zitten. Krijg je meteen andere output.

[Glashelder]

edie schreef op woensdag 10 juni 2026 @ 14:24:
Totdat het model een update krijgt en er andere statistieken in de dataset zitten. Krijg je meteen andere output.

Als je een groepje andere developers aanneemt dan gaan die het ook lichtjes anders doen dan de oude groep. Wat is je punt? Een tool als Claude gaat echt niet in een keer helemaal je codebase herbouwen omdat je van Opus 4.6 naar 4.7 bent gegaan.

Deze reactie schreeuwt geen ervaring met AI tools. Alleen al dat spreken over 'statistieken'. Zeg dan gewoon trainingsdata.

[R_Zwart]

Als je werk wilt houden in de sector zal je veel meer innovatief werk moeten gaan doen dat nog niet makkelijk vervangen kunt worden. Eigenlijk niet anders dan wat we een aantal jaren terug zagen toen "code kloppen" naar lagere lonen landen werd verplaatst.

[Lethalis]

Het perspectief als software developer is denk ik heel verschillend als je kijkt naar de korte of de lange termijn. We krijgen allemaal met AI te maken, maar het is nog maar de vraag hoe succesvol het uiteindelijk zal zijn.

Spec driven development, waarbij de mens geen code meer schrijft, gaat erg ver en wordt vooral gepusht met het oog op efficiency en meer output genereren. Er zit echter een grens aan wat wij als mensen kunnen behappen, dus zelfs al sturen we een AI aan dan gaan we het niet aankunnen om daar de hele dag door tig projecten mee te doen. Althans, ik niet. Veel te vermoeiend.

Daarnaast gaan we veel meer fouten maken, die ook weer serieus tijd gaan kosten om op te lossen.

Dit is echter een proces waar de markt even doorheen moet. We zullen even met zijn allen moeten leren hoeveel efficiënter het allemaal nou eigenlijk wordt. Is dat 2x? 3x? 10x? Is nu nog veel te lastig om te voorspellen, maar ik vermoed dat de factor lager ligt dan dat de gemiddelde managementafdeling ermee hoopt te bereiken.

Het andere aspect is dat AI vooralsnog tegen spotprijzen is geleverd. Alle leveranciers draaien er dik verlies op, dus die willen hun geld terugverdienen. Bij Microsoft begint het al, dat je nu pay per use gaat krijgen en dat het een heel stuk duurder gaat worden. De concurrenten zullen gauw volgen.

Dus je krijgt dan kort samengevat dat:
1. Programmeurs weliswaar efficiënter worden, maar waarschijnlijk niet in de mate waar nu mee gerekend wordt.
2. De kosten van AI enorm zullen stijgen.
3. Er een tekort aan ervaren programmeurs zal ontstaan door natuurlijk verloop / vergrijzing.

Deze aspecten samen geven mij het gevoel dat we echt nog wel werk zullen houden, alleen we moeten ook accepteren dat het werk verandert. In principe gaat het abstractieniveau weer een stukje omhoog en zullen daardoor andere aspecten van het werk belangrijker worden. Te denken valt hierbij aan project management, contact met klanten, requirements engineering, enzovoorts.

Dat kan natuurlijk ook betekenen dat het werk minder leuk wordt. Ik ben bijvoorbeeld echt een soort zolderkamerautist, dus ik vind het zelf programmeren en mij lekker achter mijn PC verstoppen geweldig. Lekker autistisch mijn werk doen. Tsja. Als iedereen noodgedwongen een soort product owner wordt die een AI agent aanstuurt voor de implementatie, dan weet ik ook niet of ik het nog wel leuk vind.

Eerlijk is eerlijk, ik vraag mij steeds vaker af of ik niet beter hetzelfde als mijn pa had moeten doen en gewoon werktuigbouwkunde had moeten studeren en voor de techniek had moeten kiezen. Daar schijnen genoeg mensen zoals ik rond te lopen die het prima naar hun zin hebben, dus ja. Misschien is de IT het niet meer.

Maar dat is de negatieve insteek. De positieve is dat ik toch langzaam mezelf meer ga ontwikkelen qua soft skills en toch wat serieuzer richting product owner ga. En dan maakt het straks niet meer uit of ik een team aan developers aanstuur, of AI agents.

Alleen de fun is er dan wel een beetje vanaf voor mij. Maar ja, de rekeningen moeten ook betaald worden.

[Tylen]

Lekker man dat AI. Vanmorgen nog mooie power monitor ge-vibe-code in claude. Werkt als een malle. Ben geen devver maar dat kan ik er nu ook wel bij gaan doen, zo moeilijk is het allemaal niet meer

[RM-rf]

Kleine opmerking van mijn zijde over wat mij opvalt...

De houding jegens het aannemen van jong personeel lijkt te veranderen, en ik denk zelf ook dat de omgang met bv iets als AI daarbij ook meespeelt en het zelfs ook een factor kan zijn...

Voor werkgevers wordt het moeten trainen en opleiden van personeel, en deze een structuur te geven waarbinnen ze ervaringen kunnen opdoen en darna langzaam steeds zelfstandiger kunnen functioneren, steeds meer een erg kostbaar en moeizaam proces.

AI toepassingen lijken hier zeker door beinvloed, omdat een ongecontroleerde toepassing ervan juist veel schade kan aanrichten er juist ook behoefte is aan personeel dat zelf voldoende praktijk ervaring en toepassingskennis heeft om relatief snel en efficient in de praktische toeassing hier te kunnen sturen...


De 'menselijke factor' binnen bedrijven is steeds vaker toch ook een ervaren bestuurder van verschillende 'tools', terwijl jong traineerbaar personeel dat mischien enthousiasme meebrengt en een eigen kijk, in zulke taken eerder weinig meerwaarde brengt, door het gebrek aan ervaring...
Ik zie zelf het niet echt als een voorbeeld dat jongere personen meer en beter "technologie-affiniteit" zouden hebben, wat toch enige decenia echt wel een doorslaggevende factor was om jongeren aan te nemen was (de initiele digitale revolutie rond de jaren 90 van de 20e eeuw waarin computers een bepalende rol gingen spelen in veel kantoren, toen was ouder personeel vaak 'ongeschoold' in de omgang met veel computers en programma's).


Qua carriere perspectief zou ik mensen die succesvol willen zijn, helaas vooral de tip geven om in de eerste plaats vooral geen jonge persoon te zijn _{(dat is dus sarcastisch gesteld)} maar een ouder en meer ervaren persoon, die kan terugvallen op veel praktische kennis en inzichten... daar is vooral enorme vraag naar, die kunnen in bedrijven zonder dat ze enorm veel training moeten krijgen of lang ingewerkt moeten worden, snel aan de slag.

[Liegebeest]

RM-rf schreef op woensdag 10 juni 2026 @ 15:45:
De houding jegens het aannemen van jong personeel lijkt te veranderen, en ik denk zelf ook dat de omgang met bv iets als AI daarbij ook meespeelt en het zelfs ook een factor kan zijn...

Die tendens bestaat helaas al bijna tien jaar.

In 2021 deed Naomi Buckwalter dezelfde constatering al op basis van hiring data van de jaren er voor.

YouTube: The Dirty Truth Behind Getting Into Cybersecurity - Naomi Buckwalter - 1 Hour

[FredvZ]

Volgens mij veranderd er per saldo uiteindelijk niets:

Vroeger: slimmeriken maakten zelf de machinecode
Nu: we hebben slimmeriken nodig om complexe programmeercode te schrijven zodat de compiler dat om kan zetten in machinecode
Straks: we hebben slimmeriken nodig om complexe prompts te schrijven zodat de AI de programmeercode kan genereren die compiler kan omzetten in machinecode

Net zoals zelf programmeren zit met AI 5% van de tijd in het maken van de functie en 95% van de tijd in het hardenen van de code, zorgen voor consistentie, etc. Nu met AI lijkt iedereen zich te focussen op die eerste 5% en moet het kwartje nog vallen dat die andere 95% ook nog moet gebeuren.

[wiemelen]

Artikel vandaag in hbvl.be : “We laten AI het werk van beginners doen. Maar wie leert er dan nog iets?”
https://www.hbvl.be/lifes...n-nog-iets/156458178.html

[!mark]

Wel in deze sector gewerkt (+ HBO relevante opleiding gedaan), maar inmiddels alweer een aantal jaren eruit en mogelijk dus minder/niet op de hoogte van de meest recente ontwikkelingen op technisch vlak.

In de VS is het inmiddels echt wel code zwart voor junior en midlevel functies: Zoveel te vinden op o.a. Youtube over mensen wie als software engineer afstuderen en zelfs na 1000(!) sollicitaties niks vinden, mensen met een jaar of 2-5 relevante werkervaring die ontslagen worden hebben het ook niet veel beter. Interviews welke volledig door AI afgenomen worden, extreem veel sollicitatierondes (+ bijbehorende programmeeropdrachten) om uiteindelijk geghost te worden na maanden lange commitment, want de competitie met andere kandidaten is er bijzonder fel. En dat alles voor instapfuncties welke zoveel commitment vragen qua werkuren/ethiek dat je qua uurloon net zo goed bij de McDonalds burgers kunt gaan flippen.

Goed nu is Nederland (gelukkig maar) niet de VS, maar heb in ieder geval qua AI itself wel het idee dat veel dingen welke daar al volledig normaal zijn dat hier de komende jaren ook meer en meer gaat zijn. Het kan voor mijn gevoel twee kanten op gaan:

- De ontwikkelingen blijven net zo stormachtig doorgaan als de afgelopen jaren: In dat geval verwacht ik oprecht een zelfde scenario zoals in de VS waar alleen een kleine groepje uitzonderlijk talent het zal volhouden in deze sector, lees: De mensen wie nu binnen hun bedrijf er ver bovenuit steken qua productiviteit of als ZZPer meer werk aangeboden krijgen dan ze kunnen aannemen. Voor alles daaronder zal het zwaar worden, of je ontwikkelt je tot topper of je wordt langzaam overbodig in een steeds feller wordende competentie tussen mensen. In dat scenario is het voor vers geslaagde middelbare scholieren welke software engineering gaan studeren al helemaal bar en boos, de launch van ChapGPT is nu 3.5 jaar geleden, ik kan me niet eens voorstellen waar we over nog eens 4 jaar zijn qua AI tegen de tijd dat die mensen veelal afgestuurd zijn.

- De verbetering van AI modellen vlakt af, bedrijven als een OpenAI en Anthropic gaan de werkelijke kosten rekenen aan gebruikers en de pushback richting AI bedrijven welke nu heel langzaam op gang komt zet daadwerkelijk door. In dat geval verwacht ik dat de inhoud van het werk voorgoed veranderd is en blijft, vergelijkbaar met meerdere overgangen van machinecode tot steeds hogere abstractie talen; maar niet zozeer dat de vraag naar mensen minder gaat worden op langere termijn.

JJ Le Funk schreef op woensdag 10 juni 2026 @ 08:59:
't wordt een stuk saaier. en door AI ontstaat er de verwachting dat 1 developer veel meer werk kan verstouwen met onrealistische verwachtingen tot gevolg.
ik voorzie toename voor burnouts door deze 2 factoren: minder arbeidsvreugde en meer werkdruk.

En diezelfde AI gaat mogelijk in de toekomst ook nog eens ingezet worden door veel werkgevers om je maximaal in de gaten te houden (gebeurt al in de VS), toetsaanslagen, waar je mee bezig bent, activiteit in een Teams of Slack. Alles gaat in een AI model waardoor de werkdruk tussen het personeel onderling alleen maar meer toeneemt, want niemand wil als minst productief geflagged worden bij de baas. Nu is deze ontwikkeling mogelijk in vrijwel elke sector, maar toch..

[TheGhostInc]

RM-rf schreef op woensdag 10 juni 2026 @ 15:45:
De houding jegens het aannemen van jong personeel lijkt te veranderen, en ik denk zelf ook dat de omgang met bv iets als AI daarbij ook meespeelt en het zelfs ook een factor kan zijn...

Voor werkgevers wordt het moeten trainen en opleiden van personeel, en deze een structuur te geven waarbinnen ze ervaringen kunnen opdoen en darna langzaam steeds zelfstandiger kunnen functioneren, steeds meer een erg kostbaar en moeizaam proces.

Ook naar aanleiding van het bovenstaande artikel, ik heb het idee dat er nogal een geromantiseerde kijk op de junior aan het ontstaan is.
Ik heb nogal wat Deta-vasters & starters de revue zien passeren en inwerken was niet zelden een eufemisme voor 'laten zwemmen'. Of na een paar weken interne cursus en kennismaking direct bij de klant als medior/senior op een klus worden gezet.

Een bekende van mij is recent gestart bij een van de grootzakelijke bedrijven en was 'slechts' 6 weken aan het wachten op rechten om te kunnen beginnen. En hoe vaak lokale omgevingen pas na dagen en dagen van prutsen werkten en regelmatig weer omdonderden...
Als junior was het eerder een hel dan een fijne educatieve omgeving met ruime leer mogelijkheden.
Misschien was dat vooral in de bedrijven waar ik terecht kwam, maar daar zaten wat hele grote partijen bij.

Het voordeel van AI is dat elke keer als je een vraag stelt hij braaf antwoord, al stel je 100x dezelfde vraag. Je krijgt nooit als antwoord 'probeer maar iets' of 'verzamel al je vragen voor dat uurtje in de week'.

Maar de tijd dat iedereen binnen werd gehaald, of je nu geschiedenis, filosofie of sociale wetenschappen had gestudeerd en werd gekneed tot developer is wel voorbij. Als je niet eager bent en meekomt, tja, dan is AI een stuk voordeliger en efficiënter.

[Liegebeest]

wiemelen schreef op woensdag 10 juni 2026 @ 18:24:
Artikel vandaag in hbvl.be : “We laten AI het werk van beginners doen. Maar wie leert er dan nog iets?”
https://www.hbvl.be/lifes...n-nog-iets/156458178.html

Dan grijp ik nog eens terug naar die talk van Naomi (die ik eerder linkte): als je alleen mediors en seniors in wilt huren... waar komen op termijn de nieuwe mediors en seniors vandaan?

[geekeep]

TheGhostInc schreef op woensdag 10 juni 2026 @ 18:59:
[...

Het voordeel van AI is dat elke keer als je een vraag stelt hij braaf antwoord, al stel je 100x dezelfde vraag. Je krijgt nooit als antwoord 'probeer maar iets' of 'verzamel al je vragen voor dat uurtje in de week'.

Voordeel.. Nadeel.. Wie zal het zeggen. Het is wel keer op keer bewezen als je zelf daadwerkelijk iets moet uitzoeken of proberen, je vele malen meer en beter leert dan dat je bij iedere uitdaging het antwoord vraagt aan een ander..

[defiant]

Wat software development inhoudt is zeer sterk afhankelijke van het domein waarin je actief bent. Het probleem is dat de titel die je baan heeft vaak helemaal niets zegt over het domein. John Carmack als pionier van 3D engines kan net zo goed programmeur genoemd worden als iemand die een CRUD website heeft gemaakt. Het verschil in zowel technische als domein kennis tussen beiden is echter gigantisch.

Hoe complexer het domein, hoe meer de waarde van degene die actief is op gebied van development, omdat die het domein zowel technisch als functioneel moet begrijpen. Deze afspiegeling zag je voor de opkomst van AI ook al in de markt, iemand actief op het gebied van high-frequency trading verdient meer dan iemand die bij een generiek softwarehuis werkt. Als je technisch carrière wilde maken in software development, dan moest ook in het verleden naar bedrijven met complexere domeinen.

LLM's veranderden, in principe, niet zoveel aan bovenstaande dynamiek. Een complex domein wordt niet zomaar makkelijker met de toepassing van AI, je moet nog steeds wel begrijpen wat je doet, ook al was het maar dat je het domein moet begrijpen om überhaupt tot een prompt te komen die het gewenste resultaat oplevert. En hoe complexer het domein, des te meer kans dat de LLM het functioneel moeilijker kan krijgen omdat de trainingsdata ontbreekt, er is een reden waarom sommige bedrijven hun modellen zelf wel hosten of zelfs nog conservatiever zijn. Ik heb er geen onderzoek naar gedaan, maar het is de vraag hoe effect LLM's zijn op het gebied van defensie, medische industrie en HFT.

Het laaghangende fruit zal wel enorme concurrentie krijgen, maar die ontwikkeling die is al decennia aan de gang met de evolutie van programmeertalen maar zeker ook door outsourcing. Het einde van de programmeur is hierdoor al vaak voorspeld (zie ook 4GL/low code/etc), maar dat moet ook met LLM nog maar worden bezien. Of het werk er leuker/uitdagender op wordt op een positieve manier is een ander verhaal.

[Hillie]

!mark schreef op woensdag 10 juni 2026 @ 18:41:
In de VS is het inmiddels echt wel code zwart voor junior en midlevel functies: Zoveel te vinden op o.a. Youtube over mensen wie als software engineer afstuderen en zelfs na 1000(!) sollicitaties niks vinden, mensen met een jaar of 2-5 relevante werkervaring die ontslagen worden hebben het ook niet veel beter. Interviews welke volledig door AI afgenomen worden, extreem veel sollicitatierondes (+ bijbehorende programmeeropdrachten) om uiteindelijk geghost te worden na maanden lange commitment, want de competitie met andere kandidaten is er bijzonder fel. En dat alles voor instapfuncties welke zoveel commitment vragen qua werkuren/ethiek dat je qua uurloon net zo goed bij de McDonalds burgers kunt gaan flippen.

Ben je zelf bekend met de Amerikaanse markt, of allemaal uit dezelfde soort bronnen? (YouTube zal je ook meer van hetzelfde geven als je een paar filmpjes hebt gezien).

Zelf woon en werk ik in de VS, bijna 17 jaar, maar uit eigen ervaring met kleine en grote organisaties merk ik dat men graag snel toeslaat bij goede kandidaten. 1000 sollicitaties en 0 resultaat, dan ben je als sollicitant het probleem.

Het probleem dat ik bij het overgrote merendeel van de juniors en stagiairs zie is dat men te slim denkt te zijn, door stiekem AI te gebruiken tijdens (remote) gesprekken, ondanks expliciete waarschuwing dat het niet is toegestaan en je afgewezen wordt.

Wat ik zie is dat getalenteerde engineers van junior tot principal/fellow niveau nog steeds erg gevraagd zijn. De krabbers die net voor de AI golf met een bootcamp cursusje aan de bak zijn gekomen, die hebben het zwaar. De talenten uitgezonderd natuurlijk.

Qua verdiensten is het in de VS ook nog steeds goed toeven.

[TheGhostInc]

geekeep schreef op donderdag 11 juni 2026 @ 00:04:
Voordeel.. Nadeel.. Wie zal het zeggen. Het is wel keer op keer bewezen als je zelf daadwerkelijk iets moet uitzoeken of proberen, je vele malen meer en beter leert dan dat je bij iedere uitdaging het antwoord vraagt aan een ander..

Even zuiver theoretisch:
Als ik een AI prompt schrijf die in 1x een perfect resultaat geeft of ik schrijf in 1x de perfecte code, in welke situatie leer ik iets? Als ik al de perfecte code kan schrijven, dan is de uitdaging er duidelijk niet of nauwelijks, terwijl met AI, tja, dan zou het kunnen zijn dat er iets inzit waar ik nog iets van leer.
Als het een beetje een serieuze feature is, dan zal ik bij zelf coden vrij veel moeten typen, dus redelijk tijdsintensief, bij AI, dan was het relatief weinig tijd. Misschien dat ik dus sneller aan iets toekom waar ik wel iets van leer.

Mijn ervaring met uitzoek werk binnen de grote corporates is dat het zelden interessant of leerzaam is. Het is een mix van legacy ellende, 'not invented here', speciaaltjes, mix van oud & nieuw en (externe) projecten die wel of niet meehelpen/op tijd klaar zijn. Qua kennisopbouw vaak maar heel beperkt.

defiant schreef op donderdag 11 juni 2026 @ 00:59:
LLM's veranderden, in principe, niet zoveel aan bovenstaande dynamiek. Een complex domein wordt niet zomaar makkelijker met de toepassing van AI, je moet nog steeds wel begrijpen wat je doet, ook al was het maar dat je het domein moet begrijpen om überhaupt tot een prompt te komen die het gewenste resultaat oplevert. En hoe complexer het domein, des te meer kans dat de LLM het functioneel moeilijker kan krijgen omdat de trainingsdata ontbreekt, er is een reden waarom sommige bedrijven hun modellen zelf wel hosten of zelfs nog conservatiever zijn. Ik heb er geen onderzoek naar gedaan, maar het is de vraag hoe effect LLM's zijn op het gebied van defensie, medische industrie en HFT.

Ik weet niet of mijn domein complex genoeg is, maar ik kan je zeggen het is HEERLIJK!

Natuurlijk, als ik de eerste keer aan AI in mijn domein iets vraag, dan hallucineert dat ding zich de tent uit, begint aanname op aanname te stapelen, begrippen/termen te introduceren die ik niet gebruik etc. etc.
En dan begint het spel, maak een glossary, maak een business capability beschrijving, maak een bounded context met ubiquitous language, daarna komen de business rules, de use cases en via feature files & BPMN diagrammen gaan we door naar Operator Procedures.
Als ik klaar ben met een thema, dan heb ik een handje vol met documenten die EXACT mijn domein beschrijven en die ik elke keer weer kan gebruiken om de implementatie te toetsen:
"Proces X, doet dat Y en Z, is situatie A, B & C afgevangen"
Ik ga niet elke keer zo'n generieke LLM laten zwammen en tijd verspillen, ik geef de context en daarna kan het ding heel nauwkeurig antwoorden.En als hij dan toch gaat hallucineren? Dan heb ik een review of check stap die die direct er weer uit filtert. "Zit NFR X in de implementatie"?

En dan kom je wel bij de leuke situaties, een beetje vergelijkbaar met hoe Tesla het doet en ik kan me voorstellen dat dat bij HFT bijvoorbeeld een leuke is:
Ik heb situatie A, daarin wil ik dat proces X antwoord 1 geeft, blijf het algoritme verbeteren en checken tegen de antwoorden. Dan kan AI gewoon een week lang crunchen en mogelijkheden testen en bij elke kandidaat bijvoorbeeld een zwaardere testsuite draaien of tegen 6 maanden productiedata draaien.

defiant schreef op donderdag 11 juni 2026 @ 00:59:
Het laaghangende fruit zal wel enorme concurrentie krijgen, maar die ontwikkeling die is al decennia aan de gang met de evolutie van programmeertalen maar zeker ook door outsourcing. Het einde van de programmeur is hierdoor al vaak voorspeld (zie ook 4GL/low code/etc), maar dat moet ook met LLM nog maar worden bezien. Of het werk er leuker/uitdagender op wordt op een positieve manier is een ander verhaal.

Ik heb vrij veel ervaring met low code, alle grote platformen wel serieus in professionele settings gebruikt en daarbij zie je dat de structuur in de low code vaak hetgeen is waar het mis gaat. Bij programmeren heb je best veel kennis om een goede architectuur en structuur te maken. Low code eindigt regelmatig in een enorme brei van spaghetti. Ook is de drempel om in low code 'iets te doen' veel lager, maar juist daardoor is de kwaliteit ook al snel lager. Maar de top low-code engineers die ik ken, die zijn in zeer functionele domeinen niet bij te houden met klassiek programmeren. Bijvoorbeeld bij wet- en regelgeving, waarbij je veel arbitraire rules hebt.
Ergens lijkt low code enorm veel op AI developen. Je beschrijft het systeem in plaats van daadwerkelijk te coden. Alleen low code is qua volwassenheid er nooit helemaal gekomen. Ik merk nu met AI dat we die volgende stap gewoon kunnen doen. Of het low code word of gegenereerde code uit AI, dat hangt van het low code platform af, ik denk dat er wel een paar low code platformen gaan verdwijnen.

Om je laatste vraag te beantwoorden:
Als je het leuk vindt om in je werk dagen, weken of maanden te besteden aan technische optimalisaties en puzzelen op software om de 'beste' software te bouwen. Tja, helaas is dat een hoek die heel snel nu verdwijnt. Het moet wel heel specifiek zijn om daar nog werk in te vinden.
Dicht op de hardware zie je nog wel dit soort projecten, maar al heel snel ga je daarna richting API's en hoe beter die API is, hoe eenvoudiger het weer wordt om die te integreren. En dan gaat AI al heel snel dingen overpakken en zelfs beter doen.

[wiemelen]

TheGhostInc schreef op donderdag 11 juni 2026 @ 06:07:
Even zuiver theoretisch:
Als ik een AI prompt schrijf die in 1x een perfect resultaat geeft of ik schrijf in 1x de perfecte code, in welke situatie leer ik iets? Als ik al de perfecte code kan schrijven, dan is de uitdaging er duidelijk niet of nauwelijks, terwijl met AI, tja, dan zou het kunnen zijn dat er iets inzit waar ik nog iets van leer.
Als het een beetje een serieuze feature is, dan zal ik bij zelf coden vrij veel moeten typen, dus redelijk tijdsintensief, bij AI, dan was het relatief weinig tijd. Misschien dat ik dus sneller aan iets toekom waar ik wel iets van leer.

Mijn ervaring met uitzoek werk binnen de grote corporates is dat het zelden interessant of leerzaam is. Het is een mix van legacy ellende, 'not invented here', speciaaltjes, mix van oud & nieuw en (externe) projecten die wel of niet meehelpen/op tijd klaar zijn. Qua kennisopbouw vaak maar heel beperkt.

...

Interessante gedachte.

Maar aanvullend daarop heb ik volgende vragen/bemerkingen:
Als je in 1 keer de perfecte code kan schrijven, is er geen enkele reden om AI niet te gebruiken ... tenminste als die een goed en volledig resultaat oplevert.

Als AI je werkende code oplevert die zelf niet in 1 keer kan schrijven, heb je kans op 1 of meer van volgende scenario's :

• zijn er helaas nog teveel mensen die het overnemen zonder te controleren of zonder de nieuwsgierigheid om er zelf iets van bij te leren.
• wordt er minder/niet nagedacht over of gecontroleerd op generieke en/of herbruikbare code. Dus de kans op code duplicering is best groot. Op termijn niet bevorderlijk voor een "lean en mean opzet" en onderhoud.
• blijf je vaak hangen in de denkpatronen / oplossingen die AI je oplevert. Dus oplossingen die iemand anders ooit verzonnen heeft. Dan sla je de stap over om uit te zoeken of er ondertussen al betere / andere oplossingen zijn. Ik heb me dan ook op recht de vraag al gesteld of de leercurve van AI zelf op een bepaald moment afvlakt omdat de LLM's blijven hangen in bestaande oplossingen en er geen nieuwe/betere oplossingen meer verzonnen worden.
• Ook in je hersenen komen er veranderingen waardoor je op termijn meer moeilijkheden krijgt met bepaalde denk- en leerpatronen. Iets gelijkaardigs zie je met kinderen die tegenwoordig weinig meer schrijven en veel via de computer doen. Studies tonen aan dat zij minder goed leerstof opnemen en minder goed kunnen leren. Niet voor niets dat de Scandinavische landen die eerst koploper waren om te leren via computer, dan voor leerlingen in het lager en middelbaar onderwijs massaal van het afstappen zijn.
• Je theoretische gedachte vertrekt vanuit een persoon met ervaring. Het is al vaker aangehaald dat als je AI gebruikt om de taken van juniors over te nemen, hoe ga je dan op termijn zorgen dat juniors (als je die nog steeds hebt) ooit kunnen doorgroeien naar senior niveau? Niet alleen voor wat betreft technische skills, maar ook voor denkpatronen, inbouwen van authorisatie checks, etc. Een ervaren persoon zet dit in zijn prompt omdat je die ervaring hebt, een junior niet.
• Uit mijn persoonlijke ervaring weet ik dat ik vaak nog aan extra dingen denk terwijl ik code aan het kloppen ben. Net omdat je je aan het verdiepen bent in de materie/code. Dat kan gaan om procesmatige, security, validaties, technische dingetjes. Kans zit er in dat je dat mist als je enkel maar een prompt ingeeft, omdat je net niet diep genoeg bij de materie/code betrokken wordt. Of erger nog, als een functioneel persoon met (te) weinig technische kennis ineens een prompt gaat opstellen.

Ik heb toevallig zelf vorige vrijdag een (privacy en security gevoelig) rapport laten genereren door AI. Werkte bijna out-of-the-box, op wat syntax errors na. Ik het hele rapport gescreend en allerlei aanvullingen en validaties op gemaakt. Daarna heb ik het originele en het aangepaste rapport door dezelfde AI laten vergelijken. Blijkt dat AI zelf vindt dat het originele rapport significant minder goed is opgesteld als het aangepaste en zelfs nog security issues bevat. Ik had dus snel klaar kunnen zijn, maar het finale resultaat heeft met toch een uurtje of 2 extra gekost. Al heeft AI me met het originele rapport ook een uurtje of 2 tijd bespaart.

Wat ik hiermee wil aantonen is dat AI super handig is, maar dat programmeurs zelf én zeker ook bedrijven zeer alert moeten zijn voor de valkuilen ervan én een manier moeten borgen dat kennis en ervaring nog steeds bij de persoon ligt (en opgebouwd wordt).

[geekeep]

TheGhostInc schreef op donderdag 11 juni 2026 @ 06:07:
[...]

Even zuiver theoretisch:
Als ik een AI prompt schrijf die in 1x een perfect resultaat geeft of ik schrijf in 1x de perfecte code, in welke situatie leer ik iets? Als ik al de perfecte code kan schrijven, dan is de uitdaging er duidelijk niet of nauwelijks, terwijl met AI, tja, dan zou het kunnen zijn dat er iets inzit waar ik nog iets van leer.
Als het een beetje een serieuze feature is, dan zal ik bij zelf coden vrij veel moeten typen, dus redelijk tijdsintensief, bij AI, dan was het relatief weinig tijd. Misschien dat ik dus sneller aan iets toekom waar ik wel iets van leer.

Mijn ervaring met uitzoek werk binnen de grote corporates is dat het zelden interessant of leerzaam is. Het is een mix van legacy ellende, 'not invented here', speciaaltjes, mix van oud & nieuw en (externe) projecten die wel of niet meehelpen/op tijd klaar zijn. Qua kennisopbouw vaak maar heel beperkt.

Om perfecte code te kunnen schrijven (wat overigens compleet utopisch is) heb je moeten leren om dit te kunnen. Geleerd van je fouten, bugs moeten reproduceren, paden in je logica kunnen volgen, vergelijkbare situaties kunnen gebruiken voor een oplossing.
Die AI is getraind op bestaande code, wat óók imperfecties en fouten bevat. Dus leuk zo'n zuiver theoretisch argument, maar in de praktijk gaat dat niet op.
Als jij graag die oom op je verjaardag -die naar eigen zeggen over alles verstand heeft- blind wilt vertrouwen bij het zetten van een nieuwe aanbouw, helemaal prima. Maar zonder dat je zelf ervaring hebt domweg zijn instructies opvolgen en als je aanbouw instort hem maar weer opnieuw bevragen, is nogal naïef.

Het meest ironische is dan misschien nog wel dat je het kritisch denken verliest door simpelweg uit te voeren wat een AI suggereert. Klinkt als een perfecte kandidaat om jouw rol te automatiseren.

Als jouw argument is om sneller te typen, dan ben ik teleurgesteld in die honderden miljarden die nu blijkbaar in deze 'uitvinding' gepompt moeten worden. Software ontwikkeling is zoveel meer dan code typen, en er kan zoveel meer bespaard worden door te focussen op ándere zaken dan snelheid. Iets met 'do the right things right'.

[...]

Ik heb vrij veel ervaring met low code, alle grote platformen wel serieus in professionele settings gebruikt en daarbij zie je dat de structuur in de low code vaak hetgeen is waar het mis gaat. Bij programmeren heb je best veel kennis om een goede architectuur en structuur te maken. Low code eindigt regelmatig in een enorme brei van spaghetti. Ook is de drempel om in low code 'iets te doen' veel lager, maar juist daardoor is de kwaliteit ook al snel lager. Maar de top low-code engineers die ik ken, die zijn in zeer functionele domeinen niet bij te houden met klassiek programmeren. Bijvoorbeeld bij wet- en regelgeving, waarbij je veel arbitraire rules hebt.
Ergens lijkt low code enorm veel op AI developen. Je beschrijft het systeem in plaats van daadwerkelijk te coden. Alleen low code is qua volwassenheid er nooit helemaal gekomen. Ik merk nu met AI dat we die volgende stap gewoon kunnen doen. Of het low code word of gegenereerde code uit AI, dat hangt van het low code platform af, ik denk dat er wel een paar low code platformen gaan verdwijnen.

Spaghetti kan gemaakt worden in iedere taal, platform of architectuur. En daarbovenop komt dat een AI zoveel meer output genereert, dat een mens het niet volledig kan verwerken en dus blind code doorpusht. Er kan met een AI dus nóg sneller spaghetti worden gecreëerd, waarbij niemand meer snapt hoe of waarom iets werkt. Snelheid is in deze eerder nadeel dan voordeel m.b.t. onderhoudbaarheid.

[Dido]

geekeep schreef op donderdag 11 juni 2026 @ 10:57:
Spaghetti kan gemaakt worden in iedere taal, platform of architectuur. En daarbovenop komt dat een AI zoveel meer output genereert, dat een mens het niet volledig kan verwerken en dus blind code doorpusht. Er kan met een AI dus nóg sneller spaghetti worden gecreëerd, waarbij niemand meer snapt hoe of waarom iets werkt. Snelheid is in deze eerder nadeel dan voordeel m.b.t. onderhoudbaarheid.

Dit dus... en zolang alles werkt zoals verwacht is iedereen blij.
Maar op het moment dat er iets een keer niet gaat zoals verwacht of gewenst (dat zijn niet dezelfde dingen!), AI weinig anders kan dan vertellen dat de code doet wat gevraagd was, en er du stoch een mens zal moeten gaan spitten in die nooit-begrepen spaghetti om te kijken wat er gebeurt, en waarom, en er zal alsnog door mensen bepaald moeten worden of er sprake is van een onverwachte (maar correcte) uitkomst, of van een ongewenste uitkomst, waarvoor er dus een sliert spaghetti verlegd moet worden.

En ga je AI dan die sliert laten verleggen, of moet dat dan alsnog door een mens gebeuren?

Je komt terecht in de situatie waar banken, verzekeraars en andere grote bedrijven begin deze eeuw in terecht kwamen: decennia aan COBOL en RPG code, geschreven door hele slimme mensen, die allemaal met pensioen zijn (of eruit geflikkerd gedurende de banken/hypotheek-crisis, en niet meer bereid om terug te keren), zodat de volledige code-base één grote black box is.

En ja, er zijn een aantal spelers geweest die claimden dat ze dergelijke legacy shit konden ontsluiten (o.a. Jacada en Seagull) maar het enige wat ze deden was een "modern" ogende schil over de CICS schermen heenleggen. Als er iets in de business-logica moest worden aangepast, had je toch echt weer een COBOL- of RPG-programmeur nodig, en die komen niet van de standaard opleidingen af.
Wat daar wel vanaf komt doet er over het algemeen alles aan om zo ver mogelijk weg te bliven bij die oude shit.

De enige uitweg is uiteindelijk gebleken om de hele codebase te vervangen door iets was wel door normale mensen te begrijpen en onderhouden was.

En aangezien mensen erg slecht zijn in leren van eerdere fouten (ezels schijnen daar veel beter in te zijn!) zullen er inderdaad heel wat bedrijven zijn die hun huidige software-landschap gaan laten gijzelen door de klinkende beloftes van AI, om op enig moment (ik geef het tien jaar) knarsetandend toe te moeten geven dat ze met de rug tegen de muur staan, en de poeplap moeten trekken om de hele rotzooi te vervangen met behulp van mensen.

Maar dat is helemaal niet erg, want de (top)managers die nu het probleem veroorzaken zijn tegen die tijd al lang met pensioen, of weggepromoveerd naar elders. dus er hoeft op dat niveau niemand voor te bloeden. In die zin zou je haast denken dat AI een VVD-verzinsel is

[TheGhostInc]

@wiemelen, @geekeep & @Dido
We zeilen nu wel met de discussie een totaal andere kant op, maar ik heb nog wel een vraag, ik heb met AI even een voorbeeld gemaakt van verschillende transities van code:

1. Java-broncode → bytecode (javac-compiler)
2. Bytecode → interpretatie door de JVM
3. Bytecode → machinecode via JIT-compiler (HotSpot, runtime, dynamisch)
4. Machinecode → micro-ops (decoder in de CPU zet x86-instructies om in interne micro-operaties)
5. Micro-ops → microcode (complexe instructies worden via het microcode-ROM uitgevoerd, door Intel/AMD updatebaar)
6. Micro-ops → out-of-order uitvoering (herordening, registerhernoeming, speculatie — wat er echt gebeurt wijkt af van je programma-volgorde)
7. Logische poorten → transistorgedrag (fysieke chiparchitectuur, procesnode)

En dan heb ik nog niet meegenomen dat je ook nog libraries hebt.
Welke van deze onderdelen neem je mee in je testen? Download je de micro-ops van AMD? Test je een nieuwe compiler?

Ik heb toevallig nog wel eens naast een machine van ASML & ASM gestaan, heb zelf lopen kloten met logica (op PCB's solderen), ik heb in het verleden nog weleens machinecode geschreven, zijdelings betrokken geweest bij zwaar geoptimaliseerde C code en zo helemaal naar boven. En het is echt humor om kort mee bezig te zijn, maar het is niet dat ik het idee heb dat ik geen controle meer heb over het resultaat omdat ik de onderliggende stappen niet meer doe of volledig begrijp.

Ik zit bijvoorbeeld zelf in het JVM ecosysteem en ik kan me best amuseren met een artikel over hoe bepaalde (architectonische) keuzes uitwerken, waarbij sommige dingen letterlijk dezelfde bytecode opleveren of direct worden geoptimaliseerd door de JIT compiler. Maar ik weet ook dat ik 100% erop vertrouw dat het 'doet wat het moet doen'. Ik ga er vanuit dat een for loop exact doet wat hij moet doen, ik ga geen test schrijven om te testen dat een loop over 100 getallen wel daadwerkelijk alle 100 getallen raakt. Het voordeel van die systemen is dat die zo breed worden gebruikt dat je aardig zeker kunt zijn dat ze goed werken en omdat je meerdere vergelijkbare systemen hebt kun je ook A-B testen uitvoeren.
Maar de andere kant is wel, dat er genoeg bugs gevonden worden in al die onderdelen, het is ook niet zo dat het helemaal bugvrij is.

AI Is wel bijzonder omdat het kan hallucineren, wat wel anders aanvoelt als een normale bug met onverwacht gedrag. Maar voor de rest is het niks meer dan een laag boven op de hele stapel van lagen.

En die super verbose code met ontzettend veel comments en zooi ertussen?
Dat is vooral de interpretatie van de AI zelf over hoe 'goede' code eruit moet zien. Je zou ook naar een soort geminified versie kunnen gaan, waarbij je werkt met 1 letterige variabelen. Waarschijnlijk zit daar ook nog wat in van "Do as I say, not as I do". Als je de ontwikkel documentatie tot op de letter nauwkeurig zou uitvoeren bij een corporate, dan kom je veel dichterbij bij dat soort uitgebreide code. Maar meestal leven de implementatie details in de hoofden van mensen. En als je geen documentatie hebt van je proces, dan 'moet' het wel in comments in de code. Heb je echter een strakke documentatie dan kun je ook heel eenvoudig de AI vragen alles te schrappen dat al is vastgelegd.

Overigens denk ik dat er nog wel veel waarde gaat zitten in de feedback loop. Als je AI 'matige' code oplevert, dan zou je ook naar betere model training moeten gaan. Net zoals je een bug report kunt maken voor een bug.
Zeker bij programmeren zou je ook AI los kunnen laten op je trainingsdata en gaan filteren op data die duidelijk slecht is.

Ps. Ik zet hem hier natuurlijk wel wat zwart/wit neer, maar dat is vooral voor de lol. Uiteindelijk in de echte wereld zijn er nuances, uitzonderingen e.d., maar in de basis is dit wel mijn uitgangspunt.

[geekeep]

TheGhostInc schreef op donderdag 11 juni 2026 @ 16:19:
@wiemelen, @geekeep & @Dido
We zeilen nu wel met de discussie een totaal andere kant op, maar ik heb nog wel een vraag, ik heb met AI even een voorbeeld gemaakt van verschillende transities van code:

1. Java-broncode → bytecode (javac-compiler)
2. Bytecode → interpretatie door de JVM
3. Bytecode → machinecode via JIT-compiler (HotSpot, runtime, dynamisch)
4. Machinecode → micro-ops (decoder in de CPU zet x86-instructies om in interne micro-operaties)
5. Micro-ops → microcode (complexe instructies worden via het microcode-ROM uitgevoerd, door Intel/AMD updatebaar)
6. Micro-ops → out-of-order uitvoering (herordening, registerhernoeming, speculatie — wat er echt gebeurt wijkt af van je programma-volgorde)
7. Logische poorten → transistorgedrag (fysieke chiparchitectuur, procesnode)

En dan heb ik nog niet meegenomen dat je ook nog libraries hebt.
Welke van deze onderdelen neem je mee in je testen? Download je de micro-ops van AMD? Test je een nieuwe compiler?

Ik heb toevallig nog wel eens naast een machine van ASML & ASM gestaan, heb zelf lopen kloten met logica (op PCB's solderen), ik heb in het verleden nog weleens machinecode geschreven, zijdelings betrokken geweest bij zwaar geoptimaliseerde C code en zo helemaal naar boven. En het is echt humor om kort mee bezig te zijn, maar het is niet dat ik het idee heb dat ik geen controle meer heb over het resultaat omdat ik de onderliggende stappen niet meer doe of volledig begrijp.

Ik zit bijvoorbeeld zelf in het JVM ecosysteem en ik kan me best amuseren met een artikel over hoe bepaalde (architectonische) keuzes uitwerken, waarbij sommige dingen letterlijk dezelfde bytecode opleveren of direct worden geoptimaliseerd door de JIT compiler. Maar ik weet ook dat ik 100% erop vertrouw dat het 'doet wat het moet doen'. Ik ga er vanuit dat een for loop exact doet wat hij moet doen, ik ga geen test schrijven om te testen dat een loop over 100 getallen wel daadwerkelijk alle 100 getallen raakt. Het voordeel van die systemen is dat die zo breed worden gebruikt dat je aardig zeker kunt zijn dat ze goed werken en omdat je meerdere vergelijkbare systemen hebt kun je ook A-B testen uitvoeren.
Maar de andere kant is wel, dat er genoeg bugs gevonden worden in al die onderdelen, het is ook niet zo dat het helemaal bugvrij is.

AI Is wel bijzonder omdat het kan hallucineren, wat wel anders aanvoelt als een normale bug met onverwacht gedrag. Maar voor de rest is het niks meer dan een laag boven op de hele stapel van lagen.

En die super verbose code met ontzettend veel comments en zooi ertussen?
Dat is vooral de interpretatie van de AI zelf over hoe 'goede' code eruit moet zien. Je zou ook naar een soort geminified versie kunnen gaan, waarbij je werkt met 1 letterige variabelen. Waarschijnlijk zit daar ook nog wat in van "Do as I say, not as I do". Als je de ontwikkel documentatie tot op de letter nauwkeurig zou uitvoeren bij een corporate, dan kom je veel dichterbij bij dat soort uitgebreide code. Maar meestal leven de implementatie details in de hoofden van mensen. En als je geen documentatie hebt van je proces, dan 'moet' het wel in comments in de code. Heb je echter een strakke documentatie dan kun je ook heel eenvoudig de AI vragen alles te schrappen dat al is vastgelegd.

Overigens denk ik dat er nog wel veel waarde gaat zitten in de feedback loop. Als je AI 'matige' code oplevert, dan zou je ook naar betere model training moeten gaan. Net zoals je een bug report kunt maken voor een bug.
Zeker bij programmeren zou je ook AI los kunnen laten op je trainingsdata en gaan filteren op data die duidelijk slecht is.

Ps. Ik zet hem hier natuurlijk wel wat zwart/wit neer, maar dat is vooral voor de lol. Uiteindelijk in de echte wereld zijn er nuances, uitzonderingen e.d., maar in de basis is dit wel mijn uitgangspunt.

Niet lullig bedoeld, maar snap je hoe 'een AI' tot z'n antwoord komt? De G van GPT is Generative. Het genereert een antwoord op basis van het meest waarschijnlijke, getraind met 'data'. Wat die data precies is, weet niemand. Hoe vaak die data verandert en wat de impact daarvan is? Wellicht weet Joost het.

Hoe kun je dit vergelijken met een transistor of low level code met logische statements? Een IF geeft altijd dezelfde waarde gegeven een gelijke input. Of het nu maandag, dinsdag, 2020, 2028 is en ongeacht de oorsprong van de input. De uitkomst blijft gelijk.

Ik durf je 100% te garanderen dat dit niet geldt voor de door jouw gebruikte generatieve AI tools. Het is niet 'een laag bovenop een stapel van lagen'.

Het is een vlotte verkoper die je vandaag een tv aanbiedt en morgen een monitor, als antwoord op de wens om een tweede beeldscherm te creëren. En volgende week uiteraard een koelkast met ingebouwd beeldscherm.

Ik vind het eng hoeveel vertrouwen mensen hebben in tools die bergen aan output genereren, waar geen enkele kern van waarheidsbesef in zit.

[diondokter]

geekeep schreef op donderdag 11 juni 2026 @ 20:27:
[...]

Hoe kun je dit vergelijken met een transistor of low level code met logische statements? Een IF geeft altijd dezelfde waarde gegeven een gelijke input. Of het nu maandag, dinsdag, 2020, 2028 is en ongeacht de oorsprong van de input. De uitkomst blijft gelijk.

Inderdaad, ik snap dat argument ook niet. Als dat echt zo zou zijn, dan zouden je prompts ook je nieuwe code worden. Maar wat gebeurt er? De prompts worden weggegooid en de output gooien we in git. Moest je eens voorstellen dat iemand dat zou suggereren te doen met echte compilers/assemblers.

"Oh, ik moet X doen, dus laat ik wat C schrijven, het compileren en dan de assembly of machine code in versiebeheer stoppen om vervolgens de C code weer weg te gooien."

[defiant]

geekeep schreef op donderdag 11 juni 2026 @ 20:27:
Ik vind het eng hoeveel vertrouwen mensen hebben in tools die bergen aan output genereren, waar geen enkele kern van waarheidsbesef in zit.

Ik raad mensen ook altijd aan om de techniek achter LLM's te bestuderen, het vereist wel enig inzicht/kennis, maar het is geen hogere wiskunde. Zodra je het proces begrijpt, weet je ook het model werkt. Hier is een voorbeeld, maar er zijn er meerdere: How LLMs Actually Work

Wat imho meeste inzicht geeft is dat LLM's volledig afhankelijk zijn van het trainings data en de kwaliteit ervan, het heeft zelf geen besef heeft van concepten als data kwaliteit, oorzaak/gevolg, bias in de data, logische fouten, etc. Hierin zie je de verschillen in ervaringen naar voren komen.

Dat maakt LLM's van big tech ook onvoorspelbaar, je kant goede resultaten behalen maar ook niet. Als eindgebruiker is dat lastig inzichtelijk te krijgen, het is een black box

Het kernprobleem van LLM is het ultieme probleem wat we ook al hadden met programmeertalen, de reden dat programmeertalen bestaan is omdat menselijke taal erg ambigue is. Er is een reden waarom je met een idee niet zomaar omzet in een werkende applicatie hebt, de realiteit is erg complex en vol met uitzonderingen/business logica/etc, die ook nog eens exact moet zijn. Taal is niet exact.

Dat is de reden dat automatiseringstaken vaak het beste werken als de specificaties volledig duidelijk en niet ambigue zijn. En daarmee kom je weer op het oorspronkelijke probleem van software development, 100% duidelijke en correcte specificaties bestaan niet en ze veranderen altijd. Agile was hierin de oplossing, accepteer dat de specificaties ambigue zijn en altijd wijzigen.

De wens van een prompt naar perfecte code komt dus ook steeds meer neer op het van te voren hebben van de perfecte specificatie. En dat is natuurlijk het ideale eind model, als je de exacte specificatie hebt, dan kan je in principe ook de code genereren. Maar weinig bedrijven zijn in staat om op die manier te werken en ook programmeurs die goed zijn zouden in het verleden zulke code ook handmatige hebben kunnen produceren.

En dat is de core uitdaging software development waar het allemaal begint, wat zijn exacte specificaties ? En hoe passen die binnen de architectuur/technische uitdagingen/ beperkingen ?

[ Voor 3% gewijzigd door defiant op 12-06-2026 00:47 ]

[geekeep]

defiant schreef op vrijdag 12 juni 2026 @ 00:37:
[...]

Ik raad mensen ook altijd aan om de techniek achter LLM's te bestuderen, het vereist wel enig inzicht/kennis, maar het is geen hogere wiskunde. Zodra je het proces begrijpt, weet je ook het model werkt. Hier is een voorbeeld, maar er zijn er meerdere: How LLMs Actually Work

Wat imho meeste inzicht geeft is dat LLM's volledig afhankelijk zijn van het trainings data en de kwaliteit ervan, het heeft zelf geen besef heeft van concepten als data kwaliteit, oorzaak/gevolg, bias in de data, logische fouten, etc. Hierin zie je de verschillen in ervaringen naar voren komen.

Dat maakt LLM's van big tech ook onvoorspelbaar, je kant goede resultaten behalen maar ook niet. Als eindgebruiker is dat lastig inzichtelijk te krijgen, het is een black box

Het kernprobleem van LLM is het ultieme probleem wat we ook al hadden met programmeertalen, de reden dat programmeertalen bestaan is omdat menselijke taal erg ambigue is. Er is een reden waarom je met een idee niet zomaar omzet in een werkende applicatie hebt, de realiteit is erg complex en vol met uitzonderingen/business logica/etc, die ook nog eens exact moet zijn. Taal is niet exact.

Dat is de reden dat automatiseringstaken vaak het beste werken als de specificaties volledig duidelijk en niet ambigue zijn. En daarmee kom je weer op het oorspronkelijke probleem van software development, 100% duidelijke en correcte specificaties bestaan niet en ze veranderen altijd. Agile was hierin de oplossing, accepteer dat de specificaties ambigue zijn en altijd wijzigen.

De wens van een prompt naar perfecte code komt dus ook steeds meer neer op het van te voren hebben van de perfecte specificatie. En dat is natuurlijk het ideale eind model, als je de exacte specificatie hebt, dan kan je in principe ook de code genereren. Maar weinig bedrijven zijn in staat om op die manier te werken en ook programmeurs die goed zijn zouden in het verleden zulke code ook handmatige hebben kunnen produceren.

En dat is de core uitdaging software development waar het allemaal begint, wat zijn exacte specificaties ? En hoe passen die binnen de architectuur/technische uitdagingen/ beperkingen ?

Precies, programmeertalen bestaan juist omdat er geen ambiguiteit bestaat. In tegenstelling tot natuurlijke taal, wat vol interpretatie, grijs gebied en dubbelzinnigheid zit.

Maar naast de betrouwbaarheid van de output zouden mensen als @TheGhostInc en anderen die AI gebruiken ook oog moeten hebben voor hetgeen ze erin gooien.

Privedata, financiële cijfers, intellectueel eigendom, of juist complete bagger en incomplete/ foutieve data. Ik ga er vanuit dat álles wordt bewaard en op z'n beurt weer gebruikt wordt om 'te trainen'. Naast de privacyissues heb je ook nul idee welk hersenspinsel van welke gek er nu weer in de data belandt.

nieuws: 'Microsoft blokkeert intern gebruik Claude Fable 5 omdat Anthropic data bewaart'

Het is eigenlijk ook bizar hoeveel (gevoelige) data er bedrijfsmatig wordt gestopt in die LLMs. Ik hoor afdelingen die complete PDFs vol plannen, cijfers en schema's door 'chat' gooien om een wekelijkse WhatsApp samenvatting voor het personeel te genereren... Ga er maar vanuit dat die data maar al te graag bewaard wordt, ook al draai je je 'eigen bedrijfscloud' van welke bekende AI dan ook.

[Bryan Vreijsen]

Eens met wat hierboven gezegd wordt: de discussie verplaatst zich inderdaad van 'code kloppen' naar 'code auditen'.

Het grootste gevaar van AI-gedreven development is wat mij betreft niet de vervanging van de programmeur, maar de kwaliteitsverwatering. Vroeger was het schrijven van code een natuurlijke 'speed bump': je moest even nadenken voordat je iets typte. Met AI kun je nu in seconden een enorme hoeveelheid code uitspugen. Als je niet exact begrijpt wat er onder de motorkap gebeurt, dan is die code niks meer dan een 'black box' die je later in productie alsnog om de oren vliegt.

Over het 'junior-probleem' waar veel mensen naar verwijzen: ik denk dat we naar een model moeten waarbij AI niet de leerkracht is, maar de sparringpartner. Als je als junior blind vertrouwt op een AI-output zonder te snappen hoe de architectuur eronder in elkaar zit, blijf je eeuwig junior (of erger: word je een 'spaghetti-generator').

De 'fun' waar Lethalis eerder over sprak, verplaatst zich wat mij betreft. Het is minder 'lekker prutsen' en meer 'systeemarchitectuur bewaken'. Of dat voor iedereen even leuk is? Misschien niet. Maar de behoefte aan mensen die de waarom-vraag kunnen stellen boven de hoe-vraag, die is groter dan ooit. Als je die stap niet maakt en enkel "prompt-engineer" speelt zonder de basis te kennen, dan word je inderdaad een vervangbare kracht. De echte engineer van de toekomst is degene die de AI kan temmen, niet degene die het blind volgt.

[artjan]

die verandering van kloppen naar auditing: dit is daarbij een relevant aspect, op basis van ervaringen in automatiseren: https://carlhendrick.substack.com/p/ai-brain-fry-workslop-and-the-ironies

"But the designer who tries to eliminate the operator still leaves the operator to do the tasks which the designer cannot think how to automate. What remains after automation is not a simplified role but an arbitrary residue of the most demanding, most ambiguous, and least supported work in the entire system. The human is not replaced. In other words, the human is paradoxically left with the hardest parts, and given almost no preparation for them."


En het zal vooral door klakkeloos AI gebruik zijn, maar AI is geen solve all, ja de numbers go up, maar ook de vervelende: https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways

Voor degenen die AI gebruiken, en zeker als je dat heel doelmatig doet, wat is jullie indruk mbt bugs, incidents en churn?

[Glashelder]

artjan schreef op maandag 15 juni 2026 @ 10:43:
Voor degenen die AI gebruiken, en zeker als je dat heel doelmatig doet, wat is jullie indruk mbt bugs, incidents en churn?

Niet echt veranderd. Wel kom je af en toe bij meer freestyle projecten (projecten die nog niet afgegrendeld zijn met hooks en claude.md files) dat Claude wat vreemde keuzes maakt. 99 van de 100 keer worden migrations gemaakt door Entity en ineens besluit hij zelf migrations te gaan schrijven.

Ook om soms ineens minimal API’s te schrijven ipv gewoon controllers in ASP.net. Daar kom je vrij snel achter maar WTF.

[Skywalker27]

Leuk allemaal die AI tot de echte kosten door berekend gaan worden , Want de prijzen voor tokens zijn nu nog maar een fractie.

[ Voor 29% gewijzigd door Skywalker27 op 15-06-2026 15:49 ]

[Wozmro]

Och, de snelste (AI-)chip van vandaag is de Commodore64 van morgen.

Streaming, on demand video op hoge kwaliteit werd vroeger ook weggezet als onbetaalbaar, ging nooit doorbreken. Zeiden de televisiezenders..

AI en de mens zijn heel complementair. De mens die met AI als hulpmiddel projecten doet, dat is de grote meerwaarde.

[geekeep]

Bryan Vreijsen schreef op maandag 15 juni 2026 @ 09:42:
Eens met wat hierboven gezegd wordt: de discussie verplaatst zich inderdaad van 'code kloppen' naar 'code auditen'.

Het grootste gevaar van AI-gedreven development is wat mij betreft niet de vervanging van de programmeur, maar de kwaliteitsverwatering. Vroeger was het schrijven van code een natuurlijke 'speed bump': je moest even nadenken voordat je iets typte. Met AI kun je nu in seconden een enorme hoeveelheid code uitspugen. Als je niet exact begrijpt wat er onder de motorkap gebeurt, dan is die code niks meer dan een 'black box' die je later in productie alsnog om de oren vliegt.

Over het 'junior-probleem' waar veel mensen naar verwijzen: ik denk dat we naar een model moeten waarbij AI niet de leerkracht is, maar de sparringpartner. Als je als junior blind vertrouwt op een AI-output zonder te snappen hoe de architectuur eronder in elkaar zit, blijf je eeuwig junior (of erger: word je een 'spaghetti-generator').

De 'fun' waar Lethalis eerder over sprak, verplaatst zich wat mij betreft. Het is minder 'lekker prutsen' en meer 'systeemarchitectuur bewaken'. Of dat voor iedereen even leuk is? Misschien niet. Maar de behoefte aan mensen die de waarom-vraag kunnen stellen boven de hoe-vraag, die is groter dan ooit. Als je die stap niet maakt en enkel "prompt-engineer" speelt zonder de basis te kennen, dan word je inderdaad een vervangbare kracht. De echte engineer van de toekomst is degene die de AI kan temmen, niet degene die het blind volgt.

Of het nou een leerkracht of sparringpartner is, een vereiste is dat diegene snapt waar hij/zij mee bezig is en/of op fouten gewezen wordt. Een generatieve AI die onnodig positief/instemmend is en daarnaast geen benul van juist of onjuist heeft, is een heeele slechte leraar/partner.

Maar de gemiddelde mens omarmt de soms dubieuze output blijkbaar met alle liefde, gezien de populariteit van AIs als assistent of zelfs partner..

[geekeep]

Wozmro schreef op maandag 15 juni 2026 @ 16:28:
Och, de snelste (AI-)chip van vandaag is de Commodore64 van morgen.

Streaming, on demand video op hoge kwaliteit werd vroeger ook weggezet als onbetaalbaar, ging nooit doorbreken. Zeiden de televisiezenders..

AI en de mens zijn heel complementair. De mens die met AI als hulpmiddel projecten doet, dat is de grote meerwaarde.

Het wordt nu over de hele wereld ingezet als vervanging van, dat is iets heel anders dan complementair zijn. We gaan een enorme berg aan kennis verliezen, gezien de ontslagen die gevallen zijn en nog gaan komen.

AI is geen hulpmiddel, zoals een tafelzaag dat voor een meubelmaker is. AI is de persoonlijke assistent die gevraagd wordt een nieuwe tuinset te ontwerpen, te bouwen en te verkopen. Om erna te moeten checken of de stoelen veilig zijn, de ontwerpen niet gestolen zijn en de rekening niet een 0 te weinig bevat. En dat dan in 100-voud, want die assistent heeft een leger aan eigen assistenten, die op hun beurt hetzelfde ondernomen hebben. Oh, en volgende week komt er een nieuwe update, die het gedrag van de assistent aanpast met onbekende gevolgen.

[GoingDutch]

Sinds halverwege vorig jaar is AI goed genoeg om zelf alle code te schrijven en schrijf ik zelf geen code meer. De jaren daarvoor was het inderdaad niet goed genoeg en ik denk dat daar de perceptie vandaan komt dat AI het niet of niet goed kan. De kwaliteit van de meeste code is inmiddels goed maar het blijft zinvol om zelf een achtergrond in software ontwikkeling te hebben om bij te sturen. En de snelheid waarmee het code schrijft kan een mens nooit tegen op, het schrijft in een paar minuten waar ik uren of langer over doe.

Ook voor architectuur vragen, schrijven van documentatie en rapporten en tests is AI inmiddels voor mij onmisbaar. Ik vind de AI zelfs veel beter dan veel van mijn ex collega’s. Ook bij het begrijpen en refactoring van slecht geschreven (menselijke) code werkt AI erg goed.

Bij privacy en geheimhouding zie ik nog wel beperkingen. In de defensie industrie kun je niet zo even een cloud AI inzetten maar alleen lokale open source modellen.

[wiemelen]

GoingDutch schreef op maandag 29 juni 2026 @ 23:34:
Sinds halverwege vorig jaar is AI goed genoeg om zelf alle code te schrijven en schrijf ik zelf geen code meer. De jaren daarvoor was het inderdaad niet goed genoeg en ik denk dat daar de perceptie vandaan komt dat AI het niet of niet goed kan. De kwaliteit van de meeste code is inmiddels goed maar het blijft zinvol om zelf een achtergrond in software ontwikkeling te hebben om bij te sturen. En de snelheid waarmee het code schrijft kan een mens nooit tegen op, het schrijft in een paar minuten waar ik uren of langer over doe.

Beetje vreemde vraag misschien, maar wat voor soort code schrijf je dan?
Wij zijn ook best wel wat aan het experimenteren met AI code, maar dit niveau halen wij bijlange nog niet met SAP code ontwikkeling.
Als simpele test hadden we afgelopen week een nieuw rapport genomen, met iets of wat complexere logica in. Ik had het programma zelf geschreven terwijl mijn collega het probeert te genereren via een prompt.
Ik was mijn unit test al aan het uitvoeren terwijl hij zijn prompt nog aan het finetunen was.
En dan had hij achteraf nog werk om de bugjes eruit te halen en bepaalde stukjes code zelf te schrijven.
Leesbaarheid en structuur van de AI code is wel enorm verbeterd, maar heeft ook nog wat finetuning nodig.

Voor simpele logica werkt het best goed, maar complexere logica lukt nog niet.
Zeker niet in gevallen waarbij logica moet her/gebruikt worden waarvoor wij onze eigen routines al geschreven hebben.
Let wel, wij worden verplicht om met Co-pilot te werken.

Dus gebruiken wij AI vooral om code snippets te genereren en simpele(re) logica te schrijven. Beetje als een supergebruiksvriendelijke versie van de oude Google searches.
Voor de meer complexe dingen, is de post van @artjan (link) zeer relevant, zeker volgende quote "The human is not replaced. In other words, the human is paradoxically left with the hardest parts".

[Glashelder]

wiemelen schreef op dinsdag 30 juni 2026 @ 10:11:
[...]

Let wel, wij worden verplicht om met Co-pilot te werken.

Daar gaat het mis. Claude is gewoon veel beter. Co-pilot kan ook Opus gebruiken (het model van Claude), maar in mijn ervaring is Claude Code velen malen beter dan copilot.

[Fr33z]

geekeep schreef op dinsdag 16 juni 2026 @ 18:36:
[...]

Het wordt nu over de hele wereld ingezet als vervanging van, dat is iets heel anders dan complementair zijn. We gaan een enorme berg aan kennis verliezen, gezien de ontslagen die gevallen zijn en nog gaan komen.

AI is geen hulpmiddel, zoals een tafelzaag dat voor een meubelmaker is. AI is de persoonlijke assistent die gevraagd wordt een nieuwe tuinset te ontwerpen, te bouwen en te verkopen. Om erna te moeten checken of de stoelen veilig zijn, de ontwerpen niet gestolen zijn en de rekening niet een 0 te weinig bevat. En dat dan in 100-voud, want die assistent heeft een leger aan eigen assistenten, die op hun beurt hetzelfde ondernomen hebben. Oh, en volgende week komt er een nieuwe update, die het gedrag van de assistent aanpast met onbekende gevolgen.

aanvulling: het wordt verkocht/aangeprezen als vervanging van. Het lukt nog heel weinig en er zijn echt geen honderdduizenden mensen die ineens worden ontslagen (tot nu toe). de AI-bedrijven verkopen de hype en hopen dat mensen er lang genoeg in meegaan. Misschien wordt het wel groot, misschien niet.