AI-governance kan geen bijzaak zijn

Abhishek Ranjan is de CTO van Apna en Blue Machines, waar hij nauw betrokken is bij de transformatie van zowel het menselijke personeelsbestand als het AI-personeelsbestand.

We spraken met hem over beheer in AI-workflows. Dit is wat hij zei.

Technologie naast mensen

Ik ben Abhishek Ranjan. Ik ben de CTO van Apna en Blue Machines. Twee zeer verbonden maar toch verschillende werelden hebben mijn reis naar dit moment van AI-transformatie gevormd.

Bij Apna bouwen we voor het menselijke personeelsbestand. Apna is een van India's snelst groeiende eenhoorns, met meer dan 60 miljoen gebruikers op het platform. Op die schaal zien we het personeelsbestand van India van zeer dichtbij. We zien miljoenen mensen die op zoek zijn naar betere kansen, werkgevers die sneller proberen mensen aan te nemen, verschillende talen, verschillende vaardigheidsniveaus en uiteenlopende niveaus van digitale toegang en zelfvertrouwen.

Bij Blue Machines bouwen we voor het AI-personeelsbestand. We richten ons op enterprise-spraak-AI en verwerken dagelijks miljoenen minuten. We bouwen meer dan alleen bots die vragen beantwoorden. We bouwen AI-medewerkers die met klanten kunnen praten, context kunnen begrijpen, feedback kunnen verwerken, na verloop van tijd kunnen verbeteren en echte bedrijfsworkflows kunnen uitvoeren.

Ik heb gezien hoe technologie mensen helpt werk te vinden, te groeien en deel te nemen aan de economie. En nu zie ik AI zelf een nieuw soort personeelsbestand worden dat naast mensen kan werken.

Voor mij gaat dit moment dus niet alleen over AI gebruiken voor productiviteit of sneller code schrijven. Het gaat erom opnieuw vorm te geven aan de manier waarop bedrijven werken en waarop het werk zelf wordt uitgevoerd.

De architectuur van twee zeer verschillende bedrijven

De architectuur van Apna is opgebouwd als een groot marktplaatsplatform. We hebben consumentensystemen, werkgeverssystemen, dataplatforms, AI- en matchingsystemen, zoekfuncties, communicatie, lagen voor fraudepreventie en vertrouwen, en daarbovenop nu mogelijkheden voor AI-werving en AI-voorbereiding op sollicitatiegesprekken. Het implementatiemodel is cloud-first, zeer schaalbaar en ontworpen voor hoge beschikbaarheid, omdat miljoenen gebruikers en duizenden bedrijven het platform gebruiken.

De engineeringorganisatie telt meer dan 100 mensen, die werken aan productengineering, backend, frontend, mobiel, data, AI, infrastructuur, beveiliging en platformteams. We richten ons niet alleen op het bouwen van functies, maar ook op het bouwen van betrouwbare systemen die op enorme schaal kunnen functioneren.

Blue Machines is een ander soort technologieorganisatie. Het bedrijf richt zich op enterprise-spraak-AI en agentische workflows. We bouwen AI-medewerkers die kunnen praten, redeneren, acties kunnen ondernemen, kunnen integreren met bedrijfssystemen en door feedback kunnen verbeteren. Vandaag opereren we al op serieuze schaal, met dagelijks miljoenen geregistreerde minuten aan spraak-AI.

De architectuur van Blue Machines is meer realtime en AI-native. Deze omvat spraakinfrastructuur, telefonie, spraak-naar-tekst, redeneren met LLM's, tekst-naar-spraak, workfloworkestratie, integraties, analyses, observeerbaarheid en evaluatiesystemen. De productcomplexiteit is hoog, omdat enterprise-spraak-AI in productie moet werken, in echte gesprekken, met lage latentie, hoge nauwkeurigheid, waarborgen voor naleving en duidelijke bedrijfsresultaten.

Bij Blue Machines bouwde een kernteam van vier engineers in enkele weken een gedistribueerd platform voor spraakorkestratie. We hebben ook een zeer ervaren onderzoeksteam dat diepgaand werkt aan spraak-AI, de evaluatie van agents, redeneren, latentie, meertalige systemen en het in de loop der tijd verbeteren van agents. Die onderzoeksdiepgang is belangrijk, omdat enterprise-spraak-AI niet alleen kan worden opgelost door modellen aan elkaar te koppelen. Daarvoor zijn sterke productengineering, sterke systeemengineering en sterk toegepast AI-onderzoek nodig.

Over het geheel genomen bevindt de technologieorganisatie waaraan ik leidinggeef zich op het snijvlak van grootschalige platforms en AI-native systemen.

Hoe goed beheerde AI de softwarelevenscyclus verbetert

In het afgelopen jaar heeft AI de manier veranderd waarop we technologie bouwen, testen en uitbrengen.

Voorheen was ons releaseproces traditioneler. Engineers bouwden functies, maakten PR's aan, doorliepen peerreviews, voerden testcases uit en brachten ze vervolgens via de gebruikelijke implementatiepipeline uit. Het werkte, maar de snelheid hing af van menselijke reviewcycli, handmatige kwaliteitsborging en het vertrouwen van het team in de release.

Naarmate AI-ondersteund programmeren een groter onderdeel van engineering werd, namen we het in gebruik — en al snel realiseerden we ons dat alleen snelheidsverbeteringen niet voldoende waren. AI kan engineers helpen sneller code te schrijven, maar als governance niet verbetert, kan het ook leiden tot meer verborgen bugs, gemiste randgevallen of slechte abstracties.

Daarom veranderden we het operationele model.

1. We voegden een AI-ondersteunde PR-reviewlaag toe. Elke PR werd gecontroleerd op risicovolle logica, ontbrekende randgevallen, breuken in API-contracten, beveiligingsproblemen, migratierisico's en onvoldoende testdekking voordat menselijke review plaatsvond. Hierdoor werden duidelijke fouten al vóór de review verminderd.
2. We versterkten de CI-gates. Een wijziging kon niet uitsluitend doorgaan omdat de code er goed uitzag. De wijziging moest unit-tests, integratests, linting, beveiligingscontroles, API-contracttests en regressiesuites voor het betreffende productgebied doorstaan.
3. We bouwden sterkere regressiepakketten voor kritieke workflows. Zo voegden we bijvoorbeeld testcases toe voor realistische gebruikersscenario's, randgevallen, meertalige werking, foutafhandeling en bedrijfsresultaten.
4. We veranderden het promptbeheer. Daarover zo meteen meer.
5. We maakten canary-releases verplicht voor gebieden met een hoog risico. In plaats van naar iedereen uit te rollen, brengen we een release uit naar een klein percentage van het verkeer, houden we fouten, latentie, conversie, uitval, agentkwaliteit en klantimpact in de gaten, en schalen we daarna op of draaien we de release terug.
6. We voegden betere observeerbaarheid toe. Wanneer er iets misging, wilden we precies weten welke codeversie, promptversie, welk model, welke workflow of welke afhankelijkheid de oorzaak was.

De impact is zeer duidelijk zichtbaar. Onze releasesnelheid is aanzienlijk toegenomen. Teams die eerder grotere, gebundelde releases uitbrachten, werken nu met kleinere en frequentere releases. In sommige gebieden nam de releasefrequentie bijna 2x tot 3x toe, omdat controles verder zijn geautomatiseerd en het vertrouwen groter is. En zo bouwde een team van vier in enkele weken een complex gedistribueerd platform.

Ook het aantal problemen in productie nam af, omdat elke release kleiner, beter getest en gemakkelijker terug te draaien is. We zien een duidelijke daling van bugs in productie, vooral op plekken waar geautomatiseerde regressietests en canary-releases nu verplicht zijn. Vandaag liggen defecten bijna 40% onder de oorspronkelijke baseline.

AI alleen levert snelheid. AI met governance levert snelheid en kwaliteit.

Waarom prompts als code moeten worden behandeld

Abhishek deelt

Voor AI-systemen zijn we prompts ook als code gaan behandelen… Dit is een belangrijke verbetering geweest. We weten welke prompt actief was, wat er is veranderd, wat er is verbeterd en of de resultaten voor klanten beter zijn geworden.

Voor AI-systemen zijn we prompts ook als code gaan behandelen.

We beheren nu versies, voeren reviews en tests uit, promoten prompts tussen omgevingen en rollen ze gefaseerd uit. Prompts worden niet langer behandeld als kleine configuratiewijzigingen. Ze worden onderworpen aan testgesprekken, controles van randgevallen, meertalige controles, latentiecontroles, compliancecontroles en controles van bedrijfsresultaten.

We kunnen een nieuwe prompt of agentworkflow eerst naar een klein percentage van het verkeer uitrollen, de resultaten observeren en deze vervolgens promoten als de statistieken er beter uitzien.

Dit is een belangrijke verbetering geweest. Voorheen was het moeilijk om te weten of een promptwijziging de agent verbeterde of alleen het gedrag ervan veranderde. Nu kunnen we versies objectiever vergelijken. We weten welke prompt actief was, wat er is veranderd, wat er is verbeterd en of de resultaten voor klanten beter zijn geworden.

De grotere verandering is dat het volledige technologiesysteem verder geautomatiseerd, beter meetbaar en beter beheerst werd.

Een agentische engineering-releaseworkflow

We gebruiken een agentische engineering-releaseworkflow, waarbij mensen op belangrijke momenten betrokken zijn.

Deze workflow werkt niet voor elke release. Voor zeer complexe platformwijzigingen, ingrijpende architectuurwijzigingen of gevoelige systemen gebruiken we nog steeds een traditioneler proces dat door mensen wordt geleid. Maar voor sommige productgebieden, vooral workflows die sneller veranderen, is dit de standaardmanier van bouwen geworden.

Dit is de workflow:

1. Het proces begint wanneer er een productvereiste of technisch probleem binnenkomt. Een AI-planningsagent leest de vereiste, splitst deze op in taken, identificeert afhankelijkheden, markeert risicovolle gebieden en stelt een implementatieplan voor. De engineer beoordeelt het plan, corrigeert aannames en bepaalt de uiteindelijke aanpak.
2. Vervolgens genereert een codeeragent code, herstructureert modules, schrijft standaardcode en maakt unit- en integratietests. Een beoordelingsagent controleert de pullrequest op risicovolle logica, ontbrekende randgevallen, beveiligingsproblemen, breuken in API-contracten en ontbrekende tests.
3. Daarna maakt een testagent regressiescenario's en valideert deze randgevallen. Voor AI-workflows voert deze agent ook prompt-evaluaties, gesprekstests, meertaligheidscontroles, latentietests en controles van bedrijfsresultaten uit.
4. De releaseagent adviseert vervolgens of de wijziging veilig kan worden ingezet als canaryrelease, op basis van testresultaten, het impactgebied, eerdere fouten en de gereedheid voor observeerbaarheid. Mensen keuren kritieke promoties echter nog steeds goed, vooral wanneer de wijziging invloed heeft op omzet, klantervaring, beveiliging of kerninfrastructuur.
5. Na de release houdt de monitoringagent fouten, latentie, conversie, uitval, agentkwaliteit en klantimpact in de gaten. Als er iets mis lijkt te zijn, adviseert de agent een rollback, opent deze een incident, vat hij logboeken samen en maakt hij een eerste concept van de RCA.

Deze workflow is agentisch, maar niet blind autonoom. AI-agenten plannen, coderen, beoordelen, testen, releasen, monitoren en vatten samen. Mensen keuren goed, stellen kritische vragen, stellen prioriteiten en nemen de uiteindelijke beslissing.

Waar Claude Code en Cursor in uitblinken

Mijn favoriete tools zijn Claude Code en Cursor, afhankelijk van de workflow.

Cursor blinkt uit wanneer ontwikkelaars AI diep geïntegreerd willen hebben in hun IDE voor dagelijkse ontwikkeling, refactoring, het begrijpen van de codebasis en een snellere implementatie.

Claude Code blijkt bijzonder nuttig voor meer agentische taken: het begrijpen van grotere codebases, het doorvoeren van wijzigingen in meerdere bestanden, het genereren van tests, het oplossen van problemen en het itereren als een technische partner.

Waarom AI hefboomwerking biedt en mensen het oordeel vellen

We vertrouwen nu zwaar op AI voor alles wat snelheid, dekking of consistentie verbetert, maar niet voor taken die oordeel, verantwoordelijkheid of afwegingen op lange termijn vereisen.

AI helpt ons bijvoorbeeld inmiddels bij codebeoordelingen, het genereren van testgevallen, regressiedekking, documentatie, foutopsporing, loganalyse en zelfs incidenttriage. Het kan snel risicovolle codepaden, ontbrekende randgevallen, mogelijke beveiligingsproblemen of patronen in productiefouten identificeren. In AI-systemen helpt het ons ook promptversies te vergelijken, gesprekken te evalueren en te begrijpen waar een agent fouten maakt.

Maar de uiteindelijke beslissingen blijven bij mensen. Hier zijn enkele voorbeelden:

• Architectuurkeuzes moeten bij mensen blijven, omdat deze afwegingen rond schaal, kosten, betrouwbaarheid, teamcapaciteit en de langetermijnrichting van het product met zich meebrengen.
• Een end-to-end RCA kan door AI worden ondersteund, maar mensen moeten nog steeds de verbanden leggen, de hypothese valideren en de oplossing bepalen.
• Het prioriteren van de backlog blijft mensenwerk, omdat hiervoor klantcontext, bedrijfsstrategie en inzicht in wat er echt toe doet nodig zijn.
• Bij beveiligingsbeoordelingen wordt AI gebruikt, maar deskundig oordeel blijft noodzakelijk. AI kan problemen signaleren, maar ook fout-positieven veroorzaken of risico's missen die samenhangen met de bedrijfscontext. Mensen behouden de verantwoordelijkheid, omdat de risico's en aansprakelijkheid te groot zijn.

Praktijkvoorbeelden van fouten van AI bij technisch oordeel

Hier zijn enkele voorbeelden van het belang van menselijk oordeel.

Het eerste betrof latentiespieken op millisecondenniveau in onze spraakpipeline. AI gaf terecht commentaar op het probleem en stelde vast dat latentie in één pad een probleem kon worden. Maar de code die het voorstelde was onjuist. De code zag er netjes uit, maar zou onder belasting een andere bottleneck hebben veroorzaakt. Een menselijke engineer greep in, begreep het runtimegedrag en loste het probleem goed op.

Een ander voorbeeld deed zich voor tijdens het oplossen van een productieprobleem. Meerdere downstreamsystemen vielen uit en AI bleef die systemen afzonderlijk analyseren en optimalisaties voorstellen. Maar wij wisten al dat het echte probleem een upstreamafhankelijkheid was die als eerste was uitgevallen. AI verwarde zichtbare storingen met de hoofdoorzaak.

Hier heeft AI nog steeds moeite mee. Het kan logbestanden lezen, traces samenvatten, oplossingen voorstellen en het debuggen versnellen. Maar in complexe gedistribueerde systemen kan het causaliteit, timing en context op systeemniveau over het hoofd zien.

Waarom teams kleiner worden en tegelijkertijd breder inzetbaar zijn

AI heeft het gewenste aanwervingsprofiel sterker veranderd dan het organigram.

Voorheen wierven we mensen aan voor een beperktere functionele diepgang: backend, frontend, QA, DevOps, data enzovoort. Die vaardigheden zijn nog steeds belangrijk, maar nu waardeer ik engineers die over de hele stack kunnen werken, AI diepgaand kunnen inzetten en van probleem naar productie kunnen gaan met veel minder begeleiding.

De beste engineers schrijven nu niet alleen code. Ze ontwerpen werkstromen, gebruiken AI voor de implementatie, genereren tests, beoordelen uitvoer, debuggen sneller en denken na over de kwaliteit van software-uitgaven.

Daarom verschoof de lat voor aanwerving naar engineers met veel eigenaarschap en beoordelingsvermogen. Mensen die de juiste vragen kunnen stellen, AI-uitvoer kunnen verifiëren, systemen diepgaand begrijpen en zelfstandig kunnen opleveren.

In sommige gebieden heeft dit ook de behoefte aan grote teams verminderd. Een kleiner team dat AI effectief inzet, kan nu werk doen waarvoor voorheen veel meer mensen nodig waren.

Waarom AI het moeilijker maakt om beginnende engineers op te leiden

Abhishek deelt

Ik denk niet dat AI verbieden of mensen dwingen te programmeren alsof het 2010 is, het antwoord vormt. Dat zou verkeerd zijn. Maar ik denk ook niet dat we volledig hebben opgelost hoe we diepgaand technisch beoordelingsvermogen ontwikkelen wanneer AI zo veel voorbereidend werk doet. Voorlopig is mijn beste antwoord om begrip zichtbaar te maken.

Hoe leiden we beginnende engineers op in het AI-tijdperk? Ik heb daar nog geen perfect antwoord op.

Toen wij begonnen, hielpen IDE's ons. Daarna hielp Google ons. Vervolgens hielp Stack Overflow ons. Maar in al die fasen moest je nog steeds zelf door het probleem heen worstelen. Je moest het antwoord begrijpen, het aanpassen, fouten opsporen en leren waarom het werkte.

Met AI en vibeprogrammeren kunnen we die worsteling overslaan. Een beginnende engineer kan werkende code genereren zonder het systeem, de afwegingen of de faalwijzen echt te begrijpen. Dat baart me zorgen.

Ik denk niet dat AI verbieden of mensen dwingen te programmeren alsof het 2010 is, het antwoord vormt. Dat zou verkeerd zijn. Maar ik denk ook niet dat we volledig hebben opgelost hoe we diepgaand technisch beoordelingsvermogen ontwikkelen wanneer AI zo veel voorbereidend werk doet.

Voorlopig is mijn beste antwoord om begrip zichtbaar te maken. Engineers moeten kunnen uitleggen waarom de code werkt, waar die kan falen, welke tests belangrijk zijn, wat er op schaal gebeurt en hoe ze die in productie zouden debuggen.

Hoe je tokengebruik beheert

Kosten vormen ook een uitdaging bij AI.

Tokengebruik lijkt in het begin onschuldig, maar zodra AI wordt ingezet voor programmeren, beoordelingen, testen, debuggen en agentgestuurde werkstromen, kunnen de kosten zeer snel oplopen.

Daarom moeten we het rendement nu per werkstroom meten en slimmere orkestratie gebruiken. Niet elke taak heeft het duurste model nodig.

De toekomst draait om het juiste model voor de juiste taak.

Waarom CTO's snel moeten handelen — met controlemaatregelen

Dit is mijn advies: bouw snel. Experimenteer snel. Zet AI in voor echte werkstromen op het gebied van engineering, productontwikkeling, ondersteuning, verkoop, bedrijfsvoering en interne processen. Doe niet alsof het niet werkt. Het werkt wel, soms verrassend goed.

Maar word geen blinde gelovige. AI is krachtig, maar het is geen magie. Je hebt controle, besturing, tests, observeerbaarheid en duidelijk eigenaarschap nodig. Anders creëer je alleen maar sneller chaos.

De juiste mentaliteit is noch “AI zal alles vervangen”, noch “AI wordt overschat”. De juiste mentaliteit is: “hoe gebruik ik dit om mijn organisatie tien keer capabeler te maken?”

Volg ons

Volg Abhishek Ranjan op LinkedIn. En bekijk zijn Hacktivate-nieuwsbrief.

Er volgen meer interviews met experts op The CTO Club!