Het moment van herkenning

Een paar weken geleden zat ik in een retrospective met mijn team. Een van mijn developers had een feature niet op tijd afgeleverd—niet door incompetentie, maar door misjudgering van scope. De eerste gedachte die in mijn hoofd opkwam was niet ‘waarom heb je dit niet eerder gezegd’ of ‘volgende keer plan je beter’, maar: dit is zijn moment om hiervan te leren. Mijn rol is feedback geven, niet hem sturen als een marionette.

Later die avond, terwijl ik nauwelijks sliep, dacht ik: waarom voelt dit als het enige wat ik kan doen, en tegelijk ook als het lastigste? Toen zag ik het patroon. Ik was niet passief. Ik had net omgekeerd gedaan wat veel managers doen: ik liet los wat ik niet kon controleren (zijn leerproces, zijn motivatie) en concentreerde me op wat ik wel kon bepalen (mijn feedback, mijn toon, mijn geduld). Dat is stoïcijn management. En ik was het al aan het doen zonder het zo te noemen.

Wat stoïcisme werkelijk is

Stoïcisme krijgt regelmatig de schuld voor passiviteit, alsof het ‘wat gebeurt, gebeurt’ betekent. Dat is een mislezing. Onzin. Marcus Aurelius en Seneca leidden massa’s mensen—het imperium, miljarden in geld, politieke macht—en hun notitieboekjes gaan over dezelfde wrijving als die ik nu tegenkom: incompetente mensen, vertragingen, verdriet. Ze waren niet passief. Ze waren helderziend.

Het echte idee is dit: je scheidt wat je controleert van wat je niet controleert. Wat je controleert zijn je reacties, je doelen, je waarden, je dagelijks werk. Wat je niet controleert zijn de uitkomsten, wat anderen voelen, of de markt meewerkt. Het verschil lijkt subtiel, maar het verandert alles.

Als ik probeer te controleren dat mijn developers geen fouten maken, of dat ze enthousiast zijn, of dat hun carrièrepad dat van mij volgt—dan zit ik voortdurend in conflict met de realiteit. Ik word emotioneel, defensief, controleerend. Ze voelen dat en groeien juist minder. Dat is wat ik zie gebeuren bij managers die uit angst leiden.

Als ik in plaats daarvan mijn energie richt op wat ik wel bepaal—helderheid over wat we bouwen, eerlijke feedback, een cultuur waar fouten onderdeel zijn van groei—dan gebeurt er iets anders. De spanning valt weg. Ze beginnen eigenaarschap te voelen.

Drie dingen die een stoïcijnse lead anders doet

Één: je verhaal over het probleem corrigeren

Een junior developer brengt slecht nieuws: de integratie gaat twee dagen langer duren. De meeste managers voelen meteen woedeenergie: ‘hoe kon je dit missen, dit verzieking nu ons sprint plan’. Dat verhaal, dat moment van interpretatie, determineert alles daarna. Je toon, je beslissingen, hoe het team reageert.

Stoïcisme zegt: het feit is neutraal. De integratie duurt langer. Punt. Het verhaal dat ik erover vertel—dat dit een ramp is, dat iemand gefaald heeft, dat mijn week nu verwoest is—dat verhaal maak ik zelf. En ik kan het ook anders maken.

Wat ik dus doe: ik pauzer, ik zeg tegen mezelf ‘dit is informatie, niet drama’, en dan vraag ik: wat bepaal ik hierover? Ik bepaal hoe ik dit aanpak. Ik bepaal de volgende stap. Ik bepaal hoe ik erover communiceer naar boven, naar het team. Dat focus geeft ruimte. En ineens is het gewoon een probleem dat opgelost moet worden, niet een moreel falen.

Twee: je geeft richting, niet instructies

Ik zeg tegen mijn developers niet hoe ze code moeten schrijven. Ik zeg wel wat het doel is, welke constraints bestaan (performance, beveiliging, datakwaliteit), en ik vrees niet voor onenigheid over het pad. Dat is lastig voor iedereen, want het voelt minder snel. Maar het leidt ertoe dat zij hun brein gebruiken, niet hun gehoorzaamheid.

Dit werkt alleen als ik echt loslaat. Niet alleen in woorden zeg ‘ik vertrouw je’, maar ook in gedrag. Ik controleer niet op de achtergrond. Ik vraag niet constant ‘hoe gaat het’. Ik zet vertrouwen in—en aanvaard ook dat sommigen dat vertrouwen kunnen beschamen. Dat is hun fout, en ze leren ervan. Mijn job is niet hun leven zekerstellen; mijn job is duidelijk zijn en billijk.

Drie: je accepteert dat hun pad niet jouw pad hoeft zijn

Ik heb sterke meningen over architectuur, over hoe je elegante code schrijft, hoe je een career bouwt. Voor veel van mijn developers—vooral de junior—is dat fascinerend, en ze nemen ervan over. Goed. Maar er zitten er ook bij die anders denken, die ander willen groeien, ander willen werken. Ik merkte dat ik daar vroeger ongeduldig van werd. Te veel investering in hun volgers, niet genoeg eigenheid.

Nu zie ik het anders. Dat is niet mijn probleem om op te lossen. Mijn job is hen helpen zien waar zij goed in zijn, hen feedback geven, hen de vrijheid geven het anders te doen. Als een developer een architectuurkeuze maakt die ik niet zou maken, maar het werkt, en het is verdedigbaar—dan is dat zijn groei. Niet de mijne.

Dat voelt tegen-intuïtief. Je wilt je team naar jezelf vormen. Maar stoïcisme zegt: je bepaalt jouw doelen en jouw principes. Hun weg is hun weg.

Waar stoïcisme stopt

Dit klinkt allemaal netjes. Maar er zitten gaten in.

Ten eerste: niet iedereen in je team is stoïcijn. Veel van mijn developers zijn niet geïnteresseerd in filosofie. Ze willen zekerheid, duidelijke regels, een plan dat klopt. Ik kan niet van hen verwachten dat ze mijn helderheid delen. Dus dan moet ik andere gereedschappen gebruiken—betere documentatie, duidelijkere deadlines, meer voorzeggen wat er gaat gebeuren. Stoïcisme helpt mij, niet hen.

Ten tweede: er is een grens tussen ‘hun groeien laten’ en ‘niet mijn verantwoordelijkheid nemen’. Als iemand heel veel zit te worstelen, en ik zeg ‘dat is hun leermoment’, ben ik misschien gewoon afwezig als lead. Ergens moet ik stap in, vraagsteken stellen, misschien helpen. Het verschil zit in intentie: doe ik het omdat ik bang ben en hem wil controleren, of doe ik het omdat het mijn job is hem eerlijk feedback te geven?

Ten derde: stoïcisme lost niet op wat je niet controleert. De markt kan instorten. De sprints kunnen chaos worden door zaken buiten ons bereik. Mijn developers kunnen allemaal vertrekken. Stoïcisme helpt je emotioneel gezond blijven in die chaos, maar het stopt hem niet. Je moet ook gewoon goed werk doen, goed communiceren, flexibel zijn.

Actief versus passief

Hier zit voor mij ook de echte vraag: is dit ontdekking of intentie?

Ik heb al op deze manier gemanaged zonder er bewust over na te denken. Maar nu ik het zie, word ik daar ook verantwoordelijk voor. Ik kan niet meer zeggen ‘het is gewoon wie ik ben’. Ik moet kiezen om het voort te zetten, en op sommige punten bewuster te worden waar ik terugglijdt in controlegedrag.

Gisteravond had ik een gesprek met een van mijn seniors. Hij vertelde dat hij naar een ander bedrijf kijkt. Mijn eerste reflex was schaamte en paniek: heb ik hem niet goed gemanaged? Ben ik tekortkomen? Dat is het controllemechanisme dat terugkomt. Hij gaat niet weg omdat ik faald heb; hij gaat weg omdat hij zelf een keuze maakt. Dat is zijn eigenaarschap. En mijn job is niet hem te houden, maar hem eerlijk te zeggen wat ik van hem vind en wat ik mis als hij gaat.

Die verschuiving—van ‘hoe houd ik hem’ naar ‘hoe ben ik eerlijk’—voelt als de echte toepassing van stoïcisme.

Kan dit schalen?

Ik leid nu negen developers. Als het team groeit naar vijftien, twintig—werkt dit nog? Ik denk van wel, maar anders. Met negen kan ik individuele feedback geven, kan ik nuance brengen. Met twintig moet het meer systeem worden: duidelijkere cultuur-signalen, meer formele structuur, minder persoonlijkheid.

Maar het principe verandert niet. Wat bepaal ik? Mijn doelen als leider (groei, kwaliteit, veiligheid), mijn systemen, mijn waarden. Wat bepaal ik niet? Of iemand het begrepen heeft na één keer uitleggen. Of ze morgen nog willen werken. Of ze voelen dat ze waardevol zijn.

Die scheiding blijft schoon. Het is alleen de detail dat verandert.

Bronnen

• A Stoic Guide To Workplace Peace Of Mind
• Applying Stoicism In the Workplace – 5 Useful Practices
• Dealing With Difficult People at Work: Stoic Strategies
• Stoicism and Leadership: What Managers Can Learn from the Stoics
• The Stoicism of Management

Er zijn nu twee soorten collega’s. De ene stuurt om 09:14 een PR, een voorstel, een demo én een half blogstuk. De andere opent Outlook, ziet die dump, en fluistert zachtjes: “hoe dan?”

Dat is geen karakterverschil meer. Dat is een snelheidsverschuiving. Mensen die AI serieus in hun werk trekken, produceren in een tempo dat de rest niet meer als “hard werken” herkent. Het oogt als toveren. Of als vals spelen. Of als beide, afhankelijk van hoe jaloers je die ochtend bent.

Terwijl jij nog “even afstemmen” plant, heeft die ander al drie versies gemaakt en de slechtste weggegooid.

Flabbergasted als businessmodel

Het patroon is bekend. Iemand in het team adopteert tooling vroeg. Niet speels, maar als onderdeel van het ambacht: prompts, agents, scripts, checks. Die persoon levert ineens niet één document, maar een ketting: analyse, opties, code, tests, samenvatting voor stakeholders. De rest van het team blijft flabbergasted achter. Letterlijk. Mond half open. “Dit had toch twee weken gekost?”

Ja. Vroeger. Toen we nog deden alsof typen het werk was.

Het nare is niet dat de voorloper snel is. Het nare is dat de kloof zichtbaar wordt. Wie niet meedoet, blijft niet stilstaan. Die zakt relatief weg. Vergaderingen in reviews worden ongemakkelijk. “Waarom is jouw output de helft?” is geen leuke vraag als het antwoord is: “omdat ik nog steeds alles zelf uit mijn hoofd zit te peinzen alsof het 2014 is.”

Snelheid is geen kwaliteit (maar kwaliteit zonder snelheid verliest)

Laten we eerlijk blijven. Sneller produceren is niet hetzelfde als beter denken. AI-voorlopers maken ook prachtige bergen middelmatigheid, alleen sneller. Er is een speciale hel waarin iemand in één middag zes halfbakken features “shipped” en daarna verwacht dat jij blij kijkt.

Toch wint snelheid vaak de vergadering. Niet omdat managers filosofen zijn, maar omdat zichtbaar werk politiek wint. Een werkende demo om 15:00 slaat een zorgvuldig bezwaar om 15:10. De flabbergasted-collega heeft dan gelijk én pech.

Wat de achterblijver wél kan doen

Niet panikeren. Niet doen alsof je “principieel” tegen tools bent terwijl je stiekem ChatGPT op je telefoon open hebt. Leer het tempo een beetje stelen. Gebruik AI voor de saaie meters, houd je oordeel voor de bochten. En als je collega weer iets onmogelijks heeft neergezet: vraag niet alleen “hoe snel?”, vraag “wat heb je bewust niet gedaan?”

Want daar zit het vak. In wat je weglaat. In wat je checkt. In wat je nog zelf snapt.

Anders rennen we met z’n allen sneller de mist in. En dan is niemand meer flabbergasted. Alleen maar nat. Laten we voorlopig onze collega’s maar een beetje in de waan laten en genieten van het feit dat we tot dat zij up-to-speed zijn ook kunnen kiezen voor meer tijd voor onszelf.

Er was een tijd dat je aan iemands e-mail kon zien of die persoon moe was, boos, of net koffie had gedronken. Nu zie je vooral of ChatGPT aan stond. De alinea’s zijn netjes. De opsommingen zijn heilig. Er is altijd een korte inleiding, drie punten, en een afronding die “tot slot” heet alsof we een scriptie inleveren bij een strenge leraar die niet bestaat.

Dat is geen toeval. Mensen gaan dingen doen zoals een AI ze presenteert. Niet omdat ze dat filosofisch hebben besloten, maar omdat het werkt. Je baas houdt van structuur. Jouw LinkedIn-post met drie bullets krijgt likes. Je ticket in Jira ziet er plots “professioneel” uit. En zo sleept de outputvorm van het model langzaam jouw eigen denken mee.

De mens wordt machine. De machine wordt, ironisch genoeg, steeds beter in doen alsof ze mens is.

Structuur als persoonlijkheid

Kijk eens rond in je Slack. Iedereen begint zinnen met “Belangrijk om te noemen:”. Iedereen heeft “context”, “aanpak” en “next steps”. Iedereen eindigt vriendelijk, neutraal, en net iets te glad. Alsof we collectief in een corporate meditation-app zijn beland.

De grap is: dat voelt productief. En soms ís het productief. Een slordige gedachte wordt een leesbare notitie. Een half idee wordt een voorstel. Maar onderweg verdwijnt iets. De rare associatie. De twijfel. De zin die te lang is omdat je écht aan het nadenken was. Wat overblijft is vaak beter verpakt werk, met minder inhoudelijke kennis eronder.

Je levert misschien een strakkere memo op. Je snapt alleen niet meer waarom die memo klopt. Of erger: je snapt niet meer wanneer die niet klopt.

Dommer, met betere slides

Hier komt het ongemakkelijke deel. Mensen worden door intensief AI-gebruik niet automatisch slimmer. Ze worden vaak efficiënter. Dat is iets anders. Efficiënt is je navigatie die je de route uitlegt. Slim is zelf nog weten waar het noorden is als de batterij leeg is.

Als je elke analyse laat voorbereiden, elke mail laat herschrijven, elk ontwerpbesluit laat “valideren”, dan train je niet je oordeel. Je train je promptreflex. Je wordt uitstekend in vragen stellen aan een systeem dat dolgraag antwoord geeft. Minder goed in zelf antwoorden hebben.

En ja: de oplevering kan er beter uitzien. Mooiere teksten. Nettere samenvattingen. Minder typfouten. Gefeliciteerd. Je bent een betere printer geworden.

Wat je wél kunt doen

Gebruik AI. Serieus. Ik doe het ook. Maar laat het niet jouw standaardzinnen stelen. Schrijf eerst vies. Denk eerst krom. Weet eerst iets. Laat het model daarna opruimen, niet jouw hersenen vervangen door een keurige template.

Want als we allemaal klinken als dezelfde behulpzame assistent, is er straks niemand meer die nog iets écht lastigs kan uitleggen zonder eerst “hier is een gestructureerd overzicht” te zeggen.

En dat overzicht, beste collega, was vroeger gewoon een mening. Als je die tegenwoordig nog vrijlijk kunt hebben.

Het probleem: een jaar intranet, nu een agent

Ik heb vorig jaar een intranet gebouwd voor Guidance. Dat was het werk: alle informatie centraliseren, zodat iedereen — ongeacht afdeling — kon vinden wat ze nodig hadden. Wie is onze klant X? Wat staat in contract Y? Hoe werkt onboarding? Waar is dat document over die beslissing van vorig jaar?

Het werkt. Iedereen gebruikt het. En ik heb ondertussen geleerd wat het betekent om informatie werkelijk toegankelijk te maken.

Nu willen we het volgende stap zetten: in plaats van zoeken, vragen stellen. Een AI-agent die dat intranet doorzoekt en antwoord geeft. Klinkt simpel. En precies daarom ben ik voorzichtig.

Het probleem is niet dat de AI niet slim genoeg is. De meeste agent-failures komen niet van zwakke modellen, maar van ontbrekende of slechte context. Ik ben bang voor iets anders: dat ik mijn intranet nog niet goed genoeg begrijp om het aan een AI te geven.

Wat een jaar intranet me heeft geleerd

Drie dingen die me voorzichtig maken:

1. Mensen zoeken niet zoals je denkt

Toen we het intranet bouwden, hadden we een zoekfunctie gebouwd die — op papier — logisch was. Categorieën, tags, hiërarchie. Maar hoe mensen het werkelijk gebruiken? Compleet anders. Ze zoeken op trefwoorden die niet in onze structuur zitten. Ze vinden iets, en drie minuten later realiseren ze dat ze iets anders nodig hebben dat niet in de buurt staat. Ze vergeten dat een document überhaupt bestaat totdat iemand anders ernaar verwijst.

Een AI-agent die hetzelfde retrieval-probleem heeft, maar nu “intelligenter” klinkt, zal niet dóór dit probleem heen groeien. Het zal het eerder verbergen: de agent zal zelfverzekerd antwoord geven op basis van een deel van de informatie.

2. Informatie is chaotisch opgeslagen

Ik dacht dat ik het intranet kon vullen en klaar was. Maar informatie in Guidance zit overal: in Git (code, architectuur-beslissingen), in Jira (taken, bugs, discussies), in Notion (processen, templates), in Slack (beslissingen, quick-fixes, context die nooit geëxporteerd wordt), in Google Drive (contracten, analyses). Elk systeem heeft een ander formaat, andere permissies, ander update-ritme.

Om dat allemaal in het intranet te brengen, moest ik normaliseren. Wat betekent “een stuk informatie”? Wat hou ik, wat gooi ik weg? Welke context is onmisbaar, welke is ruis?

Nu wil ik hetzelfde doen voor RAG: die chaos in een vector-database gooien. En ik weet al dat het intranet niet volmaakt is. Dan is mijn AI ook niet volmaakt.

3. Context verdwijnt

Een Jira-ticket zegt: “Fix authenticatie voor API”. Prima. Maar waarom? Welke bug was het? Welke klant was getroffen? Wat was de discussie erover? Dat staat in Slack, of in een vergader-note, of nergens.

Mijn intranet kan dit partly oplossen (we linken tickets aan issues, we schrijven context op). Maar veel context is impliciet: het zit in het hoofd van mensen. Een AI die het ticket leest, ziet alleen het ticket. Dan geeft hij een antwoord dat formeel juist is, maar niet wijzer.

RAG en Memory zijn niet hetzelfde

Ik zie mensen deze door elkaar halen, dus ik zet het scherp.

RAG is: je agent krijgt een vraag, haalt relevante stukken uit je database op (in mijn geval: mijn intranet), geeft die aan het model, en het model antwoordt. Stateless. Elke vraag begint opnieuw.

Memory is: je agent onthoudt wat hij in vorige gesprekken heeft gedaan, welke patronen hij heeft gezien. Stateful. Context accumuleert.

Je agent heeft beide nodig. Zonder RAG antwoordt hij op basis van wat het basismodel “weet” — dus halfslecht. Zonder Memory begint elke vraag opnieuw.

Voor mijn intranet: RAG betekent dat de agent Jira-tickets, wiki-pagina’s, contracten ophaalt. Memory betekent dat hij onthoudt: “Deze persoon vraagt veel over onboarding — volgende keer sneller aanbieden, gerelateerde documenten voorstellen.” Het ene vervangt het andere niet.

Privacy is je voordeel, maar alleen als je het echt doet

Hier ben ik eerlijk: mijn bedrijf wil zijn informatie niet in OpenAI’s servers. Dat is logisch. Dus we bouwen intern.

Maar: als ik Claude of Open AI gebruik voor het redeneren — en dat zal waarschijnlijk nodig zijn — dan upload ik context naar hun servers. Dus: niet helemaal privé. En als ik mijn vector-database outsource naar Pinecone (gemak, schaal), dan is ook dat niet binnenboord.

Mijn privacy-voordeel werkt alleen als ik consequent ben. Wat betekent: mogelijk lokale models, mogelijk zelf hosten, mogelijk data-extractie voordat ik upload. Dat kost meer dan “we zetten Claude op”.

Dit is niet een reden om niet te beginnen. Dit is een reden om voorzichtig te zijn. Privacy-voordeel verdient voorzichtigheid.

De integratieketen: waar het échte werk begint

Mijn intranet vult zichzelf uit zes bronnen: Git, Jira, Notion, wiki, Google Drive, Slack (partial). Elk met zijn eigen sync-patroon, schema, permissies. Dit was al moeilijk.

Nu wil ik hetzelfde doen voor de AI: dezelfde bronnen, maar nu in een vector-database. Dat voegt toe:

• Latency: hoe snel is mijn data beschikbaar in de vector-database? Realtime? Nachtelijk batch?
• Synchroon: een Jira-ticket verandert; mijn vector-database weet dit wanneer?
• Failure-points: als één connector breekt, wat dan? Geeft de agent oude informatie?
• Permissies: welke informatie mag welke persoon via de agent zien? Dit moet je normalizeir voordat je indexeert.

Progress zegt: “Dit is enkele weken werk.” Dat is technisch waar. Het telt alleen niet de integratie-pijn die ik al ken.

Drie voorzorgsmaatregelen voordat ik code schrijf

1. Definieer je metriek — nu, niet later

Mijn intranet-baseline: hoelang duurt het nu om informatie te vinden? 5 minuten? 15? Wie zoekt het? Hoe vaak? Welke vragen worden herhaald?

Ik heb dit data. Nu moet ik het harden in “succes-criteria”:

• Als de AI hetzelfde antwoord geeft als het intranet, maar in 30 seconden, is dat een win.
• Als de AI 90% van de vragen correct beantwoordt (na optimalisering), is dat acceptabel.
• Als mijn team hem in 2 van de 5 werkdagen niet gebruikt, stop ik.

Zonder deze criteria weet ik niet of ik iets heb bereikt.

2. Test je retrieval voordat je je agent live zet

DoorDash en Grab gebruiken beiden: RAG + verificatie + menselijke escalatie. Dat leren me: retrieval alleen is niet genoeg. Als mijn vector-database slechte relevante stukken ophaalt, geeft mijn agent slecht antwoord. Geen model lost dat op.

Mijn voorstel: voordat ik live ga, test ik handmatig. “Hoe haalt mijn retrieval informatie op voor deze 10 vragen?” Werkt het? Wat mist er? Daarna optimaliseer ik. Daarna live.

3. Bepaal wie wat mag zien — voordat je indexeert

Mijn intranet heeft permissies: niet iedereen ziet contracten, niet iedereen ziet salarissen. Als mijn AI dat niet respecteert, geef ik vertrouwelijke informatie aan iedereen. Dat is een permissie-probleem, niet tech.

Ik moet voordat ik indexeer bepalen: welke documenten uit het intranet mogen alle werknemers zien via de AI? Welke alleen leidinggevenden? Dit moet in mijn vector-database en retrievalogen zitten.

Waar dit breekt en hoe ik het zien aankomen

Onvolledige informatie

Mijn intranet is niet compleet. Oude Slack-threads zitten er niet in. Verwijderde Google Docs ook niet. Mijn AI zal zeggen: “daar is niets over bekend” — technisch juist, voor gebruikers nutteloos.

Dit voorkomen: ik accepteer dat gaten bestaan, of ik vul ze op voorhand. Niets tussendoor.

Context-verlies door normalisatie

Een Slack-thread heeft nuance. Discussie. Context. Wanneer ik dat in twee zinnen samenvat voor het intranet, verdwijnt nuance. Mijn AI ziet alleen die twee zinnen. Dan geeft hij simplistisch antwoord.

Dit is onvermijdelijk. Ik kan het minimaliseren: links toevoegen, backreferences, duidelijk zeggen waar volle context zit. Maar volledig voorkomen? Nee.

Synchroon-lag

Een contract wordt bijgewerkt. Mijn intranet ziet dit vandaag. Mijn vector-database ziet dit morgen (als ik nachtelijke sync heb) of nooit (als ik het vergeet). Mijn AI geeft oude informatie.

Dit bepaalt mijn architecture: realtime-sync (duurder, complexer) of batch (langzamer, riskanter)? Ik moet dit kiezen en accepteren wat dat betekent.

Hallucinations met autoriteit

Dit is mijn grootste angst: een agent die fout antwoord geeft, maar het zo zelfverzekerd zegt dat mensen het geloven. Mijn intranet zegt “dit weet ik niet”. Mijn AI zegt “dit is zo” — maar het is fout.

Dit voorkomen: guardrails. Verificatie. Confidence-scores. En training voor mijn team: “dit is een assistent, niet een bron van waarheid.”

Hoe ik begin

Week 1-2: Ik indexeer één datasource — laten we zeggen mijn wiki-pagina’s en Jira-tickets. Test: “Hoe haalt mijn vector-database informatie op voor deze 10 vragen?” Wat werkt? Wat mist er?

Week 3-4: Ik test een eerste agent. Vragen stellen. Zien wat fout gaat. Noteer false negatives (vragen die geen antwoord geven maar hadden moeten) en hallucinations (foutieve antwoorden).

Week 5-6: Ik fix wat ik heb geleerd. Chunking aanpassen? Vector-model wisselen? Context toevoegen? Dit bepaalt of week 7 live gaat.

Week 7+: Pas voeg ik de volgende datasource toe. Niet alles tegelijk. Stap voor stap, telkens meetend.

Dit is niet langzaam. Dit is voorzichtig. Groot verschil.

De exit-strategie

Voordat ik begin: wanneer stop ik?

Ik zeg hardop:

• Als mijn team na vier weken ziet “dit gebruiken we niet, we zoeken nog steeds zelf”, stop ik.
• Als onderhoud meer kost dan besparing (engineering-uren groter dan intranet-zoekvragen bespaard), stop ik.
• Als hallucinations boven 15% liggen nadat ik heb geoptimaliseerd, stop ik.
• Als mijn vector-database constant out-of-sync is, stop ik.

Dit zeggen maakt stoppen niet voelen als falen. Het voelt als voorzichtigheid.

Waarom dit nu logisch is

Ik heb een jaar aan informatie-architectuur gedaan. Ik weet hoe mensen echt zoeken. Ik weet waar data zit, wat chaotisch is, wat werkt. Dat is een sterke basis.

Een AI-agent die mijn intranet kan querien, kan sneller antwoord geven dan mensen handmatig zoeken. Dat loont zich. Maar alleen als ik voorzichtig ben. Alleen als ik test. Alleen als ik stop wanneer het niet werkt.

Dit artikel is voor mezelf geschreven. Ik wil het over zes maanden terugread en denken: ja, dit hebben we goed zien aankomen.

Bronnen

• Building a Company Knowledge Assistant with Agentic RAG — Progress
• 10 RAG examples and use cases from real companies — Evidentlyai
• AI Agents – Lesson 6: Memory, Context, and RAG — Claudia Plus AI
• RAG vs Memory for AI Agents: What’s the Difference — Memori
• Agentic RAG explained: Smarter retrieval with AI agents — Glean

Aan een dood paard blijven trekken

Een tijdje gelden kreeg ik de opdracht voor een website die ging over jelzef intern veranderen. Het soort project dat nu veel aandacht trekt — motivationeel, vol verhalen, ontworpen om iemand aan te zetten tot verandering.

Het probleem was dubbel. Ten eerste: na de dood van mijn favoriete designer, een goede vriend, probeerde ik steeds meer zijn rol in te vullen. Grafisch ontwerp, spacing, typografie — ik dacht: genoeg tijd en geduld, ik leer het wel. Maar dat was zelfbedrog. Wat ik kan, is schone code schrijven. Interfaces bouwen die mensen tijd besparen. Design — de visuele logica waarvan iemand anders *wel* kan voelen hoe het werkt — dat zit niet in mij.

Ten tweede: ik geloofde niet in het onderwerp. Heroïsche transformatie, de mens die zichzelf hercreëert — dat voelt vals op me. Ik ben meer thuis bij Marcus Aurelius dan bij Tony Robbins. Dus ik bouwde iets wat ik niet kon bouwen, voor een filosofie waar ik niet achter stond.

Weken lang sloeg ik tegen dat dode paard. Trials. Aanpassingen. Telkens opnieuw. Ik wist dat het niet werkte. Ik voelde dat het lelijk was. En ik bleef bijten.

Tot ik stopte.

De rol die niet van mij was

Epictetus zegt iets dat veel scherper is dan de gebruikelijke ‘groei uit falen’-praatjes: vervul de rol die jou is toebedeeld zo goed mogelijk. Als je probeert een rol te spelen die niet de jouwe is, sla je de plank mis. En erger — je laat de rol die wél van jou is, ongespeeld.

Dat was mijn verlies. Niet dat ik slecht in design was. Maar dat ik jarenlang een rol probeerde in te vullen die niet mijn rol was, terwijl mijn echte werk — samenwerken met goede mensen, interfaces bouwen die schoon werken, code schrijven die durft — ergens anders wachtte.

Ik probeerde mezelf te verbreden. Eigenlijk verduisterde ik gewoon wat ik goed kon doen.

Waarom falen je hersenloze wekt

Er is onderzoek dat zegt: falen werkt beter voor je brein dan voortdurend op dezelfde weg struikelen. Falen schokt je wakker. Het violates je verwachting.

Ik verwachtte dat als ik maar lang genoeg zou werken, dit zou lukken. Dat ik het kon leren. De schok — toen ik inzag dat dit eenvoudigweg niet zou gebeuren — leerde me meer dan maanden van zuchtend doorgaan ooit zouden doen.

Maar alleen als ik ernaar keek. Als ik had gezegd ‘volgende keer harder’ en opnieuw begonnen, zou ik nog steeds bijten.

Weten wat je niet bent is nuttiger dan harder werken

De populaire les is: fail forward. Leer ervan. Groei. LinkedIn houdt van dat verhaal.

Wat ik leerde was stiller: dit is niet mijn ding. Het zal niet mijn ding worden. En ik hoef het ook niet te doen.

Zodra ik dat accepteerde — zonder zelfmedelijden, gewoon als feit — kon ik iets veel nuttiger doen: naar iemand zoeken die wél designer is. Iemand die goed is in wat ik niet kan. En samen beter werk maken dan ik ooit alleen zou kunnen.

De ironie is scherp: ik bouwde een website *over persoonlijke verandering*, en de echte verandering was niet dat ik mezelf verbeterde. Het was dat ik accepteerde wat ik niet kan, en de juiste persoon erbij haalde.

Dat is geen groei. Het is efficiëntie. En dat is veel nuttiger.