Nieuwe plek in de Devschuur?

[Sp00n]

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...

[ZveenT]

Leuk idee - volg.

[Harmsen]

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!

Dit zou ook prima hier op Tweakers kunnen! Ik denk dat juist kennisdeling en ideeën opdoen waardevol kan zijn.

[SiErRa]

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.
Maar als vibecoder doe je dit wel, want je kan zelf niet inschatten of de geproduceerde code klopt. Dan kan je denken, ah de AI kan ook best debuggen en de bugs oplossen. Maar dan moet je wel weten dat die bugs er zijn. Als iets functioneel niet goed werkt, dan ontdek je dat wel, maar als er een security probleem in zit, dan merk je dat niet. Totdat het te laat is.

Die opleiding is niet voor niets en gaat niet (alleen) over het produceren van de juiste syntax, dat is eigenlijk bijzaak.

Maar wel goed om er hier over te posten, want dat kan er hopelijk nog wat worden bijgestuurd, voordat het mis gaat.

[Sp00n]

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 zal eens vragen aan m'n AI of het nodig is ;-)

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.

[Cartman!]

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
omdat ik ervan uitga dat het voor de simpele dingen die ik maak, niet nodig is.

Daar gaat het al mis. Security is niet iets erbij, het is absolute noodzaak vanaf t begin af aan goed te doen.

Development is veel meer dan wat code produceren.

[Marber]

Mijn beheerdershart doet nu al pijn

[Patriot]

Op zich zou ik het als ontwikkelaar best grappig vinden om te zien waar mensen die verder geen ontwikkelervaring hebben zoal mee aan de slag gaan, en zou ik gerust ook wel een beetje willen sturen of helpen.

Wel deel ik de vrees die @SiErRa ook heeft, dat juist dit soort ontwikkeling erg gevoelig is voor het introduceren van subtiele maar relatief ernstige beveiligingsproblemen. Op oppervlakkig niveau zijn in LLM's er in mijn ervaring best goed in om consequent de basale beveiligingsmaatregelen in acht te nemen, maar ook makkelijk gaten over het hoofd zien. Dat gebeurt 'echte' ontwikkelaars natuurlijk ook, maar het is m.i. ook een beetje te simpel om te doen alsof die twee dingen hetzelfde zijn.

Dat gezegd hebbende, op zich hoeft het ook weer niet in de weg te staan dat we er een forumonderdeel aan toewijden.

[Kheos]

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.

En da's meteen al een attitude verschil met een 'echte' developer. "Het werkt toch?" is niet hetzelfde als "het is makkelijk uit te breiden en te onderhouden" bijvoorbeeld.

Sp00n schreef op maandag 2 februari 2026 @ 11:49:
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.

En da'a een tweede attitude verschil.
Want na een tijdje wil je die app uitbreiden, uitbrengen... En ineens moet je alles from scratch herschrijven omdat de AI alles met gare SQL statements aan elkaar heeft gehangen. Weet jij veel waarom dat niet de way to go is: als AI het zegt zal het zo slecht niet zijn, zeker?

[Sp00n]

Kheos schreef op maandag 2 februari 2026 @ 11:56:
En da'a een tweede attitude verschil.
Want na een tijdje wil je die app uitbreiden, uitbrengen... En ineens moet je alles from scratch herschrijven omdat de AI alles met gare SQL statements aan elkaar heeft gehangen. Weet jij veel waarom dat niet de way to go is: als AI het zegt zal het zo slecht niet zijn, zeker?

Ik kan je verzekeren dat dat (gare SQL statements) niet gebeurt (bij de AI die ik op dit moment gebruik).

Ik zou em eerder omdraaien. Waar is je technical debt?

Kan best zijn dat de app helemaal opnieuw wordt opgebouwd bij een update met de nieuwste libraries en frameworks. Ik weet niet of dat een feature of een bug is.

We zijn met ons bedrijf nu al 18 maanden bezig om naar een nieuwe architectuur te gaan. En het duurt waarschijnlijk nog een jaar voor we weer "on par" zijn met ons huidig product. Dat is me ook een partij ellende.

[Cartman!]

Sp00n schreef op maandag 2 februari 2026 @ 12:06:
Ik kan je verzekeren dat dat (gare SQL statements) niet gebeurt (bij de AI die ik op dit moment gebruik).

Hoe kun je dat verzekeren als je zelf eerst aangeeft geen programmeur te zijn?

[Kheos]

Sp00n schreef op maandag 2 februari 2026 @ 12:06:
[...]
Kan best zijn dat de app helemaal opnieuw wordt opgebouwd bij een update met de nieuwste libraries en frameworks. Ik weet niet of dat een feature of een bug is.

Geen feature, wel een bug. Slecht design ook trouwens. Nu kost het je x maanden aan testing effort extra omdat je nergens meer op kunt vertrouwen.

[Lethalis]

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.

Dat vind ik persoonlijk erg jammer. Ik heb een groot deel van mijn leven gestoken in het leren van alle ins en outs, om een betere software ontwikkelaar te worden. Om nu de hele tijd geconfronteerd te worden met dat AI mijn baan gaan inpikken.

Vooralsnog geloof ik daar niet in, maar het is wel iets dat het verdere traject van mijn loopbaan kan beïnvloeden. Ik sta eigenlijk voor een T splitsing waarin ik of een betere domein specialist moet worden (waarbij het echte programmeren een steeds kleinere rol gaat spelen, en ik meer moet leren over de dingen die ik programmeer), of juist mijn technische kennis naar een niveau moet tillen waar ik geen last meer heb van vibe coders (als ik low level C++ of Rust software programmeer die kritiek is voor het aansturen van allerlei processen en hardware, dan is dat veel te spannend om daar AI op los te laten).

Ik weet nog niet wat het gaat worden eerlijk gezegd

De tijd dat we als software developers makkelijk geld verdienden is wel een beetje voorbij. Je moet straks echt dingen kunnen die normies niet voor elkaar krijgen met AI.

Cartman! schreef op maandag 2 februari 2026 @ 12:10:
[...]
Hoe kun je dat verzekeren als je zelf eerst aangeeft geen programmeur te zijn?

Dat vraag ik mij ook af

Ik heb zelf 4 SQL Server certificaten, en nog een paar andere SQL certificaten van het HBO en de universiteit, en schrijf al 20+ jaar SQL statements en hou daarbij rekening met indexing strategieën, analyseer data execution plans, enzovoorts.

Is al die kennis nu zinloos? Ik kan het mij bijna niet voorstellen Ik hoop het niet althans.

Kortom, laat die SQL statements eens zien!

[ Voor 20% gewijzigd door Lethalis op 02-02-2026 12:15 ]

[Sp00n]

Lethalis schreef op maandag 2 februari 2026 @ 12:11:
Vooralsnog geloof ik daar niet in, maar het is wel iets dat het verdere traject van mijn loopbaan kan beïnvloeden. Ik sta eigenlijk voor een T splitsing waarin ik of een betere domein specialist moet worden (waarbij het echte programmeren een steeds kleinere rol gaat spelen, en ik meer moet leren over de dingen die ik programmeer), of juist mijn technische kennis naar een niveau moet tillen waar ik geen last meer heb van vibe coders (als ik low level C++ of Rust software programmeer die kritiek is voor het aansturen van allerlei processen en hardware, dan is dat veel te spannend om daar AI op los te laten).

Ik denk beide. Leer samen te werken met AI. Vriend van me heeft een software bedrijf met programmeurs die zeer nadrukkelijk worden aangespoord om AI te gebruiken. Scheelt gewoon heel veel tijd. En bij hun is het natuurlijk anders dan bij mij.

Zij krijgen een nieuw stuk code en weten precies wat dat doet. Ik denk veel meer: ja het zal wel.

[Sp00n]

Cartman! schreef op maandag 2 februari 2026 @ 12:10:
[...]

Hoe kun je dat verzekeren als je zelf eerst aangeeft geen programmeur te zijn?

Ik heb informatica gestudeerd, niet afgemaakt.

SQL vind ik niet echt programmeren. Ik kan SQL lezen en schrijven.

Belangrijker is je databasestructuur denk ik.

[Yucon]

Ik vind het wel interessant om eens te zien wat voor een soort vragen naar boven komen. 20+ jaar geleden ben ik developer geweest en ik heb ook een opleiding in die richting, maar daarna ben ik de business kant uit gegaan. Tegenwoordig gebruik ik regelmatig LLMs om wat code in elkaar te draaien voor prototypes/PoC's/data-transformatietooltjes die in de IT context blijven en het niet tot bedrijfskritische prod tooling schoppen.

In die zien ben ik me door mijn achtergrond wel bewust van wat je ook vooral niet dat spul moet doen. Maar tegelijkertijd zie ik als bedrijfskundige ook dat klassiek programmeren ook z'n tekortkomingen heeft waar het om bovengenoemde use cases gaat.

Daarnaast zijn alle risico's en tekortkomingen die bij vibe coding horen ook wel gewoon een soort nieuwe iteratie van alle ellende die je bij gare access tooltjes of excel macro's had.

Ergens ben ik daarom wel heel benieuwd waar zo'n topic toe zou leiden.

[Lethalis]

Sp00n schreef op maandag 2 februari 2026 @ 12:16:
[...]
Ik denk beide. Leer samen te werken met AI. Vriend van me heeft een software bedrijf met programmeurs die zeer nadrukkelijk worden aangespoord om AI te gebruiken. Scheelt gewoon heel veel tijd. En bij hun is het natuurlijk anders dan bij mij.

Zij krijgen een nieuw stuk code en weten precies wat dat doet. Ik denk veel meer: ja het zal wel.

Het scheelt in mijn geval erg weinig tijd, maar dat komt ook omdat ik bijna uitsluitend bestaande software moet onderhouden. En elke regel code die ik tik, kan vergaande gevolgen hebben in het systeem... dus ja, dat laat je niet aan AI over.

Soms laat ik Copilot Chat weleens wat stukjes code genereren en meestal schud ik dan mijn hoofd en schrijf ik het alsnog zelf.

Ik denk dat AI veel meer van invloed is op nieuwe projecten. Als je snel iets nieuws wil bouwen. Zodra je aan een systeem werkt dat al decennia cruciale bedrijfsprocessen ondersteunt dan ga je daar niet achteloos in harken.

Maar zelfs dan vraag ik me soms af wat ik eraan heb en kom ik in een prompt loop terecht met een AI die nogal vaak "je hebt gelijk" schrijft, om vervolgens weer iets te doen wat ik niet goed genoeg vind En dan komt er vanzelf een moment dat je het zat bent en weer ouderwets zelf gaat doen.

Mijn probleem met AI is alleen dat ikzelf die technische eisen stel aan de software. Mijn opdrachtgever boeit het wellicht minder en daar loert het gevaar. Dat er ergens een "goed genoeg" situatie komt, waarbij mensen de lat simpelweg minder hoog leggen.

Kortom, "het doet het toch?".

Dat zou al het plezier uit software ontwikkelen voor mij halen, omdat ik juist de kwaliteitsattributen van complexe systemen interessant vind (de -ilities). Het wordt dan niet zozeer een kwestie van of ik AI zou kunnen gebruiken, maar of ik het überhaupt wil. Als wij naar een wereld gaan waarin alles AI slop wordt, dan check ik uit en ga ik maar een ander vak leren

[Yucon]

Sp00n schreef op maandag 2 februari 2026 @ 12:16:
[...]
Zij krijgen een nieuw stuk code en weten precies wat dat doet. Ik denk veel meer: ja het zal wel.

Ik denk dat dit een misvatting is. Volgens mij is het eerder zo dat zij weten waar ze op moeten letten om te zien of het goed zit, en dat ze intuïtief beter in kunnen schatten waar de problemen gaan zitten.

[CodeCaster]

Ik ben een verstokte back-end-developer die dat ruim anderhalf decennium als beroep uitvoert, en na drie jaar te hebben gehaat op alles wat naar AI ruikt, ben ik dankzij een paar weken Claude Code licht overstag.

Het is nog steeds objectief allemaal bagger wat er uit LLM's komt, maar je hebt qua applicatie wel snel iets relatief functioneels staan. Zo heb ik met het handje een datamodel en een set API's gebouwd die precies doen wat ze moeten, en het zal mij een worst wezen of de front-end 1 MB of 20 MB is en of het Vue 3.1 of 3.2 is.

Die front-end hebben we met twee man en een paar dagen vibe-coden mooi wel neergezet, iets wat anders een designer en een front-ender een veelvoud van die tijd had gekost.

Dus meer aandacht voor zo'n werkwijze kan in de Devschuur wat mij betreft geen kwaad. Laat men elkaar wijzen op tooling, werkwijzen, valkuilen en wat dies meer zij.

Ik ben alleen bang dat je, net als in het AI-softporn-topic, alleen maar prompting heroes krijgt die je wel even vertellen dat het aan je prompt ligt als iets niet doet wat je verwacht, maar niet hun werkwijze delen. Laten we daarop letten.

[Sp00n]

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.

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.

[Lethalis]

CodeCaster schreef op maandag 2 februari 2026 @ 12:35:
Het is nog steeds objectief allemaal bagger wat er uit LLM's komt, maar je hebt qua applicatie wel snel iets relatief functioneels staan. Zo heb ik met het handje een datamodel en een set API's gebouwd die precies doen wat ze moeten, en het zal mij een worst wezen of de front-end 1 MB of 20 MB is en of het Vue 3.1 of 3.2 is.

Dat is dus exact wat ik bedoel met de lat minder hoog leggen

Maar goed, ik zal wel een echte dino zijn die nog geeft om de efficiency van zijn software.

[Joep]

Hoewel ik vibe coding maar niks vind, mag er wat mij betreft best een subforum voor gecreëerd worden. De devschuur is op het moment namelijk zo dood als een pier en mogelijk is het een opstapje naar daadwerkelijk fatsoenlijk programmeren voor beginnende leken.

[CodeCaster]

Lethalis schreef op maandag 2 februari 2026 @ 12:40:
[...]

Dat is dus exact wat ik bedoel met de lat minder hoog leggen

Maar goed, ik zal wel een echte dino zijn die nog geeft om de efficiency van zijn software.

Ik geef absoluut om efficiëntie, maar die halen we in dit geval uit de database; de app is een intern ding dat na het eerste request vanuit de browsercache draait. Optimalisatie komt na realisatie.

[ Voor 4% gewijzigd door CodeCaster op 02-02-2026 12:45 ]

[Sp00n]

Nog groener dan groen. De:

Joep schreef op maandag 2 februari 2026 @ 12:44:
... beginnende leken.

[Yucon]

Lethalis schreef op maandag 2 februari 2026 @ 12:40:
[...]

Dat is dus exact wat ik bedoel met de lat minder hoog leggen

Maar goed, ik zal wel een echte dino zijn die nog geeft om de efficiency van zijn software.

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

Absoluut geen waardeoordeel. Ik begrijp echt hoe je erin staat, alleen sluit dat gewoon niet aan bij een deel van de use cases. Ik sta ook vooraan om te roepen dat jouw standpunt in genoeg situaties ook echt juist wel precies het juiste is. Maar niet altijd.

Enerzijds zijn efficiency, maar ook bijvoorbeeld architectuur die overhead met zich meebrengt in sommige situaties gewoon overbodig ballast die juist contra-productief kan zijn. Even gewijzigde inzichten meenemen zorgt er dan ineens voor dat je de helft weer op de schop moet nemen. En anderzijds merk ik dat veel developers er ook gewoon slecht mee om kunnen gaan dat requirements onduidelijk zijn. Dat kunnen functionele requirements zijn, maar soms ook gewoon zelfs semi-technische omdat je bijvoorbeeld met een API moet interfacen waarvan je het gedrag vooraf slecht kunt inschatten. Trial&error is dan vaak de beste oplossing maar dat werkt in de praktjik slecht als het over twee personen verdeeld is.

Ergens hoop ik misschien ook wel een beetje dat zo'n forumdeel of topic ervoor kan zorgen om zolderkamerknutselaars van al te slechte ideeën af te brengen. Maar dat kan dan weer mijn naïviteit zijn.

[Oon]

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.

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.

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

[CodeCaster]

Lethalis schreef op maandag 2 februari 2026 @ 12:31:
[...]

Mijn probleem met AI is alleen dat ikzelf die technische eisen stel aan de software. Mijn opdrachtgever boeit het wellicht minder en daar loert het gevaar. Dat er ergens een "goed genoeg" situatie komt, waarbij mensen de lat simpelweg minder hoog leggen.

Kortom, "het doet het toch?".

Dat zou al het plezier uit software ontwikkelen voor mij halen, omdat ik juist de kwaliteitsattributen van complexe systemen interessant vind (de -ilities). Het wordt dan niet zozeer een kwestie van of ik AI zou kunnen gebruiken, maar of ik het überhaupt wil. Als wij naar een wereld gaan waarin alles AI slop wordt, dan check ik uit en ga ik maar een ander vak leren

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.

Ik herken en volg je sentiment wel dat dit mogelijk een bedreiging voor het opgehemelde vak van softwareontwikkelaar is: als alle software "straks" "goed genoeg" is, dan is er mogelijk veel minder vraag naar gemiddelde developers, ja.

Ik geloof en hoop dat ik dat niveau inmiddels ontstijg, en dat ik aan het werk kan blijven als expert, als ontwerper, als finetuner. En weet je hoeveel bagger er nu in de markt wordt gezet en is gezet zonder LLM's?

Als mijn baan verwordt tot prompttyper, ga ik inderdaad wel wat anders doen. Iets met voertuigonderhoud of tuinieren lijkt me machtig mooi.

[Cartman!]

Sp00n schreef op maandag 2 februari 2026 @ 12:36:
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.

Ik voel me aangesproken Nee, ik ben niet bang dat vibe coders mn werk overnemen. Ik maak platformen voor miljoenen gebruikers en waar miljoenen euro's doorheen gaan en dit zal echt niet snel vervangen worden door een vibe coder.

Ik maak dagelijks gebruik van Windsurf met Claude Sonnet en vind het veel toevoegen. Wat ik al zei; code schrijven is niet moeilijk, de meeste tijd zit in het goed uitdenken van features en randzaken als security en performance.

Waar ik me wel zorgen maak is dat er bepaalde tools of dingen gemaakt zullen worden door lui die het eigenlijk niet snappen waardoor mijn gegevens niet goed beveiligd worden en op straat komen te liggen. Zelfs ervaren developers zien niet alles, waarom een onervaren iemand denkt dit met een LLM wel voor te kunnen zijn is me n raadsel.

[CrankyGamerOG]

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

Hoe doe jij als leek pentesten of je app wel veilig is dan?

[CrankyGamerOG]

Sp00n schreef op maandag 2 februari 2026 @ 12:18:
[...]


SQL vind ik niet echt programmeren. Ik kan SQL lezen en schrijven.

Lol. Deze statement zegt dan ook meteen alles.

[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 ]