De Devschuur Coffee Corner - Iteratie ⑬

[DevWouter]

DaFeliX schreef op donderdag 27 augustus 2026 @ 11:24:
[...]

Maar mijn codebase lijkt in de verre verte niet op die van cURL. Dus dat Daniel een andere ervaring met zijn codebase heeft lijkt me niet meer dan logisch

Die van mij lijkt ook niet op cURL desondanks heb ik dezelfde ervaring. Welk variabel is constant bij deze vergelijkingen?

[Koenvh]

eheijnen schreef op donderdag 27 augustus 2026 @ 09:35:
[...]


Schijnt toch niet allemaal kommer en kwel te zijn:
https://www.bbc.co.uk/news/articles/cjwg5n7y68xo

Kalentum schreef op donderdag 27 augustus 2026 @ 09:38:
[...]


Je kan het taalgebruik wel een beetje sturen door project level instructies mee te geven.

Ik zie niet hoe dat helpt met de meldingen van beveiligingsproblemen (aldus de LLM) die ik in m'n e-mail ontvang. Nogmaals: Open Source, dus iedereen in de wereld kan LLMs loslaten op onze code (en dat gebeurt dus ook). Soms zitten er waardevolle dingen tussen, soms wat minder, maar om dat te extraheren uit de "vulnerability report" die door LLMs gegenereerd wordt is best een uitdaging vanwege de vaak vrij onduidelijke beschrijving.

DaFeliX schreef op donderdag 27 augustus 2026 @ 10:42:
[...]

Ik heb met behulp van LLM's wel een aantal beveiligingsproblemen gevonden in oude code (~ 350.000 regels code). Deze waren vrijwel onmogelijk te misbruiken, maar toch vond ik het fijn om ze gevonden te hebben en te fixen. Maar ondanks dat ik nu meerdere modellen op dezelfde codebase heb losgelaten, heb ik het idee dat toch niet elk probleem is gevonden.

ZIjn er mensen met ervaring hier?

Het liefst draai ik het model lokaal, zodat ik het lekker kan laten churnen zonder mij druk te maken over de kosten van een 'analyze'. Tot nu toe heb ik echter Copilot en Claude gebruikt.

Ik stuur dan bijvoorbeeld heel erg aan op het vinden van 1 specifiek probleem ("spoor SQL injection op") ipv "zoek alle security issues". De laatste keer dat ik dit deed kreeg ik een lijst van ~ 20 bevindingen, waarvan 1 legitiem en de rest kul was. Het heeft mij wel een dag gekost om de 20 bevindingen te triageren, dus heb niet zoveel zin om dezelfde exercitie weer te doen als daar hetzelfde resultaat uit gaat komen. Ik heb nu dus een beetje het idee dat ik hier niet meer veel uit kan halen, zonder dat ik echt iets anders ga proberen.

Ja, best wat ervaring ondertussen. We hadden een externe (menselijke) audit tegelijkertijd met wat security issues die binnenkwamen op basis van LLM-bevindingen. Beide vonden toch grotendeels andere dingen. Overigens zit er veel verschil tussen de kwaliteit van de LLM-bevindingen, en bij ons zit er dus nog een laag tussen met een mens die de e-mail naar ons opstelt (en hopelijk ook ziet als iets nergens op slaat), maar ik ben vaak ook wel een aantal uur bezig om erachter te komen wat het probleem nou daadwerkelijk is (en of het een probleem is, en of het impact heeft). Wel minder regels code (weliswaar in Rust, ik denk dat de Java-variant drie keer zo lang zou zijn )

[eheijnen]

Koenvh schreef op donderdag 27 augustus 2026 @ 19:25:
maar om dat te extraheren uit de "vulnerability report" die door LLMs gegenereerd wordt is best een uitdaging vanwege de vaak vrij onduidelijke beschrijving.

Ja wat OT, maar wel interessant, imo.

En als je dat extraheren ook nog eens door de llm laat doen?
Vaak loont om de llm het antwoord beter te laten formuleren...

[DevWouter]

eheijnen schreef op donderdag 27 augustus 2026 @ 19:49:
[...]


Ja wat OT, maar wel interessant, imo.

En als je dat extraheren ook nog eens door de llm laat doen?
Vaak loont om de llm het antwoord beter te laten formuleren...

Een onduidelijke vraag/verhaal leidt vaak tot een onduidelijk (en onjuist) antwoord. En dat heeft niks met LLMs te maken.

Bovendien is de oplossing veel simpeler: De rapporten die aangeleverd worden moeten duidelijk zijn.

[eheijnen]

DevWouter schreef op donderdag 27 augustus 2026 @ 20:38:
[...]
Bovendien is de oplossing veel simpeler: De rapporten die aangeleverd worden moeten duidelijk zijn.

Nog een oplossing / mogelijkheid. Maar zeker iets om naar te vragen als ze iets aanleveren.
Niet duidelijk is of daar controle over uitgeoefend kan worden.

Maar dat belabberde rapport dat je juist daarom aan de kant gooit kan toch wel eens een concrete melding zijn. En die loop je dan mis.

Eventueel ze de hele chat sessie laten meesturen kun je die zelf er ook nog eens doorhalen.

[DevWouter]

eheijnen schreef op donderdag 27 augustus 2026 @ 21:25:
[...]


Nog een oplossing / mogelijkheid. Maar zeker iets om naar te vragen als ze iets aanleveren.
Niet duidelijk is of daar controle over uitgeoefend kan worden.

Maar dat belabberde rapport dat je juist daarom aan de kant gooit kan toch wel eens een concrete melding zijn. En die loop je dan mis.

Eventueel ze de hele chat sessie laten meesturen kun je die zelf er ook nog eens doorhalen.

Dat is de omgekeerde wereld. Je mag echt wel eisen dat een ander hun werk doen.

[AlphaRomeo]

Heel herkenbaar, ik zit ook al lang bij dezelfde organisatie en verslijt ook managers alsof het autobanden zijn. Wel vind ik de performance reviews altijd een mooie gelegenheid om zelf even wat hoogtepunten bij elkaar te sprokkelen. Ik bereid me dus juist wel altijd goed en grondig voor in de wetenschap dat mijn manager dat niet zal doen en wordt daarmee dus altijd positief beoordeeld en ik heb bovendien een sterke onderhandelingspositie.

Tegenwoordig moet ik zelf ook aardig wat performance reviews moet houden met mijn team, maar daar probeer ik juist weer niet verrast te worden door mij goed voor te bereiden. Bovendien denk ik dat ik mij veel beter in hen kan inleven omdat ik ook gewoon nog steeds met mijn poten in de code sta.

Ik denk onder de streep dat het niemands hobby is, aan beide kanten van de tafel niet. Met uitzondering van wat ras-bureaucraten die hier waarschijnlijk natte dromen over hebben.

[Kalentum]

DevWouter schreef op donderdag 27 augustus 2026 @ 19:10:
[...]

Ik kan het nog veel erger maken voor je. Er zijn genoeg onderzoeken waaruit blijkt dat per kwartaal toch zo'n beetje het minimum is als je actionables uit je review wil gebruiken. Langer dan dat en het heeft geen enkele waarde voor het personeel of de manager. Ik meen me te herinneren dat per kwartaal zo'n beetje het minimum was om er echt waarde uit te halen.

Wat je als manager wel moet doen is per jaar een rapport hebben die volgens dezelfde systematiek is vast gelegd.

Dus... Waarschijnlijk heeft jouw manager er net zoveel schijt aan als jij.

Ik heb het met mijn manager over mijn afkeer gehad. Uiteindelijk kwam het er op neer dat mijn belang voornamelijk is dat de manager voldoende informatie heeft om mij te bespreken in de calibratiesessies die als basis dienen voor salarisverhogingen en/of promoties. Dus voor mij is het terugkijkdeel (wat heb ik gedaan) belangrijker dan het vooruitkijkdeel (doelen enzo)

Ach ja we gaan het zien, dit is een tussentijds functioneringsgesprek en over een half jaar zal ik mij zuchtend en steunend door de zelfevaluatie voor het beoordelingsgesprek slepen.

Ik citeer de LLM die mij hielp om de data bij elkaar te sprokkelen:

The review is submitted, the evidence is real, and the anxiety can go back in the drawer until February.

[Mugwump]

Ik heb met mijn manager een prima verstandhouding. Ik zorg dat ik maximaal facturabel ben, hij zorgt dat ie al die verplichte hoepeltjes waar ik geen trek in heb bij me weghoudt.

[DevWouter]

Mugwump schreef op vrijdag 28 augustus 2026 @ 11:10:
Ik heb met mijn manager een prima verstandhouding. Ik zorg dat ik maximaal facturabel ben, hij zorgt dat ie al die verplichte hoepeltjes waar ik geen trek in heb bij me weghoudt.

En dat is het kenmerk van een goede manager. Een goede manager "managet" zijn mensen niet. Een goede manager bedient zijn mensen zodat zij hem kunnen bedienen.

[eheijnen]

Interessant stuk over AI en investeringen
https://news.lavx.hu/arti...stors-who-piled-into-them

[eheijnen]

DevWouter schreef op vrijdag 28 augustus 2026 @ 01:04:
[...]

Dat is de omgekeerde wereld. Je mag echt wel eisen dat een ander hun werk doen.

Kun je zeker doen in een OSS project.

[Voutloos]

Dat kan dus niet. De ruis is onbeperkt en jouw tijd niet.

Zonder minimale inspanning melder is het signaal niet veel sterker dan een horoscoop: “vissen: als je deze maand goed naar je repo kijkt, vind je een issue”

[ Voor 6% gewijzigd door Voutloos op 29-08-2026 12:49 ]

[DevWouter]

Voutloos schreef op zaterdag 29 augustus 2026 @ 08:51:
Dat kan dus niet. De ruis in onbeperkt en jouw tijd niet.

Zonder minimale inspanning melder is het signaal niet veel sterker dan een horoscoop: “vissen: als je deze maand goed naar je repo kijkt, vind je een issue”

Lijkt me wel een hele leuke horoscoop om elke week te lezen.

[Koenvh]

DevWouter schreef op zaterdag 29 augustus 2026 @ 12:26:
[...]

Lijkt me wel een hele leuke horoscoop om elke week te lezen.

Inderdaad, doet me denken aan de horoscoop die je op het Wii Horoscoopkanaal kreeg destijds

[DevWouter]

eheijnen schreef op zaterdag 29 augustus 2026 @ 06:42:
[...]

Kun je zeker doen in een OSS project.

Niet alleen in OSS.

[Lethalis]

Hoe meer AI ik gebruik, hoe rotter ik het vind. There, I said it.

In deze sector kan ik dan na 25 jaar ervaring in de software ontwikkeling blijkbaar beter iets anders gaan doen. Gelukkig geeft mijn werkgever er niet om.

Ik moet echt feeling met de code hebben, wil ik bugs kunnen oplossen of in detail dingetjes kunnen aanpassen. Met AI krijg ik steeds vaker het gevoel dat ik iemand anders zijn code loop te fixen en oh boy... dat vind ik al 25 jaar extreem vervelend om te doen.

I'll see myself out.

Bron van deze rant: ik heb in een project allerlei functionaliteit met AI gegenereerd en dat ging goed tot op een bepaald punt. Totdat ik bepaalde aanpassingen wou die ik de agent niet aan zijn verstand kon peuteren en ik elke keer net niet kreeg wat ik wou. Vervolgens wil ik het met de hand fixen en voel ik een soort cognitieve dissonantie ofzo. Het is niet meer mijn code. Ik weet niet meer uit mijn hoofd wat elke regel doet. Uiteraard kan ik mij daar wel weer in verdiepen, alleen de mentale overhead daarvan is dermate dat ik geneigd ben het gewoon weg te donderen en opnieuw met de hand te coderen.

Einde zondagmiddag rant Efficiency is naar het nulpunt gedaald iig. Met de hand had ik er in eerste instantie misschien iets langer over gedaan, maar was ik niet vastgelopen op dit punt en had ik het rustig afgemaakt.

Er zitten ook allerlei idiote bugs in die er niet in hadden gezeten als ik het meteen met de hand had geschreven pfff. De grap is dat backend API genereren nog best aardig ging (rechttoe rechtaan CRUD), maar dat de Angular frontend code een rommeltje is geworden (moet anders werken op verschillende schermgroottes en dus stuk complexer... bovendien vage bugs waarbij oude informatie getoond wordt, dus data wordt niet meteen ververst etc).

Het is allemaal fixbaar, maar ik had het meteen goed gedaan zelf, omdat ik mij daar bewust van ben tijdens het programmeren. Ik weet niet op wat voor shit code de AI getraind is verder, maar goed.

[ Voor 25% gewijzigd door Lethalis op 30-08-2026 14:04 ]

[eheijnen]

Vraag je AI buddy eens:
overall how much slop does ai code generation create in pro models

[Lethalis]

eheijnen schreef op zondag 30 augustus 2026 @ 15:03:
Vraag je AI buddy eens:
overall how much slop does ai code generation create in pro models

"Pro models excel at generating exactly what you ask for in the active file, but they struggle to maintain global awareness of an entire multi-directory codebase."

Dit zie ik inderdaad terug in de code base. Ik heb al wat dingen die ik weer handmatig samen wil voegen in 1 component of class, zodat het hergebruikt kan worden en de functionaliteit op 1 plek staat.

"Critical logic flaws"

Yep. Ik moest met de hand ervoor zorgen dat de data altijd bijgewerkt is. De gegenereerde code bewaarde wel de nieuwste gegevens, maar ververste zijn eigen cache niet.

"Slop code often reveals itself not on day one, but on day fourteen, when a developer tries to modify the system and realizes the AI's implementation is too rigid or brittle to expand"

Dat is waar ik nu ben inderdaad Ik ben gelukkig een stuk verder gekomen door de applicatie handmatig te verbeteren het afgelopen uur en ik zal nog wel meer refactorings doen om de code in een betere staat te krijgen.

Dit was verdorie een simpele applicatie. Bij sommige complexe projecten van mijn werk zou AI de complete doodsteek van het project zijn op deze manier.

[Guus...]

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

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.

Men overschat de driver seat enorm. Als je mij vraagt om een probleem op te lossen met mijn eigen kennis, een codebase en een leeg nieuw bestand komt er een hele andere oplossing uit dan als dat bestand al gevuld is met een mogelijke maar slechte oplossing.

Ik heb het genoegen om veel AI PRs te mogen reviewen en daar komen overal vreemde patronen in voor die je pas herkent nadat je zelf de juiste oplossing helemaal hebt uitgedacht. Volgordes die zorgen voor een doolhof aan error handling, inheritance die niets toevoegen, het niet gebruiken van library functies maar zelf 3 nested for loops genereren.

[DaFeliX]

Guus... schreef op dinsdag 1 september 2026 @ 00:32:
[...]

[...] die je pas herkent nadat je zelf de juiste oplossing helemaal hebt uitgedacht. [...]

Dit herken ik ook heel erg. "Joah, dat lijkt wel goed", maar als ik het dan vergelijk met mijn eigen code is dat echt anders. En dan ga je de verschillen bekijken en zie je ineens dat de subtiele (soms ook minder subtiel) verschillen wel degelijk grote impact hebben. Het vervelende: Ik weet niet of dit ligt aan hoe ik werk (de details zitten blijkbaar in mijn hoofd, maar staan niet in de requirements) of inherent in hoe software ontwikkeld wordt. Ik hoop natuurlijk het laatste

Ter illustratie: Ik had een projectje waar ik mbv Claude een static analyzer stricter heb strenger heb afgesteld. Ondertussen heb ik zelf het werk ook gedaan zodat ik het werk met elkaar kon vergelijken.

Ik merkte op dat (naast de code van Claude vals speelde door toch stiekem een ignore te doen) mijn code objectief beter was: Een niet-gebruikte endpoint was verwijderd, mijn code haalde een library weg, mijn had legacy stijl omgezet naar nieuwe stijl code (gebruik makende van functionaliteiten van PHP die toen nog niet bestonden) en mijn pr zorgde er voor dat er minder regels code waren.

Als ik dan vergelijk dat ik zelf 1 dag bezig was met die changes (full-focus), vs een halve dag met Claude (half-focus) en het resultaat bekijk, denk ik echt dat mijn pr beter was. Daarnaast had ik sowieso het werk extra moeten controleren, dus daar zit zo weer een halve dag werk in. En bovendien, ik kon Claude pas goed instrueren nadat ik zelf goed wist wat het werk was, en daarop mijn prompt ook aanpaste.

[Mugwump]

Er zijn momenten dat ik best blij ben met AI, maar nog minstens net zoveel momenten waar het frustratie oplevert. En ik zie toch al wel veel mensen vrij kritiekloos door AI gegenereerde oplossingen accepteren zonder nou echt te snappen wat ze aan het doen zijn. Zo had ik recentelijk ook nog weer een gevalletje waarbij tijdens mijn vakantie wat was gevibecode waarbij ook even wat refactoring aan databaseindices was meegenomen (lees: de uniciteit werd niet meer afgedwongen). Leuk reparatieklusje weer.

[DevWouter]

Ik moest een tijd terug een A4 poster maken, iets waar ik niet al te goed in ben. Dus toen heb ik AI ingezet onder het motto: Zelfs het gemiddelde van de mensheid zal een beter resultaat maken dan wat ik zou maken. Dus Figma opgestart en AI de gelegenheid gegeven.

En inderdaad, super strak ontwerp, mooie vormgeving, duidelijk met eye-catching elementen. Weliswaar wat schoonheidsfoutjes zoals omschrijving en het wanneer/wat verhaal, maar ik was daar ook niet duidelijk in de prompt mee. Kleur en contrast waren super effectief.

10 minuten later keek ik weer, en heb ik alles verwijderd en gewoon zelf een zwart-wit versie gemaakt. Zonder plaatjes, met een simpele opmaak. Eigenlijk super saai, maar het grote verschil was dat het echt en oprecht aanvoelde.

De visueel "betere" poster had zeker meer aandacht gekregen, maar ik denk ook dat minder mensen het serieus hadden genomen.

Nog opmerkelijker, tijdens het ontwerpen van mijn eigen poster realiseerde ik me dat de andere poster niet het A4 formaat had waar ik om vroeg, terwijl dat 100% een eis was in de prompt.

[WasBak]

DaFeliX schreef op dinsdag 1 september 2026 @ 07:35:
[...]

En bovendien, ik kon Claude pas goed instrueren nadat ik zelf goed wist wat het werk was, en daarop mijn prompt ook aanpaste.

Maar dit is toch heel logisch, AI kan toch pas aan de slag als jij begrijpt wat het werk is? Dat doe je zonder AI toch ook, eerst begrijpen wat de vraag is, en dan aan het werk?

Als je geen opdracht geeft om op te schonen, dan zal AI dat ook niet doen. Jij doet dat mogelijk wel, omdat je vindt dat het moet gebeuren, maar ook dat hoort dan bij de instructie.

Daarnaast neem je de review van je eigen code door een collega niet mee, maar ook dat hoort nog te gebeuren. Dan zit je alsnog op een extra halve dag.

[DevWouter]

WasBak schreef op dinsdag 1 september 2026 @ 10:25:
[...]

Maar dit is toch heel logisch, AI kan toch pas aan de slag als jij begrijpt wat het werk is? Dat doe je zonder AI toch ook, eerst begrijpen wat de vraag is, en dan aan het werk?

Als je geen opdracht geeft om op te schonen, dan zal AI dat ook niet doen. Jij doet dat mogelijk wel, omdat je vindt dat het moet gebeuren, maar ook dat hoort dan bij de instructie.

Daarnaast neem je de review van je eigen code door een collega niet mee, maar ook dat hoort nog te gebeuren. Dan zit je alsnog op een extra halve dag.

Waarschijnlijk wordt dat bedoeld als: Als ik zelf programmeer dan doe ik meer dan alleen op toetsen drukken. Waar "mijn prompt" minimaal kan zijn en toch een goed resultaat oplevert, zal AI met datzelfde prompt niet een goed resultaat opleveren. AI kan pas een bevredigend resultaat opleveren nadat ik het werk een keer gedaan heb en het exact kan vertellen waar/wat/hoe. AI kan dus alleen mijn werk doen als ik het werk al gedaan heb.

Waarschijnlijk zoiets.

[DaFeliX]

^^^ wat @DevWouter inderdaad zegt. Ik weet heel goed wat ik wil (betere code), maar als ik een prompt gebruik als "Zorg dat er geen violations zijn", dan kan het eindresultaat zijn dat de merge request geen codechanges heeft, maar wel een violations-ignore file

En dat is ook het punt wat ik probeer te maken; maar blijkbaar komt dat niet goed over in mijn post.

De code review van een collega had ik inderdaad moeten noemen. Maar of dit dan ook een halve dag zou zijn? Ik bedoel, als mijn collega devver iets aanbiedt, heb ik andere aannames dan wanneer ik de code van Claude moet reviewen. Net zoals ik een junior devver anders review dan een senior.

[RobertMe]

DevWouter schreef op dinsdag 1 september 2026 @ 11:52:
Waar "mijn prompt" minimaal kan zijn en toch een goed resultaat oplevert, zal AI met datzelfde prompt niet een goed resultaat opleveren.

Is "mijn prompt" niet ook kort op basis van eerdere afspraken, resultaten van eerdere "prompts", etc etc?

Zaken als "doe ook code opruimen / refactoren waar nodig" kunnen immers ook afspraken over gemaakt zijn. Ik haat een one-line fix in een file van 100 regels waarbij een reformat gedaan is en daardoor 50 regels "gewijzigd" zijn, anderen drukken continu op de shortcut om te reformatten. Dus daaruit kan ook een afspraak volgen om bv de reformat niet te doem of eerst een losse commit met de reformat en dan een commit mdt de one-line fix. Als je vervolgens een simpele fix moet doen zal ook niet gevraagd worden om wel/niet te reformatten, maar is die afspraak er en pas je die alsnog toe ondanks dat het niet specifiek is vermeldt.

Vervolgens zal AI zich niet aan zo'n afspraak houden, tenzij je expliciet prompt. Maar zoiets kun je toch vast vastleggen? In een CLAUDE.md file of weet ik hoe het allemaal heet (ook voor andere LLMs). Waardoor je het dus ook niet meer expliciet in de prompt hoeft te benoemen, neem ik aan. En hetzelfde dus dat, neem ik aan, als je 1x in een gesprek iets aangeeft om niet te doen, dat die bij latere opdrachten in hetzelfde gesprek nog steeds dat niet doet (als in: het staat niet in de expliciete prompt maar is in de context eerder aangegeven).

[WasBak]

DaFeliX schreef op dinsdag 1 september 2026 @ 12:00:
^^^ wat @DevWouter inderdaad zegt. Ik weet heel goed wat ik wil (betere code), maar als ik een prompt gebruik als "Zorg dat er geen violations zijn", dan kan het eindresultaat zijn dat de merge request geen codechanges heeft, maar wel een violations-ignore file

Maar dat doe je toch door een volledige prompt mee te geven, guardrails te definiëren en ervoor te zorgen dat de juiste skills worden ingeladen?

Als je tegen een collega zegt dat je een API nodig hebt om bijvoorbeeld adresgegevens op te halen op basis van een postcode, kan dat ook tot allerlei verschillende oplossingen leiden als je niet de juiste informatie en kaders meegeeft. Ongeacht of die collega junior, medior of senior is.

En dat is ook het punt wat ik probeer te maken; maar blijkbaar komt dat niet goed over in mijn post.

De code review van een collega had ik inderdaad moeten noemen. Maar of dit dan ook een halve dag zou zijn? Ik bedoel, als mijn collega devver iets aanbiedt, heb ik andere aannames dan wanneer ik de code van Claude moet reviewen. Net zoals ik een junior devver anders review dan een senior.

Dat komt volgens mij vooral omdat je die collega vertrouwt. Je vertrouwt AI (nog?) niet op dezelfde manier, omdat de output niet altijd naar wens is. Maar daarvoor moet de input en context ook goed zijn.

Ik zag gisteren toevallig een oude assembly developer hierover praten. Toen ze destijds overgingen naar C (of een vergelijkbare hogere programmeertaal), controleerde hij in het begin alle gecompileerde code, omdat hij de compiler niet vertrouwde. Naarmate de kwaliteit beter werd en het vertrouwen groeide, liet hij dat steeds meer los.

Ik geloof oprecht dat we nu in een vergelijkbare periode zitten. Het is nog niet perfect, maar moet het perfect zijn?

[DaFeliX]

WasBak schreef op dinsdag 1 september 2026 @ 12:48:
[...]

Maar dat doe je toch door een volledige prompt mee te geven, guardrails te definiëren en ervoor te zorgen dat de juiste skills worden ingeladen?

[...]

Ik beweer ook niet anders. Wat ik zeg: Als ik met vage requirements iets doe, dan komen er additionele requirements naar boven. Die komen naar boven omdat ik als mens ergens achter kom wat invloed heeft op het eindresultaat. En ja, dan verschilt het persoon per persoon wat je ermee doet; negeren, documenteren, andere richting uit gaan, whatever.

Wat ik zeg, als ik zoiets door Claude laat genereren, komt daar iets anders uit dan als ik het zelf oppak. In dit geval was ik wel tevreden met mijn eigen resultaat, en mis ik dingen in het resultaat dat Claude genereerde. Claude zou pas iets soortgelijks hebben gedaan, als ik wist wat ik wist doordat ik het werk zelf gedaan had. Dus in dit geval had Claude gebruiken mij niet geholpen.

En of dat nu aangeeft dat ik een inadequate developer ben en de requirements niet vooraf kan inschatten, of dat er een rol voor "pragmatisch nadenken" blijft bestaan laat ik graag ter discussie

[Kalentum]

DaFeliX schreef op dinsdag 1 september 2026 @ 12:00:
^^^ wat @DevWouter inderdaad zegt. Ik weet heel goed wat ik wil (betere code), maar als ik een prompt gebruik als "Zorg dat er geen violations zijn", dan kan het eindresultaat zijn dat de merge request geen codechanges heeft, maar wel een violations-ignore file

En dat is ook het punt wat ik probeer te maken; maar blijkbaar komt dat niet goed over in mijn post.

De code review van een collega had ik inderdaad moeten noemen. Maar of dit dan ook een halve dag zou zijn? Ik bedoel, als mijn collega devver iets aanbiedt, heb ik andere aannames dan wanneer ik de code van Claude moet reviewen. Net zoals ik een junior devver anders review dan een senior.

Hoe werk je dan met Claude? Ik geef de context (meestal een link naar een issue, ik zorg dat die issue goed geschreven is). Als de implementatie niet duidelijk is ga ik eerst in plan mode wat heen-en-weren zodat er implementatieplan is in Claude Code. En dan gaat 'ie aan het werk. Code maken, tests schrijven, tests runnen. En ik weet niet precies wat dan 'violations' zijn maar fouten die door de code linter worden opgepakt worden door het model netjes opgelost.

Voordat er gepusht wordt doe ik dan nog een code review, komt meestal ook nog wel wat uit (self review doe ik sowieso).

Wij hebben wel een aantal skills in de repo staan zoals coding guidelines enzo, misschien dat dat helpt, geen idee.

Voor wat betreft code reviews: maakt voor mij niet uit van wie het komt, ik beoordeel alles gelijk.

[ Voor 3% gewijzigd door Kalentum op 01-09-2026 13:22 ]

[DaFeliX]

Kalentum schreef op dinsdag 1 september 2026 @ 13:12:
[...]


Hoe werk je dan met Claude? Ik geef de context (meestal een link naar een issue, ik zorg dat die issue goed geschreven is). Als de implementatie niet duidelijk is ga ik eerst in plan mode wat heen-en-weren zodat er implementatieplan is in Claude Code. En dan gaat 'ie aan het werk. Code maken, tests schrijven, tests runnen. En ik weet niet precies wat dan 'violations' zijn maar fouten die door de code linter worden opgepakt worden door het model netjes opgelost.

Ik gebruik Claude weinig voor het uitvoereren van 'werk'; dit betrof een experiment om te zien waar ik tegenaan zou lopen als ik dat wel doe. Met 'violations' bedoel ik: Ik had nu een kleinere codebase waarin ik een strengere set van static analysis wilde hebben. Daar slaan die 'violations' op; een manier om Claude snel feedback te kunnen geven of het resultaat goed was of niet.

Ik gebruik Claude nu vooral voor dingen als debugging, een eerste code review of het maken van variaties op bestaande code. Soms genereer ik testvariaties met Claude, heel soms laat ik Claude code genereren dat prima is als ik niet zou begrijpen hoe het werk (zoals een obscure API gebruiken voor niet-kritieke code)

Voordat er gepusht wordt doe ik dan nog een code review, komt meestal ook nog wel wat uit (self review doe ik sowieso).

Wij hebben wel een zooi skills in de repo staan zoals coding guidelines enzo, misschien dat dat helpt, geen idee.

Skills delen wij ook onderling, en sommige collega's gebruiken het meer dan ik. Guidelines vind ik zelf niet echt prettig, omdat deze niet zelden worden genegeerd. Daarom ben ik fan van tools zoals deptrac en PHPStan, die ook in de pipeline draaien en dus niet genegeerd kunnen worden

Voor wat betreft code reviews: maakt voor mij niet uit van wie het komt, ik beoordeel alles gelijk.

Ik weet niet wat ik hier zelf van vind. Een pr van de ene collega bekijk ik immers ook anders dan van een andere collega, omdat ik bijvoorbeeld weet dat collega X meer verstand heeft van Y dan ik. Zo zie ik pr's van Claude als dingen die een junior gemaakt zou kunnen hebben: Met de grootst mogelijke argwaan. En bij een junior heeft dat als resultaat dat ie er beter van kan worden.

[WasBak]

DaFeliX schreef op dinsdag 1 september 2026 @ 13:09:
[...]

Ik beweer ook niet anders. Wat ik zeg: Als ik met vage requirements iets doe, dan komen er additionele requirements naar boven. Die komen naar boven omdat ik als mens ergens achter kom wat invloed heeft op het eindresultaat. En ja, dan verschilt het persoon per persoon wat je ermee doet; negeren, documenteren, andere richting uit gaan, whatever.

Wat ik zeg, als ik zoiets door Claude laat genereren, komt daar iets anders uit dan als ik het zelf oppak. In dit geval was ik wel tevreden met mijn eigen resultaat, en mis ik dingen in het resultaat dat Claude genereerde. Claude zou pas iets soortgelijks hebben gedaan, als ik wist wat ik wist doordat ik het werk zelf gedaan had. Dus in dit geval had Claude gebruiken mij niet geholpen.

Ik begrijp overigens dat je dit vooral als experiment voor jezelf hebt gedaan, en daar is natuurlijk helemaal niets mis mee. Ik reageer vooral op de conclusie die je uit dat experiment trekt.

Maar dat ligt dan volgens mij deels aan het moment waarop je de prompt schrijft. Als je de prompt schrijft voordat je begint, terwijl je zelf ook nog niet alles weet, is het logisch dat bepaalde informatie ontbreekt.

Je kunt ook eerst onderzoek doen, bepalen wat er precies moet gebeuren en op basis daarvan de prompt schrijven. Dan krijg je mogelijk wél het gewenste resultaat, zonder dat je het werk eerst zelf volledig hoeft uit te voeren.

En of dat nu aangeeft dat ik een inadequate developer ben en de requirements niet vooraf kan inschatten, of dat er een rol voor "pragmatisch nadenken" blijft bestaan laat ik graag ter discussie

Requirements kun je volgens mij simpelweg niet altijd vooraf volledig inschatten. Daarom doen we onderzoek en sturen we tijdens softwareontwikkeling bij zodra we nieuwe dingen ontdekken. Dat is met AI niet anders.

[eheijnen]

Een stukje over hoe Netflix AI toepast om hun workflow te automatiseren en daarmee stevige besparingen in tijd en geld realiseert.
https://meshedsociety.com...lt-a-tailor-made-code-ai/

[ Voor 43% gewijzigd door eheijnen op 02-09-2026 13:13 ]

[DevWouter]

RobertMe schreef op dinsdag 1 september 2026 @ 12:08:
[...]

Is "mijn prompt" niet ook kort op basis van eerdere afspraken, resultaten van eerdere "prompts", etc etc?

Zaken als "doe ook code opruimen / refactoren waar nodig" kunnen immers ook afspraken over gemaakt zijn. Ik haat een one-line fix in een file van 100 regels waarbij een reformat gedaan is en daardoor 50 regels "gewijzigd" zijn, anderen drukken continu op de shortcut om te reformatten. Dus daaruit kan ook een afspraak volgen om bv de reformat niet te doem of eerst een losse commit met de reformat en dan een commit mdt de one-line fix. Als je vervolgens een simpele fix moet doen zal ook niet gevraagd worden om wel/niet te reformatten, maar is die afspraak er en pas je die alsnog toe ondanks dat het niet specifiek is vermeldt.

Vervolgens zal AI zich niet aan zo'n afspraak houden, tenzij je expliciet prompt. Maar zoiets kun je toch vast vastleggen? In een CLAUDE.md file of weet ik hoe het allemaal heet (ook voor andere LLMs). Waardoor je het dus ook niet meer expliciet in de prompt hoeft te benoemen, neem ik aan. En hetzelfde dus dat, neem ik aan, als je 1x in een gesprek iets aangeeft om niet te doen, dat die bij latere opdrachten in hetzelfde gesprek nog steeds dat niet doet (als in: het staat niet in de expliciete prompt maar is in de context eerder aangegeven).

Nee, omdat het gaat om inzicht die verworven worden tijdens het proces waardoor de oplossingsrichting veranderd. Zoals wanneer je bezig bent bent met totaal van factuur te berekenen door de prijs van de producten van de factuurregels op te tellen waarbij je vervolgens besluit om het totaal per factuur in zijn geheel op te slaan elke keer als het veranderd omdat het extern systeem dat prijzen per product bij houdt al te zwaar belast wordt.

Als AI dit doet dan zal de mens niet het inzicht krijgen en dan krijg je die PRs waarbij een ontwikkelaar een database migratie doet waarbij die indexes aanpast waar die totaal geen verstand van heeft. Sure, je kan weer een afspraak toevoegen, maar wat als de volgende keer de situatie omgekeerd is?

[eheijnen]

Als toevoeging op de eerdere post (2 omhoog) een presentatie van de Netflix mensen over hoe Netflix AI toepast om hun workflow te automatiseren en daarmee stevige besparingen in tijd en geld realiseert.
YouTube: Netflix’s Journey to Confident Automated Changes

[ Voor 35% gewijzigd door eheijnen op 02-09-2026 13:14 ]

[WasBak]

DevWouter schreef op dinsdag 1 september 2026 @ 14:37:
[...]

Nee, omdat het gaat om inzicht die verworven worden tijdens het proces waardoor de oplossingsrichting veranderd. Zoals wanneer je bezig bent bent met totaal van factuur te berekenen door de prijs van de producten van de factuurregels op te tellen waarbij je vervolgens besluit om het totaal per factuur in zijn geheel op te slaan elke keer als het veranderd omdat het extern systeem dat prijzen per product bij houdt al te zwaar belast wordt.

Als AI dit doet dan zal de mens niet het inzicht krijgen en dan krijg je die PRs waarbij een ontwikkelaar een database migratie doet waarbij die indexes aanpast waar die totaal geen verstand van heeft. Sure, je kan weer een afspraak toevoegen, maar wat als de volgende keer de situatie omgekeerd is?

Maar dit soort problemen zijn nooit anders geweest toch? Er zijn zo vaak inzichten achteraf pas gevonden nadat een PR al op een omgeving staat, of dat nou test, acceptatie of productie is.

Het verschil kan zeker zijn dat je als ontwikkelaar het direct ziet, en het direct aan kan passen. Maar ook daarvan zijn genoeg situaties geweest, waarvan je dacht, shit, dat hadden we niet met de database moeten doen.

[eheijnen]

Was'm bijna vergeten. Nog een AI ontwikkeling die nog wel eens flink wat stof zal laten opwaaien.

Een onderzoeksduo dat ooit werd benaderd om leiding te geven aan het door Jeff Bezos gesteunde Project Prometheus, onthulde dinsdag wat ze zelfstandig hebben gebouwd: een AI-model dat zulke enorme hoeveelheden informatie kan verwerken en genereren dat één enkele computer dit mogelijk niet aankan.

https://www.reuters.com/b...odel-universe-2026-08-25/
https://acceleratedunderstanding.com/longform

[ Voor 37% gewijzigd door eheijnen op 02-09-2026 13:17 ]

[DevWouter]

WasBak schreef op dinsdag 1 september 2026 @ 15:24:
[...]


Maar dit soort problemen zijn nooit anders geweest toch? Er zijn zo vaak inzichten achteraf pas gevonden nadat een PR al op een omgeving staat, of dat nou test, acceptatie of productie is.

Het verschil kan zeker zijn dat je als ontwikkelaar het direct ziet, en het direct aan kan passen. Maar ook daarvan zijn genoeg situaties geweest, waarvan je dacht, shit, dat hadden we niet met de database moeten doen.

Allereerst het is "tijdens", niet "achteraf". Ten tweede het gaat om de verworven kennis, en ten derde de mogelijkheid om actief een keuze te maken (ipv ontdekken of achteraf kiezen).

En tuurlijk er zijn genoeg situaties waarbij je als ontwikkelaar pas achteraf een inzicht krijgt, maar met AI heb je dat probleem ook.

[WasBak]

DevWouter schreef op dinsdag 1 september 2026 @ 18:00:
[...]

Allereerst het is "tijdens", niet "achteraf". Ten tweede het gaat om de verworven kennis, en ten derde de mogelijkheid om actief een keuze te maken (ipv ontdekken of achteraf kiezen).

En tuurlijk er zijn genoeg situaties waarbij je als ontwikkelaar pas achteraf een inzicht krijgt, maar met AI heb je dat probleem ook.

Achteraf, nadat de requirements duidelijk waren. Je gaat niet blind aan het werk zonder dat je weet wat je kaders zijn toch?

[DevWouter]

WasBak schreef op dinsdag 1 september 2026 @ 18:21:
[...]

Achteraf, nadat de requirements duidelijk waren. Je gaat niet blind aan het werk zonder dat je weet wat je kaders zijn toch?

En nee, ik heb genoeg situaties meegemaakt waarbij het vooraf compleet onduidelijk was wat het werk inhield. Soms moet je gewoon Wikipedia: Exploratory programming doen

[WasBak]

DevWouter schreef op dinsdag 1 september 2026 @ 20:08:
[...]

[Afbeelding]

En nee, ik heb genoeg situaties meegemaakt waarbij het vooraf compleet onduidelijk was wat het werk inhield. Soms moet je gewoon Wikipedia: Exploratory programming doen

Leuk plaatje, maar ik geloof werkelijk dat spec-driven development de weg gaat zijn.

Wil je zelf blijven coden? Dat kan uiteraard. Maar ik denk dat het daadwerkelijk schrijven van code in de toekomst steeds minder de kern van ons vak gaat zijn en uiteindelijk misschien vooral iets wordt wat mensen doen omdat ze het leuk vinden. Zoals er ook heel veel hobbytimmermannen zijn.

Dat betekent overigens niet dat het denkwerk verdwijnt. Juist bepalen wat er gebouwd moet worden, onderzoeken wat nog onduidelijk is, keuzes maken en specificeren wat een goed resultaat is, wordt veel belangrijker.

Het blijft gissen uiteraard.

[hackerhater]

DevWouter schreef op dinsdag 1 september 2026 @ 20:08:
En nee, ik heb genoeg situaties meegemaakt waarbij het vooraf compleet onduidelijk was wat het werk inhield. Soms moet je gewoon Wikipedia: Exploratory programming doen

Ik wil nog verder gaan: In het werkveld heb ik nog nooit meegemaakt dat alle specs 100% duidelijk waren aan het begin.

WasBak schreef op dinsdag 1 september 2026 @ 20:46:
Dat betekent overigens niet dat het denkwerk verdwijnt. Juist bepalen wat er gebouwd moet worden, onderzoeken wat nog onduidelijk is, keuzes maken en specificeren wat een goed resultaat is, wordt veel belangrijker.

Het daadwerkelijk schrijven van code is altijd maar een klein onderdeel van ons werk geweest. Het framework, zelfs de taal is maar een implementatie-detail,

Achterhalen wat er gemaakt moet worden met de constraints is waar de uitdaging zit.
En dat kunnen die fancy tekst-generators met hun valse naam niet.

[ Voor 40% gewijzigd door hackerhater op 01-09-2026 21:22 ]

[ZpAz]

Het circkeltje is rond:

- Experts Exchange
- Stack Overflow
- Experts Exchange. Voornamelijk enkel voor hun nieuwsletters. (online versie van onderstaand)

We were going to write a warm retrospective. Then I opened a Google Doc titled DO NOT SEND filled with all the jokes our “legal” team forcibly cut from our weekly issues, which over two years has become the funniest thing this team has produced and the strongest argument against giving us a platform.

Here's our director's cut. Every one of these made a person in a quarter-zip Patagonia vest say "we can't run that" while their left eye did that twitchy thing.

1. On a new SaaS platform: Investors are throwing money at them like divorced dads at a strip club during custody weekend.
2. On the billionaire space race: Three of the richest men alive independently arrived at the same solution, which was to build the largest possible object and point it upward. This is the sports car of geopolitics (aka a dck measuring contest) and every single one of these hairline-receding billionaires are turning sixty.*
3. On Gwyneth Paltrow hosting a dinner honoring Sam Altman: A woman who sold a candle that smells like her genitals threw a party for a man selling the end of white-collar work. Only one of them lists the ingredients.
4. On data centers cooled by treated wastewater: The most advanced technology in human history is being kept alive by 200 million gallons of Virginia piss a day, and Sam Altman has never once said thank you. We know the sicko likes it.
5. On Elon becoming a trillionaire: He has a trillion dollars and eleven children, meaning he could fund therapy for every single one of them and instead bought a code editor for $60 billion.

Op hun vraag en antwoord pagina's.

[ Voor 17% gewijzigd door ZpAz op 01-09-2026 21:30 ]

[MueR]

eheijnen schreef op dinsdag 1 september 2026 @ 16:39:
Was'm bijna vergeten. Nog een AI ontwikkeling die nog wel eens flink wat stof zal laten opwaaien.
https://www.reuters.com/b...odel-universe-2026-08-25/
https://acceleratedunderstanding.com/longform

Heb je ook nog een doel met al die contextloze linkdrops over AI waar duidelijk niemand hier op in gaat? Probeer dit even in AI algemeen ofzo.

[eheijnen]

MueR schreef op dinsdag 1 september 2026 @ 21:57:
[...]

Heb je ook nog een doel met al die contextloze linkdrops over AI waar duidelijk niemand hier op in gaat? Probeer dit even in AI algemeen ofzo.

Naa jaa, dat vind ik wel wat kort door de bocht.
Het gaat hier de laatste tijd royaal over AI en deze zaken hebben hiermee meer raakvlakken dan AI algemeen. Zeker dat Netflix verhaal laat zien waartoe ze daar instaat zijn om programmeertaken te automatiseren. Daarnaast kan ik het hele verhaal wat daar verteld wordt hier nog eens overtypen maar dan heeft zo'n artikel ook geen zin meer (spoiler). Of mensen daarop reageren, jaaa, dat moet je altijd afwachten....

En misschien brengt het hier bij SO wat leven in de brouwerij. Tis altijd zo stil hier, vergeleken met andere kanalen alhier.

[DevWouter]

WasBak schreef op dinsdag 1 september 2026 @ 20:46:
[...]


Leuk plaatje, maar ik geloof werkelijk dat spec-driven development de weg gaat zijn.

Wil je zelf blijven coden? Dat kan uiteraard. Maar ik denk dat het daadwerkelijk schrijven van code in de toekomst steeds minder de kern van ons vak gaat zijn en uiteindelijk misschien vooral iets wordt wat mensen doen omdat ze het leuk vinden. Zoals er ook heel veel hobbytimmermannen zijn.

Dat betekent overigens niet dat het denkwerk verdwijnt. Juist bepalen wat er gebouwd moet worden, onderzoeken wat nog onduidelijk is, keuzes maken en specificeren wat een goed resultaat is, wordt veel belangrijker.

Het blijft gissen uiteraard.

Alle software ooit geschreven heeft een specificatie gehad. Het was echter vaak informeel en/of impliciet. Dat men het nu weer beweegt naar het formaliseren en/of expliciet te maken lijkt vooral gemotiveerd te zijn omdat anders de tools niet werken. De vraag is eerder hoe lang mensen gemotiveerd blijven.

En denken is een proces dat tijd kost, de enige manier om daar sneller in te worden is ervaring. Dit is ook een reden waarom veel ontwikkelaars een rondje lopen als ze vast zitten.

Overigens denk ik soms dat het merendeel van software ontwikkeling op stom fabriekswerk lijkt waarbij de baas weeïgers te automatiseren. Maar dat mag je op schrijven aan het feit dat ik nog een romantisch beeld heb van wat software ontwikkeling is.

[F.West98]

WasBak schreef op dinsdag 1 september 2026 @ 13:57:
[...]


Ik begrijp overigens dat je dit vooral als experiment voor jezelf hebt gedaan, en daar is natuurlijk helemaal niets mis mee. Ik reageer vooral op de conclusie die je uit dat experiment trekt.

Maar dat ligt dan volgens mij deels aan het moment waarop je de prompt schrijft. Als je de prompt schrijft voordat je begint, terwijl je zelf ook nog niet alles weet, is het logisch dat bepaalde informatie ontbreekt.

Je kunt ook eerst onderzoek doen, bepalen wat er precies moet gebeuren en op basis daarvan de prompt schrijven. Dan krijg je mogelijk wél het gewenste resultaat, zonder dat je het werk eerst zelf volledig hoeft uit te voeren.

In mijn ervaring kost het stukje onderzoek doen en precies bepalen wat er nodig is veel meer tijd dan het daadwerkelijke code schrijven - zeker als het gaat om grotere bestaande codebases waarin er relatief kleine wijzigingen moeten gebeuren. Dus sure, als je het hele plan vooraf uitwerkt en in tekst zet en aan de AI voert, misschien kan het de code sneller schrijven dan jij als mens. Maar je bent waarschijnlijk wel meer tijd kwijt aan het "op papier zetten" van het plan dan je zonder AI zou hebben gedaan, waarbij het vaak voldoende is om het plan in je hoofd te hebben

Er zijn wel super corporate omgevingen waarbij alles tot in de puntjes gespecificeerd moet worden voordat er ook maar een regel code geschreven kan worden; maar dat is niet overal.

---

DevWouter schreef op dinsdag 1 september 2026 @ 20:08:
[...]

[Afbeelding]

En nee, ik heb genoeg situaties meegemaakt waarbij het vooraf compleet onduidelijk was wat het werk inhield. Soms moet je gewoon Wikipedia: Exploratory programming doen

Dat is eigenlijk precies de overgrote meerderheid van de code die ik de laatste anderhalf jaar heb geschreven. Je hebt een vaag doel met een soort visie in je achterhoofd, semi-greenfield project, en je wil met de technologie spelen om te kijken wat de opties zijn en wat er praktisch kan. En gaandeweg beginnen de eisen zich dan wat beter af te tekenen, tot uiteindelijk de specificatie en de implementatie tegelijk convergeren naar één eindproduct.

En soms gaat dit op een heel hoog niveau ("we willen een flexibel configuratiesysteem met inheritance die ook intuïtief is, maar waarvan de implementatie goed te onderhouden is"), waarbij de technische mogelijkheden de eisen beïnvloeden (de meest flexibele vorm zou een nachtmerrie zijn om te onderhouden), maar waarbij de eisen ook zeker de implementatie beïnvloeden (we moeten elke inheritance "beslissing" kunnen traceren). Dan zorgt het samenspel tussen implementatie en wensen uiteindelijk voor een eindproduct.

Maar vaak genoeg heb ik dit ook op een veel kleiner niveau ("hoe kan ik het beste de current identity aan deze service meegeven"), waarbij de high-level eisen heel duidelijk en concreet zijn (regels over authn/authz), maar waarbij de implementatie sterk afhankelijk is van de features in het framework, de conventies in het ecosysteem en je eigen code, en je eigen wensen als team. Ook hierbij ga ik dan op onderzoek uit, experimenteren met verschillende approaches die ik tegenkom op internet, en dan kies ik gaandeweg de meest elegante oplossing (waarbij de implementatie uiteindelijk niet veel extra werk is).

Zou ik die exploratory iteration samen met een AI kunnen doen? Misschien wel, maar de kans is groot dat ik al snel denk "oh dit lijkt wel prima" en gewoon veel minder kritisch nadenk. Sterker nog - dat weet ik zeker. Elke keer als ik AI voor iets gebruik merk ik dat ik minder kritisch ben, sneller dingen over het hoofd zie, en dingen al snel "wel best" vind. Hetzelfde effect heb ik ook met code van collega's die ik heb gereviewd: in de review lijkt het prima, als ik er daarna in de praktijk mee aan de slag ga ontdek ik pas écht welke onderliggende problemen er zijn.

[.oisyn]

eheijnen schreef op dinsdag 1 september 2026 @ 23:50:
[...]


Naa jaa, dat vind ik wel wat kort door de bocht.
Het gaat hier de laatste tijd royaal over AI en deze zaken hebben hiermee meer raakvlakken dan AI algemeen. Zeker dat Netflix verhaal laat zien waartoe ze daar instaat zijn om programmeertaken te automatiseren. Daarnaast kan ik het hele verhaal wat daar verteld wordt hier nog eens overtypen maar dan heeft zo'n artikel ook geen zin meer (spoiler). Of mensen daarop reageren, jaaa, dat moet je altijd afwachten....

En misschien brengt het hier bij SO wat leven in de brouwerij. Tis altijd zo stil hier, vergeleken met andere kanalen alhier.

Ja maar typ erbij waarover het precies gaat, een korte samenvatting oid. Nu plemp je maar gewoon een link neer wat "iets met AI" is en mensen moeten maar raden of het interessant voor hen is.

[alwinuzz]

eheijnen schreef op dinsdag 1 september 2026 @ 23:50:
[...]

Zeker dat Netflix verhaal laat zien waartoe ze daar instaat zijn om programmeertaken te automatiseren.

...

Dit zinnetje helpt al!

Links droppen maakt het hier niet minder stil. En ik sla ze ook gewoon over.

Iha kan je in je eigen woorden (dus geen ai slop) het artikel kort inleidt/samenvat in een paar zinnen, en ook wat vind je er zelf van? Dat geeft toegevoegde waarde en dan kan er ook interactie ontstaan.

Liever 1x een interessante link met context van jou, dan 10 loze links!

[DevWouter]

alwinuzz schreef op woensdag 2 september 2026 @ 12:17:
Liever 1x een interessante link met context van jou, dan 10 loze links!

@eheijnen Exact dit, het gaat mij en anderen om wat jouw belangstelling is, zodat wij kunnen aangeven wat onze interesse wekt in jouw belangstelling.

Zo gaan de discussie over AI vooral over hoe we denken dat het impact zal hebben op ons werk. Of pak @Firesphere die blijkbaar niet druk genoeg heeft en sinds kort ook Director van PyCon 2027 is. Dat is een behoorlijke impact voor hem.

Zelfs een discussie waarom tabs of spaties beter zijn is er een die we hier nog steeds voeren omdat het gaat op de impact die wij ervaren.

[ Voor 3% gewijzigd door DevWouter op 02-09-2026 12:41 ]

[eheijnen]

@alwinuzz @DevWouter @.oisyn @MueR et all.
Je kunt context geven maar dan begeef je je ook op het vlak waar je mogelijk invloed uitoefent op de interpretatie per persoon.

Vandaar dat ik zo'n zaken graag in het ruime sop laat drijven en iedereen er zijn eigen beeld over kan vormen wat ook weer kan leidden tot discussiepunten en gespreksstof.

Deze twee onderwerpen/artikelen die ik hier poste geven een redelijk goed idee waar dit heen gaat. Bv. Vroeger stikte het in de tent van de systeembeheerders die hele dag van werkplek naar werkplek renden om probleem op te lossen, updates/upgrades te installeren --> toen kwam SMS server -> .... de rest staat in de geschiedenisboeken. In principe een klassiek voorbeeld hoe deze zaken zich ontwikkelen....

[.oisyn]

eheijnen schreef op woensdag 2 september 2026 @ 12:56:
@alwinuzz @DevWouter @.oisyn @MueR et all.
Je kunt context geven maar dan begeef je je ook op het vlak waar je mogelijk invloed uitoefent op de interpretatie per persoon.

Discussie hierover heeft niet zoveel zin hier. De algemene regel is: link plaatsen = uitleg geven. Ik zou graag zien dat je je eerdere posts even aanpast om dat er bij te plaatsen. Feedback op moderatie mag via DM of via Feedback op moderatie binnen de Devschuur.

Nu graag weer on-topic (voor zover we kunnen spreken van een topic hier )

[ Voor 27% gewijzigd door .oisyn op 02-09-2026 13:04 ]

[eheijnen]

@.oisyn OK

Om nog wat context toe te voegen aan de AI discussie/toestanden.

Er wordt vanuit de industrie gepropageerd (lees roeptoeteren) dat llms junior taken kunnen overnemen. Ik denk niet dat die industrie daar zal stoppen. M.a.w. als ze die systemen ook medior en senior werk kunnen laten uitvoeren zal dat er zeker komen.

De grote uitrol is nog steeds aan de gang. Maar ondertussen werken al veel mensen er mee waardoor er meer kennis / gegevens voor training beschikbaar komen. Dat er op termijn toe kan/zal leidden dat er steeds meer handenwerk in de fabriek verdwijnt....

[DevWouter]

eheijnen schreef op woensdag 2 september 2026 @ 13:08:

Om nog wat context toe te voegen aan de AI discussie/toestanden.

Er wordt vanuit de industrie gepropageerd (lees roeptoeteren) dat llms junior taken kunnen overnemen. Ik denk niet dat die industrie daar zal stoppen. M.a.w. als ze die systemen ook medior en senior werk kunnen laten uitvoeren zal dat er zeker komen.

De grote uitrol is nog steeds aan de gang.

En dit zijn de bijdrages waar ik blij van word.

Er zijn verschillende scenarios mogelijk. En hoewel ik zeer kritisch ben over AI denk ik dat het bovenstaande situatie een optie is. Een die ik als zeer onwaarschijnlijk acht en wat gaat inhouden dat software ontwikkeling een complete andere definitie krijgt, maar een optie niet te min.

Maar ondertussen werken al veel mensen er mee waardoor er meer kennis / gegevens voor training beschikbaar komen. Dat er op termijn toe kan/zal leidden dat er steeds meer handenwerk in de fabriek verdwijnt....

De hoeveelheid trainingsmateriaal is het probleem niet. De kwaliteit van het trainingsmateriaal is wel een probleem. De mensen die AI maken willen dat de output van een hogere kwaliteit is dan de input. Daar kan je op aansturen, maar dan krijg je problemen als overfitting (een bias in je model waardoor die altijd naar hetzelfde antwoord gaat) en dat wil je ook niet. Het is mogelijk om je model een hogere kwaliteit output te laten produceren dan het gehad heeft om te trainen, maar dat is verschrikkelijke duur.

Persoonlijk denk ik dat AI (zoals het nu is) alleen nuttig is voor het produceren van complexe templates die vervolgens veelvuldig gebruikt worden, het produceren van een Wikipedia: Spike (software development) en/of voor zeer specifieke taken (vergelijkbaar met Machine Learning). Eigenlijk alles waar falen een optie mag zijn.

[Firesphere]

DevWouter schreef op woensdag 2 september 2026 @ 12:40:
[...]

Of pak @Firesphere die blijkbaar niet druk genoeg heeft en sinds kort ook Director van PyCon 2027 is. Dat is een behoorlijke impact voor hem.

Lekker kort door de bocht hier , hoezo zou ik het "niet druk genoeg" hebben? Ik vind dit nogal een absurde aanname, en een conclusie die uit de lucht gegrepen lijkt. En wat is "Dat" in die zin? "Dat" is een behoorlijke impact?

---

Enniehoe...

Hoewel dit artikel vrij sterk georienteerd is richting genAI, is het algemene concept dat beschreven wordt erg interessant en vrij breed toe te passen op talen, tools, standaarden, etc. De Gestalt van een toepassing is iets dat in elke werkvorm toepasselijk is, an iets is waar men rekening mee zal moeten houden, bewust of unbewust.

https://deadsimpletech.com/blog/no-such-thing-as-just-a-tool

[DevWouter]

Firesphere schreef op woensdag 2 september 2026 @ 23:16:
[...]

Lekker kort door de bocht hier , hoezo zou ik het "niet druk genoeg" hebben? Ik vind dit nogal een absurde aanname, en een conclusie die uit de lucht gegrepen lijkt. En wat is "Dat" in die zin? "Dat" is een behoorlijke impact?

Dat was sarcasme, je gaf rond die tijd aan dat je behoorlijk wat hooi op de vork had en desondanks ook besloot om dit er bij te doen. En "dat" is de rol van Director zijn, want ik me niet kan voorstellen als iets simpels.

De reden dat ik jou als voorbeeld gebruik is omdat ik het vooral knap vond en het mooi voorbeeld vond van waarom de persoonlijkheden hier interessanter zijn dan de dingen die in onze RSS readers voorbij komen.

[Lethalis]

DevWouter schreef op woensdag 2 september 2026 @ 15:52:
[...]

Er zijn verschillende scenarios mogelijk. En hoewel ik zeer kritisch ben over AI denk ik dat het bovenstaande situatie een optie is. Een die ik als zeer onwaarschijnlijk acht en wat gaat inhouden dat software ontwikkeling een complete andere definitie krijgt, maar een optie niet te min.

Het "probleem" is natuurlijk dat werkgevers geld ruiken. "Oh, als dit en dat nu voortaan sneller kan dan heb ik jou niet meer nodig!".

Daarom vrees ik voor een tijdelijk duister scenario waarin dit eerst overal er doorheen gepusht gaat worden en ze op een nare manier erachter komen dat het toch niet helemaal is wat ze ervan gehoopt hadden.

En dat daarna dan weer wat banen terugkomen, maar ook niet overal.

Vergelijk het met India. Voor een groep ondernemingen was India een complete flop, omdat ze niet in staat waren het goed te managen. Maar er is ook een groep ondernemingen die het wel gelukt is om de boel te outsourcen.

Zo zal het ook met AI gaan.

Oud collega van mij noemt AI agents ook Indiërs Je moet ze precies vertellen wat ze moeten doen, anders wordt het niks.

Persoonlijk durf ik het niet aan met kritische code, zoals jij ook al aangeeft.

Voor prototyping is het dan wel weer geweldig, want dat hoeft niet perfect te zijn.

Kortom, ik denk dat alle scenario's tegelijkertijd mogelijk zijn Een deel van de software ontwikkeling verdwijnt misschien wel, maar er zal ook een deel overblijven. Hoe complexer het werk is dat je doet, hoe beter.

Mij bekruipt ook regelmatig het gevoel dat de mensen die roepen dat ze bijna geen code zelf meer schrijven, misschien in de eerste plaats al niet aan de meest complexe projecten bezig waren. Ja, dan snap ik het. Als jij aan een dertien in een dozijn line of business app werkt die 90% uit CRUD bestaat zonder complexe logica, dan kun je ook aan een AI vertellen om dat te doen.

Zit je aan een systeem te werken waarvan je amper weet hoe je het moet omschrijven omdat er zoveel uitzonderingen en scenario's zijn, dan gaat AI dat ook niet (betrouwbaar) voor je doen.

Ironisch genoeg is precies dat deel van mijn werk wat ik eigenlijk niet leuk vind, hetgene dat ervoor kan zorgen dat ik mijn baan behoud. En dat is de domein kennis en ervaring die je opdoet, waardoor je ook in staat zal zijn om die brug te slaan tussen de klant en een AI agent.

Ik vind het niet leuk, want ik pruts liever aan de code, maar ik leer ook van alles over financiële administraties, voorraadbeheer, prijs- en kortingsstrategieën en logistiek. Tsja. Ik kan al bijna een opleiding HBO Bedrijfsadministratie doen met wat ik moet weten om mijn werk als programmeur te doen

Saai Leuk hoor, die ERP systemen

Maar goed, het is dus een afweging... ik weet niet of ik een consultant wil zijn, want dat zou ik tegen wil en dank worden als ik op deze voet doorga. Aan de andere kant is dat beter dan werkloos zijn wanneer er een overschot aan "programmeurs" komt door ontwikkelingen in de IT sector.

[ Voor 37% gewijzigd door Lethalis op 04-09-2026 13:49 ]

[MueR]

Kreeg vandaag van een collega deze doorgestuurd: https://people.kernel.org/monsieuricon/creepy-crawlies

Best een goede insight in hoe AI crawlers het internet echt aan het verkloten zijn voor ons als humans.

Bonus infuriating content is het stukje Enter your TV?

[RobertMe]

MueR schreef op vrijdag 4 september 2026 @ 22:48:
Kreeg vandaag van een collega deze doorgestuurd: https://people.kernel.org/monsieuricon/creepy-crawlies

Heb je daar een collega voor nodig? Niet je "werkgever"? nieuws: AI-scrapers slokken 20 procent van cpu-capaciteit Kernel.org op

"Werkgever", tussen aanhalingstekens, uiteraard omdat je vrijwillig mod bent.

[MueR]

RobertMe schreef op vrijdag 4 september 2026 @ 23:22:
[...]

Heb je daar een collega voor nodig? Niet je "werkgever"? nieuws: AI-scrapers slokken 20 procent van cpu-capaciteit Kernel.org op

"Werkgever", tussen aanhalingstekens, uiteraard omdat je vrijwillig mod bent.

Ik mis ook wel eens dingen op de FP he

[Crazy D]

Lethalis schreef op vrijdag 4 september 2026 @ 13:19:
[...]

Het "probleem" is natuurlijk dat werkgevers geld ruiken. "Oh, als dit en dat nu voortaan sneller kan dan heb ik jou niet meer nodig!".

Daarom vrees ik voor een tijdelijk duister scenario waarin dit eerst overal er doorheen gepusht gaat worden en ze op een nare manier erachter komen dat het toch niet helemaal is wat ze ervan gehoopt hadden.

En dat daarna dan weer wat banen terugkomen, maar ook niet overal.

Vergelijk het met India. Voor een groep ondernemingen was India een complete flop, omdat ze niet in staat waren het goed te managen. Maar er is ook een groep ondernemingen die het wel gelukt is om de boel te outsourcen.

Zo zal het ook met AI gaan.

Oud collega van mij noemt AI agents ook Indiërs Je moet ze precies vertellen wat ze moeten doen, anders wordt het niks.

Persoonlijk durf ik het niet aan met kritische code, zoals jij ook al aangeeft.

Voor prototyping is het dan wel weer geweldig, want dat hoeft niet perfect te zijn.

Kortom, ik denk dat alle scenario's tegelijkertijd mogelijk zijn Een deel van de software ontwikkeling verdwijnt misschien wel, maar er zal ook een deel overblijven. Hoe complexer het werk is dat je doet, hoe beter.

Mij bekruipt ook regelmatig het gevoel dat de mensen die roepen dat ze bijna geen code zelf meer schrijven, misschien in de eerste plaats al niet aan de meest complexe projecten bezig waren. Ja, dan snap ik het. Als jij aan een dertien in een dozijn line of business app werkt die 90% uit CRUD bestaat zonder complexe logica, dan kun je ook aan een AI vertellen om dat te doen.

Zit je aan een systeem te werken waarvan je amper weet hoe je het moet omschrijven omdat er zoveel uitzonderingen en scenario's zijn, dan gaat AI dat ook niet (betrouwbaar) voor je doen.

Ironisch genoeg is precies dat deel van mijn werk wat ik eigenlijk niet leuk vind, hetgene dat ervoor kan zorgen dat ik mijn baan behoud. En dat is de domein kennis en ervaring die je opdoet, waardoor je ook in staat zal zijn om die brug te slaan tussen de klant en een AI agent.

Ik vind het niet leuk, want ik pruts liever aan de code, maar ik leer ook van alles over financiële administraties, voorraadbeheer, prijs- en kortingsstrategieën en logistiek. Tsja. Ik kan al bijna een opleiding HBO Bedrijfsadministratie doen met wat ik moet weten om mijn werk als programmeur te doen

Saai Leuk hoor, die ERP systemen

Maar goed, het is dus een afweging... ik weet niet of ik een consultant wil zijn, want dat zou ik tegen wil en dank worden als ik op deze voet doorga. Aan de andere kant is dat beter dan werkloos zijn wanneer er een overschot aan "programmeurs" komt door ontwikkelingen in de IT sector.

De grap is juist dat hoe complexer de business rules, des te makkelijker AI dit kan bouwen. Het is dan namelijk een stuk combinatie van een lap tekst kunnen samenvatten, en code schrijven. Ergens zullen die uitzonderingen toch beschreven moeten staan, want anders kun jij ze ook niet coderen....

[DevWouter]

Crazy D schreef op maandag 7 september 2026 @ 13:58:
[...]

De grap is juist dat hoe complexer de business rules, des te makkelijker AI dit kan bouwen. Het is dan namelijk een stuk combinatie van een lap tekst kunnen samenvatten, en code schrijven. Ergens zullen die uitzonderingen toch beschreven moeten staan, want anders kun jij ze ook niet coderen....

De enige reden waarom "business rules" makkelijk zijn voor AI is omdat de meeste bedrijven niks speciaal zijn zelfs als AI alle uitzonderingen volgt (en dat is een groot wat als), dan nog documenteren de meeste software teams niet alle uitzonderingen. En als ze het wel documenteren dan is het vooral de vraag in welke mate de uitzonderingen nog van toepassing zijn.

De vergelijking die @Lethalis maakt over samenwerken met een offshore team vind ik ook treffend. Als je daarmee werkt en je houdt vast aan de "Nederlandse manier van doen" dan gaat dat gigantisch fout. Passen beide kanten zich aan dan gaat het redelijk tot dat je iets afwijkends heb. Waarschijnlijk passen gebruikers van AI zich meer aan de nukken van AI dan ze denken (hier is al aardig wat onderzoek over aan de psychologische kant).

[Exodai]

Ik heb vooral met Codex de laatste tijd het gevoel dat het expres fouten maakt om je er toe te zetten meer tokens te gebruiken. Codex en dus ook Astra maken soms zulke vreemde fouten en hebben dan nog het lef om met je te discussiëren. Ook Astra maakt nu gewoon fouten die Qwen 3.8 Modellen die wij op onze M4 Max hebben draaien niet maken. Terwijl beide zijn aangesloten aan ons informatiesysteem waar alle regels, documenten en code examples/ design.md's te vinden zijn.

Wij slaan bijvoorbeeld alle AI chats en context op in een lokale DB dus zowel Qwen als Astra hebben beide toegang tot alle voormalige informatie en chats die eventueel benodigd zijn en toch lijken lokale modellen soms veel minder vreemde keuzes of fouten te maken.

Qwen mag bij ons bijvoorbeeld automatisch pushen naar Forgejo waar een runner automatisch onze projecten deployed op een testserver maar Astra daarentegen kreeg het niet voor elkaar. Nee het weigerde te pushen en begon ons ervan te overtuigen dat Forgejo geen production solution is en dat we over moeten naar Cloudhosting zoals AWS ipv Fedora Server en dat we onze repositories moeten hosten op Github.

Je ziet iedereen op Youtube op de AGI wagen springen en "I CANT BELIEVE WHAT ASTRA DID, FINALLY AGI" en het is eigenlijk gewoon dom. We hebben het ook even getest met SwiftUI en het genereert zonder zich te schamen gewoon een 1200 regels lange UI waarmee het de compiler verzuipt en durft dan nog te beweren dat dit DE MANIER is om SwiftUI te schrijven.

Volgens mij ben ik gewoon te veeleisend of heb ik een andere definitie van AGI. Of misschien ben ik gewoon dom.

[samida]

Exodai schreef op woensdag 9 september 2026 @ 01:19:
Ik heb vooral met Codex de laatste tijd het gevoel dat het expres fouten maakt om je er toe te zetten meer tokens te gebruiken. Codex en dus ook Astra maken soms zulke vreemde fouten en hebben dan nog het lef om met je te discussiëren. Ook Astra maakt nu gewoon fouten die Qwen 3.8 Modellen die wij op onze M4 Max hebben draaien niet maken. Terwijl beide zijn aangesloten aan ons informatiesysteem waar alle regels, documenten en code examples/ design.md's te vinden zijn.

Wij slaan bijvoorbeeld alle AI chats en context op in een lokale DB dus zowel Qwen als Astra hebben beide toegang tot alle voormalige informatie en chats die eventueel benodigd zijn en toch lijken lokale modellen soms veel minder vreemde keuzes of fouten te maken.

Qwen mag bij ons bijvoorbeeld automatisch pushen naar Forgejo waar een runner automatisch onze projecten deployed op een testserver maar Astra daarentegen kreeg het niet voor elkaar. Nee het weigerde te pushen en begon ons ervan te overtuigen dat Forgejo geen production solution is en dat we over moeten naar Cloudhosting zoals AWS ipv Fedora Server en dat we onze repositories moeten hosten op Github.

Je ziet iedereen op Youtube op de AGI wagen springen en "I CANT BELIEVE WHAT ASTRA DID, FINALLY AGI" en het is eigenlijk gewoon dom. We hebben het ook even getest met SwiftUI en het genereert zonder zich te schamen gewoon een 1200 regels lange UI waarmee het de compiler verzuipt en durft dan nog te beweren dat dit DE MANIER is om SwiftUI te schrijven.

Volgens mij ben ik gewoon te veeleisend of heb ik een andere definitie van AGI. Of misschien ben ik gewoon dom.

Heb je voorbeeld van 1200 regels UI dat de compiler verzuipt dat Astra gebouwd heeft? Ben wel benieuwd.

Mijn ervaring is echt heel anders. Het bouwt dingen waar fable 5.1 0 fouten in kan vinden. Maar misschien verzuip je ze in context? Doet fable 5.1 het zelfde?

[DevWouter]

Exodai schreef op woensdag 9 september 2026 @ 01:19:
Ik heb vooral met Codex de laatste tijd het gevoel dat het expres fouten maakt om je er toe te zetten meer tokens te gebruiken. Codex en dus ook Astra maken soms zulke vreemde fouten en hebben dan nog het lef om met je te discussiëren. Ook Astra maakt nu gewoon fouten die Qwen 3.8 Modellen die wij op onze M4 Max hebben draaien niet maken. Terwijl beide zijn aangesloten aan ons informatiesysteem waar alle regels, documenten en code examples/ design.md's te vinden zijn.

Wij slaan bijvoorbeeld alle AI chats en context op in een lokale DB dus zowel Qwen als Astra hebben beide toegang tot alle voormalige informatie en chats die eventueel benodigd zijn en toch lijken lokale modellen soms veel minder vreemde keuzes of fouten te maken.

Qwen mag bij ons bijvoorbeeld automatisch pushen naar Forgejo waar een runner automatisch onze projecten deployed op een testserver maar Astra daarentegen kreeg het niet voor elkaar. Nee het weigerde te pushen en begon ons ervan te overtuigen dat Forgejo geen production solution is en dat we over moeten naar Cloudhosting zoals AWS ipv Fedora Server en dat we onze repositories moeten hosten op Github.

Je ziet iedereen op Youtube op de AGI wagen springen en "I CANT BELIEVE WHAT ASTRA DID, FINALLY AGI" en het is eigenlijk gewoon dom. We hebben het ook even getest met SwiftUI en het genereert zonder zich te schamen gewoon een 1200 regels lange UI waarmee het de compiler verzuipt en durft dan nog te beweren dat dit DE MANIER is om SwiftUI te schrijven.

Volgens mij ben ik gewoon te veeleisend of heb ik een andere definitie van AGI. Of misschien ben ik gewoon dom.

Nah, jouw intelligentie is het probleem niet. Wat wel een probleem is dat Astra een ander model is en dus een andere werkwijze vereist en nu mag je uitzoeken wat jij aan jezelf mag veranderen zodat de LLM weer zijn werk doet.

Overigens vind ik het wel opvallend dat het jouw pusht richting commerciële oplossingen. Dat klinkt in mijn oren alsof bepaalde trainingsdata te veel liefde heeft gekregen.

[Mugwump]

Exodai schreef op woensdag 9 september 2026 @ 01:19:
Ik heb vooral met Codex de laatste tijd het gevoel dat het expres fouten maakt om je er toe te zetten meer tokens te gebruiken. Codex en dus ook Astra maken soms zulke vreemde fouten en hebben dan nog het lef om met je te discussiëren. Ook Astra maakt nu gewoon fouten die Qwen 3.8 Modellen die wij op onze M4 Max hebben draaien niet maken. Terwijl beide zijn aangesloten aan ons informatiesysteem waar alle regels, documenten en code examples/ design.md's te vinden zijn.

Wij slaan bijvoorbeeld alle AI chats en context op in een lokale DB dus zowel Qwen als Astra hebben beide toegang tot alle voormalige informatie en chats die eventueel benodigd zijn en toch lijken lokale modellen soms veel minder vreemde keuzes of fouten te maken.

Qwen mag bij ons bijvoorbeeld automatisch pushen naar Forgejo waar een runner automatisch onze projecten deployed op een testserver maar Astra daarentegen kreeg het niet voor elkaar. Nee het weigerde te pushen en begon ons ervan te overtuigen dat Forgejo geen production solution is en dat we over moeten naar Cloudhosting zoals AWS ipv Fedora Server en dat we onze repositories moeten hosten op Github.

Je ziet iedereen op Youtube op de AGI wagen springen en "I CANT BELIEVE WHAT ASTRA DID, FINALLY AGI" en het is eigenlijk gewoon dom. We hebben het ook even getest met SwiftUI en het genereert zonder zich te schamen gewoon een 1200 regels lange UI waarmee het de compiler verzuipt en durft dan nog te beweren dat dit DE MANIER is om SwiftUI te schrijven.

Volgens mij ben ik gewoon te veeleisend of heb ik een andere definitie van AGI. Of misschien ben ik gewoon dom.

Er is de producenten van de modellen alles aan gelegen om de boel zoveel mogelijk te hypen, dus we hebben elke nieuwe generatie zogenaamd nu echt AGI en elke keer valt het toch weer vies tegen wat die modellen daadwerkelijk zelfstandig kunnen.

Ik loop ook steeds vaker weer shit op te lossen van mensen die in aardig tempo iets opleveren dat ogenschijnlijk lijkt te werken, totdat het in productie wordt uitgerold en er allerlei bugs en performance issues naar boven komen drijven.

[eheijnen]

Ter controle kan die bewering eens afgezet worden tegen wat hier staat beschreven waaraan zo'n AGI zou moeten voldoen redelijkerwijs. Voor zover bekend zijn er geen officiële standaarden.

Buiten dat de bedrijven modellen steeds verder proberen te ontwikkelen zijn ze natuurlijk ook in een (financiële) rat-race verwikkeld met elkaar.

Hier wordt door IBM een ruime beschrijving gegeven over wat AGI inhoud, beter gezegd, zou moeten inhouden.
https://www.ibm.com/think...cial-general-intelligence

[DevWouter]

eheijnen schreef op woensdag 9 september 2026 @ 11:40:
Ter controle kan die bewering eens afgezet worden tegen wat hier staat beschreven waaraan zo'n AGI zou moeten voldoen redelijkerwijs. Voor zover bekend zijn er geen officiële standaarden.

Buiten dat de bedrijven modellen steeds verder proberen te ontwikkelen zijn ze natuurlijk ook in een (financiële) rat-race verwikkeld met elkaar.

Het is net zoiets als Tesla Full Self-Driving, wat SAE2 is terwijl ze doen alsof het SAE5 is. (wat is het verschil: https://brx-content.fulls...6-visual-chart_5.3.21.pdf)

Hier wordt door IBM een ruime beschrijving gegeven over wat AGI inhoud, beter gezegd, zou moeten inhouden.
https://www.ibm.com/think...cial-general-intelligence

Ik zou de Wikipedia: Artificial general intelligence gebruikt hebben. Dat verhaal van IBM was onleesbaar.

[arjan1995]

OpenAI gebruikt AGI in mijn ogen toch echt als marketingterm. Tuurlijk zal hun nieuwste model weer net iets beter zijn en de tooling eromheen wordt ook steeds beter, maar de algemene consensus is toch wel dat er meer nodig is dan alleen LLM's om AGI te kunnen bereiken.

[eheijnen]

Majaa, helemaal "luchtdicht" zijn die uitspraken ook niet.

We've achieved AGI," says Nvidia CEO, but his own examples suggest otherwise

https://www.techspot.com/...ceo-but-own-examples.html

Wat ik gevonden heb is dat hij dat enkele jaren roeptoetert, schijnt samen te gaan met grote orders.