Microsoft kondigt Copilot Home, Code en Autopilot aan. Daarmee komt het bouwen van applicaties en het delegeren van doorlopend werk dichter bij gewone medewerkers. Strategisch en technologisch vind ik dit voor citizen development een serieuze stap. Het prijsmodel roept bij mij meer vragen op: de mogelijkheden die de grootste verandering beloven, komen boven op de licentie via Copilot Credits.
Wat mij opvalt aan deze aankondiging
De aankondiging van Microsoft van 25 september 2026 en de bijhorende uitleg over Copilot Wave 4 is ‘packed’; een nieuwe startpagina, applicaties bouwen, agents die blijven werken, meer bedrijfscontext en nieuwe manieren om het verbruik te beheren.
Maar neem even een stap terug.
Tot nu toe kochten veel organisaties Copilot om mensen te helpen met hun bestaande werk: een document schrijven, een meeting samenvatten, een presentatie maken. Met deze aankondiging probeert Microsoft ook het vertrekpunt te worden voor het maken van nieuwe software en het organiseren van werk dat zelfstandig verderloopt.
In mijn AI-trends voor 2026 schreef ik al over Copilot als een operationele laag voor kenniswerk. Deze aankondiging maakt die richting concreter. Alleen komt er nu ook een meter naast te staan.
Wat Microsoft precies aankondigt
De belangrijkste onderdelen, met hun functie:
- Home: Chat en Cowork komen samen. Office-documenten kunnen in Copilot worden bewerkt.
- Code: Medewerkers beschrijven een app, dashboard of automatisatie. Copilot bouwt die met technologie achter GitHub Copilot. Vibe coding voor Citizens: denk Claude Code of OpenAI Codex voor iedereen in een bedrijf
- Autopilot: Scout krijgt een nieuwe naam. Een blijvende agent met eigen identiteit en geheugen voert proactief en terugkerend werk uit. Het is cloudgehost. Denk hier aan OpenClaw of Hermes.
- Bedrijfscontext en plugins: Microsoft IQ, Fabric, Dynamics en Power Platform verbreden de context. Een gedeelde plugincatalogus moet uitbreidingen beter beheersbaar maken.
Dit is een gefaseerde uitrol. Home en Code komen via Frontier; Autopilot breidt eind september uit in private preview (Microsoft-aankondiging).
Copilot Code: wat is het verschil met Codex en Claude Code?
Wie met Codex of Claude Code werkt, herkent het principe. Je beschrijft een gewenste verandering. De AI onderzoekt het project, schrijft of wijzigt code, voert stappen uit en helpt het resultaat controleren.
Software bouwen op basis van een beschrijving is dus al mogelijk. Ook voor mensen die geen professionele ontwikkelaar zijn. De interessante stap van Microsoft zit voor mij in de omgeving errond. Hoe komt een medewerker van een idee naar een bruikbare toepassing binnen de organisatie, zonder eerst hosting, toegang en beheer uit te zoeken?
Neem een accountmanager die een eenvoudige tracker voor offertes wil. In een algemene bouwtool kan hij een prototype maken. Daarna volgen andere vragen: waar draait het, wie mag de klantgegevens zien, hoe krijgen collega’s toegang, en wie houdt bij wat er gebouwd is?
De runtime is minstens even belangrijk als de codegenerator
Copilot Managed Runtime biedt Microsoft-gehoste uitvoering, Entra-identiteit, toegangsbeleid, versiebeheer en een centrale inventaris in het Microsoft 365-beheercentrum. Het ondersteunt toepassingen uit Cowork, Code en Copilot Studio, maar ook compatibele externe ontwikkeltools via een SDK. De runtime is in preview.
Voor een organisatie die al sterk op Microsoft 365 steunt, kan dat veel praktische drempels wegnemen. Voor een organisatie met een divers IT-landschap blijft het relevant om te beoordelen hoe open die aansluitingen werkelijk zijn en hoe eenvoudig een toepassing later kan worden verplaatst. Een beheerde runtime maakt de infrastructuur beter organiseerbaar. Ze bewijst op zichzelf nog niet dat de gegenereerde app inhoudelijk correct, veilig ontworpen of onderhoudbaar is.
Citizen development krijgt een andere vorm
Citizen development betekent dat medewerkers zelf toepassingen en automatisaties bouwen om hun werk te verbeteren. Vaak gebeurt dat met low-code-tools: schermen samenstellen, databronnen aansluiten en stappen in een workflow tekenen.
Copilot Code schuift een deel van dat werk naar het beschrijven van het gewenste resultaat. De medewerker hoeft minder technische bouwstappen zelf te kennen.
Voor mij wordt daarmee een andere vaardigheid belangrijker: goed kunnen uitleggen hoe het werk in elkaar zit. Wat is het probleem? Welke gegevens zijn nodig? Welke uitzonderingen bestaan er? Wat mag automatisch gebeuren? Wanneer is het resultaat goed genoeg?
Een medewerker van aankoop die die vragen helder kan beantwoorden, kan waardevol zijn als bouwer van een leveranciersdashboard. Ook wanneer hij geen programmeertaal kent.
Dat verlaagt de technische drempel. Het neemt de verantwoordelijkheid voor het resultaat niet weg. Een mooi dashboard kan verkeerde definities gebruiken. Een werkende app kan gegevens tonen aan de verkeerde collega’s. Een automatisatie kan een uitzondering verkeerd behandelen.
De medewerker wordt meer opdrachtgever en beoordelaar. IT helpt met kaders, herbruikbare bouwstenen en het beheer van wat belangrijk genoeg wordt om structureel te gebruiken.
Van schaarste aan bouwtijd naar schaarste aan aandacht
Als kleine toepassingen veel sneller ontstaan, verschuift het knelpunt. Er zullen meer apps zijn die iemand moet beoordelen, beheren en uiteindelijk weer opruimen.
De eerste versie van een offertetracker is aantrekkelijk. Maar wat gebeurt er na zes maanden? Wie past hem aan als de verkoopprocedure verandert? Wat als de maker vertrekt? Zijn er ondertussen vier trackers die hetzelfde probleem oplossen?
Daarom zou ik citizen development organiseren rond een duidelijke overgang: een persoonlijk experiment kan klein beginnen; een gedeelde toepassing krijgt een eigenaar; een bedrijfskritische oplossing vraagt structureel beheer en professionele controle.
Wordt Copilot Studio hierdoor voorbijgestoken?
Voor sommige eenvoudige vragen kan de aparte stap naar een bouwomgeving minder nodig worden. Wie een kleine interne tracker wil, zal misschien rechtstreeks in Copilot beginnen. Dat is een logische vereenvoudiging.
Maar de conclusie dat Copilot Code het agentverhaal van Copilot Studio vervangt, gaat te ver. Studio is een omgeving voor het bouwen en beheren van agents en workflows. De huidige documentatie vermeldt ook een appbouwervaring in preview. Het ondersteunt onder meer publicatie naar verschillende kanalen, evaluaties en beheer. Bovendien zijn proactieve agents ook binnen Studio mogelijk. De grenzen zijn dus nu al minder scherp dan een onderscheid tussen ‘Code maakt apps’ en ‘Studio maakt chatbots’.
De behoefte
- Een antwoord of een eerste document: Chat in Copilot
- Een afgebakend pakket werk delegeren: Cowork
- Een kleine app of dashboard bouwen: Copilot Code
- Een blijvende assistent voor terugkerend werk: Autopilot
- Een gedeelde bedrijfsoplossing met agents, workflows en beheer: Copilot Studio
- Een uitgebreid softwareproduct of bestaande codebase ontwikkelen: Codex, Claude Code of GitHub Copilot in een ontwikkelproces
Dit is een praktische indeling, geen harde productgrens. Er is overlap, en de nieuwe previewfuncties moeten hun bruikbaarheid nog bewijzen.
Mijn verwachting is dat de eenvoudige start steeds vaker in Copilot zelf gebeurt. Naarmate een oplossing meer gebruikers, uitzonderingen en verantwoordelijkheden krijgt, wordt een expliciete bouw- en beheeromgeving belangrijker.
Microsoft schuift de producten dus dichter bij elkaar. De medewerker hoeft minder van de productkaart te begrijpen, terwijl de organisatie nog steeds moet weten wat er draait.
Autopilot: waarom ik aan Hermes en OpenClaw denk
Autopilot is de nieuwe naam voor Scout. Het idee van een assistent met geheugen, een eigen rol en doorlopende taken doet denken aan Hermes en OpenClaw.
OpenClaw verbindt communicatiekanalen met een blijvend beschikbare assistent en ondersteunt onder meer geheugen, tools en geplande automatisaties. Hermes combineert eveneens geheugen, skills, uitvoertools en interactie via verschillende communicatiekanalen. Beide kunnen op zelfgekozen infrastructuur worden ingezet.
De vergelijking zit in de manier van samenwerken. Je begint minder vaak telkens een nieuw gesprek met een assistent die op jouw volgende prompt wacht. Je geeft werk aan een systeem dat context kan bewaren en later weer verdergaat.
Microsoft probeert die interactie in de bedrijfsomgeving te plaatsen. Daar zit voor mij de kans: een doorlopende assistent wordt bruikbaarder als zijn toegang, rol en handelingen passen bij hoe de organisatie werkt.
En dan de credits. Daar wringt het voor mij.
Microsoft maakt een onderscheid tussen dagelijkse AI binnen de gebruikerslicentie en geavanceerd werk op verbruik. Cowork, Code en Autopilot werken via Copilot Credits. Ook frontiermodellen zoals Astra en Fable vallen onder die verbruiksfacturatie. De licentie blijft vereist voor toegang tot deze mogelijkheden. Dat betekent niet dat elke nieuwe Copilot-functie extra credits verbruikt; dagelijkse functies blijven onderdeel van de licentie, met gebruiksvoorwaarden en limieten.
Het gaat dus ook om toegang tot de geavanceerde modellen binnen Microsoft 365 Copilot: OpenAI GPT-6 Astra en Claude Fable. Een betaalde Copilot-licentie is geen onbeperkte toegang tot ieder model en iedere nieuwe mogelijkheid.
Bij intensief gebruik kan een vast abonnement de werkelijke uitvoeringskosten moeilijk afdekken. AI-abonnementen worden vandaag zwaar gesubsidieerd, zeker voor zware gebruikers.
Dat maakt de richting begrijpelijk. Ik vind ze tegelijk opmerkelijk en jammer. Wie al een Copilot-licentie in de orde van €30 per gebruiker per maand betaalt, moet voor de meest ingrijpende mogelijkheden opnieuw budget vrijmaken. Het precieze licentiebedrag verschilt per formule en contract; mijn punt gaat over de stapeling van een abonnement en variabel verbruik.
De vaste prijs had een democratiserend effect
Een vaste maandprijs had een bruikbaar psychologisch voordeel. Zodra de organisatie de licentie had gekocht, konden medewerkers proberen, leren en hun dagelijkse werk verbeteren zonder bij iedere opdracht over de volgende factuur na te denken. Er waren grenzen, maar de kost voelde vooraf afgebakend.
Met credits verandert dat. De mogelijkheden zijn zichtbaar, maar de toestemming en het budget kunnen per medewerker of afdeling verschillen. Dan krijg je een lastige situatie: een medewerker kan technisch zelf een oplossing bouwen, maar moet eerst verantwoorden waarom hij het verbruik nodig heeft om te ontdekken of die oplossing waardevol is.
Experimenteren levert nu eenmaal niet altijd onmiddellijk rendement op. Soms zijn drie mislukte pogingen nodig om te weten wat wél werkt. Wordt AI daardoor elitair? Dat is geen voldongen feit. Het risico bestaat wel dat de krachtigste mogelijkheden vooral terechtkomen bij afdelingen met een groot budget of medewerkers die al kunnen aantonen dat hun gebruik rendeert.
Net de mensen die nog moeten leren wat mogelijk is, kunnen dan achterblijven.
Kostencontrole wordt een operationele opdracht
Bij een traditionele licentie reken je vooral gebruikers maal maandprijs. Bij doorlopende agents komen er variabele kosten bij voor het uitvoeren van werk en het gebruiken van infrastructuur. Dezelfde opdracht kan meer of minder verbruik vragen, afhankelijk van context, modelkeuze, hulpmiddelen en hoeveel herstelpogingen nodig zijn. Een nieuwe poging na een fout kan nuttig zijn, maar maakt de kost vooraf minder zeker.
Microsoft voorziet budgetbeleid, gebruikerslimieten, waarschuwingen en verbruiksinzichten. Enterprise-verbruiksdiensten blijven uit tot een beheerder een uitgavenbeleid instelt. Dat helpt. Maar zicht op kosten is nog geen voorspelbaarheid, en een harde limiet is nog geen goede bedrijfsbeslissing. Wat als de agent zijn budget opgebruikt vlak vóór een belangrijke taak klaar is?
Ik zou drie dingen uit elkaar halen.
- Medewerkers krijgen een afgebakend leerbudget om te experimenteren.
- Gedeelde toepassingen krijgen een eigenaar en een eigen budget.
- Doorlopende agents krijgen daarnaast uitvoeringsgrenzen: hoe vaak mogen ze werken, wanneer moeten ze stoppen, en welke acties vragen beoordeling?
Beoordeel vervolgens de kost per bruikbaar resultaat. Voor veel terugkerende processen blijft een gewone automatisatie met enkele gerichte AI-stappen daarom een logische keuze. Je hoeft geen doorlopende agent in te zetten als een voorspelbare workflow het probleem eenvoudiger oplost.
Welke richting gaat Microsoft uit?
Microsoft wil volgens mij een groter deel van de werkcyclus naar Copilot brengen. De intentie komt binnen via een gesprek. De bedrijfscontext helpt de opdracht begrijpen. Vervolgens ontstaat een document, een toepassing of uitgevoerd werk, binnen een omgeving die de organisatie beheert. Daarmee worden Office, Power Platform, ontwikkeltools en agents meer onderdelen van één geheel.
Dat kan de gebruiker veel zoekwerk besparen. Maar het maakt ook de kwaliteit van de routering belangrijk. Als het platform bepaalt hoe een opdracht wordt uitgevoerd, beïnvloedt het ook de kost en de controle die nodig is.
Ik verwacht daarom dat organisaties steeds meer zullen moeten bepalen wanneer een kort antwoord volstaat, wanneer een afgebakende automatisatie nodig is en wanneer doorlopende autonomie waarde toevoegt. Meer agentisch werk is niet automatisch beter werk.
Er zit ook een duidelijk economisch gevolg in deze richting: Microsoft kan naast toegang per medewerker ook verdienen aan de uitvoering van taken. Hoe meer werk succesvol wordt gedelegeerd, hoe groter die verbruikslaag kan worden.
Voor klanten maakt dat de afweging breder. De vraag is hoeveel bruikbaar werk het platform oplevert, hoeveel controle daarvoor nodig blijft en welke afhankelijkheid je opbouwt. Een keuze tussen modellen geeft flexibiliteit, maar is niet hetzelfde als eenvoudig kunnen vertrekken uit het platform dat je context, toepassingen en agents beheert.
Wat ik hier als organisatie mee zou doen
Ik zou beginnen met één klein, werkelijk probleem. Een interne toepassing waarvoor vandaag een spreadsheet rondgaat, of terugkerend voorbereidingswerk dat elke week tijd vraagt.
Test het resultaat tegen de huidige manier van werken. Meet hoeveel tijd overblijft na menselijke controle. Kijk welke fouten optreden en wat de volledige kost is. Beslis daarna of de oplossing persoonlijk blijft, gedeeld kan worden of structureel beheer nodig heeft.
Geef medewerkers tegelijk ruimte om te leren. Een democratiserende bouwtool vraagt meer dan een toegankelijke interface. Ze vraagt ook een toegankelijk experimentbudget en begeleiding bij het beoordelen van de uitkomst.
Ik vind de technische beweging van Microsoft sterk. Ze brengt het maken van software en het delegeren van werk dichter bij de mensen die de problemen het best kennen. Mijn twijfel zit bij de toegang tot die kracht. Als de bouwdrempel daalt maar de budgetdrempel stijgt, komt de belofte van AI voor iedereen onder druk.
Dat is voor mij de belangrijkste vraag achter Copilot Wave 4: hoe zorgen we dat de medewerker met het goede idee ook de ruimte krijgt om het uit te proberen?
Wil je onderzoeken wat dit betekent voor citizen development, automatisatie en AI-kosten in jouw organisatie? Bij SirusAI helpen we de stap maken van mogelijkheid naar een werkende aanpak die je ook kunt beheren en betalen.
Have a productive day!
