Wanneer je werkgever de tool afzet waar je van afhankelijk bent

Microsoft trok deze week Claudelicenties in bij duizenden ontwikkelaars. Geen voorbereiding. Geen migratiepad bij het nieuws. Gewoon een intrekkingsbericht en druk richting GitHub Copilot.

Voor de meeste getroffen ontwikkelaars is de pijn praktisch. spierspanningen onderbroken, configbestanden verweest, maanden opgebouwde promptgewoonten die nu naar niets wijzen. Maar het diepere probleem is structureel. En het raakt elk bureau, elk productteam, elke studio die een tool van derden in hun dagelijkse werkwijze heeft ingebouwd.

De vraag is simpel. Als de licentie verdwijnt, wat bezit je nog?

De workflow is het bezit, niet het abonnement

Bureaus spreken over deliverables. Klanten betalen voor output. Maar de werkelijke waarde die een team in de tijd opbouwt, zit niet in een enkel bestand. Het zit in de workflow: de reeks beslissingen, de prompts die oordeelsvermogen coderen, de reviewloops die drift opvangen voordat het live gaat.

Als die workflow in een tool leeft die je niet controleert, is het bezit geleend. Je bouwt op huurbasis.

Dit is geen nieuw probleem. Het gebeurde met Sketch toen Figma kwam. Het gebeurde met elk team dat diep ingeëerde Notion-automaties bouwde voordat Notion de API-prijsstelling wijzigde. Het patroon herhaalt zich: een leverancier bouwt een categorie, teams bedden het diep in, de leverancier prijst opnieuw of draait bij, en de wisselskosten arriveren als een verrassing.

Nieuw is de snelheid. AI-tools bewegen snel genoeg dat leveranciers platformbeslissingen nemen op driemaandelijkse schalen, niet jaarlijkse. Een tool die vandaag standaardpraktijk is, kan volgende kwartaal afgeschaft of omgeleid worden voordat je team klaar is met inwerken.

Wat Microsoft werkelijk deed

De stap is eenvoudig als zakelijke beslissing. Microsoft bezit GitHub Copilot. Het distribueert Claude Code ook aan bedrijfsklanten via Azure en desarrollarsmogelijkheden. Deze licenties intrekken en ontwikkelaars naar Copilot sturen consolidates uitgaven, beperkt afhankelijkheid van Anthropic, en houdt gebruikers binnen Microsofts oppervlak.

Voor Microsoft is dit rationeel. Voor de betrokken ontwikkelaars is het een live demonstratie van platformrisico dat geen hoeveelheid vertrouwensopbouw kan voorkomen.

Grote organisaties hebben IT-afdelingen, inkoopteams en bedrijfsovereenkomsten die zo'n migratie kunnen opvangen, zelfs als het pijnlijk is. Bureaus en kleinere productstudio's hebben die buffer niet. Als je tienpersoonsteam het hulpmiddel verliest waarmee drie mensen hun hele codereviewproces en specgeneratieproces hebben gebouwd, landet de kostprijs onmiddellijk en persoonlijk.

Het interessante is niet de verstoring zelf. Het gaat om wat het onthult over waar teams wel en niet doelbewust over eigenaarschap hebben nagedacht.

Waar bureaus nu blootgesteld zijn

De meeste bureaus hebben geen toolingaudit met eigenaarschap als lens gedaan. Ze hebben tools geëvalueerd op capability en prijs. Dat zijn de verkeerde primaire criteria als het hulpmiddel gaat bepalen hoe denken gebeurt.

Hier clustert blootstelling meestal.

Prompts opgeslagen in leveranciersinterfaces. ChatGPT Projects, Claude's projectmemory, Copilot Notebooks. Als de prompts van je team in deze systemen leven, zijn ze niet draagbaar. Als de leverancier de interface verandert of de organisatie toegang verliest, verdwijnen de prompts mee. Het antwoord is procedureel: sla prompts op in versiebeheer, dezelfde plek waar je code staat.

Evaluatiecriteria die alleen in mensen's hoofden bestaan. Door AI ondersteunde reviewloops blijven scherp als de criteria erachter zijn uitgeschreven en opgeslagen waar je team controle over heeft. Als het model de evaluatie doet maar de norm is nooit geëxternaliseerd, kun je het oordeel niet naar een ander model verplaatsen als je dat nodig hebt.

Workflows gebouwd tegen een model's eigenaardigheden. Elk model heeft gedrag. Teams leren dit en bouwen erlangs. Claude handelt lange context anders af dan GPT-4o. Gemini's function-calling gedrag verschilt van beiden. Als een migratie een modelswitch forceert, breken workflows die voor één model zijn afgestemd op manieren die moeilijk onder druk uit te debuggen zijn.

Geen van deze blootstellingen is onvermijdelijk. Ze zijn elk een documentatie en architectuurbeslissing die teams nog niet hebben gemaakt.

Het geval voor modelonafhankelijk workflowontwerp

De praktische reactie is niet om AI-tools te vermijden of alleen op opensource-alternatieven in te zetten. Het is om workflows zo te ontwerpen dat de logica van de interface kan worden gescheiden.

Dat betekent een paar concrete dingen.

Eerstens. behandel prompts als code. Ze gaan in een repo. Ze hebben commitgeschiedenis. Ze worden beoordeeld zoals elk artefact dat codeert hoe het team denkt.

Tweedens. abstract de modeloproep. Of je team daadwerkelijke code schrijft of een workflowtool gebruikt, de stap die een model aanroept moet één configuratie-instelling zijn, niet iets dat in elk knooppunt van een pipeline is ingebakken. Het wisselen van Claude naar GPT-4o hoort een middag te zijn, geen sprint.

Derdens. bezit je evaluatielaag. Als je AI gebruikt om werk te beoordelen, behoren de criteria voor goed werk aan jou. Schrijf ze op. Test nieuwe modellen ertegenaan voordat je migreert. Het model is de motor. De criteria zijn de auto.

Vierdens. houd een leverancierkaart bij. Weet welke tools je team van afhangt, wie ze controleert, en wat de migratiekosten zouden zijn als de toegang morgen verdween. Meeste teams hebben geen idee totdat ze het nodig hebben.

Dit is geen paranoia. Het is dezelfde gedachte die serieuze engineeringteams ertoe bracht vendor lock-in op infrastructuur te vermijden. AI-tools verdienen dezelfde discipline.

Wat deze week zou moeten veranderen

De Claude Code-intrekking is een nuttige dwingende factor. Het is concreet genoeg om mee te nemen naar een leidinggevend team dat vaag is geweest over AI-toolinggovernance. Het geeft een gezicht aan een risico dat eerder abstract was.

Voor bureaus specifiek gaat de implicatie dieper dan tooling. Klanten beginnen te vragen hoe hun eigen door AI ondersteunde werk is gestructureerd. Als je geen vragen kunt beantwoorden over draagbaarheid, gegevenslocatie en wat gebeurt als een model wordt afgeschaft, dan is dat een gat in je praktijk, niet alleen je stack.

De studio's die over twaalf maanden in de beste positie zullen zijn, zijn niet degenen die vandaag de meest indrukwekkende tools gebruiken. Het zijn degenen die doelbewust hebben nagedacht over wat ze bezitten versus wat ze huren, en hun werk daarnaar hebben gebouwd.

Tooling zal blijven verschuiven. Leveranciers zullen blijven beslissingen nemen die hun roadmaps dienen, niet de jouwe. Dat is prima, zolang je workflow niet volledig in hun huis leeft.