De Devschuur Coffee Corner - Iteratie ⑬

[Koenvh]

Het blijft altijd grappig om op fora te lezen over projecten waar je zelf aan werkt of zelf hebt gestart

(Context is Cambionn in 'Denuvo-drm, lootboxratings en sympathieke laptops - Tweakers Podcast #437' waar ik denk: hé, de podcast-implementatie in Astiga (en Astiga zelf) heb ik geschreven)

[farlane]

Laatste C++ vraag op dit forum is uit 2022...

[RobertMe]

Sindsdien gebruikt iedereen Rust?

[Voutloos]

Er is überhaupt ongeveer 1 goede vraagtopic per maand max. Meer leven in de brouwerij zou tof zijn, maar blijkbaar is de vraag (haha) er gewoon niet.

[whoami]

Dit forum is gewoon dood. Als je kijkt naar de topic-index, dan is er gewoon niks.

Er zijn slechts 2 topics actief, en het zijn imho dan nog 'slowchat' topics. Eén topic met een slotje dat, mits de vraag beter gesteld werd, wel iets kon geweest zijn. Voor de rest is het hier gewoon een dooie boel. Dat is ooit wel anders geweest, maar sinds de komst van Stackoverflow en meer recent het AI tijdperk, vinden mensen het niet meer opportuun om hun vragen hier te stellen - wat geheel begrijpelijk is -.

[eheijnen]

Misschien dat AI een handje kan helpen om een of meer draadjes weer aangezwengeld te krijgen....

[SPee]

RobertMe schreef op donderdag 30 juli 2026 @ 22:46:
Sindsdien gebruikt iedereen Rust?

Ja. Zelfs de bekende C++ vlogger, The Cherno, gaat over: Learn Rust

[Koenvh]

RobertMe schreef op donderdag 30 juli 2026 @ 22:46:
Sindsdien gebruikt iedereen Rust?

Ik gebruik Rust, maar ik heb nog nooit een vraag gesteld op Tweakers of StackOverflow erover. Ik denk dat als ik zoiets zou doen, ik het Rust forum zou proberen. Voor andere talen heb ik geen flauw idee waar ik tegenwoordig vragen zou stellen.

[DevWouter]

Koenvh schreef op vrijdag 31 juli 2026 @ 15:17:
[...]

Ik gebruik Rust, maar ik heb nog nooit een vraag gesteld op Tweakers of StackOverflow erover. Ik denk dat als ik zoiets zou doen, ik het Rust forum zou proberen. Voor andere talen heb ik geen flauw idee waar ik tegenwoordig vragen zou stellen.

Discord is iets waar ik wel eens gebruik van maak. Maar dat is eerder met libraries. Voor het leren van een taal zijn de meeste handleidingen prima en zo niet dan is het snel een paar tutorials kijken op youtube.

Heel af en toe ook AI, maar dat is vooral omdat ik nog niet weet hoe ik de vraag moet stellen.

[eheijnen]

Maar jaa, met al dat AI gedoe en de verdere ontwikkelingen daaromtrent.

In hoeverre zal het in de toekomst nog uitmaken in welke taal een project geschreven wordt... ?

[downtime]

eheijnen schreef op zaterdag 1 augustus 2026 @ 06:20:
Maar jaa, met al dat AI gedoe en de verdere ontwikkelingen daaromtrent.

In hoeverre zal het in de toekomst nog uitmaken in welke taal een project geschreven wordt... ?

Waarom zou je nog een taal nodig hebben? Dat is alleen maar een extra vertaalslag tussen de menselijke intentie en de machinetaal die een CPU uiteindelijk uitvoert. Het enige doel van die taal is om een tussenstap te hebben die een mens nog kan lezen. Maar hoelang is dat nog nodig?

[DevWouter]

downtime schreef op zaterdag 1 augustus 2026 @ 12:37:
[...]

Waarom zou je nog een taal nodig hebben? Dat is alleen maar een extra vertaalslag tussen de menselijke intentie en de machinetaal die een CPU uiteindelijk uitvoert. Het enige doel van die taal is om een tussenstap te hebben die een mens nog kan lezen. Maar hoelang is dat nog nodig?

Omdat taal, elke taal, een notatie is van logica. Dit gaat op voor cpu instructies, programmeer talen, wiskunde en ook normale talen. Zonder taal is expressie van logica onmogelijk.

En voordat iemand “AI” roept, is het vooral handig om na te denken hoe ons gedrag met taal veranderd door AI.

[whoami]

downtime schreef op zaterdag 1 augustus 2026 @ 12:37:
[...]

Waarom zou je nog een taal nodig hebben? Dat is alleen maar een extra vertaalslag tussen de menselijke intentie en de machinetaal die een CPU uiteindelijk uitvoert. Het enige doel van die taal is om een tussenstap te hebben die een mens nog kan lezen. Maar hoelang is dat nog nodig?

Als developer ben je nog altijd verantwoordelijk voor wat je oplevert. Je 'owned' nog altijd de deliverable en de code, of die nu door jezelf is ingeklopt, of door AI is gegenereerd. Dat wil toch zeggen dat je -imho- nog altijd moet kunnen lezen en begrijpen wat de code doet.

[farlane]

Maar blijft dat zo? Op een gegeven moment kunnen de engineers die de code maken niet meer de code lezen omdat ze het niet nodig hebben, dus welk nut heeft het dan nog?

[W1ck1e]

downtime schreef op zaterdag 1 augustus 2026 @ 12:37:
[...]

Waarom zou je nog een taal nodig hebben? Dat is alleen maar een extra vertaalslag tussen de menselijke intentie en de machinetaal die een CPU uiteindelijk uitvoert. Het enige doel van die taal is om een tussenstap te hebben die een mens nog kan lezen. Maar hoelang is dat nog nodig?

De programmeertaal voorkomt dat mensen machinetaal moeten leren. Van verschillende machines.

[whoami]

farlane schreef op zaterdag 1 augustus 2026 @ 14:56:
Maar blijft dat zo? Op een gegeven moment kunnen de engineers die de code maken niet meer de code lezen omdat ze het niet nodig hebben, dus welk nut heeft het dan nog?

Dan evolueren we naar programmeren in het engels.

Soort van 'spec driven development', waarbij we dus enkel nog -in mensentaal- functioneel moeten beschrijven wat er moet gebeuren. Dan zijn we geen engineers meer, maar business analysten.

[RobertMe]

whoami schreef op zaterdag 1 augustus 2026 @ 14:52:
[...]

Als developer ben je nog altijd verantwoordelijk voor wat je oplevert. Je 'owned' nog altijd de deliverable en de code, of die nu door jezelf is ingeklopt, of door AI is gegenereerd. Dat wil toch zeggen dat je -imho- nog altijd moet kunnen lezen en begrijpen wat de code doet.

Maar als developer ben je ook niet verantwoordelijk voor de assembly die uit de compiler rolt. Dus of je nu zeg C++ schrijft en je voert een tool uit die er assembly van maakt of dat je, zoals anderen ook al aangeven, Engels schrijft en je een tool uitvoert die er assembly van maakt blijft dan gelijk.

Maar uiteraard zal er nog een lange weg te gaan zijn voordat AI vanuit specs een volledig programma kan maken, zonder een programmeertaal als tussenlaag. Nu is de output nog tekst, en wellicht toolcalls voor een compiler / .... Over tich jaar zou de output ook direct een .exe kunnen zijn.

Een extreem verbeterde vorm van "no code" / "low code" dus.

[ Voor 3% gewijzigd door RobertMe op 01-08-2026 15:15 ]

[DevWouter]

whoami schreef op zaterdag 1 augustus 2026 @ 15:07:
[...]

Dan evolueren we naar programmeren in het engels.

Soort van 'spec driven development', waarbij we dus enkel nog -in mensentaal- functioneel moeten beschrijven wat er moet gebeuren. Dan zijn we geen engineers meer, maar business analysten.

Bestaat al: Dat is SQL.

Probleem is dat de Engelse taal niet specifiek genoeg is.

A wife sends her programmer husband to get some groceries. "Please buy a loaf of bread, and if they have eggs, buy a dozen."
So he goes and comes back with 12 loaves of bread.
"Why did you buy so much bread?" she asks. "They had eggs".

[DevWouter]

RobertMe schreef op zaterdag 1 augustus 2026 @ 15:14:
[...]

Maar als developer ben je ook niet verantwoordelijk voor de assembly die uit de compiler rolt. Dus of je nu zeg C++ schrijft en je voert een tool uit die er assembly van maakt of dat je, zoals anderen ook al aangeven, Engels schrijft en je een tool uitvoert die er assembly van maakt blijft dan gelijk.

Tuurlijk ben je verantwoordelijk voor de assembly code. Het is onze taak als ontwikkelaars om iets te maken dat werkt. Dat je er in de praktijk 0 interactie met assembly code heb is iets anders.

Overigens heb ik wel eens een mijn eigen programma moeten decompilen om een fout te vinden.

[W1ck1e]

DevWouter schreef op zaterdag 1 augustus 2026 @ 15:26:
[...]

Bestaat al: Dat is SQL.

Probleem is dat de Engelse taal niet specifiek genoeg is.

A wife sends her programmer husband to get some groceries. "Please buy a loaf of bread, and if they have eggs, buy a dozen."
So he goes and comes back with 12 loaves of bread.
"Why did you buy so much bread?" she asks. "They had eggs".

Inderdaad : in menselijke taal wordt vaak een bedoeling begrepen terwijl de formulering niet eenduidig is. Of taalfouten bevat. De veronderstelde bedoeling hoeft niet eens de juiste zijn.
Dat lijkt mij iets wat je bij programmeertalen niet wil gedogen.

[whoami]

DevWouter schreef op zaterdag 1 augustus 2026 @ 15:26:
[...]

Bestaat al: Dat is SQL.

Probleem is dat de Engelse taal niet specifiek genoeg is.

A wife sends her programmer husband to get some groceries. "Please buy a loaf of bread, and if they have eggs, buy a dozen."
So he goes and comes back with 12 loaves of bread.
"Why did you buy so much bread?" she asks. "They had eggs".

SQL is een DSL, en schaar ik niet onder 'engels'. Dan zou je evengoed COBOL als voorbeeld kunnen nemen. (SQL is dan misschien toch nog een beter voorbeeld omdat dit declaratief is en COBOL imperatief).

Met spec driven development ga je juist jouw specificaties & guard-rails heel specifiek omschrijven en verder gaan verfijnen. Het is evengoed een iteratief proces waarbij je de AI agent altijd maar gaat gaan bijsturen.

[DevWouter]

whoami schreef op zaterdag 1 augustus 2026 @ 15:34:
[...]

SQL is een DSL, en schaar ik niet onder 'engels'. Dan zou je evengoed COBOL als voorbeeld kunnen nemen. (SQL is dan misschien toch nog een beter voorbeeld omdat dit declaratief is en COBOL imperatief).

Het is een DQL.

Maar het verhaal gaat dat managers informatie wilde ophalen zonder dat ze software ontwikkelaars nodig hadden. Dus besloot men om een nieuwe taal uit te vinden die sterk overeenkomt met Engels.

Sidenote: Als je ooit een zeer oud programmeer toetsenbord heb gezien dan vind je daar allemaal tekens op die je op een modern toetsenbord niet zomaar kan reproduceren. Je was daar veel meer bezig om een wiskundige syntax te schrijven.

Met spec driven development ga je juist jouw specificaties & guard-rails heel specifiek omschrijven en verder gaan verfijnen. Het is evengoed een iteratief proces waarbij je de AI agent altijd maar gaat gaan bijsturen.

Pff… Dan kan je net zo goed direct code gaan schrijven. Dan heb je het voordeel dat je syntax gecontroleerd wordt, het reproduceerbaar is, en dat er geen inhoudelijke andere betekenis wordt gegeven aan jouw intentie.

[ Voor 3% gewijzigd door DevWouter op 01-08-2026 15:55 ]

[downtime]

DevWouter schreef op zaterdag 1 augustus 2026 @ 15:54:
[...]

Sidenote: Als je ooit een zeer oud programmeer toetsenbord heb gezien dan vind je daar allemaal tekens op die je op een modern toetsenbord niet zomaar kan reproduceren. Je was daar veel meer bezig om een wiskundige syntax te schrijven.

Heb je een voorbeeld van zo'n keyboard? Ik vermoed dat je een keyboard voor de APL taal hebt gezien. Maar dat heeft niet zoveel met "wiskundige syntax" te maken.

Elke programmeertaal maakt gebruik van constructies als != of <> waar eigenlijk ≠ wordt bedoeld. Of -> waar → wordt bedoeld. Maar een taal die wel ≠ of → gebruikt is niet perse wiskundiger dan een taal die ze niet gebruikt.

[ Voor 3% gewijzigd door downtime op 01-08-2026 17:39 ]

[DevWouter]

downtime schreef op zaterdag 1 augustus 2026 @ 17:33:
[...]

Heb je een voorbeeld van zo'n keyboard? Ik vermoed dat je een keyboard voor de APL taal hebt gezien. Maar dat heeft niet zoveel met "wiskundige syntax" te maken.

Elke programmeertaal maakt gebruik van constructies als != of <> waar eigenlijk ≠ wordt bedoeld. Of -> waar → wordt bedoeld. Maar een taal die wel ≠ of → gebruikt is niet perse wiskundiger dan een taal die ze niet gebruikt.

Wikipedia: Knight keyboard heeft een mooie foto. In eerste instantie lijkt het op een gewoon toetsenbord en dan zie je allerlei tekens die je normaal niet kent.

Bijna elke toets heeft ook een wiskundige functie.

Om je een idee te geven hoe erg het vroeger was… Het onderstaande is APL.

crt←{m|⍵+.×⍺(⊣×⊢|∘⊃{0=⍵:1 0 ⋄ (⍵∇⍵|⍺)+.×0 1,⍪1,-⌊⍺÷⍵})¨⍨⍺÷⍨m←×/⍺} ⍝ From APL Cart

Bron: https://xpqz.github.io/learnapl/intro.html

en hier de JavaScript versie van dat stukje code (ai vertaald en niet gecontroleerd).

JavaScript:

/**
 * Chinese Remainder Theorem — solves a system of congruences.
 *
 * @param {number[]} moduli   - The moduli (must be pairwise coprime), e.g. [3, 5, 7]
 * @param {number[]} remainders - The remainders, e.g. [2, 3, 2]
 * @returns {number} The unique solution in [0, M) where M = product of moduli.
 */
function crt(moduli, remainders) {
  const n = moduli.length;

  // M = product of all moduli  (m ← ×/⍺)
  const M = moduli.reduce((acc, m) => acc * m, 1);

  // For each i, compute (M / n_i) and its modular inverse mod n_i,
  // then multiply: inv_i * (M / n_i)  — the CRT "basis" contribution.
  const basis = moduli.map((ni, i) => {
    const co = M / ni;                              // ⍺÷⍨m — co-modulus value
    const inv = modInverse(co, ni);                 // extended Euclidean → Bézout coeff
    return Number(inv) * co;                        // ⊣×⊢|∘⊃  — inverse × co-modulus
  });

  // x = Σ (remainders[i] * basis[i])  then reduce mod M
  let x = 0;
  for (let i = 0; i < n; i++) {
    x += remainders[i] * basis[i];
  }

  return x % M;  // m | ...
}

/**
 * Extended Euclidean Algorithm — computes gcd(a, m) and the Bézout coefficients.
 * Returns [x, y] such that a*x + m*y = gcd(a, m).
 *
 * This mirrors the APL inner function:
 *   {0=⍵: 1 0 ⋄ (⍵∇⍵|⍺)+.× 0 1,⍪1,-⌊⍺÷⍵}
 *
 * @param {number} a - the value (co-modulus M/n_i)
 * @param {number} m - the modulus n_i
 * @returns {[number, number]} Bézout coefficients [x, y]
 */
function extEuclid(a, m) {
  // Base case: 0=⍵: 1 0
  if (m === 0) return [1, 0];

  // Recursive case: (⍵ ∇ ⍵|⍺) + .× [[0,1],[1,-⌊a/m⌋]]
  const [x1, y1] = extEuclid(m, a % m);     // ⍵∇⍵|⍺ — recurse with (m, a mod m)
  const q = Math.floor(a / m);              // ⌊⍺÷⍵   — quotient

  // Matrix multiply: [x1, y1] × [[0, 1], [1, -q]]
  //   = [x1*0 + y1*1,  x1*1 + y1*(-q)]
  //   = [y1,  x1 - q*y1]
  return [y1, x1 - q * y1];
}

/**
 * Modular inverse of a mod m — the first Bézout coefficient, reduced mod m.
 * @param {number} a
 * @param {number} m
 * @returns {number} a^{-1} mod m
 */
function modInverse(a, m) {
  const [x] = extEuclid(a, m);
  return ((x % m) + m) % m;  // ensure non-negative result
}

[ Voor 55% gewijzigd door DevWouter op 01-08-2026 18:16 ]

[Damic]

* Damic is wat een code kloten met claude. Buffers van distributerd.net direct kunnen lezen wens ik al jaren, maar die stukken code staat niet online.

Edit: na veel geklooi met GHIDRA + mistral.ai en claude, is claud de winnaar.
Ghidra kun je gewoon een programma in gooien en dan zie je de werking en dat dan tezamen met een export direct naar claude en binnen het uur heb je je ding dat je nodig hebt.

[ Voor 44% gewijzigd door Damic op 09-08-2026 01:23 ]

[Exodai]

Ik heb sinds een dag of 5 dat Codex is gestopt met luisteren naar ontwikkel regels voor code, ontwikkel plannen en vastgestelde regels. Het doet gewoon oprecht waar het zelf zin in heeft en als het geen zin heeft weigert het gewoon om iets te implementeren.

Ik was met een notificatie systeem bezig voor een iOS app, 500+ ontwikkelplan geschreven met 12 phases om het te implementeren. En ipv een notificatie systeem te implementeren heeft het gewoon de UI op 30+ Views kapot gemaakt en heeft het MVVM naar een CLEAN design pattern veranderd. En het liegt sinds kort ook tot het zwart ziet. Het beweert bijvoorbeeld onder andere dat ik het de opdracht heb gegeven om de UI te veranderen en dan beweert het opeens dat het helemaal niets heeft aangepast.

Ik heb het een beetje onderzocht en ik blijk lang niet de enige te zijn. Zelfs op de OpenAI forums wordt er geklaagd dat Codex de simpelste regels eigenlijk aan zijn laars lapt en op LinkedIn las ik een artikel van een developer waar Codex gewoon een hele andere app heeft gebouwd dan hij in zijn plan had geschreven.

Hebben jullie dat ook dat je soms beetje AI moe wordt en het eigenlijk gewoon lekker zelf wilt implementeren?

[ Voor 5% gewijzigd door Exodai op 09-08-2026 19:24 ]

[Tjolk]

Exodai schreef op zondag 9 augustus 2026 @ 19:22:

Hebben jullie dat ook dat je soms beetje AI moe wordt en het eigenlijk gewoon lekker zelf wilt implementeren?

Ik heb gelukkig nooit het punt bereikt dat ik dit werk uit handen geef. Hooguit basic tasks als schrijf een DTO voor dit object of maak een unit test voor deze method.

Nooit "go make app" ofzo

[Koenvh]

Tjolk schreef op zondag 9 augustus 2026 @ 20:28:
[...]

Ik heb gelukkig nooit het punt bereikt dat ik dit werk uit handen geef. Hooguit basic tasks als schrijf een DTO voor dit object of maak een unit test voor deze method.

Nooit "go make app" ofzo

Dat dus. Misschien helpt 't dat ik software ontwikkel voor kritieke internetinfrastructuur en niet voor CRUD-systeem #2522, maar het idee dat je een LLM code duizenden regels code laat genereren vind ik nogal eng.

[sig69]

Exodai schreef op zondag 9 augustus 2026 @ 19:22:
Hebben jullie dat ook dat je soms beetje AI moe wordt en het eigenlijk gewoon lekker zelf wilt implementeren?

Ja. "Change this code to use the v3 api". 30 nuget packages geïnstalleerd, overal versie conflicten. Hij kwam er niet meer uit. Stop maar, undo. "Change this code to use the v3 api using only httpclient and simple requests". In 5 minuten klaar, werkt. Waarom zo ingewikkeld? Hele maand tokens verbrand. Ach, leermoment. Vooral duidelijk zijn wat je wil.

[Exodai]

Tjolk schreef op zondag 9 augustus 2026 @ 20:28:
[...]

Ik heb gelukkig nooit het punt bereikt dat ik dit werk uit handen geef. Hooguit basic tasks als schrijf een DTO voor dit object of maak een unit test voor deze method.

Nooit "go make app" ofzo

Ik ook niet perse. Ik gebruik het vooral voor Modellen en DTO en aanhangende functionaliteit. Maar zoiets als Notificaties is niet zo heel bijzonder, alleen wanneer een LLM je actief tegen begint te werken is het best merkwaardig.

sig69 schreef op zondag 9 augustus 2026 @ 21:21:
[...]

Ja. "Change this code to use the v3 api". 30 nuget packages geïnstalleerd, overal versie conflicten. Hij kwam er niet meer uit. Stop maar, undo. "Change this code to use the v3 api using only httpclient and simple requests". In 5 minuten klaar, werkt. Waarom zo ingewikkeld? Hele maand tokens verbrand. Ach, leermoment. Vooral duidelijk zijn wat je wil.

Ja dat doen wij dus ook niet meer. Nu komt API versioning direct van de server af, het is hier ook een paar keer met Codex en Claude gebeurd dat er opeens hele nieuwe app werd afgeleverd met ver veranderen van API endpoints.

[ Voor 67% gewijzigd door Exodai op 09-08-2026 21:31 ]

[.oisyn]

Op vakantie, kom ik erachter dat de VPN op mijn EdgeRouter niet meer werkt. AUTH_FAILED volgens de strongswan client log. Echt, dat ding heeft jarenlang onafgebroken gewerkt en nu ineens is het stuk .

Ok, maar hoe fix ik dat remote? Gelukkig heb ik WOL webinterface op mijn NAS draaien om mijn PC remote aan te zetten, dan RDP ik daarnaartoe en kan ik bij mijn router.

Crap, onlangs een nieuwe synology gekocht, heb de boel wel overgezet maar natuurlijk niet getest. Etherwake runt alleen onder root, en mijn webscriptje doet dat (natuurlijk) niet . Vergeten een chmod u+s te doen op etherwake (echt wtf, waarom kunnen dat soort dingen alleen onder root?)

Kan ik dan bij mijn NAS? Ja, via QuickConnect kan ik bij de webinterface van de NAS. Maar dat is nogal gelimiteerd, ik moet een terminal. Gelukkig heeft imand een custom package gemaakt voor een terminal in de webinterface dus die kon ik installeren. Een stap verder, maar daarin kan ik weer geen root rechten verkrijgen want dat is blijkbaar dichtgezet . Oh maar wacht, ik kan in die terminal op de NAS webinterface wel gewoon SSH'en naar de NAS zelf, en dan kan ik wél gewoon sudo'en .

Scriptje gefixed, magic packet verstuurd, PC staat aan, ik kan nu RDP'en naar mijn PC en via mijn PC bij mijn router (zowel SSH als web) .



Nu alleen de VPN nog fixen. Claud? Gippity?

.edit: fixed. Let's Encrypt heeft tegenwoordig een extra CA in de cert chain. Ik verwijs in de ipsec settings wel naar de ca.cer in de LE dir, maar blijkbaar serveert StrongSwan alleen maar de eerste cert in die file, en dat zijn er sinds kort dus 2. Irritant. Maar wel te fixen door de tweede apart in een file te zetten en die ook te vermelden. Thanks, Gippity!

[ Voor 8% gewijzigd door .oisyn op 12-08-2026 17:11 ]

[Jolijter]

.oisyn schreef op woensdag 12 augustus 2026 @ 15:21:
Op vakantie, kom ik erachter dat de VPN op mijn EdgeRouter niet meer werkt. AUTH_FAILED volgens de strongswan client log. Echt, dat ding heeft jarenlang onafgebroken gewerkt en nu ineens is het stuk .

Ok, maar hoe fix ik dat remote? Gelukkig heb ik WOL webinterface op mijn NAS draaien om mijn PC remote aan te zetten, dan RDP ik daarnaartoe en kan ik bij mijn router.

Crap, onlangs een nieuwe synology gekocht, heb de boel wel overgezet maar natuurlijk niet getest. Etherwake runt alleen onder root, en mijn webscriptje doet dat (natuurlijk) niet . Vergeten een chmod u+s te doen op etherwake (echt wtf, waarom kunnen dat soort dingen alleen onder root?)

Kan ik dan bij mijn NAS? Ja, via QuickConnect kan ik bij de webinterface van de NAS. Maar dat is nogal gelimiteerd, ik moet een terminal. Gelukkig heeft imand een custom package gemaakt voor een terminal in de webinterface dus die kon ik installeren. Een stap verder, maar daarin kan ik weer geen root rechten verkrijgen want dat is blijkbaar dichtgezet . Oh maar wacht, ik kan in die terminal op de NAS webinterface wel gewoon SSH'en naar de NAS zelf, en dan kan ik wél gewoon sudo'en .

Scriptje gefixed, magic packet verstuurd, PC staat aan, ik kan nu RDP'en naar mijn PC en via mijn PC bij mijn router (zowel SSH als web) .

[Afbeelding]

Nu alleen de VPN nog fixen. Claud? Gippity?

.edit: fixed. Let's Encrypt heeft tegenwoordig een extra CA in de cert chain. Ik verwijs in de ipsec settings wel naar de ca.cer in de LE dir, maar blijkbaar serveert StrongSwan alleen maar de eerste cert in die file, en dat zijn er sinds kort dus 2. Irritant. Maar wel te fixen door de tweede apart in een file te zetten en die ook te vermelden. Thanks, Gippity!

Niet vergeten vakantie te houden. Fijne vakantie nog!

[Firesphere]

Weet iemand een goed alternatief voor de JetBrains suite, maar dan zonder die verdomde AI die de hele tijd de aandacht wil en/of de boel ontiegelijk verkloot als ik perongeluk op de verkeerde knop druk?

Ik wil gewoon een IDE, niet dat afzichtelijke gewauwel van een AI dat 99 van de 98 keer compleet verkeerde informatie geeft, of autocompleet er in probeert te proppen.

Ik gebruik:

Rust, Python, PHP, Javascript, HTML, CSS, SCSS, TS, Go

[ Voor 8% gewijzigd door Firesphere op 13-08-2026 01:23 ]

[DevWouter]

Firesphere schreef op donderdag 13 augustus 2026 @ 01:22:
Weet iemand een goed alternatief voor de JetBrains suite, maar dan zonder die verdomde AI die de hele tijd de aandacht wil en/of de boel ontiegelijk verkloot als ik perongeluk op de verkeerde knop druk?

Ik wil gewoon een IDE, niet dat afzichtelijke gewauwel van een AI dat 99 van de 98 keer compleet verkeerde informatie geeft, of autocompleet er in probeert te proppen.

Ik gebruik:

Rust, Python, PHP, Javascript, HTML, CSS, SCSS, TS, Go

Ik ben zelf fan van Neovim, hoewel ik nog steeds Jetbrains gebruikt. Overigens zou ik je vooral adviseren om gewoon de AI uit te zetten. Jezelf hertrainen gaat je zeker een maand of twee kosten.

[Firesphere]

DevWouter schreef op donderdag 13 augustus 2026 @ 05:28:
[...]

Ik ben zelf fan van Neovim, hoewel ik nog steeds Jetbrains gebruikt. Overigens zou ik je vooral adviseren om gewoon de AI uit te zetten. Jezelf hertrainen gaat je zeker een maand of twee kosten.

U kent mij klaarblijkelijk niet? Waarom zou ik de AI uberhaupt ooit aan willen zetten? Als ik stront wil, ga ik wel naar het toilet

[ Voor 4% gewijzigd door Firesphere op 13-08-2026 07:27 ]

[Tjolk]

Ik denk dat DevWouter bedoeld dat als je aan Jetbrains gewend bent (zonder AI) het ook gewoon tijd kost om jezelf te trainen naar een nieuwe IDE dat alles in je muscle memory zit enz.
Dus dat misschien de gemakkelijkste methode gewoon is om een maar checkboxes uit te zetten in Jetbrains.

[Cartman!]

Firesphere schreef op donderdag 13 augustus 2026 @ 07:26:
[...]

U kent mij klaarblijkelijk niet? Waarom zou ik de AI uberhaupt ooit aan willen zetten? Als ik stront wil, ga ik wel naar het toilet

Nog steeds in de ontkenningsfase?

[ElkeBxl]

[Firesphere]

Tjolk schreef op donderdag 13 augustus 2026 @ 07:57:
Ik denk dat DevWouter bedoeld dat als je aan Jetbrains gewend bent (zonder AI) het ook gewoon tijd kost om jezelf te trainen naar een nieuwe IDE dat alles in je muscle memory zit enz.
Dus dat misschien de gemakkelijkste methode gewoon is om een maar checkboxes uit te zetten in Jetbrains.

JetBrains zet ze alleen telkens weer aan, wat ontiegelijk frustrerend is.

Cartman! schreef op donderdag 13 augustus 2026 @ 08:16:
[...]

Nog steeds in de ontkenningsfase?

Ontkenningsfase van wat?

[RobertMe]

Firesphere schreef op donderdag 13 augustus 2026 @ 10:42:
[...]

JetBrains zet ze alleen telkens weer aan, wat ontiegelijk frustrerend is.

Dat is niet mijn ervaring. Uit is uit.

[...]

Ontkenningsfase van wat?

Dat AI het beste sinds gesneden brood is.

[Tjolk]

AI is helpful, maar gesneden brood blijft beter.

[Cartman!]

Firesphere schreef op donderdag 13 augustus 2026 @ 10:42:
Ontkenningsfase van wat?

Mijn vraag is beantwoord

[Firesphere]

Cartman! schreef op donderdag 13 augustus 2026 @ 11:15:
[...]

Mijn vraag is beantwoord

Ik snap nog steeds niet wat je bedoelt.

RobertMe schreef op donderdag 13 augustus 2026 @ 10:47:
[...]

Dat AI het beste sinds gesneden brood is.

Ik doe niet aan cognitive surrender, third party thinking, en al helemaal niet aan clanker capitulation.

Die hele AI hype/craze/idioterie moet zo snel mogelijk verdwijnen. Het is de asbest van software.

[DevWouter]

Firesphere schreef op donderdag 13 augustus 2026 @ 07:26:
[...]

U kent mij klaarblijkelijk niet? Waarom zou ik de AI uberhaupt ooit aan willen zetten? Als ik stront wil, ga ik wel naar het toilet

En als iemand anders jouw favoriete toilet telkens verstopt dan is het handig om eerst het toilet aan te passen zodat die persoon er niet meer bij kan. (dus ja, elke keer die plugin uitschakelen)

RobertMe schreef op donderdag 13 augustus 2026 @ 10:47:
[...]

Dat is niet mijn ervaring. Uit is uit.


[...]

Dat AI het beste sinds gesneden brood is.

Volgens mij schakelt Jetbrains het automatisch weer in als ze iets van een verbetering hebben doorgevoerd. Er zit voor hun ook een verdienmodel achter (tokens leveren geld op, en als mijn IDE een gotcha game was dan is men vooral aan het zoeken naar die "whale").

En AI denkt dat een broek ook gesneden moet worden in plakjes want 3 van de 5 letter komen overeen met brood.

Cartman! schreef op donderdag 13 augustus 2026 @ 08:16:
[...]

Nog steeds in de ontkenningsfase?

Sommige programmeurs kunnen vervangen worden door AI, anderen niet. In welke categorie val jij?

Firesphere schreef op donderdag 13 augustus 2026 @ 12:23:
Ik doe niet aan cognitive surrender, third party thinking, en al helemaal niet aan clanker capitulation.

Die hele AI hype/craze/idioterie moet zo snel mogelijk verdwijnen. Het is de asbest van software.

Allereerst: Top omschrijving!

Dit maal 10. AI kan handig zijn, maar het produceert ook extreem veel ruis. Een beetje alsof een slechte junior over je schouder mee kijkt en de hele tijd ongewenst suggesties geeft. Vroeger pikte je de vergaderhok in of zet je de collega een paar minuten op mute. Maar blijkbaar vinden de AI boeren het een goed idee om deze junior telkens je toetsenbord af te laten pakken waarna wij weer de code mogen fixen.

Oprecht, ik zou liever hebben dat de AI een melding geeft van: "Uh, weet je dit zeker? Je hebt hier al een soort gelijk iets geschreven en toen was je ook niet tevreden, misschien tijd om een rondje te lopen" dan dat ze "Yo dude, hold my beer, I know this shit" om vervolgens compleet netflix chaos monkey te gaan in de code.

Compleet gerelateerd: Je hoort ontwikkelaars amper over de flow state.

[DevWouter]

ElkeBxl schreef op donderdag 13 augustus 2026 @ 09:00:
[Afbeelding]

Wordt dat plaatje ook niet door mensen die een coup d'état plegen?

[Cartman!]

DevWouter schreef op donderdag 13 augustus 2026 @ 14:01:
[...]
Sommige programmeurs kunnen vervangen worden door AI, anderen niet. In welke categorie val jij?

In de categorie die de tools gebruikt als een stuk gereedschap, code goed reviewed en flink tijd bespaart doordat ik het niet meer met de hand hoef te typen. Er zit heel veel tussen "ik gebruik het als een hulpmiddel" en "ik laat alles blind door een agent op productie deployen". Toen de auto kwam waren er vast ook genoeg mensen die liever bij paard en wagen bleven. AI gaat echt niet meer weg dus je kunt er beter mee om leren gaan.

[ Voor 5% gewijzigd door Cartman! op 13-08-2026 14:12 ]

[Kalentum]

DevWouter schreef op donderdag 13 augustus 2026 @ 14:01:
Compleet gerelateerd: Je hoort ontwikkelaars amper over de flow state.

Ik heb het nooit over de flow state

Kun je hier wat elaboreren?

[ Voor 60% gewijzigd door Kalentum op 13-08-2026 14:28 ]

[DevWouter]

Cartman! schreef op donderdag 13 augustus 2026 @ 14:08:
[...]

In de categorie die de tools gebruikt als een stuk gereedschap, code goed reviewed en flink tijd bespaart doordat ik het niet meer met de hand hoef te typen. Er zit heel veel tussen "ik gebruik het als een hulpmiddel" en "ik laat alles blind door een agent op productie deployen". Toen de auto kwam waren er vast ook genoeg mensen die liever bij paard en wagen bleven. AI gaat echt niet meer weg dus je kunt er beter mee om leren gaan.

Een auto kan een factor 20x sneller dan dat ik kan lopen, los van het feit dat het meer kan meenemen. AI komt niet eens in de buurt daarvan. Er zijn verschillende onderzoeken die aangeven dat de ROI negatief is (dus een daling in performance) of waarbij de performance zo gering is dat wanneer de CFO er achter komt die meteen aan de rem zal trekken. En dan is het los van het aantal defecten waarbij de CTO slecht van gaat slapen.

Bronnen:

• https://letsdatascience.com/blog/developers-thought-ai-made-them-faster-the-data-said-otherwise (19% trager)
• https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways (16% snellere PRs, maar kans op bugs per PR stijgt met 28%, en code churn stijgt met 800%)

Conclusie: AI schrijft meer code dan een mens, maar code schrijven wordt te snel verward met productiviteit en rendement.

Verder is er nog geen één bedrijf bekend waarbij de kosten gedaald zijn door code schrijven door AI. En gezien de kosten per token stijgt zal dat break-even moment lang wegblijven.

[DevWouter]

Kalentum schreef op donderdag 13 augustus 2026 @ 14:23:
[...]


Ik heb het nooit over de flow state

Kun je hier wat elaboreren?

Sure: Zie Wikipedia: Flow (mentale toestand)

Een positieve mentale houding waarbij een persoon boven hun zelf kunnen uitstijgen waardoor ze moeiteloos beter lijken te presteren. Een van de vereisten is het hebben van autonomie en geen last hebben van stoorzenders/onderbrekingen. En ondermijnt AI dat volledig.

[Kalentum]

DevWouter schreef op donderdag 13 augustus 2026 @ 14:48:
[...]

Sure: Zie Wikipedia: Flow (mentale toestand)

Een positieve mentale houding waarbij een persoon boven hun zelf kunnen uitstijgen waardoor ze moeiteloos beter lijken te presteren. Een van de vereisten is het hebben van autonomie en geen last hebben van stoorzenders/onderbrekingen. En ondermijnt AI dat volledig.

Bedankt!

Ik herken niet helemaal wat je zegt. AI ondermijnt niet mijn autonomie (ik bepaal op welke manier Claude Code doet, ik stuur bij, ik kijk naar hoe de test eruit zijn). Er zijn inderdaad wel meer onderbrekingen maar 'deep work' is minder nodig. Ik zit minder vaak in de 'zone' maar heb daar ook minder behoefte aan.

Hoe ik ongeveer werk:
- Ik bedenk een implementatie richting. Meestal met wat pseudo code, high level aanpak
- Ik spar met Claude Code in Plan mode. Beetje heen- en-weren over naamgeving, interface van methods of classes etc.
- Dan laat ik Claude Code het implementeren, ik review dat, en Claude code past het aan op basis van mijn feedback
- Als ik tevreden ben vraag ik Claude Code een PR aan te maken, beschrijving toevoegen, context informatie (related issue enzo). Ik vraag ook om wie handig is om te vragen (domein expert) voor review

Blij mee.

Wat ik echt super vindt: Claude werkt door tijdens een meeting / lunch whatever. Claude gaat niet naar de WC en heeft zelf geen meetings (wat bij pair programming nog wel eens voorkomt). Claude weet nog exact waar we het een week geleden over hadden, al die context is nog aanwezig.

Ik ga er van uit dat ik over een maand of 3, als de boel weer wat verder geëvolueerd is, op een andere manier werk. En als ik het niet kostenefficiënter is, dan hoor ik het wel, we krijgen nu al regelmatig commentaar dat we de AI loop moeten vermijden om maar wat te noemen.

Het staat allemaal niet stil.

In november 2025 was ik nog sceptisch. Nu komt het voor dat ik code oplever die ik alleen maar review, en nooit in een editor zelf heb aangeraakt. En wie weet waar we over een half jaar staan.

[ Voor 23% gewijzigd door Kalentum op 13-08-2026 15:04 ]

[Cartman!]

DevWouter schreef op donderdag 13 augustus 2026 @ 14:40:
Een auto kan een factor 20x sneller dan dat ik kan lopen, los van het feit dat het meer kan meenemen. AI komt niet eens in de buurt daarvan.

Je ziet AI blijkbaar als iets wat of niet bestaat of volledig je werk overneemt maar er zit een hoop tussenin.

[DevWouter]

Kalentum schreef op donderdag 13 augustus 2026 @ 14:58:
[...]

Bedankt!

Graag gedaan.

Ik herken niet helemaal wat je zegt. AI ondermijnt niet mijn autonomie (ik bepaal op welke manier Claude Code doet, ik stuur bij, ik kijk naar hoe de test eruit zijn). Er zijn inderdaad wel meer onderbrekingen maar 'deep work' is minder nodig. Ik zit minder vaak in de 'zone' maar heb daar ook minder behoefte aan.

Autonomie staat hier voor zelfstandig functioneren, dus zonder invloed van buiten af. Heel oud voorbeeld: Ik had vroeger een sneltoets waarbij ik auto complete volledig uitschakel zodat member variables/functies type ipv ging scrollen door een lijst. Dit omdat typen sneller was dan scrollen in de lijst.

In Neovim heb ik ingesteld dat suggesties altijd vertraagd zijn met 3000ms, dit zodat als ik type ik niet continue een popup in beeld zie.

Hoe ik ongeveer werk:
- Ik bedenk een implementatie richting. Meestal met wat pseudo code, high level aanpak
- Ik spar met Claude Code in Plan mode. Beetje heen- en-weren over naamgeving, interface van methods of classes etc.
- Dan laat ik Claude Code het implementeren, ik review dat, en Claude code past het aan op basis van mijn feedback
- Als ik tevreden ben vraag ik Claude Code een PR aan te maken, beschrijving toevoegen, context informatie (related issue enzo). Ik vraag ook om wie handig is om te vragen (domein expert) voor review

Blij mee.

Dat is niet te vergelijken met flow. Flow is meer waarbij alles elke keer zonder moeite op zijn plaats valt. Alsof elke bal die je slaat een homerun is. Alsof de hele wereld meewerkt om jou te laten presteren.

Als je het nog nooit ervaren hebt is het lastig uit te leggen. Maar als je het ooit meegemaakt heb dan sta je soms versteld hoe productief je bent geweest. Dan voelt het aan alsof je een week aan werk in een ochtend heb verzet.

In november 2025 was ik nog sceptisch. Nu komt het voor dat ik code oplever die ik alleen maar review, en nooit in een editor zelf heb aangeraakt. En wie weet waar we over een half jaar staan.

Waarschijnlijk heb je (net zoals iedereen, inclusief mijzelf) te maken met een paar biassen (vooroordelen) die je oordeel beinvloeden. Zo beschouwen we meer code geschreven vaak alsof we meer gepresteerd hebben, en associëren we prestaties met de verkeerde resultaten. En AI produceert veel.

Ter illustratie: Ik heb ooit 30.000 regels vervangen had door 50 regels code. Dat heeft mij een week gekost en management was daar goed pissig over. Een week later waren ze weer pissig op mij toen ze realiseerde dat ik een complexe taak die ze voor 160 uur verkocht hadden ik in 10 minuten afgerond had. Het grootste probleem was dat ik dit niet gecommuniceerd had met ze. Het was ooit door een "geniaal ex-werknemer" geschreven en het was zo complex dat niemand het durfde aan te raken waardoor we er de heel tijd om heen werkte. Het systeem was overigens geniaal (een zeer complex state machine) maar werd in de praktijk eigenlijk nooit gebruikt. Dus die ex-werknemer had een top prestatie geleverd, maar ruk resultaat. Ik had objectief een ruk prestatie geleverd (herschrijving van een week en een factuur verkloot) terwijl het resultaat top was.

Ik denk wel eens terug en vraag me oprecht af wie beter was: Die ex-werknemer of ik. Want hoe mooi mijn resultaat technisch ook was, vanuit het bedrijf gezien heeft die ex-werknemer meer geld opgeleverd.

[RayNbow]

Cartman! schreef op donderdag 13 augustus 2026 @ 14:08:
[...] flink tijd bespaart doordat ik het niet meer met de hand hoef te typen.

Ja, een LLM kan sneller code uitspugen dan dat ik kan typen... maar het kloppen van code is volgens mij niet het grootste onderdeel van softwareontwikkeling.

Daarnaast: waarom moet er nog zo veel code nog geklopt worden? Waarom kunnen we bepaalde concepten niet beknopter in code vastleggen? Het is m.i. een symptoom dat het gros van de programmeertalen (en frameworks) nog wel een tandje beter kunnen.

[Cartman!]

RayNbow schreef op donderdag 13 augustus 2026 @ 16:29:
Ja, een LLM kan sneller code uitspugen dan dat ik kan typen... maar het kloppen van code is volgens mij niet het grootste onderdeel van softwareontwikkeling.

Precies, daarom zie ik het als een tool om te typen waar ik geen zin in heb zodat ik me bezig kan houden met andere zaken. Ik ben dan ook niet bang dat ik als ontwikkelaar zonder werk kom te zitten.

Daarnaast: waarom moet er nog zo veel code nog geklopt worden? Waarom kunnen we bepaalde concepten niet beknopter in code vastleggen? Het is m.i. een symptoom dat het gros van de programmeertalen (en frameworks) nog wel een tandje beter kunnen.

Hoe zou je dat willen aanpakken?

[DevWouter]

Cartman! schreef op donderdag 13 augustus 2026 @ 15:11:
[...]

Je ziet AI blijkbaar als iets wat of niet bestaat of volledig je werk overneemt maar er zit een hoop tussenin.

offtopic:
Mwah, je wordt nu wel persoonlijk, dus ik ga daar even op in. Ik heb al 6~7 jaar ervaring met ML en 4 jaar met LLMs, en ChatGPT bestaat pas wat... 3 jaar? Daarbij heb ik ook gewerkt aan een project dat intensief ML gebruikt. Ik zal mezelf geen expert noemen, maar ik weet genoeg van AI om een goede inschatting van het spectrum te hebben. Daarbij lees ik nog regelmatig onderzoeken over LLMs (en dan bedoel ik niet de marketing verhalen). En ja, ik gebruik nog regelmatig AI, hoewel ik het resultaat zelden gebruik om verschillende redenen. Ergo, je onderschat mij zwaar.

Maar om wat inhoudelijker zijn: Geen van de onderzoeken wijzen op een substantieel en betrouwbaar prestatieverbetering. De prestatieverbetering kan je over twisten (want die is er wel met mitsen en maren), maar de betrouwbaarheid is waar ik mij zorgen over maak.

[DevWouter]

RayNbow schreef op donderdag 13 augustus 2026 @ 16:29:
Daarnaast: waarom moet er nog zo veel code nog geklopt worden? Waarom kunnen we bepaalde concepten niet beknopter in code vastleggen? Het is m.i. een symptoom dat het gros van de programmeertalen (en frameworks) nog wel een tandje beter kunnen.

Inderdaad. Ik heb steeds vaker de neiging om template generators te schrijven of dynamische machines.

Overigens is het niet alleen programmeertalen. Ook het Apps en het OS hebben er een handje van. Een tijd terug startte ik Windows 98 op (for shit and giggles) en het was zo prettig dat een maximaliseer, minimaliseer en sluit knop grijs waren op een blauwe titelbalk. En dat mee denken aan PHP3 waarbij je weliswaar amper types had en alles aanvoelde als string manipulatie, maar het werkte. Godzijdank hoef ik geen IE4 meer te ondersteunen.

[RayNbow]

Cartman! schreef op donderdag 13 augustus 2026 @ 16:43:
[...]

Hoe zou je dat willen aanpakken?

Hier heb ik geen eenduidig antwoord op en vereist voor sommige gevallen uitgebreid onderzoek. Het is dan vooral een kunst om iets te vinden wat ons helpt om bepaalde zaken kort en bondig op te kunnen schrijven.

Een simpel voorbeeld voor C# is dat de taal op een gegeven moment syntax kreeg voor records:

Laatst liet ik een AI-agent los om iets te implementeren en toen ik de code doorlas, viel me op dat 1 specifieke class die de agent gegenereerd had bestond uit een aantal tientallen regels: een aantal properties en een constructor die de properties initialiseerde. Dit had met de recordsyntax in 1 regel gekund.

Bovenstaande is slechts een eenvoudig voorbeeld van het schrijven van onnodig veel code. Het zou ontwikkelaars dan ook sieren als we zo nu en dan stilstaan bij de bergen code die we produceren en ons afvragen: kan dit niet beknopter?

[RobertMe]

RayNbow schreef op donderdag 13 augustus 2026 @ 17:01:
[...]

Hier heb ik geen eenduidig antwoord op en vereist voor sommige gevallen uitgebreid onderzoek. Het is dan vooral een kunst om iets te vinden wat ons helpt om bepaalde zaken kort en bondig op te kunnen schrijven.

Een simpel voorbeeld voor C# is dat de taal op een gegeven moment syntax kreeg voor records:

Laatst liet ik een AI-agent los om iets te implementeren en toen ik de code doorlas, viel me op dat 1 specifieke class die de agent gegenereerd had bestond uit een aantal tientallen regels: een aantal properties en een constructor die de properties initialiseerde. Dit had met de recordsyntax in 1 regel gekund.

Bovenstaande is slechts een eenvoudig voorbeeld van het schrijven van onnodig veel code. Het zou ontwikkelaars dan ook sieren als we zo nu en dan stilstaan bij de bergen code die we produceren en ons afvragen: kan dit niet beknopter?

Naast het voorbeeld wat je al aanhaalt van DTOs die vooral vroeger veel boiler plate vereiste en vaak als voordeel van een LLM wordt aangehaald, een deel van de "oplossing" tegen veel code moeten schrijven zit natuurlijk ook in reusability. En dan niet alleen eigen code, maar ook libraries gebruiken waar nodig. Niet op het JavaScript niveau (hallo leftpad), maar ook vaak genoeg dat er eigen frameworks, ORMs, ... worden gebouwd i.p.v. libraries gebruiken. NIH gevalletje dus.

[Cartman!]

DevWouter schreef op donderdag 13 augustus 2026 @ 16:46:
[...]

offtopic:
Mwah, je wordt nu wel persoonlijk, dus ik ga daar even op in. Ik heb al 6~7 jaar ervaring met ML en 4 jaar met LLMs, en ChatGPT bestaat pas wat... 3 jaar? Daarbij heb ik ook gewerkt aan een project dat intensief ML gebruikt. Ik zal mezelf geen expert noemen, maar ik weet genoeg van AI om een goede inschatting van het spectrum te hebben. Daarbij lees ik nog regelmatig onderzoeken over LLMs (en dan bedoel ik niet de marketing verhalen). En ja, ik gebruik nog regelmatig AI, hoewel ik het resultaat zelden gebruik om verschillende redenen. Ergo, je onderschat mij zwaar.

Maar om wat inhoudelijker zijn: Geen van de onderzoeken wijzen op een substantieel en betrouwbaar prestatieverbetering. De prestatieverbetering kan je over twisten (want die is er wel met mitsen en maren), maar de betrouwbaarheid is waar ik mij zorgen over maak.

Dank voor de toelichting

Ik gebruik AI om dingen te typen waar ik geen zin heb het van scratch te maken, daarna review ik het in m'n IDE en als t niks is draai ik het terug. Daardoor schrijf ik zelf minder code en heb ik het meer naar m'n zin. Net als andere taken als het samenvatten van een mailtje of een analyze van iets waar ik nu minder tijd aan kwijt ben. En als het onder de streep me even veel tijd kost, ook prima want ik ben immers minder saaie dingen aan het doen. Dus als die auto niet 20x sneller is maar 1.01x sneller dan vind ik het prima. Overigens ben ik (lees: werkgever) nu 50 euro per maand kwijt aan aan abo met tokens waar ik voldoende aan heb, de CFO ligt daar echt niet wakker van

Ik wil gewoon de nuance aanbrengen tussen devs die het gebruiken als hulpmiddel vs developers die enkel hun agents managen en niks zelf schrijven en lukraak pushen/deployen. Dat laatste geloof ik (voorlopig) niet in, dat eerste wel. Je kunt AI/LLMs keihard gaan ontkennen of afzweren maar ik denk dat we er beter mee kunnen leren omgaan.

Ik vind het bijvoorbeeld ook super handig als ik even n visual nodig heb en dit even laat genereren zodat het er meteen netter uitziet dan een random/stock afbeelding.

RayNbow schreef op donderdag 13 augustus 2026 @ 17:01:
Bovenstaande is slechts een eenvoudig voorbeeld van het schrijven van onnodig veel code. Het zou ontwikkelaars dan ook sieren als we zo nu en dan stilstaan bij de bergen code die we produceren en ons afvragen: kan dit niet beknopter?

Maar dat is toch een kwestie van de instructie die je meegeeft aan je junior dev/LLM? Je wijst erop dat dit anders kan, zet dit in een agents file of onboarding en een 2e keer gaat het waarschijnlijk wel goed.

[ Voor 11% gewijzigd door Cartman! op 13-08-2026 17:32 ]

[RayNbow]

Cartman! schreef op donderdag 13 augustus 2026 @ 17:31:
[...]

Maar dat is toch een kwestie van de instructie die je meegeeft aan je junior dev/LLM? Je wijst erop dat dit anders kan, zet dit in een agents file of onboarding en een 2e keer gaat het waarschijnlijk wel goed.

Ja, dat kan voor dit specifieke geval, maar stel dat C# nog geen recordsyntax had. Hadden we dan maar moeten accepteren dat er onnodig veel code moest worden geschreven (hetzij door een mens, hetzij door een LLM) als noodzakelijk kwaad? Of hadden we moeten aansturen op toevoeging van betere taalfeatures zodat we niet allerlei onnodige code moeten schrijven?

Dat is vooral waar ik op doel. Wanneer ik dus tijdens een review naar lappen code kijk die door een LLM zijn opgelepeld, krab ik toch soms achter m'n oren waarom sommige dingen niet korter kunnen.^* Fijn dat we met LLM's het niet zelf meer hoeven te typen, maar ik zie liever een grondigere aanpak.

(* Hierbij nogmaals: ik heb zeker niet altijd een antwoord hoe het korter zou kunnen, maar ik verlang desalniettemin naar een manier om het korter te kunnen uitdrukken.)

[Crazy D]

RayNbow schreef op donderdag 13 augustus 2026 @ 17:01:
[...]

Hier heb ik geen eenduidig antwoord op en vereist voor sommige gevallen uitgebreid onderzoek. Het is dan vooral een kunst om iets te vinden wat ons helpt om bepaalde zaken kort en bondig op te kunnen schrijven.

Een simpel voorbeeld voor C# is dat de taal op een gegeven moment syntax kreeg voor records:

Laatst liet ik een AI-agent los om iets te implementeren en toen ik de code doorlas, viel me op dat 1 specifieke class die de agent gegenereerd had bestond uit een aantal tientallen regels: een aantal properties en een constructor die de properties initialiseerde. Dit had met de recordsyntax in 1 regel gekund.

Bovenstaande is slechts een eenvoudig voorbeeld van het schrijven van onnodig veel code. Het zou ontwikkelaars dan ook sieren als we zo nu en dan stilstaan bij de bergen code die we produceren en ons afvragen: kan dit niet beknopter?

Maar maakt het echt uit dat de code misschien langer is? Als je het zelf niet hoeft te typen, en na compileren is het resultaat mogelijk zelfs identiek. Want met dat uitgangspunt moet je bij elke update naar een nieuwe versie het framework ook meteen heel je codebase refactoren om de nieuwste features te gebruiken. Je hebt immers misschien nog wel een applicatie van 10 jaar terug die allemaal classes gebruikt die nu echt records zouden moeten zijn... Waar leg je die grens?

Wat ik irritanter van LLM-code vind, is dat er een oplossing wordt gemaakt. Het werkt vervolgens niet helemaal lekker, en dan komt ie met "oh ja, dat komt omdat....". Dude, als je weet waarom het niet goed is, had het dan meteen goed gedaan. Of moet ik overal aangeven bij skills "je bent een zeer zeer ervaren developer en je gebruikt altijd de allernieuwste technieken" etc

[Cartman!]

RayNbow schreef op donderdag 13 augustus 2026 @ 17:50:
[...]

Ja, dat kan voor dit specifieke geval, maar stel dat C# nog geen recordsyntax had. Hadden we dan maar moeten accepteren dat er onnodig veel code moest worden geschreven (hetzij door een mens, hetzij door een LLM) als noodzakelijk kwaad? Of hadden we moeten aansturen op toevoeging van betere taalfeatures zodat we niet allerlei onnodige code moeten schrijven?

Dat is vooral waar ik op doel. Wanneer ik dus tijdens een review naar lappen code kijk die door een LLM zijn opgelepeld, krab ik toch soms achter m'n oren waarom sommige dingen niet korter kunnen.^* Fijn dat we met LLM's het niet zelf meer hoeven te typen, maar ik zie liever een grondigere aanpak.

(* Hierbij nogmaals: ik heb zeker niet altijd een antwoord hoe het korter zou kunnen, maar ik verlang desalniettemin naar een manier om het korter te kunnen uitdrukken.)

Als je niet blij bent met wat een taal kan dan ben je vrij een andere taal te kiezen toch? Dat staat los van of er een junior/senior/LLM code voor schrijft.

[RobertMe]

Cartman! schreef op donderdag 13 augustus 2026 @ 18:33:
[...]

Als je niet blij bent met wat een taal kan dan ben je vrij een andere taal te kiezen toch? Dat staat los van of er een junior/senior/LLM code voor schrijft.

Volgens mij ga je voorbij aan het punt van @RayNbow?

Uiteindelijk ontwikkelen talen en frameworks zich allemaal. Als je C# van 10 jaar terug met C# van nu vergelijkt zijn er veel zaken veranderd (lees: voornamelijk toegevoegd), en hetzelfde als je kijkt naar bv .NET.

Programmeertalen staan niet stil, en hetzelfde voor frameworks. Ze maken allemaal evoluties mee. En vaak zie je ook dat ze min of meer dezelfde evoluties meemaken. In C# heb je records, in Java heb je ze meen ik ook, en in PHP heb je ook al een aantal jaren zaken als "constructor property promotion" (constructor parameters kun je als public/protected/private declareren waarmee er meteen een field / property wordt aangemaakt, van hetzelfde type, en de param waarde automatisch wordt toegekend). En ook PHP ondersteund tegenwoordig C# style properties (dus met een getter en setter, i.p.v. een get* en set* method).

En zoals ik al aangaf, een van de grote voordelen van LLMs dat vaak wordt aangehaald is dat het lekker makkelijk is om een DTO te genereren. Maar is "maak class X met string property Y en int property Z" nu echt zoveel makkelijker dan:

PHP:

readonly class X
{
  public function __construct(public string Y, public int $Z) {} 
}

of

C#:

public record X(string Y, int Z);

En zelfs vroeger was het allemaal niet perse van het niveau "hiervoor was een LLM handig".

PHP:

class X
{
    private string $Y;
    private int $Z;
}

+ in PHPStorm Generate => Getters. (+ ik vermoed dat Generate => Constructor ook al een heel eind komt). En vervolgens worden op basis van een (detault aanwezig) template ook die twee get* methods gegenereerd. Daarvoor was dus al geen LLM nodig.

En in het verlengde ligt natuurlijk ook de discussie van een tijdje terug. Waarom genereert een LLM nog leesbare code, en wordt hetgeen dat je aan de LLM vraagt uiteindelijk niet een soort programmeertaal an zich. Zeker voor zoiets als het voorbeeld van DTOs waarbij de programmeertalen dusdanig zijn geëvalueerd dat je in 1 regel een hele DTO kunt declareren dat wellicht minder woorden kost dat je een LLM moet vragen het te genereren.

[Cartman!]

RobertMe schreef op donderdag 13 augustus 2026 @ 20:30:
[...]

Volgens mij ga je voorbij aan het punt van @RayNbow?

Het is letterlijk wat hij zegt "maar stel dat C# nog geen recordsyntax had". Als je recordsyntax wil in C# maar het kan niet dan kun je uitwijken naar een andere taal die dat wel heeft of je hard maken het onderdeel te laten worden van die taal. En in de context van de LLM; als die het op manier A doet en jij wil manier B, dan prompt je dat en wordt t aangepast, voeg je t aan de agents file toe en de keer erop doet ie meteen manier B.

Als een DTO met x/y is wat je moet hebben kun je t erover hebben maar in praktijk is het natuurlijk meer dan dat.

[ Voor 8% gewijzigd door Cartman! op 13-08-2026 21:12 ]

[DevWouter]

RobertMe schreef op donderdag 13 augustus 2026 @ 20:30:
[...]

Volgens mij ga je voorbij aan het punt van @RayNbow?

Uiteindelijk ontwikkelen talen en frameworks zich allemaal. Als je C# van 10 jaar terug met C# van nu vergelijkt zijn er veel zaken veranderd (lees: voornamelijk toegevoegd), en hetzelfde als je kijkt naar bv .NET.

Programmeertalen staan niet stil, en hetzelfde voor frameworks. Ze maken allemaal evoluties mee. En vaak zie je ook dat ze min of meer dezelfde evoluties meemaken. In C# heb je records, in Java heb je ze meen ik ook, en in PHP heb je ook al een aantal jaren zaken als "constructor property promotion" (constructor parameters kun je als public/protected/private declareren waarmee er meteen een field / property wordt aangemaakt, van hetzelfde type, en de param waarde automatisch wordt toegekend). En ook PHP ondersteund tegenwoordig C# style properties (dus met een getter en setter, i.p.v. een get* en set* method).

En zoals ik al aangaf, een van de grote voordelen van LLMs dat vaak wordt aangehaald is dat het lekker makkelijk is om een DTO te genereren. Maar is "maak class X met string property Y en int property Z" nu echt zoveel makkelijker dan:

PHP:

readonly class X
{
  public function __construct(public string Y, public int $Z) {} 
}

of

C#:

public record X(string Y, int Z);

En zelfs vroeger was het allemaal niet perse van het niveau "hiervoor was een LLM handig".

PHP:

class X
{
    private string $Y;
    private int $Z;
}

+ in PHPStorm Generate => Getters. (+ ik vermoed dat Generate => Constructor ook al een heel eind komt). En vervolgens worden op basis van een (detault aanwezig) template ook die twee get* methods gegenereerd. Daarvoor was dus al geen LLM nodig.

En in het verlengde ligt natuurlijk ook de discussie van een tijdje terug. Waarom genereert een LLM nog leesbare code, en wordt hetgeen dat je aan de LLM vraagt uiteindelijk niet een soort programmeertaal an zich. Zeker voor zoiets als het voorbeeld van DTOs waarbij de programmeertalen dusdanig zijn geëvalueerd dat je in 1 regel een hele DTO kunt declareren dat wellicht minder woorden kost dat je een LLM moet vragen het te genereren.

Dan pak ik even C++.

C++:

#include <iostream>

template <typename T> struct Vec3 { T x, y, z; };
using Vec3f = Vec3<float>;
using Vec3d = Vec3<double>;
template<typename T> Vec3<T> Vec3Add(const Vec3<T>& a, const Vec3<T>& b) {
    return { a.x + b.x, a.y + b.y, a.z + b.z };
}

int main()
{
    Vec3f a = { 1, 2, 3 };
    Vec3f b = { 4, 5, 6 };
    Vec3f c = Vec3Add(a, b);

    std::cout
            << "x: " << c.x << "\t"
            << "y: " << c.y << "\t"
            << "z: " << c.z;

    return 0;
}

Zelfs met de meeste recente versie van C# is het niet fijn om je eigen vector class te schrijven. En het wordt helemaal vervelend als je rekening moet houden met memory fragmentatie en/of const.

[RayNbow]

Cartman! schreef op donderdag 13 augustus 2026 @ 18:33:
[...]

Als je niet blij bent met wat een taal kan dan ben je vrij een andere taal te kiezen toch? Dat staat los van of er een junior/senior/LLM code voor schrijft.

Nu weerspiegelt @RobertMe's reactie al grotendeels mijn gedachte, maar ik pak ook even een stuk van de laatste alinea erbij:

RobertMe schreef op donderdag 13 augustus 2026 @ 20:30:
En in het verlengde ligt natuurlijk ook de discussie van een tijdje terug. Waarom genereert een LLM nog leesbare code, en wordt hetgeen dat je aan de LLM vraagt uiteindelijk niet een soort programmeertaal an zich."

Wat als er situaties zijn waarbij de prompt korter is dan de bijbehorende gegenereerde code? Wat zegt dat over de expressiviteit van de doeltaal?

Mij zegt dat er kansen liggen om de desbetreffende programmeertaal te evolueren zodanig dat de voorheen gegenereerde code kan worden teruggebracht naar iets wat dichter bij de prompt ligt.

[Firesphere]

DevWouter schreef op donderdag 13 augustus 2026 @ 16:29:

[...]

Autonomie staat hier voor zelfstandig functioneren, dus zonder invloed van buiten af. Heel oud voorbeeld: Ik had vroeger een sneltoets waarbij ik auto complete volledig uitschakel zodat member variables/functies type ipv ging scrollen door een lijst. Dit omdat typen sneller was dan scrollen in de lijst.

Een voormalige collega van mij verwoorde dit wel mooi:

I am not afraid of AI taking our jobs, I'm afraid it's taking our minds.

Cartman! schreef op donderdag 13 augustus 2026 @ 15:11:
[...]

Je ziet AI blijkbaar als iets wat of niet bestaat of volledig je werk overneemt maar er zit een hoop tussenin.

Bijna elke stap boven "niet gebruiken", heeft om mij heen tot nu toe alleen maar geleidt tot "niet meer zelf nadenken".

Een mooie illustratie: https://calnewport.com/on-ai-coding-and-its-discontents/

Cartman! schreef op donderdag 13 augustus 2026 @ 16:43:
[...]

Precies, daarom zie ik het als een tool om te typen waar ik geen zin in heb zodat ik me bezig kan houden met andere zaken. Ik ben dan ook niet bang dat ik als ontwikkelaar zonder werk kom te zitten.

Ik vind het schrijven van code leuk. Waarom zou ik dat weg willen geven. En welke andere zaken zou ik me bezig mee willen houden.

Ik ben in de eerste plaats software engineer, niet een kleuterklas begeleider die kinderen vraagt iets te doen, en dan maar moet hopen dat wat ze doen ook inderdaad is wat het moet zijn.

[RayNbow]

DevWouter schreef op donderdag 13 augustus 2026 @ 23:07:
[...]

Dan pak ik even C++.

C++:

#include <iostream>

template <typename T> struct Vec3 { T x, y, z; };
using Vec3f = Vec3<float>;
using Vec3d = Vec3<double>;
template<typename T> Vec3<T> Vec3Add(const Vec3<T>& a, const Vec3<T>& b) {
    return { a.x + b.x, a.y + b.y, a.z + b.z };
}

int main()
{
    Vec3f a = { 1, 2, 3 };
    Vec3f b = { 4, 5, 6 };
    Vec3f c = Vec3Add(a, b);

    std::cout
            << "x: " << c.x << "\t"
            << "y: " << c.y << "\t"
            << "z: " << c.z;

    return 0;
}

Zelfs met de meeste recente versie van C# is het niet fijn om je eigen vector class te schrijven. En het wordt helemaal vervelend als je rekening moet houden met memory fragmentatie en/of const.

Wat je geschreven hebt is natuurlijk geen vector. Ik mis op z'n minst een manier om een vector te kunnen schalen.

Maar het schrijven van vector-achtige classes in C# is zeker niet eenvoudig. Bij het schrijven van tests kwam ik erachter dat ik mezelf begon te herhalen. Hierdoor heb ik op werk een abstracte testklasse VectorSpaceTests<TVector> geïntroduceerd en hoef ik voor elk nieuw vectortype zeer weinig testcode te schrijven (namelijk alleen VectorSpaceTests<TVector> overerven en o.a. aangeven hoe je instanties maakt).

Het zou echter ook fijn zijn als het concept van een vectorruimte sterker in een programmeertaal kan worden vastgelegd zodat het schrijven van nieuwe vectortypes makkelijker wordt.

[Cartman!]

Firesphere schreef op vrijdag 14 augustus 2026 @ 03:30:
Ik vind het schrijven van code leuk. Waarom zou ik dat weg willen geven. En welke andere zaken zou ik me bezig mee willen houden.

Persoonlijk vind ik het schrijven van unit tests of kleinere features minder interessant, dat iets of iemand anders dat voor me doet waarna ik t enkel hoef te controleren vind ik heerlijk. Ik ben ook een groot deel van m'n tijd kwijt om nieuwe features te bespreken en uit te denken, daar maak ik ter ondersteuning ook wel eens gebruik van AI om tot de juiste termen/flows te komen die door andere platforms ook gebruikt wordt bijvoorbeeld.

Ik ben in de eerste plaats software engineer, niet een kleuterklas begeleider die kinderen vraagt iets te doen, en dan maar moet hopen dat wat ze doen ook inderdaad is wat het moet zijn.

AI is, afhankelijk van de taal natuurlijk, echt van een flink hoger niveau dan een kleuter.

Daarnaast is het niet enkel een code schrijven, andere zaken waar ik het ook voor gebruik:

• voeren met een vage bug melding en dan zoekt ie zelf uit wat er misschien aan de hand is en hoe het te fixen is
• een model als Opus of Fable vragen een security audit te doen, daar komen soms toch nog nuttige dingen uit ondanks dat we platformen als Aikido en Sonarcloud geintegreerd hebben die grotendeels hetzelfde zou moeten doen
• In plaats van zoeken in documentatie gewoon de LLM de vraag stellen
• een SQL explain erin mikken "wat kan ik doen om te optimalizeren"
• een afbeelding genereren als voorbeeld zodat t er net ff wat beter uit ziet dan een standaard stock image

Het is zoveel meer dan enkel code schrijven en ik ben op dit moment enorm blij dat ik me eroverheen heb gezet en het gewoon ben gaan gebruiken. Dat gezegd hebbende zit ik dus niet in de hoek dat ik met agents aan de slag ga die achter de schermen doorwerken, daar ben ik nog lang niet en heb ik momenteel ook minder vertrouwen in.

RayNbow schreef op vrijdag 14 augustus 2026 @ 03:16:
Wat als er situaties zijn waarbij de prompt korter is dan de bijbehorende gegenereerde code? Wat zegt dat over de expressiviteit van de doeltaal?

Mij zegt dat er kansen liggen om de desbetreffende programmeertaal te evolueren zodanig dat de voorheen gegenereerde code kan worden teruggebracht naar iets wat dichter bij de prompt ligt.

Ik vind het een interessante gedachte maar het gevaar dat je als developer dan niet meer weet hoe het werkt omdat de uitvoer afhankelijk kan worden van een bepaalde versie of model. Als het in een bepaalde taal staat kun je het beter valideren. In de toekomst komen daar mogelijk ook standaarden voor en kan het vergelijkbaar worden met no/low code.

[ Voor 16% gewijzigd door Cartman! op 14-08-2026 09:33 ]

[Firesphere]

Cartman! schreef op vrijdag 14 augustus 2026 @ 09:29:


[...]

AI is, afhankelijk van de taal natuurlijk, echt van een flink hoger niveau dan een kleuter.

Goeie grap!

Het is zoveel meer dan enkel code schrijven en ik ben op dit moment enorm blij dat ik me eroverheen heb gezet en het gewoon ben gaan gebruiken. Dat gezegd hebbende zit ik dus niet in de hoek dat ik met agents aan de slag ga die achter de schermen doorwerken, daar ben ik nog lang niet en heb ik momenteel ook minder vertrouwen in.

Afgezien van de totale nutteloosheid, ben ik ook niet zo'n fan van het verbranden van de omgeving omdat er een bugje is. Zowel functionel als moreel is het een verwerpelijk gebied.

Wat iedereen die het zo geweldig magnifiek vind gemeenschappelijk heeft, is dat ze liever niet zelf nadenken, en het geen probleem vinden om anderen aan het werk te zetten voor hun eigen luiheid.

Als jij niet de moeite wil nemen om zelf na te denken over de code die je wil opleveren, neem ik de moeite niet om het voor je na te kijken.

[Kalentum]

Firesphere schreef op vrijdag 14 augustus 2026 @ 03:30:
[...]

Een voormalige collega van mij verwoorde dit wel mooi:


[...]


[...]

Bijna elke stap boven "niet gebruiken", heeft om mij heen tot nu toe alleen maar geleidt tot "niet meer zelf nadenken".

Een mooie illustratie: https://calnewport.com/on-ai-coding-and-its-discontents/

[...]

Ik vind het schrijven van code leuk. Waarom zou ik dat weg willen geven. En welke andere zaken zou ik me bezig mee willen houden.

Ik ben in de eerste plaats software engineer, niet een kleuterklas begeleider die kinderen vraagt iets te doen, en dan maar moet hopen dat wat ze doen ook inderdaad is wat het moet zijn.

Code schrijven is leuk maar ook maar 1 onderdeel van het vak. Voordat je code schrijft zit er nog een proces van 'hoe organiseer ik alles' (classes/ interfaces / methods) en daarvoor zit nog een fase 'hoe kan ik feature X implementeren'. En na het code schrijven zit er nog een stuk testen / reviewen (van je eigen werk) in.

AI helpt bij een heleboel van deze stappen. Maar je blijft zelf in de driver seat. Je blijft verantwoordelijk voor kwaliteit en correctheid. Zolang mensen nog naar code kijken zal code ook leesbaar en begrijpelijk moeten zijn.

[Cartman!]

Firesphere schreef op vrijdag 14 augustus 2026 @ 09:39:
Goeie grap!

Als dit jouw manier van discussieren is dan ben ik er wel klaar mee.

[Firesphere]

Kalentum schreef op vrijdag 14 augustus 2026 @ 09:49:
[...]


Code schrijven is leuk maar ook maar 1 onderdeel van het vak. Voordat je code schrijft zit er nog een proces van 'hoe organiseer ik alles' (classes/ interfaces / methods) en daarvoor zit nog een fase 'hoe kan ik feature X implementeren'. En na het code schrijven zit er nog een stuk testen / reviewen (van je eigen werk) in.

AI helpt bij een heleboel van deze stappen. Maar je blijft zelf in de driver seat. Je blijft verantwoordelijk voor kwaliteit en correctheid. Zolang mensen nog naar code kijken zal code ook leesbaar en begrijpelijk moeten zijn.

Ik wijs maar even terug naar het artikel dat ik eerder al linkte, https://calnewport.com/on-ai-coding-and-its-discontents/ In theorie blijf je zelf aansturen en "in de loop" enzo, maar het werkt in de praktijk dus geheel anders. En dat zie ik overal terug komen. Mensen die compleet geen idee meer hebben van wat ze eigenlijk aan het doen zijn. En onzin uitkramen over de code die ze hoegenaamd "zelf" geschreven hebben.

En bedankt voor uitleggen hoe mijn werk in elkaar steekt

[Kalentum]

Firesphere schreef op vrijdag 14 augustus 2026 @ 12:18:
[...]

Ik wijs maar even terug naar het artikel dat ik eerder al linkte, https://calnewport.com/on-ai-coding-and-its-discontents/ In theorie blijf je zelf aansturen en "in de loop" enzo, maar het werkt in de praktijk dus geheel anders. En dat zie ik overal terug komen. Mensen die compleet geen idee meer hebben van wat ze eigenlijk aan het doen zijn. En onzin uitkramen over de code die ze hoegenaamd "zelf" geschreven hebben.

Alles verandert altijd. Mensen leren. Organisaties moeten zich aanpassen op andere werkwijzes.

Ik ben ooit begonnen vanuit boeken. Dat je Programming Perl naast je hebt liggen op een bureau En Perl Cookbook. Toen werden search engines goed genoeg, gingen we allemaal van forums copy/pasten en dat dan aanpassen. Toen kwam StackOverflow. TDD. En nu AI (LLM's). En wie weet wat er over 5 jaar langs komt.

Dat artikel wat je linkt zegt het goed "But I think there’s a lot more work to be done trying to figure out how to integrate AI into this industry in a way that actually works." In die fase zitten we nu. Ik herken de weerstand en ik heb ook wel wat morele kanttekeningen.

Ook mooi trouwens dat stukje over bedrijfscultuur: als je medewerker 2x productie crasht, ga je kijken hoe dat komt en wat je als organisatie kan doen om dat te voorkomen. En niet dreigen met ontslag. Maar goed, dat terzijde.

[eheijnen]

Firesphere schreef op vrijdag 14 augustus 2026 @ 12:18:
[...]

Ik wijs maar even terug naar het artikel dat ik eerder al linkte, https://calnewport.com/on-ai-coding-and-its-discontents/ In theorie blijf je zelf aansturen en "in de loop" enzo, maar het werkt in de praktijk dus geheel anders. En dat zie ik overal terug komen. Mensen die compleet geen idee meer hebben van wat ze eigenlijk aan het doen zijn. En onzin uitkramen over de code die ze hoegenaamd "zelf" geschreven hebben.

En bedankt voor uitleggen hoe mijn werk in elkaar steekt

Wat je veel hoort is dat AI de junior vervangt. Of dat daadwerkelijk een gerechtvaardigde bevinding is, is niet duidelijk. Deze boodschap kan net zo goed uit de hoek van de AI-boeren zelf komen. Juist om beslissers zover te krijgen hun diensten af te nemen.

Waar deze boodschap op strand, is op het feit dat mediors en seniors doorgaans juniors zijn geweest, en daarmee op termijn een gebrek aan ervaren personeel ontstaat. Links en rechts al wat cijfers zien langskomen dat de keuze voor dev-opleidingen met zo'n 20% is gedaald sinds de introductie van AI.

De vraag is of binnen die termijn AI zover kan worden doorontwikkeld dat Henk en Ingrid daadwerkelijk met een potje klikken een solide oplossing in elkaar kunnen zetten. Misschien dat Henk en zijn vrouw daar nog een vendor based training voor moeten doen, maar dat zou het ook moeten zijn.

Sinds de resultaten van AI non-deterministisch zijn kun je momenteel niet tot een sluitende conclusie komen.

[DevWouter]

eheijnen schreef op vrijdag 14 augustus 2026 @ 15:34:
[...]


Wat je veel hoort is dat AI de junior vervangt. Of dat daadwerkelijk een gerechtvaardigde bevinding is, is niet duidelijk.

Hier een bron om jouw stelling te onderbouwen: https://jobsbyculture.com/blog/junior-developer-crisis-2026. Let op! Er worden drie oorzaken genoemd.

Entry-level developer roles are down about 67% from 2022. Employment for developers aged 22–25 has fallen roughly 20% from its peak, and juniors now make up 7% of new IT hires (down from 15%). The cause is a stack of forces — AI coding tools, post-2022 correction, and a redefinition of what "entry-level" means — not one villain. Below: the three forces, who’s still hiring, and the four routes juniors are using to break in this year.

[eheijnen]

@Firesphere
Wat meer diepgang vanuit de markt:
https://news.lavx.hu/arti...stors-who-piled-into-them

[eheijnen]

Benieuwd of de andere AI-boeren ook zo'n groei laten zien...
nieuws: Bloomberg: kwartaalomzet Anthropic verveertienvoudigt tot 11,5 miljar...

[DevWouter]

eheijnen schreef op maandag 17 augustus 2026 @ 16:33:
Benieuwd of de andere AI-boeren ook zo'n groei laten zien...
nieuws: Bloomberg: kwartaalomzet Anthropic verveertienvoudigt tot 11,5 miljar...

Mooi getal, en uiteraard compleet toevallig voor de beursgang. En dat omzet een factor 10 is zegt vrij weinig als we de kosten niet weten.

Het probleem is vooral de schaalbaarheid en beschikbaarheid van AI op een grote schaal. Ik weet even niet welke AI boer het was, maar er is er in elk geval 1 die bezig is om de toegang te beperken op piek momenten. Los van de winstgevendheid van kunstmatige schaarste is dit vooral vervelend voor eind gebruikers die te maken krijgen met een onbetrouwbaar product.

Zo las ik vandaag ook weer wat berichten van echt expert (en groot LLM fan) die aangaf dat de recente modellen van Claude Max voor zijn situatie afschuwelijk functioneren. Uiteraard een n=1 argument (zelfs als het om een expert ga), maar ik vermoed al een tijdje dat ze de modellen aan het optimaliseren zijn voor latency ipv kwaliteit, om zo minder kosten te hebben wanneer ze opschalen.

[Oon]

eheijnen schreef op maandag 17 augustus 2026 @ 16:33:
Benieuwd of de andere AI-boeren ook zo'n groei laten zien...
nieuws: Bloomberg: kwartaalomzet Anthropic verveertienvoudigt tot 11,5 miljar...

Grappig dat dit soort bedrijven gewoon getallen uit de lucht toveren. Knap staaltje creatief boekhouden.
Zolang op https://isaiprofitable.com/ geen grote "YES." staat geloof ik er helemaal niks van

[eheijnen]

In Amazon hebben ze jaren geld ingestoken en alleen verlies gedraaid. En ondertussen de concurrentie stelselmatig uit de markt gedrukt. De rest is geschiedenis...

Zo'n bericht kan investeerders naar Anthropic laten tenderen ipv een andere firma. Want als ze verder willen / moeten opschalen hebben ze meer kapitaal nodig.

[eheijnen]

Oon schreef op maandag 17 augustus 2026 @ 16:54:
[...]

Grappig dat dit soort bedrijven gewoon getallen uit de lucht toveren. Knap staaltje creatief boekhouden.
Zolang op https://isaiprofitable.com/ geen grote "YES." staat geloof ik er helemaal niks van

Lijkt me sterk dat ze zoiets verzinnen of overdrijven...
Tacteren kan natuurlijk altijd.

[eheijnen]

Als de andere AI boeren ook zo'n groei kunnen laten zien dan is er sprake van correlatie. Zo niet trekken gebruikers van X naar Anthropic....

[Kalentum]

eheijnen schreef op maandag 17 augustus 2026 @ 16:58:
[...]

Lijkt me sterk dat ze zoiets verzinnen of overdrijven...
Tacteren kan natuurlijk altijd.

Overdrijven kan, want ze zijn een niet-beursgenoteerd bedrijf. Boekhouding moet kloppen maar dit zijn geen officiële kwartaalcijfers.

[eheijnen]

Erg benieuwd hoe de competitie op dit bericht reageert....

[Vihaio]

Kalentum schreef op maandag 17 augustus 2026 @ 17:04:
[...]


Overdrijven kan, want ze zijn een niet-beursgenoteerd bedrijf. Boekhouding moet kloppen maar dit zijn geen officiële kwartaalcijfers.

Overdrijven kan niet altijd als privaat bedrijf. Het kan met name niet in de maanden voordat je een publiek bedrijf wordt, de FTC is dan heel streng in wat je wel en niet naar buiten mag brengen.

Bloomberg zou natuurlijk wel cijfers kunnen overdrijven of verzinnen, maar Anthropic kan dat op dit moment niet.

[DevWouter]

Ik heb net een studie gelezen en daar komt het gebruik van AI niet op positief uit (had je iets anders van mij verwacht?). Wat vooral waardevol is aan deze studie is dat het onderzoeken gebruikt die vrij recent zijn en ze ook als bron aan het einde heeft.

Een paar opvallende dingen voor mij:

• LLM accuraat krijgen is verschrikkelijk duur. Elke orde van grote terugbrengen is substantieel duurder dan de vorige. Als je een model heb die 30% van de tijd een fout antwoord geeft en je wilt dat terug brengen naar 3% dan heb je een factor van 10^20 aan extra rekenkracht en energie nodig. Dus vermenigvuldiging de kosten met 100.000.000.000.000.000.000 (mogelijk dat ik een nul te veel of te weinig heb).
  • Dit is voor het trainen, niet het gebruik.
• LLM kan geen onderscheid maken tussen recent en verouderd. De reden hiervoor is omdat het gewicht/waarschijnlijkheid van de tokens bepalend is, het heeft dus moeite om oplossingen uit een verschillende tijdperken te onderscheiden.
• Hoe groter de context, hoe meer fouten er in sluipen en hoe minder respect de context krijgt.
• Markdown files introduceren ruis voor een LLM (maar goed nieuws, niet meezenden als context is input-tokens besparen)
• LLMs kunnen niet omgaan met taken waarbij de context breed is.
  • Hiermee wordt bedoelt dat als je in A iets verander het nog wel door heeft wat de impact is op B en C, maar niet op X, Y, en Z.
  • Je kan het vergelijkt met auto rijden. Een LLM kan nooit verder kijken dan 5 meter vooruit ongeacht of het zonnig of mistig is. Het zal dus sneller op de linkerbaan gaan rijden terwijl je over 100 meter er rechts af moet.
• LLM versterkt zowel(!) de zwaktes als kracht van je ontwikkel proces, maar het lost problemen in je ontwikkelproces niet op.
• Psychologen zien zorgelijk veel overeenkomsten tussen mensen die overtuigd zijn in LLM en mensen die bijgelovig zijn.

Side note: Dat van context breedte ben ik recent achter gekomen. Ik was een Wikipedia: Woordladder aan het spelen en zat vast, dus ik dacht, dit zou een AI vrij makkelijk kunnen. En boy, oh boy… Hij kent de regels, maar overtreed ze elke keer. Van lengte van het woord aanpassen, tot twee letter gelijktijdig aanpassen, tot woorden die niet bestaan. Het mooiste vond ik toen het aangaf dat het onmogelijk was (bullshit, dit soort puzzels hebben altijd een oplossing) omdat het geen stap kon vinden tussen twee woorden, terwijl de meeste recente poging die stap wel had gevonden. Het was oprecht fascinerend voor mij hoe veel moeite het had.

Bron:

• https://codemanship.wordpress.com/2026/08/12/ai-software-development-what-does-the-data-say/