Carrièreperspectief software development in AI revolutie

[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

[RooT]

Ik gebruik AI dagelijks voor mijn werk. Voor de embedded software die ik schrijf, gebruik ik AI veel om drivers e.d. te maken. Bijv. een ADC uitlezen, ik voer de datasheet in en AI genereert mij de volledige code. Dan is het vaak testen, en als het werkt bekijk ik de code om het te begrijpen en eventueel te verbeteren. Normaliter kost me zoiets dagen (afhankelijk van de complexiteit), nu is het een kwestie van minuten. Ook gebruik ik AI veel om te sparren over bepaalde code.

Uiteindelijk doe ik de architectuur nog zelf, en maak ik zelf nog de keuzes hoe alles met elkaar verbonden wordt. Maar als ik zie hoe hard de AI ontwikkelingen gaan, ben ik benieuwd hoe dat over 1 jaar is, laat staan 2. Dan is AI wellicht zover gevorderd dat het dat ook al kan.

[Wozmro]

Ik denk dat het in het algemeen wel een goed idee is om eens te sparren met een AI over de toekomst van je eigen job. (zonder specifieke of persoonlijke info door te geven).

Vanuit mijn eigen nieuwsgierigheid stel ik dan een vraag zoals 'Beschrijf de evolutie van X gedetailleerd jaar per jaar tot in het jaar Y'.

Niet dat je dit dan als waarheid moet aannemen maar het heeft wel een zeker richting waarin de zaken mogelijk zouden kunnen evolueren. En dan kan daar al eens rustig over nagedacht worden. Nadenken kost geen geld.

[RooT]

Wozmro schreef op vrijdag 25 september 2026 @ 13:31:
Ik denk dat het in het algemeen wel een goed idee is om eens te sparren met een AI over de toekomst van je eigen job. (zonder specifieke of persoonlijke info door te geven).

Vanuit mijn eigen nieuwsgierigheid stel ik dan een vraag zoals 'Beschrijf de evolutie van X gedetailleerd jaar per jaar tot in het jaar Y'.

Niet dat je dit dan als waarheid moet aannemen maar het heeft wel een zeker richting waarin de zaken mogelijk zouden kunnen evolueren. En dan kan daar al eens rustig over nagedacht worden. Nadenken kost geen geld.

Dit heb ik al uitgebreid besproken met 'mijn AI agent'.

Volgens die agent zal coderen binnen afzienbare tijd verdwijnen. Althans voor het grote deel. Het enige probleem is nog dat er teveel troep zit in de trainingsdata van de publieke modellen. Op het moment dat bedrijven prive AI's gaan krijgen (al dan niet offline in hun eigen omgeving) en de modellen trainen met hun eigen software, dan is het klaar.

Voorlopig is AI nog niet geavanceerd genoeg om de architectuur te bepalen, maar als ik zie hoe snel de ontwikkelingen gaan. Ik bedoel 2 jaar geleden was AI echt nog niet in staat de code te produceren wat het nu doet, en de modellen ontwikkelen zich exponentieel. Over een paar jaar is dat ook grotendeels klaar, zeker als zoals ik hierboven al zei bedrijven hun eigen trainingsdata kunnen gaan inladen.

[Wozmro]

En heb je dan ook de vraag gesteld hoe je daar zelf zo goed mogelijk kan op anticiperen?

Welke kennis, vaardigheden,... je mogelijk moet aanscherpen, welke aspecten AI toch nog moeite mee zal blijven hebben en waar je als mens het verschil kan maken?

[RooT]

Wozmro schreef op vrijdag 25 september 2026 @ 13:51:
En heb je dan ook de vraag gesteld hoe je daar zelf zo goed mogelijk kan op anticiperen?

Welke kennis, vaardigheden,... je mogelijk moet aanscherpen, welke aspecten AI toch nog moeite mee zal blijven hebben en waar je als mens het verschil kan maken?

Yep. In mijn geval, ik doe ook elektronica. En juist op dat grensvlak tussen de software en de elektronica is iets wat AI niet kan doen. Uiteindelijk blijft dat fysiek testen en de relatie tussen die 2 begrijpen.

Antwoord van mijn AI agent:
Wat onder druk staat: puur code schrijven op basis van een duidelijke spec. Boilerplate, drivers voor een bekend peripheral, unit tests, een migratie van de ene HAL naar de andere. Dat gaat veel sneller met AI, en wie alleen dat verkoopt, gaat concurreren met iets wat bijna gratis is.

Wat een stuk minder onder druk staat, en dat is toevallig precies jouw terrein:

• Contact met de fysieke wereld. Een BLE-verbinding die wegvalt bij een bepaalde behuizing, een EMC-test waar je op 180 MHz net overheen gaat. Ik kan meedenken, maar ik kan geen scoop vasthouden, geen ferriet omleggen en niet in de testkamer staan.
• Hardware en software samen. De meeste embedded bugs zitten precies op de grens: timing, layout, voeding, een errata in de silicon. Iemand die zowel het schema als de firmware snapt, is zeldzaam, en AI maakt dat eerder waardevoller dan minder waardevol.
• Verantwoordelijkheid en certificering. Een klant wil iemand die tekent voor CE, die aansprakelijk is en die weet wat een notified body wil zien. Dat wordt niet geautomatiseerd.
• Legacy. Oude code overzetten zonder goede documentatie, met gedrag dat alleen in het veld bekend is, vraagt oordeel en niet alleen code.

Overigens ben ik het er niet helemaal mee eens dat AI niet in 'errata van silicon' kan kijken, feitelijk zijn dat gewoon toevoegingen op datasheets en mijn ervaring is dat AI veel sneller datasheets kan lezen dan een mens. Wellicht dat het nog niet foutloos is in iedere situatie, maar dat zal zich enorm verbeteren komende tijd.

[wiemelen]

Deze week heb ik een "grappige" webinar van SAP gezien over het gebruik van AI en AI agents.
Volgens mij hebben ze het daar toch nog niet goed begrepen.
Hun voorbeelden vanuit MM en FI gingen stuk voor stuk over rapportages en acties die wekelijks herhaald moeten worden om te controleren op afwijkingen of iets dergelijks.
Dus in hun ogen moest een manager of eindgebruiker dan zelf wekelijks een prompt afvuren om bijvb. productie orders te identificeren die niet gekoppeld waren aan een sales order, financiele uitschieters melden of gelijkaardige andere scenario's.
Waarom zou je daar AI voor willen gebruiken om het uit te voeren? Voor dat soort controles maak je toch een rapportje dat dagelijks of wekelijks x keer draait en bij discrepanties een mailtje in een CM dropt of een workflow opstart. Daar wil je toch niet afhankelijk zijn van de aanwezigheid en nauwgezetheid of snuggerheid van een persoon.

1 van de vragen die gesteld werden door de kijkers, was iemand die een willekeurig formaat excel wilde opvoeren om o.b.v. de inhoud orders of documenten te laten bevestigen.
Antwoord : zolang de nodige data maar terug te vinden is, kan je daar AI voor inzetten.
Tof dat dit kan, maar daar wil je toch geen willekeurig formaat excel voor gebruiken die door iedere gebruiker anders opgeleverd wordt, maar een vaste template en liefst van al nog voldoende controles en verificaties (via macro's in excel of geautomatiseerd in SAP).
Blijkbaar bedenken en ontwikkelen die mensen bij SAP enkel code en hebben zij geen last van een leger van eindgebruikers die dagelijks hun uiterste best doen om procedures en handleidingen vooral niet te volgen om vervolgens bij ons aan te kloppen om alles recht te trekken. En dan verwonderderd zijn dat wij voor veel van hun dagelijkse taken een custom oplossing hebben zodat ze zelf niet teveel in het systeem moeten zitten.

Eerlijk gezegd zien wij best wel wat mogelijkheden voor AI binnen SAP, met name voor ad hoc rapportages, ondersteuning custom code, geautomatiseerd testen, ondersteuning van analyses etc., maar daar werd niets over verteld in deze webinar. Voor de dagelijkse run hebben wij onze interfaces en flows ondertussen zo geautomatiseerd en dichtgetimmerd, dat we daar wel AI kansen zien, maar relatief weinig.

[ari3]

Ik zie weinig toekomst voor software development als carrièrepad. Inhoudelijk wordt het vak gedefinieerd als het kunnen omzetten van specificaties teneinde een domeinproces te automatiseren. Hiervoor zijn kennis van domein, architectuur, coderen, verificatie en exploitatie nodig. Uiteindelijk blijft van deze taken alleen domeinkennis en verificatie over, de rest zal AI voor zijn rekening nemen.

Velen in dit topic hebben al opgemerkt dat het werk inhoudelijk steeds meer bestaat uit het valideren van gegenereerde code. Dat is een tijdelijke tussenstap die op termijn niet meer nodig zal zijn. Bedenk daarbij dat programmeertalen slechts een abstractie van de hardware zijn die het voor mensen begrijpelijk en werkbaar maken om een computer van instructies te voorzien. AI agents kunnen prima direct de executable/deliverables bouwen zonder code te hoeven genereren die voor mensen begrijpelijk is. Dat is zelfs efficiënter. Het interne model van een AI heeft geen programmeertaal nodig om machinecode te genereren.

Als het er op aankomt heeft code alleen waarde als je verwacht dat mensen code moeten aanpassen. Echter, als de functionele en niet-functionele eisen aan een applicatie met voldoende dekking gevalideerd kunnen worden dan heeft de manier waarop de machinecode tot stand komt geen enkele waarde meer. Als de validatie uitwijst dat er iets mist dan wordt de instructie aan de AI verbeterd en laat je de applicatie opnieuw genereren. Daar komt geen handgeschreven code aan te pas.

Om die zelfde reden zal ook software architect geen carrièrepad meer zijn. Een architectuur structureert en normaliseert, veelal op een manier om het voor mensen begrijpelijk te maken, maar biedt op zichzelf geen functionele waarde. Applicaties kunnen prima voldoen aan gestelde eisen zonder een architectuur te volgen. Ook hier geldt: als de validatie uitwijst dat de applicatie voldoet aan de gestelde eisen dan heeft een architectuur geen waarde meer.

Het heeft tijd nodig voordat mensen de controle uit handen geven aan een tool. We zien dit ook met zelfrijdende auto's: het is nog niet perfect, maar het moment dat het beter is dan menselijke bestuurders nadert snel. Dit geldt ook voor het ontwerpen, coderen, testen en beheren van software.

[eheijnen]

De markt bepaalt wat er gebeurt.
Als bedrijf A door het gebruik van AI zijn concurrentie-positie kan verbeteren zullen concurrerende bedrijven mee moeten of ze lopen de kans om omzetverlies te lijden.

Het is en blijft een grote rat-race, mensen zijn daar over het algemeen bijzaak; zeker als het erop aan komt.

[Keipi]

Zolang je blijft geven om diepgaande technische kennis, denk ik dat er weinig gaat veranderen voor je carrière. Dan is AI niet veel anders dan een hulpmiddel, en hulpmiddelen komen en gaan.

Ik heb het geluk om voor een bedrijf te werken waar we zoveel of weinig AI mogen gebruiken als we willen. Vorig jaar december leek het allemaal even heel eng, maar dat is inmiddels geweest.

AI is geweldig voor veel dingen, maar uiteindelijk gaat een mens het nog moeten snappen en wij leren door te doen. Dat vindt ik ook het lastigst aan het werk op het moment; niet lui zijn.

Er zijn een aantal collega’s die nu alles viben, ik denk dat zij er over een paar jaar niet meer zullen zijn. Wat is hun meerwaarde nog?

Er zijn ook collega’s die alles zelf nog proberen te snappen. Zogauw een AI weer spaghetti heeft geschreven, zullen zij nodig zijn om het op te lossen. De vibers die alleen de bedoeling van hun prompts snappen, zullen daar niet uitkomen.

Tegelijkertijd gaan sommige takken van development werk toch veranderen, en zullen banen veranderen. Waar heb je nog zoveel frontenders voor nodig? En voor de meeste backends kan AI het echt wel beter. Maar, er gaan nu ook veel meer mensen een backend, frontend of een interne applicatie willen dan eerst. Uiteindelijk gaat iemand dat moeten onderhouden.

[Zorg]

Keipi schreef op vrijdag 25 september 2026 @ 21:09:
Er zijn ook collega’s die alles zelf nog proberen te snappen. Zogauw een AI weer spaghetti heeft geschreven, zullen zij nodig zijn om het op te lossen. De vibers die alleen de bedoeling van hun prompts snappen, zullen daar niet uitkomen.

Als de code doet wat het moet doen, wat valt er dan op te lossen?
Spaghetti code heb ik ook veelal gehoord voor het LLM tijdperk gemaakt door programmeurs van vlees en bloed.

[Gr4mpyC3t]

Zorg schreef op vrijdag 25 september 2026 @ 22:23:
[...]


Als de code doet wat het moet doen, wat valt er dan op te lossen?
Spaghetti code heb ik ook veelal gehoord voor het LLM tijdperk gemaakt door programmeurs van vlees en bloed.

'Doet wat het moet doen' is nogal een ruim begrip. Als je een LLM vraagt code te schrijven dan komt er tegenwoordig wel wat werkends uit. Vraag je vervolgens of er nog wat te verbeteren valt waardoor de boel efficiënter/stabieler/veiliger wordt, dan zijn er opeens toch weer nieuwe zaken gevonden.

Het lijkt me vooral belangrijk dat de output gecontroleerd kan worden door iemand met verstand van zaken. En dan krijg je het catch 22 effect, want wie kan dat nog als alles wordt geschreven door AI?

[Zorg]

@Gr4mpyC3t zoals bij een programmeur ook het geval is? Want daar (ok misschien andere omstandigheden) valt ook nog wel eens wat te verbeteren

Tweede stuk ben ik het helemaal mee eens! Verstand van zaken is zeer belangrijk om te kunnen beoordelen of iets goed is of niet, daar ontbreekt het vaak wel aan in de business. Het weten waarom iets gebeurd op een bepaalde manier en dat ook echt begrijpen, dat is juist het moeilijke. Maar eigenlijk doe je ervaring op door het ook te doen, hence je catch 22.... geen idee hoe we dat gaan ondervangen, en zal dat nog nodig zijn in de toekomst?

[Gr4mpyC3t]

Zorg schreef op vrijdag 25 september 2026 @ 22:40:
@Gr4mpyC3t zoals bij een programmeur ook het geval is? Want daar (ok misschien andere omstandigheden) valt ook nog wel eens wat te verbeteren

Dat is zeker zo, maar een team van programmeurs weet over het algemeen wel waar de zwakke plekken in de codebase zitten. Binnen ons team weten we dondersgoed welke componenten een nieuwe iteratie verdienen, of extra aandacht vereisen.

Er zijn keuzes gemaakt om zaken op een bepaalde manier in te richten en de juiste tijd te geven, gevoed door wat er speelt in ‘de business’.

Een AI heeft die context allemaal (nog) niet.

TLDR: Het is waardevol om te weten waar de zwaktes zitten.

[ Voor 4% gewijzigd door Gr4mpyC3t op 25-09-2026 22:52 ]

[Sissors]

RooT schreef op vrijdag 25 september 2026 @ 14:05:
[...]

Yep. In mijn geval, ik doe ook elektronica. En juist op dat grensvlak tussen de software en de elektronica is iets wat AI niet kan doen. Uiteindelijk blijft dat fysiek testen en de relatie tussen die 2 begrijpen.

Antwoord van mijn AI agent:
Wat onder druk staat: puur code schrijven op basis van een duidelijke spec. Boilerplate, drivers voor een bekend peripheral, unit tests, een migratie van de ene HAL naar de andere. Dat gaat veel sneller met AI, en wie alleen dat verkoopt, gaat concurreren met iets wat bijna gratis is.

Wat een stuk minder onder druk staat, en dat is toevallig precies jouw terrein:

• Contact met de fysieke wereld. Een BLE-verbinding die wegvalt bij een bepaalde behuizing, een EMC-test waar je op 180 MHz net overheen gaat. Ik kan meedenken, maar ik kan geen scoop vasthouden, geen ferriet omleggen en niet in de testkamer staan.
• Hardware en software samen. De meeste embedded bugs zitten precies op de grens: timing, layout, voeding, een errata in de silicon. Iemand die zowel het schema als de firmware snapt, is zeldzaam, en AI maakt dat eerder waardevoller dan minder waardevol.
• Verantwoordelijkheid en certificering. Een klant wil iemand die tekent voor CE, die aansprakelijk is en die weet wat een notified body wil zien. Dat wordt niet geautomatiseerd.
• Legacy. Oude code overzetten zonder goede documentatie, met gedrag dat alleen in het veld bekend is, vraagt oordeel en niet alleen code.

Overigens ben ik het er niet helemaal mee eens dat AI niet in 'errata van silicon' kan kijken, feitelijk zijn dat gewoon toevoegingen op datasheets en mijn ervaring is dat AI veel sneller datasheets kan lezen dan een mens. Wellicht dat het nog niet foutloos is in iedere situatie, maar dat zal zich enorm verbeteren komende tijd.

Laten we hopen dat dat niet werkelijkheid wordt. Want hardware kan AI uiteraard ook. Legacy is die misschien eerder beter in dan slechter (grote hoeveelheden code parsen). Wat overblijft is fysiek de scope aansluiten en iemand die de lul is en de verantwoordelijkheid moet pakken? Joepie...

Laatste keer dat ik in ons lab (elektronica ook) bezig geweest ben, was het kwestie van draadjes aansluiten op test-PCB van een ander, computer eraan hangen (zonder monitor zelfs) die via GPIB / USB alles bediende, en 95% van het lab werk deed ik vanuit thuis of kantoor op remote desktop naar die computer. Nu snap ik dat dat niet altijd zo is, maar als mijn werk nog zou zijn de 5% van aan een potmetertje draaien omdat die ene voeding niet digitaal bediend kon worden? Joepie?

[bloody]

De verleiding is heel groot om maar alle voorstellen van je agent te accepteren. Immers, hij zal het wel weten. Als je dit bij jezelf merkt, ben je op weg om een meat proxy te worden. Vraag je af of je dit wel wilt voor jezelf.

Ook is er een groot risico op kennisverlies/niet-toename. Immers, AI neemt het lerend vermogen weg wat je wel hebt door het zelf te doen. Als je dingen een tiental keer zelf gedaan hebt, weet je het wel en is dat prima door AI te doen. Maar juist voor de zaken die je zelf niet goed beheerst is het goed om het _juist_ zelf te doen. Hier leer je veel meer van en onthoud je het ook beter. Vergelijk het met het ouderwetse schrijven van woordjes zodat je het beter onthoudt.

Ik denk dat het belangrijk is om beide bovenstaande facetten goed (h)erkennen in je dagelijkse werkzaamheden. Kies bewust wat je hier mee wilt doen.

[Zorg]

@Gr4mpyC3t dat klopt, binnen de teams waar ik werk (ok geen software development maar meer data) ben ik veruit de zwakste schakel. Maar het werkt wel, binnen de tijd die we hebben. Kan het beter? Zeker! Zelfs als ik het zelf zou herschrijven zou ik het kunnen verbeteren. Maar dat het technisch beter kan, betekent niet persé dat dat ook nodig is. In mijn vak, een stuk slechte code loopt een uurw geoptimaliseerd misschien een half uur. Maar de code draait in de nacht waarbij we 8 uur hebben. Dat het technologisch beter kan betekent niet dat het nodig is

Zo zie ik LLM code ook, kan het beter? Misschien wel, maar als het doet wat moet, binnen de tijden en grenzen van wat geaccepteerd wordt. Wat is dan de echte meerwaarde?

[Gr4mpyC3t]

Zorg schreef op vrijdag 25 september 2026 @ 23:24:
@Gr4mpyC3t dat klopt, binnen de teams waar ik werk (ok geen software development maar meer data) ben ik veruit de zwakste schakel. Maar het werkt wel, binnen de tijd die we hebben. Kan het beter? Zeker! Zelfs als ik het zelf zou herschrijven zou ik het kunnen verbeteren. Maar dat het technisch beter kan, betekent niet persé dat dat ook nodig is. In mijn vak, een stuk slechte code loopt een uurw geoptimaliseerd misschien een half uur. Maar de code draait in de nacht waarbij we 8 uur hebben. Dat het technologisch beter kan betekent niet dat het nodig is

Zo zie ik LLM code ook, kan het beter? Misschien wel, maar als het doet wat moet, binnen de tijden en grenzen van wat geaccepteerd wordt. Wat is dan de echte meerwaarde?

Ja eens hoor. Lijkt me niets op tegen. Ik doe het zelf ook. Had afgelopen week een VM nodig om wat software te testen in Docker. Zonde om tijd te besteden aan die Docker setup, het ging mij om de software. Heerlijk dat je dan die tijd bespaard en aan de slag kan met waar het eigenlijk om gaat.

Het gaat mij vooral om de complexe systemen en infrastructuur. Ik moet er bijvoorbeeld niet aan denken dat een webshop, verzekeraar of telco een mobiele app gaat vibe coden. Dat is vragen om problemen.

[Keipi]

Zorg schreef op vrijdag 25 september 2026 @ 22:23:
[...]


Als de code doet wat het moet doen, wat valt er dan op te lossen?
Spaghetti code heb ik ook veelal gehoord voor het LLM tijdperk gemaakt door programmeurs van vlees en bloed.

Zeker, en de spaghetti code van de één creëert werkgelegenheid voor de ander! Daarom ook mijn standpunt dat er weinig zal veranderen.

En, “als code doet wat het moet doen, wat valt er dan op te lossen?”: dat was voor het LLM tijdperk ook een discussie, met mensen aan beide kanten. Net alsof er weinig veranderd is met een LLM erbij

[Zorg]

Gr4mpyC3t schreef op vrijdag 25 september 2026 @ 23:44:
[...]

Het gaat mij vooral om de complexe systemen en infrastructuur. Ik moet er bijvoorbeeld niet aan denken dat een webshop, verzekeraar of telco een mobiele app gaat vibe coden. Dat is vragen om problemen.

Is dat zo? Als mensen met voldoende systeemkennis en capabel genoeg zijn om te beoordelen of het goed is, waarom zou dat niet kunnen? Met een goeie review op gebied van security en processes, waarom zou je dat niet kunnen vibe coden maar wel bijvoorbeeld kunnen uitbesteden aan een team in India (om maar een veelvoorkomende route te benoemen)

[JJ Le Funk]

bloody schreef op vrijdag 25 september 2026 @ 23:21:
De verleiding is heel groot om maar alle voorstellen van je agent te accepteren. Immers, hij zal het wel weten. Als je dit bij jezelf merkt, ben je op weg om een meat proxy te worden. Vraag je af of je dit wel wilt voor jezelf.
[...]

product zal (eerst onzichtbaar) steeds verder gaan driften van de oorspronkelijk bedoelde werking en steeds meer helpers en functies gaan tanken voor nutteloze doeleinden. AI is te kortzichtig en moet je blijven wijzen op het ontwerp èn de visie achter het ontwerp, ook al waren die md-files al ingelezen aan het begin van de sessie.

[ Voor 6% gewijzigd door JJ Le Funk op 26-09-2026 07:23 ]

[CrazyFool]

Ik zie het in mijn team ook gebeuren: garbage in, garbage out. Voorheen had ik zelf nog de controle over mijn team. Junioren die zelf code schreven en veel fouten of verkeerde keuzes maakten, kon ik nog bijsturen tijdens het proces.

Maar nu krijg ik PR's die al direct volledig geïmplementeerd zijn, maar waarvan de basis echt absoluut niet oké is. Wat ik merk, is dat ze Claude zien als een superieure programmeur. Doordat bij junioren de echte kennis van abstractie, design patterns en architectuur nog ontbreekt, nemen ze echter alles klakkeloos over.

Ik zit zelf inmiddels ruim 20 jaar in het vak en vind architectuur echt het mooiste wat er is. Met Claude kan ik mij daarop focussen. Ik kijk niet letterlijk meer naar elke regel output, maar je moet er wel bovenop blijven zitten. Want driften is echt wel aanwezig.

De ontwikkel snelheid is absoluut omhoog gegaan, maar de kwaliteit van de code en de verschillende processen zoals reviewen zijn op dit moment de grootste bottlenecks.

[Gr4mpyC3t]

Zorg schreef op vrijdag 25 september 2026 @ 23:53:
[...]


Is dat zo? Als mensen met voldoende systeemkennis en capabel genoeg zijn om te beoordelen of het goed is, waarom zou dat niet kunnen? Met een goeie review op gebied van security en processes, waarom zou je dat niet kunnen vibe coden maar wel bijvoorbeeld kunnen uitbesteden aan een team in India (om maar een veelvoorkomende route te benoemen)

Ik weet eerlijk gezegd niet of dat echt zo is, maar de experimenten die ik zelf met AI doe, raak ik in ieder geval het overzicht kwijt. De modellen zijn tegenwoordig zo zelfstandig, dat ze sneller schrijven dan dat ik het kan beoordelen.

Mijn onderbuikgevoel zegt dan dat het verleidelijk is voor ons als mensen om geitenpaadjes te nemen en te denken dat het dan wel goed zit. Maar toegegeven, dat is mijn eigen ervaring.

En sure, uitbesteden aan India vind ik ook wat van.

[Zorg]

@Gr4mpyC3t daarvoor hebben we geen perfecte definitie van wat goed is. Maar vanuit de gebruiker gezien: als het werkt en het doet wat het moet doen, dan is het goed. Ok security is natuurlijk moeilijker te beoordelen maar als er niemand bij kan die er niet bij moet, dan is het goed.

Dat kan anders zijn vanuit een programmeur zijn/haar visie natuurlijk. Daar denk ik dat programmeurs over het algemeen gezien het wellicht nog beter en optimaler kunnen maken, maar of dat altijd nodig is?

[Stukfruit]

Als je begint met iets om video's af te spelen en je eindigt met software om de hond uit te laten omdat er een video met een hond voorbijkwam dan heb je de definitie van goed al gebroken toch?

De "eigen" reasoning van de agent wordt meegenomen als input. Dat het ding soms in de war raakt en "denkt" dat jij iets als context hebt meegegeven en plotseling tussendoor "dat is een goed idee!" roept is een feature door hoe het spul werkt en geen ongelukje (of zelfbewustzijn ).

Bijbehorend resultaat kun je inderdaad wegzetten als goed genoeg. Succes met de hondenuitlaatservice

[Stukfruit]

Gr4mpyC3t schreef op zaterdag 26 september 2026 @ 08:37:
[...]

Ik weet eerlijk gezegd niet of dat echt zo is, maar de experimenten die ik zelf met AI doe, raak ik in ieder geval het overzicht kwijt. De modellen zijn tegenwoordig zo zelfstandig, dat ze sneller schrijven dan dat ik het kan beoordelen.

Maar gesprekken met een agent voeren, alles lezen en het ook nog eens aansturen alsof je Leisure Suit Larry aan het spelen bent is sowieso niet erg productief

Ik heb in m'n systeemprompts standaard staan dat het bijvoorbeeld "absolutely critical" is om geen vragen te stellen en deze "zelf" te beantwoorden op basis van beschikbare context tenzij een combinatie van gewenste zaken echt onmogelijk is. Anders ga je daar op reageren met net iets andere input en hoppa, nóg meer vragen, terwijl je het eerder al duidelijk had opgeschreven en de vragen nergens voor nodig zijn. En met wat pech komen daar nog meer vragen uit omdat je vermoeid raakt.

Daarna laten werken en standaard forceren om bevindingen te baseren op echte data. Duurt een beetje langer en je moet soms even het OCD-gevoel om bij te sturen laten gaan, maar spaart op de langere termijn tijd. Als het resultaat niet klopt doe je git revert en is de foutieve code of architectuur de info die je nodig hebt voor verbetering ipv de proza.

Op die manier ben je meer bezig met het lezen van (en als gevolg van de werkwijze: kleinere stukken) code. Veel sneller als je er ervaring mee hebt en geeft meer overzicht.

[wiemelen]

Zorg schreef op zaterdag 26 september 2026 @ 09:14:
@Gr4mpyC3t daarvoor hebben we geen perfecte definitie van wat goed is. Maar vanuit de gebruiker gezien: als het werkt en het doet wat het moet doen, dan is het goed. Ok security is natuurlijk moeilijker te beoordelen maar als er niemand bij kan die er niet bij moet, dan is het goed.

Dat kan anders zijn vanuit een programmeur zijn/haar visie natuurlijk. Daar denk ik dat programmeurs over het algemeen gezien het wellicht nog beter en optimaler kunnen maken, maar of dat altijd nodig is?

Naast security, heb je natuurlijk ook nog vele andere (verborgen) aspecten die je op het 1ste zicht niet ziet, maar die wel aanwezig moeten zijn als je een solide, goed presterend systeem wil hebben. Ik denk dan aan :

• Performance : Net vorige week een rapport van mijn "zeer ervaren collega" kunnen tweaken van 20m looptijd naar onder 1 minuut. Wat een slimme opzet en handigheidjes al niet kunnen doen, waar AI niet aan gedacht had.
• Gebruiksvriendelijkheid : hoe kan je er voor zorgen dat een gebruiker op een zo slim mogelijke manier alle informatie ter beschikking heeft om zijn/ haar werk te doen. Om vervolgens met zo min mogelijk klikken of tabben een proces af te ronden. Zeker als je werkt met bijvb. call centers waar snelheid ook belangrijk is. In het verleden heb ik wel eens programmatuur moeten schrijven die door een call center medewerker gebruikt werd. Vereiste van het management was dat ieder van hun processen met maximum 3 muisklikken moest af te ronden zijn.
• Passend in een architectuur : Goed nadenken hoe je iets opzet, zodat alle/veel logica dezelfde look en feel krijgt. Waar mogelijk gebruik maken van herbruikbare, generieke (custom) componenten. Kost soms wat tijd/moeite, zeker om een manager te overtuigen, maar heb je achteraf enorm veel profijt aan. Dit is iets waar AI (vooralsnog) weinig tot geen rekening mee houdt én waar je je zelf pas achter komt door jaren ervaring/frustraties omdat (veelal) externe consultants hier geen kaas van hebben gegeten of niet willen (hoe meer code ze moeten schrijven, hoe meer uren ze kunnen declareren)
• Gedegen foutafhandelingsproces : Vaak volledig over het hoofd gezien, slecht ingericht, slecht te monitoren of men komt er veel te laat achter. Zo was het ook toen ik in 2017 bij mijn klant (nu werkgever) begon. Nu zoveel jaar later, durf ik te beweren dat we 95% van de processen/fouten onmiddelijk kunnen detecteren en notificaties hiervoor uitzetten (via mail, workflow of dashboard). Voor 90% van de uitval is ook een handleiding of geautomatiseerde oplossing ingericht. En allemaal weer opnieuw met eenzelfde look & feel en gebruiksvriendelijkheid. Meeste hiervan komt uit mijn hoofd, door de ervaring die ik de afgelopen 25 heb kunnen opdoen.
• Eenvoudig aan te passen : Ook een veelvoorkomende fout is dat code te specifiek of nog erger zonder nadenken geschreven wordt. Alsof processen, wetgeving of software in de loop der jaren niet kunnen veranderen. Als er dan iets moet aangepast worden, heb ik meermaals moeten vaststellen dat er een dusdanige impact op de code is, dat je beter van nul af aan de oplossing opnieuw opbouwt.
• Last but not least, een beetje fierheid in het werk dat je oplevert. Ik zou niet graag hebben dat er in de toekomst iemand code van mij moet aanpassen of analyseren en dat die persoon tot de conclusie moet komen "wat heeft deze prutser hier allemaal uitgespookt"? Persoonlijk heb ik die conclusie wel al over de code van andere programmeurs moeten trekken. Veel liever zou ik aangenaam verrast willen worden over logica of code, waarvan ik zelf ook niet iets kon bijleren.

[ari3]

wiemelen schreef op zaterdag 26 september 2026 @ 11:58:
[...]

Naast security, heb je natuurlijk ook nog vele andere (verborgen) aspecten die je op het 1ste zicht niet ziet, maar die wel aanwezig moeten zijn als je een solide, goed presterend systeem wil hebben.

De verborgen of niet-functionele aspecten zul je in je instructies aan de AI expliciet moeten maken alsook de manier waarop deze aspecten (geautomatiseerd) gevalideerd kunnen worden.

Performance

De toekomst is dat de AI vertelt wat de performance moet zijn. Dat wil zeggen: specificeer volume en minimale verwerkingstijden. Ga niet vertellen HOE dat bereikt moet worden want dat levert geen waarde op. Je wilt geen code of deployment-modellen reviewen om te controleren of de gewenste performance bereikt kan worden. Je wilt slechts toetsen of aan de specificatie voldaan wordt.

Passend in een architectuur

Architectuur is alleen noodzakelijk als leidraad voor mensen als zij zelf de bouwer van een applicatie zijn. Als je geen code genereert heb of niet zelf de exploitatie-infrastructuur inregelt heb geen architectuur nodig. Als het resultaat voldoet aan de eisen dan is het goed.

Gedegen foutafhandelingsproces

Foutafhandeling zijn alternatieve executiepaden in de functionele eisen aan een applicatie en de exploitatie-omgeving. Die neem je dus gewoon mee in de specificatie voor de AI.

Eenvoudig aan te passen

Niet relevant als er geen code gegenereerd wordt. Wel relevant in de zin dat de instructies aan de AI eenvoudig aan te passen moeten zijn. Merk op dat de instructies aan een AI in natuurlijke taal vooral handig is voor mensen, net als programmeertalen vooral handig zijn voor mensen. Een AI heeft geen natuurlijke taal of programmeertaal nodig als modellering van de context. Een AI heeft zijn eigen interne model. Mogelijk dat in de toekomst er een AI-gerichte taal komt zodat de ambiguïteit van natuurlijke taal vermeden kan worden. Of dat natuurlijke taal zelf evolueert naar een vorm met minder ambiguïteit.

Last but not least, een beetje fierheid in het werk dat je oplevert.

Tsja, de fierheid zal in de toekomst komen uit het juist instrueren van de AI om het gewenste resultaat te krijgen. Als geen code genereerd wordt, zijn codeerstandaarden en best practices geen overweging meer.

AI heeft de kennis en ervaring van de beste vakmensen tot zich genomen en kan deze op schaal toepassen, maar deze kennis is alleen nodig in de transitiefase waar we nu inzitten. De AI-native manier van werken maakt het genereren van code, gebruik van compilers, toepassing van architectuurprincipes, cloud deployment descriptors, enz. allemaal overbodig. We zullen zeer binnenkort op een niveau zitten dat Al deze zaken kan abstraheren zodat mensen zich puur met functionele en niet-functionele eisen aan applicatie kunnen bezig houden.

[Wozmro]

We zijn heel erg gewoon dat programmeren iets is dat je doet via een toetsenbord. En we gaan er vanuit dat je met en door AI dan gaat programmeren door middel van prompts.

Maar AI kan ook code genereren rechtstreeks vanuit een foto, videobeelden, data uit sensoren,...

Het lijkt mij nog niet zo simpel om als mens dergelijke code dan te begrijpen en te valideren.

[ZpAz]

Imho is juist de aanpak om eerst garbage te maken. Prototyping, daardoor kan je juist over de structuur nadenken. Je moet niet je eerste pass constant proberen aan te passen. Door prototypes the maken kan je er juist achter komen wat je wel of niet nodig hebt, wat waarschijnlijk beter kan etc. Die prototypes gooi je weg.

Op basis daarvan kan je een veel exactere definitie schrijven als prompt. En daar kan je dan gaan reviewen. Normaal immers, pre LLM. Kwam je er ook altijd pas achter wat 'nu exact nodig was' wanneer je al aan het werk geslagen was en je tegen meerdere punten aanliep die je misschien niet had voorzien.

Daarna standaard workflows die agents opspinnen voor een eerste review pass - die performance, security etc doen. Controleren of het wel aan je gedefineerde standaarden voor 'code' voldoet. (Dat plus linting etc natuurlijk, standaard CVE checks this that).

En natuurlijk het belangerijkste, je belangerijkste product wat je nu maakt is eigenlijk het framework om je AI heen.

[ Voor 25% gewijzigd door ZpAz op 26-09-2026 18:11 ]

[wiemelen]

ari3 schreef op zaterdag 26 september 2026 @ 17:33:
De toekomst is dat de AI vertelt wat de performance moet zijn. Dat wil zeggen: specificeer volume en minimale verwerkingstijden. Ga niet vertellen HOE dat bereikt moet worden want dat levert geen waarde op.

Precies toch wel als mijn code veel sneller blijkt te zijn dan de gegenereerde code. Hangt dat af van de kwaliteit en detailniveau van de prompt? Mogelijk wel, maar als een toekomstige (junior) programmeur niet de kennis heeft van wat mogelijk is of hoe je zoiets moet/kan formuleren, blijf je uiteindelijk toch zitten met je niet-performante code waarvan je zelf niet weet dat het beter/sneller kan.

AI heeft de kennis en ervaring van de beste vakmensen tot zich genomen en kan deze op schaal toepassen, maar deze kennis is alleen nodig in de transitiefase waar we nu inzitten.

Dat is een aanname, en ik werk niet met aannames, enkel met feiten. AI kan inderdaad code opleveren, maar de kwaliteit varieert enorm. Soms kan je bijna 100% kopiëren, soms moet je x-maal dieper vragen om het uiteindelijk toch maar grotendeels zelf te maken. Ik durf eerder beweren dat "AI heeft kennis tot zich genomen, waaronder pure theoretische kennis en praktische kennis. De bron en kwaliteit van de praktische kennis kunnen we niet verifiëren. Daarnaast weet iedere programmeur dat programmeren puur op basis van theorie niet altijd tot een goede/betere oplossing oplevert. We gebruiken allemaal oplossingen/code snippets/werkwijzes die afwijken van de theorie, maar in praktijk beter werken.

[ZpAz]

wiemelen schreef op zaterdag 26 september 2026 @ 18:49:
[...]

Precies toch wel als mijn code veel sneller blijkt te zijn dan de gegenereerde code. Hangt dat af van de kwaliteit en detailniveau van de prompt? Mogelijk wel, maar als een toekomstige (junior) programmeur niet de kennis heeft van wat mogelijk is of hoe je zoiets moet/kan formuleren, blijf je uiteindelijk toch zitten met je niet-performante code waarvan je zelf niet weet dat het beter/sneller kan.

Je specifeert je doel Je geeft het de tools om te meten (flamegraphs / traces etc), en je hebt al tests om de feature spec te behouden. Tegen llm 'get crankin'. (Met /goal en een ietwat specifiekere prompt)

AI heeft de kennis en ervaring van de beste vakmensen tot zich genomen en kan deze op schaal toepassen

Stack Overflow en Reddit zit ook in de trainings data

[ Voor 15% gewijzigd door ZpAz op 26-09-2026 19:14 ]

[RooT]

wiemelen schreef op zaterdag 26 september 2026 @ 18:49:
Dat is een aanname, en ik werk niet met aannames, enkel met feiten. AI kan inderdaad code opleveren, maar de kwaliteit varieert enorm. Soms kan je bijna 100% kopiëren, soms moet je x-maal dieper vragen om het uiteindelijk toch maar grotendeels zelf te maken. Ik durf eerder beweren dat "AI heeft kennis tot zich genomen, waaronder pure theoretische kennis en praktische kennis. De bron en kwaliteit van de praktische kennis kunnen we niet verifiëren. Daarnaast weet iedere programmeur dat programmeren puur op basis van theorie niet altijd tot een goede/betere oplossing oplevert. We gebruiken allemaal oplossingen/code snippets/werkwijzes die afwijken van de theorie, maar in praktijk beter werken.

Dat is met de huidige modellen inderdaad zo. Maar als je ziet hoe ongelooflijk snel de ontwikkelingen gaan, ben ik benieuwd hoe dat over een paar jaar is. AI kan op een gegeven moment ook creatiever worden natuurlijk.

[Sissors]

wiemelen schreef op zaterdag 26 september 2026 @ 18:49:
[...]

Precies toch wel als mijn code veel sneller blijkt te zijn dan de gegenereerde code. Hangt dat af van de kwaliteit en detailniveau van de prompt? Mogelijk wel, maar als een toekomstige (junior) programmeur niet de kennis heeft van wat mogelijk is of hoe je zoiets moet/kan formuleren, blijf je uiteindelijk toch zitten met je niet-performante code waarvan je zelf niet weet dat het beter/sneller kan.

Voor een embedded opensource project heb ik ooit een interrupt handler significant versneld door een stuk C code te vervangen door een inline assembler functie. Naar aanleiding van jouw post eens gekeken wat (gratis) ChatGPT doet: Exact diezelfde functie. Met wat Googlen blijkt dat dat (tegenwoordig iig) een redelijk standaard methode is geworden, maar alsnog verwacht ik niet dat de meeste junior programmeurs in de ARM instructieset duiken.

En natuurlijk dit is een N=1 voorbeeld, maar als ik kijk hoeveel code ronduit ruk is, blijf ik ietwat hoop houden dat AI dit kan verbeteren, ook bijvoorbeeld door automatisch te porten naar efficientere talen.

[CVTTPD2DQ]

Mijn vrees is nu dat AI voor een omwenteling in het securitylandschap gaat zorgen. Het was altijd bekend dat bijna elk stuk software vol zit met securityproblemen; het ontbrak vooral aan mensen met specialistische kennis en (belangrijker!) geduld om ze aan het licht te brengen.

Dat is nu opgelost. AIs lijken ook niet zoveel moeite hebben met het lezen van gecompileerde software (gewoon een ander soort symbolen). Dus daar ga je, een hele hoop zaken die een paar maanden nog "veilig genoeg" waren, zijn nu in principe te hacken door AI.

Er is niets wat een kwaadwillende persoon (of overheid, het is immers hommeles in de wereldpolitiek) verhindert om een AI gelijktijdig honderden systemen te laten scannen. Tijd en tokens zijn de beperkende factor geworden.

En de vervolgstap is natuurlijk het verplicht wordt gemaakt om een AI code te laten scannen op vulnerabilities, ofwel via ISO best practices, of iets als de EU CRA. Je kunt dan zelf uittekenen hoe dat verder gaat.

Over een paar jaar vinden we het misschien compleet onverantwoordelijk om door mensen geschreven software te gebruiken. Dat is dan een soort asbest, waar je als organisatie zo snel mogelijk vanaf wil.

[Zorg]

wiemelen schreef op zaterdag 26 september 2026 @ 18:49:
[...]

Precies toch wel als mijn code veel sneller blijkt te zijn dan de gegenereerde code. Hangt dat af van de kwaliteit en detailniveau van de prompt? Mogelijk wel, maar als een toekomstige (junior) programmeur niet de kennis heeft van wat mogelijk is of hoe je zoiets moet/kan formuleren, blijf je uiteindelijk toch zitten met je niet-performante code waarvan je zelf niet weet dat het beter/sneller kan.

Ik had een junior in mijn team die een stuk code had geoptimaliseerd, voorheen draaide het 1h, nu 10min. Daar was hij een paar dagen mee bezig geweest. De code loopt snachts en heeft een window van 8h om te runnen.....
Denk dat het beter is om juniors wat meer businesslogica te leren, geldt ook voor veel seniors overigens

Overigens wel leuk, in je vorige quote met alle zaken die er ook bij software development behoren (overigens helemaal mee eens) komt daadwerkelijk code kloppen pas als laatste

[Gr4mpyC3t]

Zorg schreef op zondag 27 september 2026 @ 18:50:
[...]

Ik had een junior in mijn team die een stuk code had geoptimaliseerd, voorheen draaide het 1h, nu 10min. Daar was hij een paar dagen mee bezig geweest. De code loopt snachts en heeft een window van 8h om te runnen.....
Denk dat het beter is om juniors wat meer businesslogica te leren, geldt ook voor veel seniors overigens

Overigens wel leuk, in je vorige quote met alle zaken die er ook bij software development behoren (overigens helemaal mee eens) komt daadwerkelijk code kloppen pas als laatste

Of heeft de junior nu geleerd hoe het proces werkt en is de optimalisatie daar de bevestiging van?

[Zorg]

@Gr4mpyC3t Tuurlijk leerde hij er van, maar eind van de dag was het gewoon een stuk code die deedt wat moest, alleen kon het efficiënter.
Ik had het origineel geschreven

[wiemelen]

Zorg schreef op zondag 27 september 2026 @ 18:50:
[...]
Denk dat het beter is om juniors wat meer businesslogica te leren, geldt ook voor veel seniors overigens

Ik wil als developer altijd betrokken worden bij de analyse. Dit geeft mij de kans om de requirements en logica te begrijpen en de grote lijnen ervan neer te schrijven. Het is ook het beste moment om vragen te stellen vanuit technisch oogpunt, die anders pas naar voren zouden komen tijdens de ontwikkeling. Soms leiden die vragen, technisch inzicht en ervaring tot hele andere oplossingen dan men eerst voor ogen had. Maar meesral winnen we gewoon tijd tijdens het ontwikkelen en vermijden we dat er dingen opnieuw moeten gedaan worden of live gaan terwijl er ondertussen al een technical dept story achterna komt.

Overigens wel leuk, in je vorige quote met alle zaken die er ook bij software development behoren (overigens helemaal mee eens) komt daadwerkelijk code kloppen pas als laatste

Klopt ook in mijn geval denk ik. Een collega van mij omschrijft zichzelf als programmeur. Hij denkt in termen van "Zeg mij maar exact wat ik moet doen, en dan doe ik dat. Maar laat me vooral niet mee nadenken". Als dat je ding is prima, maar er zijn programmeurs in lage loonlanden die dit beter en sneller kunnen ... en AI kan dit ondertussen ook al ( met wisselende kwaliteit), maar zal dit in de toekomst zeker nog veel beter kunnen.

Zoals eerder gezegd, ben ik zelf betrokken bij veel analyses, zeker als er geprogrammeerd moet worden, maar daarnaast hou ik me ook bezig met de technische architectuur en inrichting van het systeem, ga ik regelmatig samenzitten met eindgebruikers om te zien waar we hun taken kunnen ondersteunen of gebruiksvriendelijker kunnen maken, ik begeleid mijn collaga's, maak handleidingen, help mee in de planning, doe mijn deel van het OPS werk ... en o ja, ik programmeer zelf ook nog 🙂. Ik schat dat ik op jaarbasis "slechts" zo'n 35-40% van de tijd besteed aan programmeren. Ter vergelijking, mijn directe collega's besteden gemiddeld zo'n 80-85% van hun tijd aan programmeren. Dus ja, al ben ik in theorie een programmeur, code kloppen is maar een klein, maar nog steeds leuk, deel van mijn werkzaamheden.

[eric.1]

CVTTPD2DQ schreef op zondag 27 september 2026 @ 18:43:
Over een paar jaar vinden we het misschien compleet onverantwoordelijk om door mensen geschreven software te gebruiken. Dat is dan een soort asbest, waar je als organisatie zo snel mogelijk vanaf wil.

De vraag is vooralsnog of de kwaliteit van AI-output standaard hoger kan worden dan die van de gemiddelde (maar serieuze) ontwikkelaar. Waar heeft AI tot op heden van geleerd? Ons mensenwerk. Dat betekent ook dat ons niveau is overgenomen. Want echt denk-werk zit er gewoon niet in (aan de AI zijde) en ondanks de leuke termen van AGI...eh...ik druk op [x].

Dan kan je natuurlijk wél gelijktijdig wat agents laten draaien om de oplossingen te testen, waar AI wel erg goed in is. Maar of je dan degelijke oplossingen krijgt? Vooralsnog raakt AI geregeld in de war of eindigt het in een cirkel.

Hoe gaat AI die sprong omhoog maken, puur naar kwaliteit kijkende? Ik zie het niet zo snel voor me. Sterker nog, er komt nu heel veel meuk de markt op - gemaakt met en door AI. Als AI daar van gaat leren ... dan mogen we ons borst nog nat maken - hopend dat mensen blijven reviewen en daar de kennis voor blijft houden ...(waar we trouwens bijzonder slecht in zijn ...).

[Glashelder]

Ik kan me niet aan de indruk onttrekken dat er hier aan de kant van software developers sprake is van wat wens denken als ik lees dat er geen denk werk in zit aan de kant van AI.

Of jullie gebruiken modellen van jaren geleden of het wordt niet goed gebruikt, want ik zie hier AI toch echt wel serieus meedenken. En ik kom zelden tot nooit in een loop.

Ik laat hier Opus grotendeel het codingwerk doen en het reviewwerk laat ik over aan Astra. Dat levert prima resultaten op, waarbij Astra geregeld gaten in de plannen vind en fixt alsook fouten in de code van Opus fixt.

[defiant]

Het ontbrekende concept in de AI ontwikkelingen is imho het abstracte begrip kwaliteit, hier hebben we als mensen zelf vaak ook nog onvoldoende vat op. De meeste mensen kunnen aanvoelen of iets kwaliteit heeft, maar het is erg moeilijk om te bevatten in formele regels. En als het niet te bevatten is in formele regels, dan is het ook moeilijk voor een AI.

Je ziet dit het duidelijkste terug aan de meer creatieve aspecten waarin AI wordt gebruikt, het is vaak pas kwaliteit als een mens het heeft beoordeeld en bijgestuurd. AI kan nog niet creatieve media produceren en hier ook zelf uitspraken over doen of dit kwaliteit heeft.

De software wereld is wat abstracter en formeler, dus je ziet ook dat AI hierin verschillende zaken makkelijker kan analyseren/produceren. Maar ook hierin kent de AI niet het abstracte begrip van kwaliteit zodra het verder gaat dan formele kwaliteitsregels, is het software product ook gebruiksvriendelijk, doet het ook echt wat het moet doen.

Ik zie hierin de scheidslijn op het gebied van creativiteit, ik denk dat business software dat voornamelijk draait om data verwerking/business rules/etc om dit moment het domein is waarin AI veel werk kan overnemen. Zoals kantoorautomatisering ook al de eerst plek was waarin de ICT haar intrede deed, mensen die formele regels en procedures met informatie/data afhandelen zijn een van de geschikte banen om te automatiseren. Nu ook het development werk zelf.

Maar hoe creatiever het wordt, des te meer komt de mens zelf in de loop kijken. Iedereen kan nu met AI een game "one shotten", maar is het dan ook nog wel een leuk spel? Veel van de tijd van game development gaat zitten in play testing, dat is een proces wat een AI niet kan vervangen.

Overigens zag je dit concept ook terug in science fiction voorspellingen, AI wordt veelal afgebeeld als een AGI/ASI, maar zonder creativiteit of emoties.

[Gr4mpyC3t]

Glashelder schreef op zondag 27 september 2026 @ 20:49:
Ik kan me niet aan de indruk onttrekken dat er hier aan de kant van software developers sprake is van wat wens denken als ik lees dat er geen denk werk in zit aan de kant van AI.

Of jullie gebruiken modellen van jaren geleden of het wordt niet goed gebruikt, want ik zie hier AI toch echt wel serieus meedenken. En ik kom zelden tot nooit in een loop.

Ik laat hier Opus grotendeel het codingwerk doen en het reviewwerk laat ik over aan Astra. Dat levert prima resultaten op, waarbij Astra geregeld gaten in de plannen vind en fixt alsook fouten in de code van Opus fixt.

Er zit ook wel denkwerk, maar dat gebeurt op basis van die formele kwaliteitsregels zoals @defiant dat zo mooi omschrijft.

Ik krijg ook Opus 5.5 niet in het gareel om logische interfaces te maken. Bijvoorbeeld, het blijft maar knoppen in een menu erbij kwakken voor iedere webpagina die ik erbij vraag.

Het kan kennelijk niet bedenken dat de menustructuur daardoor letterlijk uit de pagina loopt, zelfs niet als ik het bijstuur met verwijzingen naar best practices.

De code werkt dus fantastisch, maar het snijdt logisch gezien geen hout.

[Orangelights23]

Gr4mpyC3t schreef op zondag 27 september 2026 @ 23:30:
[...]

Er zit ook wel denkwerk, maar dat gebeurt op basis van die formele kwaliteitsregels zoals @defiant dat zo mooi omschrijft.

Ik krijg ook Opus 5.5 niet in het gareel om logische interfaces te maken. Bijvoorbeeld, het blijft maar knoppen in een menu erbij kwakken voor iedere webpagina die ik erbij vraag.

Het kan kennelijk niet bedenken dat de menustructuur daardoor letterlijk uit de pagina loopt, zelfs niet als ik het bijstuur met verwijzingen naar best practices.

De code werkt dus fantastisch, maar het snijdt logisch gezien geen hout.

Hoe zien de project rules en je guardrails eruit? Na elke iteratie werk je je main files bij om exact dit soort dingn te voorkomen.

[CVTTPD2DQ]

Glashelder schreef op zondag 27 september 2026 @ 20:49:
Ik kan me niet aan de indruk onttrekken dat er hier aan de kant van software developers sprake is van wat wens denken als ik lees dat er geen denk werk in zit aan de kant van AI.

Je zou kunnen zeggen dat AI geen keuzes maakt. Een LLM schrijft net zo gemakkelijk een computerspelletje in javascript als een spreadsheet in C++ - Iemand zal nog steeds moeten bepalen wat er gemaakt moet worden, en iemand zal nog steeds op een of andere manier moeten valideren of het gemaakte klopt met wat er gevraagd is.

De vraag is alleen een beetje op welk niveau dat moet gebeuren. Als je je tot in details bezig houdt met de implementatie - omdat je dat zo gewend bent - zie je genoeg dingen die niet goed zijn aan wat de AI produceert. Maar is dat het niveau waarop je moet specificeren en valideren?

Ik denk dat het veel logischer is dat het uiteindelijk op functioneel niveau gebeurt. Dat je vraagt om een stuk software, en dat de LLM zelf wel bepaalt of het javascript of C++ moet zijn. Welke database, wat het schema moet zijn, enz.

[eheijnen]

CVTTPD2DQ schreef op dinsdag 29 september 2026 @ 00:51:
[...]

Iemand zal nog steeds moeten bepalen wat er gemaakt moet worden...

Dit kun je ook stellen over developers. Er is geen enkele developer die op alle ideeën/wensen van anderen kan komen. Die hebben ook input nodig.

[Wozmro]

Daarin zie ik wel een meerwaarde van programmeren met hulp van AI.

Pakweg een schrijnwerker kan een idee hebben en daar met AI iets mee fabriceren om enig idee te krijgen of en hoe het zou kunnen werken visueel, functioneel,...

En als er potentieel blijkt in te zitten naar een programmeur stappen om het verder uit te werken. Die zal dan waarschijnlijk op gebied van code zo goed als opnieuw moeten beginnen. Maar zal wel een beter beeld hebben van waar de schrijnwerker naar toe wil?

[ouweklimgeit]

Gr4mpyC3t schreef op zondag 27 september 2026 @ 23:30:
[...]

Er zit ook wel denkwerk, maar dat gebeurt op basis van die formele kwaliteitsregels zoals @defiant dat zo mooi omschrijft.

Ik krijg ook Opus 5.5 niet in het gareel om logische interfaces te maken. Bijvoorbeeld, het blijft maar knoppen in een menu erbij kwakken voor iedere webpagina die ik erbij vraag.

Het kan kennelijk niet bedenken dat de menustructuur daardoor letterlijk uit de pagina loopt, zelfs niet als ik het bijstuur met verwijzingen naar best practices.

De code werkt dus fantastisch, maar het snijdt logisch gezien geen hout.

Maar daar is Opus ook niet voor bedoeld, voor interfaces en visuele zaken gebruik je bijvoorbeeld Claude Design, die kan de meest waanzinnige layouts maken, inclusief handoff voor 'normale' agents om ermee aan de slag te gaan. Ik heb volledige iOS/Android apps, websites en PWA's op die manier laten ontwerpen waar elk knopje op de logische plek terechtkomt.

[CVTTPD2DQ]

eheijnen schreef op dinsdag 29 september 2026 @ 06:46:
Dit kun je ook stellen over developers. Er is geen enkele developer die op alle ideeën/wensen van anderen kan komen. Die hebben ook input nodig.

Dat is precies wat ik bedoel. Is die developer nog wel zo'n nuttige toevoeging? Why not skip the middleman?

[RooT]

CVTTPD2DQ schreef op dinsdag 29 september 2026 @ 09:20:
[...]


Dat is precies wat ik bedoel. Is die developer nog wel zo'n nuttige toevoeging? Why not skip the middleman?

Dat zie je nu al deels gebeuren met kantoor automatisering. Ik las laatst een artikel van een technisch directeur van een metaalbedrijf. Hij zei dat hij met AI zijn eigen ERP systeem heeft gemaakt. Dat zal uiteraard niet van SAP formaat zijn, maar vaak hebben kleine bedrijven ook maar basis functionaliteit nodig, maar wel toegespitst op hun processen.

Hij gaf ook aan dat hij nu veel sneller klaar is, want om al zijn ideeën eerst met een developer te bespreken, hopen dat die het snapt, software maakt, test en die hele loop tig keer moet doorlopen.

Bottom line is dus ja, dat gebeurt al. Maar dat geld voor software voor eigen gebruik. Software die nog echt verkocht wordt, waar support op zit, of beveiligingsaspecten, of enorm schaalbare software zie ik dat nog niet echt gebeuren. Daar is meer kennis van nodig dan wat AI op dit moment bezit. Dus daar zit waarschijnlijk de toegevoegde waarde in, domeinkennis.

[Gr4mpyC3t]

RooT schreef op dinsdag 29 september 2026 @ 09:34:
[...]

Dat zie je nu al deels gebeuren met kantoor automatisering. Ik las laatst een artikel van een technisch directeur van een metaalbedrijf. Hij zei dat hij met AI zijn eigen ERP systeem heeft gemaakt. Dat zal uiteraard niet van SAP formaat zijn, maar vaak hebben kleine bedrijven ook maar basis functionaliteit nodig, maar wel toegespitst op hun processen.

Hij gaf ook aan dat hij nu veel sneller klaar is, want om al zijn ideeën eerst met een developer te bespreken, hopen dat die het snapt, software maakt, test en die hele loop tig keer moet doorlopen.

Bottom line is dus ja, dat gebeurt al. Maar dat geld voor software voor eigen gebruik. Software die nog echt verkocht wordt, waar support op zit, of beveiligingsaspecten, of enorm schaalbare software zie ik dat nog niet echt gebeuren. Daar is meer kennis van nodig dan wat AI op dit moment bezit. Dus daar zit waarschijnlijk de toegevoegde waarde in, domeinkennis.

Een applicatie voor intern gebruik is toch net zo onderhevig aan wet- en regelgeving? Het internet staat vol met voorbeelden van datalekken en hacks. Straks is dat ERP-systeem zo lek als een mandje en dan zijn de poppen weer aan het dansen.

Dat moet je toch niet willen?

[RooT]

Gr4mpyC3t schreef op dinsdag 29 september 2026 @ 09:46:
[...]

Een applicatie voor intern gebruik is toch net zo onderhevig aan wet- en regelgeving? Het internet staat vol met voorbeelden van datalekken en hacks. Straks is dat ERP-systeem zo lek als een mandje en dan zijn de poppen weer aan het dansen.

Dat moet je toch niet willen?

Hoe dat precies met wet en regelgeving zit weet ik niet, maar ik zou het wel raar vinden dat als je iets voor eigen gebruik hebt dat je dan ook aan alle eisen moet voldoen. Voor wie? Als het gehackt wordt dan ben je dat toch zelf schuld, je kan er niemand anders voor aansprakelijk stellen.

Ik weet uiteraard ook niet hoe die beste man dat gemaakt heeft, maar zou me niks verbazen als het gewoon een interne database is, en geen cloud. Dan zit je qua security al een stuk makkelijker als het geen connectie van buitenaf heeft.

[CVTTPD2DQ]

RooT schreef op dinsdag 29 september 2026 @ 09:34:
Bottom line is dus ja, dat gebeurt al. Maar dat geld voor software voor eigen gebruik. Software die nog echt verkocht wordt, waar support op zit, of beveiligingsaspecten, of enorm schaalbare software zie ik dat nog niet echt gebeuren. Daar is meer kennis van nodig dan wat AI op dit moment bezit. Dus daar zit waarschijnlijk de toegevoegde waarde in, domeinkennis.

Er zijn genoeg kleine bedrijfjes die nu 50 euro per maand hier, 100 euro per maand daar betalen aan een SaaS-pakket. Als dat straks vervangen wordt door iets wat de baas zelf aan elkaar vibed, raakt dat natuurlijk indirect de arbeidsmarkt voor programmeurs.

En indirect voor UX designers, etc. Veel UX-werk zit in het product verkoopbaar maken; als je iets voor jezelf maakt, hoeft dat natuurlijk niet.

Gr4mpyC3t schreef op dinsdag 29 september 2026 @ 09:46:
Een applicatie voor intern gebruik is toch net zo onderhevig aan wet- en regelgeving? Het internet staat vol met voorbeelden van datalekken en hacks. Straks is dat ERP-systeem zo lek als een mandje en dan zijn de poppen weer aan het dansen.

Het zou best wel eens zo kunnen zijn dat de CRA niet van toepassing is als je een stuk software ontwikkelt voor eigen gebruik. Verder heb je gelijk, maar je beschrijft een beetje de situatie die we nu ook al hebben - ik denk niet dat AI hier een belangrijke kwalitatieve verslechtering veroorzaakt.

[Glashelder]

Gr4mpyC3t schreef op dinsdag 29 september 2026 @ 09:46:
[...]

Een applicatie voor intern gebruik is toch net zo onderhevig aan wet- en regelgeving? Het internet staat vol met voorbeelden van datalekken en hacks. Straks is dat ERP-systeem zo lek als een mandje en dan zijn de poppen weer aan het dansen.

Dat moet je toch niet willen?

Alsof dat niet ook al gebeurde voor het AI tijdperk. Zullen we niet doen alsof er op dat gebied heel erg veel veranderd is? Mensen zijn helemaal niet zo goed in programmeren als we zelf denken. Stiekem zijn we er eigenlijk gewoon erbarmelijk slecht in.

[Gr4mpyC3t]

RooT schreef op dinsdag 29 september 2026 @ 09:51:
[...]

Hoe dat precies met wet en regelgeving zit weet ik niet, maar ik zou het wel raar vinden dat als je iets voor eigen gebruik hebt dat je dan ook aan alle eisen moet voldoen. Voor wie? Als het gehackt wordt dan ben je dat toch zelf schuld, je kan er niemand anders voor aansprakelijk stellen.

Ik weet uiteraard ook niet hoe die beste man dat gemaakt heeft, maar zou me niks verbazen als het gewoon een interne database is, en geen cloud. Dan zit je qua security al een stuk makkelijker als het geen connectie van buitenaf heeft.

Als je persoonsgegevens opslaat in een ERP-systeem, dan heb je sowieso al te maken met de Algemene verordening gegevensbescherming (AVG). Je moet dan melding maken van een datalek op het moment dat je systeem gehackt is. Als de Autoriteit Persoonsgegevens dan onderzoek gaat doen en tot de conclusie komt dat je steken hebt laten vallen in het bouwen van die software, ben je echt 100% aansprakelijk.

Glashelder schreef op dinsdag 29 september 2026 @ 09:55:
[...]

Alsof dat niet ook al gebeurde voor het AI tijdperk. Zullen we niet doen alsof er op dat gebied heel erg veel veranderd is? Mensen zijn helemaal niet zo goed in programmeren als we zelf denken. Stiekem zijn we er eigenlijk gewoon erbarmelijk slecht in.

Punt dat ik probeer te maken is dat het misschien niet zo verstandig is om mensen die geen kennis van softwareontwikkeling hebben, software te laten maken? Ontwikkelaars die nu programmeren en steken laten vallen, kunnen dan mooi AI gebruiken om dit gat op te vullen. Misschien verandert er dan juist wel wat en wordt software veiliger.

Dat is een andere benadering dan jan-en-alleman maar software laten maken want ontwikkelaars bakken er nu ook al niets van...

[Glashelder]

Gr4mpyC3t schreef op dinsdag 29 september 2026 @ 10:17:
Punt dat ik probeer te maken is dat het misschien niet zo verstandig is om mensen die geen kennis van softwareontwikkeling hebben, software te laten maken? Ontwikkelaars die nu programmeren en steken laten vallen, kunnen dan mooi AI gebruiken om dit gat op te vullen. Misschien verandert er dan juist wel wat en wordt software veiliger.

Dat is een andere benadering dan jan-en-alleman maar software laten maken.

Dat is een insteek. Een andere insteek is om de tools verder te verbeteren zodat zij dit wel kunnen.

Waar ik werk ontwikkelen hele afdelingen met ons mee, van de directeuren tot projectbegeleiders. Gaandeweg verbeteren we het proces en de instructies. Claude Opus doet coding, Codex doet lokale reviews (tijdens het ontwikkelproces, iteratief) en voor er een PR voltooid kan worden is er nog CodeRabbit en een menselijke beoordeling. Dat vangt al echt heel erg veel af.. Hiermee zie je dat functionaliteit na 1 prompt al veel meer 'af' is dan gewoon een kale prompt. Natuurlijk kost het veel meer tijd en tokens, maar Opus valt behoorlijk mee qua tokengebruik.

[CVTTPD2DQ]

Gr4mpyC3t schreef op dinsdag 29 september 2026 @ 10:17:
Punt dat ik probeer te maken is dat het misschien niet zo verstandig is om mensen die geen kennis van softwareontwikkeling hebben, software te laten maken?

Alleen is dat natuurlijk decennialang gebeurd. Tel daar bij op dat ons begrip over het maken van goede software enorm is opgeschoven, en dan zou duidelijk moeten zijn wat we allemaal al weten: de meeste "handgemaakte" software voldoet niet meer aan de normen die we anno 2026 hebben.

Dertig jaar geleden was het nog de norm om software in C++ te schrijven, ook al was dat niet memory-safe. Twintig jaar geleden was het niet uitzonderlijk als een "PHP script" met stringconcatenatie queries aan elkaar plakte. Vijftien jaar geleden hadden alleen banken en webshops TLS, want dat was zo'n gedoe en die certificaten waren zo duur.

En veel van die bestaande software is eindeloos opgelapt, hier en daar verbeterd, maar draagt nog steeds alle problemen van de oude versie met zich mee.

Als je alles nu vanuit het niets laat genereren door een LLM, is het echt niet slechter.

[RooT]

Glashelder schreef op dinsdag 29 september 2026 @ 10:26:
[...]

Dat is een insteek. Een andere insteek is om de tools verder te verbeteren zodat zij dit wel kunnen.

Waar ik werk ontwikkelen hele afdelingen met ons mee, van de directeuren tot projectbegeleiders. Gaandeweg verbeteren we het proces en de instructies. Claude Opus doet coding, Codex doet lokale reviews (tijdens het ontwikkelproces, iteratief) en voor er een PR voltooid kan worden is er nog CodeRabbit en een menselijke beoordeling. Dat vangt al echt heel erg veel af.. Hiermee zie je dat functionaliteit na 1 prompt al veel meer 'af' is dan gewoon een kale prompt. Natuurlijk kost het veel meer tijd en tokens, maar Opus valt behoorlijk mee qua tokengebruik.

Hoezo gebruik je Codex voor de reviews? Is codex daar beter in, of is het gewoon omdat je een ander model de output van het model wat de code gemaakt heeft wilt laten checken?

[Gr4mpyC3t]

CVTTPD2DQ schreef op dinsdag 29 september 2026 @ 10:26:
[...]


Alleen is dat natuurlijk decennialang gebeurd. Tel daar bij op dat ons begrip over het maken van goede software enorm is opgeschoven, en dan zou duidelijk moeten zijn wat we allemaal al weten: de meeste "handgemaakte" software voldoet niet meer aan de normen die we anno 2026 hebben.

Dertig jaar geleden was het nog de norm om software in C++ te schrijven, ook al was dat niet memory-safe. Twintig jaar geleden was het niet uitzonderlijk als een "PHP script" met stringconcatenatie queries aan elkaar plakte. Vijftien jaar geleden hadden alleen banken en webshops TLS, want dat was zo'n gedoe en die certificaten waren zo duur.

En veel van die bestaande software is eindeloos opgelapt, hier en daar verbeterd, maar draagt nog steeds alle problemen van de oude versie met zich mee.

Als je alles nu vanuit het niets laat genereren door een LLM, is het echt niet slechter.

Dat ben ik dus niet met je eens. Tot op de dag van vandaag is het garbage in/garbage out. De prompts die je schrijft bepalen de kwaliteit van het gemaakte door de LLM. Als je niet vraagt om caching om bandbreedte te besparen, krijg je gewoon een website met 100 requests per actie naar een backend.

[Glashelder]

RooT schreef op dinsdag 29 september 2026 @ 10:38:
[...]

Hoezo gebruik je Codex voor de reviews? Is codex daar beter in, of is het gewoon omdat je een ander model de output van het model wat de code gemaakt heeft wilt laten checken?

Om eerlijk te zijn twee redenen:
- Ten eerste is de hoeveelheid tokens in een Claude Teams abo te beperkt om en een hele week te coden en met Fable te reviewen
- Ten tweede wilde ik eens testen inderdaad of een ander model van een andere vendor betere feedback geeft. De eerste indrukken lijken erop te wijzen dat dit zo is. Wat ik helemaal interessant vind is dat het aan de kant van Codex niet zo heel veel uit lijkt te maken of ik daar nu Astra inzet of Sol.

Ik vermoed een beetje dat de output beter is omdat Opus en Fable onderhuids gewoon vergelijkbare training hebben ondergaan. Laat je Astra of Sol tegen werk van Fable of Opus aankijken, dan is dat echt een frisse blik. Net alsof Jan het werk van Piet nakijkt, ipv Piet die het werk van Piet nakijkt na een flash van de neuralyzer:

[ Voor 19% gewijzigd door Glashelder op 29-09-2026 10:47 ]

[Glashelder]

Gr4mpyC3t schreef op dinsdag 29 september 2026 @ 10:43:
[...]

Dat ben ik dus niet met je eens. Tot op de dag van vandaag is het garbage in/garbage out. De prompts die je schrijft bepalen de kwaliteit van het gemaakte door de LLM. Als je niet vraagt om caching om bandbreedte te besparen, krijg je gewoon een website met 100 requests per actie naar een backend.

Daarom.. niet alleen maar prompten maar plannen en de plannen laten reviewen. Dat scheelt echt enorm in de kwaliteit van de output.

[RooT]

Glashelder schreef op dinsdag 29 september 2026 @ 10:43:
[...]

Om eerlijk te zijn twee redenen:
- Ten eerste is de hoeveelheid tokens in een Claude Teams abo te beperkt om en een hele week te coden en met Fable te reviewen
- Ten tweede wilde ik eens testen inderdaad of een ander model van een andere vendor betere feedback geeft. De eerste indrukken lijken erop te wijzen dat dit zo is. Wat ik helemaal interessant vind is dat het aan de kant van Codex niet zo heel veel uit lijkt te maken of ik daar nu Astra inzet of Sol.

Ik vermoed een beetje dat de output beter is omdat Opus en Fable onderhuids gewoon vergelijkbare training hebben ondergaan. Laat je Astra of Sol tegen werk van Fable of Opus aankijken, dan is dat echt een frisse blik. Net alsof Jan het werk van Piet nakijkt, ipv Piet die het werk van Piet nakijkt na een flash van de neuralyzer:

[Afbeelding]

Ook ervaring met Mistral Vibe voor dit?

[Glashelder]

RooT schreef op dinsdag 29 september 2026 @ 11:26:
[...]

Ook ervaring met Mistral Vibe voor dit?

Om eerlijk te zijn niet. Ik lees er niet zulke goede verhalen over (schijnt erg achter te lopen), dus nog geen noodzaak voor gezien so far.. Jij wel?

[RooT]

Glashelder schreef op dinsdag 29 september 2026 @ 12:33:
[...]

Om eerlijk te zijn niet. Ik lees er niet zulke goede verhalen over (schijnt erg achter te lopen), dus nog geen noodzaak voor gezien so far.. Jij wel?

Niet voor review, maar wel voor coden. Ik vind het niet slecht. Op mijn werk willen ze een bedrijfs abo nemen op Mistral en andere AI gaan 'verbieden'. Dit heeft voornamelijk met data integriteit te maken, dat de data in ieder geval niet meer naar de VS gaat. Ik denk dat dit sowieso voor ons allemaal een goed idee is, als wij als Europa de AI race verliezen hebben we echt een groot probleem. Met Mistral ondersteun je wel Europese AI.

[Glashelder]

Ik zet hem op de lijst om te testen dan! Mijn werkgever houdt wel van een experiment dus die gaat hier wel in mee t.z.t.

[wiemelen]

CVTTPD2DQ schreef op dinsdag 29 september 2026 @ 09:20:
[...]
Dat is precies wat ik bedoel. Is die developer nog wel zo'n nuttige toevoeging? Why not skip the middleman?

Is altijd een optie met de juiste kennis en voor bepaalde toepassingen.

Mijn stelling is altijd geweest "met enkel programmeurs krijg ik alles up & running, met enkel functionele mensen / architecten krijg je enkel iets op papier."

Beetje kort door de bocht natuurlijk, maar als developer heb ik vaak meer functionele kennis dan sommige van mijn functionele collega's. En ik ben niet de enige developer met deze skills. Dus misschien moeten we inzetten om alle developers meer functionele/proces kennis te geven. Dan heb je minder/geen functionele collega's meer nodig, maar behoud je de kennis om de code van AI te verifiëren en waar nodig te corrigeren.

[Sissors]

RooT schreef op dinsdag 29 september 2026 @ 12:43:
[...]

Niet voor review, maar wel voor coden. Ik vind het niet slecht. Op mijn werk willen ze een bedrijfs abo nemen op Mistral en andere AI gaan 'verbieden'. Dit heeft voornamelijk met data integriteit te maken, dat de data in ieder geval niet meer naar de VS gaat. Ik denk dat dit sowieso voor ons allemaal een goed idee is, als wij als Europa de AI race verliezen hebben we echt een groot probleem. Met Mistral ondersteun je wel Europese AI.

Uit nieuwsgierigheid, maar is dat dan een 'speciaal' bedrijf. Ik weet dat een ASML bijvoorbeeld gewoon Claude gebruikt, en die hebben meer te verliezen als het gemiddelde bedrijf.

(Overigens weet ik niet of Mistral nog te redden is, of nou ja, ze zijn gepivot naar AI's voor specifieke bedrijfstoepassingen maken, niet meer generieke AI. Doen ze misschien nog wel wat mee, maar de achterstand is daar zo enorm).

[RooT]

Sissors schreef op dinsdag 29 september 2026 @ 13:14:
[...]

Uit nieuwsgierigheid, maar is dat dan een 'speciaal' bedrijf. Ik weet dat een ASML bijvoorbeeld gewoon Claude gebruikt, en die hebben meer te verliezen als het gemiddelde bedrijf.

(Overigens weet ik niet of Mistral nog te redden is, of nou ja, ze zijn gepivot naar AI's voor specifieke bedrijfstoepassingen maken, niet meer generieke AI. Doen ze misschien nog wel wat mee, maar de achterstand is daar zo enorm).

Wij hebben wel bepaalde algoritmes in onze code, waarvan je niet zomaar wilt dat die in een AI model belanden. Overigens lijkt het me sterk dat ASML Claude gebruikt, ASML is notabene aandeelhouder van Mistral?

Ik hoop ook dat iedereen beseft, dat als wij als Europa op termijn geen concurrerend AI model meer hebben, dat onze hele welvaart in gevaar komt. Wij allemaal (inclusief ik) gebruiken AI meer en meer, en het geld en onze data gaat allemaal naar de VS (als je geen Chinese modellen gebruikt). Onze hele concurrentie positie gaat op termijn op het spel staan.

[ Voor 19% gewijzigd door RooT op 29-09-2026 13:21 ]

[geekeep]

ari3 schreef op zaterdag 26 september 2026 @ 17:33:
[...]
De verborgen of niet-functionele aspecten zul je in je instructies aan de AI expliciet moeten maken alsook de manier waarop deze aspecten (geautomatiseerd) gevalideerd kunnen worden.

Ik moet in 15 jaar softwareontwikkeling de eerste klant nog vinden die tot in de punt en komma kan specificeren wat er verwacht wordt... Er worden dus aannames gedaan in allerlei stappen van het proces, zowel toen als nu. Ironisch overigens dat AI getraind is op code met daarin diezelfde impliciete menselijke aannames. Hoe ga je AI instrueren om op iets te letten dat impliciet onderdeel is van de trainingsdata en daarmee het gegeneerde resultaat?

De toekomst is dat de AI vertelt wat de performance moet zijn. Dat wil zeggen: specificeer volume en minimale verwerkingstijden. Ga niet vertellen HOE dat bereikt moet worden want dat levert geen waarde op. Je wilt geen code of deployment-modellen reviewen om te controleren of de gewenste performance bereikt kan worden. Je wilt slechts toetsen of aan de specificatie voldaan wordt.

En dat is niet anders dan hoe het voorheen werkte (of zou moeten werken). De klant geeft de 'wat' en eventuele kaders, het softwareteam bedenkt de beste manier om dit te realiseren.

Architectuur is alleen noodzakelijk als leidraad voor mensen als zij zelf de bouwer van een applicatie zijn. Als je geen code genereert heb of niet zelf de exploitatie-infrastructuur inregelt heb geen architectuur nodig. Als het resultaat voldoet aan de eisen dan is het goed.

Totdat je moet gaan uitbreiden, migreren, koppelen met externe systemen of debuggen. Architectuur biedt houvast en maakt de kaders concreet waarbinnen men kan analyseren, plannen en bouwen. Software op zichzelf is fluïde en veranderlijk. Succes met koppelen en onderhouden als het als los zand tussen je vingers weg glipt.
Jouw argument is hoogstens valide in een bubbel waarbij je niks met de buitenwereld van doen hebt en/of altijd van nul begint. Legacy systemen, datamigraties, koppelingen met derde partijen en andere aspecten waarbij formats, standaarden en protocollen leidend zijn, zijn blijkbaar niet meer relevant?

Foutafhandeling zijn alternatieve executiepaden in de functionele eisen aan een applicatie en de exploitatie-omgeving. Die neem je dus gewoon mee in de specificatie voor de AI.

Foutafhandeling is juist het pad wat je níet expliciet functioneel afvangt, maar als 'buiten de kaders' beschouwd. Indien dat wel zo zou zijn, wordt het simpelweg business logica i.p.v. foutafhandeling. Het is daarnaast een utopie om alle mogelijke alternatieve paden functioneel te omvatten, dus je zult altijd een onverwacht pad moeten afvangen buiten je specs om.

Niet relevant als er geen code gegenereerd wordt. Wel relevant in de zin dat de instructies aan de AI eenvoudig aan te passen moeten zijn. Merk op dat de instructies aan een AI in natuurlijke taal vooral handig is voor mensen, net als programmeertalen vooral handig zijn voor mensen. Een AI heeft geen natuurlijke taal of programmeertaal nodig als modellering van de context. Een AI heeft zijn eigen interne model. Mogelijk dat in de toekomst er een AI-gerichte taal komt zodat de ambiguïteit van natuurlijke taal vermeden kan worden. Of dat natuurlijke taal zelf evolueert naar een vorm met minder ambiguïteit.

Programmeertalen zijn bedoeld om grijs gebied uit te sluiten. Een IF is altijd ja of nee, en niet misschien. Een Integer bevat geen letters. Een FOR-loop draait evenveel iteraties met dezelfde input. Natuurlijke taal is echter wel grijs, dubieus en voor meerdere interpretaties vatbaar. Het resultaat van de vertaalslag van een AI met als input/prompt natuurlijke taal zal dus inherent dubieuze logica bevatten.
Laat nou net die kritische menselijke ontwikkelaar de brug hebben gevormd tussen de wens in natuurlijke taal en de formele programmeertaal die uitgevoerd wordt. Zonder dat stukje menselijke grounding en de daaropvolgende zichtbare code heb je niks meer dan een blackbox en wat goede hoop dat het (altijd) doet wat je verwacht.

Tsja, de fierheid zal in de toekomst komen uit het juist instrueren van de AI om het gewenste resultaat te krijgen. Als geen code genereerd wordt, zijn codeerstandaarden en best practices geen overweging meer.

AI heeft de kennis en ervaring van de beste vakmensen tot zich genomen en kan deze op schaal toepassen, maar deze kennis is alleen nodig in de transitiefase waar we nu inzitten. De AI-native manier van werken maakt het genereren van code, gebruik van compilers, toepassing van architectuurprincipes, cloud deployment descriptors, enz. allemaal overbodig. We zullen zeer binnenkort op een niveau zitten dat Al deze zaken kan abstraheren zodat mensen zich puur met functionele en niet-functionele eisen aan applicatie kunnen bezig houden.

Buiten dat de volgens jou overbodige zaken ook gewoon non-functionals zijn, durf ik te betwijfelen dat "AI de kennis en ervaring van de beste vakmensen tot zich heeft genomen". Niemand weet waar het op getraind is én er zijn maar weinig mensen die zich tot de beste mogen rekenen. Daarnaast zal met het toenemen van gegenereerde code het incestueuze/inbreeding aspect een steeds grotere rol gaan spelen.

[eric.1]

Glashelder schreef op zondag 27 september 2026 @ 20:49:
Ik kan me niet aan de indruk onttrekken dat er hier aan de kant van software developers sprake is van wat wens denken als ik lees dat er geen denk werk in zit aan de kant van AI.

Of jullie gebruiken modellen van jaren geleden of het wordt niet goed gebruikt, want ik zie hier AI toch echt wel serieus meedenken. En ik kom zelden tot nooit in een loop.

Wensdenken aan de ene kant, of blind vertrouwen aan de andere kant? De waarheid ligt waarschijnlijk in het midden. Bovenop de mogelijk verschillende definities van 'denken'.

Wat ik met de recentere modellen zie is dat ze best goed naar gebruikte structuren in de code kunnen kijken en op basis daarvan aan kunnen geven: "je mist x", "y gaat niet goed", ... Maar zodra er iets gedaan moet worden waar nog geen scaffold voor is - dan mist er eigenlijk altijd wat en moet jij echt zelf alle touwtjes in handen houden en het schip sturen.

En dat is zorgelijk. Niet eens om de kwaliteit die eruit voort komt. Maar als je dit lang genoeg volhoud dan verlies je als mens snel de controle en heb je geen enkel benul meer wat er gaande is. Je hoeft niet ver te zoeken op het internet of the "LGTM"-memes vliegen je om de oren. Die komen niet uit de lucht vallen.

Wie vertelt AI wat de kaders zijn, welke speciale zaken aandacht nodig hebben, welke toekomst-uitbreidingen te verwachten zijn, etc... wanneer alle kennis bij de mens is verdwenen of op zijn minst sterk is verminderd?

En wellicht nog zorgelijker, de 'junior' developers die al het bovenstaande nog moeten leren - doen dit dus minder en leunen op de automagische tools. We lijken ervoor te kiezen om de touwtjes uit handen te geven. Dan moeten we niet gek opkijken dat alles een keer in vlammen op gaat.

[eheijnen]

En wellicht nog zorgelijker, de 'junior' developers die al het bovenstaande nog moeten leren - doen dit dus minder en leunen op de automagische tools. We lijken ervoor te kiezen om de touwtjes uit handen te geven. Dan moeten we niet gek opkijken dat alles een keer in vlammen op gaat.

Blijven er nog twee vragen over, imo.
1. Wat moeten die juniors nu geleerd krijgen, en aan kennis en ervaring meebrengen vanuit hun opleiding?
2. Zal er een herdefiniëring gaan plaatsvinden van diverse opleidingsniveaus voor developers?