De AI-agent wordt geen chatbot, maar een werkpleklaag
Het echte patroon: AI krijgt handen aan het werk
De belangrijkste verschuiving in AI-producten zit niet alleen in betere antwoorden. De opvallende beweging is dat AI steeds vaker een laag wordt die iets kan doen met werkobjecten: bestanden, code, schermen, diagrammen, takenlijsten en reviews. Dat verandert de adoptievraag voor AI-teams. Een chatbot die een concepttekst schrijft is iets anders dan een agent die door een computeromgeving navigeert, een pull request beoordeelt of op basis van een trigger automatisch een ontwikkeltaak start.
Daarom is het te smal om elke aankondiging te behandelen als modelnieuws. Voor productleads, engineering managers en operators gaat het om workflow-nieuws. De vraag wordt: waar mag AI kijken, waar mag AI klikken, waar mag AI schrijven en waar moet een mens eerst goedkeuren? Pas als die vragen concreet beantwoord zijn, kun je bepalen of een agent echt in de operatie thuishoort.
Een gezonde aanpak begint met onderscheid maken tussen advies, voorbereiding en uitvoering. Advies is relatief laag risico: de agent vat samen, markeert risico's of stelt opties voor. Voorbereiding gaat verder: de agent maakt een review, diagram of voorstel dat iemand kan controleren. Uitvoering is het zwaarst: de agent past code, bestanden of instellingen aan. Hoe dichter je bij uitvoering komt, hoe belangrijker permissies, logging, kostenplafonds en rollback worden.
Van chat naar computergebruik: lokaal is geen vrijbrief
Een lokaal gepositioneerde computer-agent klinkt aantrekkelijk, zeker wanneer privacy en controle belangrijk zijn. Toch is lokaal draaien niet automatisch hetzelfde als veilig werken. Het kan een relevante keuze zijn, maar alleen binnen een duidelijk ontwerp: welke data blijft lokaal, welke externe diensten worden alsnog geraakt, welke acties zijn toegestaan en hoe wordt misbruik of fout gedrag beperkt?
Voor AI-teams is dit een praktische ontwerpvraag. Laat een agent bijvoorbeeld alleen lezen en voorstellen doen, of mag hij ook vensters bedienen, bestanden aanpassen en workflows starten? Mag de agent overal bij, of alleen in een afgeschermde projectmap? Is er een auditlog van acties? Kun je een fout snel terugdraaien? Zonder die antwoorden wordt ‘computergebruik’ een te brede belofte.
Pascal Bouman zou dit niet framen als: kies wel of niet voor lokale agents. De betere vraag is: welke taak heeft baat bij nabijheid tot de werkplek, en welke grens wil je afdwingen? Een agent die lokale spreadsheetstructuren inspecteert en verbeteringen voorstelt, vraagt een ander risicoprofiel dan een agent die zelfstandig bestanden verplaatst, scripts draait of in meerdere applicaties tegelijk werkt.
Code-agents worden operationeel: review, triggers en afrekening
Bij code-omgevingen zie je dezelfde beweging. AI-codehulp verschuift van losse suggesties naar afgebakende workflows zoals pull request review, geautomatiseerde controles en trigger-based taken. Dat maakt de technologie bruikbaarder, maar ook serieuzer. Zodra een agent onderdeel wordt van een ontwikkelproces, moet hij passen binnen bestaande afspraken over kwaliteit, security, eigenaarschap en releasebeheer.
Een prijs- of reviewmodel rond pull requests is vooral interessant als signaal: AI-codewerk wordt verpakt als herhaalbare workflow in plaats van incidentele prompt. Dat dwingt teams om kosten per review, reviewdiepte en escalatiecriteria expliciet te maken. Niet elke pull request verdient dezelfde analyse. Een kleine tekstwijziging, een dependency-upgrade en een wijziging in autorisatielogica horen niet in één bak.
Trigger-based automatisering vraagt nog scherpere grenzen. Een always-on agent die reageert op gebeurtenissen kan handig zijn voor repetitieve taken, maar mag niet stilletjes beslissingen nemen die normaal door een senior engineer worden gedragen. Zet daarom per trigger vast wat de agent mag doen: alleen labelen, een conceptissue maken, een testadvies geven, een branch voorbereiden of daadwerkelijk wijzigingen openen. Hoe autonomer de stap, hoe zwaarder de controle.
Interactieve output verandert hoe je AI-tools evalueert
AI-output wordt steeds vaker een werkobject in plaats van platte tekst. Interactieve visuals, grafieken en diagrammen kunnen veel waarde hebben, omdat ze abstracte informatie sneller bespreekbaar maken. Maar ze vragen ook een andere vorm van beoordeling. Een tekst kun je lezen en corrigeren. Een interactief diagram moet je kunnen begrijpen, herleiden, aanpassen en herstellen.
Voor adoptie betekent dit dat antwoordkwaliteit slechts één criterium is. Teams moeten ook kijken naar bruikbaarheid: helpt het object echt in de taak? Traceerbaarheid: kun je zien waar de onderdelen vandaan komen of welke aannames zijn gebruikt? Herstelbaarheid: kun je fouten eenvoudig corrigeren zonder het hele object opnieuw op te bouwen? En overdraagbaarheid: kan een collega ermee verder zonder dezelfde promptgeschiedenis te kennen?
Dit is vooral belangrijk in product-, data- en engineeringteams waar diagrammen en grafieken beslissingen beïnvloeden. Een mooie visual is niet automatisch een betrouwbare analyse. Maak daarom onderscheid tussen verkennende output, die bedoeld is om ideeën te ordenen, en besluitvormende output, die een formele review nodig heeft.
Een besliskader voor AI-teams
Gebruik bij elke nieuwe agentfunctie een simpele matrix met vijf velden: taaktype, risico, benodigde permissies, kostenmodel en menselijke controle. Taaktype beschrijft wat de agent precies doet. Risico beschrijft wat er misgaat als de agent fout zit. Permissies leggen vast welke systemen, bestanden of acties toegankelijk zijn. Kostenmodel maakt zichtbaar of de workflow per actie, review, run of gebruiksmoment oploopt. Menselijke controle bepaalt waar de stopknop zit.
Begin bij voorkeur met reversibele taken. Denk aan concept-review, beperkte code-analyse, diagramverkenning, documentstructuur, testideeën of issue-classificatie. Daar kan AI waarde toevoegen zonder direct productieprocessen over te nemen. Vermijd in de eerste fase brede computer-control waarbij de agent meerdere applicaties bedient zonder duidelijke taakgrenzen.
De praktische conclusie: behandel agents als nieuwe collega’s met beperkte bevoegdheden, niet als magische automatisering. Je geeft een junior medewerker ook niet op dag één toegang tot elke omgeving met toestemming om zelfstandig te deployen. Dezelfde nuchtere lijn werkt voor AI-agents: klein starten, scherp loggen, kosten bewaken en autonomie pas uitbreiden wanneer de taak voorspelbaar genoeg is.
