Nieuwe plek in de Devschuur?

[Lethalis]

Yucon schreef op maandag 2 februari 2026 @ 12:52:
[...]
En dit, beste Lethalis, is precies waarom PoC's e.d. met echte developers vaak te lang duurt en te stroef gaat

Als PoC's met mij te lang duren en stroef gaan, dan komt dat omdat de stakeholders vaak niet inzien dat de daadwerkelijke realisatie complexer is dan de PoC. Kortom, het wordt dan een stuk zelfbescherming.

Ik heb in het verleden weleens snel dingen in elkaar geflanst voor een proof of concept en vervolgens moet je lullen als Brugman om uit te leggen dat het nog niet af is. Mensen snappen dat gewoon niet.

Tsja, dan ga je die fout niet nog eens maken en doe je het meteen goed. Waarbij "goed" niet betekent dat je meteen aan premature optimization doet en te complexe architectuur, maar dat je het iig zo opzet in de basis dat je het niet weg hoeft te gooien zodra je er een echt product van wil maken.

[Standeman]

CodeCaster schreef op maandag 2 februari 2026 @ 12:55:
[...]

Jouw reactie geeft meteen het probleem hier aan, wat @Yucon hierboven perfect aangeeft.

Wat als iemand een onschuldig appje wil bouwen waarmee die, ik noem maar wat, z'n boodschappenlijst kan maken zonder die data meteen bij Big Tech te stallen of op Team.Blue Hosting te moeten zetten. Zit er een SQL injection vulnerability in voor SQLite? Gefeliciteerd, heeft precies niemand last van. En is die z'n boodschappenlijst kwijt door z'n eigen foute invoer: eigen schuld, leermomentje.

Zelfde leermomentje als iemand een gevibecode POC in productie zet voor de hele wereld en die trekt een Azure-rekening naar de tienduizenden dollars, of die gaat klantgegevens in het rond spuwen. Experts blijven nodig.
...

Hoe vak ik wel eens een PoC in elkaar gehacked heb en een omhooggevallen manager riep "duw maar naar productie, want het werkt toch" is niet op 1 hand te tellen.
En dan ben je meer tijd kwijt om die manager te overtuigen dat die PoC de vuilnisbak in kan dan dat je bezig bent geweest met de PoC.

Maar LLM heeft zeker z'n nut. Ik gebruik het voornamelijk als rubber duck, hoewel mijn kat daar ook geschikt voor is. En soms gebruik ik het om een klein gaatje in mijn kennis op te vullen, maar dan werkt google ook wel voor.

Om terug on-topic te gaan.. Ik denk zeker dat er een plek is voor LLM's binnen Devschuur. Vibecoden an sich niet zo heel erg.

[Joep]

Sp00n schreef op maandag 2 februari 2026 @ 12:52:
Nog groener dan groen. De:

[...]

Ik zag het pleonasme al toen ik het schreef, maar ik dacht, wat kan het kwaad

[Lethalis]

CodeCaster schreef op maandag 2 februari 2026 @ 12:55:
[...]
En weet je hoeveel bagger er nu in de markt wordt gezet en is gezet zonder LLM's?

Dat kan ik niet ontkennen inderdaad

[Sp00n]

Oon schreef op maandag 2 februari 2026 @ 12:53:
[...]

Aan alles dat je zegt lees ik vrij expliciet af dat kwaliteit, performance, security e.d. je geen reet boeien en je gewoon lekker snel zelf iets wil laten knutselen door je AI. Prima, maar dat heeft dan ook weer helemaal niks te zoeken in een professionele/commerciele setting.

Ik heb heel wat AI-geproduceerde code gezien en met wat expliciete prompting is het zeker nuttig, maar als ik zie hoeveel tijd ik als softwaredeveloper kwijt ben om zelfs de betere AI agents code te laten produceren die voldoet aan de eisen die ik aan een vers afgestudeerde junior zou stellen dan denk ik dat we het toch over totaal andere usecases hebben.

Waar vibe coden heel leuk voor is, is bespoke persoonlijke software; snel een tootlje maken dat jouw Instagram posts bij elkaar raapt of dat twee heel specifieke datasets met elkaar vergelijkt. Maar ik zou toch oppassen met roepen dat jij het gemaakt hebt, en al helemaal met dergelijke codebases online zetten, want dat betekent dus ook dat mensen bij jou aankloppen wanneer het mis gaat.
De meeste repo's die met vibe coden gemaakt zijn zitten zo ramvol lage kwaliteit AI slop dat ze echt geen enkele code review doorkomen, laat staan een professionele pentest.

Dit alles niet om je te ontmoedigen en ik ben ook zeker geen tegenstander van het geheel, maar ik vind Devschuur toch wel gericht op mensen die willen (leren) ontwikkelen, en vibe coden heeft daarmee net zo min een plek hier als DALL-E of Midjourney in Fotografie -> Showcases en creaties

Ik ben bezig met dit project: *spam* en 95% is gemaakt met AI.

Dit is misschien "een snel tooltje", maar we blijven bouwen met AI en binnenkort is dit niet meer enkel een tooltje.

Elke week melden meer dan 100 mensen zich aan en de eerste betalende klanten (7) zijn er ook al.

Ik lees uit alles wat jij schrijft dat je nog niet in 2026 leeft

[ Voor 0% gewijzigd door MueR op 02-02-2026 23:59 ]

[Lethalis]

Maar om even ontopic te gaan over de vraag of vibe coding / LLM gebruik een plek heeft binnen de Devschuur... ik vraag mij serieus af waarom het een aparte plek nodig heeft?

Je kunt eigenlijk niet het ene hebben zonder het andere. Dus of je ziet LLM gebruik en vibe coding als onderdeel van software ontwikkeling, of niet. En als je het wel zo ziet, dan kun je ook gewoon topics in de Devschuur erover aanmaken zonder dat hiervoor een aparte plek hoeft te worden ingericht.

Het is nou ook weer niet zo alsof er zoveel gebeurt in dit subforum.

Ook al geloof ik zelf niet zo in alles met AI doen, wil ik best meelezen in die topics. Als ze maar over een concreet probleem gaan dat je probeert op te lossen. Of dat nou met of zonder AI is, is eigenlijk een detail.

Een topic over prompt engineering kan ook interessant zijn. Zoals eerder gezegd, word ik er niet vrolijk van, maar je kan er best veel mee als je het maar genoeg context voert. Zo heb ik ook weleens wat code laten genereren die data ophaalde uit een database en in een class stopte, door alleen maar het CREATE TABLE DDL statement aan een AI te geven, zodat hij iig wist wat hij moest maken.

Het is alleen dat ik 3 seconden later bedacht dat ik al 10 ORM tools heb die ditzelfde probleem voor mij oplossen, en nog beter ook, maar toch... het was even een leuke gimmick.

[Lethalis]

Sp00n schreef op maandag 2 februari 2026 @ 13:26:
[...]
Ik ben bezig met dit project ******** en 95% is gemaakt met AI.

Elke week melden meer dan 100 mensen zich aan en de eerste betalende klanten (7) zijn er ook al.

Ik lees uit alles wat jij schrijft dat je nog niet in 2026 leeft

Reclame maken voor jouw product is volgens mij niet toegestaan op Tweakers. Ook niet in 2026.

[Kheos]

Sp00n schreef op maandag 2 februari 2026 @ 13:26:
[...]
Ik ben bezig met dit project: *spam* en 95% is gemaakt met AI.
Dit is misschien "een snel tooltje", maar we blijven bouwen met AI en binnenkort is dit niet meer enkel een tooltje.
Elke week melden meer dan 100 mensen zich aan en de eerste betalende klanten (7) zijn er ook al.
Ik lees uit alles wat jij schrijft dat je nog niet in 2026 leeft

In combinatie met

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
Ik test alle apps die ik maak natuurlijk ook zelf.
Dat kan nog steeds betekenen dat er ergens onder water iets niet goed gaat, maar de output is wel wat ik wil.

Security problemen merk je als je zelf codeert ook niet altijd. Maar ik moet zeggen dat ik ook nog geen (geautomatiseerde) pentesten heb geprobeerd, noch iets van security libraries toegevoegd omdat ik ervan uitga dat het voor de simpele dingen die ik maak, niet nodig is.

Ik zet de popcorn alvast klaar want dit is gewoon wachten tot dit misgaat. En ja, dat gaat mis.

Heerlijk toch dat er decennia aan best practices en ervaring opzij worden geschoven om dan te horen dat we niet in 2026 leven. Ja hoor. Op een dag ontdek je vast waar die best practices voor nodig waren.
Succes ermee!

[ Voor 1% gewijzigd door MueR op 03-02-2026 00:01 ]

[Cartman!]

Kheos schreef op maandag 2 februari 2026 @ 13:45:
Op een dag ontdek je vast waar die best practices voor nodig waren.

Betaal- en persoonsgegevens bij een platform waarbij de maker zegt dat security niet nodig is, ik deel je zorgen.

[Sp00n]

Kheos schreef op maandag 2 februari 2026 @ 13:45:
[...]

In combinatie met

[...]

Ik zet de popcorn alvast klaar want dit is gewoon wachten tot dit misgaat. En ja, dat gaat mis.

Heerlijk toch dat er decennia aan best practices en ervaring opzij worden geschoven om dan te horen dat we niet in 2026 leven. Ja hoor. Op een dag ontdek je vast waar die best practices voor nodig waren.
Succes ermee!

Thanks!

Bij elk product is het wachten tot het misgaat. Alleen als je niet wacht en door blijft ontwikkelen en updaten, is de kans groter dat er geen kwetsbaarheden uitgebuit kunnen worden.

Een wordpress instalaltie van 2024, in 2024, was toen zo veilig als maar zijn kon. Open source. Duizenden mensen die er aan werken. Maar als je je site niet update naar de nieuwste versie, krijg je kwetsbaarheden in de software die eerder nog veilig was.

Zelfde geldt voor (maatwerk|AI) software.

[Oon]

Sp00n schreef op maandag 2 februari 2026 @ 13:26:
[...]


Ik ben bezig met dit project: <reclame> en 95% is gemaakt met AI.

Dit is misschien "een snel tooltje", maar we blijven bouwen met AI en binnenkort is dit niet meer enkel een tooltje.

Elke week melden meer dan 100 mensen zich aan en de eerste betalende klanten (7) zijn er ook al.

Ik lees uit alles wat jij schrijft dat je nog niet in 2026 leeft

Pfoe, ben benieuwd wat die 7 mensen gaan doen als jouw app gehackt wordt, jij geen idee hebt hoe je het überhaupt moet dichten en geen monitoring hebt op toegang omdat je de AI daar niet voor hebt geprompt, en je pas als die klanten komen klagen aan kan geven dat je van niks weet..

Verder heb ik letterlijk aangegeven dat ik er ook mee bezig ben, alleen dan vanuit het oogpunt van een developer. Ik weet wat de normale standaarden zijn, welke eisen veilige code heeft, hoe ik zelf mijn performance op orde kan krijgen etc. Voor je eigen lokale tooltje is het allemaal prima, lekker blijven spelen, maar als je iets online gaat zetten zijn die standaarden en eisen er niet voor niks.

[Sp00n]

Cartman! schreef op maandag 2 februari 2026 @ 13:52:
[...]

Betaal- en persoonsgegevens bij een platform waarbij de maker zegt dat security niet nodig is, ik deel je zorgen.

Waar ik het eerder over had heeft niks met die project te maken. Ik heb hier niet aan gewerkt met AI. Dat doet mijn compagnon.

[Cartman!]

Sp00n schreef op maandag 2 februari 2026 @ 13:53:
Bij elk product is het wachten tot het misgaat. Alleen als je niet wacht en door blijft ontwikkelen en updaten, is de kans groter dat er geen kwetsbaarheden uitgebuit kunnen worden.

Een product lanceren is meer dan alleen code deployen net zoals programmeren meer is dan alleen code te schrijven. Ik vind dat het als software bedrijf je morele verplichting is aan je (al dan niet betalende) klanten dat je zo zorgvuldig mogelijk om gaat met hun gegevens. Dit houdt dus in om veilig te werken op je systemen, code schrijft met security best practises en je infra zo goed mogelijk beveiligt. Dat kun je dan weer valideren met automatische tools als Aikido/Snyk als mede door handmatige pentests. Kost tijd, kost geld en ga je dingen van terug krijgen maar dat hoort bij het maken van een product.

Een wordpress instalaltie van 2024, in 2024, was toen zo veilig als maar zijn kon. Open source. Duizenden mensen die er aan werken. Maar als je je site niet update naar de nieuwste versie, krijg je kwetsbaarheden in de software die eerder nog veilig was.

Zelfde geldt voor (maatwerk|AI) software.

Wordpress was in 2024 ook niet veilig en dat is een probleem op zichzelf, een whataboutism.

Sp00n schreef op maandag 2 februari 2026 @ 13:56:
[...]

Waar ik het eerder over had heeft niks met die project te maken. Ik heb hier niet aan gewerkt met AI. Dat doet mijn compagnon.

Dan hoop ik dat hij wel weet hoe hij veilige software schrijf en beheert

[ Voor 10% gewijzigd door Cartman! op 02-02-2026 14:04 ]

[Patriot]

Sp00n schreef op maandag 2 februari 2026 @ 12:36:
Misschien nog even goed voor alle reageerders die wat offtopic gaan.

Ik snap dat de dino's de lucht in kijken en zich niet realiseren dat het toch een flinke komeet is die op (jullie) ons afkomt.

En voor elke dino die zich niet heeft aangepast aan een geslaagde technologie heb je een lemming die zich achter een falende technologie van een klif heeft gestort omdat hij net zo min de toekomst kon voorspellen. Om nog maar te zwijgen over al die gevallen waar de soep niet zo heet werd gegeten en uiteindelijk bleek dat het oude en het nieuwe een plekje had.

Het gaat me meer om de discussie of dit een aparte plek verdient binnen GoT. Er zijn genoeg pro's en con's te bedenken voor vibe coding / programmeren met AI. En er zijn zeker grote risico's.

De vraag is of we daarmee onderdeel van het probleem of van de oplossing kunnen zijn door hier een plek te bieden waar mensen terecht kunnen voor hun vragen / verhalen / twijfels.

Maar het is ook niet erg om er verantwoordelijk mee om te gaan. Je vraagt specifiek naar een subforum voor vibecoding, dat betekent dus mensen die geen of nauwelijks inhoudelijke kennis hebben er wel mee aan de slag gaan. Dat betekent dat er bijv. overwegingen gemaakt moeten worden in welke mate je dat wil ondersteunen in die gevallen waar bepaalde risico's worden genomen. Dat is dus allemaal zeker niet offtopic.

[Oon]

Patriot schreef op maandag 2 februari 2026 @ 14:14:
[...]


Maar het is ook niet erg om er verantwoordelijk mee om te gaan. Je vraagt specifiek naar een subforum voor vibecoding, dat betekent dus mensen die geen of nauwelijks inhoudelijke kennis hebben er wel mee aan de slag gaan. Dat betekent dat er bijv. overwegingen gemaakt moeten worden in welke mate je dat wil ondersteunen in die gevallen waar bepaalde risico's worden genomen. Dat is dus allemaal zeker niet offtopic.

Sowieso wordt er hier op Tweakers altijd eigen inzet verwacht, die is er toch per definitie niet met vibe coden?

Ik kan me niet voorstellen dat vraagtopics met iets anders beantwoord (kunnen) gaan worden dan 'leer eerst even de basis van programmeren en probeer het dan opnieuw', want ook als je een AI al het werk laat doen lost snappen waar de AI mee bezig is de meeste problemen direct op. Spoonfeeden doen we hier niet, en als je zelf niet snapt waar je mee bezig bent en hier om hulp komt vragen is dat de enige andere mogelijke oplossing.

Óf vibe coden is daadwerkelijk de toekomst en gaat snel goed genoeg werken dat er geen los forum of topic voor nodig is, óf vibe coden heeft hier niks te zoeken, denk ik..

[Patriot]

Oon schreef op maandag 2 februari 2026 @ 14:20:
[...]

Sowieso wordt er hier op Tweakers altijd eigen inzet verwacht, die is er toch per definitie niet met vibe coden?

Ik heb ervoor gekozen om het te interpreteren als "een subforum voor prompt engineering waar je misschien wat hulp kunt krijgen van programmeurs," al was het alleen maar omdat we allemaal meer hebben aan een constructieve insteek. Maar ik kan me ook heel goed voorstellen dat er uiteindelijk voor wordt gekozen om het niet te doen.

Ik kan me niet voorstellen dat vraagtopics met iets anders beantwoord (kunnen) gaan worden dan 'leer eerst even de basis van programmeren en probeer het dan opnieuw', want ook als je een AI al het werk laat doen lost snappen waar de AI mee bezig is de meeste problemen direct op. Spoonfeeden doen we hier niet, en als je zelf niet snapt waar je mee bezig bent en hier om hulp komt vragen is dat de enige andere mogelijke oplossing.

Óf vibe coden is daadwerkelijk de toekomst en gaat snel goed genoeg werken dat er geen los forum of topic voor nodig is, óf vibe coden heeft hier niks te zoeken, denk ik..

offtopic:
"spoonfeeden", was dat een bewuste woordkeuze?

[Oon]

Patriot schreef op maandag 2 februari 2026 @ 14:30:
[...]


Ik heb ervoor gekozen om het te interpreteren als "een subforum voor prompt engineering waar je misschien wat hulp kunt krijgen van programmeurs," al was het alleen maar omdat we allemaal meer hebben aan een constructieve insteek. Maar ik kan me ook heel goed voorstellen dat er uiteindelijk voor wordt gekozen om het niet te doen.

Prima, maar dat zou dan beter passen in een heel nieuw AI forum met daar ook de video/afbeelding tools, algemeen schrijven van tekst en dingen als Claude's nieuw Cowork feature erbij. Dat heeft allemaal net zo veel met software development te maken als vibe coden

[...]

offtopic:
"spoonfeeden", was dat een bewuste woordkeuze?

Ik was de Nederlandse term 'voorkauwen' even kwijt

[Sp00n]

Cartman! schreef op maandag 2 februari 2026 @ 14:03:
[...]

Een product lanceren is meer dan alleen code deployen net zoals programmeren meer is dan alleen code te schrijven. Ik vind dat het als software bedrijf je morele verplichting is aan je (al dan niet betalende) klanten dat je zo zorgvuldig mogelijk om gaat met hun gegevens. Dit houdt dus in om veilig te werken op je systemen, code schrijft met security best practises en je infra zo goed mogelijk beveiligt. Dat kun je dan weer valideren met automatische tools als Aikido/Snyk als mede door handmatige pentests. Kost tijd, kost geld en ga je dingen van terug krijgen maar dat hoort bij het maken van een product.

Ik ben benieuwd hoe je ervoor zorgt dat alle dependencies in je project "veilig" worden verklaard. Een kluwen aan libraries die niet altijd goed worden bijgehouden. Sommige die misschien ook al tijden geen update meer hebben gehad. Je denkt dat je safe zit omdat je de laatste versie hebt, maar schijn bedriegt natuurlijk. Want hij wordt al maanden (of jaren) niet meer geüpdatete.

[Standeman]

Sp00n schreef op maandag 2 februari 2026 @ 14:43:
[...]


Ik ben benieuwd hoe je ervoor zorgt dat alle dependencies in je project "veilig" worden verklaard. Een kluwen aan libraries die niet altijd goed worden bijgehouden. Sommige die misschien ook al tijden geen update meer hebben gehad. Je denkt dat je safe zit omdat je de laatste versie hebt, maar schijn bedriegt natuurlijk. Want hij wordt al maanden (of jaren) niet meer geüpdatete.

Door artikelen te lezen, de communities in de gaten te houden, OWASP checks om te zien of er CVE's zijn en geautomatiseerde version check in je build proces, licentie controles, auditing, code reviews, NIS2 richtlijnen volgen, procedure's, SLA's, pentesting door externen, etc.

Maar het aller aller belangrijkste is door te weten wat er allemaal je project ingetrokken wordt, waarom en wat het doet.

Allemaal geen 100% garantie, maar het beperkt de risico's behoorlijk.

[ Voor 6% gewijzigd door Standeman op 02-02-2026 15:28 ]

[Cartman!]

Sp00n schreef op maandag 2 februari 2026 @ 14:43:
Ik ben benieuwd hoe je ervoor zorgt dat alle dependencies in je project "veilig" worden verklaard. Een kluwen aan libraries die niet altijd goed worden bijgehouden. Sommige die misschien ook al tijden geen update meer hebben gehad. Je denkt dat je safe zit omdat je de laatste versie hebt, maar schijn bedriegt natuurlijk. Want hij wordt al maanden (of jaren) niet meer geüpdatete.

Daar heb je tooling voor zoals Aikido/Snyk die dat netjes voor je bijhouden, alerten en evt PRs voor kunnen doen. Maar het zijn gewoon 2 verschillende dingen, dat je een dependency hebt die geen known vulnerability heeft betekent niet per definitie dat jij als developer geen vulnerability introduceert door fout gebruik van die dependency.

OT: volgens mij had ik de eigenlijke vraag van dit topic niet behandeld; nee, ik denk niet dat dit een losse plek moet zijn. Als je tijdens het vibe coden een issue hebt moet je ook gewoon debuggen en met een duidelijk probleem komen en wat je al geprobeerd hebt om het op te lossen.

[ Voor 14% gewijzigd door Cartman! op 02-02-2026 15:13 ]

[Kheos]

Sp00n schreef op maandag 2 februari 2026 @ 14:43:
[...]
Ik ben benieuwd hoe je ervoor zorgt dat alle dependencies in je project "veilig" worden verklaard. Een kluwen aan libraries die niet altijd goed worden bijgehouden. Sommige die misschien ook al tijden geen update meer hebben gehad. Je denkt dat je safe zit omdat je de laatste versie hebt, maar schijn bedriegt natuurlijk. Want hij wordt al maanden (of jaren) niet meer geüpdatete.

Door een correcte strategie uit te denken en uit te voeren in combinatie met de juiste tooling. Genoeg tools die in je ci/cd pipeline de sbom inlezen en die dan checken met known issue databases.

[Joep]

Sp00n schreef op maandag 2 februari 2026 @ 14:43:
[...]


Ik ben benieuwd hoe je ervoor zorgt dat alle dependencies in je project "veilig" worden verklaard. Een kluwen aan libraries die niet altijd goed worden bijgehouden. Sommige die misschien ook al tijden geen update meer hebben gehad. Je denkt dat je safe zit omdat je de laatste versie hebt, maar schijn bedriegt natuurlijk. Want hij wordt al maanden (of jaren) niet meer geüpdatete.

Dat is wel even van een andere orde van grootte qua risico t.o.v. 100% afgaan op het antwoord van b.v. Claude op de vraag "Is de code die je daarnet hebt gegenereerd wel veilig?"

[Lethalis]

Sp00n schreef op maandag 2 februari 2026 @ 14:43:
[...]
Ik ben benieuwd hoe je ervoor zorgt dat alle dependencies in je project "veilig" worden verklaard. Een kluwen aan libraries die niet altijd goed worden bijgehouden. Sommige die misschien ook al tijden geen update meer hebben gehad. Je denkt dat je safe zit omdat je de laatste versie hebt, maar schijn bedriegt natuurlijk. Want hij wordt al maanden (of jaren) niet meer geüpdatete.

Daar heb je doorgaans gewoon tools voor?

Voor de gemiddelde developer betekent dat gewoon even een blik op zijn package manager werpen. Of dat nou NuGet, npm, of wat dan ook is, meestal kun je eenvoudig een lijst opvragen van outdated packages inclusief veiligheidswaarschuwingen. Even vanuit de IDE bijwerken, unit en integratie tests draaien en je kan er weer even tegenaan?

Of je hebt een automated tool die regelmatig dit soort checks voor je uitvoert. Je kunt dan denken aan Jenkins, of een andere CI/CD tool. Op mijn werk gebruiken we Jenkins om bijvoorbeeld regelmatig een code scan uit te voeren. Als er iets fout gaat, dan krijgen we automatisch een mailtje daarover.

[ Voor 7% gewijzigd door Lethalis op 02-02-2026 16:18 ]

[Sissors]

Lethalis schreef op maandag 2 februari 2026 @ 12:11:
Het vervelende van AI is dat normies nu denken dat programmeren iets is dat je wel even snel kan doen. De waardering voor het vak daalt zienderogen.

Maar als niet IT'er: Datzelfde heb ik al jaren lang gezien vanuit IT'ers. IIG op specifiek code schrijven. Dat is code kloppen. Nee de architectuur, dat is het belangrijke. Maar het daadwerkelijk code schrijven? Dat kan elke aap wel.

En nu kan ik me prima voorstellen dat een goede architectuur essentieel is. Tegelijk zolang een chat app sinds een ~2020 prima een gigabyte RAM nodig heeft, een kalender widget 150MB RAM vraagt, een home assistent met 1GB RAM als toch wel erg weinig wordt gezien voor wat automatisatie, etc. Dan is mijn conclusie dat het misschien maar beter is een AI code te laten schrijven, die dan hopelijk beter geoptimaliseerd kan zijn, in een efficiëntere taal.

(Waarschijnlijk ben ik nu naiief optimistisch dat er efficientere code uit komt, gezien het ook getrained is op diezelfde belabberde code, maar de hoop is er).

[Standeman]

Sissors schreef op maandag 2 februari 2026 @ 17:28:
[...]

Maar als niet IT'er: Datzelfde heb ik al jaren lang gezien vanuit IT'ers. IIG op specifiek code schrijven. Dat is code kloppen. Nee de architectuur, dat is het belangrijke. Maar het daadwerkelijk code schrijven? Dat kan elke aap wel.

En nu kan ik me prima voorstellen dat een goede architectuur essentieel is. Tegelijk zolang een chat app sinds een ~2020 prima een gigabyte RAM nodig heeft, een kalender widget 150MB RAM vraagt, een home assistent met 1GB RAM als toch wel erg weinig wordt gezien voor wat automatisatie, etc. Dan is mijn conclusie dat het misschien maar beter is een AI code te laten schrijven, die dan hopelijk beter geoptimaliseerd kan zijn, in een efficiëntere taal.

(Waarschijnlijk ben ik nu naiief optimistisch dat er efficientere code uit komt, gezien het ook getrained is op diezelfde belabberde code, maar de hoop is er).

Alles is belangrijk. Architectuur, goede code kloppen, onderhoud, weten wat je doet, etc.

Maar efficiëntie is duur en wordt afgewogen door de prijs van hardware (met de huidige prijzen kunnen we wel wat efficiëntere code verwachten )

En trouwens.. waar je chatapp in 2010 amper plaatjes kon versturen van (gechargeerd) 320x240 in cga, moeten ze nu 8k video met HDR en 30 talen audio over de lijn kunnen pompen en direct zichtbaar zijn in de preview, het liefst 10 tegelijk.

[Eric Z]

Hardware er tegen aan gooien is goedkoper dan uren werk om te optimaliseren. Zeker met cloud is even opschalen zo gedaan. Totdat de kosten echt uit de klauwen lopen, dan komt er best wat ellende naar boven en had er toch iets eerder een en ander ge-optimaliseert moeten worden.

AI ben ik nog niet ondersteboven van, vooral nog een goede samenvatter indien je werkt met gesloten of relatief nieuwe systemen.
Linksom of rechtsom kwam ik in een soort eindeloze verwijzing tussen manier A en manier B. Waarbij beide niet volledig konden wat ik wilde bereiken. De oplossing is er niet, maar 27 variaties van A en B verder was ik er wel klaar mee.
Ok, er zijn ook zeker gevallen geweest waar het wel goed geholpen heeft. Een melding over exposen van tokens in je front-end was goede om direct op te pakken die door mensen gemist is.

Ik ben er in ieder geval nog niet van overtuigt dat het ons als developer overbodig maakt.

Voor het eerder genoemde linkje, als AI zo goed is mag het ook aan zoiets simpels als security headers van de site denken. Iedere (web)developer weet er vanaf. Maar zolang je er niet om vraagt begint AI er blijkbaar niet zelf aan. En daar raak je een kern van het probleem, het ziet er visueel goed uit. Maar is het ook solide basis en veilig? Zonder kennis van code is dat niet te beoordelen.

White-hat hacker gaat zich niet vervelen om te assisteren/melden van gaten in AI geknutselde projecten.
En black-hat gaat ook zeker nog wel wat mooie projecten om zeep helpen door gebrek aan kennis en kunde.

[Joost1981_2]

My two cents:
- Quality is value to someone that matters.
- Wie een passie heeft voor code schrijven, testen, yaml, k8s, sql, code first of database first is af. Wie businessproblemen wil/kan oplossen is in.

Als iemand een businessprobleem kan oplossen door vibecoden en dit op een sustainable manier doet, dikke prima! Hoort er zeker thuis, net zoals low code.

[MueR]

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
Ik test alle apps die ik maak natuurlijk ook zelf.

Dat kan nog steeds betekenen dat er ergens onder water iets niet goed gaat, maar de output is wel wat ik wil.

Gefeliciteerd, je hebt jezelf naar het niveau gevibecode van een happy flow kunnen testen.

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
Security problemen merk je als je zelf codeert ook niet altijd.

Allereerst. Programmeurs programmeren. "Coderen" is iets anders. En deze hele statement is, los van de enorme nekharen-omhoog "coderen" uitspraak die alleen leken en scriptkiddiesvibecoders gebruiken, dit is precies het probleem.

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
Maar ik moet zeggen dat ik ook nog geen (geautomatiseerde) pentesten heb geprobeerd, noch iets van security libraries toegevoegd omdat ik ervan uitga dat het voor de simpele dingen die ik maak, niet nodig is.

Yeah.. ehm.. "ik heb geen idee van security en het is toch niet nodig voor mijn slop". Oke.

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
De discussie is voor mij vooral bedoeld om dit topic op het focum wat meer aandacht te geven. Misschien is Devschuur niet de juiste plek, dat zou kunnen. Maar het is wel een heel interessant groeimarkt voor Tweakers denk ik.

Nee. Nee dat is het niet. Niet binnen de context van de Devschuur met het niveau wat jij impliciet voorstelt.

Sp00n schreef op maandag 2 februari 2026 @ 12:36:
Misschien nog even goed voor alle reageerders die wat offtopic gaan.

Ik snap dat de dino's de lucht in kijken en zich niet realiseren dat het toch een flinke komeet is die op (jullie) ons afkomt.

Zullen we de moderatie gewoon overlaten aan de moderators? En iedereen die niet de AI bubble omarmt op jouw manier wegzetten als dinosaurier?

[ Voor 12% gewijzigd door MueR op 03-02-2026 00:13 ]

[eheijnen]

Kan zo snel het draadje niet meer vinden maar is al eens eerder voorgesteld om hier een dedicated VibeCoding topic te hebben.

Vind de discussie/gesprek wel interessant hoe er wordt aangekeken door de (zal ik maar even zeggen) twee fronten. Aan de andere kant kun je ook zien over de tijd of vibe coding verder ontwikkelt. Zich, bijvoorbeeld, zal manifesteren over tijd als een stuk gereedschap van veel programmeurs...

[Sissors]

Eric Z schreef op maandag 2 februari 2026 @ 20:38:
Hardware er tegen aan gooien is goedkoper dan uren werk om te optimaliseren. Zeker met cloud is even opschalen zo gedaan. Totdat de kosten echt uit de klauwen lopen, dan komt er best wat ellende naar boven en had er toch iets eerder een en ander ge-optimaliseert moeten worden.

En dat snap ik vanuit business perspectief prima. En al helemaal omdat veel software bij de klanten draait: Dus de leverancier is niet degene die maar gewoon wat extra hardware ertegenaan moet gooien.

Maar dat betekend dus in theorie iig dat er een hele hoop ruimte is voor AI om efficientere code te leveren als de gemiddelde developer nu levert. En ik snap dus ook dat dat waarschijnlijk vooral bij de theorie blijft voorlopig, gezien AI ook gewoon getrained is om overal eg Electron voor te gebruiken, maar er is veel ruimte voor verbetering iig.

[RayNbow]

@Sissors, je maakt nu wel de aanname dat veel geheugengebruik een teken is van inefficiëntie, terwijl dit helemaal niet het geval hoeft te zijn.

[Sissors]

RayNbow schreef op dinsdag 3 februari 2026 @ 09:20:
@Sissors, je maakt nu wel de aanname dat veel geheugengebruik een teken is van inefficiëntie, terwijl dit helemaal niet het geval hoeft te zijn.

Het is meer dat het het makkelijke voorbeeld is om te laten zien. Maar als 150MB geheugen gebruik voor een kalender widget niet inefficient is, dan weet ik het ook niet meer. En voor veruit de meeste toepassingen is Electron toch echt niet efficient. Wel makkelijk om iets in elkaar te zetten, dat geloof ik direct, dus je kan zeggen dat het efficient is qua development resources. Maar niet efficient qua draaien van het programma.

En als developers geen tijd hebben om het te optimaliseren, tja, dan hopelijk AI wel?

[RayNbow]

Sissors schreef op dinsdag 3 februari 2026 @ 09:23:
Maar niet efficient qua draaien van het programma.

Nou, nee. Een programma kan sneller draaien door meer geheugen te gebruiken. Het meest simpele voorbeeld is het uitrollen van een lus. Je programma wordt groter, neemt dus meer geheugen in gebruik, maar wordt daardoor wel sneller uitgevoerd.

[Woy]

Sissors schreef op dinsdag 3 februari 2026 @ 09:23:
[...]
En als developers geen tijd hebben om het te optimaliseren, tja, dan hopelijk AI wel?

Op zich zou AI hier best een goede tool voor kunnen zijn, maar eerlijk gezegd verwacht ik vooral een beweging de andere kant op. Met AI komt de focus heel erg te liggen op meer software produceren, boven betere software maken.

Sowieso is de AI natuurlijk getraind op bestaande code-bases, dus veel slechte gebruiken zullen gewoon over genomen worden.

[Sissors]

RayNbow schreef op dinsdag 3 februari 2026 @ 10:02:
[...]

Nou, nee. Een programma kan sneller draaien door meer geheugen te gebruiken. Het meest simpele voorbeeld is het uitrollen van een lus. Je programma wordt groter, neemt dus meer geheugen in gebruik, maar wordt daardoor wel sneller uitgevoerd.

En jij verwacht dat de voorbeelden die ik noemde komen door dingen als loop unrolling, en niet door gewoon heel inefficiente code / frameworks voor die toepassing? Dat het in theorie kan is wat anders dan de praktijk natuurlijk.

[RayNbow]

Sissors schreef op zaterdag 7 februari 2026 @ 08:35:
[...]

En jij verwacht dat de voorbeelden die ik noemde komen door dingen als loop unrolling, en niet door gewoon heel inefficiente code / frameworks voor die toepassing? Dat het in theorie kan is wat anders dan de praktijk natuurlijk.

Nee, maar ik geef aan dat je niet zo maar kunt stellen dat een programma dat veel geheugen gebruikt per definitie een vorm van inefficiëntie is. Het is geen voldoende voorwaarde.

[RoestVrijStaal]

Harmsen schreef op maandag 2 februari 2026 @ 11:33:
Iets soort gelijks is bij het bedrijf waar ik werk ook gebeurd: Laagdrempelig de enthousiastelingen voor AI assisted coding bij elkaar zetten. Omdat ze elkaar lieten zien wat ze maakten ontstonden meteen ideeën om nog meer aan elkaar te koppelen en volgende stappen te maken.

Hierdoor zie je dat het gebruik van AI icm MCP en Instructions ook ervoor zorgt dat er niet alleen mee geprogrammeerd wordt, maar ook review slagen op architectuur designs worden gedaan. Daarna wordt met AI ook de Work items/Test cases in het item tracking systeem aangemaakt. Dit was normaal handwerk wat niemand leuk vond om te doen...

Natuurlijk blijft het een hulpmiddel, dus controles voeren we altijd uit op wat er gemaakt wordt!

Programmeren met AI als hulptool en vibe coding waarbij een schijnbaar werkende applicatie wordt gegenereerd zijn twee takken van sport.

De Openingsposter heeft het over het tweede. Het eerste (AI als hulptool, net als iedere static code analyzer, linter of debugger) zou al prima in de devschuur kunnen (of nog een los topic om de discussie tussen de zin en onzin van vibe coding uit de weg te gaan, want dat zou offtopic kunnen zijn).


_______

Yucon schreef op maandag 2 februari 2026 @ 12:52:
[...]

En dit, beste Lethalis, is precies waarom PoC's e.d. met echte developers vaak te lang duurt en te stroef gaat

Is een Proof-of-Concept in software ontwikkeling tegenwoordig überhaupt een ding?

Naar mijn idee is het een reliek uit het verleden toen men dacht dat ontwikkkelingsmethoden die gebruikt werden in de maakindustrie (auto's, meubels, etc) ook toepasselijk waren in de softwareindustrie.

Op zekere hoogte klopt dat. En tegenwoordig is het acherhaald.
De praktijk is, ook wat @Lethalis en @Standeman onderstrepen, als een manager, stakeholder of ander soort stijfkop al iets visueels (en/of interactiefs) ziet, dat denkt die dat het al "klaar" is en dat het in productie kan. Mooi niet dus. Daarom worden, naar mijn ervaring, wireframes en mockups expres niet interactief gemaakt. Los van dat zoiets ook veel onnodig werk meebrengt.

Je zou natuurlijk wireframes en mockups kunnen laten genereren met AI. Het liefst met design language document erbij. Maar dan ben je eigenlijk niet meer aan het vibe-coden

[OverloadOfRed]

RoestVrijStaal schreef op vrijdag 13 februari 2026 @ 00:41:

[...]

Is een Proof-of-Concept in software ontwikkeling tegenwoordig überhaupt een ding?

[...]
Je zou natuurlijk wireframes en mockups kunnen laten genereren met AI. Het liefst met design language document erbij. Maar dan ben je eigenlijk niet meer aan het vibe-coden

Het is juist in mijn ervaring heel waardevol om iets in elkaar te rammen met AI, zodat de gebruiker even de 'look en feel' ook kan ervaren met de muis en toetsenbord. Dit kan je uiteraard ook bereiken met wireframes en hele prototypes die je in Adobe XD/Figma/etc kan maken, maar daar zit ook veel tijd in.

Het moet er alleen wel echt uitzien als een PoC zodat ze niet té enthousiast naar productie willen, die lijn is lastig te vinden

[Basic2me]

Sp00n schreef op maandag 2 februari 2026 @ 11:24:
Ik ben geen programmeur. Maar ik bouw tegenwoordig wel apps met AI.

Ik kan code een beetje lezen en ik kan bugs fixen met AI.

Maar ben ik nu echt software aan het ontwikkelen? (Ja!)

De komende maanden / jaren gaat dit gebied een enorme vlucht krijgen. Iedereen kan straks apps bouwen. Voordat ik mijn eerst app gepubliceerd kreeg, ben ik door heel veel LLM's en CLI's en AI Studio's heen gevlogen.

Nu weet ik een beetje wat werkt en wat niet en hoe ik dingen aan moet pakken.

Ik kan me voorstellen dat er heel veel van dit soort vragen en walkthroughs komen van mensen die hier actief mee aan de slag gaan.

Zou het dan niet een mooi moment zijn om hier een apart plekje voor in te richten in de Devschuur? Vibe coding?

Ben benieuwd naar jullie mening...

Heel mooi onderwerp, AI leert mij veel over code en hoe het werkt. Maakt hele stukken voor mij op basis van ideeën en ondertussen pas ik telkens aan en leer wat er allemaal bij hoort. Wel ontstaan heel snel fouten merk ik, en soms gaat het heel traag naarmate het uitgebreider begint te worden met oneindig debuggen.

Doordat ik geen dev./prog ben en kennis mis, merk ik ook dat bestaande concepten soms helemaal verworpen worden omdat taal, formaat of protocol dan niet op elkaar aansluiten.

Ik volg dit onderwerp met interesse.

[Lethalis]

Joost1981_2 schreef op maandag 2 februari 2026 @ 22:32:
Wie een passie heeft voor code schrijven, testen, yaml, k8s, sql, code first of database first is af. Wie businessproblemen wil/kan oplossen is in.

Mja, ik weiger vooralsnog dit te geloven.

Zeker als het businessprobleem alleen op te lossen is door een complexe technische oplossing te kiezen. Denk daarbij aan systemen die hoge volumes aan transacties moeten verwerken. Dan is het goed ontwerpen van een database en het schrijven van efficiënte queries een stuk belangrijker dan wanneer je maar 50 users hebt. En worden andere architecturele keuzes, zoals het gericht cachen van bepaalde informatie, het scheiden van commands en queries (CQRS), het kunnen opschalen van het volume door load balancing en de consequenties daarvan voor de code, enzovoorts veel belangrijker.

Kortom, technische details kennen is nog steeds erg belangrijk als het systeem veel aan moet kunnen. De zogenaamde -ilities van een systeem (system quality attributes).

Ik word immers niet betaald om de website van de bakker op de hoek te bouwen. Ik werk aan OMS/ERP systemen die duizenden orders per dag verwerken. En daar komen heel veel technische details bij kijken om de boel draaiende te houden.

Mijn ervaring met LLM's is dat ze nou eenmaal eenheidsworst genereren. Logisch ook, want ze kunnen in feite alleen uitspugen wat ze geleerd hebben en je moet wel erg veel blijven prompten om dan precies te krijgen wat je wil.

Voor de rest denk ik ook niet dat jouw stelling exclusief is, maar inclusief moet zijn. Het ene kan niet zonder het andere. Voor mijn werk zijn beide aspecten belangrijk. Ik moet de business begrijpen, maar óók de techniek. Daarom moet ik ook als ik bijvoorbeeld aan een boekhoudmodule werk, in ieder geval in grote lijnen snappen hoe een boekhouding werkt. Dat vind ik niet eens leuk om te doen, maar ik heb inmiddels wel 4 boeken over boekhouden bestudeerd. Ik zou zo examen kunnen gaan doen bij de associatie.

Maar aan de andere kant moet ik mij ook heel bewust zijn van de techniek. Elk financieel feit moet transactioneel worden verwerkt. Er mogen geen rare race conditions zijn, ik moet bewust omgaan met optimistic vs pessimistic concurrency bijvoorbeeld, want atomic updates moeten niet leiden tot dat mensen geen informatie meer op hun scherm krijgen omdat de halve database gelockt is. Daarom heeft optimistic concurrency ook de voorkeur en ga je met versioning werken van je entities, enzovoorts.

Het opvragen van financiële overzichten moet niet een te grote belasting voor het systeem opleveren, waardoor je toch ook gaat kijken naar een vorm van database warehousing en archivering met gerichte redundantie die voor een beginner totaal niet intuïtief is (omdat ze altijd hebben geleerd bij het normaliseren van gegevens dat redundantie juist voorkomen moet worden).

Kortom, de hele architectuur erachter, het technische ontwerp, is net zo belangrijk als het altijd al is geweest. Alleen het stukje code uittypen... nou daar heb je nu dan een hulpje voor. En dat hulpje voelt alsnog als gekkie Henkie die je aan de hand moet vasthouden. Hij wil wel graag helpen, maar het is het vaak nét niet.

En hoe langer ik hierover nadenk, hoe meer ik mij realiseer dat ik niet te vervangen ben door AI. Want het gaat mijn werkgever niet lukken om een AI te prompten om het allemaal maar te fixen. Daar heeft hij dan alsnog mij voor nodig.

Dus ja.

Het code tikken is ook maar 25% van mijn functie. Bedenken wat er moet gebeuren is zoveel belangrijker. Maar daarvoor moet je alsnog ook technisch zijn. Je moet op zijn minst ook in staat zijn om te kunnen beoordelen of iets technisch überhaupt haalbaar is.

[TobyW]

Ik had hierover laatst nog een discussie bij een open dag van een middelbare school, met de docente van het tech lab. Ik vroeg of ze ook iets met programmeren doen. "Ja we gaan vibe coding doen met React, maar echt kunnen programmeren is niet relevant meer".

Nou snap ik dat een leerkracht niet voldoende inzicht in dit onderwerp heeft, maar ik ben er toch tegenin gegaan. Zeker, AI kan de zoveelste simpele webapplicatie veel sneller in elkaar zetten dan een mens. Ik gebruik het zelf ook voor boilerplate code. Maar als, zoals hierboven geschreven, complexe technische keuzes gemaakt moeten worden, of een geheel nieuw algoritme bedacht en geïmplementeerd moet worden, dan moet toch echt wel een mens aan de slag. En zelfs voor redelijk eenvoudige dingen zijn de door AI gegenereerde dingen vaak suboptimaal en loop ik er regelmatig tegenaan dat, bij libraries die nog volop in ontwikkeling zijn, code gegenereerd wordt dit op zijn minst deprecated dingen gebruikt zo niet helemaal niet werkt.

Uiteindelijk is AI als programmeerhulp ook niet anders als automatisering in andere werkvelden, of het nou de mechanisatie van de landbouw of het gebruik van robots in de auto-industrie is. Iemand moet die dingen kunnen bedienen en verbeterde versies ontwikkelen.

[Glashelder]

Dat complexe algoritme en die technische keuzes kan je ook gewoon aan AI uitleggen. En die zal dat dan gewoon netjes plannen en na goedkeuring uitvoeren en dat werk kan je gewoon controleren. Als je pech hebt heeft ie nog wat suggesties om je werk (wat alleen door mensen bedacht kan worden) wat te optimaliseren

Nee echt code kloppen gaat voor mensen echt wel stoppen. Mensen die dat niet inzien doen óf aan wensdenken óf ze hebben Claude nog niet aan het werk gezien.

De laatste tijd ben ik veel met Claude bezig en neem ik developers daarin mee en op één uitzondering na zijn ze tot op heden allemaal direct verkocht.

[RayNbow]

Glashelder schreef op zaterdag 28 februari 2026 @ 11:33:
Nee echt code kloppen gaat voor mensen echt wel stoppen. Mensen die dat niet inzien doen óf aan wensdenken óf ze hebben Claude nog niet aan het werk gezien.

🤔

* RayNbow kijkt naar...

Tuurlijk.

Dat complexe algoritme en die technische keuzes kan je ook gewoon aan AI uitleggen.optimaliseren

Wat als een bepaald algoritme leunt op kennis dat in boeken staat die niet zijn gescrapet tijdens het trainen van een model? Moet je dan eerst alle stof voorkauwen?

Zo staat bijv. de HTW (ISBN 9080307815) niet op het internet.

[Glashelder]

RayNbow schreef op zaterdag 28 februari 2026 @ 12:27:
Wat als een bepaald algoritme leunt op kennis dat in boeken staat die niet zijn gescrapet tijdens het trainen van een model? Moet je dan eerst alle stof voorkauwen?

Zo staat bijv. de HTW (ISBN 9080307815) niet op het internet.

Ja.

Als je een junior developer aanneemt dan zul je die ook moeten uitleggen hoe een bepaald algoritme werkt. Dat is met AI niet anders.

Het grote verschil is dat die junior developer een hele tijd nodig heeft om het algoritme te leren terwijl AI met een fatsoenlijk geschreven readme.md dat in enkele secondes doet. Waarom denk jij trouwens dat zo’n algoritme in de trainingsdata moet zitten? Dat is niet hoe het werkt.

Zo kan je Claude bijv. gewoon vragen uit te zoeken wat ERE certificaten zijn te vragen die in je laadapp in te bouwen (heb ik van de week nog gedaan).

Dat is waarom AI deze strijd gaat winnen. De tijd van 25/30k per maand factureren is gewoon voorbij.

[RayNbow]

Glashelder schreef op zaterdag 28 februari 2026 @ 12:49:
Waarom denk jij trouwens dat zo’n algoritme in de trainingsdata moet zitten? Dat is niet hoe het werkt.

Ik had het over kennis, niet per se dat het algoritme erin moet staan.

Daarnaast is het wel zeker belangrijk dat er algoritmen in de trainingset staan. Of ga je beweren dat als je een LLM traint zonder het ooit een enkel algoritme te tonen dat het dan goed gaat presteren? De reden waarom de taalmodellen een beetje fatsoenlijk werken is omdat ze bakken vol programmeervoorbeelden gezien hebben.

---

Veel modellen gaan trouwens nog de mist in met het voorspellen wat het volgende Commodore 64 programma doet:

code:

10 SIZEX=4
20 SIZEY=5
30 SIZEZ=5
40 VOL=SIZEX*SIZEY*SIZEZ
50 PRINTVOL

[Glashelder]

RayNbow schreef op zaterdag 28 februari 2026 @ 14:57:
[...]

Ik had het over kennis, niet per se dat het algoritme erin moet staan.

Daarnaast is het wel zeker belangrijk dat er algoritmen in de trainingset staan. Of ga je beweren dat als je een LLM traint zonder het ooit een enkel algoritme te tonen dat het dan goed gaat presteren? De reden waarom de taalmodellen een beetje fatsoenlijk werken is omdat ze bakken vol programmeervoorbeelden gezien hebben.

Jij begint over bepaalde algoritmes die niet in boeken beschreven staan dus ik deed de aanname dat we het hier over bedrijfsspecifieke algoritmes hebben. Dus nee, je had het niet over ‘kennis’. Je had het over een ‘bepaald algoritme’. Je kan een LLM prima uitleggen hoe een algoritme werkt, net zoals je dat een andere developer zal moeten uitleggen.

En ja natuurlijk heeft die LLM tijdens de trainingsfase heel veel voorbeeldcode gezien. Dat heeft elke menselijke developer ook. Wat is het punt?

Veel modellen gaan trouwens nog de mist in met het voorspellen wat het volgende Commodore 64 programma doet:

code:

10 SIZEX=4
20 SIZEY=5
30 SIZEZ=5
40 VOL=SIZEX*SIZEY*SIZEZ
50 PRINTVOL

Net zo relevant als hoe goed een LLM is met COBOL. Veel relevanter zijn de prestaties met C++/C#/Java/Rust.. talen die relevant zijn. Meuk uit de jaren 70/80 is niet relevant

Daar komt nog eens bij dat je alleen naar de beste modellen moet kijken. Die zetten de standaarden vandaag de dag. Er zullen ook genoeg mensen de mist in gaan met je voorbeeld.

[TobyW]

Er is een wezenlijk verschil tussen het bedenken van een algoritme en het implementeren hiervan in een specifieke programmeertaal. Ja, uiteraard kun je een algoritme uitleggen aan AI zodat die hem kan implementeren - maar je hebt dan nog steeds een mens nodig om a) het algoritme te bedenken en b) deze op een manier te specificeren dat AI deze werkend en efficiënt implementeert. Het enige wat de AI dus overneemt is het mechanische gedeelte van code in de computer kloppen. Afhankelijk van hoeveel iteratieslagen nodig zijn om te AI te laten begrijpen wat je wilt hebben hoeft dat helemaal niet sneller te zijn dan de code zelf in te voeren. AI biedt dan alleen een voordeel als je de syntax van de programmeertaal niet goed kent.

Hoe goed een LLM met COBOL is, is trouwens zeker relevant! Ik weet niet of je het gemist hebt, maar het aandeel van IBM is 13% in waarde gedaald na de aankondiging dat Claude Code ook met COBOL overweg kan.

[RayNbow]

Glashelder schreef op zaterdag 28 februari 2026 @ 17:46:
[...]

Jij begint over bepaalde algoritmes die niet in boeken beschreven staan dus ik deed de aanname dat we het hier over bedrijfsspecifieke algoritmes hebben. Dus nee, je had het niet over ‘kennis’. Je had het over een ‘bepaald algoritme’. Je kan een LLM prima uitleggen hoe een algoritme werkt, net zoals je dat een andere developer zal moeten uitleggen.

Ik zie dat ik 1 woord verkeerd heb getikt in m'n oorspronkelijke post:

Wat als een bepaald algoritme leunt op kennis datdie in boeken staat die niet zijn gescrapet tijdens het trainen van een model?

Maar zelfs op basis van m'n oorspronkelijke getypte post, nergens zeg ik iets over wat niet in boeken beschreven staat. In tegendeel, ik heb het over iets dat wel in boeken staat, maar niet is gescrapet en dus niet als trainingmateriaal beschikbaar is.

En ja natuurlijk heeft die LLM tijdens de trainingsfase heel veel voorbeeldcode gezien. Dat heeft elke menselijke developer ook. Wat is het punt?

Het punt is dat de LLM geen betrouwbare uitvoer kan produceren over onderwerpen als het niet in het model zit. Het kwalijke daarbij is dat de modellen zo geconditioneerd zijn om toch een antwoord te formuleren, ook al slaat het nergens op.

Net zo relevant als hoe goed een LLM is met COBOL. Veel relevanter zijn de prestaties met C++/C#/Java/Rust.. talen die relevant zijn. Meuk uit de jaren 70/80 is niet relevant

Nu geeft @TobyW hierboven al aan dat iets als COBOL zeker nog steeds relevant is, maar er zijn wel meer dingen uit de vorige eeuw relevant. Wat dacht je van oude Fortran-code die nog moet worden onderhouden? Is daar geen plaats voor in een LLM omdat het oude meuk is?

Daar komt nog eens bij dat je alleen naar de beste modellen moet kijken. Die zetten de standaarden vandaag de dag. Er zullen ook genoeg mensen de mist in gaan met je voorbeeld.

Voel je vrij om mijn C64-voorbeeld aan de beste modellen te geven. De laatste keer dat ik dat probeerde kon ik maar 2 modellen vinden die een bevredigend antwoord konden geven, de rest gaf vol overtuiging een incorrect antwoord.

[Glashelder]

Het punt is dat de LLM geen betrouwbare uitvoer kan produceren over onderwerpen als het niet in het model zit. Het kwalijke daarbij is dat de modellen zo geconditioneerd zijn om toch een antwoord te formuleren, ook al slaat het nergens op.

Dit kunnen we toch gewoon testen? Of vertrouwen we het werk van mensen wel blindelings? Volgens mij ook niet. En een tool als Claude doet gewoon een ‘explore’ sessie op internet als het niet genoeg weet over een onderwerp. Vandaar mijn eerdere opmerking over ERE certificaten. Op basis van een paar zinnen heeft Claude dat hier (correct) geïmplementeerd. Door zelf uit te zoeken hoe die certificaten in Nederland (gaan) werken en hoe dat in de codebase zou passen. Uiteindelijk heb ik natuurlijk wel goedkeuring gegeven op een plan maar het plan was eigenlijk gewoon in één keer acceptabel.

Als ik zo lees heb ik echt het idee dat je nauwelijks of niet met goede AI modellen/tools hebt gewerkt (Opus in VS code met een copilot licentie is overigens echt een totáál andere ervaring dan Claude Code kan ik je zeggen). Mijn ervaring is namelijk compleet anders. Als ik zaken fatsoenlijk voorleg, wordt het in veel gevallen ook fatsoenlijk uitgevoerd. Tools zoals Claude zullen je ook gewoon vragen stellen als je onduidelijk bent. En bij grotere changes kan je gewoon plannen laten maken en bij laten stellen als je niet tevreden bent.

Nu geeft @TobyW hierboven al aan dat iets als COBOL zeker nog steeds relevant is, maar er zijn wel meer dingen uit de vorige eeuw relevant. Wat dacht je van oude Fortran-code die nog moet worden onderhouden? Is daar geen plaats voor in een LLM omdat het oude meuk is?

Ok, voor COBOL misschien wel dan. Maar waarom zou Commodore nog relevant zijn?

Voel je vrij om mijn C64-voorbeeld aan de beste modellen te geven. De laatste keer dat ik dat probeerde kon ik maar 2 modellen vinden die een bevredigend antwoord konden geven, de rest gaf vol overtuiging een incorrect antwoord.

Ik geloof je dat het zo is. Tegelijkertijd is het zo dat 99% van de developers die taal ook niet kent en dus zal gaan gokken.

TobyW schreef op zaterdag 28 februari 2026 @ 18:23:
Er is een wezenlijk verschil tussen het bedenken van een algoritme en het implementeren hiervan in een specifieke programmeertaal. Ja, uiteraard kun je een algoritme uitleggen aan AI zodat die hem kan implementeren - maar je hebt dan nog steeds een mens nodig om a) het algoritme te bedenken en b) deze op een manier te specificeren dat AI deze werkend en efficiënt implementeert. Het enige wat de AI dus overneemt is het mechanische gedeelte van code in de computer kloppen. Afhankelijk van hoeveel iteratieslagen nodig zijn om te AI te laten begrijpen wat je wilt hebben hoeft dat helemaal niet sneller te zijn dan de code zelf in te voeren. AI biedt dan alleen een voordeel als je de syntax van de programmeertaal niet goed kent.

Hoe goed een LLM met COBOL is, is trouwens zeker relevant! Ik weet niet of je het gemist hebt, maar het aandeel van IBM is 13% in waarde gedaald na de aankondiging dat Claude Code ook met COBOL overweg kan.

Daar zit zeker een groot verschil tussen. Je kan met moderne AI met beide manieren werken.

Net zoals je met een andere developer kan samenwerken kan je ook met een tool als Claude samenwerken om samen tot een goed resultaat te komen. Claude is echt niet meer de domme AI van vorig jaar. Over het algemeen doet Claude best goed zijn huiswerk bij complexe vragen. Als het iets niet weet, zal het over het algemeen een grondige websearch op poten zetten om meer over het onderwerp te weten te komen.

Als er dan niets over het onderwerp te vinden is.. dan is er een punt. Maar dan zou je collega developer zonder context evengoed ook een probleem hebben.

[ Voor 28% gewijzigd door Glashelder op 28-02-2026 19:40 ]

[RayNbow]

Glashelder schreef op zaterdag 28 februari 2026 @ 19:30:
[...]

Dit kunnen we toch gewoon testen? Of vertrouwen we het werk van mensen wel blindelings?

Ik vertrouw het werk van mensen niet blindelings, maar ik werk in ieder geval niet met mensen die complete onzin verkondigen op het moment dat ze iets niet weten. In plaats daarvan geven ze aan dat ze iets niet weten.

En een tool als Claude doet gewoon een ‘explore’ sessie op internet als het niet genoeg weet over een onderwerp.

En dan zijn we weer bij het begin wat ik oorspronkelijk aanhaalde: wat als die informatie niet op het internet staat?

Ok, voor COBOL misschien wel dan. Maar waarom zou Commodore nog relevant zijn?

Geen idee... misschien omdat er sinds vorig jaar weer nieuwe Commodores worden verkocht?

Ik geloof je dat het zo is. Tegelijkertijd is het zo dat 99% van de developers die taal ook niet kent en dus zal gaan gokken.

Het verschil is dat een persoon die de taal niet kent en gaat gokken dat ook laat blijken, i.p.v. vol overtuiging een antwoord geeft zoals een LLM geconditioneerd is te doen.

[Glashelder]

RayNbow schreef op zaterdag 28 februari 2026 @ 20:52:
[...]

Ik vertrouw het werk van mensen niet blindelings, maar ik werk in ieder geval niet met mensen die complete onzin verkondigen op het moment dat ze iets niet weten. In plaats daarvan geven ze aan dat ze iets niet weten.

Als Claude iets niet kan vinden, dan zegt ie dat ook gewoon. En jij kent ze misschien niet, maar ik heb wel degelijk met mensen gewerkt die altijd een antwoord geven, ook al weten ze het niet. Sterker nog, ik heb met een collega gewerkt die live in een meeting mij tegensprak omdat wat ik zei 'niet juist was', terwijl het een quote was uit Microsoft documentatie. Die klopte niet was het vervolgantwoord

Dus geloof mij, die mensen bestaan en er zijn er veel teveel van. Ik denk dat we gemeen hebben dat we een hekel hebben aan dat soort mens.

En dan zijn we weer bij het begin wat ik oorspronkelijk aanhaalde: wat als die informatie niet op het internet staat?

Zoals ik al zei: dan is de situatie tussen LLM of menselijke developer hetzelfde. Je zult dan afdoende uitleg moeten geven.

Geen idee... misschien omdat er sinds vorig jaar weer nieuwe Commodores worden verkocht?

Ok cool. Komt vanzelf trainingsdata voor dan

Het verschil is dat een persoon die de taal niet kent en gaat gokken dat ook laat blijken, i.p.v. vol overtuiging een antwoord geeft zoals een LLM geconditioneerd is te doen.

Aanname. Genoeg mensen zullen gewoon wat gokken.

Maar zoals ik al zei: als je met Claude netjes met de planmodus werkt dan zal hij gewoon vertellen waar hij onzekerheden ziet. En je moet testen..of code nou door mensen is gemaakt of AI.

[Tarkin]

Het is een deel zwart wit denken, we gaan ervan uit dat er enkel perfecte coders zijn (hint, die zijn er veel minder dan je denkt) en dat een llm enkel hallucineert. Beiden zijn gewoon niet correct en blijven vasthouden aan de methodes van 2 jaar geleden. Helpt niet naar de toekomst.

Ik zou niets liever zien als discussie topics over de verschillende modellen/aanbieders en alle voors en tegens van verschillende methodes.

Helaas blijven we hier op het forum hangen in "het hallucineert enkel..., het maakt je alleen maar dommer,... in onze tijd moesten we wel nadenken voor x..."

[Glashelder]

Tarkin schreef op zaterdag 28 februari 2026 @ 21:08:

Helaas blijven we hier op het forum hangen in "het hallucineert enkel..., het maakt je alleen maar dommer,... in onze tijd moesten we wel nadenken voor x..."

Helemaal mee eens. Als iemand die veel gebruik maakt van in dit geval Claude heb ik echt het idee te communiceren met mensen die nooit meer gebruikt hebben dan een beetje Copilot en die ervaring dan doortrekken naar alle AI code tools.

[RayNbow]

Glashelder schreef op zaterdag 28 februari 2026 @ 21:00:
[...]

Zoals ik al zei: dan is de situatie tussen LLM of menselijke developer hetzelfde. Je zult dan afdoende uitleg moeten geven.

Behalve dat misschien de menselijke developer al tijdens het solicitatieproces geselecteerd is op de kennis die deze al heeft? Wat je dus aangeeft is dat we eerst LLM's een volledige opleiding moeten geven in het werkgebied?

Ok cool. Komt vanzelf trainingsdata voor dan

Als je in een losse sessie een LLM een specifieke vraag stelt over de beperkingen van C64 BASIC (of elke andere BASIC van dezelfde tijd; ze komen immers van Microsoft vandaan), dan zijn de meeste modellen op de hoogte over hoe C64 BASIC zich gedraagt m.b.t. variabelen. Dat wil zeggen dat de kennis die nodig is om de vraag over mijn codevoorbeeld te beantwoorden al gescrapet is.

Het probleem is dat het niet is voorgekauwd. Je moet bij de meeste taalmodellen al sterk hinten naar het antwoord in je vraagstelling, anders komt het niet tot het goede antwoord... kind of defeats the purpose.

---

Edit: als experiment heb ik om de taalmodellen wat hulp te geven een multiple choice versie geprobeerd:

What is the output of this Commodore 64 Basic program?

10 SIZEX=4
20 SIZEY=5
30 SIZEZ=5
40 VOL=SIZEX*SIZEY*SIZEZ
50 PRINTVOL

A: 100
B: 125
C: SYNTAX ERROR
D: Other, please specify

Waar nu sommige modellen eerst een incorrect numeriek antwoord gaven, zijn er nu modellen die gokken dat er sprake is van een syntaxfout.

[ Voor 16% gewijzigd door RayNbow op 01-03-2026 08:42 ]

[Glashelder]

RayNbow schreef op zondag 1 maart 2026 @ 08:13:
[...]

Behalve dat misschien de menselijke developer al tijdens het solicitatieproces geselecteerd is op de kennis die deze al heeft? Wat je dus aangeeft is dat we eerst LLM's een volledige opleiding moeten geven in het werkgebied?

Volgens mij heb ik al een aantal keer benoemd dat doucmentatie (readme.md of claude.md in het geval van Claude) files belangrijk zijn. Jij noemt het een ‘volledige opleiding’, maar volgens mij heb je gewoon geen idee hoe deze modellen werken? Deze modellen zijn contextloos en alles wat niet in de trainingsdata zit zul je elke keer weer mee moeten sturen met elk verzoek. Gelukkig voor jou als gebruiker doet de tooling rondom het model dat elke keer weer netjes voor je.

Die volledige opleiding komt neer op het lezen van de .md files en analyseren van je codebase waar nodig. Dat is een minutenproces in tegenstelling tot mensen die daar weken dan wel maanden voor nodig hebben. En die LLM doet die opleiding iedere keer weer opnieuw als de context gereset is.

Als je in een losse sessie een LLM een specifieke vraag stelt over de beperkingen van C64 BASIC (of elke andere BASIC van dezelfde tijd; ze komen immers van Microsoft vandaan), dan zijn de meeste modellen op de hoogte over hoe C64 BASIC zich gedraagt m.b.t. variabelen. Dat wil zeggen dat de kennis die nodig is om de vraag over mijn codevoorbeeld te beantwoorden al gescrapet is.

En menselijke developers hebben dit allemaal zelf verzonnen ofzo? Die hebben deze kennis toch ook gewoon ergens vandaan? Wat is het verschil?

Het probleem is dat het niet is voorgekauwd. Je moet bij de meeste taalmodellen al sterk hinten naar het antwoord in je vraagstelling, anders komt het niet tot het goede antwoord... kind of defeats the purpose.

Onzin.

Ik heb je eerder al een voorbeeld gegeven waarbij Claude hier naar aanleiding van een prompt van een paar zinnen in staat was om zelfstandig op internet op te zoeken wat ERE certificaten zijn, hoe ze berekend moeten worden, en hoe dat vervolgens geïmplementeerd moest worden in een laadapp.

Je zit een beetje vast in het verleden.

[Glashelder]

RayNbow schreef op zondag 1 maart 2026 @ 08:13:
Waar nu sommige modellen eerst een incorrect numeriek antwoord gaven, zijn er nu modellen die gokken dat er sprake is van een syntaxfout.

Uit nieuwsgierigheid, maar wat is het correcte antwoord?

[TobyW]

Als ik het in een C64 online emulator intoets, dan komt er 125 uit. Als ik het me goed herinner is de toegestane lengte van een variabelennaam nogal kort, dus het zal maar één variabele zijn die twee keer met zichzelf vermenigvuldigd wordt. C64 Basic was echt een gedrocht, het was een vooruitgang voor me toen ik een oude CP/M machine met Microsoft Basic kreeg.

Ik denk dat jullie allebei correcte punten hebben. De AI code assist tools zijn veel krachtiger geworden, en als ze a) duidelijke instructies krijgen en b) alle informatie tot hun beschikking hebben, dan kunnen ze heel snel tot het gewenste doel leiden. Maar er zijn ook situaties waarbij je echt sneller je doel bereikt wanneer je zelf programmeert. Mijn ervaring is inderdaad beperkt tot Copilot/ChatGPT/Gemini, met Claude Code heb ik nog niet gewerkt.

[RayNbow]

Glashelder schreef op zondag 1 maart 2026 @ 08:50:
[...]

Uit nieuwsgierigheid, maar wat is het correcte antwoord?

Waarom stel je die vraag niet aan Claude?

[Glashelder]

RayNbow schreef op zondag 1 maart 2026 @ 10:22:
[...]

Waarom stel je die vraag niet aan Claude?

Ik ga er door jou vanuit dat het antwoord fout is, dus ik wil jouw antwoord vergelijken met die van Claude.

Nog steeds blijf ik er bij dat het allemaal irrelevant is om te bewijzen waarom developers relevant zullen blijven voor het kloppen van code in de toekomst.

Maar ik heb Claude even gevraagd:

code:

> Wat does this Commondore64 script do? If you don't know you can say it: 10 SIZEX=4
  20 SIZEY=5
  30 SIZEZ=5
  40 VOL=SIZEX*SIZEY*SIZEZ
  50 PRINTVOL

● It calculates and prints the volume of a rectangular box.

  - SIZEX=4, SIZEY=5, SIZEZ=5 — defines the three dimensions
  - VOL=SIZEX*SIZEY*SIZEZ — calculates 4 × 5 × 5 = 100
  - PRINTVOL — prints the result (Commodore BASIC allows omitting the space; the interpreter reads this as PRINT VOL)

  Output: 100

> A simulator says its 125

● You're right — I made a multiplication error. Let me redo it:

  4 × 5 × 5 = 100

  That's still 100. Are you sure the simulator isn't using different values, or could there be additional code? 125 would be 5 × 5 × 5, which suggests SIZEX might be
   read as 5 instead of 4.

> Look up if there might be some weird quirks with commondore64 basic

● Web Search("Commodore 64 BASIC variable name length limit quirks")
  ⎿  Did 1 search in 7s

● That explains it. Commodore 64 BASIC only recognizes the first two characters of variable names. So:

  - SIZEX → SI
  - SIZEY → SI
  - SIZEZ → SI

  All three are the same variable. Each assignment overwrites the previous one:

  10 SI = 4
  20 SI = 5   ← overwrites
  30 SI = 5   ← overwrites
  40 VO = SI * SI * SI = 5 × 5 × 5 = 125
  50 PRINT VO

  Output: 125. The simulator is correct.

  To make the script work as intended, you'd need distinct two-character prefixes, e.g. SX, SY, SZ.

  Sources:
  - https://www.c64-wiki.com/wiki/Variable
  - https://odd.blog/2019/02/06/oddities-of-c64-basic/

> Can you create a claude.md in C:\Users\<>\Documents\source\Commondore for future sessions?

● Read 1 file (ctrl+o to expand)

● Write(~\Documents\source\Commondore\CLAUDE.md)
  ⎿  Wrote 8 lines to ..\..\Documents\source\Commondore\CLAUDE.md
      1 # Commodore 64 BASIC
      2
      3 ## Key quirks
      4
      5 - **Variable names are only 2 characters long.** The interpreter only reads the first two characters. `SIZEX`, `SIZEY`, `SIZEZ` all resolve to `SI` an
        d overwrite each other. Use distinct two-character prefixes (e.g. `SX`, `SY`, `SZ`).
      6 - **Reserved words inside variable names cause syntax errors.** For example, `MAINTOTAL` contains `INT`, and `BORDER` contains `OR`. The interpreter w
        ill reject these.
      7 - **Type suffixes distinguish variables.** `CO`, `CO%` (integer), and `CO$` (string) are three separate variables.
      8 - **`PRINT` can be written without a space** before the variable (e.g. `PRINTVOL` is interpreted as `PRINT VOL`).

● Created C:\Users\<>\Documents\source\Commondore\CLAUDE.md with the key quirks we discovered — the 2-character variable name limit, reserved word
  conflicts, type suffixes, and the PRINT spacing behavior.

Opvolgende sessie:

code:

> Wat does this Commondore64 script do? If you don't know you can say it: 10 SIZEX=4
    20 SIZEY=5
    30 SIZEZ=5
    40 VOL=SIZEX*SIZEY*SIZEZ
    50 PRINTVOL

● This script tries to calculate the volume of a box (4 × 5 × 5 = 100), but it has a bug due to a classic Commodore 64 quirk.

  What it looks like it does:
  - Set width to 4, height to 5, depth to 5
  - Calculate volume (4 × 5 × 5 = 100)
  - Print the result

  What it actually does:

  Variable names in C64 BASIC are only 2 characters long. The interpreter ignores everything after the first two characters, so:

  ┌──────┬───────────────────────┬──────────────────────────┐
  │ Line │       You wrote       │         C64 sees         │
  ├──────┼───────────────────────┼──────────────────────────┤
  │ 10   │ SIZEX=4               │ SI=4                     │
  ├──────┼───────────────────────┼──────────────────────────┤
  │ 20   │ SIZEY=5               │ SI=5 (overwrites!)       │
  ├──────┼───────────────────────┼──────────────────────────┤
  │ 30   │ SIZEZ=5               │ SI=5 (overwrites again!) │
  ├──────┼───────────────────────┼──────────────────────────┤
  │ 40   │ VOL=SIZEX*SIZEY*SIZEZ │ VO=SI*SI*SI              │
  ├──────┼───────────────────────┼──────────────────────────┤
  │ 50   │ PRINTVOL              │ PRINT VO                 │
  └──────┴───────────────────────┴──────────────────────────┘

  All three "different" variables (SIZEX, SIZEY, SIZEZ) resolve to the same variable SI. After line 30, SI is 5.

  So the calculation becomes 5 × 5 × 5 = 125, not 100.

  Line 50 works correctly though — PRINTVOL is parsed as PRINT VO (since PRINT doesn't need a space before the variable).

  The fix would be to use distinct two-character prefixes:

  10 SX=4
  20 SY=5
  30 SZ=5
  40 VO=SX*SY*SZ
  50 PRINTVO

  This would correctly print 100.

Hier kan je dus zien hoe je AI kan bijsturen door instructies in een repo te zetten. Dat hoef je maar eenmalig te doen.

Hoe vaak mensen zich wel niet aan dezelfde steen stoten daarentegen

[RayNbow]

Glashelder schreef op zondag 1 maart 2026 @ 08:49:
Die volledige opleiding komt neer op het lezen van de .md files en analyseren van je codebase waar nodig. Dat is een minutenproces in tegenstelling tot mensen die daar weken dan wel maanden voor nodig hebben.

Hoeveel minuten heb jij nodig om een heel fysiek boek in .md om te zetten?

En menselijke developers hebben dit allemaal zelf verzonnen ofzo? Die hebben deze kennis toch ook gewoon ergens vandaan? Wat is het verschil?

Dat is niet het punt. De benodigde informatie zit in het taalmodel, maar wordt blijkbaar niet gebruikt om tot een correct antwoord te komen. Dit gedrag lijkt op het vooral leren van voorbeeldtentamens en dan falen als er op een daadwerkelijk tentamen een vraag voorbij komt die niet exact op eerdere vragen lijkt, maar wel over de stof gaat.

Ik heb je eerder al een voorbeeld gegeven waarbij Claude hier naar aanleiding van een prompt van een paar zinnen in staat was om zelfstandig op internet op te zoeken wat ERE certificaten zijn, hoe ze berekend moeten worden, en hoe dat vervolgens geïmplementeerd moest worden in een laadapp.

Ja, en ik heb meerdere keren aangegeven dat niet alles op het internet staat?

Ja, het is mooi als een tool zelf extra relevante tekst van een externe bron kan plukken, want dat helpt als in die tekst het antwoord staat.

[RayNbow]

Glashelder schreef op zondag 1 maart 2026 @ 10:37:
[...]

Ik ga er door jou vanuit dat het antwoord fout is, dus ik wil jouw antwoord vergelijken met die van Claude.

Nog steeds blijf ik er bij dat het allemaal irrelevant is om te bewijzen waarom developers relevant zullen blijven voor het kloppen van code in de toekomst.

Maar ik heb Claude even gevraagd:

code:

> Wat does this Commondore64 script do? If you don't know you can say it: 10 SIZEX=4
  20 SIZEY=5
  30 SIZEZ=5
  40 VOL=SIZEX*SIZEY*SIZEZ
  50 PRINTVOL

● It calculates and prints the volume of a rectangular box.

  - SIZEX=4, SIZEY=5, SIZEZ=5 — defines the three dimensions
  - VOL=SIZEX*SIZEY*SIZEZ — calculates 4 × 5 × 5 = 100
  - PRINTVOL — prints the result (Commodore BASIC allows omitting the space; the interpreter reads this as PRINT VOL)

  Output: 100

Maar je ziet dus hier wel dat Claude geconditioneerd is om vol vertrouwen een antwoord te geven.

Verder ben ik benieuwd wat Claude zonder bestaande context voor antwoord had gegeven op deze vraag:

What are the limitations of variables in Commodore 64 Basic?

Doet Claude daar ook een websearch voor of put het uit z'n bestaande trainingset?

[Glashelder]

RayNbow schreef op zondag 1 maart 2026 @ 10:48:
[...]

Maar je ziet dus hier wel dat Claude geconditioneerd is om vol vertrouwen een antwoord te geven.

Het is ook gewoon een obscure bug. Er zullen genoeg devers zijn die je ook gewoon vol vertrouwen een antwoord geven want wie verzint zo'n limitatie?

Verder ben ik benieuwd wat Claude zonder bestaande context voor antwoord had gegeven op deze vraag:

> What are the limitations of variables in Commodore 64 Basic?

code:

● Here are the key limitations of variables in Commodore 64 BASIC (V2):

  Variable Name Recognition
  - Only the first two characters of a variable name are significant. SCORE and SC refer to the same variable. TOTAL and TOKEN would also collide.
  - Variable names must start with a letter and can contain letters and digits.
  - Names cannot contain BASIC keywords (e.g., TO, IF, OR), even as substrings — STORE is invalid because it contains TO and OR.

  Data Types (3 types only)
  - Floating-point (default): A, X1 — 5-byte MBF (Microsoft Binary Format), ~9 digits of precision.
  - Integer: A%, X1% — 16-bit signed, range -32768 to 32767. Despite being smaller, integers are actually slower than floats because they get converted to/from float
   internally for math.
  - String: A$, X1$ — max 255 characters per string.

  Arrays
  - Default dimension is 0–10 (11 elements) if not explicitly DIM'd.
  - Maximum of 255 elements per dimension when using DIM.
  - Arrays can have multiple dimensions, but total size is limited by available RAM.

  Memory & Quantity
  - No fixed limit on the number of variables, but all variables, arrays, and strings share the ~38K of free RAM with program code.
  - Each simple variable entry takes 7 bytes (2 name bytes + 5 value bytes).
  - Strings are stored in a string heap that grows downward in memory, and garbage collection can cause long pauses when many strings exist.

  No Local Scope
  - All variables are global. There are no local variables, no scoping, and GOSUB routines share the same variable namespace.

  Other Quirks
  - No constants — every "constant" is a variable or literal.
  - No structured types (records/structs).
  - DEF FN user functions are limited to single-line numeric expressions only.

Doet Claude daar ook een websearch voor of put het uit z'n bestaande trainingset?

Zo te zien geen web searches. De kennis zit dus inderdaad in het model. Wat dat betreft is het net een mens af en toe. Hoe vaak maken mensen wel geen fouten terwijl de kennis echt wel ergens diep in het brein zit? De bekende 'oja momentjes'.

Het is niet perfect, dat weten we. Maar voor alledaagse zaken met actuele talen is het prima bruikbaar en dan produceert het code in een veelvoud van de snelheid waarin een menselijke developer dat kan. Als je dan ook je testprocessen goed op orde hebt, dan ben je spekkoper als organisatie. Het blijft mijn persoonlijke mening dat daarom mensen het af gaan leggen. Misschien niet morgen, maar het komt er echt wel aan.

[RayNbow]

TobyW schreef op zondag 1 maart 2026 @ 10:18:
C64 Basic was echt een gedrocht, het was een vooruitgang voor me toen ik een oude CP/M machine met Microsoft Basic kreeg.

C64 Basic was ook van Microsoft, maar een oude variant. Zo heeft bijv. Basic op de Apple II (ook van Microsoft) dezelfde beperkingen m.b.t. variabelenamen.

[ Voor 3% gewijzigd door RayNbow op 01-03-2026 11:04 ]

[RayNbow]

Glashelder schreef op zondag 1 maart 2026 @ 10:57:
want wie verzint zo'n limitatie?

Mensen die te maken hebben met limitaties van machines. Zo had de Apple II maar 4 KB aan geheugen.

[TobyW]

Interessant om te zien hoe dit werkt en dat je een lokale kennisbank kunt opbouwen.

Het is niet perfect, dat weten we. Maar voor alledaagse zaken met actuele talen is het prima bruikbaar en dan produceert het code in een veelvoud van de snelheid waarin een menselijke developer dat kan. Als je dan ook je testprocessen goed op orde hebt, dan ben je spekkoper als organisatie. Het blijft mijn persoonlijke mening dat daarom mensen het af gaan leggen. Misschien niet morgen, maar het komt er echt wel aan.

Ik ben het hier gedeeltelijk mee eens, maar je hebt nog steeds iemand nodig die het bestek/programma van eisen kan opstellen, en hoe goed de uiteindelijke software het doet zal sterk hiervan afhangen. Dat betekent dat de rol van een softwareontwikkelaar verandert in richting systems engineering.

Maar hoe zit het dan eigenlijk met intellectueel eigendom? In Duitsland zijn er al rechterlijke uitspraken geweest dat afbeeldingen of muziek die door AI is gegenereerd niet beschermd is. Hoe zit het met code die afgeleid is van code onder de GPL?

[ Voor 13% gewijzigd door TobyW op 01-03-2026 15:14 ]

[RayNbow]

TobyW schreef op zondag 1 maart 2026 @ 15:12:
In Duitsland zijn er al rechterlijke uitspraken geweest dat afbeeldingen of muziek die door AI is gegenereerd niet beschermd is. Hoe zit het met code die afgeleid is van code onder de GPL?

Al ergens in 2011 of zo toen ik in een Europees FP7-project zat hoorde ik dat onder Duitse wetgeving een getraind model wordt gezien als een afgeleid werk. Het is dan ook niet verrassend als de uitvoer uit hedendaagse taalmodellen daardoor ook als afgeleid werk wordt gezien. M.a.w.: op z'n minst rust het oorspronkelijke auteursrecht op de uitvoer.

[Basic2me]

"jij moet de woorden leren voor dingen die je al doet"

Als het goed is moet ik over twee weken fatsoenlijk met jullie kunnen praten.

[ Voor 61% gewijzigd door Basic2me op 02-03-2026 08:51 ]

[MueR]

Basic2me schreef op maandag 2 maart 2026 @ 08:20:
"jij moet de woorden leren voor dingen die je al doet"

Als het goed is moet ik over twee weken fatsoenlijk met jullie kunnen praten.

Geen idee wat de relevantie van je youtube link is bij deze post, maar ik zal maar vast zeggen dat als je een LLM aan de site gaat hangen, je snel een ban krijgt.

[Lethalis]

Microsoft vreest tekort aan ervaren programmeurs door opkomst AI:

https://www.bnr.nl/nieuws...grammeurs-door-opkomst-ai

Guess I'm safe after all

[Woy]

Overduidelijke AI reacties worden hier dus verwijderd!

[Standeman]

Lethalis schreef op dinsdag 3 maart 2026 @ 19:42:
Microsoft vreest tekort aan ervaren programmeurs door opkomst AI:

https://www.bnr.nl/nieuws...grammeurs-door-opkomst-ai

Guess I'm safe after all

Ik geloof idd dat we wel goed zitten.

https://www.citadelsecuri...obal-intelligence-crisis/

11% groei in developer vacatures.

[ Voor 3% gewijzigd door Standeman op 05-03-2026 18:20 ]

[marapuru]

Vraag me wel af hoe de beroepen rondom de developers zich gaan ontwikkelen. Denk PO/PM/SM/UX/Analyse…

[TobyW]

Na deze en andere discussies heb ik vorige week een Claude Pro abonnement afgesloten en ben daar een beetje mee aan het spelen. Ik ben eerlijk gezegd behoorlijk onder de indruk. Ik ben iets aan het doen wat niet helemaal mainstream is (puntenwolken viewer in Rust met macroquad/miniquad, documentatie is erg mager) en dat gaat echt heel goed. Je vliegt alleen door de tokens heen, zeker met Opus maar ook met Sonnet. Als je er heel de dag door mee zou willen werken, dan is het Pro abonnement zeker niet voldoende.

[RayNbow]

TobyW schreef op woensdag 11 maart 2026 @ 11:15:
puntenwolken viewer

Over puntenwolken gesproken... zijn er al taalmodellen die een juiste uitleg kunnen geven hoe de buffer in LASzips ArithmeticEncoder werkt? Het heeft mij ooit veel moeite gekost om dat stuk code van Martin Isenburg te doorgronden.

[Glashelder]

TobyW schreef op woensdag 11 maart 2026 @ 11:15:
Na deze en andere discussies heb ik vorige week een Claude Pro abonnement afgesloten en ben daar een beetje mee aan het spelen. Ik ben eerlijk gezegd behoorlijk onder de indruk. Ik ben iets aan het doen wat niet helemaal mainstream is (puntenwolken viewer in Rust met macroquad/miniquad, documentatie is erg mager) en dat gaat echt heel goed. Je vliegt alleen door de tokens heen, zeker met Opus maar ook met Sonnet. Als je er heel de dag door mee zou willen werken, dan is het Pro abonnement zeker niet voldoende.

Je zult naar Pro Max moeten of Teams met een premium seat. In de praktijk ben daarmee nog maar eenmaal tegen de limiet aangelopen maar daarvoor moest ik wel meerdere Claude's aan het werk houden

[TobyW]

RayNbow schreef op woensdag 11 maart 2026 @ 13:09:
[...]
Over puntenwolken gesproken... zijn er al taalmodellen die een juiste uitleg kunnen geven hoe de buffer in LASzips ArithmeticEncoder werkt?

You've got mail.

Glashelder schreef op woensdag 11 maart 2026 @ 13:11:
[...]
Je zult naar Pro Max moeten of Teams met een premium seat. In de praktijk ben daarmee nog maar eenmaal tegen de limiet aangelopen maar daarvoor moest ik wel meerdere Claude's aan het werk houden

Voor nu houd ik het bij Pro. Ik ben nu bijv. met iets bezig waar de uitleg mij meer moeite zou kosten dan het zelf programmeren. Ik ben wel benieuwd naar jou ervaring, wat werkt beter? Iteratief functionaliteit toevoegen, of proberen één goede specificatie te schrijven en hem daarop los te laten?

[Glashelder]

Om eerlijk te zijn heb ik Claude nog nooit aan het werk gezet met een volledige specificatie voor een nieuwe app.

Ik gebruik Claude momenteel voornamelijk voor appjes/POC's die nog niet goed uitgedacht zijn. Een iteratief proces past dan veel beter. Evengoed groeien sommige van deze POC's nu wel uit tot productie apps. Uiteraard besteed ik daarbij wel veel aandacht aan het sturen van Claude richting oplossingen die secure zijn. Het gaat hier wel om apps waarbij we geen miljoenen gebruikers verwachten dus aan efficiency wordt wat minder aandacht besteed.

Ik geloof ook niet zo in een volledige specificatie vanaf scratch. Dat neigt naar waterval, en dat hebben we toch juist achter ons gelaten? Natuurlijk probeer je vanaf scratch wel gewoon een goede fundering op te laten zetten wat fatsoenlijk uitgebouwd kan worden, maar dat wil niet zeggen dat na een Claude stamp sessies alles erin moet zitten. Wat mij betreft zit hier weinig verschil met ontwikkelen in het pre-AI tijdperk: vrijwel altijd wil men dat het er toch wat anders uit ziet dan gedacht OF moet het anders werken dan gedacht omdat het originele concept gewoon niet helemaal goed is uitgedacht.

Wat dat betreft geldt hetzelfde als met waterval: hoe meer je al klaar hebt, des te meer werk is het om aanpassingen achteraf te doen als je zaken anders wilt. Met Claude kost je dat gewoon tokens.

[TobyW]

Daar heb je gelijk in. Het is inderdaad makkelijker om kleine stukken te bouwen, te testen en af te vinken en dan door te gaan naar het volgende.

[RayNbow]

TobyW schreef op woensdag 11 maart 2026 @ 15:21:
[...]

You've got mail.

Ja, m'n inbox puilt uit?

(Maar als je bedoelt dat ik een bericht van je hebt, dan heb ik die niet ontvangen.)

[AW_Bos]

SiErRa schreef op maandag 2 februari 2026 @ 11:42:
Ah een real-life vibecoder.

Als ervaren developer vind ik het echt een doodeng fenomeen. Niet vanwege mijn eigen toekomst ofzo, maar mee vanwege de gevolgen:

Je bent als vibecoder toch een beetje een olifant in een porseleinkast.
Het ding met AI is dat je de output die je terugkrijgt niet voor waarheid moet aannemen, want is het gegenereerd en het kan best fout zijn.

Dit dus. Iedereen die ik in mijn omgeving maar een beetje zie aankloten met AI, zeg ik het volgende:
"AI is een middel, en geen doel, maar dus maar enkel een tool!"

Je zult altijd wel moeten weten wat je aan het doen bent! En pas daarop dan je vragen aan die je aan de LLM stelt.

Daarnaast heb ik wel wat leuke snippets gebouwd met bewuste vibe-coding, denk aan een speciale parser extentie voor CKeditor, een rechtensysteem of een Docker container met een Python-script wat liftinformatie van ProRail via ZeroMQ ontvangt en naar een URL stuurt (API wat je zelf mag bouwen ) .

Maar qua licenties ben ik wel weer zo dat ik weet dat er officieel geen auteursrechten op zitten, en dus krijgen die vaak een eervol plaatsje op GitHub.

[ Voor 22% gewijzigd door AW_Bos op 16-03-2026 23:17 ]

[eborn]

Waar ik vooral benieuwd naar ben is hoe mensen en bedrijven de bestaande development- en support functies uitdagend en interessant houden. Ik las eerder in dit topic al zo iets van: "een echte developer ziet meteen of code goed is". Dat is zeker niet het geval. Een van de lastigste punten bij samenwerking is het inlezen in code die je niet zelf (of lang geleden) geschreven hebt. Goede developers hebben tijdens de bouw een soort mentaal model van de applicatie in hun hoofd en weten dus inderdaad hoe zaken samenwerken. AI vervangt dit mentale model nu grotendeels, waardoor het voor een ontwikkelaar allemaal 'foreign code' wordt.

Als uiteindelijk de development functies enkel nog de AI-slop mogen oplossen c.q. met AI nieuwe slop mogen introduceren om bugs en klanten feedback te verwerken, dan verwacht ik dat veel goede ontwikkelaars hun heil in andere functies gaan zoeken. Maar misschien is dat ook de volgende stap.

[Glashelder]

@eborn wat ik zie is dat er eindelijk tijd is om applicaties te bouwen die compleet zijn op het gebied van features, security, usability... Hoe vaak maak je wel niet mee dat voor veel dingen die je eigenlijk zou willen bouwen of fixen geen tijd en budget is, want te duur of niet belangrijk? Met tools zoals Claude speelt dat veel minder een rol.

Feitelijk wordt je als developer veel meer tester dan echt developer. Als dat echt je ding niet is.. dan ga je het nog zwaar krijgen.

[eborn]

Glashelder schreef op woensdag 25 maart 2026 @ 10:36:
@eborn wat ik zie is dat er eindelijk tijd is om applicaties te bouwen die compleet zijn op het gebied van features, security, usability... Hoe vaak maak je wel niet mee dat voor veel dingen die je eigenlijk zou willen bouwen of fixen geen tijd en budget is, want te duur of niet belangrijk? Met tools zoals Claude speelt dat veel minder een rol.

Ik maak persoonlijk veel vaker mee dat er een applicatie staat waar initieel tijd in is gestoken, maar waar men daarna geen cent meer aan wil uitgeven aan onderhoud en optimalisaties. Ook omdat je dan opnieuw een test-traject in moet en 'het nu eenmaal draait'. Het zou een enorme verbetering zijn als AI daar een aantal handjes kan toevoegen. Helemaal als er straks nog veel meer losse applicaties ontwikkeld worden als greenfield projeten.

[TobyW]

Feitelijk wordt je als developer veel meer tester dan echt developer. Als dat echt je ding niet is.. dan ga je het nog zwaar krijgen.

Eens, het wordt meer specificaties schrijven en daarna verificatie en validatie uitvoeren. Dat wil je natuurlijk ook geautomatiseerd doen, dus dat zal nog belangrijker worden, net als het kunnen begrijpen van AI code om de bugs te fixen die de AI zelf niet gefikst krijgt. Ik kreeg maandag ook nog allemaal wilde voorstellen van Claude, terwijl de fix heel simpel was.

[Marc3l]

Glashelder schreef op woensdag 25 maart 2026 @ 10:36:
@eborn

Feitelijk wordt je als developer veel meer tester dan echt developer. Als dat echt je ding niet is.. dan ga je het nog zwaar krijgen.

Dat ben ik nu al, hoe weinig code ik zelf nog schrijf. Als developer ben je nu de manager, je stuurt de developers (a.i.) aan. Voor mijn werk noem ik dit niet vibe-coden, ik doe het in kleine stapjes, ik weet wat er staat/wat het doet als hij iets heeft gemaakt. Dus niet alleen het werkt wel/niet.

Dus denk ook dat de developer een uitstervend beroep is. Ik ben wel benieuwd hoe dat in de toekomst gaat. Als je nu programmeur bent en het gebruikt, dan kan je (als het goed is) de code lezen / weten wat hij maakt. Maar in de toekomst weten mensen niet meer (goed) wat het doet. Als de a.i, op een gegeven moment zo goed is, dan heeft het ontwikkelen tot programmeur ook geen zin meer lijkt mij. Alleen op den duur weet niemand goed meer wat het doet / wat de code doet 😛

Ik denk dat heel veel van web verschuift naar a.i., zoals traditioneel zoeken (Google Search enz.) en webshops, dat zit in de toekomst allemaal in a.i. agents.

[TobyW]

Marc3l schreef op zondag 26 april 2026 @ 09:50:
Ik denk dat heel veel van web verschuift naar a.i., zoals traditioneel zoeken (Google Search enz.) en webshops, dat zit in de toekomst allemaal in a.i. agents.

Ik merk het nu al bij mezelf, ik ben ook geneigd om dingen aan Claude te vragen i.p.v. via Google te zoeken en de diverse resultaten aan te klikken en door te kijken. Ik begrijp ook dat dit voor StackOverflow etc. een probleem vormt. We zullen op een gegeven moment ook zien dat, als er geen openbare discussies meer zijn, er ook geen trainingsmateriaal meer is en de kwaliteit van de antwoorden achteruit zal gaan. Alhoewel de "reasoning" modellen natuurlijk niet alleen stochastisch dingen voorspellen en als agent ook actuele API documentatie etc. kunnen bekijken om tot antwoorden te komen.

[gorgi_19]

Marc3l schreef op zondag 26 april 2026 @ 09:50:
[...]


Dat ben ik nu al, hoe weinig code ik zelf nog schrijf. Als developer ben je nu de manager, je stuurt de developers (a.i.) aan. Voor mijn werk noem ik dit niet vibe-coden, ik doe het in kleine stapjes, ik weet wat er staat/wat het doet als hij iets heeft gemaakt. Dus niet alleen het werkt wel/niet.

Dus denk ook dat de developer een uitstervend beroep is. Ik ben wel benieuwd hoe dat in de toekomst gaat. Als je nu programmeur bent en het gebruikt, dan kan je (als het goed is) de code lezen / weten wat hij maakt. Maar in de toekomst weten mensen niet meer (goed) wat het doet. Als de a.i, op een gegeven moment zo goed is, dan heeft het ontwikkelen tot programmeur ook geen zin meer lijkt mij. Alleen op den duur weet niemand goed meer wat het doet / wat de code doet 😛

Ik denk dat heel veel van web verschuift naar a.i., zoals traditioneel zoeken (Google Search enz.) en webshops, dat zit in de toekomst allemaal in a.i. agents.

Voorlopig kan AI wel prima code maken, documentatie doen, maar ik moet hem nog te vaak corrigeren, zeker op juistheid qua architectuur, testing principes, vertalingen naar businessrules, etc.
Hij gaat hard, maar vliegt af en toe nog geregeld uit de bocht, en is ook nog vaak kort door de bocht.
En sorry zeggen is die erg goed in.

Code schrijven doe ik ook tegenwoordig weinig; code reviewen, bijsturen, etc. des te meer.

TobyW schreef op zondag 26 april 2026 @ 20:09:
[...]

Ik merk het nu al bij mezelf, ik ben ook geneigd om dingen aan Claude te vragen i.p.v. via Google te zoeken en de diverse resultaten aan te klikken en door te kijken. Ik begrijp ook dat dit voor StackOverflow etc. een probleem vormt. We zullen op een gegeven moment ook zien dat, als er geen openbare discussies meer zijn, er ook geen trainingsmateriaal meer is en de kwaliteit van de antwoorden achteruit zal gaan. Alhoewel de "reasoning" modellen natuurlijk niet alleen stochastisch dingen voorspellen en als agent ook actuele API documentatie etc. kunnen bekijken om tot antwoorden te komen.

Klopt, wat is de meerwaarde van SO voor een ontwikkelaar? AI kan prima code maken. Ontwikkelaars die nog relatief junior zijn, geloven het en nemen de AI code over. Ontwikkelaars met meer ervaring corrigeren de AI, en krijgen daardoor betere code (hopelijk dan).

SO heeft hier geen rol meer in. Dat levert wel een ander probleem op. Hoe ontwikkelt iemand zichzelf nog verder, als je weinig feedback of correcties krijgt?

[ Voor 27% gewijzigd door gorgi_19 op 26-04-2026 21:51 ]

[Marc3l]

@TobyW ja, ik doe dat ook al, zoeken via ai. Maar producten, afbeeldingen of sorteren op datum nog wel via Google.
Wel denk ik dat openbare discussies zoals dit forum wel blijven bestaan, dat lijkt mij wel lastiger in de huidige agents.

@gorgi_19 daarom werk ik in kleine stapjes, ik controleer dan de code, commit het of weer corrigeren, dan en dan weer verder. Ook geef ik zoveel mogelijk context mee.
Niet alleen voor betere output, maar ook voor token gebruik. Lees veel geklaag over het snel door je tokens heen gaan, daar heb ik zelden last van.
SEO zal meer verschuiven naar GEO (Generative Engine Optimization)

[Lethalis]

gorgi_19 schreef op zondag 26 april 2026 @ 21:49:
[...]
Klopt, wat is de meerwaarde van SO voor een ontwikkelaar? AI kan prima code maken. Ontwikkelaars die nog relatief junior zijn, geloven het en nemen de AI code over. Ontwikkelaars met meer ervaring corrigeren de AI, en krijgen daardoor betere code (hopelijk dan).

SO heeft hier geen rol meer in. Dat levert wel een ander probleem op. Hoe ontwikkelt iemand zichzelf nog verder, als je weinig feedback of correcties krijgt?

De meerwaarde van Stack Overflow zit hem vooral in de momenten dat AI niet werkt en alleen maar met suggesties komt waar je niets aan hebt.

Probleem is alleen dat het voor Stack Overflow straks niet meer nuttig is om te blijven draaien, omdat ze te weinig bezoekers krijgen. Dus ik verwacht eerder dat we ouderwets op specifieke fora of sub reddits uit zullen komen om informatie te vinden waar AI (nog) niet op getraind is.

[Lethalis]

Marc3l schreef op zondag 26 april 2026 @ 09:50:
[...]
Dat ben ik nu al, hoe weinig code ik zelf nog schrijf. Als developer ben je nu de manager, je stuurt de developers (a.i.) aan. Voor mijn werk noem ik dit niet vibe-coden, ik doe het in kleine stapjes, ik weet wat er staat/wat het doet als hij iets heeft gemaakt. Dus niet alleen het werkt wel/niet.

Ik gebruik AI in principe op 2 manieren:

1. Als alternatief voor een zoekmachine om even snel iets op te zoeken. De grap is dat ik nog wel vaak naar Google ga, maar hem in de AI mode zet (Gemini).

2. In agent mode, waarbij ik vanuit Visual Studio opdrachten geef aan Copilot en deze wijzigingen aan het project voorstelt die ik dan kan reviewen voordat ik ze accepteer.

Maar ik doe ook nog wel veel met de hand moet ik toegeven. Zeker in kritische code die toch al fragiel is.

Onderzoek heeft uitgewezen dat mensen ook vaker fouten maken als ze alleen maar in de "controleer modus" staan. Op de 1 of andere manier gaan onze hersenen dan in shut down in tegenstelling tot wanneer we echt iets aan het doen zijn.

Dus denk ook dat de developer een uitstervend beroep is.

Dat denk ik niet, want:

Ik ben wel benieuwd hoe dat in de toekomst gaat. Als je nu programmeur bent en het gebruikt, dan kan je (als het goed is) de code lezen / weten wat hij maakt. Maar in de toekomst weten mensen niet meer (goed) wat het doet.

Iemand zal altijd moeten weten wat het doet en er verantwoording over moeten kunnen afleggen. Een machine kun je de schuld niet geven, kun je niet aanklagen, enzovoorts

Niet dat het leuk is om overal verantwoordelijk voor te zijn, maar ja... dat is wel ons bestaansrecht zometeen. Je wordt in principe een kwaliteitscontroleur, dus ben je ook verantwoordelijk ervoor.

Ik denk ook dat onze rol erdoor noodgedwongen verruimd wordt naar Product Owner. Jij ontwikkelt / onderhoudt een product met behulp van AI, maar omdat het feitelijk coderen een kleinere rol inneemt van jouw dagelijkse taken, moet je dus meer verantwoordelijkheid op je nemen op andere gebieden. Dus meer contact met de klanten / stakeholders, beter begrijpen hoe de business werkt, enzovoorts.

Je wordt dan eigenlijk semi verplicht een consultant die tussen de opdrachtgever en de AI in staat.

Leuk is anders, maar het werk verandert. Het verdwijnt niet, maar het wordt anders.

Disclaimer: dit is ook een bias van mij, want mijn werk beweegt zich sowieso al die kant op, ook zonder AI. 90% van mijn werk is het onderhouden van bestaande code, dus het programmeren an sich is al enorm afgenomen. Wat ik ook jammer vind, want ik zou dolgraag meer nieuwe dingen willen bouwen.

Ik ben eigenlijk de hele dag aan het overleggen en aan het debuggen van bestaande zooi. It's sad.

En vanuit mijn werk heb ik er bijna meer aan als ik cursussen op het gebied van bedrijfskunde, logistiek en administratie volg dan dat ik een betere programmeur word, want het interesseert niemand hoe het technisch werkt, als het maar werkt.

Ik denk dat heel veel van web verschuift naar a.i., zoals traditioneel zoeken (Google Search enz.) en webshops, dat zit in de toekomst allemaal in a.i. agents.

Ja, ik merk nu al dat ik bijna altijd Gemini gebruik ipv ouderwets zoeken op Google.

Is luiheid van mij, maar ook een symptoom van hoe slecht de zoekmachine tegenwoordig werkt. In de AI modus krijg ik tenminste direct resultaat. Dat gaan ze straks uiteraard verpesten door in de AI modus ook reclame en productsuggesties te verwerken, maar goed.

Met een beetje geluk hebben lokale LLM's de toekomst, als de hardware er beter voor geschikt is.

[ Voor 16% gewijzigd door Lethalis op 04-05-2026 15:21 ]

[TobyW]

De hardware is er al, die is alleen duur en de beste modellen zijn niet open weight. Ik heb een klein beetje getest met Qwen3.6-35B-A3B, die draait prima op een RTX5090, maar scoort in tests uiteraard wel minder dan Claude Sonnet en Opus. Ik heb het nog niet uitgebreid getest omdat ik snel klaar was met het copy/paste gebeuren en het model nog niet aan Claude Code gekoppeld had, wat wel mogelijk is.

Ik denk dat het slechts een kwestie van tijd is voordat er (mixture of experts) open weight modellen zijn die op 128GB (bijv. Mac Studio) best goede resultaten leveren.

[Marc3l]

Daarom denk ik dat wij als programmeur toch een uitstervend beroep hebben.

Lethalis schreef op maandag 4 mei 2026 @ 15:06:

want het interesseert niemand hoe het technisch werkt, als het maar werkt.

Waarom een programmeur in dienst nemen als Pietje die op de administratie zit het ook kan maken.
Als iets niet werkt, net zo lang promten tot het wel werkt.

[BernardV]

Marc3l schreef op donderdag 7 mei 2026 @ 12:16:
Daarom denk ik dat wij als programmeur toch een uitstervend beroep hebben.


[...]

Waarom een programmeur in dienst nemen als Pietje die op de administratie zit het ook kan maken.
Als iets niet werkt, net zo lang promten tot het wel werkt.

Precies!
"Een gebruiker kan nu zijn eigen naam wijzigen, kijk eens hoe mooi dat werkt"
...Even niet gezien dat het endpoint ook gewoon is_admin op 1 kan zetten...

[Glashelder]

Marc3l schreef op donderdag 7 mei 2026 @ 12:16:
Daarom denk ik dat wij als programmeur toch een uitstervend beroep hebben.


[...]

Waarom een programmeur in dienst nemen als Pietje die op de administratie zit het ook kan maken.
Als iets niet werkt, net zo lang promten tot het wel werkt.

Ik denk dat ook. Nu is vooral security nog een ding, maar het is een kwestie van tijd en AI heeft dat ook gewoon (heel) goed onder de knie.

Als dat eenmaal zo ver is dan zie ik gebeuren dat ontzettend veel SAAS boeren het zwaar gaan krijgen. Waarom bakken met geld betalen aan bijv. Salesforce voor een enorme hoeveelheid features die je niet gebruikt terwijl je ook iets kan vibecoden.

BernardV schreef op donderdag 7 mei 2026 @ 12:27:
[...]

Precies!
"Een gebruiker kan nu zijn eigen naam wijzigen, kijk eens hoe mooi dat werkt"
...Even niet gezien dat het endpoint ook gewoon is_admin op 1 kan zetten...

Dat is ook gewoon een kwestie van niet de juiste vragen stellen.

Maar wat nou als je bij bijv. Claude gewoon een set system prompts krijgt die juist dat soort problemen voorkomt? Dat gaat echt gewoon komen.

[ Voor 24% gewijzigd door Glashelder op 07-05-2026 12:32 ]

[BernardV]

Glashelder schreef op donderdag 7 mei 2026 @ 12:29:


[...]

Dat is ook gewoon een kwestie van niet de juiste vragen stellen.

Maar wat nou als je bij bijv. Claude gewoon een set system prompts krijgt die juist dat soort problemen voorkomt? Dat gaat echt gewoon komen.

Het prompten is natuurlijk het probleem, iemand die geen besef heeft van de impact zal dat niet meenemen in de prompt. Daarvoor moet je al enige kennis hebben wil je dat meenemen.

Het zal zeker komen dat Claude dat zelf gaat oppakken. Ik gebruik Claude ook veel en development tijd is echt een stuk minder. Wat al eerder gezegd is is de verschuiving wel naar tester.

[Technoid]

Glashelder schreef op donderdag 7 mei 2026 @ 12:29:
[...]

Dat is ook gewoon een kwestie van niet de juiste vragen stellen.

Maar wat nou als je bij bijv. Claude gewoon een set system prompts krijgt die juist dat soort problemen voorkomt? Dat gaat echt gewoon komen.

Run a deep OWASP security sweep of the full app, like a person that get 1000 dollar an hour, forget every fix we already done, scan everything again, all APls and any internal services. Report in descending severity and suggest solutions, do not fix them yet. Save in security.md

[ZpAz]

Er gaat zeker wel een verschuiving van het werk aankomen. Zelf programmeer ik al +- 25 jaar. (Waarvan +- 20 betaald) en dit is toch wel de grootste verandering tot nu voor mij.

Op het moment is het zeker niet dat de gemiddelde vibe coder iets in elkaar zet waarvan ik denk, daar wil ik mijn data stallen. Ook kan je soms absoluut prompten tot je een ons weegt. Maar als je zelf niet bepaalde kennis hebt, gaat een LLM je zeker ook niet altijd helpen om de juiste architecturele beslissingen te namen. Werk nu zelf aan een project, waar ik echt al meerdere maanden intensief AI voor gebruik. En het grote verschil is:

- Ik bedenk nog steeds de architecturele structuur
- Ik ben minder tijd kwijt aan het uittypen hiervan


Het is veel makkelijker om een aanpak te proberen, refactoren is vrijwel gratis. Dat is de grote verandering. In plaats van dat ik over iedere individuele regel agonize. Het is meer 'PR' reviews geworden. Maar als je geen ervaring hebt met best practices kan je de reviews niet verder beoordelen dan: "dit lijkt te werken". Stapel genoeg van de "lijkt te werken" op elkaar en de LLM gaat zich steeds verder in de problemen werken. (Eg ik heb in al mijn prompten diverse regels als DRY, look what exists etc) maar toch gaat hij nog regelmatig de fout in.

Maar. Ik denk dat een andere hoek ook de ruimte voor SaaS producten kan verminderen. Iemand uit de US die ik ken bijvoorbeeld, diende normaal zijn taxes in via TurboTax etc. Nu had hij voor zichzelf wat in elkaar laten schroeven om hetzelfde uit te voeren. Misschien is het wel niet veilig geschreven. Maar hij is toch de enige gebruiker en het verlaat zijn computer verder niet.

Dus dat het meer gaat richting, mensen vragen aan een LLM taken uit te voeren, zonder dat de data eerst bij een SaaS gestald moet worden. Is de data daar niet, is de aanvalsvector ook veel kleiner.

[lordgandalf]

Wat hier gebeurde is dat bepaalde interne procedures gewoon werden ignored en software of packages werden verkregen vanuit het internet zonder scans want de AI vraagt er om. Die vlieger gaat hier niet op zijn bepaalde regels voor. code of software word binnengehaald via een dienst die er ook even een scan over los laat. En ja is niet zalig makend maar goed beter dan niks. Ons software product word van tijd tot tijd met ons medeweten en ook zonder gescanned en gechecked.

We hadden een beheerder die wat programmeer kennis had die vroeg 90% aan de AI en copy paste code gewoon ruczichloss zonder te checken wat het deed.

[simotion]

Ah ja, “vibe coders”.

Allereerst: AI is bijzonder en een geweldige tool, die ik zelf als developer ook dagelijks gebruik. Maar het is nog geen volwaardige vervanging voor een senior full stack developer. En zelfs áls dat ooit zo wordt, maakt dat iemand zonder technische kennis nog niet automatisch een succesvol softwarebedrijf.

Het is een beetje alsof een CTO zonder technische achtergrond een developmentteam inhoudelijk gaat aansturen. Dat levert zelden goede software op.

Het grootste risico zit wat mij betreft bij de klant, die vaak ook niet goed kan beoordelen wat er technisch onder de motorkap gebeurt. Die ziet vooral een werkende frontend en moet erop kunnen vertrouwen dat het softwarebedrijf weet waar het mee bezig is.

Met AI kunnen beginners nu relatief eenvoudig applicaties genereren die op het eerste gezicht prima werken. Maar onderliggend kan de code slecht onderhoudbaar zijn, vol technische schuld zitten of fouten bevatten die pas later voor grote problemen zorgen. Uiteindelijk is dan vooral de klant de dupe — en indirect ook de markt voor specialisten.

Daarnaast zie je nu al dat de markt voor juniors verandert. Veel taken die ik vroeger aan een junior of stagiair gaf, laat ik tegenwoordig door AI uitvoeren. Wat een junior enkele uren kostte, doet AI soms in minder dan een minuut.

Ik ben benieuwd hoe dit zich verder ontwikkelt. Ik maak me persoonlijk nog niet direct zorgen over mijn eigen werk, maar disruptief is deze ontwikkeling absoluut.

[smesjz]

simotion schreef op zaterdag 9 mei 2026 @ 15:55:
Het grootste risico zit wat mij betreft bij de klant, die vaak ook niet goed kan beoordelen wat er technisch onder de motorkap gebeurt. Die ziet vooral een werkende frontend en moet erop kunnen vertrouwen dat het softwarebedrijf weet waar het mee bezig is.

Het ligt beetje aan het product maar de klant koopt functionaliteit en heeft de kennis en interesse niet om te beoordelen hoe het onder de motorkap precies werkt. daarnaast is die code - handmatig of AI assisted - gewoon intellectual property dus die deel je in principe niet zelfs als je escrow gebruikt en alles gewoon doorloopt.

Verder vang je als klant af door bij selectie van je leverancier vragen te stellen die voor jou belangrijk zijn t.a.v. hosting, support, gebruikte technologie, versie beheer, test strategie, SDLC.

Met AI kunnen beginners nu relatief eenvoudig applicaties genereren die op het eerste gezicht prima werken. Maar onderliggend kan de code slecht onderhoudbaar zijn, vol technische schuld zitten of fouten bevatten die pas later voor grote problemen zorgen. Uiteindelijk is dan vooral de klant de dupe — en indirect ook de markt voor specialisten.

Die agents worden ook steeds beter dus t.z.t. maak je gewoon nieuwe prompt voor framework upgrade, optimaliseren van code, analyse,nieuwe test cases schrijven. je kan natuurlijk ook instructies geven hoe code georganiseerd moet worden, code standaard meegeven etc.

Voor huis,tuin en keuken vibe coding misschien allemaal overbodig maar als je iets voor een klant maakt als bedrijf, kan je je afvragen of je zelf aan de complexe code moet zitten als je je hele app al met AI gemaakt hebt.

Daarnaast zie je nu al dat de markt voor juniors verandert. Veel taken die ik vroeger aan een junior of stagiair gaf, laat ik tegenwoordig door AI uitvoeren. Wat een junior enkele uren kostte, doet AI soms in minder dan een minuut.

Ik ben benieuwd hoe dit zich verder ontwikkelt. Ik maak me persoonlijk nog niet direct zorgen over mijn eigen werk, maar disruptief is deze ontwikkeling absoluut.

Voor mijn gevoel wordt het bij ons nog te weinig gebruikt, iedere developer heeft GitHub copilot enterprise license maar kwaliteit van bug reports en nieuwe requirements is nog te laag om het efficiënt te gebruiken. MCP servers maken is nog spannend etc. dus besparing is er nog niet.