Binnen Kabisa staat het delen van kennis en ervaring centraal. Twee keer per jaar zetten we daarvoor een hele middag en avond opzij: de craftsmanshipdag. Een dag waarop we elkaar inspireren met presentaties, tafelgesprekken en groepsdiscussies – en waarop we dieper nadenken over hoe we ons vakmanschap dagelijks toepassen en continu kunnen blijven verbeteren.
Op 8 april 2026 kwamen we samen op kantoor in Weert voor de eerste editie van dit jaar. Rode draad: de razendsnelle opmars van AI in ons dagelijkse werk en wat dat betekent voor wie wij als Kabisa zijn.
Craftmanship
Onze definitie van craftsmanship blijft onveranderd:
“Building the right thing and building the thing right.”
Kwaliteit zit voor ons niet alleen in de code die we schrijven, maar ook in het advies dat we geven. Wat wel verandert is de context waarin we dat vakmanschap toepassen. Een jaar geleden schreven we nog het grootste deel van onze code zelf; vandaag werken veel van ons met agentic workflows, waarbij AI hele features oplevert op basis van onze specs. Juist daarom voelde deze dag urgent.
Wat blijft er over van ons ambacht als de machine het typewerk overneemt? Waar ligt onze toegevoegde waarde? En hoe bewaken we kwaliteit op een tempo dat nog maar een jaar geleden ondenkbaar was?
Tafelgesprekken: identiteit en cognitieve load
In groepjes van vijf tot zes gingen we aan de slag met twee stellingen. Bij elke stelling stemden we eerst anoniem via Mentimeter, en gingen daarna met elkaar het gesprek aan.
Stelling 1: “De beste developer over 2 jaar is niet de beste programmeur, maar de beste AI-aanstuurder. En dat is prima.”
Een lichte meerderheid was het eens met de stelling, maar in de gesprekken werd al snel duidelijk dat “AI aansturen” allesbehalve een noodgreep is. Het vraagt echte vaardigheid: werk opbreken, context meegeven, op het juiste moment bijsturen, en het resultaat kunnen beoordelen. De analogie die in meerdere groepen terugkwam: het lijkt op mensen aansturen. Werk kleiner maken, voldoende uitleg geven, de juiste autonomie toelaten.
"Zolang ik het gevoel heb dat ik nog voldoende invloed heb, denk ik dat ik gewoon trots kan blijven."
De trots verschuift, maar verdwijnt niet. De voldoening van het typen neemt af; de trots op architectuurkeuzes, op het begeleiden van collega’s, en op het bijsturen van AI op het juiste moment neemt toe. Uit groep Ariejan kwam een mooie formulering: de abstractiestapel loopt van ponskaarten → assembler → hogere programmeertalen → nu AI. Elke stap nam werk weg, maar vroeg dat je de laag eronder blijft begrijpen.
Stelling 2: “AI maakt niemand productiever. Het verhoogt alleen de baseline van wat ‘normaal’ is, en iedereen draait harder.”
Hier was het beeld verdeelder. De gedeelde conclusie: je draait harder en je bereikt meer, maar de verhoudingen zijn ongelijk en situatie-afhankelijk. Bepaalde taken gaan aanzienlijk sneller, terwijl de cognitieve last stijgt doordat je meer parallel doet en minder echte rustmomenten hebt.
"Er zat een heel erg grote hit en miss ratio in. Sommige dagen lijken van alles heel veel sneller te gaan, en andere dagen loop je helemaal klem en bereik je veel minder."
Meerdere groepen signaleerden dat deep work lastiger wordt: de AI is bezig, je wacht, je begint ondertussen iets anders, en aan het eind van de dag heb je veel gedaan maar ben je ook uitgeput. Het flow-gevoel, in de zone raken, is aanzienlijk moeilijker te bereiken.
De scherpste observatie ging over kennisoverdracht. Een feature die vroeger een week kostte met pair-programming en whiteboard-sessies, wordt nu solo in twee dagen gebouwd. Dat is sneller, maar de kennis embeddet niet meer in het team. En de productiviteitswinst van nu is tijdelijk: zodra iedereen het gebruikt, wordt het de nieuwe norm. Zoals iemand het samenvatte: “de mensen die heel goed zijn, die worden met AI nog beter. En mensen die niet zo heel goed zijn, die krijgen met AI-tools dan nog sneller troep te maken.”
Groepsdiscussie: AI & PR reviews
Na de tafelgesprekken zoomden we plenair in op één concrete plek waar AI ons werk raakt: het code review-proces. De vraag: wat betekent AI voor eigenaarschap, verantwoordelijkheid en teamcultuur?
Over één ding was de groep vrijwel unaniem: AI verandert niets aan wie verantwoordelijk is. AI schrijft de code, de developer tekent ervoor. De stelling “Als AI het grootste deel van de code in een PR heeft geschreven, draagt de auteur nog steeds de volledige verantwoordelijkheid” kreeg een 4.8 op 5.
De vuistregel die breed werd gedeeld: als je het niet kunt uitleggen aan een collega, dien je het niet in. Niet elke byte hoef je te kennen, maar je moet de gemaakte keuzes en de reden daarachter kunnen verantwoorden, zeker op code die je over twee jaar nog moet onderhouden.
Waar teams wél mee worstelen: concrete afspraken. Betekent een approval nog hetzelfde als de PR voor 80% door AI is geschreven? Als je zelf al een AI-review hebt laten doen, weet je collega dat? Zijn review-comments die je via AI hebt laten opstellen eigenlijk van jou? De aanbeveling die breed werd herkend: maak dit onderdeel van je way-of-working-document. Niet als AI-uitzondering, maar als expliciete afspraak.
De rol van de software artisan
In een aparte groepssessie onder leiding van Pascal ging het over de vraag: wat is straks nog de rol van de software artisan? De stelling stond scherp — “de enige relevante software artisan is straks iemand die de taal van de business spreekt” — maar de groep nuanceerde meteen: dit was altijd al waar. Wat verandert is de zichtbaarheid.
"De verantwoordelijkheden die je pakt worden zichtbaarder. De codeklopper-stempel die ons soms werd opgeplakt, terwijl we altijd al meer deden, dat wordt zuiverder."
De rol die we zien ontstaan: de developer als brug tussen business en AI. Genoeg technische diepgang om AI goed aan te sturen, en genoeg business-begrip om te vertalen wat de klant écht nodig heeft. Kabisa beweegt daar al een tijd naartoe — met vragen van klanten die niet willen dat we software voor hen bouwen, maar hen helpen om zelf goede software te kunnen maken.
Over de tweede stelling — “code kwaliteit en documentatie zijn niet meer belangrijk in het AI-tijdperk” — was de groep ronduit oneens. Sterker: juist nu worden ze belangrijker. AI is een papegaai van je codebase. Heldere patronen, goede documentatie en ADR’s zorgen ervoor dat AI vliegt in plaats van struikelt. Betere documentatie is geen overhead; het is een multiplier op wat AI kan.
Lightning talks
Naast de discussies was er ruimte voor zestien korte presentaties, in drie blokken verdeeld over de dag. Onderwerpen liepen uiteen van homelab-setups en het bouwen van een eigen NAS, via lokale AI-modellen en meeting-transcriptie, tot AI agents, backend-integraties en CV-analyse. Van concrete tools die collega’s morgen kunnen gebruiken tot experimenten die de verbeelding prikkelen.
Wat opvalt: vrijwel elke talk had op de een of andere manier een AI-component. Niet omdat dat verplicht was, maar omdat het bij iedereen — op z’n eigen manier — het werk aan het veranderen is.
Na een lange dag vol gesprekken, stellingen en nieuwe inzichten hebben we samen gegeten en nog lang nagepraat over alles wat langsgekomen was. De belangrijkste rode draad: we zitten midden in een verschuiving die niemand van ons een jaar geleden zo precies had voorzien. Maar de waarden waar Kabisa op rust — de juiste dingen bouwen, en die dingen goed bouwen — zijn niet verouderd. Ze worden alleen op een nieuwe manier ingevuld.
