Carrièreperspectief software development in AI revolutie

[pieter.a]

R_Zwart schreef op zaterdag 11 juli 2026 @ 16:04:
[...]

Ik denk dat mensen "slecht" programmeren omdat het zo laagdrempelig is om even snel iets te proberen. En als het dan werkt laat je het daarbij en kan een prototype in een product terecht komen.

Er zijn makkelijk tientallen redenen te benoemen waardoor we "slechte" door mensen gemaakte code tegen komen.

[Kist]

De vraag is natuurlijk dan wel hoe goed is die AI gegenereerde code dan echt? Ik zie de afgelopen jaren de problemen die door mijn testers(test lead perspectief) wordt gevonden significant toenemen. En ja dat loopt parallel aan de hoeveelheid AI gebruik van onze bouwers.

En dan praten we op sommige type features over honderden procenten meer dan we een jaar of twee geleden zouden hebben gevonden. Vaak ook meer op kritieke paden.

Door ons type applicatie(we hebben geen noemenswaardige voorkant) is het ook niet zo dat we gebruik maken van agents die voor ons allerlei paden door de voorkant lopen.

We zien ook een vals vertrouwen bij veel developers. Dan wordt bijvoorbeeld letterlijk gevraagd, joh wat heb je gedaan aan error handling, en dan krijg je een heel relaas over hoe dat allemaal gedaan wordt. Vervolgens kijk je paar minuten naar het endpoint en dan zie je dat niks conform spec is afgehandeld en dat door kleine verschillen het grote problemen elders zal veroorzaken. Komt het leuk door je lokale tests maar daar hebben we weinig aan.

[Hillie]

Als ik de reacties zo eens lees dan bekruipt mij het idee dat menigeen denkt dat AI een soort single-shot oplossing is, terwijl je als menselijke ontwikkelaar iteratief aan zaken werkt.

Zelf ben ik alweer een paar decennia actief in de chipontwikkeling, front end digitale design verificatie. Ik werk sinds korte tijd bij een AI startup waar iedereen eigenlijk vrije keuze heeft in het gebruik van AI hulpmiddelen of niet. Zelf ben ik jaren geïnteresseerd doch terughoudend geweest, maar inmiddels tik ik vrij weinig code zelf meer, maar ik stuur aan en beslis over hoe en wat. Het mooie is eigenlijk ook wel dat je veel sneller zaken op kunt zetten en bij kunt stellen. Ook het abstraheren naar generieke en/of common componenten gaat vlot. Sterker nog, dat heb ik de laatste weken ook gedaan. Een aantal collega's had eigen componenten gebouwd voor een generieke interface, ieder met net kleine zaken anders (vooral in de API en gebruiksgemak). Dat heb ik in een paar slagen met m'n maat Claude in een generieke component gebruikt en het mooie is dat die ook automatisch opgepikt wordt in andere projecten door de AI. Ook weer teruggeintegreerd in de omgevingen van collega's en ik heb exact 0 klachten gehad dat iets niet meer werkte.

Maar voor dat laatste is de menselijke input belangrijk. Je moet nog altijd iteratief te werk blijven gaan. Die droom van een single shot oplossing zie ik ook weleens voorbijkomen, maar dat hangt dan wel af van een volledig duidelijke probleemstelling en specificatie. En dat is vaak onmogelijk. En in de dagelijkse realiteit van velen waarin specificaties en wensen van klanten geregeld veranderen is een iteratieve aanpak gewoon noodzakelijk. Voor AI begonnen we ook niet volledig opnieuw als er een paar dingen bijgesteld werden. Op dat punt zijn de tools gelukkig ook goed genoeg. Ik laat geregeld analyse uitvoeren op documentatie en implementatie en het aanpassen van bestaande code base gaat heel goed. Wel blijft het natuurlijk zaak om zelf grenzen te stellen in wat gedaan moet worden, net zoals je een externe inhuur geen vrije hand geeft om alles maar naar wens en eigen interpretatie aan te passen.

En daar zie ik een punt waar de huidige tools nog kunnen groeien, interpretatie en redeneren. De AI wil soms weleens teveel in de eerste prompt/suggestie blijven hangen, of een punt wat voor mensen duidelijk nog open is toch maar te interpreteren. Ook de overtuiging van het eigen gelijk versus het om input vragen mag nog weleens beter. Misschien (waarschijnlijk) ligt dat ook aan mijn persoonlijke (on)vermogen tot betere prompts of configuratie. Al doende leert men. Maar ik verwacht wel dat er verbetering blijft komen in de menselijke interactie en interpretatie.

[Wozmro]

Zou een AI-agent dan ook niet goed in staat moeten zijn om de afgesproken kaders in de gaten te houden, dat iedereen zich daaraan houdt, zowel de mens als een andere AI?

Dat je een waarschuwing krijgt als je iets wil aanpassen wat niet binne de afspraken valt?

Iedereen is wel eens verstrooid of het moet snelsnel, doen wel later nog wel eens deftig,...

[Liegebeest]

Hillie schreef op zondag 12 juli 2026 @ 17:29:
En daar zie ik een punt waar de huidige tools nog kunnen groeien, interpretatie en redeneren. De AI wil soms weleens teveel in de eerste prompt/suggestie blijven hangen, of een punt wat voor mensen duidelijk nog open is toch maar te interpreteren. Ook de overtuiging van het eigen gelijk versus het om input vragen mag nog weleens beter. Misschien (waarschijnlijk) ligt dat ook aan mijn persoonlijke (on)vermogen tot betere prompts of configuratie. Al doende leert men. Maar ik verwacht wel dat er verbetering blijft komen in de menselijke interactie en interpretatie.

Je vraagt daar om een bewustzijn, wat er niet is. Het is geen rationeel, denkend iets; het is en blijft een tekstgenerator.

Wat betreft het “blijven hangen in een prompt”: meerdere mensen hebben gewaarschuwd voor wat er gebeurt met een lange context. De een noemt het “the dumb zone”, een ander stelt dat je de belangrijkste dingen aan het begin en het eind van de context moet hebben, omdat modellen minder waarde hechten aan “het middenstuk”.

[Furion2000]

Mijn grootste 'valkuil' blijft dat AI te graag wil gaan en guardrails (MUST / SHOULD) stiekem toch vaak weer in verval raken. Als in ik heb een regel dat hij een functie moet testen maar heb claude al meerdere keren moeten zeggen dat die 25 testen voor een simpele functie overkill zijn. Mijn context zal vast niet helemaal optimaal zijn, maar imo ligt het niet alleen daar aan. Zelfde als de responses, vaak te langdradig, ondanks dat ik wil dat hij bondig reageert.

Ben wel benieuwd naar de nadelen die anderen ervaren tijdens het programmeerwerk.

[Reinier]

Vijf taalfouten in de topictitel plus de eerste zin van de openingspost. Wat zijn we allemaal blij met AI
We hoeven niet meer na te denken en inderdaad worden we allenaal steeds dommer en luier.
Ik ben inmiddels zo ver dat ik AI-geile collega's niet meer help als ze ergens niet uitkomen en Claude/ChatGPT/Copilot/etc. ze niet meer kunnen helpen

/rant

[Pieter.txt]

Glashelder schreef op vrijdag 10 juli 2026 @ 12:03:
[...]

Niet. Je laat de code beoordelen door andere AI. Elke developer zal beamen dat het kut is om code van anderen te lezen en dat is niet anders met AI code.

Dit is gewoon een soortgelijke discussie als toen C kwam en Assembly eruit ging. En toen unmanaged talen voor veel projecten werden ingeruild door managed. Nu zetten we een veel grotere stap: geen eigen code schrijven.

Die vergelijking gaat IMHO toch mank. Bij de stap van de ene programmeertaal naar de andere veranderd weliswaar de taal, maar de programmeur moet zelf blijven nadenken. Ik zie meer in de vergelijking tussen zelf een verbouwing uitvoeren of dat laten doen door een aannemer. In het eerste geval snap je precies hoe alles werkt en hoe het in elkaar zit. Als er dan iets niet werkt, dan weet je veel beter waar je moet zoeken. Dit in tegenstelling tot wanneer je een aannemer alles laat doen en jij nog steeds twee linker handen hebt.

De uitdaging met AI is dan ook dat we naast technical debt nu ook last krijgen van cognitive debt. Zoals iemand anders al schreef, de code van anderen lezen en vooral begrijpen is vaak erg lastig. Onderzoek van onder meer Anthropic laat dit ook zien. Naar mate de complexiteit van de te schrijven code toeneemt, neemt de tijdswinst van het gebruik van AI t.o.v. ontwikkelaars af. Het echte probleem zit erin dat de groep die AI gebruikt slechter scoort op begrip van de code, het doen van onderhoud of uitbreidingen en debugging.

Nu is dit gemeten m.b.v. ontwikkelaars die, naar ik aanneem, allemaal zijn "opgegroeid" zonder AI en dus nog handson ervaring hebben met programmeren en zaken als design patterns. Ik vraag me af hoe iemand zoiets als het visitor-pattern goed gaat leren als AI alles voor hem doet. En kun je dat dan nog beoordelen als je in het rijtje "see one, do one, teach one" nooit voorbij "see one" komt?

[Glashelder]

Reinier schreef op maandag 13 juli 2026 @ 09:11:
Vijf taalfouten in de topictitel plus de eerste zin van de openingspost. Wat zijn we allemaal blij met AI
We hoeven niet meer na te denken en inderdaad worden we allenaal steeds dommer en luier.
Ik ben inmiddels zo ver dat ik AI-geile collega's niet meer help als ze ergens niet uitkomen en Claude/ChatGPT/Copilot/etc. ze niet meer kunnen helpen

/rant

Hoeveel zullen dat er geweest zijn zonder AI en/of spellingcontrole? Waarschijnlijk nog meer.

@Pieter.txt goede punten, waar we als ontwikkelaars mee om moeten leren gaan. Ik denk persoonlijk niet dat de oplossing zal blijven liggen in menselijke reviews, maar eerder in de modellen leren hoe ze goede onderhoudbare oplossingen bouwen, waarbij wij als mensen hier niet over na hoeven denken. In plaats daarvan hebben we goede controlevragen nodig waarbij het model zelf gaat reflecteren (of een ander model).

Ik verwacht echter wel dat zaken als techical debt veel minder een rol gaan spelen, net zoals geheugengebruik vandaag de dag nauwelijks nog een rol speelt terwijl dat vroeger heel belangrijk was. Simpelweg omdat het contextwindow van LLM's groter en groter wordt en de snelheid waarmee tokens worden uitgepoept zal ook steeds hoger worden. Who cares over dat kleine beetje technical debt dan? En als niemand je code nog leest, who cares, zolang de LLM het maar begrijpt.

[edie]

De "prompt" is gewoon de nieuwe hype in programmeertaalland. Met als enige probleem dat de output niet consistent is en praktisch altijd achterloopt op de ontwikkelingen, want de nieuwe ontwikkelingen zitten niet in de statistieken van de tekstgenerator.

Plus het is volkomen onzinnig: prompt -> statistisch gegenereerde code in bepaalde taal -> compiler -> machinecode. Waarom kan dat ding niet meteen machinecode genereren? Dat zou toch veel efficienter zijn? Het enige dat we nu hebben gedaan is een extra stap toegevoegd aan het begin van de softwareontwikkeling... Lekker efficient bezig mensen!

[Corrit]

edie schreef op maandag 13 juli 2026 @ 09:59:
De "prompt" is gewoon de nieuwe hype in programmeertaalland. Met als enige probleem dat de output niet consistent is en praktisch altijd achterloopt op de ontwikkelingen, want de nieuwe ontwikkelingen zitten niet in de statistieken van de tekstgenerator.

Plus het is volkomen onzinnig: prompt -> statistisch gegenereerde code in bepaalde taal -> compiler -> machinecode. Waarom kan dat ding niet meteen machinecode genereren? Dat zou toch veel efficienter zijn? Het enige dat we nu hebben gedaan is een extra stap toegevoegd aan het begin van de softwareontwikkeling... Lekker efficient bezig mensen!

Daar ben ik het niet mee eens. Ik gebruik claude regelmatig om stukjes code te schrijven en vind het toch wel verdomd handig dat claude leesbare code produceert die ik zelf nog even kan doorlezen en checken op correctheid. En als ik dan nog labelteksten of kleuren oid wil aanpassen dan doe ik dat rechtstreeks in de code en hoef ik het niet aan claude te vragen.

Efficiënte code klinkt leuk maar is pas zinvol als het (honderd)duizenden keren wordt uitgevoerd. Voor veruit de meeste toepassingen is het veel belangrijker dat de functionaliteit controleerbaar is dan dat het stukje software zo snel mogelijk werkt. (en ik ben iemand die vaak zit te vloeken op trage software )

[Hillie]

Liegebeest schreef op maandag 13 juli 2026 @ 06:34:
[...]

Je vraagt daar om een bewustzijn, wat er niet is. Het is geen rationeel, denkend iets; het is en blijft een tekstgenerator.

Nee, ik vraag "slechts" om nog betere interpretatie en aanpassing aan de persoon aan de prompt. Het verschil met een jaar en twee jaar terug is al enorm en ik verwacht dat die verbetering nog wel een tijdje door blijft zetten.

Wat betreft het “blijven hangen in een prompt”: meerdere mensen hebben gewaarschuwd voor wat er gebeurt met een lange context. De een noemt het “the dumb zone”, een ander stelt dat je de belangrijkste dingen aan het begin en het eind van de context moet hebben, omdat modellen minder waarde hechten aan “het middenstuk”.

Daarom schrijf ik een paar zinnen en blijf aanpassen/verbeteren, de iterative aanpak. Ik lees overigens nauwelijks wat de zogeheten experts vinden, dat zijn over het algemeen net zulke krabbers in de marge als ik, alleen hebben zij een paar maanden extra ervaring.

Wat me sinds het begin al stoort is hoe makkelijk de engines overtuigd zijn van de correctheid van foutieve interpretatie, maar dan ook weer meteen het roer omgooien als je tegengas geeft. Meer terughoudendheid en terugkoppeling zou wel prettig zijn.

[Stukfruit]

Wozmro schreef op zondag 12 juli 2026 @ 18:26:
Zou een AI-agent dan ook niet goed in staat moeten zijn om de afgesproken kaders in de gaten te houden, dat iedereen zich daaraan houdt, zowel de mens als een andere AI?

Het automatiseren van de automatisering inderdaad

Zelfs met een agent erbij een tijdrovende klus...

Iedereen is wel eens verstrooid of het moet snelsnel, doen wel later nog wel eens deftig,...

Zodra je programmeerwerk als tool gaat zien om echte problemen mee op te lossen dan is dat sowieso geen uitdaging meer

Voor een agent is je code context. Niet in metaforische zin, maar letterlijk. Het is puur context.

Dus als je begint met slechte code maar zelf de skills hebt om te vertellen hoe het beter moet (of de skills hebt om te vragen hoe het beter moet ) dan krijg je door de werking van taalmodellen ook de effecten van compounding: is de code die je als input gebruikt goed of beter, dan wordt natuurlijk ook automatisch dat patroon vaker gevolgd dan wanneer je ongecontroleerde spaghetti laat genereren.

Uiteraard moet je dat alsnog onder toeziend oog doen, maar langdurige refactors waarbij je 2 weken met 50 tabs open zat om het werk te verrichten dat nodig was om eindelijk en überhaupt te kunnen beginnen aan feature X zijn nu wel een beetje voorbij.

2 uur laten refactoren, uurtje controleren, daarna beginnen met de feature.

[Stukfruit]

Maar het belangrijkste is echt dat je die IDE er weer bij pakt en niet achter de tool van Claude gaat zitten slapen.

Dat is de grootste fout die je kan maken.

[Hillie]

Stukfruit schreef op maandag 13 juli 2026 @ 12:21:
Maar het belangrijkste is echt dat je die IDE er weer bij pakt en niet achter de tool van Claude gaat zitten slapen.

Dat is de grootste fout die je kan maken.

Dat is denk ik wel de kern en zodra je dat niet doet is het heel makkelijk het overzicht kwijt te raken.

[Marc3l]

Stukfruit schreef op maandag 13 juli 2026 @ 12:21:
Maar het belangrijkste is echt dat je die IDE er weer bij pakt en niet achter de tool van Claude gaat zitten slapen.

Dat is de grootste fout die je kan maken.

Dat zeker, anders ben je net zoals 'vroeger' aan het copy/pasten van bijvoorbeeld Stack Overflow. 
Mijn Claude is ook Italiaans, hij maakt graag spagetti, maar is ook niet vies van 
functies bedenken die niet bestaan voor een taal waar ik mee bezig ben.

edie schreef op maandag 13 juli 2026 @ 09:59:
De "prompt" is gewoon de nieuwe hype in programmeertaalland. Met als enige probleem dat de output niet consistent is en praktisch altijd achterloopt op de ontwikkelingen, want de nieuwe ontwikkelingen zitten niet in de statistieken van de tekstgenerator.

Nee, zeker geen hype, het is zeker wel iets wat je tijd bespaart.
Maar niet alleen code schrijven, ook herhalende taken. Ik heb bijvoorbeeld een opensource package.
Bij een update moet ik de code fixer runnen, testen runnen, git commit (bericht) maken, nieuwe tag aan maken, nieuwe release maken. Dit doe ik nu met 1 Claude skill.

[Liegebeest]

Hillie schreef op maandag 13 juli 2026 @ 12:19:
[...]. Wat me sinds het begin al stoort is hoe makkelijk de engines overtuigd zijn van de correctheid van foutieve interpretatie, maar dan ook weer meteen het roer omgooien als je tegengas geeft. Meer terughoudendheid en terugkoppeling zou wel prettig zijn.

maar dat is wat ik eerder zei: er is helemaal geen overtuiging. Er is niets aan de overkant dat is overtuigd van diens gelijk, want er is geen bewustzijn. Het is een tekstgenerator en die is gebouwd om zelfverzekerd te klinken en om beleefde tekst te schrijven wanneer iemand het niet eens is.

[edie]

Marc3l schreef op maandag 13 juli 2026 @ 15:05:

[...]

Nee, zeker geen hype, het is zeker wel iets wat je tijd bespaart.
Maar niet alleen code schrijven, ook herhalende taken. Ik heb bijvoorbeeld een opensource package.
Bij een update moet ik de code fixer runnen, testen runnen, git commit (bericht) maken, nieuwe tag aan maken, nieuwe release maken. Dit doe ik nu met 1 Claude skill.

Dat specifiek kan ook met een simpel .bat of .sh scriptje (of met een custom task binnen je favoriete IDE). Geen LLM voor nodig, en nog sneller, voorspelbaarder en goedkoper ook.

Juist herhalende zaken zijn veel beter te automatiseren via scripts of templates dan het via een LLM te laten doen. Hier op het werk ook: wordt gepoogd om Claude een 'standaard web api project' te laten genereren met onze eigen code/libraries/configuratie al volledig klaar. Heeft meerdere weken aan prompts gekost. Ondertussen had men ook ook in 5 minuten gewoon een template kunnen maken van een bestaand project welke vervolgens te selecteren is bij nieuwe projecten.

[Marc3l]

edie schreef op maandag 13 juli 2026 @ 16:13:
[...]

Dat specifiek kan ook met een simpel .bat of .sh scriptje (of met een custom task binnen je favoriete IDE). Geen LLM voor nodig, en nog sneller, voorspelbaarder en goedkoper ook.

Juist herhalende zaken zijn veel beter te automatiseren via scripts of templates dan het via een LLM te laten doen. Hier op het werk ook: wordt gepoogd om Claude een 'standaard web api project' te laten genereren met onze eigen code/libraries/configuratie al volledig klaar. Heeft meerdere weken aan prompts gekost. Ondertussen had men ook ook in 5 minuten gewoon een template kunnen maken van een bestaand project welke vervolgens te selecteren is bij nieuwe projecten.

Deels, een commit message maken aan de hand van de staged code niet.
Ik heb Claude Pro en ga zelden door mijn (sessie)tokens heen.

[Hillie]

edie schreef op maandag 13 juli 2026 @ 16:13:
[...]

Dat specifiek kan ook met een simpel .bat of .sh scriptje (of met een custom task binnen je favoriete IDE). Geen LLM voor nodig, en nog sneller, voorspelbaarder en goedkoper ook.

Juist herhalende zaken zijn veel beter te automatiseren via scripts of templates dan het via een LLM te laten doen. Hier op het werk ook: wordt gepoogd om Claude een 'standaard web api project' te laten genereren met onze eigen code/libraries/configuratie al volledig klaar. Heeft meerdere weken aan prompts gekost. Ondertussen had men ook ook in 5 minuten gewoon een template kunnen maken van een bestaand project welke vervolgens te selecteren is bij nieuwe projecten.

Daar gaat het dus duidelijk om slimme en juiste keuzes maken. Als je kunt scripten dan is dat meestal duidelijk de betere keuze. En dan kun je Claude het script laten schrijven.

Overigens is Claude gelukkig al voorzien van aardig wat middelen om te bepalen wanneer te scripten als het zelf met iets bezig gaat. Dat scheelt ook alweer een hoop onzin.

[Kurkentrekker]

Om dan toch nog even in te gaan op de vraag die in de topictitel centraal staat: wat is het effect van AI op het carrièreperspectief van softwareontwikkelaars: ik denk dat die best wel groot is. Er zijn, zoals in de reacties hierboven ook ruimschoots aangetoond, veel situaties denkbaar waarbij de mens nog veel moet bijsturen. Waarbij kennis van onderliggende systemen, principes en best practices echt heel relevant is. Toch denk ik dat AI, met name de manier waarop het nu kan programmeren, een enorm effect zal hebben op de carrièreperspectieven van softwareontwikkelaars. (Overigens, @Reinier, het is vaak de AI-spellingscontrole die nutteloze spaties juist toevoegt! Kots-emoji… Maar bedankt voor je observatie)

De reden dat AI zo’n groot effect zal hebben is dat het een heel groot deel van de vraag in de markt kan doen afnemen. Ja, een groot deel van de markt bestaat uit ontwikkelaars die dingen maken die je niet gemakkelijk bij elkaar kunt promoten (misschien nog wel efficiënter kunt laten doen). Maar een zeer groot deel van de markt bestaat ook gewoon uit eenvoudig werk. Een simpel tooltje in de bedrijfsvoering hier, een CRUD-systeempje daar, een CMS-je, allemaal kleine projecten die vroeger gerust duizenden euro’s aan maatwerk kostten, en nu zo in een avondje door Claude in elkaar gezet worden. Dat is niet spannend, maar een aanzienlijk deel van de  softwareontwikkelaars zijn gewoon het grootste deel van hun werkweek bezig met dit soort projecten. En die carrières zijn echt wel eindig. Niet allemaal, maar hetzelfde (of een beter) resultaat kan ook met een kwart van de mensen worden bereikt.

Waar leidt dat toe? Een grote verschuiving op de arbeidsmarkt: als softwareontwikkelaars ineens niet meer schaars zijn omdat alle figuren die vroeger Wordpress sites zaten te programmeren nu ineens nieuwe banen gaan zoeken, dan wordt de markt een stuk competitiever. Dan kun je dus niet meer met je BSc software engineering tekenen bij het kruisje, je lease-BMW ophalen, en 3x modaal verdienen in je startersfunctie.

Natuurlijk, er blijft heus werkgelegenheid voor de mensen die echt handig zijn en aan systemen werken die niet gemakkelijk kunnen worden gerund of onderhouden door AI-agents, maar de arbeidsmarkt zal er niet makkelijker op worden. Ik denk dus dat er een soort tweedeling zal kunnen ontstaan: de mensen die de echt complexe shit maken zullen misschien nog wel waardevoller worden (omdat juniors niet meer echt worden opgeleid en de eisen van de markt aan enterprise grade software alleen maar zullen toenemen), en dat de ontwikkelaars die vooral commodity-achtige applicaties maken juist enorm zal verslechteren. AI schrijft immers betere wegwerpcode.


Ps; geen AI gebruikt bij het schrijven van deze post. ik zeg het er maar even bij.

[Stukfruit]

Kurkentrekker schreef op maandag 13 juli 2026 @ 23:26:
AI schrijft immers betere wegwerpcode.

Daarom is ook daar aansturing (menselijk of geautomatiseerd) nodig om te voorkomen dat die code geschreven moet worden.

Als ik een dashboardje wil, dan verwacht ik iets in Grafana (intern) of zoiets als Refine (meer voor eindgebruikers), omdat je anders met een berg code en tests (zelfs BDD) eindigt die je zelf moet managen omdat een agent maar een beperkte aandachtsspanne kan hebben. Dat gaat vast nog omhoog, maar het is nu eenmaal hoe de achterliggende techniek werkt.

De beste code is code die je niet hoeft te schrijven. Dat blijft met een agent erbij en 17k tokens per seconde nog steeds staan omdat code niet alleen schrijf(generatie)werk is. Je moet de fouten eruit halen, het moet doen wat nodig is (en dat blijven doen), het moet efficiënt of snel kunnen draaien, je wil het kunnen hergebruiken omdat genereren onzinnige tijdverspilling is...

[Sissors]

Dan kun je dus niet meer met je BSc software engineering tekenen bij het kruisje, je lease-BMW ophalen, en 3x modaal verdienen in je startersfunctie.

Nu verwar je volgens mij Amerika met Europa. Op uitzonderingen na zijn de salarissen hier nooit zo geweldig geweest, en ik denk dat gemiddelde HBO'er blij is met een modaal salaris bij zijn startersfunctie. En juist degene die 3x modaal ging verdienen na zijn studie (oké niemand, 1.5x modaal dan), zal dat blijven doen, omdat de goede alleen maar productiever kunnen zijn. En natuurlijk er is meer aanbod op de markt. Maar laten we wel wezen, er is ook geen enkel andere engineering functie waarbij je ook communicatiewetenschappen kan studeren, een traineeship van een maand krijgen, en instromen.

[wiemelen]

De arbeidsmarkt heeft ook de neiging om zichzelf in evenwicht te houden.
Ik heb net even gezocht naar artikels over een verminderde in/uitstroom van studenten in IT richtingen. Blijkt toch dat er nu al een verminderde instroom zichtbaar is.
Benieuwd wat dit voor de toekomst gaat betekenen. De tijd van de gouden bergen zijn misschien voorbij, maar je hebt nog steeds (junior) IT'ers nodig, al is het bij bedrijven (veelal MKB), waar IT of automatisering nog steeds een vies of onbekend woord is. En zeker ook op bestaande posities waar AI zeker nog wel even tijd nodig heeft om goed te landen, waardoor de IT-ers zelf ook de tijd hebben om zich aan te passen aan de veranderende wereld (net zoals we al jaren doen).

• Digitaal Talent Nederland (10 feb 2026) – instroom HBO-ICT daalt met 14,4%.
  https://digitaaltalentned...-hbo-ict-vraagt-om-actie/
• BeInCrypto (20 jun 2026) – studenten verlaten informatica wegens angst voor AI-gerelateerd banenverlies.
  https://nl.beincrypto.com...ppen-inschrijving-daling/
• TechCrunch (15 feb 2026) – "The great computer science exodus (and where students are going instead).
  https://techcrunch.com/20...udents-are-going-instead/

[CVTTPD2DQ]

Sissors schreef op dinsdag 14 juli 2026 @ 08:34:
Nu verwar je volgens mij Amerika met Europa. Op uitzonderingen na zijn de salarissen hier nooit zo geweldig geweest, en ik denk dat gemiddelde HBO'er blij is met een modaal salaris bij zijn startersfunctie. En juist degene die 3x modaal ging verdienen na zijn studie (oké niemand, 1.5x modaal dan), zal dat blijven doen, omdat de goede alleen maar productiever kunnen zijn. En natuurlijk er is meer aanbod op de markt. Maar laten we wel wezen, er is ook geen enkel andere engineering functie waarbij je ook communicatiewetenschappen kan studeren, een traineeship van een maand krijgen, en instromen.

Maar wat is ‘goed’?

Vanaf het moment dat mensen de term ‘software engineering’ gingen gebruiken, werd al opgemerkt dat programmeurs relatief veel van hun tijd dezelfde problemen (al dan niet correct) oplosten. En dat het proces zoveel efficiënter zou zijn als er standaardmethoden werden gebruikt. In volgorde zijn de volgende zaken geprobeerd:

1. boeken, bijvoorbeeld Numerical Recipes of de boeken van Knuth. Dat recipes ‘recipes’ heet is al een indicatie dat het geen goed idee is om er zelf je eigen creatieve variant op te bedenken
2. Object-oriented programmeren één van de motivaties achter de hype was dat er een markt zou ontstaan voor componenten die, net als ICs, aan elkaar konden worden gekoppeld zonder te hoeven begrijpen hoe ze intern werkten. In plaats daarvan kregen we een combinatorische explosie van puzzelstukjes die op geen enkele manier in elkaar pasten.
3. Service-oriented architectures zodat je functionaliteit bij een derde partij on-demand kunt aanroepen, in plaats van zelf implementeren. Het resultaat is dat veel bedrijven een ‘service-landschap’ hebben van intern gebouwde services die vooral met elkaar praten.
4. Open Source en Stack Overflow om de barrière voor hergebruik nóg lager te maken.

Al die oplossingen draaiden om integratie, en alle integraties hebben nadelen: het begrijpen van de integratie kost zelf tijd, en redeneren over een black box is moeilijker (dus er is een grens waaronder integratie van een kleine component simpelweg niet rendabel is). De belangrijkste is natuurlijk churn, het continu bijwerken van de integraties naar nieuwere versies. Of niet, het laten versloffen, alle bugs en securityproblemen op de koop toenemen.

Het beroep van ‘software-developer’, ongeacht opleiding, convergeerde dus naar relatief eenvoudig en gelijkvormig onderhoudswerk. Misschien was iemand in staat om moeilijke nieuwe algoritmes te bedenken: jammer dan, de meeste bedrijven hebben geen moeilijke nieuwe algoritmes nodig. Een bootcamper was eigenlijk ook wel goed. En de salarissen kónden eenvoudigweg niet superhoog zijn, omdat de toegevoegde waarde zo laag was.

Een ‘goede’ developer in deze wereld was iemand die goed bestaande componenten kon integreren. Een goedverdienende was een developer die er heel snel in was, maar telkens weg was voordat die integratie door churn onrendabel werd in het onderhoud.

En dan nu LLMs, de ultieme patroonherkennende copy-paste machine. Als ik nog iets cynischer
zou zijn, zou ik me afvragen wat programmeurs nu weer zullen verzinnen om hun baantjes te kunnen behouden. Maar het is ook te zien als het antwoord op zestig, zeventig jaar aan pogingen om op een efficiënte manier software te ontwikkelen.

Ik ben het eigenlijk wel eens met @Glashelder : mensen hebben decennialang laten zien dat ze niet zo goed zijn in programmeren. En ik wil toevoegen, we zijn abominabel slecht in software engineering.

Er zal vast wel iets van menselijk werk in software development overblijven (net zoals er nog een paar timmermannen en hoefsmeden zijn), maar het is moeilijk om je voor te stellen hoe dat eruit zal zien. Of zelfs maar wat een ‘goede’ software developer is in deze situatie: de kwaliteiten die je eerst ‘goed’ maakten zijn nu niet zo belangrijk meer.

Verder vermoed ik dat het een kwestie van tijd is voordat aansprakelijkheid en wetgeving ertoe leiden dat bedrijven het als risico gaan beschouwen om code te leveren / draaien die niet door een LLM is nagelopen op securityproblemen.

LLMs zijn misschien niet de intelligentste securityanalisten, ze hebben wel het vermogen om onbeperkt hun volledige aandacht aan een probleem te geven, en dat effect zien we nu met de stortvloed aan CVEs die over ons wordt uitgestort (wat weer leidt tot churn, wat weer leidt tot meer werk voor mensen die ‘traditioneel’ werken).

Op termijn zal alles wat nu in software gebeurt natuurlijk gebeuren met banen die zich voornamelijk in het digitale domein afspelen. Doe je je werk op een computer en wordt het resultaat op een computer opgeslagen? Draait het om patroonherkenning en redeneren? Kijk maar uit

[wiemelen]

CVTTPD2DQ schreef op woensdag 15 juli 2026 @ 07:52:
Een ‘goede’ developer in deze wereld was iemand die goed bestaande componenten kon integreren. Een goedverdienende was een developer die er heel snel in was, maar telkens weg was voordat die integratie door churn onrendabel werd in het onderhoud.

Dat is 1 van de grote issues van externe consultants/programmeurs.
Ze verzinnen iets, maar blijven niet lang genoeg hangen om de rotzooi achteraf op te ruimen of te leren uit hun fouten. En op hun volgende project herhalen ze exact dezelfde fout "want het werkt op een vorig project".
In mijn ogen moet een goede programmeur/oplossing niet zorgen voor de allerbeste/allersnelste/modernste oplossing. Alle programmeurs binnen 1 team/bedrijf moeten achter dezelfde visie staan die er voor zorgt dat er een goede, onderhoudbare (ook door juniors), gedocumenteerde, gebruiksvriendelijke oplossing komt, liefst met gebruik van generieke, herbruikbare, makkelijk te onderhouden (custom) componenten. Een soort "future proof" oplossing waarbij toekomstige wijzigingen makkelijk en snel te integreren zijn.
In mijn ervaring kan dit perfect in praktijk toegepast worden met gebruik van "gezond verstand", ervaren programmeurs die voor langere tijd blijven en een management dat hier ook in volgt.
Helaas ontbreekt 1 van deze schakels in vele bedrijven.

En dan nu LLMs, de ultieme patroonherkennende copy-paste machine. Als ik nog iets cynischer
zou zijn, zou ik me afvragen wat programmeurs nu weer zullen verzinnen om hun baantjes te kunnen behouden. Maar het is ook te zien als het antwoord op zestig, zeventig jaar aan pogingen om op een efficiënte manier software te ontwikkelen.

Ik ben het eigenlijk wel eens met @Glashelder : mensen hebben decennialang laten zien dat ze niet zo goed zijn in programmeren. En ik wil toevoegen, we zijn abominabel slecht in software engineering.

Het zullen net de goede programmeurs zijn die LLM's slimmer gaan maken ... en het zullen net de minder goede programmeurs zijn die er voor zorgen dat bedrijven LLM's blijven gebruiken ter verbetering van hun code.

Verder vermoed ik dat het een kwestie van tijd is voordat aansprakelijkheid en wetgeving ertoe leiden dat bedrijven het als risico gaan beschouwen om code te leveren / draaien die niet door een LLM is nagelopen op securityproblemen.

Wat dan zoals zo vaak uitdraait op een wassen neus.
Ik werk in een bedrijf waar "security en autorisatie" zwaar onder de loep ligt en alles dichtgezet wordt, o.a. o.b.v. audits van externe "security experts", penetration tests en ethische hackers. Blijkt dat wij als programmeurs (met interne functionele en technische kennis) toch telkens nieuwe gaten vinden of manieren waarop we dingen kunnen omzeilen (wat dan telkens ook mooi gemeld en opgelost wordt).
Dus een LLM zal vast een lijst van aanbevelingen en security/autorisatie issues kunnen checken (net zoals de scripts van audits nu ook al doen) en zeker tot verbeteringen leiden, de mens achter de knoppen heeft het voordeel van creativiteit die een LLM vooralsnog niet heeft.

[CVTTPD2DQ]

wiemelen schreef op woensdag 15 juli 2026 @ 10:44:
In mijn ogen moet een goede programmeur/oplossing niet zorgen voor de allerbeste/allersnelste/modernste oplossing. Alle programmeurs binnen 1 team/bedrijf moeten achter dezelfde visie staan die er voor zorgt dat er een goede, onderhoudbare (ook door juniors), gedocumenteerde, gebruiksvriendelijke oplossing komt, [...]

Dat is inderdaad een manier om software te ontwikkelen ... met mensen. In grotere bedrijven wordt het lastiger, omdat het moeilijker wordt om dezelfde 'visie' te delen met allerlei teams met verschillende taken en belangen, maar in dit scenario zijn de mensen de dragers van de kennis van en de visie op de systemen.

Heb je overwogen dat het veel voordelen voor een bedrijf heeft als je het zonder mensen kunt doen? Als de kennis over de systemen ergens opgeslagen ligt, en er ontwikkelcapaciteit is die je on-demand kunt aanschakelen (200 virtuele developers die 24 uur per dag doorploeteren ... of andersom, zes maanden lang in de pauzestand staan zonder dat het iets kost). Als kennis niet bij medewerkers ligt die zwanger of ziek kunnen worden, een wereldreis willen maken, of ergens anders een beter salaris krijgen?

wiemelen schreef op woensdag 15 juli 2026 @ 10:44:
Het zullen net de goede programmeurs zijn die LLM's slimmer gaan maken ... en het zullen net de minder goede programmeurs zijn die er voor zorgen dat bedrijven LLM's blijven gebruiken ter verbetering van hun code.

Leg eens uit hoe programmeurs die LLMs slimmer gaan maken. En welke programmeurs zijn dat, de programmeurs van Anthropic in Silicon Valley? Of onderbetaalde datamasseurs in Kenia? Welke rol hebben Nederlandse programmeurs daarin?

wiemelen schreef op woensdag 15 juli 2026 @ 10:44:
Wat dan zoals zo vaak uitdraait op een wassen neus.

Zeker. Maar dat maakt niet uit als die wassen neus verplicht wordt.

wiemelen schreef op woensdag 15 juli 2026 @ 10:44:
Dus een LLM zal vast een lijst van aanbevelingen en security/autorisatie issues kunnen checken (net zoals de scripts van audits nu ook al doen) en zeker tot verbeteringen leiden, de mens achter de knoppen heeft het voordeel van creativiteit die een LLM vooralsnog niet heeft.

Heb je later dan januari 2025 eens een coding tool gebruikt?

[Philip Ross]

CVTTPD2DQ schreef op woensdag 15 juli 2026 @ 18:31:
[...]


Dat is inderdaad een manier om software te ontwikkelen ... met mensen. In grotere bedrijven wordt het lastiger, omdat het moeilijker wordt om dezelfde 'visie' te delen met allerlei teams met verschillende taken en belangen,

Daar zijn zaken als programmeer afspraken voor. En standaarden.

maar in dit scenario zijn de mensen de dragers van de kennis van en de visie op de systemen.

Als de kennis over de systemen ergens opgeslagen ligt,

Als kennis niet bij medewerkers ligt die zwanger of ziek kunnen worden, een wereldreis willen maken, of ergens anders een beter salaris krijgen?

Die kennis is bij een degelijk bedrijf juist heel goed vastgelegd. Zeker bij grotere bedrijven moet dat wel.
Er bestaat ook zoiets als documentatie.

en er ontwikkelcapaciteit is die je on-demand kunt aanschakelen (200 virtuele developers die 24 uur per dag doorploeteren ... of andersom, zes maanden lang in de pauzestand staan zonder dat het iets kost).

Zolang het model consistent blijft, geen storing heeft, en niet afgesloten wordt door de regering van de VS.

[...]
Leg eens uit hoe programmeurs die LLMs slimmer gaan maken. En welke programmeurs zijn dat, de programmeurs van Anthropic in Silicon Valley? Of onderbetaalde datamasseurs in Kenia? Welke rol hebben Nederlandse programmeurs daarin?

Door de code die door LLMs gelezen en gestolen wordt te schrijven

[Nutral]

Ik denk dat omdat LLM's en AI gebruikt gaat worden om zoveel andere bedrijfstakken te automatiseren/vervangen van mensen er daardoor toch weer extra vraag gaat zijn naar software devs, door LLM's is software makkelijker te schrijven maar door LLM's word er ook meer software gebruikt.

Het is heel erg afhankelijk van de kwaliteit (en fouten) in hoe goed een LLM een business vraag/case kan omzetten naar code die goed werkt in dat domein.

[Kist]

Wel lachen. Allerlei grote bedrijven lopen er tegen aan dat agents een godsvermogen aan tokens kosten en dat daardoor het heel moeilijk zo niet onmogelijk is om ROI te zien.

Sterker nog die ROI wordt nu nog hoger geacht bij menselijke Devs.

Roept iemand hier non stop 24/7 honderden agents laten draaien.

Als je je bedrijf door het afvoerputje wil spoelen lijkt mij dat inderdaad een geweldig idee.

[ Voor 9% gewijzigd door Kist op 15-07-2026 19:17 ]

[Glashelder]

Er wordt ontzettend veel geëxperimenteerd en geprutst met AI. We staan aan het begin van de ontwikkelingen. Niet alleen de technische maar ook de menselijke kant: hoe gaan we ermee om?

Ik zie veel developers worstelen met AI. Vaak omdat ze eigenlijk niet eens goed weten wát ze nou willen bouwen maar dan wél van de AI goede resultaten verwachten.

[GoingDutch]

Hillie schreef op donderdag 11 juni 2026 @ 04:28:


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.

Een wat late reactie maar m.i. is dit niet wat er werkelijk speelt. Als je 1000 sollicitaties verstuurd en 0 reacties krijgt ligt dat aan de markt en niet aan een individuele ontwikkelaar. Er zijn in de VS honderdduizenden ontwikkelaars ontslagen bij Meta, Google, Microsoft, etc. De markt is overspoeld met goede kandidaten en dan is het zo goed als onmogelijk om iets te vinden.

In de VS is wie je kent belangrijker dan wat je kunt en connecties zijn belangrijker dan kennis en ervaring. (Ik heb zelf in Austin, TX gewoond en ben onder andere ook door de slechte markt weer in Europa terecht gekomen). Silicon Valley is ook niet beter, eerder nog slechter.

Dit komt niet door AI overigens maar m.i. door de wereldwijde economische neergang, de algemene onzekerheid en politieke instabiliteit en dat er te veel ontwikkelaars zijn aangenomen in de home-office hype tijdens Corona.

In Duitsland speelt nu precies hetzelfde door massa ontslagen in de auto industrie, heel veel embedded ontwikkelaars zijn op straat komen te staan die zoekende zijn terwijl de markt nog steeds verder krimpt.

[CVTTPD2DQ]

Philip Ross schreef op woensdag 15 juli 2026 @ 18:48:
Daar zijn zaken als programmeer afspraken voor. En standaarden.

En dan krijg je consistentie, maar geen gedeeld begrip, omdat menselijk begrip eenvoudigweg niet zo schaalbaar is. Maar deze discussie gaat niet over de vele manieren waarop ‘best practices’ in software engineering het paard achter de wagen spannen.

Philip Ross schreef op woensdag 15 juli 2026 @ 18:48:
Zolang het model consistent blijft, geen storing heeft, en niet afgesloten wordt door de regering van de VS.

[...]


Door de code die door LLMs gelezen en gestolen wordt te schrijven

Ik vermoed dat de cloud-providers beschikbaarheidsgaranties kunnen geven waar de meeste mensen een puntje aan kunnen zuigen.

En het morele verhaal van LLMs klopt van geen kanten, dat ben ik met je eens. Maar de wet- en werkgevers zullen altijd partij kiezen voor degenen die gouden bergen beloven. En je ziet hoe ook in Europa de wetgevende macht maar al te graag water bij de wijn doet om de AI-bedrijven ter wille te zijn. Zelfs de GDPR blijkt ineens zo heilig niet meer.

Als we het belangrijk vinden dat mensen betrokken blijven bij ontwikkelwerk, zullen we toch echt met iets beter moeten komen dan een beroep op rechtvaardigheidsgevoel. We moeten kunnen uitleggen waarom software geschreven door mensen béter is dan de code uit een LLM.

Kist schreef op woensdag 15 juli 2026 @ 19:13:
Roept iemand hier non stop 24/7 honderden agents laten draaien.

Als je je bedrijf door het afvoerputje wil spoelen lijkt mij dat inderdaad een geweldig idee.

Wat denk je dat honderden developers kosten?

[crisp]

CVTTPD2DQ schreef op woensdag 15 juli 2026 @ 22:52:
[...]
Wat denk je dat honderden developers kosten?

Dat zijn in ieder geval nog uitgaven binnen de eigen economie

[CVTTPD2DQ]

crisp schreef op woensdag 15 juli 2026 @ 23:29:
Dat zijn in ieder geval nog uitgaven binnen de eigen economie

En daar krijgen we misschien de wetgevers mee, het geld gaat naar de eigen inwoners, die zelf kennis opbouwen en hun loon weer laten circuleren in de eigen economie, in plaats van dat het de kennis en bottom line van Silicon Valley groter maakt.

-knip- ongepast

Maar de werkgevers gaan roepen dat we niet kunnen concurreren, alsof we dat uberhaupt al konden vóór de uitvinding van LLMs.

Ik sta zelf op het punt dat het heel verstandig is dat mensen (ook) zélf over dingen blijven nadenken. maar alle trends wijzen toch de andere richting op.

[ Voor 7% gewijzigd door ZieMaar! op 16-07-2026 17:49 ]

[Philip Ross]

CVTTPD2DQ schreef op woensdag 15 juli 2026 @ 22:52:
[...]


En dan krijg je consistentie, maar geen gedeeld begrip, omdat menselijk begrip eenvoudigweg niet zo schaalbaar is.

Begrip heeft een LLM sowieso niet.
Begrip is ook niet nodig als je goede documentatie hebt, dan zoek je gewoon op wat je niet direct weet.

[...]
Ik vermoed dat de cloud-providers beschikbaarheidsgaranties kunnen geven waar de meeste mensen een puntje aan kunnen zuigen.

De cloud providers wel. Maar een groot bedrijf heeft ook een vrij hoge uptime van arbeidskrachten.
De LLM providers daarentegen zijn minder betrouwbaar.

En dan heb ik het nog niet over de inconsistentie van modellen. Dat nieuwe modellen die steeds komen weer net even anders (en soms slechter) werken.

Bovendien draaien alle LLM bedrijven nog miljarden per jaar verlies.
Dus de prijs van die modellen gaat nog een veelvoud omhoog.

[GoingDutch]

-knip- dit is wel erg generaliserend

De huidige LLMs zijn nu al veel beter dan de gemiddelde ‘ontwikkelaar’. Daarnaast hoeft een AI geen salaris, werkt rustig 24/7 door, is nooit vervelend, geeft meteen z’n ongelijk toe, staat open voor kritiek, zeurt nooit en heeft de bijzondere eigenschap wel in staat te zijn om documentatie en tests te kunnen schrijven.

Dat er dingen fout gaan met context, agents, hallucinaties, etc komt omdat de verkeerde modellen of prompts worden gebruikt. Mijn achtergrond is Deep Learning(CNNs) en het heeft mij 6 tot 12 maanden gekost om bij te komen met alle recente ontwikkelingen op het gebied van LLMs, VLMs en VLAs.

[ Voor 206% gewijzigd door ZieMaar! op 16-07-2026 17:55 ]

[wiemelen]

-knip- niet zo generaliseren aub.

De huidige LLMs zijn nu al veel beter dan de gemiddelde ‘ontwikkelaar’. Daarnaast hoeft een AI geen salaris, werkt rustig 24/7 door, is nooit vervelend, geeft meteen z’n ongelijk toe, staat open voor kritiek, zeurt nooit en heeft de bijzondere eigenschap wel in staat te zijn om documentatie en tests te kunnen schrijven.

Even uit nieuwsgierigheid, als developer gebruik ik AI tools meermaals per dag.
Maar uiteindelijk werk ik ook maar 8 uur per dag, waarvan een deel van de dag ook nog analyse, beheer, testen, architectuur inhoudt. Hoe zie jij AI 24/7 doorwerken? Een argument dat ik wel vaker hoor, maar niet echt van toepassing lijkt in software ontwikkeling. Kan wél van toepassing zijn in andere toepassingen.

[ Voor 43% gewijzigd door ZieMaar! op 16-07-2026 17:53 ]

[Philip Ross]

-Knip- reactie op verwijderde tekst

[ Voor 96% gewijzigd door ZieMaar! op 16-07-2026 17:53 ]

[Glashelder]

-Knip- reactie op verwijderde tekst

[ Voor 106% gewijzigd door ZieMaar! op 16-07-2026 17:54 ]

[wiemelen]

-Knip- reactie op verwijderd bericht

[ Voor 107% gewijzigd door ZieMaar! op 16-07-2026 17:55 ]

[Lethalis]

GoingDutch schreef op donderdag 16 juli 2026 @ 09:00:
[...]

De huidige LLMs zijn nu al veel beter dan de gemiddelde ‘ontwikkelaar’. Daarnaast hoeft een AI geen salaris, werkt rustig 24/7 door, is nooit vervelend, geeft meteen z’n ongelijk toe, staat open voor kritiek, zeurt nooit en heeft de bijzondere eigenschap wel in staat te zijn om documentatie en tests te kunnen schrijven.

Dat er dingen fout gaan met context, agents, hallucinaties, etc komt omdat de verkeerde modellen of prompts worden gebruikt. Mijn achtergrond is Deep Learning(CNNs) en het heeft mij 6 tot 12 maanden gekost om bij te komen met alle recente ontwikkelingen op het gebied van LLMs, VLMs en VLAs.

Tenzij het je lukt om een LLM lokaal te draaien die enorm veel parameters aankan, zul je als bedrijf toch altijd een andere partij moeten betalen voor de AI tokens die worden gebruikt. En de prijs daarvan zal nog even doorstijgen, want al die datacenters zijn niet gratis.

En je hebt nog altijd iemand nodig die met de AI praat, want de opdrachtgever is vaak amper in staat om te formuleren wat hij / zij nou eigenlijk wil.

Is ook beetje het verschil tussen een ontwikkelaar (bedenkt oplossing) en een programmeur (doet alleen implementatie). Daarom hebben ook vooral juniors het moeilijk, want die kregen toch vooral de simpelere taken die je nu aan een AI agent kunt geven.

De lastigere dingen - niet zozeer qua techniek, maar wel qua het begrijpen van het business domein en dit vertalen naar een oplossing - zijn veel moeilijker te automatiseren.

Ik moet dan altijd aan een inmiddels gepensioneerde collega van mij denken. Die was ook eigenlijk meer consultant geworden dan ontwikkelaar. Toen ik nog wat jonger was, had ik altijd zoiets van "die collega is klaar als programmeur, laat hem alsjeblieft beschrijven wat er moet gebeuren en dan bouwen wij het wel".

Nou die meneer heeft het meeste baat bij AI. Want hij begrijpt de klant, weet wat hij wil en dan hoeft hij het alleen nog uit te leggen aan een AI.

Die mensen blijven werk houden.

De rest zal het lastiger krijgen, maar het is niet alsof we allemaal gedoemd zijn ofzo. Het is alleen dat je software ontwikkeling moet zien als iets groters dan alleen implementatie. Je lost een probleem op. Hoe je dat doet, doet er eigenlijk niet toe. Het kan immers ook zijn dat de oplossing simpelweg het gebruiken van een reeds bestaande tool is. Of tegenwoordig omdat je een AI een tool vraagt te maken. Maar je bent nog steeds nodig, omdat de klant het zelf niet gaat doen.

Wel kan ik mij voorstellen dat veel mensen zullen afvallen. En dat is ook logisch. Al die jaren dat er enorme tekorten aan ontwikkelaars waren, kwam inderdaad iedereen binnen. Dus eigenlijk is dit gewoon een kleine reset, waardoor de harde kern weer overblijft, net zoals vroeger.

De rest kan weer terug iets anders doen

[CVTTPD2DQ]

Lethalis schreef op donderdag 16 juli 2026 @ 16:08:
Tenzij het je lukt om een LLM lokaal te draaien die enorm veel parameters aankan, zul je als bedrijf toch altijd een andere partij moeten betalen voor de AI tokens die worden gebruikt. En de prijs daarvan zal nog even doorstijgen, want al die datacenters zijn niet gratis.

Er spelen twee zaken: op de tokens zelf (dwz. het 'denkwerk' door de AI) maken de AI-bedrijven vette winstmarges, die soms op wel 90% worden geschat.

Neem je de investeringen in steeds grotere nieuwe modellen en datacenters erbij, is het geheel inderdaad verlieslatend. De beurskoersen zijn te hoog, er zullen ongetwijfeld bedrijven failliet gaan, maar daardoor verdwijnt de technologie niet.

De mensen die roepen dat dit niet eeuwig door kan gaan hebben gelijk. Op een gegeven moment moeten de investeringen terugvallen naar een niveau dat uit de lopende inkomsten kan worden betaald.

En dan kan het nog twee kanten op: het trainen van nieuwe modellen is noodzakelijk voor de AI-bedrijven om 'bij te blijven', en bij een volhoudbaar investeringsniveau is het tempo van training niet voldoende om de modellen bruikbaar te houden. In dat geval ontstaat er een industrie waarin LLMs alleen "houdbare" verouderde kennis hebben, maar waarin ze wellicht nog wel nuttig inzetbaar zijn voor deeltaken.

Of het is mogelijk om (met een iets lager ambitieniveau) de modellen courant te houden.

In beide scenario's is het aannemelijk dat de prijs van tokens gaat dalen.

[Wozmro]

De huidige rekenkracht in onze modale smartphones werd vroeger ook als totaal onrealistisch weggezet. Kan niet, nooit nie.

En ik herinner mij artikels met de als titel: 'binnen 10 jaar verbruikt het internet evenveel energie als de rest van de wereld, zo kan het niet verder'.

Net omdat AI momenteel zoveel geld en energie kost wordt er naarstig gezocht naar oplossingen want meer winst.

Ok, Jevons-paradox speelt een rol maar ook de wet van Wright en de wet van massa is kassa.

[CVTTPD2DQ]

Wozmro schreef op vrijdag 17 juli 2026 @ 08:22:
Net omdat AI momenteel zoveel geld en energie kost wordt er naarstig gezocht naar oplossingen want meer winst.

Zelfs zonder technologische sprongen (efficiëntere modellen / hardware, en daar is nog genoeg winst te behalen) is het dus rendabel te rekenen.

Mensen die denken dat LLMs niet met hun baan zullen concurreren "omdat het allemaal een bubbel is" hebben dus niet zo'n overtuigend verhaal. In ieder geval niet op de lange termijn.

[Philip Ross]

Wozmro schreef op vrijdag 17 juli 2026 @ 08:22:
De huidige rekenkracht in onze modale smartphones werd vroeger ook als totaal onrealistisch weggezet. Kan niet, nooit nie.

Volgens mij was de wet van Moore er juist al decennia duidelijk over dat dat absoluut wel kon en ook zou gebeuren.

CVTTPD2DQ schreef op vrijdag 17 juli 2026 @ 08:27:

Mensen die denken dat LLMs niet met hun baan zullen concurreren "omdat het allemaal een bubbel is" hebben dus niet zo'n overtuigend verhaal. In ieder geval niet op de lange termijn.

Mensen denken dat niet "omdat het een bubbel" is maar omdat ze realistisch naar de mogelijkheden kijken.
Ik probeer met regelmaat gebruik te maken van AI maar zoals al eerder gemeld is er gewoon nog niets voor ons vakgebied dat ook maar enigszins in de buurt komt van een normale programmeur.

De bubbel gaat over de beurs waardering en de hoeveelheid AI die op de vreemdste plekken in producten gestopt wordt.

Ja, er is zeker toekomst perspectief voor AI. En het zal een goede ondersteuning zijn in veel vakgebieden en veel eenvoudige rollen vervangen. Maar het idee dat het uiteindelijk elk (behalve fysiek) vakgebied overhoop gaat halen is met de huidige manier van modellen trainen nog ver gezocht.

[Wozmro]

En ook de (daarom niet onterechte) uitgebreid beschreven tegenreacties bezorgen de ontwikkelaars van AI ook heel veel informatie om hun product te optimaliseren.

Iedere fout, onbestaande quote, rare reactie,... van een AI-bot daar wordt heel uitgebreid en tot in het detail online over gedebatteerd.

Moest het allemaal maar een bubbel zijn dan zouden al die critici daar gewoon geen tijd en moeite in steken. Het moet toch zijn dat er iets fundamenteels toch aangevoeld wordt?

Waarmee ik zeker niet wil zeggen dat kritiek onterecht is.

[Corrit]

De bubbel is naar mijn mening vooral financieel, niet technologisch. Uiteindelijk moet er idioot veel geld binnenkomen om de waardes waar de AI bedrijven momenteel op worden geschat te kunnen rechtvaardigen. Bij sommigen zal dat misschien lukken, maar bij veel ook niet. Er is toch ergens een limiet aan wat bedrijven willen uitgeven aan AI, en ik geloof er persoonlijk niets van dat het op lange termijn "normaal" wordt geacht om een paar honderd euro per medewerker per maand aan AI kosten te gaan aftikken. Dan gaan bedrijven echt wel zelf 'rondshoppen' om goedkopere opties te vinden.

Maar ook als alle AI bedrijven morgen in elkaar zouden klappen dan blijft de techniek bestaan, en die kan in veel gevallen nu al prima concurreren met het werk dat een mens kan leveren (administratief, programmeren, etc). Wat er ook gebeurt, daar moeten we ons individueel en als samenleving op aanpassen.

[Philip Ross]

Wozmro schreef op vrijdag 17 juli 2026 @ 08:47:
Moest het allemaal maar een bubbel zijn dan zouden al die critici daar gewoon geen tijd en moeite in steken. Het moet toch zijn dat er iets fundamenteels toch aangevoeld wordt?

Is dat niet gewoon omdat veel mensen moe worden van hoe hard AI gepushed wordt en hoe dood je ermee gegooid wordt op social media?
Dan krijg je logischerwijs een tegenreactie.

[Corrit]

CVTTPD2DQ schreef op vrijdag 17 juli 2026 @ 07:58:
Er spelen twee zaken: op de tokens zelf (dwz. het 'denkwerk' door de AI) maken de AI-bedrijven vette winstmarges, die soms op wel 90% worden geschat.

Neem je de investeringen in steeds grotere nieuwe modellen en datacenters erbij, is het geheel inderdaad verlieslatend. De beurskoersen zijn te hoog, er zullen ongetwijfeld bedrijven failliet gaan, maar daardoor verdwijnt de technologie niet.

Deze redenatie snap ik niet. Die omzet op tokens kun je m.i. niet los zien van alle investeringen die deze bedrijven moeten doen. Zonder concurrerend model (met bijbehorende ontwikkelkosten) dat op courante (dure) hardware moet draaien heb je geen omzet. De operationele kosten zijn gigantisch en vziw is nog geen enkele van de grote AI bedrijven in staat om daadwerkelijk winst te maken.

[Wozmro]

Je wordt met vanalles en nog wat doodgegooid op sociale media. Reageren zorgt net voor een versterkend effect.

En wat het financiële betreft: het zou best kunnen dat er een aantal bedrijven failliet gaan, dat investeerders geld kwijt zijn. Is dat zo erg of uitzonderlijk in het kapitalistisch systeem?

Ja, dan kan er een beurscorrectie/crash volgen, maar zou dat zo erg zijn voor de gewone mens in de straat, met een gewone job?

[Philip Ross]

Wozmro schreef op vrijdag 17 juli 2026 @ 09:04:
Je wordt met vanalles en nog wat doodgegooid op sociale media. Reageren zorgt net voor een versterkend effect.

Ik zou verwachten dat we hier op Tweakers wat inhoudelijker kunnen praten.
Op social media reageer ik inderdaad niet, hier wel.

Daarnaast is het niet alleen op social media maar ook op de werkvloer.

Directies die even besluiten dat je vanaf morgen alles in 50% van de tijd moet doen zonder onderzocht te hebben of AI wel geschikt is voor die rol. "Want bij ons in de directie konden we makkelijk de helft van ons werk door AI laten doen dus engineers moeten dat ook wel kunnen."
Alsof een secretaresse die notulen maakt laten vervangen door AI hetzelfde is als iemand die technische ontwerpen en tekeningen maakt.

[ Voor 41% gewijzigd door Philip Ross op 17-07-2026 09:53 ]

[Wozmro]

Gebeurd dat bij jullie op de werkvloer werkelijk op die manier?

[Philip Ross]

Wozmro schreef op vrijdag 17 juli 2026 @ 10:08:
Gebeurd dat bij jullie op de werkvloer werkelijk op die manier?

Bij mijn vorige werkgever wel ja.
Van de een op de andere dag mocht het project geen regel meer zelf programmeren en was de verwachting dat alles 50% sneller zou zijn.

Een van de redenen dat ik opgestapt ben daar. Zonder overleg met het team overigens over wat de mogelijkheden waren.

[Wozmro]

Amai, dat zegt ook iets over de communicatieve vaardigheden van de leidinggevenden.

[Philip Ross]

Wozmro schreef op vrijdag 17 juli 2026 @ 10:22:
Amai, dat zegt ook iets over de communicatieve vaardigheden van de leidinggevenden.

Zeker, veel bezwaar tegen AI gaat ook niet over de AI zelf maar over de manier waarop het vaak opgedrongen wordt.

[njitter]

AI is prima zolang er maar iemand aanwezig is om exact te vertellen wat gewenste output is.

Zelf gebruik ik CoPilot regelmatig om een query te optimaliseren. Ik ken genoeg SQL om data uit het systeem te halen. Maar als er allerlei logica nodig is met verschillende joins dan is het handig om dit door ai te laten verzinnen. De output is ook niet dusdanog lang dat het lastig te controleren is.

Maar als je een complete applicatie laat vibecoden inclusief UI en niemand heeft een idee wat er nu eigenlijk gebouwd is en hoe het werkt dan ben je verkeerd bezig. ZIe het als een tool en niet als een doel op zich.

[t_captain]

GenAI en agentic AI is gewoon een grote stap in developer productivity.

Kijk naar de afgelopen 60 jaar aan software ontwikkeling. Van assembly naar C en Fortran. De opkomst van C++ met betere mogelijkhedne tot code reuse en organisatie in grotere projecten. De opkomst van standaard libraries. De opkomst van IDE's met gelijdelijk steeds meer slimheid om sneller en fijner te kunnen coderen. De shift naar 3G talen met managed runtimes. De boom in frameworks. In het verlengde van die frameworks, productization als PaaS diensten door cloud providerd. En vergeet niet de websites als Github en Stackoverflow om je te helpen met je werk.

Al die ontwikkelingen hebben bijgedragen aan developer productivity: een gestage toename van hoeveel complexiteit je per werkdag kunt bouwen.

En de markt heeft die productiviteit tot nu toe steeds opgenomen. Software wordt steeds betaalbaarder (gemeten in inflatiegecorrigeerde dollars per complexiteit). We bouwen steeds meer systemen en steeds complexere systemen.

30 jaar geleden was een site als Hotmail een hoogvliegende start-up die voor veel geld werd overgenomen door Microsoft. Tegenwoordig kun je het in een manweek bouwen, als je leunt op alle beschikbare tools, LLM's, frameworks en clouddiensten.

De vraag nu: kan de markt ook een plotselinge grote stap in productiviteit opnemen? Of geeft het een echte shake-out? Time will tell. De zorg speelt in bredere context al langer: gaat de productiviteitswinst door technologische vooruitgang leiden naar een nieuwe boost aan welvaart of aan een structurele werkloosheid?

Dit is dus niet anders dan wat technologie maatschappijbreed doet. Landbouwmechanisatie maakte een eeuw geleden heel veel boerenknechten werkloos. Die vonden uiteindelijk ander werk in een groeiende industriele sector, die bijdroeg aan een forse toename van de levensstandaard. Tot nu toe is dat altijd de uitkomst geweest, maar er zijn ook stemmen die zeggen dat het huidige tempo niet kan worden geabsorbeerd.

De ironie is dat ICT de afgelopen 30 jaar juist de driver was van een bredere maatschappelijke modernisering en nu is begonnen om zichzelf in de staart te bijten.

[wiemelen]

Wozmro schreef op vrijdag 17 juli 2026 @ 08:22:
Net omdat AI momenteel zoveel geld en energie kost wordt er naarstig gezocht naar oplossingen want meer winst.

Lijkt me ook wel nodig als je het energieverbruik van datacenters ziet.
Zie ook https://tweakers.net/nieu...e-nederlandse-stroom.html.
Ben dan ook benieuwd hoeveel energie alle datacenters in Nederland tesamen gebruiken, rekening houdend dat er nog meer data centers gepland staan.

Dus datacenters die minder energie verbruiken lijkt wel streefdoel ja.

[njitter]

wiemelen schreef op vrijdag 17 juli 2026 @ 11:21:
[...]

Dus datacenters die minder energie verbruiken lijkt wel streefdoel ja.

Niet alleen minder stroomverbruik maar ook gewoon minder datacenters erbij. Zo heeft de gemeente Amsterdam vorig jaar de bouw van nieuwe datacenters voor een periode van tien jaar verboden.

https://www.bnr.nl/nieuws/tech-innovatie/10606372/meeste-datacenters-in-nederland-maken-stroomverbruik-niet-openbaar

[PWSteal]

t_captain schreef op vrijdag 17 juli 2026 @ 11:11:
GenAI en agentic AI is gewoon een grote stap in developer productivity.

Kijk naar de afgelopen 60 jaar aan software ontwikkeling. Van assembly naar C en Fortran. De opkomst van C++ met betere mogelijkhedne tot code reuse en organisatie in grotere projecten. De opkomst van standaard libraries. De opkomst van IDE's met gelijdelijk steeds meer slimheid om sneller en fijner te kunnen coderen. De shift naar 3G talen met managed runtimes. De boom in frameworks. In het verlengde van die frameworks, productization als PaaS diensten door cloud providerd. En vergeet niet de websites als Github en Stackoverflow om je te helpen met je werk.

Al die ontwikkelingen hebben bijgedragen aan developer productivity: een gestage toename van hoeveel complexiteit je per werkdag kunt bouwen.

En de markt heeft die productiviteit tot nu toe steeds opgenomen. Software wordt steeds betaalbaarder (gemeten in inflatiegecorrigeerde dollars per complexiteit). We bouwen steeds meer systemen en steeds complexere systemen.

30 jaar geleden was een site als Hotmail een hoogvliegende start-up die voor veel geld werd overgenomen door Microsoft. Tegenwoordig kun je het in een manweek bouwen, als je leunt op alle beschikbare tools, LLM's, frameworks en clouddiensten.

De vraag nu: kan de markt ook een plotselinge grote stap in productiviteit opnemen? Of geeft het een echte shake-out? Time will tell. De zorg speelt in bredere context al langer: gaat de productiviteitswinst door technologische vooruitgang leiden naar een nieuwe boost aan welvaart of aan een structurele werkloosheid?

Dit is dus niet anders dan wat technologie maatschappijbreed doet. Landbouwmechanisatie maakte een eeuw geleden heel veel boerenknechten werkloos. Die vonden uiteindelijk ander werk in een groeiende industriele sector, die bijdroeg aan een forse toename van de levensstandaard. Tot nu toe is dat altijd de uitkomst geweest, maar er zijn ook stemmen die zeggen dat het huidige tempo niet kan worden geabsorbeerd.

De ironie is dat ICT de afgelopen 30 jaar juist de driver was van een bredere maatschappelijke modernisering en nu is begonnen om zichzelf in de staart te bijten.

Ik denk dat de vraag hoofdzakelijk is of de toegenomen productiviteit daadwerkelijk vertaald naar een toename in levensstandaard. Waar zijn de nuttige producten die door deze toegenomen productiviteit zijn onstaan, ik zie ze namelijk niet?

[Wozmro]

Veel zaken zijn ook niet zichtbaar als je er niet rechtstreeks mee te maken hebt.

Medische toepassingen, bedrijfsprocessen, weersvoorspellingen, landbouw,...

Negatieve gebeurtenissen die niet voorvallen zorgen ook voor een stijging van de welvaart.

Een vermeden overstroming door betere weersvoorspelling, wat minder tijd in de file staan,...

[Gr4mpyC3t]

PWSteal schreef op zondag 19 juli 2026 @ 15:02:
[...]

Ik denk dat de vraag hoofdzakelijk is of de toegenomen productiviteit daadwerkelijk vertaald naar een toename in levensstandaard. Waar zijn de nuttige producten die door deze toegenomen productiviteit zijn onstaan, ik zie ze namelijk niet?

Nou ja, ik hoop vooral dat AI straks een bijdrage kan leveren aan een hogere kwaliteit van geleverde (digitale) diensten.

Bijvoorbeeld, er zijn al experimentele projecten in de zorg waar AI kijkt naar röntgenfoto’s om in een vrij vroeg stadium afwijkingen in het lichaam te vinden. Dat levert nu al hoopvolle resultaten op.

[PWSteal]

Gr4mpyC3t schreef op zondag 19 juli 2026 @ 15:36:
[...]

Nou ja, ik hoop vooral dat AI straks een bijdrage kan leveren aan een hogere kwaliteit van geleverde (digitale) diensten.

Bijvoorbeeld, er zijn al experimentele projecten in de zorg waar AI kijkt naar röntgenfoto’s om in een vrij vroeg stadium afwijkingen in het lichaam te vinden. Dat levert nu al hoopvolle resultaten op.

Als ik 1 ding zie gebeuren is het wel het tegenovergstelde van hogere kwaliteit diensten. Code reviewers, testers en QA worden volledig overspoeld door ontwikkelaars die nu aan de lopende band PRs van 5000+ regels maken. De volledige kwaliteitscontrole word hierdoor omzeild, geen enkele reviewer gaat dit namelijk serieus bekijken dan wel begrijpen wat er gedaan is.

Dan mag je geluk hebben met reviewers die de boel blokkeren, maar in praktijk word het rubber stampen. Inmiddels genoeg ervaring mee: ontwikkelaar denk na een dag klaar te zijn; levert 5000 regels op wat er 1000 hadden kunnen zijn. Niemand bekijkt de code dus ook niemand snapt hoe het werkt. Spendeert vervolgens 2 weken aan allerlei vage fixes. Deployed naar productie waar het nagenoeg onbruikbaar blijkt te zijn en vereist dus nog een week aan fixes. Op dat moment raken er meerdere mensen bij betrokken en de tijdsinvestering explodeert, die komen er dan achter dat het ook nog eens vol zit met architecturele problemen. Dan word de conclusie: bouw maar helemaal opnieuw want dit gaat nooit werken.

Ben je 4 weken aan het rotzooien, allerlei mensen tijd verspilt en een brak product aan klanten opgeleverd. Hetzelfde had iemand met een week handmatig programmeren ook kunnen opleveren, alleen dan had je niet 3 weken lang aan puin ruimen erachteraan gehad.

[R_Zwart]

PWSteal schreef op zondag 19 juli 2026 @ 16:15:
[...]

Als ik 1 ding zie gebeuren is het wel het tegenovergstelde van hogere kwaliteit diensten. Code reviewers, testers en QA worden volledig overspoeld door ontwikkelaars die nu aan de lopende band PRs van 5000+ regels maken. De volledige kwaliteitscontrole word hierdoor omzeild, geen enkele reviewer gaat dit namelijk serieus bekijken dan wel begrijpen wat er gedaan is.

Dan mag je geluk hebben met reviewers die de boel blokkeren, maar in praktijk word het rubber stampen. Inmiddels genoeg ervaring mee: ontwikkelaar denk na een dag klaar te zijn; levert 5000 regels op wat er 1000 hadden kunnen zijn. Niemand bekijkt de code dus ook niemand snapt hoe het werkt. Spendeert vervolgens 2 weken aan allerlei vage fixes. Deployed naar productie waar het nagenoeg onbruikbaar blijkt te zijn en vereist dus nog een week aan fixes. Op dat moment raken er meerdere mensen bij betrokken en de tijdsinvestering explodeert, die komen er dan achter dat het ook nog eens vol zit met architecturele problemen. Dan word de conclusie: bouw maar helemaal opnieuw want dit gaat nooit werken.

Ben je 4 weken aan het rotzooien, allerlei mensen tijd verspilt en een brak product aan klanten opgeleverd. Hetzelfde had iemand met een week handmatig programmeren ook kunnen opleveren, alleen dan had je niet 3 weken lang aan puin ruimen erachteraan gehad.

Dit komt deels omdat deze manier van softwareontwikkeling of relatief nieuw is. De meesten zullen de negatieve kanten herkennen, en dat zal ervoor zorgen dat tools worden aangepast in de komende jaren waardoor het resultaat beter wordt. Ook de hoge prijs van een geheugen zal voor extra eisen zorgen. Tevens moet je ook naar andere manieren van testen en QA moeten gaan kijken. Er mee stoppen omdat het nu niet perfect is, is het laatste wat je moet doen.

[Stukfruit]

PWSteal schreef op zondag 19 juli 2026 @ 16:15:
[...]

Als ik 1 ding zie gebeuren is het wel het tegenovergstelde van hogere kwaliteit diensten. Code reviewers, testers en QA worden volledig overspoeld door ontwikkelaars die nu aan de lopende band PRs van 5000+ regels maken. De volledige kwaliteitscontrole word hierdoor omzeild, geen enkele reviewer gaat dit namelijk serieus bekijken dan wel begrijpen wat er gedaan is.

Dan mag je geluk hebben met reviewers die de boel blokkeren, maar in praktijk word het rubber stampen. Inmiddels genoeg ervaring mee: ontwikkelaar denk na een dag klaar te zijn; levert 5000 regels op wat er 1000 hadden kunnen zijn. Niemand bekijkt de code dus ook niemand snapt hoe het werkt. Spendeert vervolgens 2 weken aan allerlei vage fixes. Deployed naar productie waar het nagenoeg onbruikbaar blijkt te zijn en vereist dus nog een week aan fixes. Op dat moment raken er meerdere mensen bij betrokken en de tijdsinvestering explodeert, die komen er dan achter dat het ook nog eens vol zit met architecturele problemen. Dan word de conclusie: bouw maar helemaal opnieuw want dit gaat nooit werken.

Ben je 4 weken aan het rotzooien, allerlei mensen tijd verspilt en een brak product aan klanten opgeleverd. Hetzelfde had iemand met een week handmatig programmeren ook kunnen opleveren, alleen dan had je niet 3 weken lang aan puin ruimen erachteraan gehad.

Is de kwaliteitscontrole in kwestie deterministisch (de nodige SAST-tools, volledige SonarQube zonder taalmodellen, enz) of gebaseerd op agents? Want dit klinkt alsof je niet beide kanten automatiseert.

Wat is er mis met reviewen met hulp van een agent die alles wat langer dan 1000 regels is helpt analyseren of nog beter: wegknikkert?

Als iemand bijvoorbeeld een "godfile" indient dan kan dat automatisch worden afgekeurd. Geldt ook voor zaken waarin de junior vrolijk dingen heeft zitten "vibecoduplicaten" tot aan de problemen met architectuur aan toe. Hoef je niet eens een hele pipeline voor op te zetten. Handmatig een setje prompts en skills bijhouden waarvan de resultaten afgedwongen kunnen worden doet een hoop goeds.

Setje goede architectuur- en reviewskills erop zetten icm systemprompt voor agent die echt heel graag door wil gaan en alles wat fout lijkt te zijn wil afkeuren. Eerst laten pruttelen voordat je er zelf ook maar een seconde naar kijkt. Niet goed? Direct terug naar indiener sturen om het werk te verplaatsen naar de persoon die nog moet leren of te lui is geweest.

Het pakt niet alles op omdat begrip van wat je nodig hebt op hoger niveau totaal ontbreekt, maar je kan wel gebrek aan begrip bij de indiener aanpakken en in de eerste laag alle vibecode-onzin er al grotendeels uithalen zodat je zelf een blik met intelligentie kan opentrekken voor de rest op basis van code die een stuk minder overdreven in elkaar steekt.

Pak je dat als bedrijf niet goed op, dan ga je inderdaad vaker slechtere producten leveren dan andere partijen omdat je niet (genoeg) aan automatisering doet en werk je jezelf uit de markt.

[t_captain]

PWSteal schreef op zondag 19 juli 2026 @ 15:02:
[...]

Ik denk dat de vraag hoofdzakelijk is of de toegenomen productiviteit daadwerkelijk vertaald naar een toename in levensstandaard. Waar zijn de nuttige producten die door deze toegenomen productiviteit zijn onstaan, ik zie ze namelijk niet?

Het hoeft niet altijd een nieuw product of nieuwe dienst te zijn. Het efficienter maken van bestaand werk is ook welvaartsverhogend. De nieuwe producten en diensten ontstaan dan elders. Zoals de landbouwmechanisatie de boerendochters van de boerderijen naar de Philipsfabrieken migreerde, waar ze transistorradio's gingen bouwen.


Een grote vraag is wel in deze tijd: in welke mate is arbeid nog de bottleneck van welvaartscreatie? Cleantech en greentech lossen andere efficiency-bottlenecks op dan AI en die kunnen wel eens relevanter blijken.

[Wozmro]

Dan komt de econoom Daniel Susskind in beeld met zijn concept van het conditional basic income.

Geen gratis geld maar een basisinkomen in ruil voor bijdragen aan de samenleving (niet economische taken). Bijvoorbeeld twee dagen per week mantelzorg, vrijwilligerswerk, gemeenschapstaken,...

En de rest van je tijd doe je hobby zoals bijvoorbeeld manueel programmeren, kunst, allerhande opleidingen. Niet omwille van economische perspectieven maar voor het leren om het leren zelf.

Dat wordt wel nogal een culturele en psychologische omslag waarbij mensen (de jeugd) stapje voor stapje (zonder veel gerucht aan te geven) in die richting evoluren en de politiek daar dan reactief zal op reageren met onder andere hogere belastingen op (AI-) bedrijven.

[pieter.a]

PWSteal schreef op zondag 19 juli 2026 @ 16:15:
[...]

Als ik 1 ding zie gebeuren is het wel het tegenovergstelde van hogere kwaliteit diensten. Code reviewers, testers en QA worden volledig overspoeld door ontwikkelaars die nu aan de lopende band PRs van 5000+ regels maken. De volledige kwaliteitscontrole word hierdoor omzeild, geen enkele reviewer gaat dit namelijk serieus bekijken dan wel begrijpen wat er gedaan is.

Ja, dat kan en dat gebeurt al.

In mijn team werken we sinds vorig jaar met een outsourcing partij. Uit de eerste code reviews kwam zoveel feedback dat we een checklist hebben gemaakt met conventies en best practices. Ik kijk er naar uit om AI de code te laten reviewen aan de hand van de checklist voordat er überhaupt een PR wordt gemaakt.

[CVTTPD2DQ]

Wozmro schreef op maandag 20 juli 2026 @ 12:07:
Geen gratis geld maar een basisinkomen in ruil voor bijdragen aan de samenleving (niet economische taken). Bijvoorbeeld twee dagen per week mantelzorg, vrijwilligerswerk, gemeenschapstaken,...

En de rest van je tijd doe je hobby zoals bijvoorbeeld manueel programmeren, kunst, allerhande opleidingen. Niet omwille van economische perspectieven maar voor het leren om het leren zelf.

Wederom, wie heeft het geld om dit te betalen? Want als jouw baan straks door een LLM ergens in een datacentrum in Texas gedaan wordt door een LLM uit Californië, komt ook de meerwaarde die jouw baan creëert grotendeels in de VS terecht.

[CVTTPD2DQ]

t_captain schreef op maandag 20 juli 2026 @ 11:38:
Het hoeft niet altijd een nieuw product of nieuwe dienst te zijn. Het efficienter maken van bestaand werk is ook welvaartsverhogend. De nieuwe producten en diensten ontstaan dan elders. Zoals de landbouwmechanisatie de boerendochters van de boerderijen naar de Philipsfabrieken migreerde, waar ze transistorradio's gingen bouwen.

Je slaat voor het gemak wel de eeuw van bittere armoede over, waarin ontheemde boeren (die trouwens niet werden verdreven door landbouwmechanisatie, maar vaak door onteigening. In Europa vond mechanisatie van de landbouw pas in de 20e eeuw echt plaats) in vuil en honger leefden, en hun levensstandaard alleen maar achteruit zagen hollen. "Uiteindelijk komt het allemaal goed" is dan niet zo troostend.

[ Voor 4% gewijzigd door CVTTPD2DQ op 21-07-2026 08:09 ]

[t_captain]

De grote impact van landbouwmechanisatie zat in de 1e helft van de 20e eeuw, met name het interbellum. Er is wel een economische crisis geweest in het begin van de jaren '30, maar een eeuw van bittere armoede is anders. Sterker nog, industrialisatie was 1 van de grote drivers van de welvaartsboom in de periode 1945-2000.

[diondokter]

CVTTPD2DQ schreef op dinsdag 21 juli 2026 @ 07:41:
[...]


Wederom, wie heeft het geld om dit te betalen? Want als jouw baan straks door een LLM ergens in een datacentrum in Texas gedaan wordt door een LLM uit Californië, komt ook de meerwaarde die jouw baan creëert grotendeels in de VS terecht.

Draai hem om. Wie kan voor LLMs betalen als je geen klanten hebt die je producten kunnen betalen?

[Philip Ross]

t_captain schreef op dinsdag 21 juli 2026 @ 08:43:
De grote impact van landbouwmechanisatie zat in de 1e helft van de 20e eeuw, met name het interbellum. Er is wel een economische crisis geweest in het begin van de jaren '30, maar een eeuw van bittere armoede is anders. Sterker nog, industrialisatie was 1 van de grote drivers van de welvaartsboom in de periode 1945-2000.

Elke industriële revolutie veroorzaakt eerst enorme armoede om na een gevecht van vakbonden tegen de rijke elite weer in balans te komen en de welvaart van de grote groep te verbeteren.

De vraag is of dat gevecht tegen de tech bedrijven in de huidige tijd nog wel te winnen valt.

[CVTTPD2DQ]

t_captain schreef op dinsdag 21 juli 2026 @ 08:43:
De grote impact van landbouwmechanisatie zat in de 1e helft van de 20e eeuw, met name het interbellum. Er is wel een economische crisis geweest in het begin van de jaren '30, maar een eeuw van bittere armoede is anders.

Dat komt omdat we aan verschillende eeuwen zitten te denken. De Industriële revolutie begon rond 1800 (iets eerder in het VK), en heeft inderdaad een eeuw aan armoede opgeleverd. Onteigening van boeren begon in het VK ook in die tijd, in Nederland kwam die aan het einde van de 19e eeuw. In de 20e eeuw is de welvaartsgroei gelijker verdeeld, maar dat gebeurde niet vanzelf.

Productiviteitsverbetering hoeft niet tot verbetering van de welvaart te leiden.

diondokter schreef op dinsdag 21 juli 2026 @ 09:56:
Draai hem om. Wie kan voor LLMs betalen als je geen klanten hebt die je producten kunnen betalen?

We hebben nu een wereldeconomie waarbij een groot deel van de wereldbevolking arbeid verricht die weinig toegevoegde waarde heeft (of waar weinig waarde aan wordt toegekend), en een klein deel van de wereldbevolking de consumptie aanjaagt. Er is geen reden waarom dat deel niet nóg kleiner kan worden, als ze nóg meer gaan consumeren.

En verder is er de AI Layoff trap: zelfs als bedrijven beseffen dat massa-ontslagen de consumptie en economie schaden, kan de concurrentie hen ertoe dwingen dit te doen.

[ Voor 5% gewijzigd door CVTTPD2DQ op 21-07-2026 19:32 ]

[LED-Maniak]

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

dat lijkt mij een broodje aap verhaal.

Voor alle likes op deze post die de ervaring als broodje aap aanzien: blijkbaar gebeurt het vaker. Toevallig kwam ik deze post vandaag tegen: https://www.reddit.com/r/..._entire_project_and_home/

Claude kan meer kapot maken dan je lief is. Gewaarschuwd mens telt voor twee.

[Marc3l]

LED-Maniak schreef op vrijdag 18 september 2026 @ 15:52:
[...]

Claude kan meer kapot maken dan je lief is. Gewaarschuwd mens telt voor twee.

Als je Claude ook zoveel permissie geeft, geen backup hebt moet je je ook wel afvragen waar jezelf mee bezig bent.

[NiGeLaToR]

Marc3l schreef op vrijdag 18 september 2026 @ 16:31:
[...]


Als je Claude ook zoveel permissie geeft, geen backup hebt moet je je ook wel afvragen waar jezelf mee bezig bent.

Hoezo? Doet Claude dat niet voor je? Dat afvragen?

Dit is toch de shittification van 'nadenken' in een notendop?

De hoeveelheid mensen die nu website live pleuren met louche businessmodellen is verschrikkelijk en ze zijn vaak nog goed te vinden in Google ook. Ik heb inmiddels diverse vrienden en familie gehad die mij sites over niet bestaande energiesubsidies stuurden (marketing tunnel), sites over goedkope thuisbatterijen (marketingtunnel) en prijsvergelijkers met niet bestaande producten en winkels (nog een vorm van data hervesting). Elke keer weer zit er een net opgericht bedrijfje achter wat je data gebruikt om je shit aan te smeren, elke keer weer klopt er niets van het 'advies'.

Dus: als je een toekomst wilt in development: ga mensen oplicht
Of begin een Claude-code-fixing bedrijfje, om de chaos die ongetwijfeld ontstaat her en der, te helpen fixen.
Ben een fervent en dagelijks AI gebruiker, maar daardoor ook scepticus.

[LED-Maniak]

Marc3l schreef op vrijdag 18 september 2026 @ 16:31:
[...]


Als je Claude ook zoveel permissie geeft, geen backup hebt moet je je ook wel afvragen waar jezelf mee bezig bent.

Er is een stukje educatie nodig hoe je met AI moet omgaan. Zoals mijn collega dus die blind op alles van claude vertrouwt en alles copy-paste in een terminal doet zonder maar iets te weten over de commando's in linux.

Aansluitend op de "Carrièreperspectief software development in AI revolutie" titel denk ik dat daar het grootste stuk weggelegd is: niet het schrijven van code, maar hoe goed om te gaan met deze krachtige technologie en precies begrijpen wat je wel en wat je juist niet moet doen. Iedereen kan prompten, niet iedereen kan goede prompts maken.

[Stukfruit]

LED-Maniak schreef op vrijdag 18 september 2026 @ 15:52:
[...]

Voor alle likes op deze post die de ervaring als broodje aap aanzien: blijkbaar gebeurt het vaker. Toevallig kwam ik deze post vandaag tegen: https://www.reddit.com/r/..._entire_project_and_home/

Claude kan meer kapot maken dan je lief is. Gewaarschuwd mens telt voor twee.

Van de gelinkte pagina:

"... and I was at the point where I wanted to add a relatively straightforward delete feature."

Feature werkte dus

Maar de verantwoordelijke ontwikkelaar had nooit om een "delete feature" gevraagd, noch had deze direct met bestanden op een harddisk gewerkt, noch had deze het op deze manier ingeschoten als prompt.

Wat ik probeer te zeggen: je leest dit soort verhalen inderdaad best vaak op Reddit. En iedere keer blijkt het een beginner te zijn. Een beetje ontwikkelaar werkt met ontkoppeling van data en opslag of gebruikt een package/library die dit werk uitvoert via code die al gecontroleerd is voordat het wordt uitgevoerd. Waarom deed betreffende gebruiker dit niet?

Met C++ kun je jezelf ook al vele jaren heel hard in de voet schieten, dus wat dat betreft is er eigenlijk weinig veranderd behalve dat meer mensen nu een geladen geweer op hun voet richten en verwachten dat het niet af kan gaan.

Qua carrièreperspectief lijkt deze persoon daarmee ook zonder AI niet erg geschikt te zijn voor het produceren van betrouwbaar werk.

[Zorg]

@Stukfruit je leest dit soort verhalen ook veel op reddit omdat er vaak geen ruk van waar is
Ik heb zelf verschillende apps gebouwd met allemaal delete functies maar nog nooit zoiets meegemaakt, niet eens in de buurt. En ja ik maak(te) backups op s3 buckets maar moet toch eerlijk toegeven dat ik daar wel mee gestopt ben ook omdat ik in de afgelopen twee jaar nog nooit een backup terug heb gezet. Dat is natuurlijk geen excuus.

Overigens vrijwel full terminal access tot mijn (dedicated) Ubuntu PC, AWS (ok daar moet ik wel specifiek een key voor activeren met MFA) en (dedicated) Windows PC. Heb daar een agentic orchestration laag omheen gebouwd waarbij opdrachten voor development (of gewoon Windows achtige taken) naar één van de twee PCs worden gestuurd en worden uitgevoerd met checkpoints die terug naar mijn visuele omgeving wordt gestuurd. Deze set-up verzorgt vrijwel alle volledige code maar ook office taken (email opvolging, betalingen klaarzetten). Ik ben inmiddels wel van mening dat het alles kan wat ik zelf op een pc kan doen.
En werkt met eigen voice2voice, voice2text, text2text interface zodat ik er gewoon tegen kan praten en opdrachten kan geven.

[wiemelen]

[b]Stukfruit schreef op vrijdag 18 september 2026 @ 20:26

En iedere keer blijkt het een beginner te zijn. Een beetje ontwikkelaar werkt met ontkoppeling van data en opslag of gebruikt een package/library die dit werk uitvoert via code die al gecontroleerd is voordat het wordt uitgevoerd. Waarom deed betreffende gebruiker dit niet?
...
Qua carrièreperspectief lijkt deze persoon daarmee ook zonder AI niet erg geschikt te zijn voor het produceren van betrouwbaar werk.

Welkom in het dagelijkse leven zou ik zeggen.
Maar ook "ervaren" IT-ers leveren zulke code op met beginnersfouten. Ik heb ook zo iemand naast me die langer dan ik aan't programmeren is (+25 jaar) en die maakt ook nog steeds bijna dagelijks zulke fouten. Levert buiten veel frustratie ook nog extra werk op voor mij. En ondanks het zoveelste begeleidingstraject (lees opnieuw extra werk voor mij) durven/kunnen ze niet echt ingrijpen.

Ik hoor/lees vaak dat AI er voor gaat zorgen dat enkel de betere programmeurs nog werkzekerheid gaan hebben. Daar twijfel ik sterk aan. Want dit soort beunhazen zullen vast ook werkende code opleveren, maar over X aantal jaar heeft zijn werkgever een draak van IT systeem waar niemand nog iets van de code snapt. En onderschat niet het aantal KMO's waarbij 1 beunhaas IT-er zich helemaal heeft laten gaan.

Een goed punt dat je aanhaalt is dat het vaak een beginner is. Maar hoe ga je over een aantal jaar een beginner dan opleiden? Kennis groeit door de jaren en door het feit dat je fouten kan/mag maken waaruit je leert. Zo hebben wij toch ook doorheen de jaren (hopelijk) veel bijgeleerd (hopelijk) zonder al te grote ongevallen. Door zelf te programmeren en telkens kleine stukjes code te testen, blijft de impact beperkt. Maar als je hele oplossingen copy/paste van AI, zonder de juiste ervaring, ga je toch ergens eens serieus tegen de lamp lopen. Beeld je eens in wat er zou gebeurd zijn indien het pensienfonds uit onderstaand voorbeeld niet zelf voor een backup bij een 2de cloud provider had gezorgd.
https://www.notebookcheck...-herstellen.839219.0.html
En dan was dit een opeenstapeling van menselijke fouten (of wordt toch zo beweerd). Stel je voor dat iemand (of een rogue AI) zoiets voor mekaar krijgt door een copy/paste actie.

[defiant]

wiemelen schreef op zaterdag 19 september 2026 @ 08:11:
Ik hoor/lees vaak dat AI er voor gaat zorgen dat enkel de betere programmeurs nog werkzekerheid gaan hebben. Daar twijfel ik sterk aan. Want dit soort beunhazen zullen vast ook werkende code opleveren, maar over X aantal jaar heeft zijn werkgever een draak van IT systeem waar niemand nog iets van de code snapt. En onderschat niet het aantal KMO's waarbij 1 beunhaas IT-er zich helemaal heeft laten gaan.

Het probleem met IT is al sinds het begin dat er weinig professionalisering vanuit het vakgebied zelf wordt opgelegd. In veel andere vakgebieden zijn er opleidingseisen die ook verplicht worden gesteld en wordt er vanuit het vakgebied zelf vaak gewerkt met procedures en protocollen.

In de IT wil men hier al decennia niets van weten. Het is geen beschermd beroep en er zijn ook geen opleidingseisen, iedereen kan gewoon direct aan de slag. Ik heb menig manager horen proclameren dat hun beste programmeurs zijinstromers waren, maar ook menig IT'er zelf is van mening dat je het beroep het beste vrij kan laten.

En je ziet dat het hierdoor ook vaak fout gaat met de non-functionals zoals onderhoudbaarheid, beveiliging en infrastructuur. De requirements zijn bij veel software niet erg hoog zodat ook een matige programmeur wel een manager tevreden kan krijgen, maar die heeft vaak geen zicht op dit soort non-functionals.

Het vakgebied is nu al meer dan 50 jaar oud, maar In veel opzichten is het nog steeds een cowboy gebied. Het is typisch dat Fred Brooks in de jaren 70 al zaken constateerde die het vakgebied nog steeds plagen.

AI gaat hier niet veel mee helpen, omdat de AI simpelweg meegaat in bestaande conventies en daar ook is getraind. De enige vooruitgang op dit gebied is dat AI wel goed is in het vinden van beveiligingsproblemen.

Wil het vakgebied vooruitgang boeken, dan zijn er gewoon meer harde eisen en procedures nodig inclusief inhoudelijk audits. Het is aan de enge kant best verwonderlijk dat we collectief de huidige staat van de IT zijn gaan accepteren, met matige functionerende software, exploits, datalekken, etc.

[dmantione]

Betere opleiding: Weinig programmeurs hebben een informatica-opleiding gevolg. Zelfstudie, of mensen die op een cursus programmeren gestuurd zijn, domineren het programmeersvak. Of er worden wat "kennismigranten" geïmporteerd, die inderdaad wel kunnen programmeren, maar direct falen als je ze naar hun theoretische achtergrond vraagt.

Een belangrijke reden is dat er in de maatschappij veel meer behoefte is aan software dan we informatici kunnen opleiding. Ik ben altijd warm pleitbezorger geweest van echt informatica-onderwijs op scholen in plaats van de computervaardigheden die nu worden onderwezen: Er is immers veel meer behoefte aan software in de maatschappij dan waar door afgestudeerde informatici in kan worden voorzien, de oplossing is om het een gewoon schoolvak te maken. Zeker niet minder nuttig voor de maatschappij dan dat iedereen op school leert om een wiskundige vergelijking te integreren.

De KI-revolutie doorbreekt dat op vrij ruwe wijze: Opeens is er geen schaarste aan software meer, er is een overvloed. Ik denk dat het nog steeds zinnig is om mensen beter op te leiden, maar programmeeronderwijs staat op eens in een heel ander licht.

[Stukfruit]

Zorg schreef op zaterdag 19 september 2026 @ 08:03:
@Stukfruit je leest dit soort verhalen ook veel op reddit omdat er vaak geen ruk van waar is
Ik heb zelf verschillende apps gebouwd met allemaal delete functies maar nog nooit zoiets meegemaakt, niet eens in de buurt. En ja ik maak(te) backups op s3 buckets maar moet toch eerlijk toegeven dat ik daar wel mee gestopt ben ook omdat ik in de afgelopen twee jaar nog nooit een backup terug heb gezet. Dat is natuurlijk geen excuus.

Overigens vrijwel full terminal access tot mijn (dedicated) Ubuntu PC, AWS (ok daar moet ik wel specifiek een key voor activeren met MFA) en (dedicated) Windows PC. Heb daar een agentic orchestration laag omheen gebouwd waarbij opdrachten voor development (of gewoon Windows achtige taken) naar één van de twee PCs worden gestuurd en worden uitgevoerd met checkpoints die terug naar mijn visuele omgeving wordt gestuurd. Deze set-up verzorgt vrijwel alle volledige code maar ook office taken (email opvolging, betalingen klaarzetten). Ik ben inmiddels wel van mening dat het alles kan wat ik zelf op een pc kan doen.
En werkt met eigen voice2voice, voice2text, text2text interface zodat ik er gewoon tegen kan praten en opdrachten kan geven.

Je bespreekt hier behoorlijk wat lagen die de kans op fouten redelijk vergroot

Het punt van risicomanagement is dat je onafhankelijk van enige bias en/of wel/niet kloppende externe verhalen vooraf voorkomt dat je achteraf niets meer hebt.

Bij jou kan dit bijvoorbeeld gebeuren doordat de agent je een waslijst met taken stuurt waarvan de bijbehorende informatie niet binnen de context past of simpelweg niet wordt nageslagen zoals in de meeste gevallen.

Agent belooft plechtig niet te zullen afwijken van wat je denkt dat het ding gaat doen, agent vindt echter buiten de planningsfase om dat ie niet goed alles vooraf heeft gebaseerd op echte kennis, besluit om toch door te gaan en toevallig moet daarvoor je AWS-account worden opgeheven.

Whoop, daar gaat je account

Nu kun je zeggen: dat overkomt mij niet, want ik doe netjes vooraf aan het decomposen van alle taken die ik het laat uitvoeren zodat het altijd 100% vooraf duidelijk is en volledig gebaseerd op feitelijke informatie.

Laten we aannemen dat dit ook klopt: dan alsnog zit er een stoorfactor in: jijzelf. Want na een dag flink werken of anderszins bezigheidstherapie beoefenen ga jij echt niet helder genoeg zijn om in een heftige sessie waarin je alleen visueel naar resultaten kijkt precies te achterhalen waar alle prozaïsche meuk die door het model wordt uitgepoept exact over gaat.

Dat visuele is per definitie een hele grote rode vlag; wat er goed uitziet is 100% nooit wat je denkt dat het is. Heb je gekeken naar de hoeveelheid if-else meuk die je nu zal hebben voor honderden uitzonderinssituaties die als een prachtige spaghetti ieder toekomstig inzicht voor jou én de agent exponentieel moeilijker maken om te interpreteren?

Dat is het verschil tussen zelf wat leuk aanprutsen (helemaal niets mis mee zolang je maar niet doet alsof je ervaring hebt met het onderliggende werk) en professioneel prutsen: een persoon die dat laatste volgt neemt eerder vooraf maatregelen nemen om de "blastradius" bij fouten ernstig te verkleinen. Iemand zoals die persoon op Reddit is daar, als het echt is, op de minder leuke manier achtergekomen.

En omdat je het over het automatiseren van kantoortaken lijkt te hebben: dat (software development dus) is niet waar dit topic over gaat he. Dat maakt ook veel uit

[Stukfruit]

wiemelen schreef op zaterdag 19 september 2026 @ 08:11:
[...]

Welkom in het dagelijkse leven zou ik zeggen.
Maar ook "ervaren" IT-ers leveren zulke code op met beginnersfouten. Ik heb ook zo iemand naast me die langer dan ik aan't programmeren is (+25 jaar) en die maakt ook nog steeds bijna dagelijks zulke fouten. Levert buiten veel frustratie ook nog extra werk op voor mij. En ondanks het zoveelste begeleidingstraject (lees opnieuw extra werk voor mij) durven/kunnen ze niet echt ingrijpen.

Klopt, dat noem ik altijd de "frameworkprogrammeurs": mensen die wel met frameworks kunnen omgaan, maar beginnen te zweten als ze dieper moeten duiken en die kans nooit eerder hebben opgepakt om redenen.

Ik heb liever een beginner naast me zitten die wel interesse heeft in uitzoeken hoe het onder de motorkap werkt.

Een goed punt dat je aanhaalt is dat het vaak een beginner is. Maar hoe ga je over een aantal jaar een beginner dan opleiden?

Misschien door de beginner mee te nemen in de laag achter de gegenereerde code?

Dat is wat je nu als senior in principe ook doet: je blijft herhalen dat mensen geen spaghetti kunnen schrijven omdat X en Y anders onwerkbaar worden met reden Z en W. Je legt uit waarom, niet wat.

Je leert ze de abstracte concepten aan, niet de code.

[Wozmro]

Misschien een domme vraag van een niet-programmeur: bestaan er dan geen normen in de programmeerwereld? Iets vergelijkbaar als pakweg de NEN1010 (en heel veel andere in allerlei vakgebieden), of een algemene Euroepese norm (EN...), ISO...?

Ik hoorde onlangs op de radio van een of ander hoofd van Imec dat de kostprijs voor een regel code is gedaald van 44 dollar naar 1 dollar door de opkomst van AI.

Dat vertelt niet het volledige plaatje maar wel dat dit iets onweerstaanbaar is voor bedrijven en dat je dit niet kan (blijven) negeren. Er zal moeten gepraat worden over het kader.

[Zorg]

@Stukfruit Ik heb het dan over circa 55 development taken op het gebied van webapp development. Ok, privé gebruik maar als ik de code bekijk en beoordeel, zover als ik met mijn kennis en ervaring kan, zie ik er geen rariteiten in. Het komt wel voor dat ik bijv merk dan een functie langer duurt dan ik zou verwachten, ook het debuggen gaat dan eigenlijk prima. Dit gaat dan om redelijk uitgebreide taken die ik klaarzetten door eerst rustig functionaliteiten uit te schrijven (met behulp van chatgpt), gevolgd door gerichte vragen te stellen gericht op het technische Luik, vervolgens een uitgebreide MD file te maken die altijd begint met onderzoek van het huidige stuk en altijd in stappen het werk doet welke ik dan controleer. Vervolgens stuur ik dat voor execution en wordt het werk uitgevoerd. Eens het klaar is worden alle logfiles en outputs beoordeeld en wordt het kennisprofiel daarmee geupdate. Voor mij valt dit onder software development.

En gezien het (voor mij) goed werkt met het maken van wat ik wil ben ik daarnaast gaan zien hoe goed het werkt voor, eigenlijk simpelere, taken uit te voeren. Zoals dus office achtige taken. Hetgeen ook prima werkt.

Ik ben geen programmeur als in software development maar heb wel een zeer brede kennis van IT. Ik kan programmacode prima lezen en weet 9 vd 10 ook echt wel wat het doet. Ik heb alleen een grafhekel aan code schrijven

[ Voor 58% gewijzigd door Zorg op 19-09-2026 13:18 ]

[diondokter]

Wozmro schreef op zaterdag 19 september 2026 @ 13:04:
bestaan er dan geen normen in de programmeerwereld?

Ja en nee. Niet in het algemeen, maar in de verschillende safety-critical domeinen (zoals automotive, medical en aerospace) zijn er wel systeemseisen. Het uiteindelijke product moet veilig zijn. Als er software in het systeem zit dat (deels) verantwoordelijk is voor die veiligheid, dan zal er ook verantwoord moeten worden hoe dat gewaarborgd is.

In principe kun je bij een keurings instantie langs gaan met willekeurige code en die laten keuren. En als het goede code is, dan zal dat lukken. Maar het is erg duur.
Om het goedkoper te maken, dan kun je je houden aan bestaande guidelines. Dat wil je doen omdat je dan alleen hoeft te bewijzen dat de code aan die guidelines voldoet. Dit maakt het voor de keuring veel makkelijker.

Dus nee, normen zijn er alleen voor systemen en die zijn makkelijker te halen als de software aan bepaalde guidelines voldoet

[Stukfruit]

Zorg schreef op zaterdag 19 september 2026 @ 13:09:
@Stukfruit Ik heb het dan over circa 55 development taken op het gebied van webapp development. Ok, privé gebruik maar als ik de code bekijk en beoordeel, zover als ik met mijn kennis en ervaring kan, zie ik er geen rariteiten in. Het komt wel voor dat ik bijv merk dan een functie langer duurt dan ik zou verwachten, ook het debuggen gaat dan eigenlijk prima.

Debuggen door jou of door de agent?

Qua webapps: zie m'n reactie van gisteren op de frontpage. Vooral het laatste stukje.

[Zorg]

Stukfruit schreef op zaterdag 19 september 2026 @ 13:17:
[...]


Debuggen door jou of door de agent?

Qua webapps: zie m'n reactie van gisteren op de frontpage. Vooral het laatste stukje.

Ook debuggen laat ik vanzelfsprekend door claude zelf doen, daarna test ik of het juist gedaan is.

Goh back-end / front-end discussie. Ik denk dat het meer is dan statische HTML code, er zitten databases achter, execution triggers, beveiligde SSH tunnels om de servers aan te spreken, synchronisatie van bestanden tussen onedrive, api links naar openai om weer outputs te laten beoordelen maar ook de realtime api voor communicatie, hetzelfde voor elevenlabs. Security wordt afgehandeld via cognito over aws. Dus wel meer dan een beetje Frontpage denk ik

Daar ben ik overigens mee begonnen.... eerste webpagina HTML code via notepad.... vol trots laten zien aan een oom (die studieboeken programmeren in Pascal heeft uitgebracht) en die mij (als toen jong jochie) liet zien dat dat 10x sneller kon in Frontpage. Ja die laadde destijds veel rommel mee maar de impact daarvan was miniem.

Was mijn vorige bericht nog aan het typen maar drukte perongeluk op verstuur dus had nog wat meer erbij gezet, je was alleen te snel

[ Voor 5% gewijzigd door Zorg op 19-09-2026 13:26 ]

[SCIxX]

Ben juist benieuwd naar verhalen van mensen die écht software development hebben weten te automatiseren via genAI, of dat nou KTLO reductie, modernisatie of nieuwe features live krijgen.

Wat ik zelf vooral zie is Anthropic die de wilde verhalen rondslingert van loops and fully automic agents, maar buiten deze slager die ziin eigen vlees keurt zie ik hier helemaal geen voorbeelden van.

Begrijp me niet verkeerd, ik gebruik genAI dagelijks en haal er veel waarde uit maar voor zover ik kan zien zijn we ver weg van fully autonomous development en weet ik niet of dit voor een gemiddeld bedrijf (met een complexe codebase en een hoop legacy) haalbaar is met genAI.

[dmantione]

Een programmeursmentaliteit om toezicht te houden op de bots is heel belangrijk. KI-bots kunnen niet-triviale lappen code schrijven en debuggen, maar ze produceren code die aan de prompt voldoet. Ze hebben weinig respect of dat elegant of lelijk gebeurt, ze kijken niet vooruit, snijden bochten af en ga zo verder. Als jij met programmeursinzicht een bot stuurt is het resultaat veel beter dan als je het ding autonoom zijn werk laat doen.

Daarbij wel de nuancering dat de ontwikkelingen momenteel erg snel gaan.

[eric.1]

Wozmro schreef op zaterdag 19 september 2026 @ 13:04:
Ik hoorde onlangs op de radio van een of ander hoofd van Imec dat de kostprijs voor een regel code is gedaald van 44 dollar naar 1 dollar door de opkomst van AI.

Dat vertelt niet het volledige plaatje maar wel dat dit iets onweerstaanbaar is voor bedrijven en dat je dit niet kan (blijven) negeren. Er zal moeten gepraat worden over het kader.

Volgens mij neemt niemand (met een degelijke achtergrond) 'een regel code' als maatstaf, laat staan de kostprijs ervan. Geen idee wat zoiets zegt. Een regel code van iemand ingehuurd uit India zal ook significant goedkoper zijn dan van een ontwikkelaar in West-Europa. Toch is de gehele ontwikkeling-markt niet vertrokken naar India, ondanks doem-beelden toen ik nog op de Hogeschool rondliep een jaar of 13 terug.

En ook enig ironisch vind ik die kostprijs voor een regel code gebruik makend van AI. Als je puur kijkt naar de gebruikte tokens, sure. Naar het financiële plaatje erachter? Dan lijkt me het volstrekte onzin - er zijn nog vele miljarden terug te verdienen....dat moeten we wel mee blijven rekenen.

Maar ook om een voorbeeld te geven:

Ik deed een steekproef voor een afgebakende module binnen onze software. Geheel zelf geschreven, want het was relatief eenvoudig toen de vereisten (design, wensen, eisen, ...) eenmaal bekend waren (en daar zit ook een deel van het AI-punt...dat blijft veel mens-werk). Vanaf hetzelfde startpunt heb ik met AI dit getracht te doen - wat op zich wel lukte. Na een heel aantal iteraties kwam de AI-oplossing uit op 5x zoveel code.

Ja, dat kostte inderdaad weinig tokens. Maar wat zegt zoiets? In mijn optiek dat je binnen de kortste keren een niet-beheerbaar product hebt.

[Marc3l]

Ik wil ook echt alles zelf controleren wat hij schrijft, niet alleen output en de logs.
Moet hem nog vaak corrigeren, 'zijn' gemaakte functionaliteit werkt meestal wel maar is niet efficiënt of netjes. Ik doe het in kleine stapjes, in mijn prompts geef ik op wat ik wil hebben met zoveel mogelijk details/context, ik weet wat zelf prima wat ik moet schrijven maar Claude doet dit sneller. Dus het is meer mijn notulist dan ik hem vanzelf alles laat bedenken.

[defiant]

SCIxX schreef op zaterdag 19 september 2026 @ 13:32:
Ben juist benieuwd naar verhalen van mensen die écht software development hebben weten te automatiseren via genAI, of dat nou KTLO reductie, modernisatie of nieuwe features live krijgen.

Ik ben ook benieuwd waar die verhalen vandaan komen, ik werk persoonlijk best veel met AI (claude), maar ik heb nog steeds bottlenecks als toen ik alles zelf moest doen. Requirements engineering blijft hetzelfde qua tijdsbesteding en gebruik van AI heeft plaats gemaakt voor code reviews en testen. Ik ben er nog steeds niet over uit of ik nu sneller ga dan als ik alles handmatig programmeer, want als ik handmatig programmeer doe ik ook kennis op van de code en het domein, ik ben er dan vaak vrij zeker van dat het functioneel correct is volgens de requirements. Met de AI bot moet ik het allemaal nog weer handmatig controleren.

Het enige waar AI echt veel winst mee behaald zijn afgebakende taken die functioneel gezien niets wijzigingen. Grote refactors zoals het verplaatsen/orderen/etc van code was normaliter erg vervelend handwerk, maar gaat met AI verbazingwekkend soepel.

[wiemelen]

Wozmro schreef op zaterdag 19 september 2026 @ 13:04:
Ik hoorde onlangs op de radio van een of ander hoofd van Imec dat de kostprijs voor een regel code is gedaald van 44 dollar naar 1 dollar door de opkomst van AI.

Ja de kostprijs zal (voorlopig) wel naar beneden gaan door AI. Totdat de tokens duurder worden. Maar hij vergeet wel even te vermelden dat het nog best veel tijd en geld kost om iemand op te leiden zodat die de kennis heeft een correcte prompt te schrijven en de resultaten achteraf te verifiëren. Om inzicht te krijgen om componenten generiek en herbruikbaar te maken. Om de juiste technische analyse te maken vooraleer de code geschreven kan worden. Want ook dat zijn skills die een programmeur zich eigen moet maken.

Het blijft gemakkelijk om zulke uitspraken te doen als je al 20-30 jaar ervaring hebt. AI ondersteunt, genereert code, maar crap in resulteert nog altijd in crap out.

[Kurkentrekker]

Voor heel veel organisaties en doelen is crap ook goed genoeg. Daar waar je vroeger een goed opgeleide ontwikkelaar zelf code liet schrijven, hoeft dat nu veel minder.

Dat neemt niet weg dat er nog steeds doelen zijn waar je wél die inzet van de echte professional nodig hebt (ziekenhuis software, noem maar op), maar voor heel veel dingen is ai slop nu goed genoeg. Ook omdat je het over vijf jaar, als het onbeheersbaar is geworden, gewoon in de modellen van dat moment gooit en die snappen het dan wel weer.

Het aantal mensen dat nog nodig is zal dus lager worden omdat de bedrijven die af kunnen met ai slop geen echte programmeurs meer inhuren. Dat zag je jaren terug bijvoorbeeld ook in de markt voor professionele vertalers. Dat ene literaire werk moet nog steeds gedaan worden, maar de handleiding van je broodrooster wordt gewoon gegenereerd door een machine.

Dat betekent dus nogal wat voor het vakgebied. En dan worden we dus ook nog afhankelijker van die gekkies uit silicon valley. Immers, als niemand meer de bulk van de code begrijpt en je tokens nodig hebt om continuïteit te waarborgen, dan gooien ze de prijzen weer wat omhoog. Lekker dan.

[Sissors]

defiant schreef op zaterdag 19 september 2026 @ 12:13:
[...]

Het probleem met IT is al sinds het begin dat er weinig professionalisering vanuit het vakgebied zelf wordt opgelegd. In veel andere vakgebieden zijn er opleidingseisen die ook verplicht worden gesteld en wordt er vanuit het vakgebied zelf vaak gewerkt met procedures en protocollen.

In de IT wil men hier al decennia niets van weten. Het is geen beschermd beroep en er zijn ook geen opleidingseisen, iedereen kan gewoon direct aan de slag.

Het zijn natuurlijk wel echt uitzonderingen, de gebieden waar harde opleidingseisen zijn vanuit bijvoorbeeld de wetgever. En dat is normaal voor goed afgebakende zaken. Eg je mag alleen met koudemiddel werken, met de juiste opleiding. Of alleen met een CV met de juiste opleiding. Medici hebben natuurlijk ook duidelijke eisen.

IT is veel grijzer. Een verplichte opleiding voordat je software mag schrijven? Geldt dat ook voor mijn Home Assistent plugin die ik zelf maak? Mag ik op mijn werk nog wel een Python scriptje maken om wat te automatiseren?

Het een beschermd beroep maken lijkt mij dan ook vooral heel erg complex voor heel weinig voordeel in de praktijk. Veruit de meeste beroepen zijn niet beschermd, maar daar kunnen we wel eisen stellen. Mijn beroep is absoluut niet beschermd. We halen ook niet zijinstromers met een traineeship van 2 maanden binnen... Dat is voor mij vooral hetgene bij de IT: Het zijn zoals je schreef echt niet alleen de managers die zeggen dat elke idioot IT'er kan worden, genoeg IT'ers zeggen dat ook.

Het is aan de enge kant best verwonderlijk dat we collectief de huidige staat van de IT zijn gaan accepteren, met matige functionerende software, exploits, datalekken, etc.

En dit vooral, niks is perfect, maar ik kan ook niet snel een ander vakgebied bedenken waarbij het zo geaccepteerd is dat zaken vol met fouten zitten.

[Glashelder]

Kurkentrekker schreef op zondag 20 september 2026 @ 08:54:
Dat betekent dus nogal wat voor het vakgebied. En dan worden we dus ook nog afhankelijker van die gekkies uit silicon valley. Immers, als niemand meer de bulk van de code begrijpt en je tokens nodig hebt om continuïteit te waarborgen, dan gooien ze de prijzen weer wat omhoog. Lekker dan.

Ik verwacht persoonlijk eigenlijk dat dat niet gaat lukken, omdat de open source modellen ook steeds beter worden. Het is een kwestie van tijd voordat hardware toch weer beter beschikbaar wordt. Als de prijs van tokens dan te hoog wordt, gaat men over naar lokale modellen.

Ik denk dat we in die hoek een beetje de roep om regulering van de AI frontiers moeten zoeken. Open source de nek omdraaien want niet gecertificeerd/voldoet niet aan de regels ofzo