De Devschuur Coffee Corner - Iteratie ⑬

[DevWouter]

MueR schreef op vrijdag 2 oktober 2026 @ 00:27:
[...]

Volgens mij was het ongeveer 20% ontwikkeltijd. De rest was bedenken wat je moet bouwen, hoe je het moest bouwen en flauwekul als meetings.

Zoiets inderdaad, ik dacht zelfs dat het zo laag als 5% kan zijn.

[Firesphere]

DevWouter schreef op vrijdag 2 oktober 2026 @ 00:22:
[...]

Eens, maar dat is van alle tijden. Overigens spenderen ontwikkelaars heel weinig tijd aan het kloppen van code. Het zijn vaak de randzaken waar de kosten in gaan zitten.

Peter Naur verwoord dit prachtig:

A program is not its source code, it is a shared mental construct or theory, that lives in the minds of the people who work on it.

Conversely, if you lose the people, you lose the program. The code is merely a written representation of the program, and it's lossy, you can't reconstruct a program from its code.

Dit verklaart ook een groot deel van het NMH syndroom, of waarom veel ontwikkelaars zeggen dat iets moet worden herbouwd vanaf 0.

Voor meer, lees zijn essay "Programming as Theory building"

[Firesphere]

DevWouter schreef op vrijdag 2 oktober 2026 @ 01:53:
[...]

Zoiets inderdaad, ik dacht zelfs dat het zo laag als 5% kan zijn.

In letterlijke termen zal ik misschien een half uur per dag echt code schrijven. Het meeste zit'm in nadenken over hoe en wat ik eigenlijk wil bereiken

[Firesphere]

BarôZZa schreef op zaterdag 26 september 2026 @ 16:59:
[...]

Vast geen populaire mening hier, maar als er een beroep is die het verdient om door AI overgenomen te worden, dan zijn het de developers.

Want wij hebben natuurlijk al decennia lang iedereen weg geautomatiseerd, zonder enige compassie. Als je niet mee kon doen had je pech, had je maar slimmer werk moeten doen. Als iedereen met geknepen billen zat bij een reorganisatie, dan kregen de IT'ers lachend een opslag omdat ze het mogelijk maakten om met minder mensen te werken.

Dit is een vrij kortzichtige mening.

Veel ontwikkeling wordt juist gedaan om het leven makkelijker te maken. Of dit nu software is, of hardware, een betere tractor of een website met meer functionaliteit. Het is niet om het mogelijk te maken om met minder mensen te werken.

Dit is ook zichtbaar in andere werkgroepen. Vooruitgang door techniek toe te passen, leidt inderdaad aan de ene kant tot de mogelijkheid om met minder mensen hetzelfde of meer te bereiken. Het leidt echter ook naar nieuwe paden, nieuwe openingen en posities.

Het is niet "IT die mensen overbodig maakt", het is vooruitgang.

Een mooi voorbeeld hiervan is mijn eigen ervaring met een specifiek project. In dit project maakten we het inschrijven voor een nieuwe energie aansluiting makkelijker, en zorgden er voor dat er minder telefoontjes naar de helpdesk waren, met problemen rondom de aansluiting.

Dit leidde echter niet tot een vermindering van personeel op de helpdesk. Een deel van de helpdesk kon worden herplaatst in het team dat de aansluitingen aanstuurde met de netwerkbeheerder. Dit was nodig omdat er meer aanvragen voor aansluitingen kwamen.

Een ander deel was nog steeds nodig op de helpdesk, niet om aansluitingen via telefoon op te lossen, maar omdat het aantal aangesloten huishoudens explosief was toegenomen, waren er meer mensen nodig voor de bemensing van de "normale" helpdesk.

Aan de ene kant maakte mijn team een deel van de helpdesk onnodig, aan de andere kant, zorgden we voor nieuw werk voor diezelfde mensen.

En daarnaast, als een ITer "lachend een opslag krijgt omdat er mensen konden worden ontslagen", dan is die ITer waarschijnlijk niet erg geliefd bij de collega's.

[AlphaRomeo]

Firesphere schreef op vrijdag 2 oktober 2026 @ 02:47:
Dit verklaart ook een groot deel van het NMH syndroom, of waarom veel ontwikkelaars zeggen dat iets moet worden herbouwd vanaf 0.

Bedoel je NIH (Not Invented Here) syndrome? Ik kan over NMH niets zinnigs vinden.

[Firesphere]

AlphaRomeo schreef op vrijdag 2 oktober 2026 @ 09:41:
[...]

Bedoel je NIH (Not Invented Here) syndrome? Ik kan over NMH niets zinnigs vinden.

Not Made Here, zelfde, maar ander woordje

[ Voor 7% gewijzigd door Firesphere op 02-10-2026 09:44 ]

[hackerhater]

DevWouter schreef op vrijdag 2 oktober 2026 @ 01:53:
[...]

Zoiets inderdaad, ik dacht zelfs dat het zo laag als 5% kan zijn.

Ik porteer zelf legacy code en ik schat dat 90 a 95% van de tijd gaat zitten in het achterhalen wat de code eigenlijk doet, wat het hoort te doen en het nieuwe gedrag documenteren.

Het daadwerkeljk schrijven van de code is maar weinig werk en veel kan door tools als rector gedaan worden. LLM's zijn een negatieve tijd-factor in dit werk, juist omdat niet te voorspellen is wat ze doen.

[Lethalis]

Hoeveel procent van mijn dag uit code kloppen bestaat, varieert nogal. Maar het is zeker waar dat een groot deel van mijn tijd aan andere zaken opgaat dan programmeren. En daarop heeft AI vrij weinig (niet per se 0) invloed.

[Lethalis]

hackerhater schreef op zaterdag 3 oktober 2026 @ 16:56:
[...]

Ik porteer zelf legacy code en ik schat dat 90 a 95% van de tijd gaat zitten in het achterhalen wat de code eigenlijk doet, wat het hoort te doen en het nieuwe gedrag documenteren.

AI kan enorm helpen bij het achterhalen van wat de code doet en ook bij het opsporen van bugs.

Dus ik gebruik het voor meer dan alleen programmeren.

Dit stukje vind ik ironisch genoeg juist leuk aan AI, terwijl ik liever zelf de code ontwikkel / daar graag veel invloed op wil hebben.

Stel je krijgt een stacktrace van een null reference exception en je weet daardoor de functie waarin deze voorkomt. Dan kan ik aan Copilot simpelweg vragen waardoor dit kan komen en krijg ik een lijstje met mogelijkheden terug.

Vaak zit de boosdoener ertussen en dat scheelt veel tijd t.o.v. het helemaal zelf uitzoeken.

[hackerhater]

Lethalis schreef op zaterdag 3 oktober 2026 @ 23:02:
[...]

AI kan enorm helpen bij het achterhalen van wat de code doet en ook bij het opsporen van bugs.

Dus ik gebruik het voor meer dan alleen programmeren.

Dit stukje vind ik ironisch genoeg juist leuk aan AI, terwijl ik liever zelf de code ontwikkel / daar graag veel invloed op wil hebben.

Stel je krijgt een stacktrace van een null reference exception en je weet daardoor de functie waarin deze voorkomt. Dan kan ik aan Copilot simpelweg vragen waardoor dit kan komen en krijg ik een lijstje met mogelijkheden terug.

Vaak zit de boosdoener ertussen en dat scheelt veel tijd t.o.v. het helemaal zelf uitzoeken.

Geloof me met die crap code die ik onder handen krijg zijn die LLM's geen pre ;)
Iets als standaarden bestaan in PHP pas een jaar of 10 en tenzij het bedrijf zelf al tools gebruikt om die af te dwingen (doubtfull als ze me inhuren) is er niks die je tegen houd er een enorme puinzooi van te maken.
Ik zit nu op een project dat nog PHP 4 code had, 25 jaar oud.............

[Lethalis]

hackerhater schreef op zaterdag 3 oktober 2026 @ 23:07:
[...]

Geloof me met die crap code die ik onder handen krijg zijn die LLM's geen pre ;)
Iets als standaarden bestaan in PHP pas een jaar of 10 en tenzij het bedrijf zelf al tools gebruikt om die af te dwingen (doubtfull als ze me inhuren) is er niks die je tegen houd er een enorme puinzooi van te maken.
Ik zit nu op een project dat nog PHP 4 code had, 25 jaar oud.............

Ik zit nog regelmatig VB.NET code te debuggen van 22 jaar oud, die door VB6 developers gemaakt is. Ze hebben daarbij zelfs een namespace gebruikt die oude VB6 functies terugbracht zoals Left, Mid, etc. Als je echt wil huilen

En zelfs dat snapt Copilot nog grotendeels.

Sure, aanpassingen kan die beter niet doen. Ondanks dat de redenatie soms logisch lijkt, gaat het dan toch mis, omdat onze bagger code soms afhankelijk is van een volgorde van events die getriggerd worden in een Windows applicatie.

Dat heeft Copilot simpelweg niet door. Ook de dure modellen niet. Ik neem dat AI ook niet kwalijk Want ik doe er soms ook een dag over om het te snappen.

Hopeloze zooi is het.

Maar goed, in modernere projecten heb je een andere situatie. Zeker als je ook goede unit tests hebt. Dan is het geheel voorspelbaarder en kan je ook meer met AI doen.

[DevWouter]

Lethalis schreef op zaterdag 3 oktober 2026 @ 23:18:
[...]

Ik zit nog regelmatig VB.NET code te debuggen van 22 jaar oud, die door VB6 developers gemaakt is. Ze hebben daarbij zelfs een namespace gebruikt die oude VB6 functies terugbracht zoals Left, Mid, etc. Als je echt wil huilen

En zelfs dat snapt Copilot nog grotendeels.

Sure, aanpassingen kan die beter niet doen. Ondanks dat de redenatie soms logisch lijkt, gaat het dan toch mis, omdat onze bagger code soms afhankelijk is van een volgorde van events die getriggerd worden in een Windows applicatie.

Dat heeft Copilot simpelweg niet door. Ook de dure modellen niet. Ik neem dat AI ook niet kwalijk Want ik doe er soms ook een dag over om het te snappen.

Hopeloze zooi is het.

Maar goed, in modernere projecten heb je een andere situatie. Zeker als je ook goede unit tests hebt. Dan is het geheel voorspelbaarder en kan je ook meer met AI doen.

VB.NET uit het jaar 2004? Dat maakt het oorspronkelijke framework .NET 2003 / VB 7.1. Daar heb ik nogal wat slechte ervaringen mee.

Overigens... De reden waarom AI in jouw situatie wel werkt is juist o.a. omdat ze de oude namespaces hersteld hebben. LLMs zijn namelijk niet instaat om informatie in de juiste historisch context te plaatsen. En een taal zoals PHP is wat extremer veranderd dan VB.NET waardoor AI vaker met foute context aankomt.

[Lethalis]

DevWouter schreef op zaterdag 3 oktober 2026 @ 23:43:
[...]

VB.NET uit het jaar 2004? Dat maakt het oorspronkelijke framework .NET 2003 / VB 7.1. Daar heb ik nogal wat slechte ervaringen mee.

Overigens... De reden waarom AI in jouw situatie wel werkt is juist o.a. omdat ze de oude namespaces hersteld hebben. LLMs zijn namelijk niet instaat om informatie in de juiste historisch context te plaatsen. En een taal zoals PHP is wat extremer veranderd dan VB.NET waardoor AI vaker met foute context aankomt.

Maar dat kun je evt meegeven in Agents.md

Angular is modern, maar ook enorm veranderd. Dan moet je ook continu meegeven dat je bijvoorbeeld de control flow syntax en signals wil gebruiken, anders gaat het ook mis.

Nou vind ik dat Copilot ook niet zo fijn werkt met Angular, maar goed. De backend in C# gaat dan juist weer een stuk beter.

(ik werk zowel in nieuwe als hele oude projecten)

Mijn slechtste ervaring met VB.Net kwam doordat option strict ergens uit stond. En een situatie met een ByRef die ik het grote ByRef monster heb genoemd op mijn werk.

[DevWouter]

Lethalis schreef op zaterdag 3 oktober 2026 @ 23:52:
[...]

Maar dat kun je evt meegeven in Agents.md

Dat verandert niks aan het feit dat de LLMs geen historische besef hebben. Ze zijn alleen getraind gemaakt om tokens associëren.

Angular is modern, maar ook enorm veranderd. Dan moet je ook continu meegeven dat je bijvoorbeeld de control flow syntax en signals wil gebruiken, anders gaat het ook mis.

Nou vind ik dat Copilot ook niet zo fijn werkt met Angular, maar goed. De backend in C# gaat dan juist weer een stuk beter.

Zucht… Fucking signals… Die krengen zitten vol met timing bugs en ik ben overtuigd dat de grootste push heeft gekregen omdat het beter werkt met LLMs puur omdat ze beter getraind zijn op dat soort stijl code en niet zo zeer omdat mensen moeite hebben met RxJs stijl code. Signals zijn leuk als je code naïef kan zijn, maar zodra je iets met realtime nodig heb is het onbetrouwbaar.

De control flow syntax had ook wat issues maar daar was dat was vooral omdat het niet overal een 100% een 1-op-1 vervangen kon worden. Dat was uiteindelijk wel een duidelijke upgrade.

(ik werk zowel in nieuwe als hele oude projecten)

Mijn slechtste ervaring met VB.Net kwam doordat option strict ergens uit stond. En een situatie met een ByRef die ik het grote ByRef monster heb genoemd op mijn werk.

Pff… Ik heb meegemaakt dat het een form twee keer openen zonder op te slaan niet werkte in VB.NET. De eerste keer werkte en de tweede keer crasht de complete IDE. Uiteindelijk vond ik de oorzaak bij toeval. Blijkbaar resulteerde het openen alleen al dat het form werd aangepast en sloeg die het automatisch op met een syntax fout. Sloot je de tab en opende je het opnieuw dan crashte die zonder dat je ook maar iets had aangepast.

Twee uur later was het project plotseling herschreven in csharp ondanks dat er een expliciet verbod op stond. Geen idee wie dat gedaan heeft. 🤷

[hackerhater]

Lethalis schreef op zaterdag 3 oktober 2026 @ 23:52:
[...]

Maar dat kun je evt meegeven in Agents.md

Angular is modern, maar ook enorm veranderd. Dan moet je ook continu meegeven dat je bijvoorbeeld de control flow syntax en signals wil gebruiken, anders gaat het ook mis.

Nou vind ik dat Copilot ook niet zo fijn werkt met Angular, maar goed. De backend in C# gaat dan juist weer een stuk beter.

(ik werk zowel in nieuwe als hele oude projecten)

Mijn slechtste ervaring met VB.Net kwam doordat option strict ergens uit stond. En een situatie met een ByRef die ik het grote ByRef monster heb genoemd op mijn werk.

Het grote verschil is dat PHP vroeger niet als programmeertaal was opgezet. Nauwelijks klassen support, geen namespaces, geen afscherming van variabelen, globale variabelen die overal in de code aangepast kunnen worden, etc.
Laat staan iets als code standaarden. De reputatie van PHP onveilig en buggy te zijn komt uit deze tijd.
Tegenwoordig is dat een stuk beter, maar nog steeds is het meeste optioneel om niet backwards compatiblity te breken.
Kunnen LLM's werkende code opleveren? Ja. Goede code, laat staan onderhoudbare code? nee.

En om het nog erger te maken: het gros van de publieke code waar die LLM's op getraind zijn is level bad practices en outdated code, oa van StackExchange.

[Firesphere]

Lethalis schreef op zaterdag 3 oktober 2026 @ 23:52:
[...]

Maar dat kun je evt meegeven in Agents.md

Gelukkig helpen al die markdown bestanden heel erg...

https://pivot-to-ai.com/2026/08/27/your-agents-md-file-doesnt-actually-do-anything/

BRB, ik ga een "Jeremy.md" schrijven.

[Lethalis]

@DevWouter Onze Windows Forms code staat vol met if statements "doe dit alsjeblieft niet in design mode"

Wat je beschrijft, kan namelijk net zo hard met C# gebeuren en is gewoon Windows Forms designer ellende.

Waarschijnlijk heb je de echte bug per ongeluk opgelost met de rewrite.

Maar goed, ik ben op mijn werk de meest negatieve over AI, dus het voelt een beetje gek om de discussie met jullie te voeren dat het soms wel handig kan zijn.

Met Angular signals heb ik nog geen issues gehad trouwens, maar heb ook geen realtime updates nodig gehad in de applicaties die ik ermee gemaakt heb. Wel vind ik het naar hoe vaak Angular verandert. Dat is niet bij te houden in een groter project en de automatische migraties gaan vaak fout of doen niet alles.

[Firesphere]

Lethalis schreef op zondag 4 oktober 2026 @ 10:49:
Maar goed, ik ben op mijn werk de meest negatieve over AI, dus het voelt een beetje gek om de discussie met jullie te voeren dat het soms wel handig kan zijn.

In mijn oogpunt ben jij bent lyrisch over ""ai"", helemaal vergeleken met mijzelf en anderen hier.

[Zenomyscus]

Her verbaast me een beetje om ook nu nog zoveel negatieve dingen te lezen over LLMs. De meeste kritiek die ik lees is voor mij inmiddels alweer een tijd geleden. De meeste problemen die ik hier lees heb ik niet (meer). Ik heb inmiddels tussen 10 en bijna 20 jaar ervaring met bepaalde talen. Onze codebase is voornamelijk C#, SQL, TS (of JS), HTML en CSS en ik betrap de AI zelden nog op dingen die niet correct zijn. Niet alle oplossingen zou ik zelf op dezelfde manier doen, maar dat heb ik met andere developers ook.

Ik gebruik tot nu toe al jaren Visual Studio en builde web projecten naar IIS. Online gebruiken we ook Linux. Ik merk nu dat ik Visual Studio eigenlijk niet meer nodig heb. Claude kan de projecten testen, builden, zelf draaien in een browser en als ik moet kijken staat het klaar. Niet zelf op de startknop duwen, niet wachten op een build, niks. Gewoon drukken op F5, heerlijk! Mijn rol is dus meer verschoven naar tester.

Het is mijn eigen platform, met 3 anderen heb ik een bedrijf. Toen ik in loondienst zat was programmeren inderdaad max 20% van mijn tijd. Ik hoor dat dat bedrijf ook niet veel sneller gaat met AI. PRs blijven nog lang hangen etc. Maar hier heb ik daar geen last van. Ik moest altijd lachen om die '10x' Youtubers, ik vond dat zo onzinnig. Alsof je elke 3 dagen een grote feature afmaakt waar je normaal een maand over zou doen!? Nou je raad het al, inmiddels komt hier elke 3 dagen een grote feature van de grond. En ik durf te zeggen dat het beter is dan wanneer ik het zelf zou doen. Er is ook veel meer code, maar dat komt vooral omdat allerlei edge cases nu wel afgevangen zijn. Mijn kijk op de codebase is ook veranderd. Collegas zeggen wel eens 'kunnen we niet beter wachten op X of Y, anders moeten we dat weer aanpassen'. Dat maakt dus niet meer uit. Dan schrijf 'je' (lees: de AI) het nog maar een keer en gooi je de rest weg. Kan gewoon. Wees niet te bang zijn om keuzes te maken die later weer kunnen veranderen, dan doe je dat. Met die instelling en een goede lokale AI setup bereik ik dus heel veel.

Die goede setup doet ook het halve werk. ~18% van mijn tokenverbruik komt van agents / skills die altijd meedraaien. Dat is vrij fors, maar het zorgt gewoon voor betere code. Als ik dezelfde prompt bij mij draai of bij mijn collega dan is het verschil groot, op dezelfde codebase dus. Mijn collega heeft een resultaat waar veel op aan te merken is, moet zelf alles klaarzetten en ziet dan allerlei dingen die beter kunnen. Je kunt er soms weinig mee, niveau junior 'het build toch'. Mijn setup stopt de AI regelmatig om tussendoor vanalles te verbeteren. Gaat automatisch in de browser visuele vergelijkingen doen etc. Zodra ik het test is het praktisch klaar. Een wereld van verschil. Voor iedereen die negatief is, probeer je eigen setup te verbeteren. Het heeft mij in elk geval enorm geholpen.

Tot slot plan ik eigenlijk alles eerst. Ik laat de AI uitzoeken wat er nu is (ik help hem in de juiste richting), ik geef aan waar ik naar toe wil, ik geef aan welke valkuilen ik verwacht en de AI gaat daar een plan voor maken. Vaak komen er extra uitdagingen naar boven en keuzes die ik kan maken nog voordat er een regel code is geschreven. Is het plan goed? Dan gaan we er voor, in stappen zodat ik tussendoor kan testen. Combineer dat met een goede lokale setup en een krachtig model als Opus 5.5 en boem je hebt elke 3 dagen een leuke feature. Na jaren onze todolijst zien oplopen met duizenden ideeen, letterlijk, kan ik eindelijk waarmaken wat ik altijd voor ogen had. Klein nadeel is dat 1 van mijn collegas gewoon niet meer mee komt. Het gaat te snel en tegen de tijd dat hij iets bedenkt heb ik het al een paar dagen klaar.

Ook met nieuwe technieken is de AI goed. Laat hem documentatie lezen. Laat hem zelf voorbeelden bouwen. Laat hem een eigen 'playground' bouwen en gebruiken. Schrijf meer tools, schrijf wat je nodig hebt om je einddoel te bereiken. Laat hem desnoods de hele omgeving kopieren en daar in klooien totdat er wat uit komt. Wil je weten hoe iets werkt met 10.000 requests per seconde? Laat hem hem schrijven, testen en analyseren. Wil je weten wat voor invloed bepaalde parameters hebben? Dan laat je dat 16 keer uitvoeren en analyseer je dat. Of 100 keer, of 1000 keer.

Hoe creatiever je bent, hoe meer je met AI kunt bereiken.

[Lethalis]

Firesphere schreef op zondag 4 oktober 2026 @ 10:53:
[...]

In mijn oogpunt ben jij bent lyrisch over ""ai"", helemaal vergeleken met mijzelf en anderen hier.

Ik denk dat ik niet per se negatief over de tools zelf ben, maar wel depressief word van hoe roekeloos ze worden gebruikt en wat het effect ervan is op klanten en managers.

Roekeloos, omdat er minder aandacht is voor de kwaliteit van de code en dat je nu steeds meer druk van alle kanten krijgt om alles maar sneller te doen "want je hebt toch AI".

Daarnaast vind ik zelf programmeren juist leuk en ook iets rustgevends hebben. AI haalt de lol eruit.

Heel eerlijk heb ik gisteren nog gekeken naar AutoDesk Revit, omdat er veel vraag naar 3D modelleurs lijkt te zijn (ik heb een achtergrond als CAD tekenaar) en heb ik erover gefantaseerd de IT te verlaten.

Vanwege AI. En dan noem jij me lyrisch erover

[Firesphere]

Zenomyscus schreef op zondag 4 oktober 2026 @ 10:57:
Ook met nieuwe technieken is de AI goed. Laat hem documentatie lezen. Laat hem zelf voorbeelden bouwen. Laat hem een eigen 'playground' bouwen en gebruiken. Schrijf meer tools, schrijf wat je nodig hebt om je einddoel te bereiken. Laat hem desnoods de hele omgeving kopieren en daar in klooien totdat er wat uit komt. Wil je weten hoe iets werkt met 10.000 requests per seconde? Laat hem hem schrijven, testen en analyseren. Wil je weten wat voor invloed bepaalde parameters hebben? Dan laat je dat 16 keer uitvoeren en analyseer je dat. Of 100 keer, of 1000 keer.

"Hem"? Echt? Ik geef mijn computer namen, maar ik ga ze niet antromorphiseren. En ik zal't daar ook maar bij laten, niet echt zin om je hele relaas gedetailleerd te lezen.

---

Lethalis schreef op zondag 4 oktober 2026 @ 11:08:
Vanwege AI. En dan noem jij me lyrisch erover

Let me quote:

Lethalis schreef op zaterdag 3 oktober 2026 @ 23:02:
[...]

AI kan enorm helpen bij het achterhalen van wat de code doet en ook bij het opsporen van bugs.

Dus ik gebruik het voor meer dan alleen programmeren.

Dit stukje vind ik ironisch genoeg juist leuk aan AI, terwijl ik liever zelf de code ontwikkel / daar graag veel invloed op wil hebben.

Stel je krijgt een stacktrace van een null reference exception en je weet daardoor de functie waarin deze voorkomt. Dan kan ik aan Copilot simpelweg vragen waardoor dit kan komen en krijg ik een lijstje met mogelijkheden terug.

Vaak zit de boosdoener ertussen en dat scheelt veel tijd t.o.v. het helemaal zelf uitzoeken.

Lethalis schreef op zaterdag 3 oktober 2026 @ 23:52:
[...]

Maar dat kun je evt meegeven in Agents.md

[...]

Nou vind ik dat Copilot ook niet zo fijn werkt met Angular, maar goed. De backend in C# gaat dan juist weer een stuk beter.

Dat valt onder "lyrisch", bij mij.

[hackerhater]

Zenomyscus schreef op zondag 4 oktober 2026 @ 10:57:
Her verbaast me een beetje om ook nu nog zoveel negatieve dingen te lezen over LLMs. De meeste kritiek die ik lees is voor mij inmiddels alweer een tijd geleden. De meeste problemen die ik hier lees heb ik niet (meer). Ik heb inmiddels tussen 10 en bijna 20 jaar ervaring met bepaalde talen. Onze codebase is voornamelijk C#, SQL, TS (of JS), HTML en CSS en ik betrap de AI zelden nog op dingen die niet correct zijn. Niet alle oplossingen zou ik zelf op dezelfde manier doen, maar dat heb ik met andere developers ook.

......................

Hoe creatiever je bent, hoe meer je met AI kunt bereiken.

En nu probeer dat eens te doen in omgevingen waar data beveiliging een belangrijk ding is
De code, laat staan de data, kopieren in een offsite systeem is een big no en dan mag je direct een melding gaan doen voor een data-breach.
De bedrijven die me inhuren maken geen cheap run-of-the-mill software. Databeveiliging en betrouwbaarheid zijn de nummer 1 eisen.

Ik ben negatief over die LLM's omdat de qualiteit van code die ze opleveren subpar is.
En wat ze doen is niet herhaalbaar zoals code-generator/refactor tools wel zijn.
Sure als je geen hoge eisen stelt zal het wel aardig uit zien

[Lethalis]

Firesphere schreef op zondag 4 oktober 2026 @ 11:16:
[...]


Dat valt onder "lyrisch", bij mij.

Dan ken je sommige van mijn collega's en ook ex collega's nog niet.

Eentje verhuurt zich als AI Engineer, de volgende vibe code hele API's ermee in elkaar, nog een ander heeft zichzelf helemaal weg geautomatiseerd en drukt alleen nog op OK.

Ik moet er niet aan denken. Maar goed, ik gebruik AI wel voor kleinere taken die ik volledig kan overzien.

[Zenomyscus]

Firesphere schreef op zondag 4 oktober 2026 @ 11:16:

"Hem"? Echt? Ik geef mijn computer namen, maar ik ga ze niet antromorphiseren. En ik zal't daar ook maar bij laten, niet echt zin om je hele relaas gedetailleerd te lezen.

Hem, het, hullie, whatever. Ik weet ook wel dat het geen persoon is. Wellicht was dit niet het juiste topic voor een positief AI geluid. Jammer dat de rest dan niet meer relevant is. Eigenlijk vind ik het ook helemaal niet erg dat er een hoop programmeurs zijn die weinig / minder met AI doen. Dat geeft mij een gigantische voorsprong

[hackerhater]

Zenomyscus schreef op zondag 4 oktober 2026 @ 11:42:
[...]

Hem, het, hullie, whatever. Ik weet ook wel dat het geen persoon is. Wellicht was dit niet het juiste topic voor een positief AI geluid. Jammer dat de rest dan niet meer relevant is. Eigenlijk vind ik het ook helemaal niet erg dat er een hoop programmeurs zijn die weinig / minder met AI doen. Dat geeft mij een gigantische voorsprong

1 grote vraag: weet je uberhaupt wat de code doet?
Bij mijn klant was er ook zo iemand die alles door een LLM liet genereren.
Well het is zo'n grote puinzooi dat de klant nu is het kijken dat of ze mij en een andere freelancer gaan betalen het te fixen (naast de huidige klus) of alles weg knikkeren van de laatste 2 maanden.

[ Voor 21% gewijzigd door hackerhater op 04-10-2026 11:53 ]

[Zenomyscus]

hackerhater schreef op zondag 4 oktober 2026 @ 11:35:
[...]

En nu probeer dat eens te doen in omgevingen waar data beveiliging een belangrijk ding is
De code, laat staan de data, kopieren in een offsite systeem is een big no en dan mag je direct een melding gaan doen voor een data-breach.
De bedrijven die me inhuren maken geen cheap run-of-the-mill software. Databeveiliging en betrouwbaarheid zijn de nummer 1 eisen.

Ik ben negatief over die LLM's omdat de qualiteit van code die ze opleveren subpar is.
En wat ze doen is niet herhaalbaar zoals code-generator/refactor tools wel zijn.
Sure als je geen hoge eisen stelt zal het wel aardig uit zien

Onze online omgeving staat volledig los van de lokale omgeving. De AI kan daar ook absoluut niet bij, want de AI doet ook zeker dingen die ik absoluut niet wil met die data. In onze omgeving is het niet moeilijk om met nepdata te werken, maar ik heb dan ook geen product in de financiele wereld of iets wat met NASA te maken heeft. Neemt niet weg dat wij ook persoonsgegevens en andere belangrijke gegevens verwerken en we dus goed met die data om moeten gaan. Dat doen we al jaren en staat los van AI.

Het merendeel van onze inkomsten is afkonstig van het hacken (legaal) van andere platformen / producten van grote bedrijven via HackerOne of andere platformen. En ja, wederom met AI. Het is echt onzin om te lezen dat AI niet veilig zou kunnen werken. Het grootste deel van alle bugs en beveiligingslekken wordt gevonden door AI. De AI 'weet' meer van dataveiligheid dan de gemiddelde programmeur. Ik mag geen namen noemen van platformen waarvoor wij lekken vinden, maar ik heb het gevoel dat ik in een andere AI wereld leef dan sommige anderen in dit topic. En die lekken testen we met de hand en blijken inderdaad te kloppen. De suggesties om het op te laten lossen zijn correct.

En AI is niet herhaalbaar? Je laat hem de tooling schrijven zodat het herhaalbaar en te testen is.

Maar het is duidelijk. AI is kut. AI maakt vooral fouten. AI schrijft lelijke code. AI is niet veilig. Ik ga wel uit dit topic

[hackerhater]

Zenomyscus schreef op zondag 4 oktober 2026 @ 11:57:
[...]

Onze online omgeving staat volledig los van de lokale omgeving. De AI kan daar ook absoluut niet bij, want de AI doet ook zeker dingen die ik absoluut niet wil met die data. In onze omgeving is het niet moeilijk om met nepdata te werken, maar ik heb dan ook geen product in de financiele wereld of iets wat met NASA te maken heeft. Neemt niet weg dat wij ook persoonsgegevens en andere belangrijke gegevens verwerken en we dus goed met die data om moeten gaan. Dat doen we al jaren en staat los van AI.

Het merendeel van onze inkomsten is afkonstig van het hacken (legaal) van andere platformen / producten van grote bedrijven via HackerOne of andere platformen. En ja, wederom met AI. Het is echt onzin om te lezen dat AI niet veilig zou kunnen werken. Het grootste deel van alle bugs en beveiligingslekken wordt gevonden door AI. De AI 'weet' meer van dataveiligheid dan de gemiddelde programmeur. Ik mag geen namen noemen van platformen waarvoor wij lekken vinden, maar ik heb het gevoel dat ik in een andere AI wereld leef dan sommige anderen in dit topic. En die lekken testen we met de hand en blijken inderdaad te kloppen. De suggesties om het op te laten lossen zijn correct.

En AI is niet herhaalbaar? Je laat hem de tooling schrijven zodat het herhaalbaar en te testen is.

Maar het is duidelijk. AI is kut. AI maakt vooral fouten. AI schrijft lelijke code. AI is niet veilig. Ik ga wel uit dit topic

LLM's zijn goed in het vinden van lekken dat geef ik toe.
Net als fuzzle tools goed zijn in het vinden van rare bugs.
Maar daadwerkelijk onderhoudbare en veilige code schrijven? Not so much.
De meeste hier zitten aan de andere kant van de tafel. Diegene die de code schrijven waar jij en je collega's tegen testen.

Note: ik heb het als een persoonlijke professionele standaard dat pentesters NIKS vinden.
Ik werk zelf met privacy gevoelige gegevens. Denk medische data, financiele data, etc. Ik heb zelfs een keer meegedinged naar een klus voor de NAVO.
Dat was letterlijk een geval van: "There come the man in black" (lees AIVD screening).

Snelheid is in mijn werkgebied van ondergeschikt belang.

[Zenomyscus]

hackerhater schreef op zondag 4 oktober 2026 @ 11:48:
[...]

1 grote vraag: weet je uberhaupt wat de code doet?
Bij mijn klant was er ook zo iemand die alles door een LLM liet genereren.
Well het is zo'n grote puinzooi dat de klant nu is het kijken dat of ze mij en een andere freelancer gaan betalen het te fixen (naast de huidige klus) of alles weg knikkeren van de laatste 2 maanden.

Ja. Inchecken / commits doe ik zelf. Wat ik aangeef is dat ik merk dat aanpassingen van mijn kant steeds minder worden en er steeds minder code aangepast hoeft te worden. Enkele maanden geleden heb ik nog regelmatig alles moeten reverten omdat het resultaat nergens op sloeg. Maar inmiddels is dat, met de nodige investering in mijn setup, niet nodig. Natuurlijk stuur ik bij en ben ik actief betrokken bij het plannen en het eindresultaat. Mijn hoeveel werk om bij te sturen wordt gewoon steeds minder en als ik iets tegenkom investeer ik graag wat tijd om dat lokaal te verbeteren (indien mogelijk).

Ik werk aan 1 ding tegelijk. Maar ik kan ondertussen wel analyses laten doen. Of alvast een plan laten schrijven. Of reviews laten doen. Of een proof of concept laten maken van iets.

Veel van onze features zijn bijvoorbeeld opgebouwd uit bepaalde modellen. Het kost mij een hoop tijd die modellen te maken. Naar de AI doet dat enorm snel. Ik heb een skill die dat uitwerkt. Dan is het eindresultaat 100% zoals ik het zou schrijven of in het verleden zonder AI is geschreven. Dat controleer ik en dan check ik dat in. Werkelijk 0 verschil met handgeschreven code op dat vlak. Daar waar hij zelf wat moet bedenken is de kwaliteit ook goed.

[ZpAz]

AI zal altijd beter zijn in het vinden van lekken dan het reparareren van lekken onder gelijke omstandigheden. Grofweg (ja ik begrijp er is nuance):

- Je hoeft maar één lek te vinden en je bent binnen, je moet alle lekken dichten om veilig te zijn
- Om een lek te dichten moet je hem OOK vinden

[hackerhater]

Of te wel: je moet dat ding constant aan het handje houden alsof het een stagair is.
Ook keep in mind: Ik ben een freelancer. Ik ben ergens mischien 1 of 2 jaar en dan ben ik weer weg.

Hypergespecialiseerde modellen zijn nutteloos voor mij. Buiten dat de code in een non-local ding duwen een big no-no is.
Mijn kracht is niet de snelheid waarmee ik code schrijf. Mijn kracht is mijn hele sterke analytische kant met het vermogen om specs uit de raarste dingen te achterhalen.

[ Voor 78% gewijzigd door hackerhater op 04-10-2026 12:15 ]

[Zenomyscus]

hackerhater schreef op zondag 4 oktober 2026 @ 12:11:
Of te wel: je moet dat ding constant aan het handje houden alsof het een stagair is.

Correct en dat wordt steeds minder. De AI is wel een stagair die inmiddels op senior niveau code oplevert en alles zelfstandig kan vinden en analyseren. Als een feature meerdere projecten raakt dan pakt de AI ze allemaal aan. Het gebeurde mij nog regelmatig dat ik dan zelf iets vergat wanneer ik zoiets moest doen. Die AI vergeet dat niet. En dan ken ik het systeem door en door.

Zelfs met mijn controles gaat dat 10x zo snel als eerst. Een echte stagair is niet zo snel. Het enige nadeel is dat het wel enorm veel energie vreet. Ik moet bewust pauzes nemen, want anders blijf ik als een rakket doorgaan. Dat heeft inmiddels al wat problemen opgeleverd (mentaal en lichamelijk).

[hackerhater]

Het is geen AI. Noem die fancy code generators geen AI.
Dat is een belediging voor het meer serieuze onderzoeksveld.

Ja het kan snel code genereren. Soms komt er ook wat nuttigs uit.
Maar er zit 0 inteliigentie achter. 0 creativiteit. Het snapt geen context, het snapt geen geschiedenis. Het kan zich niet verplaatsen in de gedachten van wat iemand probeerde te doen.

En om die fancy teksten te genereren verstookt het ook nog enorme grote hoeveelheden electricteit en water.

[ Voor 13% gewijzigd door hackerhater op 04-10-2026 12:23 ]

[DevWouter]

Lethalis schreef op zondag 4 oktober 2026 @ 10:49:
@DevWouter Onze Windows Forms code staat vol met if statements "doe dit alsjeblieft niet in design mode"

Het probleem ontstaat bij het openen van het form. Zelfs als je daarna meteen de IDE kill zonder ook maar iets te doen was de schade al gedaan.

Wat je beschrijft, kan namelijk net zo hard met C# gebeuren en is gewoon Windows Forms designer ellende.

Het was compile vb, daarna decompile in C# en daarna kwam het probleem nooit voor.

Waarschijnlijk heb je de echte bug per ongeluk opgelost met de rewrite.

Nope, het was een bug in de serializer en deserializer van de form designer. Blijkbaar schreef hij altijd terug nadat hij gedeserialized had. Volgens mij vond ik dat uiteindelijk ook terug in de release notes van een latere Visual Studio, maar helaas was die niet compatible met het project.

Maar goed, ik ben op mijn werk de meest negatieve over AI, dus het voelt een beetje gek om de discussie met jullie te voeren dat het soms wel handig kan zijn.

Waar je mee omgaat word je mee besmet
Zonder dollen, ik denk dat veel programmeurs veel gevoeliger zijn voor manipulatie dan dat ze durven te erkennen. Ik denk dat iedere programmeur met wat jaartjes ervaring wel verhalen ken waarbij iemand vol overtuiging voor een optie pleit met de overtuiging dat ze er wel overwogen en objectief zijn. Althans, als ik er over nadenk dan ken ik geen enkele collega die daar last van heeft. Ook ik niet, trouwens.

Met Angular signals heb ik nog geen issues gehad trouwens, maar heb ook geen realtime updates nodig gehad in de applicaties die ik ermee gemaakt heb. Wel vind ik het naar hoe vaak Angular verandert. Dat is niet bij te houden in een groter project en de automatische migraties gaan vaak fout of doen niet alles.

Het is eerder dat het onbetrouwbaar is qua timing waardoor het automatisch events afvuurt (of soms overslaat). Om je een beter beeld te geven: De architectuur pusht nagenoeg exclusief data naar de client dmv websockets ipv dat de client het pullt van de server. RxJs heeft garanties over hoe het informatie verwerkt en timing, signal niet.

[Gropah]

Zenomyscus schreef op zondag 4 oktober 2026 @ 12:18:
[...]

Correct en dat wordt steeds minder. De AI is wel een stagair die inmiddels op senior niveau code oplevert en alles zelfstandig kan vinden en analyseren. Als een feature meerdere projecten raakt dan pakt de AI ze allemaal aan. Het gebeurde mij nog regelmatig dat ik dan zelf iets vergat wanneer ik zoiets moest doen. Die AI vergeet dat niet. En dan ken ik het systeem door en door.

Zelfs met mijn controles gaat dat 10x zo snel als eerst. Een echte stagair is niet zo snel. Het enige nadeel is dat het wel enorm veel energie vreet. Ik moet bewust pauzes nemen, want anders blijf ik als een rakket doorgaan. Dat heeft inmiddels al wat problemen opgeleverd (mentaal en lichamelijk).

Wat mij nog wel eens breekt over LLM output is dat het vooral veel output lijkt te prefereren over het hergebruiken van code. Dan zet ie business logica op meerdere plekken, of copy/paste ie hele chains aan functionele operaties en data extracties in plaats van hergebruik van wat ie (soms zelf) al heeft (gemaakt).

Daar komt ook bij dat context erg belangrijk is, waardoor het (zeker in grote projecten) erg veel uitleg nodig heeft over waarom of hoe iets werkt, en als je dat niet goed doet het vaak echt een gat graaft voor zichzelf.

[Zenomyscus]

ZpAz schreef op zondag 4 oktober 2026 @ 12:11:
AI zal altijd beter zijn in het vinden van lekken dan het reparareren van lekken onder gelijke omstandigheden. Grofweg (ja ik begrijp er is nuance):

- Je hoeft maar één lek te vinden en je bent binnen, je moet alle lekken dichten om veilig te zijn
- Om een lek te dichten moet je hem OOK vinden

Of je statement waar is of niet weet ik niet. Maar 'lekken' zijn over het algemeen een stuk complexer dan één lek vinden. Hoewel we uiteraard domme dingen tegenkomen zoals XSS of SQL-injection (zelden overigens) gaat het vaak om 'lekken' die bestaan uit meerdere stappen waarbij de simpele problemen geen factor zijn. Soms zijn die stappen niet eens fout, maar kun je ze binnen de context van de applicatie misbruiken. De meeste dingen die wij vinden zijn potentieel te misbruiken. Pas als je een keten van te misbruiken fouten vind kun je echt spreken van een lek. Als we dat vinden levert dat ook gelijk het meeste geld op. In veel gevallen hoef je dus niet per se een lek te vinden, maar kun je een platform of product verbeteren door de 'potentieel te misbruiken fouten' eruit te halen. Dat is prima te doen zonder te weten wat er lek is. De zin 'om een lek op te lossen moet je hem ook vinden' heeft dus zeker nuance nodig. Want zodra je een van de stappen uit de keten oplost is je lek dicht. Dat geldt ook als er nog verbeterpunten open blijven staan die gemist worden (of waarvan nog niet bekend is dat het een probleem is). Natuurlijk wil je dat het liefst verbeteren. Maar ik vond het leuk om hier een nuance in aan te brengen, simpelweg omdat ik het een leuk onderdeel van mijn werk vind.

[Kalentum]

Zenomyscus schreef op zondag 4 oktober 2026 @ 10:57:
Her verbaast me een beetje om ook nu nog zoveel negatieve dingen te lezen over LLMs. De meeste kritiek die ik lees is voor mij inmiddels alweer een tijd geleden. De meeste problemen die ik hier lees heb ik niet (meer). Ik heb inmiddels tussen 10 en bijna 20 jaar ervaring met bepaalde talen.

Iedereen redeneert vanuit de eigen ervaring en context. Ik zit zelf bij een werkgever waarvan AI ook onderdeel is van het product voor onze klanten. Het bedrijf heeft in de afgelopen 2 jaar een omslag gemaakt en nu is het AI-first: Altijd hulp van whatever LLM inroepen. Dit geldt voor alle functies: ook voor sales, CS en marketing. En ook voor product en egineering.

Ik behoor tot de sceptici maar er worden regelmatig demo's enzo gegeven en sinds eigenlijk dit jaar ben ik ook van 'het is allemaal crap' naar 'AI-first' gegaan. Waarbij ik vaak het hele proces (van issue tot aan pull request) door AI laat doen en ik review dan alles. De code, de docuumentatie, database structuur aanpassingen, alles.

Bij ons op het werk is het nu allemaal AI-first en vanuit de directie is ook aangegeven dat het leer- en adaptietempo voor iedereen anders is.

[ThomasG]

Sinds pak en beet eind 2025/begin 2026 is AI qua code heel veel vooruit gegaan. Dat kun je niet meer vergelijken met de situatie uit 2022-2024, etc. Je kunt er als developer van alles van vinden, maar het is gewoon een realiteit dat je er niet meer omheen kunt. Dat betekend niet dat we allemaal vervangen worden. Je kunt dat meer zien als een boerenbedrijf: de paarden worden vervangen door een tractor. Je kunt in dezelfde tijd veel meer werk verzetten. En als je niet mee gaat, werk je jezelf uiteindelijk de markt uit.

[Zenomyscus]

Gropah schreef op zondag 4 oktober 2026 @ 13:13:
[...]


Wat mij nog wel eens breekt over LLM output is dat het vooral veel output lijkt te prefereren over het hergebruiken van code. Dan zet ie business logica op meerdere plekken, of copy/paste ie hele chains aan functionele operaties en data extracties in plaats van hergebruik van wat ie (soms zelf) al heeft (gemaakt).

Daar komt ook bij dat context erg belangrijk is, waardoor het (zeker in grote projecten) erg veel uitleg nodig heeft over waarom of hoe iets werkt, en als je dat niet goed doet het vaak echt een gat graaft voor zichzelf.

Wat je zegt klopt helemaal. Een van de dingen waar ik feedback op moet geven is precies wat je schrijft. Dat proces is echter te verbeteren. Wij hebben zat frontend componenten, maar als een LLM dat kopieert dan word ik daar niet vrolijk van. Er draaien bij mij tools mee die dat herkennen en gelijk een stop hook aanroepen bij de LLM. De LLM 'krijgt op zijn flikker' en past het gelijk aan. Dat is precies waarom ik eerder aangaf dat mijn collega slechte output krijgt bij dezelfde prompt, met hetzelfde model, op dezelfde codebase. Iedere keer als ik de afgelopen tijd dacht 'wat ongelofelijk slecht of irritant is dit' ben ik gaan zoeken naar een verbetering. Dat heeft op veel vlakken geholpen, waardoor de hoeveelheid ingrepen en het handje vasthouden een stuk minder is geworden.

Met het laatste wat je schrijft ben ik het mee eens. Wij hadden de mazzel om de codebase al aan te passen voordat het hele AI / LLM gebeuren meer en meer gebruikt werd. Ik heb anderhalf jaar lang refactoring gedaan zonder LLM en toen gelukkig de juiste keuzes gemaakt. We hebben bepaalde keuzes gemaakt waar (achteraf) een LLM erg goed mee overweg kan. Ik word wel eens gevraagd mee te kijken bij projecten (mijn enthousiasme valt op bij anderen) omdat bijvoorbeeld Claude Code niet handig te gebruiken is en dan is het vaak al snel duidelijk dat bepaalde onderdelen van een codebase erg lastig zijn voor een LLM. Dat is niet iets wat ik dan voor ze kan oplossen met een betere setup.

[ZpAz]

Zenomyscus schreef op zondag 4 oktober 2026 @ 13:24:
[...]

Of je statement waar is of niet weet ik niet. ... Maar ik vond het leuk om hier een nuance in aan te brengen, simpelweg omdat ik het een leuk onderdeel van mijn werk vind.

Oh absoluut, het was een beetje een simplificatie. Een enkele vector maakt nog geen chain. Ook heeft de verdediger vaak de blueprints wat het ook makkelijker maakt.

[SPee]

Lethalis schreef op zondag 4 oktober 2026 @ 10:49:
Met Angular signals heb ik nog geen issues gehad trouwens, maar heb ook geen realtime updates nodig gehad in de applicaties die ik ermee gemaakt heb. Wel vind ik het naar hoe vaak Angular verandert. Dat is niet bij te houden in een groter project en de automatische migraties gaan vaak fout of doen niet alles.

Ik ben momenteel bezig met een Angular upgrade. Dat heb ik AI laten uitvoeren en die heeft dat in een uur gedaan. Die heeft ook alles herschreven naar signals. Op zich heb ik daar geen problemen mee. Maar wat die ook heeft gedaan, is dus alles herformatteren. Dus ik zit nu met bestanden waar bijna de gehele inhoud is veranderd.
Ik ben nu dus alles aan het nalopen om te controleren of die niet stiekum ook andere aanpassingen heeft gedaan. En om code waar alleen de indentatie van is gewijzigd weer terug te zetten. Anders krijg ik alle git blame.

Op zich hebben we hier ruim de tijd voor. Er is een schatting gemaakt, maar daar is geen rekening gehouden met AI en hoeveel die alles kan versnellen. Ik heb al een andere feature waar 4,5 week voor stond in 4,5 dag afgerond (met een beetje van mezelf en een beetje van AI). Dus we lopen ruim voor qua planning. Dus wij kunnen onze klant geruststellen dat een release in december mogelijk is.

Ik loop nog wel steeds alles wat AI doet na. De vorige keer heb ik AI gebruikt om een component op te splitsen en beter begrijpbaar te maken. Het zat vol met Promises (op de oude manier) en via signals is dat een stuk overzichtelijker en betrouwbaarder geworden. Alleen sloop er wel een foutje in, wat resulteerde in twee bugs. Eerste bug koste veel tijd om uit te zoeken, pas toen de tweede bug een paar dagen later werd gemeld zag ik het probleem en was het snel opgelost.

[DevWouter]

Zenomyscus schreef op zondag 4 oktober 2026 @ 10:57:
(...) Alsof je elke 3 dagen een grote feature afmaakt waar je normaal een maand over zou doen!? Nou je raad het al, inmiddels komt hier elke 3 dagen een grote feature van de grond. (...)

Als je dat een jaar volhoudt dan heb je een jaar tijd (365/7)*5)/3=86 nieuwe "grote features" per jaar. Ik ben overtuigd dat product dat zoiets vertoond nog maar kort bestaat of een gigantisch probleem heeft. De enige uitzondering die ik op die regel ken is het produceren van white-labels of rapporteren maar dat beschouw ik configuratiewerk, of one-time tools die binnen een maand verdwijnen/vervangen worden.

Los van mijn twijfel (want daar kunnen verschillende verklaringen voor zijn). Stel je voor dat een product dat je vaak gebruikt elke week minimaal twee grote features introduceert. Dan wordt je als gemiddeld gebruiker compleet gek. De meeste mensen gebruiken 90% van de tijd maar 10% van de features.

Zenomyscus schreef op zondag 4 oktober 2026 @ 12:18:
Zelfs met mijn controles gaat dat 10x zo snel als eerst. Een echte stagair is niet zo snel. Het enige nadeel is dat het wel enorm veel energie vreet. Ik moet bewust pauzes nemen, want anders blijf ik als een rakket doorgaan. Dat heeft inmiddels al wat problemen opgeleverd (mentaal en lichamelijk).

En dat is een kenmerk van ongezonde product ontwikkeling. Het feit dat het zelfs lichamelijk impact op je heeft is echt een teken dat je eigenlijk te laat ben met je gedrag te veranderen.

[DevWouter]

Kalentum schreef op zondag 4 oktober 2026 @ 13:26:
Ik behoor tot de sceptici maar er worden regelmatig demo's enzo gegeven en sinds eigenlijk dit jaar ben ik ook van 'het is allemaal crap' naar 'AI-first' gegaan. Waarbij ik vaak het hele proces (van issue tot aan pull request) door AI laat doen en ik review dan alles. De code, de docuumentatie, database structuur aanpassingen, alles.

En dat is juist waar psychologen al een tijd lang voor waarschuwen. Het gebruik van AI is voldoende om het gedrag van een persoon te veranderen, ook van mensen die sceptici zijn.

• https://www.sciencedirect.com/science/article/pii/S0001691825010388
• https://www.psychologytoday.com/au/blog/the-algorithmic-mind/202505/ai-weakens-critical-thinking-and-how-to-rebuild-it

Overigens ben ik van mening dat hoe de mens AI gebruikt compleet crap is. Mijn probleem met LLMs is namelijk niet de LLM zelf.

[Zenomyscus]

DevWouter schreef op zondag 4 oktober 2026 @ 15:45:
[...]

Als je dat een jaar volhoudt dan heb je een jaar tijd (365/7)*5)/3=86 nieuwe "grote features" per jaar. Ik ben overtuigd dat product dat zoiets vertoond nog maar kort bestaat of een gigantisch probleem heeft. De enige uitzondering die ik op die regel ken is het produceren van white-labels of rapporteren maar dat beschouw ik configuratiewerk, of one-time tools die binnen een maand verdwijnen/vervangen worden.

Los van mijn twijfel (want daar kunnen verschillende verklaringen voor zijn). Stel je voor dat een product dat je vaak gebruikt elke week minimaal twee grote features introduceert. Dan wordt je als gemiddeld gebruiker compleet gek. De meeste mensen gebruiken 90% van de tijd maar 10% van de features.


[...]

En dat is een kenmerk van ongezonde product ontwikkeling. Het feit dat het zelfs lichamelijk impact op je heeft is echt een teken dat je eigenlijk te laat ben met je gedrag te veranderen.

Dat laatste klopt, dus daar heb ik inmiddels het een en ander bewust aan veranderd. Inmiddels gaat het een stuk beter. Al had ik daar wel een vakantie voor nodig om om te vallen en weer rustiger verder te gaan. Het is erg gemakkelijk om toch even de laptop te pakken en de output te controleren. Ik vind het ook leuk om te doen, dus dan doe je dat een stuk sneller. En dan toch even testen en wat aanpassingen doen.. Dat proces herhaalt zich een paar keer en dan kun je het ook wel even inchecken nadat je de code hebt gezien. Afijn, dat 'even kijken' werd dus 3 uur. Ook op zaterdag, of zondag. Dat soort dingen zijn op te lossen door dat bewust niet te doen. Morgen weer een dag, ook al zou ik er graag nog naar kijken.

Wat betreft die features, de term dekt niet helemaal de lading. Los van dat we daadwerkelijk veel features kunnen maken, zijn er ook veel zaken die voor ons van belang zijn. Features voor de admin zegmaar. Maar ook features om het product als white label aan te bieden etc. Dat zijn allemaal vrij grote ingrepen die verder geen impact hebben op onze gebruikers. Anderzijds is ons product ook uitgebreid waarmee we met hetzelfde product een andere klantengroep aanspreken. Dat staat los van elkaar en geeft vooral ons meer mogelijkheden.

En uiteraard allerlei feedback van klanten waar we eindelijk aan kunnen werken, voorheen hadden we daar de tijd niet voor. Maar een 'feature' zoals ik het noemde kan ook een refactor zijn. Een migratie in ons framework of gewoon een performance boost. Genoeg te doen zonder dat de klant gek wordt van een product dat veranderd. Onze kennisbank was ook waardeloos en daar wordt ook gewerkt. Compleet met videos etc. Passen we nu een onderdeel aan in onze codebase dan wordt ook de documentatie aangepast en doen we een re-run van het videoscript die er bij hoort. Het duurde even voordat dat goed werkte, maar dat scheelt ons inmiddels enorm veel tijd.

We hebben ook bepaalde features opnieuw gebouwd die voorheen code van een derde partij gebruikte. Het eindresultaat is hetzelfde of beter omdat het nu beter aansluit op de rest en wij betalen een licensie minder. Dat soort dingen zou ik normaal niet gedaan hebben, dan betaal je liever voor een product omdat je geen tijd hebt dat allemaal zelf te implementeren. Het kon allemaal wel, maar het was niet interessant omdat het teveel tijd kost. Dat soort wensen hebben we genoteerd en nu is er tijd om ook die dingen aan te pakken. Ik noemde het 'features' omdat ik er verder niet te diep op in wilde gaan.

Dat geeft mij absoluut het gevoel 10 keer zo snel te gaan.

[DevWouter]

Zenomyscus schreef op zondag 4 oktober 2026 @ 16:39:
[...]

Dat laatste klopt, dus daar heb ik inmiddels het een en ander bewust aan veranderd. Inmiddels gaat het een stuk beter. Al had ik daar wel een vakantie voor nodig om om te vallen en weer rustiger verder te gaan. Het is erg gemakkelijk om toch even de laptop te pakken en de output te controleren. Ik vind het ook leuk om te doen, dus dan doe je dat een stuk sneller. En dan toch even testen en wat aanpassingen doen.. Dat proces herhaalt zich een paar keer en dan kun je het ook wel even inchecken nadat je de code hebt gezien. Afijn, dat 'even kijken' werd dus 3 uur. Ook op zaterdag, of zondag. Dat soort dingen zijn op te lossen door dat bewust niet te doen. Morgen weer een dag, ook al zou ik er graag nog naar kijken.

Allereerst, goed om te horen. En ik snap het ook allemaal wel. Werk kan verslavend zijn. Het is voor mij ook een reden waarom dat ik een hobby heb want anders zou ik ook de hele tijd doorgaan.

Wat betreft die features, de term dekt niet helemaal de lading. Los van dat we daadwerkelijk veel features kunnen maken, zijn er ook veel zaken die voor ons van belang zijn. Features voor de admin zegmaar. Maar ook features om het product als white label aan te bieden etc. Dat zijn allemaal vrij grote ingrepen die verder geen impact hebben op onze gebruikers. Anderzijds is ons product ook uitgebreid waarmee we met hetzelfde product een andere klantengroep aanspreken. Dat staat los van elkaar en geeft vooral ons meer mogelijkheden.

En uiteraard allerlei feedback van klanten waar we eindelijk aan kunnen werken, voorheen hadden we daar de tijd niet voor. Maar een 'feature' zoals ik het noemde kan ook een refactor zijn. Een migratie in ons framework of gewoon een performance boost. Genoeg te doen zonder dat de klant gek wordt van een product dat veranderd. Onze kennisbank was ook waardeloos en daar wordt ook gewerkt. Compleet met videos etc. Passen we nu een onderdeel aan in onze codebase dan wordt ook de documentatie aangepast en doen we een re-run van het videoscript die er bij hoort. Het duurde even voordat dat goed werkte, maar dat scheelt ons inmiddels enorm veel tijd.

We hebben ook bepaalde features opnieuw gebouwd die voorheen code van een derde partij gebruikte. Het eindresultaat is hetzelfde of beter omdat het nu beter aansluit op de rest en wij betalen een licensie minder. Dat soort dingen zou ik normaal niet gedaan hebben, dan betaal je liever voor een product omdat je geen tijd hebt dat allemaal zelf te implementeren. Het kon allemaal wel, maar het was niet interessant omdat het teveel tijd kost. Dat soort wensen hebben we genoteerd en nu is er tijd om ook die dingen aan te pakken. Ik noemde het 'features' omdat ik er verder niet te diep op in wilde gaan.

Dat geeft mij absoluut het gevoel 10 keer zo snel te gaan.

Ah duidelijk, dit klinkt een stuk gezonder (voor jou en je gebruikers)

[Kalentum]

DevWouter schreef op zondag 4 oktober 2026 @ 16:30:
[...]

En dat is juist waar psychologen al een tijd lang voor waarschuwen. Het gebruik van AI is voldoende om het gedrag van een persoon te veranderen, ook van mensen die sceptici zijn.

• https://www.sciencedirect.com/science/article/pii/S0001691825010388
• https://www.psychologytoday.com/au/blog/the-algorithmic-mind/202505/ai-weakens-critical-thinking-and-how-to-rebuild-it

Hoe ga jij van 'ik review alles' (= kritisch nadenken) naar 'je denkt niet meer kritisch'?

[ Voor 29% gewijzigd door Kalentum op 04-10-2026 19:47 ]

[ThomasG]

DevWouter schreef op zondag 4 oktober 2026 @ 16:30:
[...]

En dat is juist waar psychologen al een tijd lang voor waarschuwen. Het gebruik van AI is voldoende om het gedrag van een persoon te veranderen, ook van mensen die sceptici zijn.

• https://www.sciencedirect.com/science/article/pii/S0001691825010388
• https://www.psychologytoday.com/au/blog/the-algorithmic-mind/202505/ai-weakens-critical-thinking-and-how-to-rebuild-it

Overigens ben ik van mening dat hoe de mens AI gebruikt compleet crap is. Mijn probleem met LLMs is namelijk niet de LLM zelf.

Dat geldt voor veel meer dingen. Wat dat betreft is er groter probleem dan AI: social media, en ouders die hun kinderen geen aandacht geven, maar op 3 jarige leeftijd al een iPad zodat ze kun klep houden.

[farlane]

Kalentum schreef op zondag 4 oktober 2026 @ 13:26:
[...]

Ik behoor tot de sceptici maar er worden regelmatig demo's enzo gegeven en sinds eigenlijk dit jaar ben ik ook van 'het is allemaal crap' naar 'AI-first' gegaan. Waarbij ik vaak het hele proces (van issue tot aan pull request) door AI laat doen en ik review dan alles. De code, de docuumentatie, database structuur aanpassingen, alles.

Wie gaat die shit reviewen dan als er door AI geen seniors meers zijn?

[ThomasG]

farlane schreef op zondag 4 oktober 2026 @ 21:47:
[...]

Wie gaat die shit reviewen dan als er door AI geen seniors meers zijn?

Andere AI natuurlijk Je laat er 3 verschillende AI naar kijken, en als er twee het zelfde resultaat geven neem je dat

[farlane]

Ik zou willen dat ik een andere skill had. Metaal/houtbewerken of iets wat echt productief is en mensen helpt. Bouwvakker, maar dan wel een vakman ofzo...kutzooi.

[edit]

Bijvoorbeeld, een collega geeft in een PR aan dat we feature X niet gaan doen want LLM Y zegt dat het maar Z procent perfomance oplevert.

WTF. Hoeven we tegenwoordig dan niets meer te onderbouwen?


I'm too old for this shit.

[ Voor 43% gewijzigd door farlane op 04-10-2026 21:57 ]

[Koenvh]

Even een hele andere AI: de AIrfryer. Hij staat nu een paar weken op kantoor en het is best een succes... en best gevaarlijk voor m'n lijn

Dat ding heeft blijkbaar ook WiFi (geen idee waarom), en ik kon 't niet laten om 't te proberen - wilde die gelijk een software-update uitvoeren. Ik kan helaas geen changelog vinden van wat er tussen versie 1.0.3 en 4.0.0 is veranderd (Philips HD 9280/70 voor de geïnteresseerden).

Er is blijkbaar ook een airfryer-HACS-integratie voor Home Assistant, en we hebben een Home Assistant op kantoor, maar ik weet nog niet wat ik daarmee zou willen doen.

[farlane]

Koenvh schreef op zondag 4 oktober 2026 @ 21:57:
Even een hele andere AI: de AIrfryer.

Epic. +2

[ThomasG]

farlane schreef op zondag 4 oktober 2026 @ 21:53:
Ik zou willen dat ik een andere skill had. Metaal/houtbewerken of iets wat echt productief is en mensen helpt. Bouwvakker, maar dan wel een vakman ofzo...kutzooi.

[edit]

Bijvoorbeeld, een collega geeft in een PR aan dat we feature X niet gaan doen want LLM Y zegt dat het maar Z procent perfomance oplevert.

WTF. Hoeven we tegenwoordig dan niets meer te onderbouwen?


I'm too old for this shit.

Als dit een echt scenario is, is het geen AI-probleem maar een businessprobleem. Dit is namelijk van hetzelfde kaliber als: het heeft op Feesboek gestaan.

[Puddi Puddin]

farlane schreef op zondag 4 oktober 2026 @ 21:53:
Ik zou willen dat ik een andere skill had. Metaal/houtbewerken of iets wat echt productief is en mensen helpt. Bouwvakker, maar dan wel een vakman ofzo...kutzooi.

[edit]

Bijvoorbeeld, een collega geeft in een PR aan dat we feature X niet gaan doen want LLM Y zegt dat het maar Z procent perfomance oplevert.

WTF. Hoeven we tegenwoordig dan niets meer te onderbouwen?


I'm too old for this shit.

Amateur... Code reviews gebeuren hier door middel van geweldige AI collega's. Alleen deze week al 37 keer een schouder klopje gehad dat ik de beste oplossing versie tweehonderd en dertien duizend had. Ik voel me inmiddels een echte next level engineer het project heeft 6700 groene vinkjes als een ci buikd draait en nog werkt de meest basale functionaliteit niet. Problem for another day... Misschien is Goose Farmer een mooi beroep?

ThomasG schreef op zondag 4 oktober 2026 @ 22:20:
[...]

Als dit een echt scenario is, is het geen AI-probleem maar een businessprobleem. Dit is namelijk van hetzelfde kaliber als: het heeft op Feesboek gestaan.

AI heeft de neiging tot het creëren van een vergrotend effect. Zowel negatief als positief. Durf jij het argument: "Heeft op feesboek gestaan." Aan de dragen in een meet? Ik niet dat is mijn eigen graf.

[ Voor 21% gewijzigd door Puddi Puddin op 04-10-2026 22:34 ]

[Lethalis]

Zenomyscus schreef op zondag 4 oktober 2026 @ 12:18:
[...]

Het enige nadeel is dat het wel enorm veel energie vreet. Ik moet bewust pauzes nemen, want anders blijf ik als een rakket doorgaan. Dat heeft inmiddels al wat problemen opgeleverd (mentaal en lichamelijk).

Dat is een groot probleem en dat ervaar ik ook sinds we meer met AI zijn gaan doen.

Stel je lost 2 bugs op een dag, op de ouderwetse manier. Dan heb je je ingeleefd in 2 projecten, modules, whatever. Gebruik je nu tools waardoor je 10 bugs op een dag fixt, dan moet je mentaal jezelf inleven in 10 verschillende dingen. Daar ga je aan onderdoor.

Maakt niet uit dat het makkelijker is. Het is mentaal gezien extreem veel om mee bezig te zijn.

Ik ben vaak vliegende keep in meerdere projecten omdat ik al te lang bij mijn werkgever zit en dan ben ik soms ook helemaal dood aan het einde van de dag, met 6 verschillende projecten open op mijn computer.

Dat is gewoon ongezond. Dat werk vroeger langer duurde, was eigenlijk dus ook een soort van zelfbescherming.

Sneller is niet beter.

[Lethalis]

farlane schreef op zondag 4 oktober 2026 @ 21:53:
Ik zou willen dat ik een andere skill had.
I'm too old for this shit.

Ik denk serieus na over een plan B inmiddels, terwijl programmeren juist altijd een passie van mij is geweest.

Toen ik ooit voor de keuze Informatica of Werktuigbouwkunde stond na de middelbare school... tsja. Zou wel bizar zijn als ik nu op mijn 45ste alsnog WTB ga doen in de avonduren

Maar ik heb ooit 5 jaar als CAD tekenaar gewerkt met AutoCAD. En als ik nu Revit en Inventor zie... I kinda like it.

[ThomasG]

Lethalis schreef op zondag 4 oktober 2026 @ 22:53:
[...]

Toen ik ooit voor de keuze Informatica of Werktuigbouwkunde stond na de middelbare school... tsja. Zou wel bizar zijn als ik nu op mijn 45ste alsnog WTB ga doen in de avonduren

Maar ik heb ooit 5 jaar als CAD tekenaar gewerkt met AutoCAD. En als ik nu Revit en Inventor zie... I kinda like it.

Niet om heel vervelend te doen, maar je weet dat een groot deel van CAD en BIM ook vervangen gaat worden door AI? Daar zijn de grote spelers al mee bezig.

[ Voor 4% gewijzigd door ThomasG op 04-10-2026 22:57 ]

[Puddi Puddin]

Lethalis schreef op zondag 4 oktober 2026 @ 22:40:
[...]

Dat is een groot probleem en dat ervaar ik ook sinds we meer met AI zijn gaan doen.

Stel je lost 2 bugs op een dag, op de ouderwetse manier. Dan heb je je ingeleefd in 2 projecten, modules, whatever. Gebruik je nu tools waardoor je 10 bugs op een dag fixt, dan moet je mentaal jezelf inleven in 10 verschillende dingen. Daar ga je aan onderdoor.

Maakt niet uit dat het makkelijker is. Het is mentaal gezien extreem veel om mee bezig te zijn.

Ik ben vaak vliegende keep in meerdere projecten omdat ik al te lang bij mijn werkgever zit en dan ben ik soms ook helemaal dood aan het einde van de dag, met 6 verschillende projecten open op mijn computer.

Dat is gewoon ongezond. Dat werk vroeger langer duurde, was eigenlijk dus ook een soort van zelfbescherming.

Sneller is niet beter.

Ik herken het gevoel. Ik werk aan 2 features en 3 bugfixes tegelijkertijd. Continue inlezen, schakelen en beoordelen, compleet gesloopt eind van de dag. Alles wat ik uit spuug heeft geen emotionele waarde meer, waar ik vrijdag avond nog door ging om toch iets op te lossen klap ik nu liever de laptop dicht om lekker te gaan schoffelen. Prive projecten zijn opgedroogd passie is verdwenen.

Wat ik nog wel het meest beangstigend vind is hoe relevant mijn skills en het niveau na een jaar of twee zijn met deze werkwijze. Die gaan nou niet bepaalt voor uit.

ThomasG schreef op zondag 4 oktober 2026 @ 22:57:
[...]

Niet om heel vervelend te doen, maar je weet dat een groot deel van CAD en BIM ook vervangen gaat worden door AI? Daar zijn de grote spelers al mee bezig.

Betwijfel ik, ligt geheel aan de waarde, als daar de maatstaaf slopje hier slopje daar is, copy en pasta, dan is het snel gebeurd inderdaad. Zolang AI mij nog geen goede user experience van de volgorde van velden in een formulier kan geven zie ik hem nog niet heel ver komen met het oplossen van echte problemen in CAD.

[ Voor 16% gewijzigd door Puddi Puddin op 04-10-2026 23:01 ]

[Lethalis]

ThomasG schreef op zondag 4 oktober 2026 @ 22:57:
[...]

Niet om heel vervelend te doen, maar je weet dat een groot deel van CAD en BIM ook vervangen gaat worden door AI? Daar zijn de grote spelers al mee bezig.

De vraag is alleen hoe het alles beinvloedt en dat is nu nog lastig in te schatten. Uiteindelijk gaan alle kantoorbanen eraan als je het zo bekijkt, maar ik krijg van mensen signalen dat het in die sector niet zo hard gaat als in de IT en dat AI meer een hulpmiddel dan een complete vervanging van de bezigheden is.

Maar ook dat is uiteraard een momentopname.

(Ik heb een vrij kort lijntje naar een hoofd engineering bij een serieus bedrijf in de Offshore, dus die is goed op de hoogte )

[ Voor 9% gewijzigd door Lethalis op 04-10-2026 23:08 ]

[ThomasG]

Puddi Puddin schreef op zondag 4 oktober 2026 @ 22:57:
[...]

Betwijfel ik, ligt geheel aan de waarde, als daar de maatstaaf slopje hier slopje daar is, copy en pasta, dan is het snel gebeurd inderdaad. Zolang AI mij nog geen goede user experience van de volgorde van velden in een formulier kan geven zie ik hem nog niet heel ver komen met het oplossen van echte problemen in CAD.

ik heb 10 jaar in de BIM wereld gewerkt (inmiddels niet meer). Ik weet dat ze in ieder geval bij gebouwen met AI bezig zijn. Er is namelijk heel veel winst te behalen met bijvoorbeeld loze ruimtes, efficiëntere indeling qua vloeroppervlak, etc. Het staat nog wel in de kinderschoenen. Ook kan AI in CAD meer dan je denkt.

[ Voor 3% gewijzigd door ThomasG op 04-10-2026 23:09 ]

[DevWouter]

Kalentum schreef op zondag 4 oktober 2026 @ 17:47:
[...]


Hoe ga jij van 'ik review alles' (= kritisch nadenken) naar 'je denkt niet meer kritisch'?

offtopic:
Laten we even uit gaan dat we met "kritisch nadenken" hier het systematisch, analytisch, en rationeel, het vormen van een standpunt is gebaseerd op objectieve en betrouwbare waarneming, en dat denker de vaardigheid en het waarnemingsvermogen heeft om de beoordeling te maken. Want anders wordt dit een semantisch discussie waarbij ik vooral wil bewijzen dat de meeste mensen het gebruiken terwijl ze vooral het tegenovergestelde doen.

Allereerst, ik heb nergens beweerd dat jij een minder programmeur/reviewer ben geworden. Ik wijs je er alleen maar op jouw omschakeling niet zo vreemd is als jij denkt. Het was in elk geval niet bedoeld als aanval op jou als persoon.

Het probleem is tweevoudig: Het eerste probleem is dat iemand geconditioneerd wordt om iets niet zelf te doen, het een logisch gevolg heeft dat die persoon gaat inleveren op diens vaardigheid en kennis. Dit is zowel het standaard klassieke conditionering (reflex) als het standaard operante conditionering (bekrachtiging). Het tweede probleem is dat zelf nadenken afgestraft zal worden. Naar mate iemand vertrouwen krijgt in de tool hoe minder snel die geneigd zal zijn om het in twijfel te trekken. En zelfs als iemand wel een systematisch, analytisch en rationeel proces heeft die elke keer gevolgd wordt dan nog zijn er externe factoren zoals een baas die wilt dat het sneller en eerder opgeleverd wordt.

ThomasG schreef op zondag 4 oktober 2026 @ 18:12:
[...]

Dat geldt voor veel meer dingen. Wat dat betreft is er groter probleem dan AI: social media, en ouders die hun kinderen geen aandacht geven, maar op 3 jarige leeftijd al een iPad zodat ze kun klep houden.

Yep, maar er is ook een reden dat men in de psychologie soms over AI-gebruikers spreekt als een boekhouder die soms een gokje waagt als parabool, het is een stuk problematischer dan de meeste mensen in eerste instantie denken.

Overigens moet ik wel bekennen dat het ongeveer 6 maanden geleden is dat ik dit echt onderzocht heb. Maar wat ik via-via begrepen heb duurt het nog even voordat er empirisch onderzoek gepubliceerd wordt, maar de onderzoekers die er mee bezig zijn zien nog weinige positieve uitkomsten terwijl de negatieve uitkomsten juist extremer lijken te zijn dan gedacht. Hier bij moet ik wel zeggen dat dit informatie uit derde hand is en dat mijn bronnenselectie inmiddels een behoorlijke bias heeft (ondanks dat ik het probeer te vermijden).

De paar AI-positivos die ik in de gaten hou (en oprecht waardeer) gebruiken ChatGPT/Claude/Grok/Whatever amper zoals de meeste ontwikkelaars het doen. Dat is veel meer multimodel of zelfs eigen modellen. Persoonlijk zie ik dat als de toekomst, maar dat is vrij exclusief, en kan eigenlijk niet als algemene dienst aangeboden worden gezien het gebruik specialisme vereist.

[Firesphere]

Afgelopen Vrijdag, en vandaag, een berg AI-code reviewen.

Wat een ongelofelijke berg rotzooi zeg. S3 parsers links an rechts, op 3 verschillende manieren in dezelfde class een verbinding met AWS opzetten, met 3 verschillende libraries. En geen van de libraries is the AWS SDK.

En dat gaat dan voor bijna elke methode. Alles is minstens 1x dubbel, maar subtiel anders, en dan zeggen "AI generated, I reviewed it"? Ik geloof er geen bal van dat er meer dan 5 minuten aan "review" in zit, want er is gewoon teveel dat onlogisch is.

Werkt het? Vast, het zalf vast werken, maar dat betekend niet dat het goed, efficient, of veilig is. Want dat is het zeker niet.

[Lethalis]

DevWouter schreef op maandag 5 oktober 2026 @ 00:00:
[...]

Het eerste probleem is dat iemand geconditioneerd wordt om iets niet zelf te doen, het een logisch gevolg heeft dat die persoon gaat inleveren op diens vaardigheid en kennis.

Ik ben opgegroeid met Duitse ouders en ik heb de eerste 23 jaar van mijn leven veel Duits gesproken, totdat ik het ouderlijke huis verliet en daarna ook minder contact met mijn ouders had. Sindsdien heb ik nog wel Duitse artikelen gelezen, Duitse documentaires gekeken, het Duitse nieuws gekeken, en Duitse YouTube filmpjes gekeken (o.a. over programmeren etc).

Je zou denken dat ik nu nog steeds goed Duits kan praten, toch?

Nope. Ik kom niet uit mijn woorden, want ik heb het in feite al 22 jaar nauwelijks nog zelf gesproken. Ik versta alles, ik begrijp alles, maar als ik het zelf moet gaan praten... oef.

Zo gaat het straks ook met programmeren als je het niet meer zelf doet. In ieder geval bij mij dan vrees ik.

Wel geloof ik er in dat als je mij een paar maanden in Duitsland parkeert en ik het elke dag moet gaan praten dat het al gauw weer een stuk beter wordt. En dat is dan met zelf programmeren hopelijk ook zo.

PS
Overigens gaat het met programmeertalen net zo. Ik heb jarenlang C++ gedaan in het begin van mijn loopbaan en heb vorig jaar eens geprobeerd wat dingen met C++ te bouwen. Nou dat is wel even schrikken hoor als je de hele tijd vooral .NET (VB en C#) gedaan hebt.

[ Voor 18% gewijzigd door Lethalis op 05-10-2026 08:42 ]

[Lethalis]

Firesphere schreef op maandag 5 oktober 2026 @ 00:20:
Afgelopen Vrijdag, en vandaag, een berg AI-code reviewen.

Wat een ongelofelijke berg rotzooi zeg. S3 parsers links an rechts, op 3 verschillende manieren in dezelfde class een verbinding met AWS opzetten, met 3 verschillende libraries. En geen van de libraries is the AWS SDK.

En dat gaat dan voor bijna elke methode. Alles is minstens 1x dubbel, maar subtiel anders, en dan zeggen "AI generated, I reviewed it"? Ik geloof er geen bal van dat er meer dan 5 minuten aan "review" in zit, want er is gewoon teveel dat onlogisch is.

Werkt het? Vast, het zalf vast werken, maar dat betekend niet dat het goed, efficient, of veilig is. Want dat is het zeker niet.

Dat is wel erg extreem.

Wat ik wel zie in de gegenereerde code van een collega is dat het niet menselijk aanvoelt. Het gebruik van white space is wat mij betreft niet autistisch verantwoord Maar ik ben dan ook zo'n lul die zich nog druk kan maken om waar een accolade precies staat (nieuwe regel!) en hoeveel lege regels er tussen bepaalde blokken code staan om het overzichtelijk te houden.

Als je die code ziet dan ontbreekt dat volledig. Het is gewoon onder elkaar geprakt en doet pijn aan mijn ogen.

Voor de rest is de code niet rechttoe rechtaan. Codex houdt blijkbaar niet van KISS.

[ Voor 3% gewijzigd door Lethalis op 05-10-2026 08:53 ]

[eheijnen]

Een beetje zoals bij sport, je verleert het niet maar als je meer traint wordt je over het algemeen beter dan die die minder trainen.

[Lethalis]

ThomasG schreef op zondag 4 oktober 2026 @ 23:08:
[...]

ik heb 10 jaar in de BIM wereld gewerkt (inmiddels niet meer). Ik weet dat ze in ieder geval bij gebouwen met AI bezig zijn. Er is namelijk heel veel winst te behalen met bijvoorbeeld loze ruimtes, efficiëntere indeling qua vloeroppervlak, etc. Het staat nog wel in de kinderschoenen. Ook kan AI in CAD meer dan je denkt.

Er zullen allerlei toepassingen zijn waarbij AI een uitkomst is, maar het werk zelf is natuurlijk meer dan dat.

En dat geldt voor ons als software ontwikkelaars net zo natuurlijk. De vraag is alleen dat naarmate een functie verandert, wat je dan nog wel en wat je niet leuk vindt eraan. Ik heb mezelf altijd meer als een techneut gezien en minder als een product owner.

Ik vond het wel prima als een consultant lekker met die klant ging sparren over wat er moest gebeuren en dan deed ik de technische realisatie wel. You see my problem with AI?

Terwijl ik persoonlijk wel graag over technische vraagstukken nadenk. Stel nou dat je hele baan technisch is en je hebt slimmere tools om sneller tekeningen te genereren, maar je blijft eindverantwoordelijk voor het omzetten van een ontwerp of schets naar iets dat technisch gerealiseerd kan worden. Dat vind ik leuker om over te sparren denk ik dan over financiële processen / koppelingen. Het leeft meer voor mij.

Wat ik ook grappig vind, is dat ik hoor dat ingenieurs in de petrochemie / offshore / bouw vaak niet altijd even handig met computers en tools zijn. Dus als ze bijvoorbeeld AutoDesk Revit of Inventor moeten leren, terwijl ze AutoCAD gewend zijn, dan lijken ze vast te lopen en heeft het bedrijf de grootste moeite om mensen te vinden die het wel kunnen. En moet iedereen op cursus en dan lukt het niet, etc.

Voor mij is dat een omgekeerde wereld, want ik vind het leuk om met die software te stoeien. Ik heb vroeger zelfs voor AutoCAD allerlei tools geprogrammeerd.

Dus als ik een technische opleiding zou doen, zodat ik in die sector binnenkom, dan kan ik mij uitleven met die tools. Die kennis van mij toont al interesse terwijl ik de opleiding niet eens heb En in feite zou ik dan hetzelfde doen als mijn vader.

Die was ingenieur, maar programmeerde ook en was 1 van de eersten die een computer kocht en zichzelf AutoCAD aanleerde. Dus dan is die ICT kennis / feeling ineens een bonus bovenop wat je normaal doet.

Ik vond dat klooien met die computers alleen veel te leuk, waardoor ik van mijn hobby mijn werk heb gemaakt.

Goed. Ik moet het alleen wel allemaal laten bezinken even. Ik lees ook dat steeds meer bedrijven hun AI gebruik minderen, omdat het teveel kost, dus er is ook nog een sprankje hoop dat we kunnen blijven programmeren.

Maar misschien moet ik eens naar een open dag ofzo

[BarôZZa]

Firesphere schreef op vrijdag 2 oktober 2026 @ 02:57:
[...]

Dit is een vrij kortzichtige mening.

Veel ontwikkeling wordt juist gedaan om het leven makkelijker te maken. Of dit nu software is, of hardware, een betere tractor of een website met meer functionaliteit. Het is niet om het mogelijk te maken om met minder mensen te werken.

Dit is ook zichtbaar in andere werkgroepen. Vooruitgang door techniek toe te passen, leidt inderdaad aan de ene kant tot de mogelijkheid om met minder mensen hetzelfde of meer te bereiken. Het leidt echter ook naar nieuwe paden, nieuwe openingen en posities.

Het is niet "IT die mensen overbodig maakt", het is vooruitgang.

Een mooi voorbeeld hiervan is mijn eigen ervaring met een specifiek project. In dit project maakten we het inschrijven voor een nieuwe energie aansluiting makkelijker, en zorgden er voor dat er minder telefoontjes naar de helpdesk waren, met problemen rondom de aansluiting.

Dit leidde echter niet tot een vermindering van personeel op de helpdesk. Een deel van de helpdesk kon worden herplaatst in het team dat de aansluitingen aanstuurde met de netwerkbeheerder. Dit was nodig omdat er meer aanvragen voor aansluitingen kwamen.

Een ander deel was nog steeds nodig op de helpdesk, niet om aansluitingen via telefoon op te lossen, maar omdat het aantal aangesloten huishoudens explosief was toegenomen, waren er meer mensen nodig voor de bemensing van de "normale" helpdesk.

Aan de ene kant maakte mijn team een deel van de helpdesk onnodig, aan de andere kant, zorgden we voor nieuw werk voor diezelfde mensen.

En daarnaast, als een ITer "lachend een opslag krijgt omdat er mensen konden worden ontslagen", dan is die ITer waarschijnlijk niet erg geliefd bij de collega's.

Ah yes, ik ben ook altijd enorm blij als ik de helpdesk zoe en een chatbot krijg die je eerst een kwartier moet verleiden om in contact te mogen komen met een mens. Enorme verbetering voor de gebruiker.

De IT'er die lachend opslag krijgt is natuurlijk een beetje beeldspraak, maar ze zijn jaren lang buiten schot gebleven terwijl zij het mogelijk maakten dat anderen wel konden verdwijnen.

De nieuwe paden en mogelijkheden waren vaak maar voor een select groepje (de werkgever).

Ik zeg niet dat het allemaal geen vooruitgang is (alhoewel vaak ook een achteruitgang voor de ervaring van de eindgebruiker), ik zeg alleen dat IT'ers de laatste zijn die mogen klagen en het het meest verdienen. Dit is onze droom, alles automatisch.

[Lethalis]

DevWouter schreef op zondag 4 oktober 2026 @ 17:31:
[...]

Allereerst, goed om te horen. En ik snap het ook allemaal wel. Werk kan verslavend zijn. Het is voor mij ook een reden waarom dat ik een hobby heb want anders zou ik ook de hele tijd doorgaan.

Het is mij eigenlijk nooit goed gelukt. Programmeren was mijn hobby en werd mijn werk, en bleef mijn hobby.

Ik heb nog een tijd gitaar gespeeld en ben ooit gaan tafeltennissen, maar uiteindelijk eindig ik altijd weer achter mijn computers. Ik wil ook te graag goed in dingen zijn denk ik en ik was maar een matige gitarist ondanks alle tijd die er in ging.

Soms denk ik dan "laat ik piano spelen proberen" maar ik weet nu eigenlijk al hoe dat gaat eindigen

[Firesphere]

BarôZZa schreef op maandag 5 oktober 2026 @ 09:26:
[...]

Ah yes, ik ben ook altijd enorm blij als ik de helpdesk zoe en een chatbot krijg die je eerst een kwartier moet verleiden om in contact te mogen komen met een mens. Enorme verbetering voor de gebruiker.

De IT'er die lachend opslag krijgt is natuurlijk een beetje beeldspraak, maar ze zijn jaren lang buiten schot gebleven terwijl zij het mogelijk maakten dat anderen wel konden verdwijnen.

De nieuwe paden en mogelijkheden waren vaak maar voor een select groepje (de werkgever).

Ik zeg niet dat het allemaal geen vooruitgang is (alhoewel vaak ook een achteruitgang voor de ervaring van de eindgebruiker), ik zeg alleen dat IT'ers de laatste zijn die mogen klagen en het het meest verdienen. Dit is onze droom, alles automatisch.

Je reactie hier, zegt dat je eigenlijk geen flauw idee hebt wat software engineering eigenlijk is, waar het voor is, en wat mensen in dit vakgebied doen.

Wat betreft die droom, die mag je helemaal voor jezelf houden, wat mij betreft.

[.oisyn]

hackerhater schreef op zondag 4 oktober 2026 @ 11:48:
[...]

1 grote vraag: weet je uberhaupt wat de code doet?

Voor productiecode? Altijd. Afgzien van simpele taakjes ben ik het nooit helemaal eens met wat AI produceert, maar met wat itereren komen we er wel (en sneller dan ik dat in zou moeten typen). En wij schrijven medische software.

Voor ondersteunende tools? Couldn't care less. Ik heb in wat vrije uurtjes een profile viewer gevibecode die zo enorm veel beter is dan de brakke in-house tool die al 10 jaar geen update meer heeft gehad. Zonder AI had me dit weken aan devtijd gekost, wat niet te verantwoorden is. Hier telt resultaat meer dan kwaliteit van code (die niet eens zo slecht is).

Danzij AI ben ik productiever dan ooit, en dat is niet eens omdat ik AI alles laat doen, maar omdat ik last heb van iets wat lijkt op executive disfunction en AI een goede sparringspartner is en mij helpt knopen door te hakken en verder te gaan, ipv afgeleid te raken.

[ Voor 36% gewijzigd door .oisyn op 05-10-2026 10:15 ]

[Matis]

Ik sta er hetzelfde in. Schrijf zelf bijna geen code meer, maar zit wel heel dicht op de bal qua code die AI produceert. Ik review zelf altijd de code, voordat ik het ter review aanbied.
Ik vraag het ding ook altijd om eerst een analyse te doen, daarna een plan te maken en vragen te stellen als iets niet duidelijk is. Ook geef ik het mee om geen aannames te doen.
Op basis van de analyse, het plan, de vragen (eventueel met voorbeelden en aanbevelingen) stuur ik hem dan in mijn (interpretatie van) de juiste richting. Daarna zeg ik: succes en gaat hij aan het pruttelen. De code die dat ding oplevert is echt heel goed, voorzien van commentaar (waar nodig of bij uitzonderingen) en erg strikt.
Moet toegeven: De codebases en tech stacks waarop ik momenteel werk, lenen zich daar wel voor. Conform standaarden, gestructureerd en goed gedocumenteerd. Veel publieke kennis waarop het model zich heeft getraind.

Ik heb nog een hard-copy van https://automatetheboringstuff.com/ liggen, tegenswoordig doen we dat met AI

[.oisyn]

Matis schreef op maandag 5 oktober 2026 @ 11:07:
voorzien van commentaar (waar nodig of bij uitzonderingen)

Ik merk dat Claud altijd wel wat zinloos commentaar toevoegt wat verwijst naar de discussie die ik met hem heb gehad, terwijl dat voor iemand die de code leest een stuk minder nuttig is.

Dan is mijn feedback iets als "accepteer hier liever een std::span dan een std::vector zodat het ook werkt als je gewoon een array hebt", en dan insert ie in de doccomment van de functie "dit is een std::span zodat het ook met een array werkt". Ja, duh, dat soort commentaar hoeft nou weer net niet in die van de API. Zet dat lekker in de documentatie die de architectuur bescrhijft ofzo

GPT doet dat een stuk minder.

[ThomasG]

.oisyn schreef op maandag 5 oktober 2026 @ 11:25:
[...]


Ik merk dat Claud altijd wel wat zinloos commentaar toevoegt wat verwijst naar de discussie die ik met hem heb gehad, terwijl dat voor iemand die de code leest een stuk minder nuttig is.

Dan is mijn feedback iets als "accepteer hier liever een std::span dan een std::vector zodat het ook werkt als je gewoon een array hebt", en dan insert ie in de doccomment van de functie "dit is een std::span zodat het ook met een array werkt". Ja, duh, dat soort commentaar hoeft nou weer net niet in die van de API. Zet dat lekker in de documentatie die de architectuur bescrhijft ofzo

GPT doet dat een stuk minder.

Wat vaak beter werkt is om het commentaar pas achter te laten toevoegen. Anders gaat het tijdens wijzigingen opschrijven waarom je het hebt laten wijzigen. Toch schrijf ik het code commentaar bij business logic nog altijd zelf, vooral de rationale. Onze organisatie heeft namelijk overal uitzonderingen op.

[.oisyn]

ThomasG schreef op maandag 5 oktober 2026 @ 11:46:
[...]

Wat vaak beter werkt is om het commentaar pas achter te laten toevoegen. Anders gaat het tijdens wijzigingen opschrijven waarom je het hebt laten wijzigen. Toch schrijf ik het code commentaar bij business logic nog altijd zelf, vooral de rationale. Onze organisatie heeft namelijk overal uitzonderingen op.

Wat ik de laatste tijd vooral doe is dat ik Opus het hele gedetailleerde plan laat uitwerken, en de daadwerkelijke code changes delegeer naar GPT Luna agents. Scheelt ook een hoop credits

[MueR]

Firesphere schreef op maandag 5 oktober 2026 @ 00:20:
Afgelopen Vrijdag, en vandaag, een berg AI-code reviewen.

Wat een ongelofelijke berg rotzooi zeg. S3 parsers links an rechts, op 3 verschillende manieren in dezelfde class een verbinding met AWS opzetten, met 3 verschillende libraries. En geen van de libraries is the AWS SDK.

En dat gaat dan voor bijna elke methode. Alles is minstens 1x dubbel, maar subtiel anders, en dan zeggen "AI generated, I reviewed it"? Ik geloof er geen bal van dat er meer dan 5 minuten aan "review" in zit, want er is gewoon teveel dat onlogisch is.

Werkt het? Vast, het zalf vast werken, maar dat betekend niet dat het goed, efficient, of veilig is. Want dat is het zeker niet.

Junior zeker? Want dit soort dingen is wel een enorme pet peeve als het op AI generated dingen aankomt. Ik spot het ook regelmatig in code die Claude voor me uitpoept, maar een simpele "you're repeating this three times, dry this up" of "why aren't we using the official sdk" lost dat vaak wel op. Beter om vooraf te specificeren natuurlijk, maar zelfs als je het in een agents.md hebt staan negeren ze het nog wel eens.

Eigenlijk het enige wat ik niet self-review zijn AI generated tests. Ik kijk wel naar de code coverage. Want niemand leest graag een paar duizend regels aan unittests.

[MueR]

.oisyn schreef op maandag 5 oktober 2026 @ 12:38:
[...]


Wat ik de laatste tijd vooral doe is dat ik Opus het hele gedetailleerde plan laat uitwerken, en de daadwerkelijke code changes delegeer naar GPT Luna agents. Scheelt ook een hoop credits

Hmm, ik laat vaak juist Sonnet het plan uitwerken (met Opus als backstop indien nodig), dan kan Haiku het inbouwen. Mag Opus nog een keer een review doen. Gaat best aardig vind ik zelf.

[eheijnen]

Misschien nog een leuke vraag aan ChatGpt of er een soort van tweedeling zal ontstaan in de ontwikkelaars wereld.

Will there be a revival of the arts & crafts movement so to speak among software developers? (30 dagen geldig)

https://duck.ai/share/5b0...ywBlYRbfFFWZsssOZ-xalIzh8

[RayNbow]

MueR schreef op maandag 5 oktober 2026 @ 14:05:
Want niemand leest graag een paar duizend regels aan unittests.

Het onderliggende probleem is natuurlijk waarom we duizenden regels aan unittests nodig hebben. Wordt het niet eens tijd dat we bepaald gedrag kunnen abstraheren?

De uitdaging zal natuurlijk zijn hoe we kort en bondig gedrag kunnen abstraheren.

Voor sommige dingen zal dit eenvoudiger zijn dan andere. Zo heb ik voor de Stream class (.NET) een abstracte base-test-class gemaakt. Op die manier kan ik op eenvoudige wijze een MyStream testen door simpelweg de base-test-class te overerven en een paar specifieke methoden te implementeren.

[Kalentum]

eheijnen schreef op maandag 5 oktober 2026 @ 14:30:
Misschien nog een leuke vraag aan ChatGpt of er een soort van tweedeling zal ontstaan in de ontwikkelaars wereld.

Will there be a revival of the arts & crafts movement so to speak among software developers? (30 dagen geldig)

https://duck.ai/share/5b0...ywBlYRbfFFWZsssOZ-xalIzh8

Ik zit minder dan 20 jaar van mijn pensioen. Ik hoop eerder te stoppen met werken.

Ik ga dan op een oude ambachtenmarkt zitten, tussen een klompenmaker en een mandenmaker. Groot scherm mee, laptopje aansluiten en dan ga ik software "schrijven".

Misschien zelfs met een boek erbij. Internetgebruik verboden.

[ Voor 5% gewijzigd door Kalentum op 05-10-2026 14:44 ]

[MueR]

RayNbow schreef op maandag 5 oktober 2026 @ 14:37:
[...]

Het onderliggende probleem is natuurlijk waarom we duizenden regels aan unittests nodig hebben. Wordt het niet eens tijd dat we bepaald gedrag kunnen abstraheren?

De uitdaging zal natuurlijk zijn hoe we kort en bondig gedrag kunnen abstraheren.

Voor sommige dingen zal dit eenvoudiger zijn dan andere. Zo heb ik voor de Stream class (.NET) een abstracte base-test-class gemaakt. Op die manier kan ik op eenvoudige wijze een MyStream testen door simpelweg de base-test-class te overerven en een paar specifieke methoden te implementeren.

Als je een http api aan het testen bent heb je vaak gewoon veel verschillende testcases met valid en invalid input. Dat loopt nog al snel in de regeltjes. Kun je prima wat generieke structs hebben die je tests beschrijven of je testdata bevatten en 1 methode die ze allemaal uitvoert, maar evengoed zijn dat veel regeltjes code.

Granted, ik zie bij ons ook nog al eens tests waarvan ik denk "is dit nou nodig?". Bijvoorbeeld een generiek list/table component wat al helemaal kapotgetest is in de UI library, die vervolgens nog in elke view waar deze gebruikt wordt wordt getest of er wel data in getoond wordt, of de sorting werkt etc. Like, dude. Dat raakt ongeveer elke view in het dashboard. Is dat echt nodig?

[ Voor 16% gewijzigd door MueR op 05-10-2026 14:56 ]

[eheijnen]

Kalentum schreef op maandag 5 oktober 2026 @ 14:43:
[...]


Ik zit minder dan 20 jaar van mijn pensioen. Ik hoop eerder te stoppen met werken.

Ik ga dan op een oude ambachtenmarkt zitten, tussen een klompenmaker en een mandenmaker. Groot scherm mee, laptopje aansluiten en dan ga ik software "schrijven".

Misschien zelfs met een boek erbij. Internetgebruik verboden.

Arts & Crafts was een beweging die zich afzette tegen de industriële revolutie en haar eenheidsworst.
Toch lijkt me zoiets wel mogelijk in de komende tijd. De gemoederen zweven tussen blinde adoptie en wrange afkeer dat mensen hun baan wordt afgepikt door het grote geld....

[ThomasG]

Kalentum schreef op maandag 5 oktober 2026 @ 14:43:
[...]


Ik zit minder dan 20 jaar van mijn pensioen. Ik hoop eerder te stoppen met werken.

Ik ga dan op een oude ambachtenmarkt zitten, tussen een klompenmaker en een mandenmaker. Groot scherm mee, laptopje aansluiten en dan ga ik software "schrijven".

Misschien zelfs met een boek erbij. Internetgebruik verboden.

Ik heb een collega die hier 30 jaar gewerkt heeft en vorig jaar met pensioen is gegaan. Hij vind het eigenlijk wel jammer dat hij met pensioen is, en nu privé met AI aan het spelen is. Toch wel grappig dat de een het leuk en interessant vind, en de ander een erg volledig van walgt.

[DevWouter]

eheijnen schreef op maandag 5 oktober 2026 @ 14:30:
Misschien nog een leuke vraag aan ChatGpt of er een soort van tweedeling zal ontstaan in de ontwikkelaars wereld.

Tabs of spaties?
* DevWouter zet alvast wat schaaltjes met popcorn klaar

Wat serieuzer, er is binnen elke beroep wel meerdere stromingen te vinden. Dat is niks speciaals. Verder moet AI trouwens extreem veel zuiniger worden om een AI-only toekomst mogelijk te maken. Dus tot die tijd heb je hoe dan ook een tweedeling puur uit noodzaak.

[DevWouter]

ThomasG schreef op maandag 5 oktober 2026 @ 15:24:
[...]

Ik heb een collega die hier 30 jaar gewerkt heeft en vorig jaar met pensioen is gegaan. Hij vind het eigenlijk wel jammer dat hij met pensioen is, en nu privé met AI aan het spelen is. Toch wel grappig dat de een het leuk en interessant vind, en de ander een erg volledig van walgt.

Het is ook fantastisch speelgoed

[eheijnen]

@Kalentum @DevWouter etc.
De vraag kan zijn of hier nog niche markten uit naar voren komen. Die zijn vaak te klein om rendabel te zijn voor de industrie.

Wat performance aangaat kan het opkomend gebruik van asics daar nog een rol in gaan spelen.

Bij manden en klompen maken denk ik toch al weer eerder aan experimentele archeologie

[RayNbow]

MueR schreef op maandag 5 oktober 2026 @ 14:52:
[...]

Als je een http api aan het testen bent heb je vaak gewoon veel verschillende testcases met valid en invalid input. Dat loopt nog al snel in de regeltjes. Kun je prima wat generieke structs hebben die je tests beschrijven of je testdata bevatten en 1 methode die ze allemaal uitvoert, maar evengoed zijn dat veel regeltjes code.

Uiteraard. Als er veel terechte testcases zijn, dan correspondeert dat met meer code. Ik zou dan ook niet weten hoe je dat snel beknopter zou kunnen krijgen.

[DevWouter]

eheijnen schreef op maandag 5 oktober 2026 @ 15:39:
@Kalentum @DevWouter etc.
De vraag kan zijn of hier nog niche markten uit naar voren komen. Die zijn vaak te klein om rendabel te zijn voor de industrie.

Wat performance aangaat kan het opkomend gebruik van asics daar nog een rol in gaan spelen.

Bij manden en klompen maken denk ik toch al weer eerder aan experimentele archeologie

Performance != efficiëntie. De beschikbare elektriciteit is de bottleneck. En de aankomende AI-chips zijn nog niet zuinig genoeg om de huidige groei op te vangen, laat staan als iedereen het gaat doen. Je krijgt dus hoe dan ook een mix (tenzij Ai volledig flopt).

[DevWouter]

RayNbow schreef op maandag 5 oktober 2026 @ 15:55:
[...]


Uiteraard. Als er veel terechte testcases zijn, dan correspondeert dat met meer code. Ik zou dan ook niet weten hoe je dat snel beknopter zou kunnen krijgen.

(Cc: @MueR)
Ik heb als regel dat configuratie nooit getest mag worden dmv van unit-tests. Dus meestal als ik met dat soort databinding dingen te maken hebben probeer ik het vooral uit het project te duwen. Is een beetje meer werk, maar daardoor schaalt het project op termijn wel stukken beter.

[eheijnen]

Op dit moment beginnen ze tegen de rente aan te hikken die ze elke maand moeten ophoesten. Ze praten over zo'n 4.1 biljoen aan geleend geld. OpenAI verhoogt de prijzen, Anthropic will asap naar de beurs met een IPO...

Lijkt op een pas op de plaats samen met de regulering die ze samen willen gaan bedrijven....

[Firesphere]

MueR schreef op maandag 5 oktober 2026 @ 14:05:
[...]

Junior zeker? Want dit soort dingen is wel een enorme pet peeve als het op AI generated dingen aankomt. Ik spot het ook regelmatig in code die Claude voor me uitpoept, maar een simpele "you're repeating this three times, dry this up" of "why aren't we using the official sdk" lost dat vaak wel op. Beter om vooraf te specificeren natuurlijk, maar zelfs als je het in een agents.md hebt staan negeren ze het nog wel eens.

Eigenlijk het enige wat ik niet self-review zijn AI generated tests. Ik kijk wel naar de code coverage. Want niemand leest graag een paar duizend regels aan unittests.

Helaas geen junior, maar iemand die zeker beter zou moeten weten

[Firesphere]

DevWouter schreef op maandag 5 oktober 2026 @ 15:25:
[...]

Tabs of spaties?
* DevWouter zet alvast wat schaaltjes met popcorn klaar

;!

[Mugwump]

ThomasG schreef op maandag 5 oktober 2026 @ 15:24:
[...]

Ik heb een collega die hier 30 jaar gewerkt heeft en vorig jaar met pensioen is gegaan. Hij vind het eigenlijk wel jammer dat hij met pensioen is, en nu privé met AI aan het spelen is. Toch wel grappig dat de een het leuk en interessant vind, en de ander een erg volledig van walgt.

Als speelgoed is het leuk. In een professionele context is het binnen de juiste kaders ook erg nuttig. Maar ik merk bij mezelf ook wel enige irritatie / frustratie bij overmatig AI gebruik waarbij mensen zelf de 'monkey in the loop' lijken en van mij de 'human in the loop' maken.

Waar voorheen minder ervaren mensen voor het produceren van een beperkte hoeveelheid code een week nodig hadden, spugen ze nu een veel grotere bak code in een paar uur uit zonder echt te snappen of dat nou echt doet wat het hoort te doen, waarom ontwerpkeuzes zijn gemaakt en wat de consequenties daarvan zijn en ga zo maar door. Ik maak me ook ergens wel een beetje zorgen om het gebrek aan didactisch effect dat deze manier van werken lijkt te hebben. Een niet onbelangrijk deel van je werk als junior of medior (en zelfs als ervaren developer) is dat je leert door te doen.

Feedback die ik geef op MRs is niet primair bedoeld om elke mogelijke bug uit een bak code te vissen, want dat is een illusie. Natuurlijk is het wel de bedoeling om de grootste ellende te voorkomen, maar het is ook een discussie en uitwisseling van gedachten. Mensen denken nu serieus dat ze mijn opmerkingen / vragen moeten beantwoorden door mijn tekst door AI te halen en het antwoord van AI terug te plakken. Dat is toch echt niet de bedoeling.

[Lethalis]

ThomasG schreef op maandag 5 oktober 2026 @ 15:24:
[...]

Ik heb een collega die hier 30 jaar gewerkt heeft en vorig jaar met pensioen is gegaan. Hij vind het eigenlijk wel jammer dat hij met pensioen is, en nu privé met AI aan het spelen is. Toch wel grappig dat de een het leuk en interessant vind, en de ander een erg volledig van walgt.

Als ik met pensioen zou zijn, zou ik het ook leuk vinden hoor.

Ik krijg nu alleen met de gevolgen van AI te maken. Daar kan AI niks aan doen, maar mensen gaan er maar van uit dat je nu 10x zo productief moet zijn, terwijl er juist heel veel tijd zit in het ontwikkelproces die weinig tot niets met de implementatie te maken heeft.

Dus ik voel nu op mijn werk veel meer druk om dingen sneller op te leveren met AI, waar dat voorheen niet zo was en iedereen "begreep" dat je nou eenmaal even bezig was om iets te maken.

Ik heb geen hekel aan AI zelf. Het is gewoon een LLM met wat tools er omheen en het kan best grappig zijn. Ik wil alleen niet gedwongen worden om als een soort productiemedewerker in een fabriek zooi uit te poepen met AI. Software ontwikkelen was meer dan dat en het zelf programmeren was ook leuk. Vond ik dan.

En ik ben bang dat de kwaliteit er enorm van achteruit gaat. Ook wederom niet door AI zelf, maar door hoe mensen AI gebruiken.

[ThomasG]

Lethalis schreef op dinsdag 6 oktober 2026 @ 11:45:
[...]

Als ik met pensioen zou zijn, zou ik het ook leuk vinden hoor.

Ik krijg nu alleen met de gevolgen van AI te maken. Daar kan AI niks aan doen, maar mensen gaan er maar van uit dat je nu 10x zo productief moet zijn, terwijl er juist heel veel tijd zit in het ontwikkelproces die weinig tot niets met de implementatie te maken heeft.

Dus ik voel nu op mijn werk veel meer druk om dingen sneller op te leveren met AI, waar dat voorheen niet zo was en iedereen "begreep" dat je nou eenmaal even bezig was om iets te maken.

Ik heb geen hekel aan AI zelf. Het is gewoon een LLM met wat tools er omheen en het kan best grappig zijn. Ik wil alleen niet gedwongen worden om als een soort productiemedewerker in een fabriek zooi uit te poepen met AI. Software ontwikkelen was meer dan dat en het zelf programmeren was ook leuk. Vond ik dan.

En ik ben bang dat de kwaliteit er enorm van achteruit gaat. Ook wederom niet door AI zelf, maar door hoe mensen AI gebruiken.

Zijn dit niet gewoon symptomen van het werkelijke probleem: de bedrijfsprocessen deugen niet? Het AI-gebruik maakt het enkel beter voelbaar.

[Lethalis]

ThomasG schreef op dinsdag 6 oktober 2026 @ 12:37:
[...]

Zijn dit niet gewoon symptomen van het werkelijke probleem: de bedrijfsprocessen deugen niet? Het AI-gebruik maakt het enkel beter voelbaar.

Daar is inderdaad ook wel het e.e.a. aan te verbeteren, maar heb ik zelf weinig invloed op helaas.

[hackerhater]

Persoonlijk zie ik de bagger van tools als toekomstige inhuur jobs om de rommel op te ruimen.

[Firesphere]

hackerhater schreef op dinsdag 6 oktober 2026 @ 23:28:
Persoonlijk zie ik de bagger van tools als toekomstige inhuur jobs om de rommel op te ruimen.

Ik ben met een goede vriend al aan't kijken naar het opzetten van een bedrijfje "Code Asbestos removal service"

[Woy]

hackerhater schreef op dinsdag 6 oktober 2026 @ 23:28:
Persoonlijk zie ik de bagger van tools als toekomstige inhuur jobs om de rommel op te ruimen.

Ja, maar het grote verschil met voorheen is vooral dat mensen die eigenlijk geen software zouden moeten maken nu veel meer code uitspugen. De code zelf is mogelijk zelfs van betere kwaliteit, maar er zijn veel developers die een goede codebase/system design nog niet zouden herkennen als het ze in hun gezicht slaat.

[hackerhater]

Woy schreef op woensdag 7 oktober 2026 @ 08:56:
[...]

Ja, maar het grote verschil met voorheen is vooral dat mensen die eigenlijk geen software zouden moeten maken nu veel meer code uitspugen. De code zelf is mogelijk zelfs van betere kwaliteit, maar er zijn veel developers die een goede codebase/system design nog niet zouden herkennen als het ze in hun gezicht slaat.

Hence job zekerheid als freelancer ;)
Het schrijven van code is maar zo'n klein deel van de werkzaamheden van een software engineer

[ Voor 9% gewijzigd door hackerhater op 07-10-2026 09:02 ]

[Mugwump]

Nou moet ik wel zeggen dat als je zelf in staat bent kritisch na te denken de kwaliteit van de nieuwe modellen en wat ze genereren echt wel heel goed is. Zo ben ik nu een totale rewrite van een intern datamodel aan het doen waarbij nieuwe versies van REST endpoints moeten worden gemaakt en het genereren van de implementatie is eigenlik vrijwel vlekkeloos.
Zelfs zaken die ik zelf waarschijnlijk over het hoofd had gezien zitten er netjes in. Waar er meerdere opties zijn krijg je ook netjes een meerkeuze menuutje met een 'anders, namelijk: ' optie, wat een hele vooruitgang is ten opzichte van een jaar geleden toen agents gewoon unilateraal besloten je halve codebase te refactoren.
Paar kleine verbeteringen en correcties, de testsuite laten porten naar de nieuwe endpoints en je hebt binnen een paar uur staan waar je zelf wel iets langer mee zoet was geweest. Andere agent nog even laten reviewen en je haalt er nog een subtiel bugje uit.

Dit is allemaal dan wel op een codebase met een uitgebreide testset en een implementatie die grotendeels kan worden afgeleid, maar nog steeds wel een behoorlijke stap vooruit.

[dusty]

MueR schreef op maandag 5 oktober 2026 @ 14:08:
[...]

Hmm, ik laat vaak juist Sonnet het plan uitwerken (met Opus als backstop indien nodig), dan kan Haiku het inbouwen. Mag Opus nog een keer een review doen. Gaat best aardig vind ik zelf.

Mijn ervaring is dat sonnet (low) betere code maakt dan Haiku (ultracode) zolang je goede instructies hebt geplaatst in the claude.md om claude met instructies to voorzien zodat code gestructureerd terug komt.

Voor de planning gebruik ik Sonnet (Medium); als final validatie gebruik ik Opus (Medium). Maar voordat ik Opus gebruik, gebruik ik Sonnet(Medium) om eerdere reviews te doen.