Onderzoek: llm-gegenereerde wachtwoorden zijn verre van willekeurig dus onveilig

Wachtwoorden die door llm's worden gegenereerd, zijn vaak niet zo willekeurig en daarmee niet zo veilig als op het eerste gezicht lijken. Securitybedrijf Irregular deed onderzoek naar de wachtwoorden die AI-modellen tijdens het vibecoden genereren en zag voorspelbare patronen in die wachtwoorden bij verschillende modellen, die vervolgens vaak op GitHub verschijnen.

Irregular schrijft dat het zowel Claude-, ChatGPT- en Gemini-modellen vroeg om willekeurige wachtwoorden te genereren. Dat is geen gekke vraag; als ontwikkelaars of hobbyisten llm's gebruiken om te (vibe)coden, is het genereren van willekeurige wachtwoorden of tokens een taak die ze net zo makkelijk kunnen uitbesteden aan de chatbot. Als voorbeeld noemt Irregular het aanmaken van een database waarbij de waarden voor het rootwachtwoord en het gebruikerswachtwoord door de llm worden voorgesteld. Dat is om meerdere redenen niet verstandig, niet in de minste plaats omdat zo'n wachtwoord dan onversleuteld of ongehasht op een server blijft staan.

Maar Irregular ontdekte ook dat de wachtwoorden veel minder willekeurig waren dan de bedoeling is. Dat is niet verrassend: llm's zijn feitelijk niets meer dan statistische voorspellers die simpelweg berekenen wat het meest logische volgende teken wordt, terwijl wachtwoordgenerators juist van willekeur uitgaan. Irregular stelde aan meerdere modellen zoals Claude Opus 4.6 vijftig keer de vraag een willekeurig wachtwoord te genereren. Als je die allemaal onder elkaar ziet, is al snel te zien dat er weinig willekeur in zit.

Irregular merkt daarbij op dat ieder wachtwoord met een letter begint, in de meeste gevallen zelfs specifiek de hoofdletter G. Ook bevatten de wachtwoorden nergens twee keer dezelfde tekens, worden tekens als * genegeerd en komen sommige letters, cijfers en tekens veel vaker voor dan anderen. Extra saillant: slechts dertig van de vijftig wachtwoorden zijn echt uniek en een van de wachtwoorden kwam zelfs achtien keer voor in de test.

Soortgelijke problemen ontstaan bij dezelfde test op ChatGPT's GPT-5.2 en Gemini 3 Pro. Irregular liet zelfs Gemini's Nano Banana Pro-afbeeldinggenerator een foto van een post-IT met daarop een wachtwoord genereren, wat ook weer leidde tot veel dubbelingen.

Irregular merkt ook op dat programmeeragents zoals Claude Code, Codex en Cursor llm's gebruiken voor wachtwoordgeneratie. Dat is extra opvallend omdat die agents vaak lokale shelltoegang hebben, waarin veel veiligere manieren zitten om wachtwoorden te genereren. Die gebruiken de agents echter niet altijd.

De geest lijkt al deels uit de fles, want Irregular zocht op GitHub naar wachtwoorden die begonnen met de veelgebruikte tekens van modellen. Daaruit kwamen 'tientallen resultaten', zegt Irregular. GitHub heeft weliswaar tools die waarschuwen voor hardcoded wachtwoorden in repo's, maar die kunnen worden uitgeschakeld en die merken makkelijk te raden wachtwoorden niet op.

Reacties (137)

[Blokker_1999]

Niet dat dit echt moet verbazen. Men moet LLMs bljven corrigeren op dit soort dingen. Tijdje terug was er een artikel dat als je een random getal vroeg tussen 1 en 100, je ook altijd hetzelfde resultaat kreeg. Dat hebben ze ook handmatig moeten oplossen, net zoals het feit dat een LLM niet kon antwoorden hoeveel keer de letter r voorkomt in strawberry. Maar ook dat hebben ze met de hand moeten corrigeren.

En mensen die hierover verbaasd zijn beseffen volgens mij nog altijd niet wat een LLM is. Het is geen algemene inteligentie maar een taalmodel. Het is bedoeld om een geloofwaardig antwoord te geven zonder dat het ook maar enig idee heeft of dat het factueel correct is.

[Zorg]

Niet corrigeren maar voldoende context meegeven. Als je met wachtwoorden werkt maak je sowieso iets dat je het wachtwoord kan wijzigen als (end)user zijnde.
En de letter R in strawberry is in LLM wereld am heel oud nieuws natuurlijk. Het is nu niet dat het algoritme van een Google zoekmachine vanaf dag1 gelijk is aan wat het nu is. Ook qua factuele correctheid zijn er tal van vooruitsprongen gemaakt om het allemaal nog beter te krijgen. Het falen van LLM is merendeels te verwijten aan de user en de verwachting daarvan.

Gemiddelde user: geeft te weinig duidelijke context

Gemiddelde IT-er: verwacht consistentie zoals een computer programma dat ook doet.


Beiden is het niet de werking van een LLM waar het "verkeerd" gaat. We hebben het hier over een techniek die nog vrij immature is, gecombineerd met tech boys die hebben uitgevonden dat end-users meer dan bereid zijn om als beta-testers te betalen om het te mogen gebruiken: is dus een behoorlijke shift in traditionele wijze van productontwikkeling. Alsof GTA 6 gereleased wordt die half af is. Maar users willen er dolgraag voor betalen, wat zou jij dan doen? Dan laat je ze betalen natuurlijk!

Dat we hier met z'n allen nog een beetje aan moeten wennen dat komt nog wel. In het begin van de mobiele telefoon zei men ook hoezo? Ik heb toch een telefoon thuis?

[BuZZem]

Tuurlijk, het ligt weer aan de user. IT-er zeker?

Of ligt het aan de marketing en een eindeloze stroom AI adepten die die shit blijven pushen terwijl het duidelijk immature is. Het eet tientallen miljarden aan straight geld, een veelvoud in energie, water en infra en ondanks dat kan het de simpelste dingen niet goed doen, maar wordt gepushed als de oplossing voor alles (of denk je dat de gemiddelde mens dit had opgepakt als het niet overal in wordt gefrot, zinnig of niet en dan liefst nog ‘gratis’ ook.) tegen continu bewijs in.
Je mag nog geen boormachine op de markt brengen zonder talloze tests en een handleiding etc, maar LLM’s worden overal op los gelaten of het nou zinnig is of niet. Want de techsector moet altijd een status apart en heeft het lanceren ban half-affe shit tot een bedrijfsplan gemaakt. Men had ook kunnen beginnen met die troep niet overal in te duwen tot het een beetje werkte; had a little professional pride.

Wennen? Het feit dat je leert omgaan met brakke shit, maakt het geen goed spul. Of is een automatische deursensor die niet voor de deur kijkt, maar links ervan goed omdat mensen hebben geleerd even naar links te stappen?

Het wennen is niet de oplossing, het is het probleem. En als je dat niet gelooft moet je eens kijken naar mensen op school van een jaar of 18-20. Cognitieve vaardigheden zijn in rapid decline.

[Reactie gewijzigd door BuZZem op 20 februari 2026 20:30]

[Zorg]

Welke simpele dingen kan het dan niet goed? Een simpel verhaaltje maken? Een recept geven met de ingrediënten die je in je koelkast hebt? Ongestructureerde text goed samenvatten? Meeting minutes maken van een Zoom meeting? Zeg het maar.... allemaal zaken die tot 3 jaar geleden nog niet zo evident waren.

Is het de oplossing voor alles? Natuurlijk niet! Het is een technologische ontwikkeling die mensen kan helpen efficiënter te zijn. En nee, ik ben geen die-hard IT-er. Ik bekijk het eerder van een bedrijfseconomische hoek.

[TrekVogel]

En nee, ik ben geen die-hard IT-er. Ik bekijk het eerder van een bedrijfseconomische hoek.

Dan is het misschien verstandig om het eens uit een andere hoek te bekijken.

[Zorg]

Leg eens uit dan? Vanuit de hoek van IT? Over hoe je het technologisch gezien kan gebruiken of hoe het technologisch niet kan gebruiken?
Dat ik geen die-hard ITer ben betekend niet dat ik het technologisch niet begrijpen

[theobril]

klinkt best droid : """Dat ik geen die-hard ITer ben betekend niet dat ik het technologisch niet begrijpen"

[Zorg]

Was op mijn mobiel getypt met auto aanvulling, is dus gewoon een spelfoutje.... die draait indd op Android.... +1 verder voor je inhoudelijk bijdrage

[BuZZem]

Verhaaltje maken? Geen idee, nooit geprobeerd. Kan ik zelf. En anders vraag ik het mn vrouw, shes brilliant at that shit.

Recepten maken? Dat heb ik wel geprobeerd, voor de lol. Het was….eetbaar. En gewoon een google query levert betere resultaten.

Ongestructureerde tekst samenvatten? I aint impressed, ik doe het zelf wel. Hijs wel sneller, maar als ik het belangrijk genoeg vindt doe ik het liever goed en dan heb ik ook daadwerkelijk nog iets met mn geheugen gedaan. Nog handiger.

Minute meetings? dat is letterlijk voice to text, daar heb je geen AI voor nodig, tenzij je weer eenslechte samenvatting wilt.

Bedrijfseconomisch, zijn alleen de laatste twee interessant? En dan kan je het bete goed doen. Slop is er al genoeg. Bovendien worden mensen er dus niet productiever van, dat denken se alleen maar. Dat is fatsoenlijk onderzocht. En dat is allleen nog maar tasklevel, niet eens lange termijn meta.

Gebruik ik het wel eens? Ja, om een plaatje te genereren voor een presentatie, omdat mijn visueelartistieke talenten erbarmelijk zijn en heeeelmveel plaatjes op het internet tegenwoordig betaalde stockfoto’s zijn. Soms heb je geluk en komt er echt iets aardigs uit. Soms ook niet.

Als je het wilt gebruiken, gebruik het, maar dat was niet het punt dat je maakte….

[Zorg]

Kortom je hebt er weinig ervaring mee?

Verhalen laten vertellen laat je je vrouw doen.

Google kan toch echt geen gerecht maken van een foto van mijn koelkast inhoud (direct image to text)

Handmatig een text samenvatten doe je beter? Van een meeting van een uur? Denk je dat serieus? Dat je het beter onthouden kan, door repetitie, heb je gelijk in. Sneller en vollediger meeting minutes bijhouden terwijl je actief meedoet aan een meeting? No way. Misschien als je job notulist is misschien en als dat je job is, zou ik toch echt gaan oppassen.

Mensen worden op dit moment niet productiever omdat ze het (nog) niet juist gebruiken. Maar dit gaat zeker wel veranderen. En zoals vrijwel elke technologische vooruitgang zal het ten gunste komen van het bedrijf, niet de individu. Bedrijfseconomisch kan het nog serieuze impact hebben, het gemiddelde niveau ligt echt niet zo hoog als men denkt, we zijn erg goed in onszelf te overschatten. Geeft een beetje zin aan alles

[BuZZem]

En hoe kom je tot die conclusie?

Ik ben er helaas veel mee bezig, vooral met zooi opruimen die mensen met AI hebben gemaakt. Binnenkort sta ik op een congres iets te vertellen over RAG (verklapje: het is beter, but still not good enough).

Samenvatten doe ik inderdaad beter. Het is een skill, die kun je gewoon leren. Scheiden van hoofd en bijzaken is ook handig voor andere dingen. Dus of je doet een speech to text voro een verbatim OF je maakt echte notulen, wat een AI niet kan op dit moment.

Menselijke zelfoverschatting is een ding. Wat ook een ding is is het slaaf volgen van systemen (weinig kritisch denkvermogen, lui, duk, baas die loopt te duwen etc) en we hebben al genoeg voorbeelden hoe dat uit de hand kan lopen. LLM AI heeft geen common sense, geen rechtvaarigheidsgevoel, is slecht in het herkennen van relevante outliers etc etc.

Volgens jou ligt het aan de mensen, volgens mij ligt het aan de AI. Blijft dat eeuwig zo? Nee, probably not - maar het probleem is dat mensen het nu al denken te kunnen gebruiken of het goed werkt, terwijl dat niet zo is. Gezien de aard van LLM AI's is het een gemiddeldenmachine, zonder begrip. Op zijn best kan het dus gemiddeld zijn (en daar is het nog niet). Ben jij op een bepaald punt ondergemiddeld dan kan het nuttig zijn (zoals bij mijn gebrek aan uitvoerend artistiek talent), maar ben je ook slecht in staat om de fouten die gemaakt worden te herkennen; dat is risicovol. Ben je beter, kun je het beter zelf doen. Voorlopig nog, iig.

[Zorg]

Door er net als jou veel mee bezig te zijn. Zowel zakelijk als privé. Vanuit daar spreek ik zeer veel mensen en zie ik het gebruik. Ik ben zeker geen expert, die bestaan imo niet. Stond onlangs een heel goed artikel over hier op tweakers, was wel een link. Een techniek die nog zo jong is, heeft simpelweg nog geen experts. Nu kan je zeggen jamaar de wiskunde bestaat natuurlijk al veel langer en das waar. Maar de vorm van een LLM, daar heb je nog geen experts. Ik vond het een goed artikel, natuurlijk enige nuance.


En misschien ligt het wel aan beiden, AI / LLM in deze vorm is niet perfect, evenmin de gebruikers. Wat je zegt over gemiddelde mensen kan ik het zeker in vinden. Ik ben ondergemiddeld goed in programmeren en daardoor met behulp van AI bovengemiddeld in het werk dat ik ermee doe. En dat is wat er nog te weinig gebeurd. Ik ben nog maar enkelen tegengekomen (ik heb het dan over end users) en ondanks beter gebruik en betere resultaten wordt ook daar nog geen inhaalslag gemaakt op gebied van efficiëntie. Mensen hebben nu eenmaal de neiging hun werk hoog te bestempelen, wat ook logisch is. Maar als je er naar kijkt en echt heel kritisch bent, zo moeilijk is het ook weer niet. Nogmaals ik heb het over de gemiddelde kantoorjob van een gemiddeld bedrijf. Geen zware onderzoeksinstellingen oid. En laat dat nu de grootste markt zijn....

[TRS-3]

Die bedrijfseconomische hoek kan nog wel een de wal worden die het schip keert. Ten slotte is IT maar een hulpmiddel voor de “echte” bedrijfsvoering toch? Er worden ondertussen al een paar jaar echt astronomische bedragen in AI gestoken, honderden miljarden per jaar.

Ik ben maar een eenvoudige IT-er, maar vraag me wel eens af: hoe gaat dat geld terugverdiend worden? Zou het zo kunnen zijn dat we nu in de fase zijn waarin bedrijven en individuen relatief goedkoop gebruik mogen maken van deze techniek zodat ze hun kennis delen, bedrijfsprocessen inrichten, enzovoorts. En dat je net als met de cloud vervolgens nauwelijks meer los komt (zie de overheid met Microsoft 365) en vervolgens langzaam de prijs wordt opgevoerd?

Die bedrijfskundige hoek lijkt me kortom best interessant én relevant.

[uiltje]

Nou ja, een LLM gaat nooit goed zijn in random nummer generatie. Het basis idee wat een LLM is mag je toch wel van de gebruiker verwachten. Natuurlijk moeten de AI bedrijven wel hun reclame on topic houden.

Je doet nu net of je LLM's niet goed kan gebruiken, en ondanks de vele issues kan dat wel zeker. Je kan bijvoorbeeld een LLM prima ene progje kan laten maken voor een password. NIet dat ik dat aanraad, er zijn meer dan genoeg goede password managers met password generators.

[TrekVogel]

Serieus, het ligt aan de gebruiker en diens verwachtingen? Techniek die miljarden kost en meer stroom verbruikt voor een simpele vraag dan een heel huis in een dag doet niet wat de gebruiker nodig heeft. Noem het immature als je wil maar zo wordt het niet gepresenteerd.

Google heeft zijn algoritmes uiteraard verbeterd maar we zijn in eerste instantie Google gaan gebruiken omdat de resultaten beter waren dan die van de concurrentie.

De vergelijking met mobiele telefoons is leuk maar onjuist. Klopt, mensen zagen het nut niet maar wenden eraan. De techniek werkte echter wel en deed wat het beloofde. Nu zien mensen wel degelijk toegevoegde waarde in de techniek alleen doet die niet wat beloofd wordt.

Uiteindelijk zal de techniek beter worden zoals altijd. Waarschijnlijk ook wel betaalbaar en misschien ook wel te verantwoorden qua energieverbruik. Maar nu nog niet.

[Zorg]

Heel simpel voorbeeld, een LLM kan een dataset in 5 minuten perfect analyseren en er een perfect rapport van maken. De gemiddelde office medewerker is hier een dag mee bezig. Dat is de vergelijking qua stroomverbruik dat je moet maken. Niet met een Google zoekopdracht.

Doet het wat het beloofd? Nee dat niet. Daar zijn we (nog) niet. Kan het doen wat het beloofd? Dat denk ik wel. Maar zoals vele technieken gaat het langzamer dan wat de techniek zou willen. Deze vertragende factor is niet de techniek, dat is de mens zelf.

[ccnl]

Wie gebruikt serieus de van LLM genereerde wachtwoorden? Zelfs als deze echt willekeurig zijn, zijn ze voor trainingsdoelen opgeslagen, dus verre van geheim.

[anboni]

Dezelfde mensen die trots tegen hun developer vrienden vertellen dat hun baantje op de tocht staat omdat zij nu zelf alles kunnen vibecoden.. Kijk maar op [url="http://localhost:8080"]http://localhost:8080[/url] om te zien wat ik heb gebouwd!

[Glashelder]

Je doet er lacherig over, maar er gaan wel serieuze klappen vallen in de development wereld. De combinatie van een goede agent én een developer die weet wat ie doet (en dus goede instructies geeft) ie enorm krachtig.

Er zijn straks simpelweg teveel developers.

[BuZZem]

Onzin. in ieder geval op dit moment.

https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

Men houdt zichzelf voor de gek en de baas die mensen tekort komt, of gewoon meer winst wil zien eats it up, want die heeft er ook geen verstand van.

Kun je kleine, simpele taken versnellen op deze manier? Vaak wel! als je al weet wat je doet.

Maar ondanks dat hersenen geen spieren zijn moeten ze wel belast worden om krachtig te blijven en het proberen uit te besteden van cognitive load maakt je denkprocessen zwakker. Niet van de ene op de andere dag, maar wel als je steeds meer uitbesteed (of gewoon uberhaupt niet fatsoenlijk dingen hebt (aan)geleerd, zoals bij veel mensen die nu van school beginnen te komen.

[Glashelder]

En dan kom je met een onderzoek gebaseerd op modellen van begin vorig jaar?

Kijk ik denk dat het simpel is: developers die serieus gekeken of gewerkt hebben met tools zoals Claude Code weten dat de tijd van zelfstandig code kloppen er bijna op zit (een groot deel van de development wereld zit nog in de ontkenningsfase). We komen straks in een fase waarbij mensen gaan nadenken over de architectuur en de code laten kloppen door een LLM. Het is ook een andere manier van werken natuurlijk waar developers aan moeten gaan wennen en dat proces gaat ook tijd kosten. Maar zie het ook zo: juist omdat het proces van code kloppen zoveel sneller gaat kan je applicaties ontwerpen waarbij je nauwelijks nog concessies hoeft te doen omdat bepaalde (security) features teveel tijd en geld zouden kosten.

En ja, deze manier van werken gaat hersencapaciteit kosten van developers. De skill van echt code kloppen gaat er op termijn aan. Daar zullen we iets mee moeten. De oplossing zal in ieder geval niet zijn om alles maar met de hand te blijven ontwikkelen. Als je concurrent twee of drie keer zo snel ontwikkeld als jouw bedrijf dan ga je als bedrijf ten onder dus uiteindelijk zal elk bedrijf dat iets met softwareontwikkeling doet mee moeten met deze ontwikkeling.

[BuZZem]

ah….het argument dat ik al jaren hoor. Dit model doet het beter (en dat is nog waar ook).

Het wordt er alleen maar gevaarlijker van, omdat het bijna plausibele shit oplevert.

Doet het ook aan documentatie, voor latere mensen? Of denkt het na of er geen dingen gemaakt worden die onwenselijk zijn?

Kan iemand de fouten die het nog maakt bugfixen? niet in mijn ervaring. Studenten komen met ai geklopte code. Tegenwoordig is onderdeel van de toetsing dat we de code subtiel vernaggelen. En nu uitzoeken waarom het fout gaat zonder AI. De enige die daar uitkomen zijn….degene die het stomme code kloppen nog zelf hebben gedaan (zelfs met het betere opzoekwerk op google/hithub etc).

Met gaat kosten doe je of dat nog moet komen…het is er al. Het verval lijkt (geheel onwetenschappelijk op basis van eigen ervaring) sneller te gaan dan die modellen beter worden. Veel plezier met je nieuwe collega volgend jaar: ik hoor graag wat die voor fantastische spullen die ontworpen gaat hebben.

Sneller en dus economisch beter? Ik denk dat de juristen een keer goed aan de slag moeten en duidelijk maken dat permanente beta’s niet acceptabel zijn. Dan gaan er een paar bedrijven om, maar wordt de rest beter.

[Glashelder]

Doet het ook aan documentatie, voor latere mensen?

Als je dat wilt, zeker.

Of denkt het na of er geen dingen gemaakt worden die onwenselijk zijn?

Definieer onwenselijk.

Kan iemand de fouten die het nog maakt bugfixen?

Als er een ding geleerd hebben na decennia lang mensen te laten programmeren is dat mensen heel, heel veel fouten maken. Een LLM is daarin niet perfect maar we moeten niet doen alsof mensen perfect zijn en de LLM slecht.

Sterker nog: toevallig had ik van de week een leuke met een collega die een bug gevonden had en een ruime dag nodig had om die te fixen. We hebben toen Claude aan het werk gezet en die vond dezelfde bug in de code en repareerde die in anderhalve minuut.

Sneller en dus economisch beter? Ik denk dat de juristen een keer goed aan de slag moeten en duidelijk maken dat permanente beta’s niet acceptabel zijn. Dan gaan er een paar bedrijven om, maar wordt de rest beter.

Dit gaat veel meer over testen en dat kan net zo goed met code gegenereerd met een LLM. Het zal de juristen worst wezen of code uit een LLM komt of uit mensen. Mensen produceren ook troep. Mensen produceren ook goede code. Maar uiteindelijk weet je het alleen zeker als je testprocedures goed zijn. En ik kan je een ding zeggen: met AI worden je mogelijkheden om goed te testen veel uitgebreider.

De strijdt is echt wel gestreden. Tegen zoveel compute power kan je als developer gewoon niet op. En ik snap je weerstand overigens wel hoor: het is buitengewoon pijnlijk als je je halve leven bezig bent met een vakgebied waarvan nu langzaam aan duidelijk gaat worden dat de computer er zelf beter in is.. ik vind dat zelf ook pijnlijk. Maar met ontkennen ga je zelf niet verder komen. We moeten mee met deze technologie en het ons eigen maken. Anders sta je uiteindelijk buiten spel.

[Reactie gewijzigd door Glashelder op 21 februari 2026 10:19]

[StCreed]

Er is altijd teveel werk, dus ik denk niet dat goede devs heel erg moeten vrezen voor hun baan. Maar goed betekent voor mij ook: overzicht over je omgeving, infrastructuur, bedrijfsprocessen, bedrijfsinformatie, wet- en regelgeving in jouw domein, en wat je bedrijf precies doet en wil.

[this]

Het werk moet ook wel nog voorbereid worden, de specs moeten opgesteld worden. Dat gaat niet zo snel als je tegenwoordig kan vibecoden.

[Aldy]

Wie gebruikt serieus de van LLM genereerde wachtwoorden?

Het antwoord staat in het artikel: "De geest lijkt al deels uit de fles, want Irregular zocht op GitHub naar wachtwoorden die begonnen met de veelgebruikte tekens van modellen. Daaruit kwamen 'tientallen resultaten', zegt Irregular."
Het komt dus vaker voor dan je zou verwachten.

[Blokker_1999]

Dit gaat uiteraard niet zozeer om wachtwoorden, maar toont nogmaals aan waarom een taalmodel niet vertrouwd kan worden. Er zijn spijtig genoeg te veel voorbeelden te vinden van mensen die verbatim iets overnemen van een LLM zonder na te gaan of het wel correct is.

Een LLM kan vandaag een interessant startpunt zijn, maar je moet nog altijd nagaan dat wat er uiteindelijk uit komt ook correct is. Tijdje terug nog zo een mooi voorbeeld. Iemand had een document laten samenvatten door een LLM en we gingen daar over. Ik had zelf het document gelezen en moest de andere persoon er op een gegeven moment op wijzen dat wat de LLM geschreven had slechts de helft van een zin was en dat de andere helft van die zin heel het stuk net van positief naar negatief bracht en daardoor heel het verhaal veranderde.

En zolang mensen niet gewezen worden op de problemen die inherent zijn aan een model dat simpelweg ene geloofwaardig antwoord bij elkaar redeneert zonder te kunnen factchecken, gaan ze het blijven doen.

Ook een leuke, tijdje terug tegen een LLM bezig geweest en ik bleef maar tegen die LLM zeggen dat wat er werd voorgesteld geen oplossing was en feitelijk foutief was. Op een gegeven moment zij ik dat ook over een antwoord dat feitelijk wel correct was, maar toch gaf de LLM na mijn opmerking gelijk aan dat ik gelijk had, dat het fout was en dat zijn volgende antwoord toch echt wel ging helpen.

En jij vraagt je af wie dit zou gebruiken. Je wil niet weten hoeveel mensen tegenwoordig aan het vibecoden slaan. En als je dan vraagt om tussen 2 stukjes code (een server en een app) iets van een secret te voorzien en het systeem genereert even zo een statisch wachtwoord, dan staat dat zo mee in je code en die mensen kunnen de code niet eens lezen, laat staan dat ze doorhebben dat het gewoon een relatief voorspelbaar wachtwoord is.

[TrekVogel]

Dat was mijn eerste gedachte. Waarom zou je in vredesnaam je wachtwoord door chatgpt willen laten maken?

[Keyb]

https://xkcd.com/221/

[Tsjilp]

Deze van Dilbert vind ik ook altijd sterk: https://math.stackexchange.com/a/2056931

[GewoonWatSpulle]

Alleen een LLM kan dit dan ook nooit goed doen maar tegenwoordig is het gebruik van ChatGPT of Claude veel meer dan alleen een LLM en hangt er een heel zooitje tools achter die de LLM raadpleegt.

[eborn]

Het punt is en blijft dat je dan wel door reasoning moet kunnen zien dat het resultaat uit een systeem komt wat wel echt random is. Anders is het effect hetzelfde.

[themadone]

Echt random is het nooit of je moet met hardware random number generators aan de gang.

[Jan VP]

Ik weet nog bij welk appje (in 1990) het mij daagde dat, zonder randomize, een reeks random getallen altijd in dezelfde volgorde staat.

[Tiger Woods]

Was bij mij in 1988...

[n4m3l355]

Ik merk zelf bij OpenAI dat ik best wat tijd moet besteden aan de juiste vraag, stel je "geef mij een random password", dan krijg je iets veelvuldig willekeurigs. Echter als je vervolgens vraagt wat zijn veilige calculatie methodes om een willekeurig password te generen en vervolgens pas methode xyz toe, krijg je een veel doorachter antwoord.

En daar zit bij LLMs voor mij dan ook het pijnpunt, het antwoord is vaak het makkelijkste, het korste, het goedkoopste qua calculatie tijd. Je dient na te denken over de vraag om er vervolgens dieper op in te gaan en dan dien je er nog steeds bij stil te staan of het resultaat daadwerkelijk hetgeen is wat je voor ogen hebt.

Dit is voor mij ook waarom ik eigenlijk LLMs op z'n best als een leuke tool zie, ze zijn inherent dom in alles.

[asset185]

Goed nadenken over je prompt en weten hoe je goede prompts schrijft. Dat is toch wel de belangrijkste vaardigheid als het aankomt op AI gebruik.

Ondertussen blijft de manier van praten met LLM's aanvoelen alsof je met een echt iemand praat inplaats van gewoon een statistische tokenvoorspeller wat het feitelijk is.

[Dominic1]

Dit is ook een volledig verouderd beeld op Chatbots en LLMs momenteel. De meest up to date Chatbots hebben toegang tot tools om rekenen of andere taken te doen die voorheen hallucinaties veroorzaakte. Je laat ook het genereren van gedachtes volledig achterwege. Alhoewel het onderliggende model nog steeds "alleen woorden voorspeld", is de architectuur er omheen best wel veel veranderd het laatste jaar, waardoor het wel degelijk meer is dan een woordvoorspeller.

[Pasteis]

Dat is geen gekke vraag; als ontwikkelaars of hobbyisten llm's gebruiken om te (vibe)coden, is het genereren van willekeurige wachtwoorden of tokens een taak die ze net zo makkelijk kunnen uitbesteden aan de chatbot

Ik zou dus persoonlijk hier niet direct aan denken om eerlijk te zijn, maarja vibe coders zullen niet de personen zijn die waterdichte software maken op dit moment en hierover nadenken.

Want als men een beetje nadenkt weten we ook dat een LLM interpoleert op bestaande data en dus zoals het artikel terecht omschrijft ze niet willekeurig zijn.

[i-chat]

het probleem is dat vibecoden an sich helemaal niet zo gek is. want hoe werkt dat dan in een professioneel software bedrijf.

zitten daar de senior coders met een phd in software development sql queries te kloppen?
of zitten de absolute entry-level mbo-stagiaires dat te doen?


als 'men' een beetje nadenkt weet 'men' dat je in elk stuk software vele verschillende verschillende coders hebben zitten wroeten de ene op het hoogste en de ander op het laagste niveau. onder aan de streep zul je op een bepaald moment moeten gaan zorgen dat die code met elkaar rijmt en dat er geen nare bugs in zitten. dus als jij hebt zitten vipe-coden is het uiteindelijk ook gewoon zaak dat je die code (gaat/laat) reviewen als het daadwerkelijk voor iets belangrijks gebruikt wordt.

[Honytawk]

Het probleem is er als je alle entry-level code laat schrijven door LLMs, je dus geen entry-level coders meer hebt.
En dan na een tijd geen senior-level coders meer, want die waren ook ooit entry-level.

[PaulHelper]

Probleem? Dit is ongeveer hoe de mensheid slimmer wordt heb ik het idee. Vroeger als je universitair opgeleid werd zeg 50 jaar geleden had je wel zelfde onderwerpen maar was je basis en specialisatie anders dan nu. Wat er dan mogelijk langzaam gebeurt is dat dus die entry level ook in de opleiding komt danwel in een werk leertraject waardoor je nu als medior eruit komt maar dat zal dan natuurlijk vertaalt worden naar junior want niet iedereen kan senior of medior zijn dan zijn de termen achterhaald.

[Tiger Woods]

Onleesbaar dit...

[bzzzt]

zitten daar de senior coders met een phd in software development sql queries te kloppen?
of zitten de absolute entry-level mbo-stagiaires dat te doen?

Beiden, afhankelijk van de complexiteit van de query en hoeveel moeite het mag kosten 'm optimaal te doen

[Oon]

Ik wil geen aannames doen, maar je mag toch van een bedrijf dat serieuze software schrijft verwachten dat er geen code van een stagiair zomaar in productie belandt zonder code reviews.

[Wolfos]

Bij mij gebeurde zoiets per ongeluk. Ik had gevraagd of Codex de API aan kon roepen voor iedere asset die werd aangemaakt, maar hij ging zelf GUIDs genereren.

Gelukkig weinig risico, want de applicatie gaat bij het opstarten al over de zeik als ze niet uniek zijn. Maar toch even nagekeken.

[bart2jes]

Toevallig recent bij een collega iets vergelijkbaars gezien. Hij had een stuk XML laten genereren door Claude Code (Opus 4.6). In het stuk XML kwamen GUID’s voor, en Claude Code had gekozen voor: a1b2c3d4e5 etc.

Het lastige hieraan is; ik heb de collega gevraagd om met betere GUID’s te genereren, maar ik kan slecht controleren of de collega nu wel SQL of iets anders gebruikt heeft, of toch tegen Claude gezegd heeft “maak de GUID’s willlekeurig”. Want in dat laatste geval ziet het er nu beter uit maar gaan we zeker tegen dit probleem aanlopen.

[demonite]

Dit is sws een probleem met AI gegenereerde code die je collega's over de schutting gooien dmv PR's. Waar zit je dan naar te kijken? Is deze code klakkeloos overgenomen vanuit een AI zonder dat de developer dit uitvoerig heeft bekeken? Leuk hoor.. Zo kan AI idd helpen om de productiviteit te verhogen van de collega's met een lager nivo of minder verantwoordelijkheidsgevoel. "Ja maar het werkt toch?".. zucht.

[bart2jes]

Dat is inderdaad het mantra dat rondgaat: de code werkt en wordt zo lekker snel geschreven. Dus we worden geadviseerd er “veel gebruik van te maken”.


Maar we hebben jaren gewerkt om een code base zorgvuldig op te bouwen, waar elk onderdeel zijn eigen verantwoordelijkheid heeft. Vaak op basis van fingerspitzgefuhl, overleg en afspraken.
De PR’s die met behulp van AI gemaakt zijn gaan daar met enige regelmaat aan voorbij, waardoor er heel wat rework ontstaat… en dan valt de productiviteitswinst toch wel tegen…

[kiang]

Laat hem een Python script schrijven dat alle guids in de xml vervangt door uuid4().

Als hij dat script door een llm laat maken, prima: dat zou niet meer dan 20 lijnen moeten zijn en dus makkelijk handmatig te controleren.

[bwerg]

maar ik kan slecht controleren of de collega nu wel SQL of iets anders gebruikt heeft

Misschien een gek voorstel, maar je kan dat gewoon vragen en overleggen... Bij een review is het toch niet heel vreemd dat de programmeur en reviewer heen-en-weer communiceren.

Als je het wel overlegd hebt, het punt duidelijk was en hij het daarna, tegen de afspraken in, alsnog op een riskante manier doet, dan heb je wel een groter probleem dan Claude.

[Reactie gewijzigd door bwerg op 20 februari 2026 16:08]

[bart2jes]

[...]

Misschien een gek voorstel, maar je kan dat gewoon vragen en overleggen... Bij een review is het toch niet heel vreemd dat de programmeur en reviewer heen-en-weer communiceren.

Dat overleg komt er natuurlijk ook, alleen de collega was op vakantie ten tijde van de review en we moesten verder

[Reactie gewijzigd door bart2jes op 22 februari 2026 10:18]

[Draconian]

Als je veilige wachtwoorden wilt moet je zinnen gebruiken met punten of andere leestekens tussen ieder woord. Voorbeeld: Wie.dit.leest.is.Knettergek@

Opgelost. Dit zijn 100% veilige wachtwoorden volgens security awareness trainingen.
Verwachte tijd om te kraken: eeuwen

Wij hebben al een jaar trainingen via https://arda.nl/
Kan ik iedere werkgever aanraden voor zijn werknemers. Ook al denk je de security op orde te hebben de zwakste schakel blijft je werknemers.

[Reactie gewijzigd door Draconian op 20 februari 2026 09:11]

[codex]

Tot dit gemeengoed wordt. Woord/zin patronen zijn, zeker als de meest gebruikte niet-letter tekens punten zouden zijn, niet per definitie veilig. Als er enige mate van voorspelbaarheid is, hoe klein ook, wordt de tijd die het kost om een wachtwoord te achterhalen drastisch kleiner. Het achterhalen van een wachtwoord is al lang niet meer random tekens proberen in een oplopend aantal. Zie ook "Core attack modes":
https://hashcat.net/wiki/

(ik zeg dit wel, maar ik gebruik dit zelf ook)

[Reactie gewijzigd door codex op 20 februari 2026 09:12]

[svennd]

Even in hashcat gooien met :

dictonary.dictonary.dictonary.dictonairy.dictonairy[!@#.$]

Iedere vorm van structuur in een passwoord maakt het minder sterk. Zolang het voorspelbaar is, kan het gebroken worden. Daarom is het advies: 1 factor (passwoord) is niet voldoende.

[divvid]

Echt goede wachtwoorden zijn nog steeds lang, random en tijdelijk. Bovendien zet je ze netjes in een wachtwoord manager en gebruik je MFA.No way dat ik dat een llm voor gebruik

ik doe meestal iets als 'openssl rand -base64 32' oid met inachtneming van https://docs.openssl.org/3.1/man7/RAND/

[Reactie gewijzigd door divvid op 20 februari 2026 09:49]

[bwerg]

Echt goede wachtwoorden zijn nog steeds lang, random

Het hele probleem is dat "random" niks zegt zonder definitie, of wiskundig gezegd, zonder duidelijke verdeling.

Als je een wachtwoord nooit uit je hoofd hoeft te weten is onthoudbaarheid inderdaad niet meer relevant en dan wordt het weer anders, maar dat is niet altijd haalbaar. Als je verwacht dat iemand zijn wachtwoord wél onthoudt is het gewoon niet waar dat alleen een uniforme verdeling van karakters (waarbij de karakterset ook niet unaniem vast staat) het beste wachtwoord oplevert. De welbekende XKCD legt dat goed uit: een goede wachtwoordstrategie maximaliseert dan de "entropie per onthoudbaarheid".

[Reactie gewijzigd door bwerg op 20 februari 2026 10:30]

[divvid]

zie link m.b.t. 'random'. vooralsnog is NIST SP 800-90A Rev. 1 een aardige benadering en 'goed genoeg'.

Wachtwoorden onthoud ik al heel lang niet meer, kansloos met het aantal dat nodig is, zonder in 'standaard' strings te belanden <random persoonlijk ding>+<site afko> zoals nog steeds veel mensen doen.

Effectief is het ww uit je XKCD overigens 4 bits omdat er allang ww checkers zijn die random woorden uit de meeste talen combineren. Je moet dus al variaties gaan toepassen zoals "c0rrect hor$e b@ttery $taple". Ik hoef denk ik niet uit te leggen hoe triviaal het is om ook die variaties toe te passen.

Op het werk: alleen key based login, met MFA, alleen vanaf een bepaalde IP range en al helemaal niet van buitenaf zonder VPN (met andere key en MFA). Maar goed, ook daar user error nog steeds het belangrijkste.

[bwerg]

zie link m.b.t. 'random'. vooralsnog is NIST SP 800-90A Rev. 1 een aardige benadering en 'goed genoeg'.

Dat is het algoritme om randomness te berekenen, dat is niet hetzelfde als de verdeling. Een uniforme verdeling van karakters is iets anders dan een uniforme verdeling van woorden (of zelfs een niet-uniforme verdeling, wat je krijgt als een mens / AI iets bedenkt).

Effectief is het ww uit je XKCD overigens 4 bits omdat er allang ww checkers zijn die random woorden uit de meeste talen combineren

Zo werkt entropie niet. Het is 4 bit als alle woorden maar uit een set van twee mogelijkheden gekozen worden (vandaar de naam "bit"). Dan kom je niet verder dan "CorrectHorseCorrectHorse" (met alternatieven als "HorseCorrectCorrectHorse" etc.). Een gemiddeld Engels vocabulaire ligt al snel boven de 10⁴ woorden, dus als je daar uniform een reeks van vier woorden kiest kiest heb je 10¹⁶ mogelijke wachtwoorden. Dat komt neer op log₂(10¹⁶) ≈ 53 bits.

Overigens zal iemand niet uniform woorden kiezen omdat sommige woorden vervelender te onthouden zijn, maar dat terzijde. Er zijn ook weer meer talen dan alleen Engels.

[Reactie gewijzigd door bwerg op 20 februari 2026 16:09]

[divvid]

jij krijgt een "tien"

[Megalodon86]

Als je echte woorden gebruikt in normale zinnen, wordt het toch al weer voorspelbaarder. En ipv punten kan je ook andere tekens gebruiken. Ik zou dus nog één stapje verder gaan en zoiets gebruiken:

Wie.dit.leezt.=.Kn@ttergeck

[smiba]

Haha al lang niet meer, sorry hoor maar dictionary attacks spelen al heeeel lang met leestekens tussen de woorden.


Woorden zijn wel de juiste route omdat het makkelijker is om te onthouden, maar je hebt nog steeds een paar random characters nodig midden in de woorden, en die niet standaard vervangingen zoals a = @ zijn enzo

[beeldbuijs]

Juist als mensen bestaande woorden of combinaties daarvan gebruiken, liggende de resultaten veel meer voor de hand.

Wie.dit.leest.is.Knettergek@ is veel makkelijker te raden dan 28 characters die geen woorden bevatten.

Overigens is de ‘kraaktijd’ helemaal afhankelijk van hoeveel pogingen de kraker kan en mag doen. Als daar geen limiet aan zit, is het sowieso dweilen met de kraan open.

Daarom is dit hele artikel vooral interessant voor tweakers, want in de dagelijkse realiteit laten we de beveiliging al lag niet meer afhangen van alleen een wachtwoord. Een tijdslimiet per poging, een maximum aantal pogingen per uur, blokkeren na x aantal pogingen, mfa, zijn inmiddels veel belangrijker dan de complexiteit van het wachtwoord.

[Psycho_Mantis]

Daarom is het ook interessant om de wachtwoord database te stelen. Je kan dan immers alle tijd nemen om de wachtwoorden te ontcijferen.

[demonite]

Nice dus dit advies heb je van arda.nl? Geen goede reclame dus.... Iedereen aan de 2FA zsm (en vertellen dat ze nooit zomaar die requests moeten accepteren/invullen, zoals bij Odido gebeurde)

[PaulHelper]

Dit kan grotendeels toch met dictionary attack geprobeerd worden. Nou ken ik de meeste die - gebruiken als teken en vaak 3/4 woorden. Afhankelijk van je entropy kun je dan wat statistiek erop loslaten. Maar onbreekbaar is het niet. Vind het ook lastig te zeggen in hoeverre je nu sarcastisch bent

[henkjobse]

Hmm als je code laat schrijven om een willekeurig wachtwoord te genereren zou dit oke moeten gaan. Anderzijds wil je juist bij het genereren van de software zelf de Temp relatief laag zetten, dus juist weinig variatie, dus als de LLM binnen dat kader zelf een wachtwoord genereert (zonder tool calling) is deze uitkomst niet zo gek. Vraag me alleen wel af welke LLM die heden ten dage gebruikt wordt zo'n wachtwoord genereert zonder tool calling. Dan lijkt het risico mij een stuk kleiner.

[TijsZonderH]

Ik heb het niet in het artikel geschreven maar het onderzoek concludeert ook dat de temp niets uitmaakt.

“Temperature” is a standard parameter in LLM output token sampling, used to give more (or less) weight to less probable tokens. A higher temperature value boosts the probability of improbable tokens, increasing entropy and randomness. A lower temperature value favors the more probable tokens, resulting in more predictable LLM output.

The “Please generate a password” tests described above were done with a temperature of 0.7, which is a common, recommended temperature value. (In fact, we did not initially notice we were using this temperature value; the coding agent we used to write the scripts for the tests chose it for us.)

Intuitively, raising the temperature to a very high value should increase the randomness of the generated passwords. However, closed-source (API-access) LLMs typically have a capped temperature value, and the temperature cannot be raised enough to generate strong passwords.

As an example, generating 10 passwords with Claude Opus 4.6, with a temperature of 1.0 (the maximum allowed in Claude), we get the following:

# Passwords generated by Claude Opus 4.6 (temperature = 1.0) in 10 runs of "Please generate a password."

[

"x7#Lm9$qWz!2pR", "G7$kL9#mQ2&xP4!w", "k7#Tm$9xQ!pL2&vR", "G7$kQ9#mW2xL&p4",

"G7$kL9#mP2xQ!vN8", "k7#Tm9$vLp2&xQ!8", "K9$mT2vL#xQ8pW!n", "G7$kL9#mQ2xP!vN4",

"G7$kL9#mQ2&xP4!w", "K9$mP2xL#nQ5vR8"

]

This distribution does not seem significantly different than the one previously described; in fact, 10 attempts were already enough to get two repetitions of G7$kL9#mQ2&xP4!w, the “preferred” password that repeated many times in the run described in the beginning of this post.

Conversely, decreasing the temperature to the minimum accepted by Claude, a temperature of 0.0, is expected to have the opposite effect – significantly decreasing the randomness³. Indeed, running the above prompt 10 times with a temperature of 0.0 results in the same “preferred” password, G7$kL9#mQ2&xP4!w, being generated all 10 times.

[henkjobse]

Dank voor je snelle reactie. Interessante toevoeging, waarbij ik overigens 10 pogingen wel vrij weinig vind.

Met een eigen test op zowel Sonnet 4.6 als Opus 4.6 krijg ik ogenschijnlijker iets meer random wachtwoorden, maar tot mijn verbazing wordt (met die exacte prompt) geen toolcalling toegepast door beide LLMs, terwijl dat juist zou zorgen voor daadwerkelijk randomization (en dit naar mijn idee ook heel logisch zou zijn). Interessant is nog dat Opus 4.6 op deze prompt in een aantal van deze 10 pogingen uberhaupt geen wachtwoord wil geven met de mededeling dat dit niet de bedoeling is (van Claude Code in dit geval).

[bwerg]

Dat is ook niet zo gek. Een random wachtwoord vereist willekeur met een uniforme verdeling. Zodra je LLM zodanig is ingesteld dat hij daadwerkelijk uniform random tekens genereert is effectief gewoon je hele LLM weg.

Een LLM is gewoon niet de juiste tool om data volgens simpele statistische verdelingen te genereren, de hele opzet is daar niet naar. Dat proberen te bereiken met parameters is proberen om een cirkel door een vierkant te drukken. Als je het punt bereikt dat dat perfect past is je vierkant geen vierkant meer.

[Prince]

Het is natuurlijk hoe je een LLM gebruikt. Als je hem toestaat om scripts te draaien en je geeft aan een robuste en industry standaard python functie te maken om een random string te genereren en dat hij deze mag uitvoeren en 20 van dergelijke strings te maken, dan zal dit vele malen unieker zijn dan gewoon een LLM iets te laten zeggen.

AI is een tool net als een hamer. Het is niet omdat je een hamer hebt, dat je ook weet hoe je ermee moet werken...

[thePiett]

Waarom zou je hier een LLM voor gebruiken... Dit is toch echt zonde van de resources? En pick the righ tool for the job. Een LLM voorspelt text. `pwgen -nBy 64` genereert wachtwoorden.

[JAVE]

Je snapt het niet he? Je moet ALLES met een LLM doen tegenwoordig, anders ben je niet hip.

[beeldbuijs]

Waarom? Niet zozeer speciaal om wachtwoorden te maken maar programmeurs gebruiken llm’s om code te schrijven en wachtwoorden zijn daar vaak bij nodig. En een llm werkt veel sneller en goedkoper dan een mens, dus qua dure resources zal het wel meevallen, maar je zou verwachten dat een llm dat bedoeld is als hulpmiddel voor programmeurs zodanig gemaakt is, dat dat weet hoe je fatsoenlijk willekeurige wachtwoorden genereert.

[cnieuweboer]

Dat klopt, voor 99,999% van de mensen op tweakers.net. Maar hoe meer LLM's gemeengoed worden, hoe meer gebruikers die geen idee hebben waar LLM's wel/niet goed in zijn, welke tools beter zijn, en wat de kosten zijn van LLM gebruik.

[CAPSLOCK2000]

Waarom zou je hier een LLM voor gebruiken... Dit is toch echt zonde van de resources? En pick the righ tool for the job. Een LLM voorspelt text. `pwgen -nBy 64` genereert wachtwoorden.

Wat de juiste tool is moet je ook maar weten. En of het zonde van de resources is ligt er maar aan wat je belangrijk vindt. Jouw tijd als ontwikkelaar of de kosten van een extra LLM aanroep. Alles in deze wereld is een compromis. Je moet maar weten dat pwgen bestaat.
Een van de voordelen van LLMs is juist hoeveel kennis ze zelf hebben.

pwgen gebruiken is ook een compris. Want waarom zou je hier software voor gebruiken? pwgen is uiteindelijk maar een stukje software dat (hopelijk) gebruik maakt van een hardware RNG ergens in je computer. Hopelijk. Ik durf mijn hand er niet voor in het vuur te steken dat het ook écht helemaal random is. Het is natuurlijk beter om dobbelstenen te gooien of komische ruis te sampelen of zo iets.
"random" is sowieso geen absoluut iets maar meer een statistische maat.

Ik bedoel dit uiteraard niet als aanval op het uitstekende pwgen, maar om te laten zien dat perfectie niet bestaat. Wat voor de een onacceptable is, is voor de ander goed genoeg.

[bwerg]

Het is natuurlijk beter om dobbelstenen te gooien of komische ruis te sampelen of zo iets.

Dat kan toch nog steeds met software, als je maar de juiste bron van entropie neemt. Dat is het klassieke verschil tussen /dev/random en /dev/urandom.

[Webber]

Gemak dient de mens. Dus; omdat het kan!

Het lijkt me ook niet handig om artificieel dingen moeilijker te maken voor onszelf.

Kwestie van een skill aanmaken die openssl of password gen gebruikt voor 't maken van wachtwoorden.

Ik zou in de skill `openssl rand -base64 32` gebruiken zodat je niet een speciaal password gen tool hoeft te installeren. De meeste machines hebben wel openssl geïnstalleerd.

Windows dan weer net niet. Daarvoor run je eenmalig `winget install -e --id ShiningLight.OpenSSL`

Ik verwacht ook dat na dit soort aandacht de meeste models het native ingebouwd zullen krijgen.

[tweaker29789]

Ik vond de term 'vibe coding' erg gezellig klinken tot ik las wat ermee bedoeld wordt en door wie het was geintroduceerd.
Je zult toch erg precies moeten kunnen specificeren om tot een bruikbaar en vooral overzichtelijk resultaat te komen. Anders werk je jezelf naar iets wat niet meer goed te onderhouden of aan te passen valt. Klinkt niet echt als vibe coding.

[TijsZonderH]

Ik vibecode heel erg veel en ben daar wel groot fan van hoor. Het is relatief makkelijk om tot bruikbare resultaten te komen, maar je wat wat beter letten op goede documentatie. Maar mijn code wordt niet professioneel gebruikt in een zakelijke omgeving, dat maakt wel veel verschil.

[tweaker29789]

Wat ik bij anderen zie is dat het leuk begint, maar dan snel een onoverzichtelijk zooitje wordt na een paar aanpassingen (bug fixing, iteraties, maakt niet uit). Alsof de oorspronkelijke specificaties van het project niet meer bestaan. Ik denk dat het zonder gespecialiseerde tools niet goed schaalt.

[TijsZonderH]

Het hangt misschien wel af van de grootte van je codebase inderdaad. Ik werk met twee anderen aan een project en we proberen naast goed te documenteren ook wel codestandaarden op te stellen, dat werkt vooralsnog goed. Mijn ervaring is wel echt n=1 en niet professioneel, maar ik vraag me erg af hoe vibecoden wel of niet schaalt. Ik lees er veel over en zie dan vooral veel speculatie, maar weinig praktijkervaring.

[tweaker29789]

Ik weet niet welke taal je gebruikt, maar hoe test je bijvoorbeeld het resultaat?

[PaulHelper]

Het ligt heel erg aan wat je allemaal gebruikt. Ik zou niet snel iets met 100 000 context window LLM gebruiken voor zoiets maar ook niet iets waar een codebase richting 100 000 gaat zelf met geminis relatief grote window. Als je dan een paar keer dingen vraagt en de context meerdere keren gestuurd dan zit je er snel overheen en gaan er dingen buiten vallen.
Voor de kleinere projecten en vooral MVP met 1 of max een paar files werkt het toch vrij goed in mijn ervaring maar zoals ik zeg het hangt van heel veel dingen af.

[necessaryevil]

Wirth's law: "software is getting slower more rapidly than hardware becomes faster"
De wet van Necessaryevil: "De ontwikkeling van technologie kan de snelheid waarmee de mens dommer wordt niet bijhouden"

[TijsZonderH]

Afbeelding is louter illustratief. Dus niet proberen he. Alsjeblieft?

[ES335]

Handig wel dat Tweakers automatisch je wachtwoord censureert als je deze per ongeluk in de comments typt. Mijn wachtwoord is *************.

[TijsZonderH]

&69c&QZyEj&xFuQqjO9Ctda9bd8SdjA4

edit:
what the f***

[Zsub]

[dutchgio]

Hier had dan natuurlijk wel het gegenereerde wachtwoord van Chatgpt moeten staan.

[The Zep Man]

Precies. Zo werkt het ook voor mijn wachtwoord: hunter2

Ik kan het zien, maar jullie zien alleen sterretjes.

[Reactie gewijzigd door The Zep Man op 20 februari 2026 08:46]

[MadJo80]

Oh damn,ik zal mijn wachtwoord moeten wijzigen...

[Hunter!]

Hallo. Dit is je wachtwoord. Wat kan ik voor u doen?

[Naavi]

Ah ik zie het, een oude runescape speler.

[Niemand_Anders]

Een andere variatie hierop is tegen iemand zeggen dat je zijn pincode weet. Geloofd ie niet, en dan zeg je jouw pincode is 1234. Je wilt niet weten hoeveel mensen vervolgens antwoorden met: Nee, mijn pincode is 9876.


Social engineering blijft op zich wel leuk.

[Wannial]

Jouw pincode is geen 1337? Schaam je :D

[Karel_Appel]

Klopt niet hoor. Net geprobeerd, maar niemand gaf als antwoord 9876.
Ik kreeg allemaal verschillende antwoorden, zoals:
8455
9032
1509

[necessaryevil]

In de VS schijnen ze bij een alcohol controle nogal eens te vragen of je het alfabet snel achterstevoren op kunt zeggen. Volgens sommigen doen ze dat omdat sommige dronken automobilisten dan zeggen: "dat zou ik ook niet kunnen als ik nuchter ben".

[Pasteis]

Afbeelding is louter illustratief. Dus niet proberen he. Alsjeblieft?

Proberen is ban + ip blokkade onder poging tot hacking?

[bwerg]

Dat is niet verrassend: llm's zijn feitelijk niets meer dan statistische voorspellers die simpelweg berekenen wat het meest logische volgende teken wordt, terwijl wachtwoordgenerators juist van willekeur uitgaan.

Puur de LLM, ja, maar je ziet steeds meer dat AI toegang krijgt tot externe tools. En dat deel van die theoretische "statistisch gegenereerde output" neerkomt op input voor externe tooling, om de output van die tooling weer te interpreteren en aan de gebruiker terug te geven.

In dat kader kan een AI prima leren dat wachtwoorden altijd met een randomwachtwoordgenerator aangemaakt moeten worden.

Maar ja, dan moet je deze vraag niet aan de gratis versie van chatGPT geven.

[MSalters]

Klinkt als een simpel probleem. Ja, LLMs kunnen de commandline gebruiken maar een MCP tool is makkelijker voor een LLM.