Wel apart dat een bedrijf wat geen fatsoenlijke servers meer verkoopt nu wel vindt dat ze containers in hun client OS moeten ondersteunen. Is dit puur als service naar developers of heeft de doorsnee desktop user er ook wat aan?ThomasG schreef op dinsdag 10 juni 2025 @ 10:07:
macOS Tahoe krijgt Containerization Framework
[Afbeelding]
Developers zijn natuulijk wel gewoon een redelijk grote groep gebruikers waar je voor wilt cateren, ik zie inderdaad niet hoe dit iets toevoegt voor normale desktop gebruikers, hooguit voor de wat meer tech-savy users die apps als containers willen draaien.downtime schreef op dinsdag 10 juni 2025 @ 10:51:
[...]
Wel apart dat een bedrijf wat geen fatsoenlijke servers meer verkoopt nu wel vindt dat ze containers in hun client OS moeten ondersteunen. Is dit puur als service naar developers of heeft de doorsnee desktop user er ook wat aan?
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Omdat veel developers werken op MacOs. En er zijn meer virtualisatie systemen dan alleen Docker. Verder kunnen de images ook gewoon uitgewisseld worden. Je bent alleen niet meer verplicht tot Docker.downtime schreef op dinsdag 10 juni 2025 @ 10:51:
[...]
Wel apart dat een bedrijf wat geen fatsoenlijke servers meer verkoopt nu wel vindt dat ze containers in hun client OS moeten ondersteunen. Is dit puur als service naar developers of heeft de doorsnee desktop user er ook wat aan?
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Maar was je dat dan, verplicht tot Docker? Want "Docker" is al jaren gestandaardiseerd binnen het Open Container Initiative (dat is gebaseerd op de formaten van Docker) en heeft, in ieder geval onder Linux, ook al meerdere runtimes (met K8s uiteraard als bekenste, maar ook Podman bv). En toevallig (of nouja, vast niet) kwamen dit weekend op HN ook wat "links" voorbij van container runtimes voor Mac wat mij ook liet denken aan "Docker alternatief" (/"de OCI container variant").DevWouter schreef op dinsdag 10 juni 2025 @ 12:06:
Verder kunnen de images ook gewoon uitgewisseld worden. Je bent alleen niet meer verplicht tot Docker.
Nee, en Docker is van ver gekomen. Maar om even aan te geven hoe ingewikkeld is: K8s is geen runtime, maar een orchestation, meestal gebruikt het containerd. En er zijn allerlei verschillen tussen containerd, CRI-O, Docker of Mirantis die vaak toch erg relevant zijn qua performance.RobertMe schreef op dinsdag 10 juni 2025 @ 12:57:
[...]
Maar was je dat dan, verplicht tot Docker? Want "Docker" is al jaren gestandaardiseerd binnen het Open Container Initiative (dat is gebaseerd op de formaten van Docker) en heeft, in ieder geval onder Linux, ook al meerdere runtimes (met K8s uiteraard als bekenste, maar ook Podman bv). En toevallig (of nouja, vast niet) kwamen dit weekend op HN ook wat "links" voorbij van container runtimes voor Mac wat mij ook liet denken aan "Docker alternatief" (/"de OCI container variant").
Ik denk dat we mogen aannemen dat Apple spul vergelijkbaar of beter werkt dan Docker.
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Dan heb jij meer vertrouwen in Apple dan ikDevWouter schreef op dinsdag 10 juni 2025 @ 13:40:
[...]
Ik denk dat we mogen aannemen dat Apple spul vergelijkbaar of beter werkt dan Docker.
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Stackoverflow heeft storing, drie jaar geleden was dat een probleem geweest, vandaag is dat een "oeps, ach ja, chatGPT waar waren we gebleven?"
Allejezus wat een godganze klotetool is de git command line ook. /rant
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Heb je hier wat aan? https://github.com/nvbn/thefuck.oisyn schreef op woensdag 11 juni 2025 @ 10:40:
Allejezus wat een godganze klotetool is de git command line ook. /rant
🇪🇺 pro Europa! | Dit was niet mijn kabinet!
Not really. Ik heb een rebase gedaan met merge conflicts, maar een van de files is een binary file en ik wil gewoon "ours" pakken. mergetool heb ik niets aan want het is een binary file. git merge of git rebase met een merge strategy is het blijkbaar al te laat voor want ik zit al in een rebase. git status zegt "first resolve conflicts". JA HOE DAN ACHTELIJKE TORVALDS DEMON SPAWNRhapsody schreef op woensdag 11 juni 2025 @ 10:44:
[...]
Heb je hier wat aan? https://github.com/nvbn/thefuck
.edit: oh, git checkout --ours dus. Ja, heel logisch

.edit2: oh en dán nog eens een git add.
[ Voor 8% gewijzigd door .oisyn op 11-06-2025 10:57 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
git checkout --ours, of theirs dus. En uiteraard niet vergeten dat bij een rebase ours en theirs soort van "omgedraaid" zijn. Ours is immers de branch die je hebt opgegeven bij git rebase. (Terwijl bij een merge theirs juist de opgegeven branch is)..oisyn schreef op woensdag 11 juni 2025 @ 10:53:
[...]
Not really. Ik heb een rebase gedaan met merge conflicts, maar een van de files is een binary file en ik wil gewoon "ours" pakken. mergetool heb ik niets aan want het is een binary file. git merge of git rebase met een merge strategy is het blijkbaar al te laat voor want ik zit al in een rebase. git status zegt "first resolve conflicts". JA HOE DAN ACHTELIJKE TORVALDS DEMON SPAWN
Edit:
Ja logisch. Want als je wijzigingen doet moet je die ook adden aan de staging area. En checkout is natuurlijk ook gewoon een wijziging en dat je een checkout --ours/theirs doet betekent niet dat die wijziging definitief is. Misschien wil je die file als basis nemen en vervolgens toch nog met de hand wat wijzigingen doen (of bv een tool over de file draaien die wijzigingen doet)..edit2: oh en dán nog eens een git add.
[ Voor 22% gewijzigd door RobertMe op 11-06-2025 11:01 ]
Of je schrijft gewoon in 1x goede code en bestaat je repository uit één enkele commit..oisyn schreef op woensdag 11 juni 2025 @ 10:40:
Allejezus wat een godganze klotetool is de git command line ook. /rant
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Soms wil je je probeersels wel bewaren. Dat lukt niet als je steeds --amend gebruikt.
let the past be the past.
Maar dan schrijf je dus niet in 1x goede code.SPee schreef op woensdag 11 juni 2025 @ 11:47:
Dat lukt niet als je steeds --amend gebruikt.
Ipsa Scientia Potestas Est
NNID: ShinNoNoir
Ik word altijd zenuwachtig als code in een keer doet wat het moet doen. Dan zit ik langer te debuggen om er achter te komen wat ik gemist heb.RayNbow schreef op woensdag 11 juni 2025 @ 11:32:
[...]
Of je schrijft gewoon in 1x goede code en bestaat je repository uit één enkele commit.
Anyone who gets in between me and my morning coffee should be insecure.
Daarvoor heb je het reflog, en zolang de vuilnisman nog niet langs is geweest kun je die commits nog gewoon inzienSPee schreef op woensdag 11 juni 2025 @ 11:47:
Soms wil je je probeersels wel bewaren. Dat lukt niet als je steeds --amend gebruikt.
Dat doe ík wel maar dan blijkt dat ik weer moet mergen met de inferieure code van anderenRayNbow schreef op woensdag 11 juni 2025 @ 11:32:
[...]
Of je schrijft gewoon in 1x goede code en bestaat je repository uit één enkele commit.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Dan had je dus toch --theirs moeten gebruiken en niet ours. Want nu heb je juist de code binary file van die anderen behouden..oisyn schreef op woensdag 11 juni 2025 @ 13:06:
[...]
Dat doe ík wel maar dan blijkt dat ik weer moet mergen met de inferieure code van anderen
Of dat het framework dat je gebruikt toch niet voldoet en je alles herschrijft naar een ander framework..oisyn schreef op woensdag 11 juni 2025 @ 13:06:
[...]
Dat doe ík wel maar dan blijkt dat ik weer moet mergen met de inferieure code van anderen
Dezelfde perfecte code, maar dan op andere manier.
Of gewoon gewoon meer perfecte code toevoegen.
let the past be the past.
Nu we het toch over git en command-line hebben. Wisten jullie dat je meerdere branches tegelijk checked out kunt hebben binnen dezelfde repository? En dat je bij mergen/rebasen niet steeds hetzelfde opnieuw hoeft te doen?
In dit geval was die binary een screenshot van een test-situatie, waarbij ik de test sowieso opnieuw moet runnen nadat de code gemerged is, waar mogelijk een verandering uit komt, en dan wil ik die verandering comparen met wat er in de repo staat en niet wat ik eerder heb gegenereerdRobertMe schreef op woensdag 11 juni 2025 @ 13:09:
[...]
Dan had je dus toch --theirs moeten gebruiken en niet ours. Want nu heb je juist de code binary file van die anderen behouden.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Mijn werkgever is helemaal hoteldebotel van Claude in combinatie met MCP servers. Hij heeft in 3 dagen zelf een repository de grond uit gestampt met een project waar hij normaal maanden over zou doen (naar eigen zeggen).
Enfin, iedereen wordt dus geënthousiasmeerd om het ook eens te gaan proberen, dat 'vibe-coden'.
Iedereen is natuurlijk wel bekend met hoe LLM's helemaal los lijken te gaan als je ze teveel ruimte geeft daarom werden er uitgebreide tips gegeven. Hier een beetje in het kort:
Laat de LLM eerst de code documenteren. Alle libraries afzonderlijk.
Maak een project binnen Claude en een standaard prompt waarin je vertelt om de docs eerst te lezen.
Dan vragen om een plan te maken met wat je voor mekaar probeert te krijgen en dat plan op laten schrijven in kleine stappen en dat dan ook weer op te slaan op disk.
Vervolgens binnen het project steeds nieuwe 'chats' beginnen en 'm steeds 1 stap laten uitvoeren en controleren.
Rinse and repeat.
Nou, ik heb het een week een kans gegeven en ik kan nou niet echt zeggen dat ik het gevoel heb dat ik sneller ga. Ja, er wordt zeker meer code geproduceerd, maar ik ben godganse tijd bezig om dat kreng terug te fluiten. Ik krijg het gewoon niet goed werkend. Je moet echt goed op blijven letten wat de code precies doet. Als ik het niet zelf schrijf verlies ik het overzicht een beetje en voor ik het weet heb ik weer een bak overengineered bende die verder eigenlijk niet eens echt goed is.
Ik geloof het allemaal wel. Ik ga gewoon weer verder zoals ik het altijd al deed.
Tenslotte ook maar eens een blik geworpen op die wonder repo van hem en man man man....
Heel veel onzin code die vooral andere onzin code bezighoudt en daarom niet echt meteen duidelijk te detecteren als dode code, maar het zit vol met dat soort 'eilandjes'.
Talloze onnodige vistors en adapters, implementatiedetails gedupliceerd all over the place en ga zo maar door. Minimal api's en controllers dwars door elkaar. Het is zo'n grote troep dat ik zelf het gewoon opnieuw zou schrijven.
Alle unit tests harken zelfs in de database.
Maar goed, hij is er heel blij mee. Het doet functioneel wat hij heeft gevraagd en daarmee is het dus geweldig. Ik kreeg dus de vraag of ik er toch niet nog een keer verder mee wilde experimenteren.
Neen was mijn antwoord. Ik ben echt niet zo'n oude lul die niet mee wil gaan met de laatste dingen hoor, maar het is er gewoon nog lang niet. Het is leuk om snel snippet te laten schrijven als je heel specifiek bent of een wat 'grotere' vraag te stellen en dat dan wel of niet gebruiken ter inspiratie, maar daar houdt het op het moment voor mij wel een beetje op.
Enfin, iedereen wordt dus geënthousiasmeerd om het ook eens te gaan proberen, dat 'vibe-coden'.
Iedereen is natuurlijk wel bekend met hoe LLM's helemaal los lijken te gaan als je ze teveel ruimte geeft daarom werden er uitgebreide tips gegeven. Hier een beetje in het kort:
Laat de LLM eerst de code documenteren. Alle libraries afzonderlijk.
Maak een project binnen Claude en een standaard prompt waarin je vertelt om de docs eerst te lezen.
Dan vragen om een plan te maken met wat je voor mekaar probeert te krijgen en dat plan op laten schrijven in kleine stappen en dat dan ook weer op te slaan op disk.
Vervolgens binnen het project steeds nieuwe 'chats' beginnen en 'm steeds 1 stap laten uitvoeren en controleren.
Rinse and repeat.
Nou, ik heb het een week een kans gegeven en ik kan nou niet echt zeggen dat ik het gevoel heb dat ik sneller ga. Ja, er wordt zeker meer code geproduceerd, maar ik ben godganse tijd bezig om dat kreng terug te fluiten. Ik krijg het gewoon niet goed werkend. Je moet echt goed op blijven letten wat de code precies doet. Als ik het niet zelf schrijf verlies ik het overzicht een beetje en voor ik het weet heb ik weer een bak overengineered bende die verder eigenlijk niet eens echt goed is.
Ik geloof het allemaal wel. Ik ga gewoon weer verder zoals ik het altijd al deed.
Tenslotte ook maar eens een blik geworpen op die wonder repo van hem en man man man....
Heel veel onzin code die vooral andere onzin code bezighoudt en daarom niet echt meteen duidelijk te detecteren als dode code, maar het zit vol met dat soort 'eilandjes'.
Talloze onnodige vistors en adapters, implementatiedetails gedupliceerd all over the place en ga zo maar door. Minimal api's en controllers dwars door elkaar. Het is zo'n grote troep dat ik zelf het gewoon opnieuw zou schrijven.
Alle unit tests harken zelfs in de database.
Maar goed, hij is er heel blij mee. Het doet functioneel wat hij heeft gevraagd en daarmee is het dus geweldig. Ik kreeg dus de vraag of ik er toch niet nog een keer verder mee wilde experimenteren.
Neen was mijn antwoord. Ik ben echt niet zo'n oude lul die niet mee wil gaan met de laatste dingen hoor, maar het is er gewoon nog lang niet. Het is leuk om snel snippet te laten schrijven als je heel specifiek bent of een wat 'grotere' vraag te stellen en dat dan wel of niet gebruiken ter inspiratie, maar daar houdt het op het moment voor mij wel een beetje op.
Lekker op de bank
Ik vond volgend artikel ook erg goed beschrijvend wat de limieten zijn van AI assistents, en hoe je met die beperkingen goed omgaat om er optimaal gebruik van te maken. https://blog.thepete.net/...-wrong-and-how-to-fix-it/
tl;dr Hoe vager de requirements, hoe meer je het gevoel krijgt dat de AI er niets van kan
.
tl;dr Hoe vager de requirements, hoe meer je het gevoel krijgt dat de AI er niets van kan
@ZaZ er is naar mijn mening wel een groot verschil tussen 'vibe-coden' en zelf programmeren mbv een AI tool. Bij vibe-coden kijk je puur functioneel en moet je vooral niet naar de code gaan kijken. Ideaal voor prototypen of iets van een hobby projectje maar niet iets wat je live op productie moet willen zetten. Als ik zie wat een van onze product owners in een paar minuten tevoorschijn tovert met een tool als v0 is dat heel indrukwekkend. Je hebt letterlijk met een prompt van een paar zinnen in een minuut een volledig functionerende applicatie. En dat werkt toch fijner dan een paar screenshotjes in een user story 
Ik heb zelf de laatste weken/maanden veel getest met de verschillende GitHub Copilot opties icm VS Code en het is een nieuwe techniek die je je eigen moet maken, maar als je het een beetje in de vingers hebt kan je er veel winst mee boeken. En dat zit dan voornamelijk in de simpele, saaie dingen zoals documenteren van code, boilerplate code, unit tests. Als je dat een beetje slim inzet heb je zelf meer tijd voor de leuke dingen. En de ontwikkeling gaat nog steeds snel, iedere maand worden de tools en modellen beter dus ik ben er van overtuigd dat iedereen vroeg of laat mee zal gaan.
AI tools zullen developers niet snel vervangen, maar als je als developer niet met de tools om leert gaan, zul je op een gegeven moment wel vervangen worden door schoolverlaters die je aan alle kanten voorbij rennen en een stuk goedkoper zijn. Vergelijk het met code schrijven in notepad versus een fatsoenlijke IDE gebruiken.
Ik heb zelf de laatste weken/maanden veel getest met de verschillende GitHub Copilot opties icm VS Code en het is een nieuwe techniek die je je eigen moet maken, maar als je het een beetje in de vingers hebt kan je er veel winst mee boeken. En dat zit dan voornamelijk in de simpele, saaie dingen zoals documenteren van code, boilerplate code, unit tests. Als je dat een beetje slim inzet heb je zelf meer tijd voor de leuke dingen. En de ontwikkeling gaat nog steeds snel, iedere maand worden de tools en modellen beter dus ik ben er van overtuigd dat iedereen vroeg of laat mee zal gaan.
AI tools zullen developers niet snel vervangen, maar als je als developer niet met de tools om leert gaan, zul je op een gegeven moment wel vervangen worden door schoolverlaters die je aan alle kanten voorbij rennen en een stuk goedkoper zijn. Vergelijk het met code schrijven in notepad versus een fatsoenlijke IDE gebruiken.
Kater? Eerst water, de rest komt later
Van "shit, ik moet weer op jacht", naar 2 aanbiedingen...
Veel nadenken en voor en nadelen afwegen volgende week
Veel nadenken en voor en nadelen afwegen volgende week
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Ik heb voor mijn privé projecten ook Copilot aan staan. Maar als ik een regel zonder wil typen, maar eerst wil uitlijnen, moet ik elke tab die suggestie weer wegklikken. Zeer vervelend dat ze die tab als activator hebben gebruikt. Blijkbaar kun je dat wel in een verborgen setting aanpassen, dus dat ga ik nog doen.Haan schreef op vrijdag 13 juni 2025 @ 09:15:
@ZaZ er is naar mijn mening wel een groot verschil tussen 'vibe-coden' en zelf programmeren mbv een AI tool. Bij vibe-coden kijk je puur functioneel en moet je vooral niet naar de code gaan kijken. Ideaal voor prototypen of iets van een hobby projectje maar niet iets wat je live op productie moet willen zetten. Als ik zie wat een van onze product owners in een paar minuten tevoorschijn tovert met een tool als v0 is dat heel indrukwekkend. Je hebt letterlijk met een prompt van een paar zinnen in een minuut een volledig functionerende applicatie. En dat werkt toch fijner dan een paar screenshotjes in een user story
Ik heb zelf de laatste weken/maanden veel getest met de verschillende GitHub Copilot opties icm VS Code en het is een nieuwe techniek die je je eigen moet maken, maar als je het een beetje in de vingers hebt kan je er veel winst mee boeken. En dat zit dan voornamelijk in de simpele, saaie dingen zoals documenteren van code, boilerplate code, unit tests. Als je dat een beetje slim inzet heb je zelf meer tijd voor de leuke dingen. En de ontwikkeling gaat nog steeds snel, iedere maand worden de tools en modellen beter dus ik ben er van overtuigd dat iedereen vroeg of laat mee zal gaan.
AI tools zullen developers niet snel vervangen, maar als je als developer niet met de tools om leert gaan, zul je op een gegeven moment wel vervangen worden door schoolverlaters die je aan alle kanten voorbij rennen en een stuk goedkoper zijn. Vergelijk het met code schrijven in notepad versus een fatsoenlijke IDE gebruiken.
let the past be the past.
Klopt ik heb daarvoor het pijltje naar rechts geconfigureerd. Andersom is het ook irritant, dan wil je de suggestie wél, maar staat er ondertussen ook een standaard autocompleet-dingetje open en dan gebruikt hij dat ipv de copilot suggestie, die je dan vervolgens kwijt bentSPee schreef op vrijdag 13 juni 2025 @ 11:23:
[...]
Ik heb voor mijn privé projecten ook Copilot aan staan. Maar als ik een regel zonder wil typen, maar eerst wil uitlijnen, moet ik elke tab die suggestie weer wegklikken. Zeer vervelend dat ze die tab als activator hebben gebruikt. Blijkbaar kun je dat wel in een verborgen setting aanpassen, dus dat ga ik nog doen.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Als je zelf een stukje typt komt de suggestie (vaak) weer terug. Ik vind dat je sowieso betere suggesties krijgt als je zelf het begin typt, dan wordt het aangevuld in de zelfde stijl..oisyn schreef op vrijdag 13 juni 2025 @ 14:10:
[...]
Klopt ik heb daarvoor het pijltje naar rechts geconfigureerd. Andersom is het ook irritant, dan wil je de suggestie wél, maar staat er ondertussen ook een standaard autocompleet-dingetje open en dan gebruikt hij dat ipv de copilot suggestie, die je dan vervolgens kwijt bent
Gewoon CoPilot niet gebruiken...?
A real copilot, on a commercial airline? They know the plane. The systems. They’ve done the simulations. They go through recertification. When they speak, it’s to enhance the pilot... Not to shotgun random advice into the cockpit and eject themselves mid-flight.
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
Zo is het met het stenenbijl ook gegaan. Destijds "state of the art" gereedschap.....
Wie du mir, so ich dir.
Niet helemaal.eheijnen schreef op dinsdag 17 juni 2025 @ 09:04:
[...]
Zo is het met het stenenbijl ook gegaan. Destijds "state of the art" gereedschap.....
Of, preciezer, helemaal niet.
Alle zinloze "AI" en "LLM" systemen hebben alleen maar bewezen dat hun gebruikers minder zelfstandig kunnen denken.
Het dichtste bij een vergelijking zou zijn IDE versus Kate. En zelfs dan, komt het nog niet in de buurt van het weghalen van zelfstandig denken.
Als dit geblaat over AI echt zo geweldig was als sommigen mij willen laten geloven, dan zou ik niet zo veel AI code hoven te debuggen en problemen op te lossen die volledig ontstaan zijn door blind copy-pasten van foutieve, door bugs omringde code.
Een blinde copy-paste van StackOverflow bevat tenminste nog een gedachtengang van de schrijver.
De horror-verhalen over de ecologische rampen die sommigen "LLM" noemen, of de vergelijking met een (steen)bijl, maken mij niet meer enthousiast.
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
AI-assisted programmeren is een nieuwe tool die je moet leren / leren waarderen. Het is geen magie, gewoon een (bijzonder krachtig) hulpmiddel dat op de juiste manier ingezet moet worden.
Om te vergelijken met normaal gereedschap kan een elektrische multi-tool in de handen van een onervaren klusser ook vreselijk veel schade aanrichten, maar in de handen van een klusjesman die weet wat hij doet enorm veel tijd besparen tov de klusjesman die met handzaag en beitels aan de slag gaat.
Om te vergelijken met normaal gereedschap kan een elektrische multi-tool in de handen van een onervaren klusser ook vreselijk veel schade aanrichten, maar in de handen van een klusjesman die weet wat hij doet enorm veel tijd besparen tov de klusjesman die met handzaag en beitels aan de slag gaat.
Kater? Eerst water, de rest komt later
De tijd gaat vooruit (windmolen, stoommachine, zo maken ze op vandaag niet meer, etc.)...Firesphere schreef op dinsdag 17 juni 2025 @ 13:25:
[...]
Niet helemaal.
Of, preciezer, helemaal niet.
Alle zinloze "AI" en "LLM" systemen hebben alleen maar bewezen dat hun gebruikers minder zelfstandig kunnen denken.
Het dichtste bij een vergelijking zou zijn IDE versus Kate. En zelfs dan, komt het nog niet in de buurt van het weghalen van zelfstandig denken.
Als dit geblaat over AI echt zo geweldig was als sommigen mij willen laten geloven, dan zou ik niet zo veel AI code hoven te debuggen en problemen op te lossen die volledig ontstaan zijn door blind copy-pasten van foutieve, door bugs omringde code.
Een blinde copy-paste van StackOverflow bevat tenminste nog een gedachtengang van de schrijver.
De horror-verhalen over de ecologische rampen die sommigen "LLM" noemen, of de vergelijking met een (steen)bijl, maken mij niet meer enthousiast.
En ook al is dit niet de heilige graal zoals het aangekondigd werd, is dit zeker een blijvertje en zullen we er nog wel meer van zien.
Zoals meerdere mensen al aangeven kan dit een handige aanvulling zijn maar ook weer geen vervanging voor hoger geschoolde expertise.
Wie du mir, so ich dir.
Hier nog een aardig artikel dat een aantal voor- en nadelen benoemt: https://engineering.leani...99t-grow-great-engineers/
Kater? Eerst water, de rest komt later
Ik wacht op het moment dat we een LLM niet meer op nieuwe, menselijke, data kunnen trainen. Want als al die data die een LLM nu uitspuugt (al dan niet aangepast) op het internet komt, gaat het uiteindelijk geen betere gebruikerservaring(en) geven: een LLM wordt dan gedeeltelijk getrained door eigen data. Dat zal vast goed gaan.
Ik sluit me dan ook gedeeltelijk aan bij @Firesphere. Een LLM als techniek kan veel toffe dingen (een soort verlengde van NLP), maar het kan ook heel veel niet. Intelligent zijn bijvoorbeeld. Het hele gedoe dat een LLM veel meer stroom verbruikt landt nog niet bij het gros van de mensen, maar dat gaat na deze hele hype nog wel komen. Dan is de storm voorbij en zal het wel mee gaan vallen.
“AI” ontkom je niet aan, denk ik, maar het er mee om gaan, of slim kunnen ontwijken van, is veel belangrijker. Ik snap de hype van vibe coding ed ook niet, want het voelt voor mij alsof ik een incompetente dev naast mij heb zitten die ik beetje bij beetje de goede kant op duw, laat mij het dan maar zelf doen.
Ik sluit me dan ook gedeeltelijk aan bij @Firesphere. Een LLM als techniek kan veel toffe dingen (een soort verlengde van NLP), maar het kan ook heel veel niet. Intelligent zijn bijvoorbeeld. Het hele gedoe dat een LLM veel meer stroom verbruikt landt nog niet bij het gros van de mensen, maar dat gaat na deze hele hype nog wel komen. Dan is de storm voorbij en zal het wel mee gaan vallen.
“AI” ontkom je niet aan, denk ik, maar het er mee om gaan, of slim kunnen ontwijken van, is veel belangrijker. Ik snap de hype van vibe coding ed ook niet, want het voelt voor mij alsof ik een incompetente dev naast mij heb zitten die ik beetje bij beetje de goede kant op duw, laat mij het dan maar zelf doen.
[ Voor 17% gewijzigd door sky- op 17-06-2025 17:22 ]
don't be afraid of machines, be afraid of the people who build and train them.
AI helpt soms, geen complete rocket science maar het scheelt me wel typen. Dat is lekker. Maar te vaak zitten er nog fouten in. En aanpassen van bestaande functies gaat ook nog niet altijd even lekker. Of hij (?) komt met een oplossing, zeg ik: dat mag niet, zegt ie vrolijk: ja klopt, dat mag niet. Stel het dan niet voor
Ben het wel eens met @sky- dat het wel zorgelijk is dat ze straks getraind worden met hun eigen output, waardoor je eigenlijk alleen maar meer fouten gaan genereren.


Ben het wel eens met @sky- dat het wel zorgelijk is dat ze straks getraind worden met hun eigen output, waardoor je eigenlijk alleen maar meer fouten gaan genereren.
Exact expert nodig?
Het probleem is toch dat die LLM helemaal niks snapt en ook niks valideert? Hij lult gewoon met je mee. Jij zegt "mag niet" waaroo de LLM antwoordt met "inderdaad", omdat zoiets nu eenmaal vaak voor komt in "opvolging van woorden".Crazy D schreef op dinsdag 17 juni 2025 @ 20:35:
AI helpt soms, geen complete rocket science maar het scheelt me wel typen. Dat is lekker. Maar te vaak zitten er nog fouten in. En aanpassen van bestaande functies gaat ook nog niet altijd even lekker. Of hij (?) komt met een oplossing, zeg ik: dat mag niet, zegt ie vrolijk: ja klopt, dat mag niet. Stel het dan niet voor![]()
Dat is gewoon hetzelfde als wat hier een paar weken terug langs kwam. Link naar Reddit draadje dat weer linkte naar .NET GitHub waarbij MS aan Copilot vraagt om tickets op te lossen. En Copilot keer op keer komt aanzetten met "oplossingen" waarbij de unit tests falen (of die zelfs nieuwe unit tests files maakte, maar niet in de project file toevoegde en dus niet eens werd uitgevoerd). En elke keer als iemand antwoordde met "de tests mislukken, kun je het oplossen?" volgde een "Je hebt gelijk. Ik heb het nu opgelost" en werkte de tests nog steeds niet (al dan niet andere fouten). Ergo: het ding heeft geen enkel begrip van wat gevraagd wordt en gooit gewoon nieuwe / andere code over de schutting heen ("in de hoop dat die de vraag beantwoordt").
Let op:
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.
Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.