Pixel-telefoons, AI-labels en Windows-verbeteringen - Tweakers Podcast #439

Deze week praten Wout Funnekotter, Jurian Ubachs, Jasper Bakker en Dennis de Vries over een onverwachte Lord of the Rings-game, Microsofts belofte om Windows te verbeteren, AI-labels in Spotify, onrust bij Googles Gemini en de nieuwe Pixel 11-serie.

0:00 Intro
0:20 Opening
2:44 .post
24:32 Een 'nieuwe' LotR-game
30:00 Gaat Windows de goede kant op?
39:23 Spotify gaat AI labelen
45:52 Wat is er met Gemini aan de hand?
54:34 Wat is er nieuw aan de Pixel 11?
01:06:37 Sneak peek

Vorige .geek Volgende .geek

Door Wout Funnekotter

Hoofdredacteur

Feedback • 13-08-2026 06:00 26

13-08-2026 • 06:00

Lees meer

Saaie games, 4K-sprookjes en vakantiebespiegelingen - Tweakers Podcast #441

Saaie games, 4K-sprookjes en vakantiebespiegelingen - Tweakers Podcast #441 .Geek van 27 augustus 2026

Console-pc's, gpu-prijzen en AirPod-camera's - Tweakers Podcast #440

Console-pc's, gpu-prijzen en AirPod-camera's - Tweakers Podcast #440 .Geek van 20 augustus 2026

Audio Podcast Tweakers Podcast

Reacties (26)

26

26

6

3

0

19

Wijzig sortering

13 augustus 2026 08:39

Ik word als software ontwikkelaar zeker productiever door het gebruik van AI. Maar jullie slaan de spijker wel op de kop. Wat AI inmiddels vlekkeloos kan schrijven is exact de code die een junior normaal ook vlekkeloos zou kunnen schrijven. Maar dan 4x zo snel. Dat is voor mij (medior/senior) heel prettig omdat ik saai, simpel en repetitief werk kan laten doen. Mijn eigen brein kan dan volledig bezig zijn met ingewikkelder werk en hoe alles straks in elkaar gaat passen. Los van het echt schrijven is AI ook goed in code lezen, dus uitzoeken waar een bug vandaan komt of je werk valideren zijn dingen die erg kunnen helpen.

Als ik nu een net afgestuurde junior was zou ik er denk ik niet zo comfortabel bij zitten. AI is inmiddels best goed in programmeren, zeker als code niet enorm netjes en ondehoudbaar hoeft te zijn. Ik denk dat met name klassieke 'webdevelopment bureaus' (voor kleine informatie en eenmalige websites) hierdoor snel compleet weggevaagd zullen worden.

[Reactie gewijzigd door n9iels op 13 augustus 2026 09:44]

darkkingll @n9iels • 13 augustus 2026 09:26

Niet alleen de Junior software developer wordt er oncomfortabel door.

Ik werk als test Engineer bij een bedrijf dat sinds kort copilot toestaat en ik maak mij zorgen. Het is in die korte tijd namelijk al een aantal keren gebeurd dat mijn testen faalden. Puur omdat een developer op aanraden van AI een stukje reeds bestaande en geteste code had aangepast. Waarom? Omdat AI zei dat de door AI gedane suggestie netter was.

AI kan een erg mooi hulpmiddel zijn en zorgen voor meer productiviteit, maar ik ben bang voor de brainrot en dat mensen blind gaan vertrouwen op wat AI zegt. Op social media zie ik dat al regelmatig gebeuren.

Update: inmiddels gaan er daadwerkelijk onderdelen van de applicatie stuk doordat de (senior) developer zich liet misleiden door AI

[Reactie gewijzigd door darkkingll op 13 augustus 2026 11:28]

Fugitive2008 @n9iels • 13 augustus 2026 09:04

Ik weet niet of je ook eerder ook die mening deelde (ik niet zo, ben meer van leer maar met je handen werken) maar net voor de AI boom/hype werd er nog weleens gezegd dat kinderen op jonge leeftijd zouden moeten leren programmeren dat dit net als bv het leren van de engelse taal wat toevoegd in het leven, zie je dat dat verandert door AI en het gemak van programmeren daarmee (uiteraard kan je moeilijker code lezen wanneer je niet leert)?

@Fugitive2008 • 13 augustus 2026 09:28

Het is niet per se zo dat programmeren zelf iets toe voegt, maar het vereist wel z'n eigen manier van denken om problemen op te lossen. Programmeren is ook niet per se duizenden regeltjes code schrijven om een webpagina of applicatie te maken - in vele takken heb je al tientallen jaren met allerlei robots te maken. Die zo ver krijgen om hun taken correct uit te voeren is ook programmeren en daar is niet altijd code voor nodig, dat kan vaak visueel gedaan worden.

Ik ben nog steeds van mening dat kinderen daar eerder aan blootgesteld moeten worden. Tegenwoordig is het allemaal wat toegankelijker, maar informatica is nog steeds een ondergesteld kindje in het onderwijs, terwijl het wél een essentiëel onderdeel van het dagelijks leven is. Ik ken talloze goede programmeurs die er pas veel later (eigenlijk te laat!) in het leven mee begonnen zijn omdat ze simpelweg geen besef hadden van wat het inhield. Allemaal hebben ze bachelors/masters in dingen als taal, media, geschiedenis - geen bèta vakken. Zelf ben ik er heel vroeg mee begonnen dankzij m'n ouders (SuperLogo voor kinderen

), maar de meeste van m'n leeftijdsgenoten hadden geen flauw benul wat programmeren inhield.

Zoals @n9iels zegt kun je met AI veel boilerplate (code die een sjabloon volgt) veel rapper doen, maar je moet die code wel nog steeds kunnen lezen en begrijpen. En dat is waar de volgende generatie programmeurs simpelweg ook in getraind moet worden. De reden dat wij "oude" rotten zo veel productiever kunnen zijn is omdat we de LLM de juiste instructies kunnen geven en de uitvoer vervolgens ook kunnen controleren. We zullen uiteraard nog steeds dingen over het hoofd zien, maar juist de repetitieve code (een database model, een data structuur voor een API, een web formulier dat aan zoiets hangt, etc.) die bijna 0,0 hersencellen vereist gaat veel sneller en kan LLM 100% correct uitvoeren omdat er een duidelijk I/O pad is.

mvh @Werelds • 13 augustus 2026 13:38

Het juist sturing geven lijkt mij inderdaad de clou. Wij gaan binnenkort over op 'AI first', waar ik eerst erg terughoudend was in het gebruik van AI tools 'moet' ik nu wel.

Voor een perfect geschreven ticket met duidelijke doelen implementeert hij het allemaal prima. Maar de meeste tickets zijn niet perfect. Als senior kan ik dan de gaten invullen of prompts aansturen, als junior is dat vrijwel onmogelijk.

Net iets laten programmeren dat op het eerste gezicht deed wat ik de LLM vroeg. Een interne migratie. Maar op zo'n manier dat het later onmogelijk is om nieuw van oud te scheiden. Dus terug naar de tekentafel en het de AI opnieuw laten implementeren, met betere veiligheidshekjes (door mij geplaatst).

Als junior developer herinner ik me nog goed dat ik een keer zo'n stuk slop zelf heb geschreven. Twee klasses die ogenschijnlijk hetzelfde doel hadden, maar fundamenteel gescheiden waren en hadden moeten blijven. In een refactor-opwelling daar één van gemaakt en daarna nog jaren last gehad van het mentaal uit elkaar moeten houden van de twee concepten met dezelfde naam in dezelfde klasse.

Hoe gaat een junior die nu aan de slag gaat de juiste dieptekennis opbouwen om over 5 jaar de LLM te vertellen wat wél de juiste (in)richting is?

tweakuwe @Fugitive2008 • 13 augustus 2026 11:12

Ik denk dat het nog steeds waardevol is, op eenzelfde manier als dat het nog steeds goed is om te leren reken ondanks rekenmachines. Je leert een bepaalde manier van logisch redeneren en structureel problemen aanpakken die goed is voor je ontwikkeling als kind.

Specifieke talen en tooling leren is daarbij niet zo belangrijk. Maar algoritmisch te werk gaan zou ergens tussen algebra (werken met variabelen, zoals x en y) en calculus (limieten, afgeleiden, etc.) moeten zitten in het onderwijs.

Wo3ps @n9iels • 13 augustus 2026 10:32

"Wat AI inmiddels vlekkeloos kan schrijven is exact de code die een junior normaal ook vlekkeloos zou kunnen schrijven"

Ik zie deze opmerking vaker maar mijn eigen ervaring is daar toch anders is. Vaak zie ik dat AI gewoon code blijft toevoegen tot dat het werkt. (of in elkgeval lijkt dat het werkt)

Dat is naar mijn mening niet "vlekkeloos" nog de code die onze juniors zouden schrijven (al hebben ik er een paar die daar ook een handje van hebben)

Edit: Maar als het voor anderen werkt, dat is dan mooi.

[Reactie gewijzigd door Wo3ps op 13 augustus 2026 10:34]

StarZ @n9iels • 13 augustus 2026 13:16

Je kunt code redelijk goed testen met tests maar tests testen ook maar wat van te voren gedefineerd is.

Ik merk dat ik steeds meer mensen zie die duidelijk een lijn trekken tussen iets wat we door mensen willen laten doen: journalistiek, kunst, muziek en iets wat we anders beoordelen en eigenlijk prima vinden om door AI te laten doen zoals code.

Terwijl ik soms denk dat code toch ook een kunst vorm kan zijn, denk alleen al aan Wikipedia: Fast inverse square root

en daar buiten ben ik bang dat AI zorgt voor meer van hetzelfde en waar voor echte voortgang echt ook mensen werk nodig is.

Het kan ook zijn dat ik gewoon een beetje verdrietig ben dat mijn passie en beroep dus schijnbaar zo makkelijk te vervangen is.

Neemt niet weg dat ik als sr software engineer ook veelvoudig gebruik maak van AI, zeker om de zoveelste API client te maken of DTO's te genereren.

[Reactie gewijzigd door StarZ op 13 augustus 2026 13:19]

brielsefie 13 augustus 2026 10:16

Als senior developer spendeer ik veel van mijn tijd in vergaderingen, of met analyses van complexe features, hier en daar een beetje management en coaching van de collega's,

De dagen dat ik echt mijn ambacht mag uitoefenen worden alsmaar zeldzamer.

Ik kan wel echt genieten van es een namiddag of als ik geluk had een paar daagjes gewoon code schrijven.

Achteruit leunen in bureaustoel en de code laten vloeien van mijn gedachten door de vingers naar het scherm en zo langzaam maar zeker in een flow raken.

Mijn 30j ervaring die komen nog van pas als ik het werk van claude review (en gelukkig vind ik nog wel regelmatig issues),

maar de eerste keren dat een nieuwe feature waar ik anders een paar uurtjes met plezier had aan gewerkt en nu in een paar minuten door claude tevoorschijn werden getoverd had ik tranen in mijn ogen en veel zin in een carriere switch.

Oja:

7u om een printer aan de praat te krijgen onder linux???? In die 15j dat ik linux als daily driver gebruik nog niet meegemaakt.

Geertje 14 augustus 2026 08:39

Ik ben ook al jaren SW dev en zo'n 6 jaar geleden geswitched van werkgever omdat onze nieuwe Amerekaanse eigenaar had begrepen dat we goedkoper konden ontwikkelen in samenwerking met een Indiaas outsourcing bedrijf.
Maar ons domein was redelijk complex, onze aansturing was ook niet goed (er zouden eigenlijk mensen van ons in India moeten zitten voor dagelijkse aansturing) en dan had je ook nog de tijdzones.
Dit leidde er uiteindelijk toe, dat ik alleen nog maar hooguit een halve dag zelf iets kon doen en de andere helft code aan het nakijken was, mailtjes/telefoontjes met wat er verbeterd moest worden en de volgende dag weer aan het nakijken was.

We zijn nu enkele maanden begonnen met AI en ik moet zeggen dat er inderdaad hele fijne dingen aan zijn: rapid prototyping, boilerplate code, intelligente find-and-replace acties, niet meer precies weten welke LINQ query je nodig hebt, dus in commentaar typen wat je wil, <Enter> en voila: er staat gelijk de juiste query, je eigen code laten reviewen op bugs, etc, etc..

Maar we hebben ook collega's die nooit iets met code gedaan hebben en een hele app vibe-code (wat er echt fantastisch en shiny uit ziet) en dan komt er een mega PR met (tien)duizenden files op het bordje van de 'echte' devs komt te liggen met 0 structuur. Of mogen de devs het 'verder ontwikkelen'.

Dit heeft wel geleid tot discussies binnen ons bedrijf hoe we hier mee omgaan.
En collega zei toen ook: de lol van dev-en is juist het puzzelen hoe je een complex probleem (zo efficient mogelijk) wil oplossen in de code.
Maar dus ook: hoe gaan we om met vibe-code. En je kunt natuurlijk via skills aangeven hoe je wil dat de code gestructureerd wordt, maar dan moeten we wel company-wide gedeelde skills hebben. Er zou een AI-stuurgroep komen...

Kom ik terug op mijn werkgever-switch: Het is vast ongegrond, want er blijven vast nog genoeg leuke uitdagingen over (en in ieder geval geen tijdzone verschil), maar ik hoop niet dat mijn werk eruit gaat zien als 6 jaar geleden, waarbij ik alleen nog maar AI-code aan het reviewen/testen ben om te kijken of het doet wat het zou moeten doen.

bigoldie 13 augustus 2026 08:48

De ondernemer die z'n bedrijf aan de werknemers heeft gegeven is Mark Vletter van het Groningse bedrijf Voys:
https://metnerdsomtafel.nl/gasten/mark-vletter

Just Me Or Tha One 13 augustus 2026 09:30

Wellicht dat ik iets mis, maar het hele verhaal met AI en junior ontwikkelaars, is dat niet eenzelfde discussie als met de rekenmachine tegenover het uit het hoofd leren / kennen van tabellen en tafels?

@Just Me Or Tha One • 13 augustus 2026 10:20

Verschil is wel dat je rekenen op school leert, waar de aandacht juist ligt op het leren. Van junior naar medior of senior groeien doe je vaak in een commerciële setting waar het commerciële belang nu steeds meer botst met het belang van de junior om te leren.

Ik ben vooral wel benieuwd hoe scholen hierop gaan inspelen. Hopelijk kunnen ze studenten de skillset meegeven waar ze juist waarde toevoegen bovenop AI.

T-men 13 augustus 2026 10:40

Ik kijk een beetje van twee kanten naar vibecoden. In mijn dagelijkse werk ben ik senior COBOL-programmeur. Als ik AI code laat genereren, werkt het vaak redelijk, maar bedrijfsstandaarden, onderhoudbaarheid en codehergebruik worden regelmatig genegeerd. Als senior krijg ik daar soms kromme tenen van. Wel moet ik erbij zeggen dat de AI-tools die wij op het werk mogen gebruiken nog vrij beperkt zijn.

Aan de andere kant ben ik privé begonnen met Home Assistant. Daar ben ik juist een complete junior. Nauwelijks kennis van Python, YAML of de interne structuur van Home Assistant. Met hulp van Gemini heb ik in korte tijd dingen gebouwd die me anders waarschijnlijk weken of maanden hadden gekost. Ging dat foutloos? Zeker niet. Soms zaten we op een dwaalspoor, maar vaak ook omdat ik zelf nog niet precies wist wat ik wilde.

Het resultaat is geen toonbeeld van software engineering, maar het doet wel wat het moet doen. Mijn grootste zorg blijft alleen: als er morgen iets kapot gaat, kan ik het dan zelf oplossen? Eerlijk gezegd niet. AI heeft me geholpen iets te bouwen, maar niet automatisch geholpen het ook echt te begrijpen. Dat is voor mij denk ik de grootste keerzijde van vibecoden.

Robbaman @T-men • 17 augustus 2026 13:54

Ik kijk een beetje van twee kanten naar vibecoden. In mijn dagelijkse werk ben ik senior COBOL-programmeur. Als ik AI code laat genereren, werkt het vaak redelijk, maar bedrijfsstandaarden, onderhoudbaarheid en codehergebruik worden regelmatig genegeerd. Als senior krijg ik daar soms kromme tenen van. Wel moet ik erbij zeggen dat de AI-tools die wij op het werk mogen gebruiken nog vrij beperkt zijn.

Maar daar zit ook de crux. Die dingen zijn alleen maar nuttig voor mensen. Als je AI-model je volledige codebase in een keer kan overzien, maakt het ook geen drol meer uit of het aan bedrijfsstandaarden voldoet, of code hergebruikt.

Met andere woorden: wat voor de gebruiker van de software belangrijk is, is of de software de juiste output en gebruikservaring geeft bij de gegeven inputs. De enige reden waarom jouw leidinggevende wil dat de code 'aan de bedrijfsstandaard' voldoet is omdat de hoop is dat andere ontwikkelaars de code dan beter snappen en (mogelijk) dat je hiervan weet dat de kans op fouten/bugs kleiner is.

Maar als AI een expert is in het opsporen van bugs en security vulnerabilities, en elke code correct kan interpreteren, dan ben je beter af met de AI vragen de gevraagde functionaliteit te implementeren op zo'n manier dat deze voor AI goed te begrijpen is, dan dat het aan je eigen zelfbedachte standaarden voldoet lijkt mij.

Mijn grootste zorg blijft alleen: als er morgen iets kapot gaat, kan ik het dan zelf oplossen? Eerlijk gezegd niet. AI heeft me geholpen iets te bouwen, maar niet automatisch geholpen het ook echt te begrijpen. Dat is voor mij denk ik de grootste keerzijde van vibecoden.

Maar ook hier geldt weer. Dan laat je AI het toch gewoon oplossen? Net zoals dat een opdrachtgever in de zakenwereld niet snapt hoe jouw code werkt, maar gewoon aan jou vraagt om ongewenst gedrag te fixen zodat het wel gewenst is.

[Reactie gewijzigd door Robbaman op 17 augustus 2026 13:55]

13 augustus 2026 10:52

Ik las zondag dit artikel op OMGUbuntu dat mooi illustreert waarom Windows wel wat geoptimaliseerd moet worden: https://www.omgubuntu.co....s-windows-weather-app-ram

Het gebruikt de weer-app als voorbeeld om te tonen hoe log en zwaar Windows geworden is. In tijden van goedkope RAM was dit misschien minder een probleem, maar het ziet er niet naar uit dat dit op korte termijn goedkoper zal worden, dus ze kunnen beter hun OS afslanken om het vlotter te laten draaien.

Zelf gebruik ik al jaren een mix van macOS, Linux en Windows. Als het kan, vermijd ik Windows.

tweakuwe @Aegir81 • 13 augustus 2026 11:34

Ik heb laatst mijn eigen weather app gevibe-code. 110MB ram, in Rust op Bazzite in een flatpack. Maar om dat nou te vergelijken met de weer apps die standaard bij OS’en in zitten dan moet je ook de features naast elkaar zetten. Dan zal mijn persoonlijke weer app erg kaal afsteken.

Download ik nu even MSN Weer (er is helemaal geen weer app inbegrepen bij Windows 11, dus ik pak maar een app die Microsoft online aanbied, daar zit je artikel de boel al lelijk te framen), dan zie ik best wat features die bijv. de standaard Mac weer app en enkele linux weer apps die ik tegenkwam niet hebben. Ook gebruikt de app ‘maar’ 600-700MB hier tenzij ik de meer complexe kaarten open en het naar in de 900mb schiet.

Ja, de weer app van Microsoft (niet van Windows) is niet geoptimaliseerd voor ram efficiëntie. Maar je zit nu ook Word met Notepad++ te vergelijken, of appels met peren.

_{Waarom een eigen app maken? Ik wou graag het dauwpunt gelijk op de ‘card’ zien bij het 14 dagen overzicht. Je eigen weer app maken is sneller dan het internet afstruinen naar een UI die doet wat ik wil.}

@tweakuwe • 13 augustus 2026 13:44

Maar je zit nu ook Word met Notepad++ te vergelijken, of appels met peren.

Het is inderdaad niet dezelfde app op de verschillende platforms, maar ik je eigen voorbeeld toon je al aan, dat wanneer iets gemaakt wordt voor een platform het veel efficiënter kan. Tegenwoordig is het gebruik van WebView2 de standaardpraktijk bij MS en als dan 1 zo'n app al richting de GB schiet, wat doet de rest dan nog?

Leuk trouwens dat je je eigen app maakte ;-)

tweakuwe @Aegir81 • 13 augustus 2026 14:07

Maar MSN weer is geen standaard Windows app. Het is een extra app die online gratis wordt aangeboden, waarom zouden ze daar moeite in stoppen? Er zijn genoeg Windows Apps die wel heel efficient zijn.

Hier op mijn werklaptop heb ik nu al vele dagen kladblok continue open staan met nu 9 tabs daarin, en het gebruikt 0,5MB ram. Boot ik mijn Linux pc (Bazzite met KDE), en start ik KWrite, Kate, en Text Editor (de drie apps die standaard mee kwamen en die geschikt zijn voor simpele notities) dan gebruiken ze respectievelijk 28,4; 38,0; en 219,7MB als ik in elk één nieuw blanco document open. Waarvan die laatste de meest bassale tekst editor is trouwens

Als je gaat cherry picken kan je altijd wel zulke artikelen schrijven. Ik kijk hier tenminste nog naar apps die daadwerkelijk met het OS zijn meegeleverd

En dan negeer ik hoe bloaty het is dat er standaard drie tekst editors worden meegeleverd op mijn distro.

Niet dat ik een fan ben van Windows. Thuis gebruik ik het vrijwel niet, alleen voor werk moet ik het gebruiken. Maar ik wel allergische voor zulke artikelen.

[Reactie gewijzigd door tweakuwe op 13 augustus 2026 14:11]

@tweakuwe • 13 augustus 2026 14:55

De bron is uiteraard OMG Ubuntu, maar zij haalden de mosterd bij https://www.windowslatest...r-and-it-still-shows-ads/ en daar vermelden ze dat het wel degelijk over een ingebouwde app gaat. Ik heb geen Windows-computer meer, dus kan het niet zelf checken.

Windows 11’s built-in Weather app is basically MSN adware wearing a forecast icon, and it uses about five times the RAM of macOS native Weather, all while showing ads on an OS you already paid for.

Joest-J 13 augustus 2026 17:47

De redenatie 'Journalistiek is het eindproduct' volg ik niet helemaal.

Het gaat toch uiteindelijk om het gepubliceerde artikel of item? Dat is hetgeen dat de lezer, kijker of luisteraar uiteindelijk voorgeschoteld krijgt, net als bij een webapplicatie of game.
Het proces wat aan zo'n item vooraf gaat is voor de eindgebruiker ook niet altijd even interessant.

En ja, als het gaat om duiding of reviews e.d. moet er een mens aan te pas komen. Maar als het gaat om het brengen van feitelijk nieuws, gebaseerd op controleerbare bronnen, zou een 'héél goede LLM' dit toch ook wel kunnen lijkt me.

Ik snap dat code een onderdeel is, maar vergelijk dat met de woorden van een artikel of item en het komt al een stuk dichter bij elkaar.

Snikker 14 augustus 2026 12:19

Ik kan heel weinig loslaten, ik denk wel duidelijk waarom, maar ik ben onderdeel van een kleine groep externe testers van een AI product van Google en de braindrain verbaasd mij niets. Al is dat bij dit project (nog) niet aan de orde.

Wat mij opvalt is de stuurloosheid en het lage tempo van ontwikkeling. Het lijkt erop dat men zich telkens op een andere specialisatie wil gaan richten, terwijl er echt mensen met een indrukwekkende staat van dienst aan werken.

Ik ben benieuwd of het ooit gaat uitkomen en in welke hoedanigheid. Indien ik er ooit meer over kan vertellen zal ik eens wat meer posten.

Jorah_Newstone 14 augustus 2026 17:55

Vanuit mijn werk schrijf ik zelf geen code maar ik gebruik wel claude code/codex om bijvoorbeeld heel snel aanpassingen aan bijvoorbeeld interne ticket systemen aan te kunnen passen, gewoon via een api. Claude heeft lees en schrijfrechten op de dev omgeving. Rapportages kan ik nu super snel rapportages en documentatie schrijven. Na even zelf checken push ik dit zo naar productie. Mijn werk is gewoon 10x sneller geworden.

Om te kunnen reageren moet je ingelogd zijn