Volwassenheid van AI-ondersteund coderen

Beoordeel de praktijk van AI-ondersteund ontwikkelen van je team op tooladoptie, prompting, validatie, beveiliging en impact — van Ad hoc tot Geoptimaliseerd.

Rennen in TeamRetro

Meet hoe effectief je team AI-codeerassistenten gebruikt

AI-codeerassistenten zijn van een nieuwigheid uitgegroeid tot een dagelijks hulpmiddel, maar adoptie alleen maakt een team nog niet effectief. Dit volwassenheidsmodel helpt engineeringteams om eerlijk te kijken naar hoe ze AI inzetten gedurende de hele ontwikkelcyclus — van toolgebruik en prompting-vaardigheden tot validatie van de output, beveiliging en meetbare impact. Door elke dimensie te beoordelen op een vijftraps schaal van Ad hoc tot Geoptimaliseerd, bouwt het team een gedeeld beeld op van waar het sterk staat, waar AI risico's introduceert en waar gerichte investering loont. Gebruik het om een open gesprek aan te wakkeren, een nulmeting vast te leggen en te volgen hoe je praktijk van AI-ondersteund ontwikkelen groeit in de tijd.

Afmetingen

Tooladoptie

Hoe breed en doordacht AI-codeertools binnen het team worden opgepakt, geconfigureerd en actueel gehouden.

  • Toolbereik

    We gebruiken AI-codeertools consistent in ons dagelijkse ontwikkelwerk.

    1. Ad hocEen paar engineers experimenteren met AI-tools; de meesten gebruiken ze nooit.
    2. OpkomendSommige engineers gebruiken AI-tools regelmatig, maar het bereik is binnen het team onregelmatig.
    3. GedefinieerdDe meeste engineers grijpen naar AI-tools bij routinetaken; adoptie is breed, zij het niet universeel.
    4. BeheerdAI-tools maken deel uit van vrijwel ieders dagelijkse workflow, met verstandige keuzes die passen bij de taak.
    5. GeoptimaliseerdAI-tools worden reflexmatig ingezet waar ze helpen en bewust vermeden waar niet; het team heeft een helder, gedeeld oordeelsvermogen.

  • Configuratiekwaliteit

    Onze AI-tools zijn goed geconfigureerd voor onze codebase, workflows en projectcontext.

    1. Ad hocTools draaien op standaardinstellingen; geen projectspecifieke context, conventies of vangrails ingesteld.
    2. OpkomendEen paar engineers passen hun eigen setup aan; niets wordt op teamniveau gedeeld.
    3. GedefinieerdConfiguratie op teamniveau (regelsbestanden, instructies, ignore-lijsten) is voor de meeste tools aanwezig.
    4. BeheerdConfiguratie wordt geversioneerd, beoordeeld en actueel gehouden naarmate de codebase evolueert.
    5. GeoptimaliseerdConfiguratie is een eersteklas asset — gemeten, geïtereerd en afgestemd om de nauwkeurigheid op onze code te maximaliseren.

  • Onboardingondersteuning

    Nieuwe teamleden komen snel op snelheid met onze AI-tooling en werkwijzen.

    1. Ad hocNieuwe mensen zoeken de AI-tooling zelf uit; geen begeleiding, voorbeelden of gedeeld startpunt.
    2. OpkomendInformele tips van collega's; geen geschreven materiaal.
    3. GedefinieerdEr bestaat een gedocumenteerde setup en startersgids die grotendeels actueel is.
    4. BeheerdOnboarding omvat praktische AI-sessies, voorbeeldprompts en een buddy voor de eerste vragen.
    5. GeoptimaliseerdNieuwe engineers zijn binnen hun eerste week productief met onze AI-workflow en dragen bij aan het onboardingmateriaal.

  • Toolbewustzijn

    We blijven op de hoogte van nieuwe AI-codeermogelijkheden en herevalueren onze toolchain.

    1. Ad hocNiemand volgt wat er verandert in het AI-codeerlandschap; we gebruiken wat we als eerste oppikten.
    2. OpkomendEen paar engineers volgen het veld persoonlijk; inzichten bereiken zelden het team.
    3. GedefinieerdIemand deelt af en toe relevante updates; we weten ruwweg wat er beschikbaar is.
    4. BeheerdWe evalueren periodiek nieuwe tools en functies tegen onze behoeften en stappen over als het de moeite waard is.
    5. GeoptimaliseerdActief verkennen met gedeelde experimenten; toolchainbeslissingen zijn weloverwogen en gebaseerd op bewijs, niet op hype.

Promptvaardigheden

Hoe goed het team communiceert met AI-tools — via heldere prompts, goede context, verfijning en taken op de juiste maat.

  • Promptduidelijkheid

    We beschrijven taken voor AI-tools helder en precies.

    1. Ad hocPrompts zijn vage oneliners; resultaten zijn onvoorspelbaar en vaak onbruikbaar.
    2. OpkomendSommige engineers maken goede prompts; anderen gooien ruwe verzoeken naar de AI en hopen op het beste.
    3. GedefinieerdPrompts bevatten meestal intentie, input en verwachte output; resultaten zijn grotendeels op doel.
    4. BeheerdPrompts zijn consistent helder en ondubbelzinnig; het team heeft een gedeeld beeld van hoe goed eruitziet.
    5. GeoptimaliseerdPrompting wordt behandeld als een eersteklas vaardigheid; engineers landen hoogwaardige output bij de eerste of tweede poging.

  • Contextverstrekking

    We geven AI-tools de juiste context — code, beperkingen en intentie — zodat ze hun beste werk leveren.

    1. Ad hocEngineers vragen zonder de omliggende code, conventies of beperkingen te delen; output negeert de realiteit.
    2. OpkomendEr wordt context meegegeven als die voor de hand ligt; subtielere beperkingen worden meestal gemist.
    3. GedefinieerdEngineers nemen routinematig de relevante bestanden, types en beperkingen op in hun prompts.
    4. BeheerdContextverstrekking is weloverwogen; tools worden standaard naar de juiste bestanden, voorbeelden en tests verwezen.
    5. GeoptimaliseerdContext wordt gecureerd — de AI ziet genoeg om nuttig te zijn en niet zoveel dat hij afgeleid raakt; output past natuurlijk bij onze codebase.

  • Iteratieve verfijning

    We verfijnen en sturen AI-antwoorden effectief bij wanneer de eerste poging mis is.

    1. Ad hocEngineers accepteren wat de AI produceert of verwerpen het volledig; ze sturen zelden bij om te verfijnen.
    2. OpkomendEr vindt enige verfijning plaats, maar engineers beginnen vaak helemaal opnieuw in plaats van voort te bouwen op wat er is.
    3. GedefinieerdEngineers itereren op AI-output om hiaten te dichten; gesprekken zijn productief in plaats van rondjes draaien.
    4. BeheerdVerfijning is snel en gericht; engineers weten hoe ze kunnen bijsturen zonder de draad kwijt te raken.
    5. GeoptimaliseerdEngineers halen maximale waarde uit elk gesprek; ze weten vloeiend wanneer ze moeten verfijnen, opnieuw beginnen of de AI aan de kant zetten en het zelf schrijven.

  • Taakopdeling

    We breken complex werk op in AI-passende stukken die betrouwbare resultaten opleveren.

    1. Ad hocEngineers gooien hele features naar de AI en zijn teleurgesteld in de output.
    2. OpkomendSommige engineers verdelen het werk passend; anderen vragen te veel ineens.
    3. GedefinieerdTaken zijn doorgaans afgebakend tot een functie of kleine wijziging; de output is bruikbaar.
    4. BeheerdEngineers delen werk betrouwbaar op tot AI-vriendelijke porties en koppelen stappen aan elkaar waar nodig.
    5. GeoptimaliseerdOpdeling is intuïtief; engineers weten precies hoe ze werk moeten verdelen om de AI nauwkeurig te houden en zelf de controle te behouden.

Outputvalidatie

Hoe grondig het team door AI gegenereerde code reviewt, test en bevraagt voordat het die vertrouwt.

  • Grondigheid codereview

    We reviewen door AI gegenereerde code net zo zorgvuldig als door mensen geschreven code.

    1. Ad hocDoor AI gegenereerde code wordt met weinig of geen review geaccepteerd; defecten glippen erdoorheen.
    2. OpkomendReviewers scannen door AI gegenereerde code maar bekijken die niet kritisch; sommige problemen worden gevonden, vele gemist.
    3. GedefinieerdDoor AI gegenereerde code wordt volgens dezelfde standaard beoordeeld als andere code.
    4. BeheerdReviewers letten extra op bekende AI-faalpatronen (verzonnen API's, plausibel-maar-foute logica).
    5. GeoptimaliseerdReviews zijn even grondig en even snel; het team heeft heldere heuristieken voor waar het scherpst naar gekeken moet worden.

  • Testdekking

    Onze door AI gegenereerde code wordt onderbouwd door geautomatiseerde tests.

    1. Ad hocDoor AI geschreven code belandt zonder tests; bugs duiken op in productie.
    2. OpkomendTests worden inconsistent toegevoegd; de dekking van AI-code blijft achter bij de rest van de codebase.
    3. GedefinieerdVan door AI gegenereerde code wordt verwacht dat die met tests wordt opgeleverd; aan die verwachting wordt meestal voldaan.
    4. BeheerdTest-first is het gangbare patroon voor door AI gegenereerde code; de dekking komt ruwweg overeen met de rest van de codebase.
    5. GeoptimaliseerdDe AI maakt concepten en engineers verfijnen testcases als standaardworkflow; de dekking van AI-code evenaart of overtreft de rest van de codebase.

  • Kritische evaluatie

    We bevragen en verifiëren AI-output in plaats van die klakkeloos te accepteren.

    1. Ad hocEngineers vertrouwen AI-output tenzij die overduidelijk kapot is; subtiele hallucinaties glippen erdoorheen.
    2. OpkomendEngineers zijn aanvankelijk sceptisch maar accepteren het zodra het compileert of draait.
    3. GedefinieerdEngineers controleren actief beweringen, functiesignaturen en bibliotheekaanroepen tegen echte documentatie en types.
    4. BeheerdHet team heeft een gedeeld mentaal model van wanneer de AI betrouwbaar is en wanneer niet, en past de inspanning daarop aan.
    5. GeoptimaliseerdKritische evaluatie gaat vanzelf; engineers herkennen hallucinaties en zelfverzekerd klinkende onzin zonder vaart te verliezen.

  • Bugtoeschrijving

    We kunnen vaststellen wanneer een defect afkomstig is uit AI-ondersteunde code.

    1. Ad hocDefecten worden opgelost zonder dat iemand vraagt waar ze vandaan kwamen; het team heeft geen signaal over de bijdrage van AI.
    2. OpkomendIndividuele engineers merken af en toe een door AI geïntroduceerd defect op, maar het team heeft geen gedeeld beeld.
    3. GedefinieerdWezenlijke aan AI toegeschreven defecten worden benoemd in post-mortems of retro's wanneer ze opduiken.
    4. BeheerdHet team kan achteraf betrouwbaar vaststellen of een defect uit AI-ondersteuning kwam of niet.
    5. GeoptimaliseerdAI-toeschrijving is een heldere, gedeelde lens op elk significant defect; het team heeft een eerlijk beeld van het kwaliteitseffect van AI.

Workflowintegratie

Hoe natuurlijk AI-ondersteuning past in dagelijkse gewoonten, de toolchain, teamprocessen en de mens-AI-balans.

  • Dagelijkse gewoonte

    AI-ondersteuning maakt natuurlijk deel uit van ons dagelijkse engineeringwerk.

    1. Ad hocAI-ondersteuning is een nieuwigheid die af en toe wordt ingezet; geen onderdeel van hoe engineers echt werken.
    2. OpkomendSommige engineers grijpen dagelijks naar AI; anderen zelden.
    3. GedefinieerdDe meeste engineers gebruiken AI meerdere keren per dag in hun normale flow.
    4. BeheerdAI-ondersteuning is volledig verweven in het dagelijkse werk; engineers weten ook wanneer ze het moeten loslaten.
    5. GeoptimaliseerdHet team werkt met een weloverwogen mens-AI-ritme — AI inzetten waar het waarde toevoegt en op het eigen oordeel vertrouwen waar niet.

  • Pipeline-aansluiting

    AI-tools sluiten soepel aan op onze ontwikkelomgeving en CI/CD-pipeline.

    1. Ad hocAI-gebruik leeft volledig buiten de pipeline; output wordt handmatig ingeplakt en de wrijving is hoog.
    2. OpkomendAI-tools werken in editors maar stoppen bij de deur van CI/CD; integratie is oppervlakkig.
    3. GedefinieerdAI is geïntegreerd in editors en codereview; CI/CD-raakvlakken bestaan voor de gangbare gevallen.
    4. BeheerdAI-tools passen end-to-end in de toolchain (IDE, review, CI, zelfs incidentrespons).
    5. GeoptimaliseerdPipeline-integratie is onzichtbaar — AI-ondersteuning verschijnt waar die nuttig is en blijft anders buiten beeld.

  • Procesaanpassing

    We hebben onze processen aangepast om het meeste uit AI-ondersteund ontwikkelen te halen.

    1. Ad hocProcessen zijn ongewijzigd ten opzichte van het pre-AI-tijdperk; het team gebruikt AI binnen een oude workflow.
    2. OpkomendKleine aanpassingen aan standups of reviews om over AI te praten; niets structureels.
    3. GedefinieerdSpecifieke werkwijzen (reviewfocus, gezamenlijk prompten, prompts delen) zijn toegevoegd aan de werkwijze van het team.
    4. BeheerdHet proces van het team is actief ontworpen rond AI-ondersteuning en wordt regelmatig herzien.
    5. GeoptimaliseerdProces en AI evolueren samen; wijzigingen worden getest, wat werkt blijft, wat niet werkt verdwijnt.

  • Mens-AI-balans

    We weten wanneer we op AI moeten vertrouwen en wanneer op ons eigen oordeel.

    1. Ad hocEngineers vertrouwen AI te veel (en leveren de bugs uit) of weigeren het te gebruiken (en missen de hefboomwerking).
    2. OpkomendEngineers ontdekken de grens geval per geval; de keuzes zijn inconsistent.
    3. GedefinieerdDe meeste engineers hebben een verstandig gevoel voor wanneer AI helpt en wanneer niet.
    4. BeheerdHet team heeft gedeelde, geformuleerde heuristieken voor mens-versus-AI-werk; nieuwe engineers nemen ze snel over.
    5. GeoptimaliseerdDe balans is een tweede natuur; engineers schakelen vloeiend tussen modi en bespreken de grens openlijk.

Beveiliging en compliance

Hoe goed het team gevoelige gegevens beschermt, beleid volgt en IP-, licentie- en beveiligingsrisico's in door AI gegenereerde code beheert.

  • Gegevensverwerking

    We vermijden het blootstellen van gevoelige of vertrouwelijke informatie aan AI-tools.

    1. Ad hocEngineers plakken alles in AI-tools — geheimen, klantgegevens, eigen code — zonder erbij na te denken.
    2. OpkomendDe meeste engineers weten dat ze geen geheimen moeten plakken; bij subtielere gegevens (PII, interne ontwerpen) gaat het nog mis.
    3. GedefinieerdEr bestaan duidelijke regels voor wat wel en niet naar AI-tools mag, en engineers volgen die grotendeels.
    4. BeheerdGoedgekeurde datastromen zijn goed begrepen, ondersteund door tooling (redactie, allowlists) en versterkt in reviews.
    5. GeoptimaliseerdBlootstelling van gevoelige gegevens aan AI-tools wordt structureel voorkomen, niet alleen ontmoedigd; het team kan de controles met vertrouwen beschrijven.

  • Naleving van beleid

    We volgen consistent het organisatiebeleid voor AI-gebruik.

    1. Ad hocEngineers zijn onbekend met het AI-beleid van de organisatie of omzeilen het actief.
    2. OpkomendEr is beleid, maar het wordt los gevolgd; engineers gebruiken soms niet-goedgekeurde tools.
    3. GedefinieerdEngineers kennen de regels en blijven erbinnen op de dingen die ertoe doen.
    4. BeheerdBeleid is zichtbaar in workflows (lijsten met goedgekeurde tools, IDE-plugins) en naleving is de weg van de minste weerstand.
    5. GeoptimaliseerdHet beleid is mede-eigendom van het team; hiaten en wrijving worden gemeld aan de beheerder in plaats van omzeild.

  • Besef van IP en licenties

    We begrijpen de risico's rond intellectueel eigendom en licenties in door AI gegenereerde code.

    1. Ad hocEngineers staan niet stil bij waar door AI gegenereerde code vandaan komt of welke licentiegevolgen die heeft.
    2. OpkomendEr is besef maar geen actie; het team zou moeite hebben om vragen van een auditor te beantwoorden.
    3. GedefinieerdEngineers kennen de basis (licentietype van suggesties, attributienormen) en vermijden duidelijke valkuilen.
    4. BeheerdIP-/licentiecontroles maken deel uit van de review; het team kan zijn positie geloofwaardig verdedigen indien gevraagd.
    5. GeoptimaliseerdIP en licenties zijn een expliciet, belegd onderdeel van hoe AI-ondersteunde code wordt opgeleverd; controles en uitzonderingen zijn gedocumenteerd.

  • Waakzaamheid voor kwetsbaarheden

    We controleren door AI gegenereerde code actief op beveiligingsproblemen.

    1. Ad hocDoor AI gegenereerde code gaat zonder beveiligingscontrole naar productie; engineers gaan ervan uit dat het in orde is omdat het werkt.
    2. OpkomendStatische scanners vangen de voor de hand liggende problemen; reviewers kijken zelden verder.
    3. GedefinieerdReviewers controleren door AI gegenereerde code actief op veelvoorkomende beveiligingslekken (injectie, geheimen, onveilige standaardinstellingen).
    4. BeheerdHet team heeft een helder beeld van waar AI-ondersteuning het beveiligingsrisico verhoogt en past daar extra scrutiny toe.
    5. GeoptimaliseerdDoor AI geïntroduceerde kwetsbaarheidspatronen worden bijgehouden, teruggekoppeld naar prompts en reviewchecklists, en herhalen zich zelden.

Kennisdeling

Hoe openlijk het team prompts vastlegt, successen en mislukkingen deelt, teamoverstijgend samenwerkt en zijn AI-vaardigheden laat groeien.

  • Promptbibliotheken

    We documenteren en delen effectieve prompts en AI-patronen.

    1. Ad hocElke engineer vindt dezelfde prompts opnieuw uit; niets wordt gedeeld.
    2. OpkomendEen paar nuttige prompts worden af en toe in de chat geplakt en weer kwijtgeraakt.
    3. GedefinieerdEen gedeelde plek (repo, wiki, bestand) verzamelt prompts en patronen; mensen dragen bij en raadplegen die.
    4. BeheerdDe bibliotheek wordt gecureerd, is actueel en wordt als startpunt voor gangbare taken gebruikt.
    5. GeoptimaliseerdGedeelde prompts evolueren mee met de codebase; de bibliotheek is een echte productiviteitsasset en bespaart aantoonbaar herwerk.

  • Leercultuur

    We delen openlijk successen, mislukkingen en experimenten met AI-ondersteund ontwikkelen.

    1. Ad hocEngineers praten niet over hoe ze AI gebruiken; successen en mislukkingen blijven privé.
    2. OpkomendEr vindt wat delen via zijkanalen plaats (DM's, losse opmerkingen); niets gestructureerd.
    3. GedefinieerdAI-ervaringen komen aan bod in retro's, demo's of standups; zowel successen als missers worden besproken.
    4. BeheerdDelen is een vast teamritme — sessies, verslagen of terugkerende agendapunten.
    5. GeoptimaliseerdHet team heeft een oprechte cultuur van nieuwsgierigheid rond AI; mislukkingen worden gewaardeerd als leermoment, niet bestraft.

  • Teamoverstijgende samenwerking

    We wisselen AI-codeerpraktijken uit met mensen buiten ons directe team.

    1. Ad hocOnze AI-praktijken blijven binnen het team; we weten niet wat andere teams doen.
    2. OpkomendAf en toe vindt informeel teamoverstijgend overleg plaats; geen echte uitwisseling.
    3. GedefinieerdEngineers delen notities tussen teams wanneer het ertoe doet; nuttige patronen verspreiden zich.
    4. BeheerdEr bestaan actieve teamoverstijgende fora of guilds voor AI-praktijken; de deelname is oprecht.
    5. GeoptimaliseerdHet team geeft zowel aan als leert van andere teams continu; AI-praktijk verspreidt zich als een vliegwiel.

  • Vaardigheidsontwikkeling

    We investeren bewust in het laten groeien van onze AI-ondersteunde ontwikkelvaardigheden.

    1. Ad hocVaardigheidsgroei is toevallig; engineers verbeteren alleen wanneer ze toevallig iets nieuws proberen.
    2. OpkomendEen paar zelfgestuurde leerlingen; de meeste engineers blijven op het niveau waarmee ze binnenkwamen.
    3. GedefinieerdHet team reserveert wat expliciete tijd voor het opbouwen van AI-vaardigheden (sessies, pairing, lezen).
    4. BeheerdVaardigheidsontwikkeling is een vaste investering; nieuwe technieken worden geprobeerd, geëvalueerd en als team overgenomen.
    5. GeoptimaliseerdContinue, bewuste groei is onderdeel van de identiteit van het team; engineers worden elk kwartaal zichtbaar beter in AI-ondersteund werk.

Impactmeting

Hoe eerlijk het team het effect van AI op productiviteit en kwaliteit bijhoudt en die lessen terugbrengt in zijn werkwijze.

  • Productiviteitsmeting

    We beoordelen of AI-tools onze opleversnelheid echt verbeteren.

    1. Ad hocNiemand weet of AI ons sneller of langzamer maakt; we gaan ervan uit dat het helpt.
    2. OpkomendOnderbuikgevoel over productiviteit wordt besproken; geen signaal voorbij anekdotes.
    3. GedefinieerdHet team houdt enkele indicatoren bij (doorlooptijd, PR-doorvoer) naast de AI-adoptie.
    4. BeheerdProductiviteitsimpact wordt bewust bijgehouden; het team kan het effect van AI met bewijs beschrijven.
    5. GeoptimaliseerdProductiviteitsmeting is eerlijk over winst en verlies; het team past het AI-gebruik aan op basis van wat de data tonen.

  • Kwaliteitsmetingen

    We beoordelen of AI-ondersteuning de kwaliteit van ons werk helpt of schaadt.

    1. Ad hocGeen zicht op hoe AI defectpercentages, reviewchurn of onderhoudbaarheid beïnvloedt.
    2. OpkomendEngineers merken anekdotisch kwaliteitspatronen op; geen gedeeld signaal.
    3. GedefinieerdHet team houdt kwaliteitsindicatoren bij (defectpercentages, herwerk, reviewfeedback) in de context van AI-gebruik.
    4. BeheerdKwaliteitsimpact maakt deel uit van hoe het team over AI denkt; zowel positieve als negatieve effecten zijn zichtbaar.
    5. GeoptimaliseerdKwaliteit is een eersteklas lens op AI-gebruik; het team heeft zijn praktijk aangepast op basis van wat het ontdekte.

  • Integratie in retrospectives

    We reflecteren op AI-ondersteund ontwikkelen tijdens onze retrospectives.

    1. Ad hocAI-gebruik komt nooit ter sprake in retro's; het is onzichtbaar in de reflectie van het team.
    2. OpkomendAI wordt af en toe in retro's genoemd, meestal als eenmalige opmerking.
    3. GedefinieerdAI-onderwerpen zijn een terugkerende lijn in retro's; het team bespreekt ze wanneer ze ertoe doen.
    4. BeheerdRetro's brengen consistent AI-gerelateerde observaties naar boven en zetten die om in acties.
    5. GeoptimaliseerdAI-gebruik is een vaste lens in retro's; inzichten vertalen zich snel naar veranderde praktijk.

  • Continue verbetering

    We passen ons AI-gebruik aan op basis van feedback, uitkomsten en geleerde lessen.

    1. Ad hocHoe we AI gebruiken verandert niet; we draaien op onze eerste ingevingen.
    2. OpkomendIncidentele aanpassingen op basis van individuele frustratie of een tip van elders.
    3. GedefinieerdHet team herziet zijn AI-praktijken regelmatig; veranderingen blijven hangen als ze hun waarde bewijzen.
    4. BeheerdVerbetering is een echte cyclus — meten, aanpassen, opnieuw meten — en het team kan wijzen op veranderingen die het heeft doorgevoerd.
    5. GeoptimaliseerdContinue verbetering van de AI-praktijk maakt deel uit van hoe het team werkt; niets aan ons AI-gebruik is statisch.

Wanneer deze gezondheidscontrole gebruiken

  • Wanneer je team AI-codeerassistenten heeft ingevoerd en een eerlijke nulmeting wil van hoe effectief ze worden gebruikt.
  • Voordat je doelen stelt of investeringsbeslissingen neemt rond AI-tooling, training of governance.
  • Wanneer door AI gegenereerde code vragen oproept over kwaliteit, beveiliging of reviewgrondigheid die het team openlijk wil aanpakken.
  • Als terugkerend ijkpunt om te volgen hoe je praktijk van AI-ondersteund ontwikkelen kwartaal na kwartaal rijpt.
  • Tijdens een retrospective of teamuitje om een open gesprek aan te wakkeren over waar AI helpt en waar het risico introduceert.

Tips & trucs

  • Laat elk lid onafhankelijk beoordelen vóór de bespreking, zodat het gesprek echte verschillen in perceptie blootlegt in plaats van groepsdenken.
  • Richt de debrief op de dimensies met de grootste spreiding in scores — onenigheid wijst meestal op het meest waardevolle gesprek.
  • Behandel de volwassenheidsniveaus als een gedeelde taal, niet als een cijfer; het doel is eerlijke reflectie, niet hoog scoren.
  • Kies een of twee dimensies om tussen sessies aan te werken in plaats van alles tegelijk te willen verbeteren.
  • Voer de check elk kwartaal opnieuw uit en vergelijk de resultaten om te zien of weloverwogen veranderingen echt het verschil maken.
  • Gebruik de optie 'Niet van toepassing' vrijelijk — niet elke dimensie weegt voor elk team of elke fase even zwaar.

Veelgestelde vragen

Wie zou aan deze health check moeten deelnemen?
Iedereen die met AI-ondersteuning code schrijft, reviewt of oplevert — doorgaans het hele engineeringteam, inclusief leads. Een mix van ervaringsniveaus geeft een eerlijker beeld dan alleen enthousiastelingen of alleen sceptici te bevragen.
Hoe zijn de volwassenheidsniveaus opgebouwd?
Elke dimensie wordt beoordeeld op een vijftraps schaal van Ad hoc via Opkomend, Gedefinieerd en Beheerd naar Geoptimaliseerd. De niveaus beschrijven hoe consistent, weloverwogen en effectief de praktijk van het team is, niet hoeveel tools het gebruikt.
Is een hogere score altijd beter?
Hogere niveaus weerspiegelen een volwassener, weloverwogen praktijk, maar de echte waarde zit in het gesprek en de acties die volgen. Een team dat bescheiden scoort maar eerlijk praat over waar het kan verbeteren, haalt hier meer uit dan een team dat een perfect resultaat najaagt.
Hoe vaak moeten we hem uitvoeren?
Een kwartaalritme werkt goed voor de meeste teams — vaak genoeg om voortgang na veranderingen te volgen, maar voldoende uit elkaar zodat betekenisvolle verschuivingen tijd krijgen om plaats te vinden. Het na een grote tooling- of proceswijziging uitvoeren is ook waardevol.
Wat doen we met de resultaten?
Gebruik de spreiding van scores om te zien waar het team het eens en oneens is, kies een of twee dimensies om op te focussen en zet die om in concrete acties. Kom op die acties terug en voer de check later opnieuw uit om te zien of ze het verschil hebben gemaakt.