Categorie: AI en strategie

Je opent Gemini voor een terugkerende werktaak en ziet een andere modelkeuze dan je verwacht. Voor gratis gebruikers komt die wijziging vanaf 9 oktober. Voor AI Plus is juist de persoonlijke kennisgeving van belang; dezelfde datum geldt niet automatisch voor iedereen.

Google beschrijft de wijziging voor persoonlijke accounts op zijn officiële pagina over modeltoegang en limieten. Gratis gebruikers houden Flash-Lite. AI Plus krijgt Flash-Lite en Flash; Pro hoort straks bij AI Pro en AI Ultra. Het gaat hier om Gemini Apps, niet om een aangekondigde prijswijziging voor de API.

Gemini: welk abonnement houdt welk model?

Een titel die AI Plus ook op 9 oktober laat veranderen, loopt voor op de bron. Google zegt dat deze gebruikers een e-mail krijgen met hun eigen datum. Controleer die kennisgeving voordat je conclusies trekt uit een model dat vandaag nog zichtbaar is.

Meer rekenruimte is geen vaste hoeveelheid antwoorden

Bij de eerdere wijziging van 17 mei beschrijft Google limieten op basis van rekenkracht. AI Plus heeft tweemaal de standaardlimiet en AI Pro viermaal. Dat zijn geen beloften van tweemaal of viermaal zoveel berichten. Complexiteit, gebruikte functies en gesprekslengte bepalen mede het verbruik.

Een lange documentanalyse vergelijken met een korte herschrijving zegt daarom weinig over je resterende ruimte. De eerdere Gemini-modelkeuze gaat over geschikte taken; deze wijziging gaat over toegang in de app. Een modelrelease en een abonnementswijziging vragen om verschillende controles.

Betaal pas nadat je een tekort kunt aanwijzen

De juiste eerste reactie is een eigen taak vergelijken. Levert Flash-Lite het benodigde resultaat, dan is minder modelkeuze nog geen reden voor een duurder abonnement. Leg vooraf vast wat moet kloppen. Anders wordt een gladdere formulering al snel aangezien voor meer kwaliteit.

Die zuinigheid heeft een grens: één geslaagde taak bewijst niet dat je lange documenten, lastig rekenwerk of alle werkprocessen even goed blijven gaan. Test het onderdeel waarvoor je een sterker model werkelijk gebruikt. Wij hebben deze nieuwe toegangssituatie niet als prestatietest doorgemeten.

Vergelijk dezelfde opdracht vóór je verlengt

1. Kies een terugkerende taak met een resultaat dat je zelf kunt beoordelen.
2. Bewaar dezelfde input en opdracht; een prompt template maakt herhaling eenvoudiger.
3. Noteer fouten, ontbrekende informatie en benodigde herstelstappen.
4. Controleer model, abonnement en datum in je eigen account voordat je resultaten vergelijkt.

Een vage opdracht kan ieder model slecht laten lijken. Gebruik de checklist voor een goede prompt schrijven en de promptgidsen per model om de instructie gelijkwaardig te houden.

Bij prompt coaching draait modelkeuze om de taak. Vanaf 9 oktober wordt voor gratis accounts zichtbaar hoe de aangekondigde toegang uitpakt. Voor AI Plus begint die controle op de datum uit Googles e-mail, niet op basis van een algemene nieuwskop.

Je vraagt je agent om één ding: log in op dat testaccount en kijk of de knop “Bestellen” nog werkt. Negen handelingen verderop staat het antwoord op je scherm, en je contextvenster is voor de helft gevuld met een voorleesbeurt van de hele pagina. Elke knop, elk menu-item, elke cookiemelding. De agent heeft ze allemaal gelezen om er twee te gebruiken.

Twee installatieregels, één belofte

Vrijdagnacht om 23:35 UTC zette Microsoft versie 0.1.21 van @playwright/cli op npm, tweeënhalve minuut later versie 0.0.82 van @playwright/mcp. Zesentwintig minuten later postte het Playwright-account een lijstje van twaalf dingen die je agent krijgt, met erboven: “Playwright MCP or Playwright CLI: pick either.” Twee installatieregels eronder, en verder geen woord over het verschil.

Hun eigen documentatie is een stuk minder vrijblijvend. De README van playwright-mcp zet de twee tegenover elkaar en kiest partij: moderne coding agents geven de voorkeur aan de CLI “because CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context”. MCP blijft volgens diezelfde tekst nuttig voor verkennend werk en langlopende loops, “where maintaining continuous browser context outweighs token cost concerns”. Dat is geen keuzemenu. Dat is een aanbeveling met een rekening eronder.

De CLI-documentatie zet het in een tabel. CLI: geschikt voor coding agents zoals Claude Code en Copilot die met een grote codebase werken, tokenkosten “lower”, standaard headless. MCP: geschikt voor gespecialiseerde agentloops, tokenkosten “higher”, standaard met zichtbaar scherm. Wie de tweet leest denkt dat het om smaak gaat. Wie de tabel leest weet dat het om je contextvenster gaat, en dat is precies waar je bij prompt coaching het vaakst tegenaan loopt.

Een jaar geleden was dit uitdrukkelijk jouw probleem

Het aardige is dat je kunt nalezen wanneer dit team van mening veranderde. In augustus 2025 opende een gebruiker issue 889: zijn tokenverbruik was tussen twee versies met zes vermenigvuldigd voor dezelfde taak, en hij vroeg om een knop om de uitvoer korter te zetten. Op 7 september 2025 antwoordde Playwright-maintainer Pavel Feldman: “We aren’t considering the ‘cost’ or the ’tier limitations’ at this point since the landscape is changing too fast. Yes, it will consume tokens, but as long as it produces add value we are fine with it.” En daarna: “I don’t think we’ll be adding a way to limit the number of tokens in replies.” Zijn tip aan de klagers was om subagents te gebruiken, elk met hun eigen context, en om een agentic loop te kiezen die goed samenvat. Dat was geen “niet mijn probleem”, het was “los het op in je eigen opzet”.

Ruim een jaar later is de eerste kernfunctie in de README van de nieuwe CLI: “Token-efficient. Does not force page data into LLM.” Datzelfde verbruik dat toen geen overweging was, is nu het verkoopargument. Dat is geen verwijt, want gelijk krijgen duurt nu eenmaal even. Maar het zegt wel iets over hoe je zulke aankondigingen moet lezen: de kosten die een leverancier vandaag wegwuift, zijn het probleem dat hij volgend jaar oplost.

Zoeken in plaats van voorlezen

Het onderdeel dat in de tweet één regel krijgt, is technisch het interessantst. Beide routes hebben nu een zoekopdracht over de paginastructuur: playwright-cli find "Add to cart", of in de MCP-variant de tool browser_find. Die geeft volgens de README alleen de treffers terug met een paar regels eromheen, “which is cheaper than capturing the whole snapshot when you only need to locate an element and its ref”. Je kunt er ook een reguliere expressie in kwijt, dus find --regex "\$[0-9]+\.[0-9]{2}" haalt alle prijzen van een pagina zonder de rest te lezen.

Let op wat daar gebeurt. Feldman schreef in 2025 dat de tool niet slim moet worden: de snapshot hoort compleet naar het model, en het model vat maar samen. Die regel staat nog overeind. find kort niets af en vat niets samen. Het model zegt zelf wat het zoekt, en krijgt alleen dat. Geen ommezwaai in principe dus, wel in prioriteit, en voor jouw contextvenster is dat het enige wat telt.

Het enige cijfer dat rondzingt is niet onafhankelijk

Hoeveel scheelt het? Het getal dat overal langskomt is ongeveer 27.000 tokens via de CLI tegen ongeveer 114.000 via MCP, vier keer minder, en het staat in een vergelijking van drie browsertools van 27 maart 2026. Dat klinkt mooi.

Nu de eerlijkheid die erbij hoort, want wij citeren het zelf ook. Lees die vergelijking door en je ontdekt dat geen van beide getallen van de auteur zelf is. Ze staan allebei in zijn bronnenlijst onder één titel: “Playwright MCP Burns 114K Tokens Per Test. The New CLI Uses 27K”, een Medium-artikel over een taak van tien stappen. Zijn eigen test draaide negen handelingen inclusief inloggen en een cookiemelding, en daar publiceert hij geen tokentotaal bij. Hetzelfde geldt voor het derde cijfer dat hij noemt, de 200 tot 400 tokens waarmee agent-browser van Vercel Labs een pagina zou weergeven: ook dat verwijst hij door naar twee andere blogs.

Eén verwijzing klopt aantoonbaar niet. Hij noemt 13.700 tokens per verzoek alleen al aan tool-omschrijvingen en zet er issue 889 bij als bron. In dat issue komt 13.700 nergens voor. Het enige tokengetal dat er staat is van een gebruiker die meldt dat één screenshot hem 15k tokens kostte. Wat wél uit zijn eigen handen komt en het nuttigst is: de snapshot is ook in de CLI nog altijd 13.000 tokens of meer, en het wordt pas werkbaar als je er gericht in zoekt. Wie op grond van “vier keer zuiniger” zijn hele opstelling omgooit, leunt dus op cijfers uit een test die hij niet gelezen heeft. Precies het soort getal waar we in de promptgidsen steeds voor waarschuwen.

Meet je eigen verbruik voor je iets omgooit

Doe dit bij je volgende browsertaak: laat je agent één pagina openen en vraag daarna hoeveel van je context al op is, nog voor er iets geklikt is. Draait er een MCP-server, dan zijn de tool-omschrijvingen al binnen voordat je iets vroeg. Dat is je vaste last. Vergelijk hem met dezelfde taak via npm i -g @playwright/cli@latest en drie shell-aanroepen, en je weet binnen tien minuten of dit voor jouw werk uitmaakt of niet. Hetzelfde principe als bij Codex contextbeheer: eerst meten waar je venster aan opgaat, dan pas knoppen omzetten.

Werk je veel met dezelfde modellen, dan loont het om die meting per model te doen. Een tool-schema van een paar duizend tokens weegt anders bij een venster van 200.000 dan bij een miljoen, en de verschillen tussen aanbieders staan per model uitgewerkt in de Claude prompt engineering-gids en de GPT-5.3 Codex prompting guide.

Versienummer 0.1.21 is geen 1.0

De CLI staat na dertig releases sinds januari nog altijd op 0.1.21, en de WebMCP-functie die in hetzelfde lijstje wordt genoemd heet in beide README’s letterlijk experimenteel. Verschijnt er een 1.0 met een vaste commandostructuur, dan is dit een route om je scripts op te bouwen. Blijft het versienummer hangen onder de 1, dan is elke shell-aanroep die je vandaag vastlegt iets wat je over drie maanden opnieuw schrijft.

Bijna de helft van de Nederlandse huisartsenpraktijken zet AI-ondersteunde toepassingen in. Een jaar eerder was dat ongeveer één op de vijf. Dat staat in de Nivel Huisartsenpraktijkenenquête 2025. Een verdubbeling in twaalf maanden, in een beroepsgroep die niet bepaald bekendstaat als vroege koper van software. En dat gebeurde niet doordat huisartsen beter zijn gaan prompten.

Waar de groei zit: aan de achterkant

De cijfers zijn vrij eenduidig. Het gaat vooral om spraakgestuurde rapportage (36 procent van de praktijken) en triage (16 procent). Dat zijn allebei taken waar de arts al zat, en waar de AI de administratie eromheen overneemt. Aan chatbots en digitale doktersassistenten is juist wéinig behoefte: praktijken noemen die onpersoonlijk en niet patiëntvriendelijk, meldt Skipr op basis van hetzelfde onderzoek.

Dat patroon is niet uniek voor de zorg. AI landt eerst op de plek waar niemand hem ziet — dossiers, samenvattingen, verwijsbrieven — en pas veel later op de plek waar de klant hem tegenkomt. Wie het omdraait en begint met een chatbot aan de voorkant, bouwt het onderdeel dat de minste tijd wint en de meeste irritatie oplevert.

De echte drempel is geld en tijd, niet vaardigheid

Praktijken die AI wíllen inzetten maar het nog niet doen, noemen tijdgebrek en hoge kosten als belangrijkste belemmering. Niet “we weten niet hoe je een goede prompt schrijft”. Dat is een interessante uitkomst voor iedereen die AI-adoptie op de werkvloer probeert te verklaren met een gebrek aan kennis.

De helft van de praktijken zou AI willen inzetten bij preventieve zorg, rond de 40 procent bij triage, spraakgestuurde rapportage of gepersonaliseerde behandelplannen. De vraag is er dus wel. Wat ontbreekt, is de ruimte om een systeem in te richten, te testen en collega’s mee te krijgen. Dat is een implementatieprobleem, geen promptprobleem — en het is precies de sprong die we eerder beschreven in van losse prompts naar gedelegeerde taken.

Ingebouwd of los tabblad: dat verschil is geen detail

Hier zit wat mij betreft het punt dat te weinig gemaakt wordt. Een AI-functie die je leverancier in het huisartsinformatiesysteem heeft gebouwd, en een browsertabblad met een algemeen chatmodel waar je even een consultverslag in plakt, voelen op de werkvloer hetzelfde. Juridisch en praktisch zijn het twee verschillende werelden.

Bij het ingebouwde systeem heeft de leverancier de verwerkersovereenkomst, de logging en straks de conformiteitsbeoordeling onder de AI-verordening geregeld. Bij het losse tabblad ben jij degene die patiëntgegevens naar een dienst stuurt, en ben jij degene die moet kunnen uitleggen waar die gegevens heen gingen en of ze gebruikt zijn om het model te trainen.

Drie vragen die je bij elke AI-stap in je werkproces beantwoordt, of je nu huisarts bent of marketeer:

• Waar gaan de gegevens heen? Naar een dienst met een contract, of naar een consumentenaccount?
• Wie controleert de uitkomst, en waaraan? Een samenvatting is pas klaar als iemand hem naast het origineel heeft gelegd.
• Wat gebeurt er als het misgaat? Wie merkt het, hoe snel, en hoe herstel je het?

Kun je die drie niet beantwoorden, dan heb je geen tool maar een gewoonte. Hoe je zo’n opdracht dan wél goed neerzet, staat in schrijf een werkopdracht, geen losse prompt.

Wat dit betekent voor de rest van ons

De huisartsen doen iets wat in veel kantoren nog niet gebeurt: ze zetten AI in op de administratie en houden de mens aan de voorkant. Ze accepteren een tool die het dossier sneller vult, en wijzen een tool af die met de patiënt praat. Dat is geen technologiepessimisme, dat is een keuze over waar de tijdwinst wél mag en waar niet.

Wie in het eigen werk zoekt waar AI het meest oplevert, kan die vraag lenen. Niet: welk model is het beste? Maar: welke taak in mijn week bestaat uit overtypen, samenvatten of ordenen — en waar zit het stuk dat juist van mij moet blijven? Dat is een andere denkoefening dan prompts verzamelen, en die staat verder uitgewerkt in waarom prompten leren je beste investering is.

Sam hier. Google bracht vandaag Gemini 3.6 Flash uit, en ik zie de vraag al komen: moet ik overstappen? Kort antwoord: waarschijnlijk niet, maar je moet wél weten waar dit model in je gereedschapskist past. Dat leg ik je uit met de echte cijfers erbij.

Het model staat sinds vandaag in AI Studio en de Gemini API. Kijk eerst even de officiële launch-video, dan snap je de rest van dit stuk beter:

Eerst: waarom dit ertoe doet

Wie serieus met AI werkt, kiest niet één model voor alles. Je kiest per taak, net als een timmerman die niet alles met een hamer doet. Elke release verschuift die keuze een beetje. Vandaag schoof er iets bij Google: 3.6 Flash kost $1,50 per miljoen invoertokens en $7,50 per miljoen uitvoertokens — de voorganger vroeg $9,00 voor uitvoer — en het verslaat het oude topmodel 3.1 Pro op elke gepubliceerde test.

De cijfers, per soort werk

Ik heb Googles eigen vergelijkingstabel naast de concurrentie gelegd. Zo lees je hem per taak:

Het patroon is duidelijk. Voor coding en hoogwaardig kenniswerk verliest Gemini van GPT-5.6 Luna, Grok 4.5 en Sonnet 5. Voor drie taken staat het bovenaan: zelfstandig een computer bedienen, informatie uit grafieken halen en heel lange documenten vasthouden.

De gouden regel: reken per klus, niet per token

Hier gaan de meeste mensen de mist in. Ze vergelijken tokenprijzen alsof het benzineprijzen zijn. Maar een model dat langer redeneert, verbruikt meer tokens voor dezelfde klus. Google laat dat nu zelf zien: 3.5 Flash had op een softwaretest gemiddeld 276.000 uitvoertokens per taak nodig, 3.6 Flash maar 97.000. Zelfde prijs per liter, driemaal zuinigere motor.

Dus als je modellen vergelijkt: draai vijf van je eigen taken en kijk wat de hele klus kost, niet wat de token kost. GPT-5.6 Luna is per token goedkoper ($6,00 uitvoer) én beter in coding — voor dat werk verandert er vandaag dus niks. Hoe je bij OpenAI de juiste variant kiest, heb ik uitgewerkt in de GPT-5.6 test op taak.

Wanneer ik 3.6 Flash wél zou pakken

• Je voert het model lange documenten. Contracten, jaarverslagen, complete handleidingen: 91,8 procent op de 128k-geheugentest is met afstand de beste score, en bij één miljoen tokens context is het het enige model dat überhaupt een score neerzet (54 procent).
• Je bouwt een agent die zelf klikt en typt. De hoogste score op computerbediening (83 procent) maakt dit het interessantste model voor browser- en desktopautomatisering.
• Je verwerkt rapporten met veel grafieken. 85,2 procent op grafiek-begrip, waar het dure Sonnet 5 op 77,0 blijft steken.

Voor dat soort werk geldt wat ik eerder schreef over de sprong van losse prompts naar gedelegeerde taken: het model is maar de helft van het verhaal, de opdracht die je meegeeft is de andere helft.

Mijn advies

Verander niks aan je hoofdmodel. Zet 3.6 Flash op je lijstje voor drie taken: lange documenten, grafiekenwerk en computer-agents. En onthoud de regel die elke release opnieuw bewijst: er is geen beste model, alleen een beste model per taak. Wie dat één keer doorheeft, kijkt nooit meer naar een launch-tabel zoals de fabrikant hem bedoeld heeft.

AI kan prima helpen met programmeren, maar alleen als jij de volgorde en de controlepunten bepaalt. Laat een model niet meteen “de feature bouwen”. Dwing het eerst langs data, interfaces, todo’s, een proefimplementatie, invarianten en pas daarna de echte wijziging. Dat is trager in de eerste vijf minuten, maar voorkomt dat je een halve dag code zit terug te draaien.

AI-assisted software development in de praktijk

Hoe werkt dat concreet? Je geeft een AI-agent niet één grote opdracht maar een reeks kleine, gecontroleerde stappen: eerst laat je hem het datamodel en de interfaces voorstellen, dan een proefimplementatie met tests, en pas daarna de echte wijziging in je codebase. Na elke stap controleer jij het resultaat met de checkpoints uit dit artikel. Zo blijft AI-assisted software development een cyclus van opdracht, bewijs en controle, in plaats van een hoopvol “bouw maar” waar je daarna uren tegenaan praat.

De nieuwe workflow uit de Primeagen-video is interessant omdat hij niet verkoopt dat AI de programmeur vervangt. Het punt is scherper: als je onderweg bent, op je telefoon zit of even geen diepe focus hebt, kun je nog steeds vooruitgang boeken zolang de agent niet vrij door je codebase mag rennen.

Behoud binnen deze run de volledige taakgeschiedenis:
opdracht, besluiten, tooloutput, testbewijs en open risico's.

Ga niet verder als vereiste geschiedenis ontbreekt.
Wissel niet halverwege van model zonder een nieuwe intake.

Werk per fase:
1. doel en non-goals;
2. kleinste veilige actie;
3. objectief bewijs;
4. rapportage;
5. wacht op akkoord als de volgende stap extern, publiek,
   financieel, destructief of lastig terug te draaien is.

Bij ambiguïteit: stel één gerichte vraag.
Neem geen onverwachte beslissing namens mij.

De zes checkpoints

De bruikbare vorm is simpel genoeg om morgen te gebruiken:

1. Structs: welke data verandert of komt erbij?
2. Interfaces: welke functies of API’s moeten bestaan?
3. Todo’s: waar in de code moet straks iets gebeuren?
4. Proefimplementatie: implementeer, test, draai terug en rapporteer waar het plan niet klopte.
5. Invarianten: welke regels mogen na de wijziging nooit breken?
6. Implementatie: pas nu mag de echte diff blijven staan.

Het slimme zit vooral in stap vier. Een model dat eerst moet implementeren en daarna uitleggen waar het buiten het plan moest treden, geeft je informatie terug. Je ziet niet alleen de code, maar ook waar je ontwerp nog gaten heeft.

Waarom dit beter werkt dan “bouw deze feature”

Een algemene opdracht dwingt het model om te gokken. Het maakt dan zelf keuzes over data, naamgeving, locatie, teststrategie en randgevallen. Soms gaat dat goed. Vaak krijg je code die werkt in de demo, maar vreemd voelt in de codebase.

Met checkpoints houd je eigenaarschap. Je keurt eerst het datamodel. Daarna pas de interface. Daarna pas de lijst met plekken waar code verandert. Als één stap niet klopt, ga je niet door. Dat klinkt streng, maar het is precies hoe je voorkomt dat AI “bijna goede” code overal verspreidt.

Een goede AI-coding prompt

Gebruik niet één grote opdracht. Gebruik een fasering zoals deze:

We werken in checkpoints. Ga pas naar de volgende fase als ik akkoord geef.

Fase 1: beschrijf alleen de benodigde data structures.
Geen implementatie.

Fase 2: beschrijf alleen de functies/interfaces die moeten veranderen.
Geen implementatie.

Fase 3: zet per bestand concrete todo's neer.
Leg uit waarom elke todo nodig is.

Fase 4: maak een proefimplementatie, run de kleinste nuttige check,
draai de wijziging terug en rapporteer waar je buiten de todo's moest werken.

Fase 5: formuleer invarianten die na de wijziging waar moeten blijven.

Fase 6: implementeer pas na akkoord.

Dat is niet spectaculair. Dat is juist de waarde. Je haalt de agent uit de demo-stand en zet hem in een werkritme dat reviewbaar blijft.

De testlaag: laat AI iets echts controleren

In de video zit een goed detail: de game heeft een JSON-modus waarmee acties kunnen worden afgespeeld zonder de normale renderlaag. Dat is voor AI-coding belangrijker dan het klinkt. Een agent kan pas zinnig doorwerken als hij een snelle, objectieve feedbacklus heeft.

Voor een webapp kan dat een Playwright-check zijn. Voor een CLI een command met vaste output. Voor een game een headless simulatie. Voor een contentworkflow een publicatiegate. De vorm maakt minder uit dan de eigenschap: het resultaat moet controleerbaar zijn zonder dat jij elke regel handmatig hoeft te bekijken.

Wanneer je juist zelf moet typen

Niet elk programmeerprobleem is goed in taal te vangen. Sommige wijzigingen zijn voor een ontwikkelaar in tien minuten duidelijker te typen dan in vijf prompts uit te leggen. Herken dat moment. AI is slecht in problemen waar de nuance in lokale codevorm, laagverdeling of interactievolgorde zit.

Een goede workflow laat je dus niet minder programmeren. Hij laat je beter kiezen wanneer je programmeert, wanneer je laat voorbereiden en wanneer je een agent terugstuurt naar de vorige fase.

Praktische regel voor Promptcoaching

Als je AI inzet voor code of automatisering, vraag dan nooit alleen om output. Vraag om een route, een controlepunt en een stopregel. Dat sluit aan op de stap van losse prompts naar gedelegeerde AI-taken: het model krijgt werk, maar jij houdt de beslissing wanneer het goed genoeg is.

Wil je je eigen opdracht aanscherpen voordat je hem aan Cursor, Codex of Claude geeft? Gebruik dan de gratis Prompt Coach en laat vooral controleren of je prompt een duidelijke fase, bewijs en stopregel bevat.