Toen we bij Blis Digital begonnen met AI, merkten we al snel: dit moet veel verder gaan dan het ontwikkelen van individuele AI-skills. Als je echt AI-first wilt werken, moet je niet alleen je mensen trainen, je moet ook je teams anders inrichten. Want het effect van AI zit niet alleen in wat één engineer doet, maar in hoe een heel team samenwerkt, leert en versnelt. Dat inzicht was de start van een complete transformatie van ons bedrijf.
We gebruiken de vier levels van AI-adoptie niet alleen om individuele groei zichtbaar te maken, maar ook als hulpmiddel in onze personeelsplanning. Het stelt ons in staat om per projectteam in kaart te brengen waar de sterke punten zitten en waar gaten vallen.
Als een team bijvoorbeeld vooral bestaat uit Level 1- en 2-developers, weten we dat we daar een Level 3 of 4 bij moeten zetten. Iemand die niet alleen zelf AI-first werkt, maar ook het team daarin meeneemt. Dat maakt het verschil tussen “AI erbij gebruiken” en “AI echt integreren in je werkwijze”.
‘Mixing levels’, bewust en strategisch
We stellen onze teams samen met verschillende ervaringsniveaus op AI-vlak. Een typisch Blis Digital-team heeft bijvoorbeeld:
- een product owner of architect op Level 4
- 1 of 2 ervaren developers op Level 3
- developer(s) op Level 2
Waarom? Omdat we geloven in de kracht kennisoverdracht binnen het team. Door ervaren AI-gebruikers samen te laten werken met collega’s die nog aan het groeien zijn, leren mensen in de praktijk. Niet via training, maar via echte projecten en side-by-side werken. We werken heel expliciet niet met ‘AI-specialisten’ die anderen leren hoe AI werkt. We integreren AI-expertise in elke rol, want alleen zo wordt het een vast onderdeel van je proces en dus van je vak. Een Level 2-ontwikkelaar leert dus van Level 3- en Level 4-ontwikkelaars. Designers leren van designers, architecten van architecten.
Teams als hybride mens-AI-eenheid
Wat we echt anders zijn gaan doen, is kijken naar een team als hybride samenstelling: een samenwerking tussen mensen én AI. Niet als losse tools, maar als volwaardige teamleden met hun eigen beperkingen én sterktes. Dat betekent ook dat we rollen opnieuw zijn gaan formuleren. De functietitels zijn hetzelfde, maar de praktijk is totaal veranderd. Een tester die met een LLM-agent tests laat genereren en uitvoeren, werkt op een ander abstractieniveau dan een tester die alles zelf klikt. Een developer die een AI prompt ‘engineert’ om boilerplate-code te genereren, werkt anders dan iemand die dat handmatig uitschrijft.
De oude testers en developers bestaan dus uiteindelijk helemaal niet meer. Van de ‘nieuwe’ vragen we een andere mindset. Je moet bereid zijn om werk los te laten, om te delegeren aan AI en om tegelijkertijd verantwoordelijkheid te blijven nemen voor het resultaat. Niet makkelijk, maar wel nodig.
We hebben dat ook gemerkt in onze eigen productteams. In één project werkte een Level 3 engineer aan een complexe nieuwe functie met een strakke deadline. In plaats van alles zelf te bouwen, splitste hij de taak op: het kernalgoritme bouwde hij zelf, maar de randcomponenten — logging, API-koppelingen, validatie — liet hij een AI-agent genereren. In een halve dag had hij iets werkends. Zonder AI was dit minstens twee weken werk geweest.
Kleinere teams, meer eigenaarschap
Teams worden dus kleiner. En we weten al heel lang: kleinere teams werken beter. Ze nemen beslissingen sneller, hebben minder overdrachtsmomenten en er gaat minder kennis en informatie verloren. En AI zorgt dat ze meer werk kunnen doen dan grotere teams daarvoor, mits het mensen zijn met overzicht en die de tooling onder controle hebben.
Twee mensen die effectief met AI samenwerken, hebben in mijn ervaring uiteindelijk meer grip op het proces dan een groter team van specialisten. Omdat veel van het codeerwerk door AI gedaan wordt, is er ook geen reden meer om refactoring uit te stellen. Daardoor bouwt het project ook minder technical debt op.
In mijn visie wordt het ideale projectteam een team van twee: een engineer en een consultant. Of, als dat beter past, een developer en een productmanager. Dat zijn dan geen klassieke ‘bouwers’ meer, maar ontwerpers van een oplossing. Mensen die samen, vanuit hun expertise, op een hoog abstractieniveau aan een product werken en daarbij een groot deel van het werk uitbesteden aan AI.
Hoewel deze kernteams klein zijn, betekent dat niet dat ze geïsoleerd opereren. Ze kunnen nog steeds een beroep doen op de expertise van specialisten – denk aan UX-designers, security-experts, testers of cloud-architecten – die hen ondersteunen waar nodig. Ook deze specialisten maken gebruik van AI in hun werk, maar zijn inhoudelijk vaak minder diep betrokken bij het specifieke domein van het product. Zo blijft specialistische kennis toegankelijk, zonder de wendbaarheid van het kernteam te belemmeren.
De uitdaging is om een goede balans te vinden tussen efficiëntie en menselijke continuïteit. Het is dus prima — en soms zelfs wenselijk — om twee engineers en twee productspecialisten in te zetten, ook als de omvang van het werk daar niet direct om lijkt te vragen. Continuïteit, samenwerking en gedeeld eigenaarschap zijn minstens zo belangrijk als schaalbaarheid.
AI als factor in projectplanningen
Een van de grootste veranderingen zit misschien nog wel in hoe we projecten plannen. Waar we vroeger inschatten hoeveel mensen en uren nodig waren, houden we nu ook rekening met de mate waarin AI taken kan overnemen of versnellen.
Bijvoorbeeld: een module die traditioneel drie weken kostte, kan met een Level 3-engineer en een slimme AI-agent soms in vijf dagen klaar zijn. Of een test-cyclus die normaliter tien dagen duurde, wordt gecomprimeerd tot drie dagen met hulp van automatische testgeneratie.
AI is nu een resource. Geen tool die je inzet, maar een capaciteit die je meeneemt in je planning. En dat betekent dat onze resourceplanning flexibeler is geworden, maar ook slimmer. We kijken niet alleen naar capaciteit in mensen, maar ook naar de AI-vaardigheid van die mensen. En dat scheelt, zeker bij krappe deadlines.
Naar echte snelheid
We hebben door AI ook onze kijk op agile herzien. De traditionele agile-setup — met aparte rollen, ceremoniële overleggen en veel communicatie — past steeds minder goed bij hoe we nu werken. Soms laat ik in presentaties een slide zien met aan de ene kant het klassieke agile-plaatje vol poppetjes en pijltjes, aan de andere kant twee mensen en een handvol AI-agents. En dan stel ik de vraag: welke setup levert sneller waarde?
De komende jaren gaan we toe naar compactere, snellere teams. Maar dat lukt alleen als mensen leren denken op een hoger abstractieniveau. In plaats van: “hoe schrijf ik deze code”, moet de vraag zijn: “hoe ontwerp ik een proces dat deze functionaliteit oplevert — mét hulp van AI?”
AI-kracht vermenigvuldigen door structuur
Wat we geleerd hebben, is dat AI pas echt tot z’n recht komt als je de juiste structuur eromheen zet. Dat betekent niet alles centraal bepalen en geen ruimte laten voor creativiteit en innovatie. Maar wél: richtlijnen over hoe we met AI werken, welke tools we gebruiken en (vooral) hoe we kwaliteit borgen. Die normen bepalen wij, als managementteam. Natuurlijk is er inspraak, maar uiteindelijk moet het gewoon werken in de praktijk.
De kunst is om structuur aan te brengen zonder het experiment te verstikken. Daarom blijven we ruimte maken voor verkenning: we besteden veel tijd aan R&D. We hebben een kopgroep die experimenteert, we hebben wekelijkse momenten waarin lead developers tooling en ervaringen bespreken en we passen continu aan. En iedereen kan een bijdrage leveren. Binnen Blis is AI-adoptie geen strak opgelegd programma, maar een uitnodiging om te groeien.
Dit is deel 4 in een vijfdelige serie over AI-first werken in software development. In de whitepaper ‘Het fundament van een AI-first bedrijf’ lees je over het framework dat wij gebruikten om Blis Digital AI-first te maken en wat we nu toepassen bij het AI-first maken van onze klanten.
Lees ook:
Blog 1: Waarom veel softwarebedrijven de AI boot missen
Blog 2: Het 4-level framework; zo bevorder je AI-readiness in je team
Blog 3: Waarom AI juist méér senioriteit vraagt
