Waarom één regel code veranderen zo gevaarlijk is?

Het aanpassen van een model naam in je code lijkt triviaal. Maar een nieuw model kan volledig andere JSON teruggeven, langere samenvattingen produceren, of tool-aanroepen in een andere volgorde afvuren. Je foutmeldingenlog blijft leeg. Je gebruikers krijgen rare antwoorden. Dat is het echte risico van een model migratie zonder plan.

Stel je bouwt een bestelassistent voor een webshop. Die roept een AI-model aan, dat JSON teruggeeft met velden als product_id, quantity en shipping_option. Je vervangt het model, de API reageert nog steeds, je dashboard zegt groen. Maar het nieuwe model geeft productId terug in camelCase. Je parser crasht niet. Hij leest gewoon een leeg veld en slaat een bestelling op zonder product-ID.

Dit is precies het probleem dat Microsoft Foundry beschrijft: model failures zijn vaak stil voor de systemen die het model aanroepen, maar luid voor de eindgebruiker. Dat maakt het zo lastig. Er is geen alarm. Alleen een groeiende supportwachtrij.

Eerlijk gezegd is dit het type fout dat ik zelf ook niet direct zou zien aankomen. Je denkt: ik verander een string, wat kan er misgaan? Veel, blijkt. Elk model heeft zijn eigen ‘karakter’ in hoe het formaten, hoe uitgebreid het antwoordt en hoe het tools aanroept. Dat karakter verandert bij elke generatiewissel. Een goed begrip van hoe LLMs werken helpt je hier sneller doorheen.

GPT-4o stopt op 1 oktober 2026: wat doe jij nu?

Microsoft maakt het concreet: GPT-4o (versie 2024-05-13) wordt op 1 oktober 2026 afgezet. De opvolger is GPT-5.1. Pay-as-you-go deployments worden automatisch omgezet, maar provisioned deployments (PTU) doe jij zelf. En automatisch omzetten betekent niet dat je app zich hetzelfde gedraagt.

Er zijn drie soorten deployments op Microsoft Foundry, en ze worden elk anders behandeld bij een pensionering:

• Standard / Global Standard / Data Zone Standard (pay-as-you-go): worden automatisch geüpgraded. Je bepaalt de timing via de instelling versionUpgradeOption. Kies je NoAutoUpgrade, dan stopt de deployment gewoon op de pensioneringsdatum.
• Provisioned (PTU): worden niet automatisch gemigreerd. Jij regelt dit zelf, in-place (20-30 minuten zonder downtime) of naast elkaar (side-by-side).
• Batch deployments: altijd side-by-side aanpak. Nieuw model deployen, jobs opnieuw indienen, oud model weggooien.

Microsoft maakt een vervangend model beschikbaar in Global Standard ongeveer 90 dagen voor pensionering, in provisioned regio’s 30 dagen van tevoren en in standaard regio’s 2 weken ervoor. Je hebt dus tijd, maar die raakt op als je wacht.

Mijn standpunt: begin nu met de validatie op GPT-5.1, ook als je deployment automatisch wordt omgezet. Automatisch verkeer omzetten bewijst niet dat je app zich hetzelfde gedraagt. Dat bewijs lever jij zelf.

De 6 fasen van een veilige model migratie

Microsoft Foundry beschrijft zes fasen: Discover, Assess, Adapt, Validate, Roll out en Retire. Elke fase heeft een duidelijk eindpunt. Geen fase overslaan, ook niet als het model ‘lijkt te werken’. De Adapt-fase is voor de meeste productie-apps de zwaarste en meest tijdrovende.

Hier zijn de zes fasen kort uitgelegd, met wat ik er zelf bij denk:

1. Discover: je hoort dat een model met pensioen gaat, of je wilt proactief upgraden. Einddoel: weet je wat er verandert en wanneer?
2. Assess: kies een kandidaat-model en check of het beschikbaar is in jouw regio, SKU en quota. Let op: prijsstructuren veranderen per generatie. Redeneer-tokens, gecachte input en structured-output overhead kunnen je kosten met factor 2 of meer verschuiven.
3. Adapt: speel je huidige workload af op het nieuwe model zonder aanpassingen. Kijk waar het gedrag afwijkt: verbositeit, JSON-structuur, tool-aanroepen. Pas daarna je prompts, parameters en output-schema’s aan.
4. Validate: run een evaluatiesuite met concrete kwaliteitscriteria. Azure AI Evaluation SDK heeft meer dan 30 evaluatoren, inclusief LLM-as-judge (dat is een AI die de output van een andere AI beoordeelt).
5. Roll out: stuur eerst een klein percentage verkeer naar het nieuwe model (canary deployment). Meet live kwaliteit naast latency en foutpercentages. Houd rollback mogelijk.
6. Retire: gooi het oude deployment weg, archiveer je evaluatie-artifacts en noteer wat je hebt geleerd.

Fase 0 staat er eigenlijk voor: bouw een testdataset van echte productie-input vóór je begint. Zonder die dataset heb je niets om tegen te valideren. En die dataset moet je nu al loggen, want productie-logs zijn niet retroactief beschikbaar.

Welke tools helpen je door elke fase heen?

Microsoft Foundry heeft voor elke fase specifieke tooling: van model-pensioneringschema’s en leaderboards in Assess, tot de Prompt Optimizer in Adapt en de Azure AI Evaluation SDK in Validate. De tooling is goed, maar er zijn ook gaten waar je zelf iets moet bouwen.

Wat goed werkt in de Foundry toolchain:

• Discover: het model-pensioneringschema en de Models API geven je programmatische toegang tot pensioneringsdatums en vervangers. Ideaal voor een interne notificatielaag.
• Assess: model leaderboards vergelijken kwaliteit, veiligheid, kosten, doorvoer en latency. Je kunt tot drie modellen naast elkaar vergelijken.
• Adapt: de Prompt Optimizer in de Foundry Agent playground helpt je prompts aanpassen. Een simulator genereert synthetische testdata als je geen productie-data hebt.
• Validate: Azure AI Evaluation SDK met 30+ evaluatoren. Inclusief LLM-as-judge voor kwalitatieve beoordeling.
• Roll out: automatische upgrade-opties, continuous evaluation en Azure Monitor alerts.
• Retire: de Models API geeft een 410 Gone terug als een model echt offline is. Je observability dashboard toont het deployment-aantal.

Waar het soms misgaat: teams ontdekken een pensionering via e-mail of een productie-fout, in plaats van via een gestructureerd systeem. En soms blijkt een gekozen model niet beschikbaar in de vereiste regio, iets wat je pas ontdekt als de planning al klaar is. Dat is vervelend. Mijn advies: valideer beschikbaarheid in jouw specifieke regio als eerste stap in de Assess-fase, niet als laatste.

Als je meer wilt weten over wat AI-implementatie in de praktijk kost, ook buiten de licentiekosten, bekijk dan wat AI implementatie echt kost aan tijd en aanpassing.

Wat moet jij nu concreet doen als je een AI-app draait?

Check welk model je deployment gebruikt en wanneer dat model met pensioen gaat. Zet logging aan als je dat nog niet hebt. Start alvast met het bouwen van een testdataset op basis van echte productie-input. Wacht niet op een pensioneringsbericht.

Drie concrete stappen die je deze week kunt zetten:

1. Check je deployment type. Gebruik je Standard of Provisioned? Bij Provisioned doe jij de migratie zelf. Dat wil je weten voordat de deadline nadert.
2. Zet content capture aan. Log je prompts, responses, latency en token-aantallen nu. Dit is opt-in en nooit retroactief. Zonder logs heb je geen testdataset voor Validate.
3. Plan een side-by-side test. Draai je huidige workload op GPT-5.1 naast je huidige model. Kijk waar de output afwijkt. Dat hoeft niet perfect te zijn, maar je wilt weten waar de risico’s zitten voordat je live gaat.

Overigens: je hoeft niet te wachten op een pensioneringsbericht om te beginnen. Als een nieuw model betere kwaliteit of lagere kosten biedt, is dat reden genoeg om het proces te starten. Een geplande migratie is altijd minder stressvol dan een gedwongen upgrade op een datum die je niet hebt gekozen.

Voor bredere context over hoe AI-tools en -modellen zich in 2026 ontwikkelen, is het ook de moeite waard om te volgen hoe grote platforms als Google hun AI-functies uitrollen en wat dat voor afhankelijkheden in je toolstack betekent.

Wat ik in mijn eigen werk zie veranderen

Ik ben zelf developer en ik werk dagelijks met AI-tools voor klantprojecten. Het verschil met twee jaar geleden: ik typ minder code, ik review meer. Ik schrijf minder algoritmes, ik schrijf meer specificaties. De rol is niet kleiner geworden, hij is verschoven. Wie nog elke regel zelf wil typen omdat dat "echt programmeren" is, loopt achter.

Twee jaar geleden begon ik een feature met een lege editor en een idee. Nu begin ik met een prompt: hier is de huidige code, hier is wat ik wil, schrijf de eerste versie. De AI tikt het in 30 seconden uit. Daarna komt mijn werk: kloppen de assumpties, zit er geen verzonnen library in, hoe gaat dit zich gedragen onder load.

Niet elke developer ervaart dit zo. Sommige collega’s negeren AI bewust. Anderen accepteren elke gegenereerde regel klakkeloos. Beiden lopen risico. De eerste groep raakt achter omdat AI-tools zo sterk worden dat handmatig coderen straks duurder is. De tweede groep stopt productie-bugs in hun software omdat ze de output niet snappen.

Wat blijft, en zelfs belangrijker is geworden: weten waarom code werkt. Niet alleen of het werkt. Bij mijn klanten zie ik dat de developers die het beste presteren, de developers zijn die kritisch lezen en doorvragen op de output. Niet de developers die het hardst typen.

Welke skills écht waarde toevoegen in 2026

Architectuur, systeemontwerp, security en het schrijven van heldere specificaties. Dat is waar de waarde nu zit. AI bouwt componenten, jij ontwerpt het systeem. AI schrijft de query, jij beoordeelt of de query veilig is. Skills die niet goed door AI worden ingevuld zijn de skills die je doelgericht moet bijspijkeren.

De skills die in mijn ervaring nu het zwaarst wegen, in volgorde:

Systeemontwerp. Een AI kan een loginscherm bouwen, maar niet bedenken hoe authenticatie samenhangt met sessions, met de cache-laag, met de e-mailprovider, met je hosting. Dat overzicht moet uit een mensenhoofd komen.

Code reviewen met aandacht voor wat er níét staat. AI vergeet edge cases. AI verzint soms dependencies die niet bestaan. AI gebruikt soms verouderde APIs. Een goede review controleert wat ontbreekt, niet alleen wat er staat.

Security en privacy. AI-tools genereren regelmatig code met onveilige defaults: hardcoded secrets, ontbrekende input-sanitisatie, te brede CORS-headers. Wie dat herkent, voorkomt incidenten. De Autoriteit Persoonsgegevens publiceerde richtlijnen voor AI-gebruik waar elke developer met klantdata mee bekend hoort te zijn.

Specificaties schrijven. Een AI doet alleen wat je vraagt, en een vage vraag levert vage code op. Helder kunnen formuleren wat je wilt is geen managers-skill meer maar core developer-werk.

Wat dit betekent als jij een developer of freelancer inhuurt

Ondernemers die freelance-developers of een dev-team inhuren, kijken nu naar andere signalen dan vijf jaar geleden. Niet meer "kan deze persoon snel typen", maar "begrijpt deze persoon mijn business en kan hij de AI-output beoordelen". Een developer die alle code uit ChatGPT haalt zonder review levert je een tijdbom. Een developer die AI bewust inzet en de output kritisch leest, levert je in dezelfde tijd meer waarde op.

Drie concrete dingen die je nu anders moet doen bij het inhuren of werken met developers:

Vraag naar AI-werkwijze, niet naar AI-vermijding. Iemand die zegt "ik gebruik geen AI" is in 2026 vaak duurder dan iemand die het slim inzet. Niet omdat AI gratis is, maar omdat de eerste groep langer doet over hetzelfde werk. Vraag liever: hoe gebruik je AI in je workflow, en wat doe je om niet in valkuilen te trappen.

Reken op review-tijd, niet alleen bouwtijd. Vroeger schatten developers bouwtijd. Nu is bouwtijd korter en review-tijd langer. Een feature van twee weken oude stijl is misschien drie dagen bouwen plus drie dagen review. Plan beide in.

Eis documentatie van AI-keuzes. Welke libraries gebruikt de developer, welke daarvan zijn AI-suggesties, en welke tests zitten erop. Dit is je verzekering voor als de developer wegloopt en jij straks zelf de code moet onderhouden of overdragen.

Wat ik adviseer aan junior developers en ondernemers met een dev-team

Junior developers: leer de fundamenten zoals datastructuren, algoritmen en systeemontwerp. Daar bouw je je AI-werk bovenop. Ondernemers met een dev-team: investeer in pair-programming en code-review-cultuur, niet in meer AI-licenties. Tools maken het werk niet beter, kritisch denken doet dat.

Voor junior developers die net beginnen: laat AI niet je leerproces overnemen. Genereer code, ontleed hem, schrijf hem opnieuw vanaf scratch zonder AI, vergelijk. Dat is hoe je AI gebruikt om sneller te leren in plaats van langzamer.

Voor ondernemers met een eigen dev-team of freelance-developers: de grootste winst zit niet in betere tools maar in betere werkprocessen. Een uur per week pair-programmen levert meer op dan een nieuwe AI-licentie. Een verplichte code-review op AI-gegenereerde features voorkomt incidenten die je later weken kosten.

Voor ZZP’ers die zelf bouwen: het is geen schande om de AI te gebruiken voor je klantenwebsite. Het is wel een probleem om de output blind te plaatsen. Schrijf een korte review-checklist en ren die door op alles wat AI voor je maakt: input-validatie, foutmeldingen, edge cases, security-headers. Vijf minuten controle voorkomt een uur incident-respons.