Van modelupdate naar AI-roadmap: wat Gemini 3.5, Spark en Omni wél veranderen
Het probleem is niet nóg een modelnaam
AI-teams krijgen op dit moment geen nette rij updates voorgeschoteld. Ze krijgen bundels. In één golf verschijnen modelversies, snelle varianten, multimodale videofuncties, cloud-agents, toolprotocollen, science-toepassingen, world-model experimenten en coding-agents. Voor een product owner of technisch beslisser is dat verwarrend, omdat elk onderdeel een andere vraag oproept. Een nieuw taalmodel vraagt om evaluatie op taakniveau. Een multimodale generator vraagt om product- en rechtenvragen. Een always-on agent vraagt om infrastructuur, monitoring en toegangsbeheer. Een coding-agent vraagt om acceptatie door ontwikkelaars en integratie met repositories, tests en pull requests.
De valkuil is om elke aankondiging als een los speeltje te behandelen. Dan wordt de roadmap een verzameling experimenten zonder samenhang. Vandaag een videodemo, morgen een agent, volgende week een coding-tool. Dat voelt actief, maar het levert zelden een houdbare architectuur op. De praktische vraag is daarom niet: welk model wint? De betere vraag is: welke laag in onze AI-stack verandert hierdoor, en moeten we daar nu iets mee? Voor Funnel Adviseur is dat precies het verschil tussen hype volgen en waarde bouwen. Een roadmap hoort te laten zien welke experimenten mogen lopen, welke afhankelijkheden bewust worden geaccepteerd en welke toepassingen nog niet productiegeschikt zijn.
Laag 1: modellen en multimodaliteit vragen om andere evaluatie
Gemini 3.5 en een snelle 3.5 Flash-variant worden in de huidige updategolf genoemd als modelontwikkelingen waarbij snelheid en benchmarks een rol spelen. Voor teams is dat op zichzelf nog geen besliskader. Benchmarks kunnen nuttig zijn als eerste signaal, maar ze beantwoorden niet automatisch de vraag of een model in jouw workflow beter presteert. Een supportclassificatie, een juridische samenvatting, een RAG-zoekproces en een contentvalidatieflow hebben elk andere eisen. Denk aan fouttolerantie, contextlengte, latency, kosten per taak, auditbaarheid en de mate waarin output door mensen wordt gecontroleerd.
Multimodale video, zoals Gemini Omni in de aankondigingen wordt gepositioneerd, is nog weer een andere categorie. Tekstmodellen kun je vaak relatief gecontroleerd testen met input-outputsets. Video raakt sneller aan merkconsistentie, beeldrechten, montageprocessen, goedkeuring en publicatiekanalen. Een productteam moet dus niet alleen vragen of de output indrukwekkend is, maar ook of die output juridisch, operationeel en creatief bruikbaar is. Wie mag prompts maken? Welke assets mogen worden gebruikt? Hoe voorkom je dat een experimentele video ineens als productiecontent wordt behandeld? Multimodaliteit hoort daarom niet onder dezelfde testcriteria te vallen als chat of tekstextractie.
Laag 2: agents worden infrastructuur, geen losse prompttruc
Gemini Spark wordt genoemd als een always-on agent op Google Cloud met MCP tool support. Zelfs zonder prestatiewaarde aan die specifieke implementatie te hangen, is het signaal belangrijk: agents verschuiven richting infrastructuur. Een agent die altijd beschikbaar is en tools kan aanroepen, is geen betere chatbot. Het is een procescomponent. Zodra een agent toegang krijgt tot agenda’s, CRM-data, code, documenten, tickets of databases, verandert de vraag van promptkwaliteit naar beheersing. Welke tools mag de agent gebruiken? Onder welke voorwaarden? Met welke logging? Wie kan een actie terugdraaien? En hoe test je of de agent niet te veel autonomie krijgt in een proces dat eigenlijk menselijke controle vraagt?
MCP tool support is in dat kader interessant omdat toolkoppelingen steeds meer standaardisering vragen. Voor AI-teams betekent dit niet dat elk team meteen op hetzelfde protocol moet inzetten. Het betekent wel dat toolrechten, connectorbeheer en governance niet achteraf kunnen worden toegevoegd. Als je agents bouwt zonder toegangsmodel, bouw je technische schuld. Een nuchtere roadmap reserveert daarom tijd voor identity, permissies, observability, fallbackprocedures en menselijke goedkeuring. Pas daarna is het zinvol om te praten over schaal. De agent die in een demo moeiteloos taken uitvoert, moet in productie vooral voorspelbaar, begrensd en controleerbaar zijn.
Laag 3: coding-agents zijn een apart slagveld
Cursor Composer 2.5 en een vroege Grok Build-release worden genoemd als signalen dat coding-agents een eigen productcategorie blijven. Dat is logisch. Softwareontwikkeling is geen generieke teksttaak. Een coding-agent moet repositorycontext begrijpen, bestaande conventies volgen, tests draaien of voorbereiden, pull requests begrijpelijk maken en ontwikkelaars niet voortdurend onderbreken. De waarde zit niet alleen in codegeneratie, maar in de hele ontwikkelaarservaring. Een model kan een knappe functie schrijven en toch onbruikbaar zijn als de integratie met bestaande tooling stroef is.
Daarom moet je coding-agents anders evalueren dan algemene AI-assistenten. Kijk naar doorlooptijd per ticket, kwaliteit van tests, hoeveelheid reviewcommentaar, regressies, securityrisico’s en acceptatie door het team. Laat ontwikkelaars niet alleen stemmen op gevoel, maar meet ook waar de agent daadwerkelijk werk uit handen neemt. Een agent die kleine refactors betrouwbaar doet, kan waardevoller zijn dan een spectaculaire demo die grote features genereert maar veel correctie vraagt. Voor de roadmap betekent dit: behandel coding niet als bijlage bij de modelstrategie, maar als eigen werkstroom met eigen meetpunten.
Een praktisch roadmap-kader voor AI-teams
Een bruikbaar kader begint met drie vragen. Eén: welk concreet probleem lost deze ontwikkeling op? Niet ‘we willen iets met multimodaal’, maar bijvoorbeeld: productvideo’s sneller prototypen, interne trainingsclips samenvatten of visuele kwaliteitscontrole ondersteunen. Twee: welke lock-in ontstaat? Denk aan cloudinfrastructuur, model-API’s, toolprotocollen, dataformaten en opgebouwde prompts of evaluatiesets. Drie: welke data- en toolrechten zijn nodig? Dit is vaak de vraag die bepaalt of iets een labexperiment blijft of veilig naar productie kan.
Vertaal die vragen naar drie gecontroleerde experimenten. Kies één multimodale use-case met duidelijke input, output en goedkeuringsroute. Kies één agentworkflow waarin de agent hooguit beperkte acties mag uitvoeren en alle toolaanroepen worden gelogd. Kies één coding-agenttest op een afgebakende repository of taakcategorie. Geef elk experiment een stopcriterium en een opschalingscriterium. Stop als de foutcorrectie te hoog is, de governance onduidelijk blijft of de afhankelijkheid niet acceptabel is. Schaal pas op als de workflow aantoonbaar sneller, beter beheersbaar of consistenter wordt.
Minder launch-volgen, meer architectuurdenken
De meest spectaculaire demo bepaalt niet automatisch de AI-roadmap. De combinatie van bruikbaarheid, beheerbaarheid en afhankelijkheden bepaalt of een ontwikkeling waarde heeft. Voor AI-teams is dat misschien minder spannend dan een ranglijst met winnaars en verliezers, maar het is wel volwassener. Modelupdates, multimodale functies, cloud-agents en coding-tools horen niet in één grote experimenteerbak. Ze horen in een architectuur waarin duidelijk is welke laag je test, waarom je dat doet en welke risico’s je accepteert.
De houdbare aanpak is dus sober: volg ontwikkelingen, maar laat je roadmap niet door elke release herschrijven. Bouw evaluatiesets, leg besliscriteria vast, beperk rechten, documenteer afhankelijkheden en betrek de mensen die met de workflow moeten werken. Dan wordt AI-adoptie geen verzameling losse pilots, maar een reeks bewuste keuzes. Dat is waar de komende periode het verschil zal zitten: niet bij wie het snelst elke nieuwe naam probeert, maar bij teams die nieuwe mogelijkheden in een beheersbare architectuur kunnen plaatsen.
