Companies & AI

Copilot “dogfooden” bij Microsoft was niet de beste manier om adoptie te vergroten

Ik lees het tweede artikel in mijn zoektocht naar de wetenschap achter technologie- en AI-adoptie. Een van de grootste uitdagingen met onderzoek, experimenten en de artikelen die daaruit voortkomen op het gebied van AI is natuurlijk het absurde tempo van de ontwikkelingen. Experimenten en resultaten van vier jaar geleden gaan over een compleet ander niveau en een compleet andere kwaliteit AI dan we vandaag zien.

Toch vind ik het belangrijk om deze artikelen door te spitten en te kijken welke inzichten eruit te halen zijn. Al is het soms alleen maar om vraagtekens te zetten bij de gebruikte methodologie, want dat maakt toekomstig onderzoek en de inzichten daaruit beter (ja, een kleine spoiler alert voor een van mijn kritiekpunten).

Maar goed, even wat context bij het artikel en dan duiken we erin.

Het artikel beschrijft drie experimenten bij Microsoft, Accenture en een anoniem bedrijf, waarbij developers werden uitgenodigd om Copilot te gaan gebruiken (toen nog puur een tool die code aanvulde en suggesties gaf). De vraag was of het gebruik van generatieve AI, in de vorm van Copilot, de productiviteit zou verhogen.

Mijn belangrijkste kritiekpunt

En daar zitten we meteen bij mijn belangrijkste kritiekpunt. Productiviteit. Als begrip is dat letterlijk hoe productief developers zijn. In het artikel gedefinieerd als het aantal zogenoemde pull requests (als je code hebt gebouwd en die klaar is om naar je applicatie te gaan, maak je een pull request (PR) aan en na review, handmatig of automatisch, wordt die code naar productie gepusht en is hij onderdeel van het live softwareproduct).

In mijn eigen bouw- en codeeravontuur met AI als solopreneur draai ik een gigantisch aantal PR’s. Bepaal ik zelf de omvang en het moment van die PR’s? Nee. Stelt AI regelmatig voor om taken over meerdere PR’s te verdelen? Ja. Ik was dan ook heel verbaasd dat ze dit als kernindicator gebruiken, want in mijn ogen zegt het me niets over productiviteit (laat staan over kwaliteit).

Eerlijk is eerlijk: dit was 3 tot 4 jaar geleden, dus er waren nog geen agents die code draaiden en PR’s voorstelden. En dit zijn grote bedrijven en geen solopreneurs, dus er lagen handmatige codereviewprocedures klaar om de kwaliteit van de PR’s te beoordelen. De auteurs benoemen deze tekortkoming trouwens zelf ook in het artikel en stellen dat de kwaliteit van code heel lastig te meten is.

Nul vragenlijsten

De drie experimenten laten een flinke productiviteitswinst zien (26%), maar er zit behoorlijk wat ruis in de data, zoals ze in hun samenvatting ook toegeven. Dat is prima. Het is zo’n nieuw vakgebied dat onderzoek vaak vol ruis zit en lastig is. Waar ik vooral kritisch over ben, is dat ze de menselijke ervaring totaal niet gemeten hebben. Ze gebruiken alleen harde data. Nul vragenlijsten richting de bijna 5.000 developers die aan de pilots meededen.

Als ze het aan de developers gevraagd hadden, hadden ze kunnen achterhalen:

• Of autocompletion en suggesties een nuttige toevoeging waren
• Of het ontbreken van training op Copilot hun meer tijd kostte om het uit te vogelen dan de code gewoon zelf schrijven (alleen Accenture had training gegeven en zag betere adoptie)
• Of ze thuis met betere AI werkten dan Copilot en of ze daar gefrustreerd van raakten
• Of ze het gevoel hadden betere oplossingen voor klanten te bouwen
• Of ze het gevoel hadden sneller te bouwen en wat ze met de gewonnen tijd deden

En dat is dan nog alleen achteraf. Waardevol, maar het had nog veel waardevoller gekund.

Als ze vooraf een vragenlijst hadden uitgezet, hadden ze nog veel meer impact kunnen testen. Dan hadden ze de echte dagelijkse pijn en frustraties van de developers boven tafel gekregen en Copilot use cases aan die pijnpunten kunnen koppelen. Dat had de adoptie en de impact van de tool op hun werk gegarandeerd vergroot.

In de Microsoft case kregen de developers in de testgroep de mail hieronder.

Je snapt vast waarom in eerste instantie maar 8% van de developers reageerde om mee te doen.

Tap to open the full size image

Ontwerp voor de ervaring van je medewerkers

Zo vaak zijn bedrijven veel te gefocust op productiviteit zonder naar de kwaliteit van het werk te kijken.

Meet jij nog steeds de gewerkte uren van je medewerkers, of de snelheid en kwaliteit van wat ze voor je organisatie opleveren?

Zelfde probleem.

Laat staan dat je de ervaring van zowel medewerkers als klanten meeneemt.

Ken je die echt waardeloze klantenservice-chatbot nog waar je laatst tegenaan liep?

Dat er geen enkele manier was om een echt mens te spreken, hoe aardig “Botty” ook deed?

Of al die medewerkers die op hun werk een AI-oplossing moeten gebruiken die zoveel slechter is dan wat ze thuis tot hun beschikking hebben?

Ik weet het, een groot bedrijf kan niet zo snel schakelen en tools omarmen als een ondernemer.

Maar ze kunnen wel eerlijk zijn en die worsteling erkennen, in plaats van medewerkers de schuld te geven dat ze de AI niet gebruiken terwijl de enige “adoptie-aanpak” een centrale e-learning was over de risico’s van het delen van vertrouwelijke informatie in de bedrijfs-AI.

Je moet ontwerpen voor de ervaring van je medewerkers.

Hun dagelijks werk, hun pijnpunten, hun kennisniveau van AI, enzovoort.

Dit is het punt waarop technologie toepassen overgaat in transformatie van de organisatie.