AI Readiness

AI readiness beschrijft de mate waarin een organisatie technisch, organisatorisch en strategisch in staat is om AI-toepassingen succesvol te implementeren. Het gaat niet alleen om de technologie, maar ook om datakwaliteit, interne kennis, governance en het vermogen om AI te vertalen naar aantoonbare businesswaarde.

AI-volwassenheid varieert sterk: van organisaties die AI kennen als code-autocomplete, tot teams die AI als primair productie-instrument inzetten en hun hele werkwijze eromheen hebben heringericht. De meest betrouwbare manier om je positie te bepalen is een eerlijk gesprek over wat je nu doet, wat het oplevert, en wat de barriere is voor de volgende stap. Technologie is zelden het echte probleem -- eigenaarschap, data en strategie zijn dat vaker.

AI-pilots mislukken zelden door de techniek. De meest voorkomende oorzaken zijn een onduidelijke probleemstelling vooraf, onvoldoende datakwaliteit, gebrek aan intern eigenaarschap, en een te grote afstand tussen technische uitvoering en de businessdoelstelling.

Organisaties die beginnen bij de businessvraag -- wat willen we verbeteren, versnellen of mogelijk maken -- vinden sneller een zinvol startpunt dan organisaties die beginnen bij de technologie.

Datakwaliteit is een van de meest onderschatte factoren. Onvolledige of inconsistente data leidt tot onbetrouwbare uitkomsten, ongeacht de kwaliteit van het model.

AI governance omvat de afspraken, processen en verantwoordelijkheden die bepalen hoe AI-systemen worden ontwikkeld, ingezet en gemonitord -- inclusief naleving van regelgeving zoals de EU AI Act.

Automatiseren laat een proces vaste, vooraf vastgelegde stappen volgen. Agentificeren voegt agents toe die een vraag begrijpen, zelf de juiste informatie ophalen en die tonen binnen de context van de applicatie.

Ja. Tools zoals GitHub Copilot en Claude Code ondersteunen zowel low-code als pro-code ontwikkeling, van codegeneratie tot het sneller opzetten van apps. Dat verkort de time-to-market en geeft ruimte voor de oplossing zelf.

Via het Microsoft 365 Admin Center krijgen beheerders inzicht in gebruik, knelpunten, kosten en gerealiseerde waarde. Daarmee houden ze niet alleen controle, maar kunnen ze ook onderbouwde keuzes maken over verdere inzet.

Dat hangt af van de context, de gebruikers, het proces, de beheerbaarheid, de kosten en de gewenste gebruikerservaring. Begin niet bij de techniek, maar bij de vraag achter de vraag van de klant.

Technologie voegt pas waarde toe als een proces er slimmer, sneller of gebruiksvriendelijker van wordt. De kernvraag blijft of het de klant echt verder helpt, niet of iets technisch mogelijk is.

Prompt engineering bepaalt hoe betrouwbaar AI je bedoeling begrijpt. Voor Nederlandse software- en SaaS-bedrijven die AI in hun product bouwen, is dat het verschil tussen een leuke demo en een oplossing die klanten echt vertrouwen. Wie de context goed inricht, houdt grip op kwaliteit.

Prompt engineering gaat over de vraag die je stelt. Context engineering gaat over alle informatie die je het model daarbij meegeeft. In onze projecten in Nederland zit de winst vooral in die context: hoe scherper je die inricht, hoe betrouwbaarder de output van een AI-agent.

AI's grootste valkuil is dat het fout kan zijn met overtuiging. Je vangt dat op door output structureel te testen en te valideren, met een mens die meekijkt. Bij AI-projecten voor organisaties in Nederland bouwen wij dat validatieproces standaard in het ontwerp.

Vooral software- en dataintensieve bedrijven met eigen productteams, van scale-ups tot corporates. Zij zijn voorbij de losse experimenten en willen AI structureel inzetten. Een volwassen workflow met vaste structuur, testen en validatie maakt het verschil tussen incidentele en voorspelbare waarde.

Blis Digital helpt organisaties door heel Nederland om van losse AI-experimenten naar structurele, AI-first ontwikkelprocessen te groeien. We denken mee als bijrijder: we bouwen mee én richten het proces eromheen in, met focus op context, testen en menselijke validatie.

Een AI-first cultuur betekent dat AI een vast onderdeel is van hoe mensen werken, in elke discipline, van development tot finance en sales. Het draait om durven experimenteren, delen wat werkt en eerlijk zijn over waar je nog tegenaan loopt. Zo wordt AI een manier van kijken.

Geef deelnemers vooraf een vast format: het probleem, de gekozen AI-oplossing, een concreet voorbeeld en het resultaat. Dat geeft houvast zonder de creativiteit te beperken. Houd het vooral luchtig, want juist in een ontspannen sfeer ontstaan de goede gesprekken over keuzes en grenzen.

Vrijwel allemaal. Bij AIdols lieten acht disciplines het zien: testen, sales, office management, finance, development, studio, service management en enterprise IT. Van geautomatiseerde rapportages tot een AI-agent die tickets beoordeelt, elke afdeling vindt een eigen praktische invalshoek.

Als mensen zich veilig voelen om te experimenteren, ontstaat er meer dan alleen efficiëntie. Dan komen energie, plezier en ideeën waar je zelf niet op was gekomen. Voor Nederlandse organisaties die AI structureel willen inzetten, is die cultuur vaak de echte versneller.

Blis Digital deelt regelmatig praktijkervaringen over AI-first werken met organisaties in Nederland. Van interne sessies zoals AIdols tot echte klantprojecten: we laten zien wat werkt en waar de grenzen liggen, zodat je AI inzet zonder het groter of ingewikkelder te maken dan nodig.

De toverstaf-illusie is het idee dat AI het volledige denkwerk overneemt. Omdat tools als ChatGPT menselijk en intelligent overkomen, staren bedrijven zich blind op de snelle oplossing. Ze vergeten de context die nodig is en denken dat de machine het proces zelf begrijpt.

Een AI-model begrijpt de diepere logica en nuances van jouw specifieke bedrijfsproces niet. De uitkomst alleen is te weinig. Bij vroege projecten bleek al dat techniek zelden het echte probleem is: zonder context bouw je op drijfzand, hoe indrukwekkend het model ook lijkt.

Het kamp algoritmiek geloofde in geprogrammeerde logica, beslisbomen en een beetje machine learning. Het kamp neurale netwerken geloofde dat machines moesten leren door patronen te herkennen, de voorloper van deep learning. Jarenlang won algoritmiek, omdat rekenkracht en data voor neurale netwerken ontbraken.

Waar het vroeger ongeveer negentig procent algoritmiek was met een vleugje machine learning, verschuift het nu richting machine learning met traditionele algoritmiek alleen waar nodig. De rekenkracht en data die vroeger ontbraken zijn er inmiddels in overvloed, waardoor neurale netwerken hun waarde tonen.

In een wereld vol rekenkracht wordt het menselijke vermogen om context te zien, ethiek te bewaken en de juiste vragen te stellen belangrijker. AI levert de kracht, maar de mens blijft de bestuurder die richting geeft en beoordeelt of de uitkomst klopt.

Suddertijd is de traagheid van handmatig werken waarin informatie van je kortetermijngeheugen naar je langetermijngeheugen sijpelt. Terwijl je typte, debugde en herschreef, sudderde de logica door in je achterhoofd. De volgende dag leverde dat vaak een frisse blik en een betere oplossing op.

De belasting verschuift van doen naar beoordelen. Je komt in een constante review-stand die nooit verslapt: is dit veilig, past het bij de architectuur, begrijp ik echt wat er staat? Die aanhoudende staat van wantrouwen vreet energie, ook al gaat het werk sneller.

Bouw bewust blokken in voor strategisch denkwerk: de koers van een project bepalen, architectuurkeuzes maken en andere developers coachen. Met die helikopterblik hoef je minder in vermoeiende details te duiken. Accepteer ook dat een dag vol AI-regie mentaal korter is dan een traditionele dag.

Een doordachte prompt werkt als nieuwe suddertijd. Door twintig tot dertig minuten na te denken over een prompt, los je het probleem eerst in je eigen hoofd op. Dat levert betere output en een rustiger hoofd, omdat je de regie neemt in plaats van de AI te laten gokken.

AI wint altijd op snelheid, maar weet niet waarom je bouwt wat je bouwt. De menselijke traagheid is het filter dat bepaalt of software goed of fout is. Richting geven, keuzes maken en ingrijpen wanneer het moet, blijft het werk waar mensen het verschil maken.

De OWASP LLM Top 10 is een overzicht van de tien grootste beveiligingsrisico's bij toepassingen die large language models gebruiken. Denk aan prompt injection, het lekken van gevoelige data en een agent die te veel mag. OWASP stelt de lijst samen op basis van praktijkincidenten en input uit de securitygemeenschap.

Omdat je aan de voorkant voorkomt dat een review je project weken stillegt. Als je basismaatregelen vanaf het begin inbouwt, sta je met vertrouwen voor die securitycheck en hoef je achteraf niets open te breken. Je verliest minder tijd aan herstelwerk en kunt met een gerust hoofd door naar productie.

Je begint met het scheiden van instructies en gebruikersinvoer, zodat een model kwaadaardige input niet als opdracht leest. Daarnaast filter je invoer, beperk je wat de agent mag aanroepen en log je alle acties. Beide platformen bieden hiervoor ingebouwde opties. Het whitepaper zet per platform op een rij wat je concreet aanzet.

Toegangsbeheer, invoervalidatie en logging leveren de meeste winst. Wie strak regelt welke data en systemen een model mag benaderen, dekt in een keer risico's als data leakage en excessive agency af. Het whitepaper markeert per maatregel welke risico's je ermee afvangt, zodat je begint bij wat het breedst beschermt.

Zodra een model toegang heeft tot gevoelige bronnen zonder duidelijke grenzen. Denk aan een agent die klantgegevens kan opvragen en die per ongeluk in een antwoord teruggeeft, of documenten die via de context uitlekken. Je beperkt dit door de agent alleen toegang te geven tot wat hij echt nodig heeft.

Door van je pilot geen eindpunt maar een bewijs te maken. Leg vast wat werkte en wat niet, regel eigenaarschap en governance, maak data en architectuur herbruikbaar en prioriteer vervolg-use-cases op businesswaarde. Zo groeit één succesvolle pilot uit tot een AI-portfolio in plaats van een verzameling losse experimenten.

Ja, mits je vooraf toestemming vraagt aan alle deelnemers en duidelijk bent over bewaartermijnen. Blis verwijdert opnames na dertig dagen en bewaart alleen het transcript.

Onderzoek naar leads, gespreksverslagen, offertes in een vast format en de overdracht naar delivery. Taken met veel structuur en herhaling leveren de grootste tijdwinst op.

Breng eerst je eigen werkproces in kaart en kies één stap waar AI direct tijd bespaart, bijvoorbeeld leadonderzoek. Breid pas uit als die stap goed loopt.

Dat kan, maar beoordeel elke koppeling vooraf kritisch. In een CRM staan persoonsgegevens en bedrijfsgevoelige data, dus maak werkafspraken over wat de tooling wel en niet mag inzien.

Ja, als je de finale check zelf doet. Leg tone of voice en huisstijl vast in skills, houd de tekst kort en controleer elk woord voordat iets naar de klant gaat.

Spreek korte looptijden af, eigendom van je code en broncode-overdracht, en documentatie die een andere partij kan overnemen. Vraag ook hoe de leverancier tooling en taalmodellen vervangt zonder herbouw. Zo blijft schakelen naar een ander model of platform een keuze van weken, geen migratieproject van maanden.

Licenties vallen meestal mee, de echte kosten zitten in leertijd. Reken op enkele maanden waarin teams trager werken terwijl ze nieuwe tools en werkwijzen oppakken. Begin met een project van beperkte omvang, meet doorlooptijd en kwaliteit, en breid uit als die cijfers kloppen. Budgetteer ook tijd voor begeleiding van mensen die twijfelen.

Innovatiebudgetten schuiven bij Nederlandse corporates nu per kwartaal in plaats van per jaar, en AI verandert de technische aannames onder een roadmap binnen maanden. Een plan van drie jaar legt keuzes vast die je halverwege wilt herzien. Werk met richting op jaarniveau en concrete besluiten per kwartaal.

Leg de kaders een keer vast en toets elke tool daaraan: waar staat de data, welke bewerkersovereenkomst geldt, en wat gebeurt er met prompts en logs. Houd een korte lijst goedgekeurde modellen bij, met per model de regio van verwerking. Een nieuwe tool erbij betekent dan een toets van dagen.

Vacatures worden breder. In de regio Rotterdam concurreer je om mensen die meerdere rollen kunnen pakken en die snel nieuwe tooling oppakken. Zet in de vacaturetekst hoe vaak jullie werkwijze verandert, dan trek je kandidaten die daar energie van krijgen. Reken ook op meer interne opleiding dan voorheen.

Begin klein en concreet. Geef een handvol developers en consultants een betaald AI-abonnement, kies twee terugkerende taken zoals marktresearch en documentatie, en spreek af dat je na vier weken terugkijkt. Wat tijd oplevert, breid je uit. Wat niets oplevert, stop je zonder discussie.

Reken op ongeveer 20 tot 40 euro per persoon per maand voor een zakelijk AI-abonnement, plus een codeerassistent in dezelfde orde. De grootste kostenpost is leertijd: een paar uur per developer per maand om prompts, checks en werkafspraken te ontwikkelen. Licenties zijn goedkoop, gewenning kost aandacht.

Meestal ligt het aan onduidelijkheid over toestemming. Zonder beleid over data en tools durven mensen niets te delen, dus blijft AI hangen bij privegebruik thuis. Een korte richtlijn over welke data wel en niet in een model mag, haalt die rem er direct af.

Zet een mens op de punten waar fouten doorwerken: klantcommunicatie, besluiten over personen en verwerking van persoonsgegevens. Laat het model tussenresultaten expliciet vastleggen, zodat je kunt zien waar stap twee misging voordat stap twintig eruit rolt. Log prompts en uitkomsten voor je verantwoording richting de Autoriteit Persoonsgegevens.

Leg vast welke modellen en tools het team mag gebruiken, waar jouw code en data terechtkomen, en wie de output reviewt. Vraag ook hoe de leverancier omgaat met nieuwe modelversies. Dat voorkomt dat elke twee weken een andere werkwijze jouw project binnenkomt.

Laat AI het eerste idee leveren en herschrijf daarna zelf. Geef het model voorbeelden van je eigen mails en notities, zodat de toon dichter bij je komt. Schrap superlatieven, kort zinnen in en check of een klant in Nederland dit zo van jou zou verwachten. Jij klikt op verzenden.

Spreek af wie inhoudelijk eigenaar is van elk stuk dat naar buiten gaat, en dat die persoon het antwoord ook zonder AI kan onderbouwen. Leg vast welke tools mogen, welke klantdata erin mag en waar output wordt gecontroleerd. Bij twijfel gaat het stuk terug naar de auteur.

Reken op twee kostenposten: Microsoft-licenties voor Copilot en Power Platform, plus de bouwtijd. Een agent voor veelgestelde IT-vragen is vaak in enkele dagen werkend, mits je kennisbank op orde is. Slechte documentatie kost meer tijd dan de techniek. Vraag altijd een inschatting per usecase.

Omdat een klant tijdens het gesprek een richting verwacht, geen samenvatting achteraf. Je moet keuzes kunnen verdedigen, weten wat er in deze organisatie politiek speelt en zien welk scenario ontbreekt. AI levert het voorwerk en de eerste versie. De afweging en het gesprek blijven mensenwerk.

Je begint een niveau dieper, wat prettig is en risicovol tegelijk. Zonder ervaring zie je niet snel of een voorstel klopt. Laat AI je uitleggen waarom iets werkt, toets het bij een senior en draai zelf de klantvragen na. Zo bouw je oordeel op terwijl je tempo maakt.

Begin bij een repeterende testtaak, bijvoorbeeld je regressieset in de browser. Laat je tester die in gewone taal beschrijven en de test met Playwright MCP genereren, zodat je binnen een sprint ziet of het tijd oplevert. Werkt het, breid dan uit naar acceptatiecriteria in Gherkin.

Vooral licenties en leertijd. Reken op een betaald abonnement per tester voor een AI-assistent en tools als V0, plus enkele weken waarin je mensen wennen aan prompten en aan het controleren van gegenereerde tests. De hardware die je al hebt volstaat meestal.

Alles waar de afweging belangrijker is dan de uitvoering: exploratief testen en de keuze wat je bij een deadline laat liggen. Risico gebaseerd testen vraagt dat iemand de context van de klant kent. Laat AI het schrijfwerk doen en houd de prioritering bij je tester.

Omdat een gegenereerde test vaak precies checkt wat er in de user story staat en niets daarbuiten. Je krijgt een groene suite terwijl de randgevallen ongetest blijven. Laat je tester per feature bepalen welke risico's een test verdienen, voordat je de scripts laat schrijven.

Zodra je een flow kunt tekenen, dus voordat er een regel code ligt. In V0 zet je in vijf minuten een wizard of flow neer die je in een refinement laat zien, zodat de klant reageert op iets zichtbaars. Verwerk de feedback direct in je acceptatiecriteria.

Zet een budget per engineer en maak het verbruik zichtbaar in een dashboard. Bij ons verbrandden engineers in het begin ongemerkt honderden euro's aan tokens zonder resultaat, simpelweg omdat niemand meekeek. Spreek af wanneer je een grote agent-run start en wanneer je gewoon zelf typt.

Je houdt het kernalgoritme en de unieke businesslogica zelf en laat de agent de rest bouwen: validatie, UI en foutafhandeling. In een klantproject met krappe deadline stond er zo in anderhalve dag een werkende versie. Begin dus met de vraag wat de AI kan doen en waar jij het overneemt.

Omdat het onzeker voelt: je levert een stuk van je vak in en de eerste pogingen leveren vaak onbruikbare code op. Help mensen er doorheen met pairing en een vast moment per week om resultaten te delen. Reken op enkele maanden voordat het normaal aanvoelt.

Geef de agent een afgebakende opdracht, expliciete constraints over architectuur en codestijl, en een testsuite die de output direct afstraft. Zonder die vangrails krijg je code die werkt in isolatie en breekt in je systeem. Voeg ook een limiet toe aan hoeveel bestanden de agent in een run mag aanraken.

Op een afgebakende taak zie je binnen enkele weken verschil, bijvoorbeeld testgeneratie of documentatie door een eigen agent. Je hele ontwikkelproces omzetten duurt langer: bij ons zat er ongeveer een jaar tussen losse prompts in ChatGPT en werkende agentic workflows. Kies dus een proces en meet daar.

Begin bij een project en zet daar een Level 3- of Level 4-collega bij een team van Level 2-developers. Die persoon werkt side-by-side mee, zodat de rest in echte projecten leert. Reken op enkele weken voordat je verschil ziet in de werkwijze.

Maak expliciet wat de nieuwe rol vraagt: delegeren aan AI en toch verantwoordelijk blijven voor het resultaat. Laat die developer een paar weken side-by-side werken met een Level 3-collega en beoordeel daarna of de mindset verschuift.

Leg vast welke AI-tools je gebruikt, hoe je ermee werkt en vooral hoe je kwaliteit borgt. Bij Blis Digital bepaalt het managementteam die normen, met inspraak uit de teams. Een wekelijks overleg met lead developers houdt de richtlijnen actueel.

Meestal omdat de twee mensen te weinig overzicht hebben of de tooling nog niet beheersen. Een kernteam van twee werkt alleen als beiden op een hoog abstractieniveau kunnen werken. Zet er bij twijfel een tweede engineer en productspecialist bij.

Alleen als je weet welk AI-niveau de betrokken engineer heeft. Een module van drie weken kan met een Level 3-engineer en een AI-agent in vijf dagen klaar zijn, met een team van Level 2 lukt dat niet. Plan die versnelling dus per persoon in plaats van per team.

Laat een senior de output reviewen op precies de dingen die AI structureel misdoet: secrets in de frontend, ontbrekende inputvalidatie en SQL injection. Zet daarnaast een linter en een dependency-scan in je pipeline, zodat de basis automatisch wordt afgevangen. Een pull request zonder menselijke review gaat niet live.

Juniors blijven nodig, maar hun werk verschuift van code typen naar code beoordelen. Koppel elke junior aan een senior die de AI-output samen met hem doorloopt en uitlegt waarom iets een antipattern is. Zo bouw je de senioriteit op die AI-gebruik vraagt.

Geef een kandidaat AI-gegenereerde code te reviewen en kijk of iemand de API-key in de frontend en het SQL injection-lek eruit haalt. Dat toetst het oordeel en de contextkennis die de echte bottleneck vormen bij AI-gebruik. Op de krappe Rotterdamse arbeidsmarkt selecteer je zo breder dan op dienstjaren.

Je ziet het aan je reviews: pull requests worden groter en het nakijken duurt steeds langer. Ook bugs die terugkomen op code die net is aangepast zijn een signaal, net als tests die niemand meer durft te wijzigen. Meet de doorlooptijd van PR naar merge.

Meestal omdat er alleen licenties worden uitgedeeld en verder niets verandert in de manier van werken. Zonder afspraken over review en grenzen gebruikt iedereen AI als zoekmachine en blijft de winst uit. Begin met een klein team van ervaren developers dat de werkwijze uitprobeert en vastlegt.

Vraag bij elk level om een voorbeeld uit de afgelopen twee weken. Iemand die zegt op Level 3 te zitten, laat zien welke taak hij aan een AI-agent overdroeg en hoe hij de output beoordeelde. Zonder dat bewijs blijft het bij een gevoel.

Koppel die meting aan je resourceplanning en doe hem opnieuw bij elke nieuwe teamsamenstelling of grote toolwissel. Laat mensen zelf aangeven waar ze staan, van Level 1 AI User tot Level 4 AI Champion, en gebruik dat in je coachinggesprekken.

Zorg dat er minstens een Level 3 AI Orchestrator meedraait, iemand die complete werkstromen aan agents uitbesteedt en de output beoordeelt zoals werk van een junior developer. Bij Blis leverde die aanpak 80 tot 90 procent bruikbare code in een middag. Vraag om voorbeelden uit hun eigen projecten.

Voeg een Level 3 of 4 toe aan zo'n team, want met alleen Level 1 en 2 blijft de verandering in je werkproces klein. Geef die persoon ook de opdracht om collega's te coachen, zodat alle AI-initiatieven niet bij een enkeling blijven hangen.

Omdat de succescriteria te vaag blijven. Vraag je een agent om tests op basis van een halve beschrijving, dan dekt hij alleen de happy path. Schrijf de randgevallen zelf uit voordat je de AI de tests en de code laat maken.

Blis mixt bewust ervaringsniveaus, bijvoorbeeld een architect op level 4 met één of twee level 3-developers en developers op level 2. Zo leren minder ervaren teamleden in de praktijk van collega's die AI al structureel inzetten, in plaats van via een aparte training. Kennisoverdracht gebeurt zo side-by-side, binnen echte projecten.

Een hybride team behandelt AI als volwaardig teamlid, met eigen beperkingen en sterktes. Een tester die met een LLM-agent tests laat genereren, werkt op een ander niveau dan iemand die alles handmatig klikt, ook al blijft de functietitel gelijk. De praktijk van de rol verandert dus wel.

Blis ziet het ideale kernteam als twee mensen, bijvoorbeeld een engineer en een consultant of een developer en een productmanager. Zij ontwerpen de oplossing op een hoog abstractieniveau en besteden een groot deel van het bouwwerk uit aan AI. Specialisten zoals UX-designers of security-experts blijven beschikbaar voor ondersteuning waar nodig.

Omdat AI veel codeerwerk overneemt, is er geen reden meer om refactoring uit te stellen tot later in het project. Kleinere teams nemen ook sneller beslissingen en verliezen minder kennis bij overdrachtsmomenten. Twee mensen die goed met AI samenwerken, hebben volgens Blis vaak meer grip op een project dan een groter team van specialisten.

Ja, de klassieke agile-opzet met losse rollen en veel overleggen past minder goed bij compacte AI-teams. Blis zet in presentaties het klassieke agile-plaatje met poppetjes en pijltjes tegenover twee mensen en een handvol AI-agents, en vraagt welke opzet sneller waarde levert. Dat vraagt vooral een hoger abstractieniveau van denken.

AI genereert met gemak code die ogenschijnlijk werkt maar een beveiligingslek of antipattern bevat. Bij Blis halen de meest ervaren engineers het meeste uit AI, omdat ze het gebruiken om hun denkproces te versnellen in plaats van werk uit handen te geven. Zonder die ervaring krijg je tech debt op AI-snelheid.

Een teamlid liet in twee uur een werkende app bouwen met AI-hulp, maar de API-key stond onbeschermd in de frontend en er zat een groot SQL injection-lek in. Het voorbeeld laat zien dat AI met evenveel gemak een kwetsbaarheid genereert als een werkende functie. Wie de output niet kritisch bekijkt, ziet dat verschil niet.

Een growth mindset is het geloof dat je jezelf continu kunt ontwikkelen door te oefenen. Blis merkt dat teams met die houding sneller groeien dan teams die AI eenmalig uitproberen en er dan mee stoppen. Wie denkt 'ik kan hier iets nieuws leren' groeit sneller dan wie zich bedreigd voelt.

Een zoekmachine geef je een losse vraag, een stagiair geef je een duidelijke opdracht die je controleert en soms laat overdoen. Blis traint mensen daarom vooral op goede prompts schrijven, grenzen stellen en resultaten checken. Dat geldt voor developers, en ook voor testers die met AI honderden tests genereren en logbestanden controleren.

Developers worden minder uitvoerder en meer ontwerper van hun eigen proces: ze bedenken eerst hoe een oplossing eruit moet zien en pas daarna hoe AI daarbij helpt. Bij Blis levert dat snellere, consistentere software op en meer werkplezier voor het team. Wie zo werkt, weet precies wat hij aan AI overlaat.

Een AI User gebruikt AI passief, bijvoorbeeld voor een stukje code of een samenvatting, zonder dat de werkwijze verandert. Een AI Collaborator werkt actief samen met AI: die persoon bepaalt zelf de aanpak, laat AI een eerste versie maken en controleert die kritisch. Het verschil zit in wie de regie heeft.

Een AI Orchestrator besteedt hele onderdelen van een project uit aan AI-agents, inclusief context en grenzen, en beoordeelt de output als werk van een junior developer. Bij Blis leverde dat 80 tot 90% bruikbare code op na één middag werk aan een bestaande applicatie. Een Collaborator blijft dichter bij losse taken.

Een AI Champion helpt anderen groeien in hun AI-vaardigheid, met workshops, documentatie en collega's meenemen in nieuwe tools. Bij Blis vormt een kopgroep van nieuwsgierige pioniers deze rol, met ruimte om te experimenteren voordat iets breed wordt uitgerold. Zo wordt AI een gedeelde vaardigheid in het team.

Blis brengt per projectteam in kaart welke levels aanwezig zijn en zet bewust een Level 3- of 4-persoon bij een team met vooral Level 1- en 2-profielen. Die persoon werkt zelf AI-first en coacht de rest van het team mee in die werkwijze. Zo wordt het raamwerk een praktisch hulpmiddel bij het samenstellen van teams.

Nee, het framework is bedoeld als houvast en gezamenlijke taal, geen dogma om precies aan te houden. Blis gebruikt het vooral om te bepalen waar iemand staat en als uitnodiging om te groeien. De meeste organisaties onderschatten hoeveel hun team al kan en overschatten hoeveel er vanzelf verandert.

Een succesvol ontwikkelteam heeft meer nodig dan programmeurs alleen: een mix van technische, creatieve en zakelijke vaardigheden. Denk aan cloud-kennis, out-of-the-box probleemoplossing en het vermogen om mee te denken over wat echt waarde toevoegt voor de eindgebruiker. Die combinatie van mindset en kennis bepaalt het verschil tussen een team en een groep individuen.

Een team kan bestaan uit een solution architect voor het technisch ontwerp, een business analist die requirements vertaalt, UX-specialisten, developers, cloud- en data-engineers en testers. Project- of servicemanagers houden het geheel op de rails. Rollen zijn niet strikt gescheiden: developers dragen ook bij aan infrastructure-as-code.

Flexibiliteit en gedeelde verantwoordelijkheid maken een team sterker dan strikt afgebakende taken. Cloud engineers denken bijvoorbeeld mee over architecturale keuzes buiten hun eigen rol, en testers werken vroeg in het proces samen met developers om problemen te signaleren. Zo draagt iedereen actief bij aan het projectresultaat, met een duidelijke eindverantwoordelijke per onderdeel.