Global Head of AI-architectuur zegt dat AI een verandering van het operationele model is, geen uitrol van tools

Manish Jain is VP en wereldwijd hoofd AI-architectuur bij Firstsource, waar hij leiding geeft aan een team van 50 mensen. Zijn focus ligt momenteel op het bouwen van agentische systemen die werk in meerdere stappen kunnen uitvoeren.

We spraken met Manish om te ontdekken hoe AI zijn operationele model verandert. Dit is wat hij zei.

Van potentieel naar productierijpe capaciteiten

Ik ben Manish Jain, een leider op het gebied van AI en technologie die zich richt op het helpen van organisaties om AI-potentieel om te zetten in betrouwbare, productierijpe capaciteiten. Ik baseer mijn werk op de praktische realiteit van transformatie. De afgelopen jaren heb ik leiding gegeven aan veel AI- en ML-initiatieven, nauw samengewerkt met bedrijfsteams en gewerkt aan technische ontwikkeling en implementaties waarbij succes van veel meer afhangt dan alleen het selecteren van het juiste model. Architectuur, datakwaliteit, beveiliging, integratie, gebruikersacceptatie en duidelijke bedrijfswaarde moeten allemaal samenkomen.

Momenteel leid ik AI-initiatieven binnen een multifunctionele organisatie van ongeveer 50 mensen, waaronder software- en platformtechnici, AI- en dataspecialisten, productleiders, beveiligingspartners en experts uit bedrijfsdomeinen. Het werk omvat de implementatie van AI binnen ondernemingen en vooruitgeschoven dienstverlening. Teams werken nauw samen met klanten en interne belanghebbenden om waardevolle toepassingen van verkenning tot veilige, schaalbare implementatie in productie te brengen.

Onze aanpak is bewust cloudonafhankelijk en modelonafhankelijk. We implementeren voornamelijk in Azure en AWS en gebruiken Google Cloud selectief, afhankelijk van de klantomgeving, het datalandschap en de operationele behoeften. In plaats van architecturen te ontwerpen rond één cloudprovider of basismodel, bouwen we modulaire architecturen waarmee we de onderliggende componenten kunnen kiezen en ontwikkelen naarmate de vereisten veranderen. Dit omvat de modellengelaagdheid, diensten voor gegevens ophalen en verwerken, het orkestratiekader, evaluatietools, observeerbaarheid en beveiligingsmaatregelen.

De echte complexiteit zit niet simpelweg in het selecteren van een LLM. Het gaat erom AI te integreren in bedrijfswerkstromen over gefragmenteerde gegevensbronnen, verouderde applicaties, uiteenlopende gebruikersrechten en strikte vereisten op het gebied van beveiliging, betrouwbaarheid, kosten en naleving. We beginnen doorgaans met een gerichte toepassing en een grondige evaluatie en brengen vervolgens wat werkt naar productie door middel van vangrails, waar passend menselijk toezicht, monitoring en voortdurende iteratie. Het doel is AI-capaciteiten te creëren die zich blijven aanpassen naarmate de technologie verandert en die betrouwbaar genoeg zijn om er dagelijks op te kunnen vertrouwen.

Ik ben bijzonder geïnteresseerd in de verschuiving van individuele copiloten naar agentische systemen die werk in meerdere stappen kunnen uitvoeren binnen vastgestelde grenzen. Voor technologieleiders is de kans aanzienlijk, maar om die te benutten zijn gedisciplineerde technische ontwikkeling, doordacht bestuur en een sterke focus op resultaten nodig.

Waarom AI-implementatie met evaluatie als uitgangspunt betere resultaten oplevert

Het afgelopen jaar ben ik AI-implementatie gaan verschuiven van een mentaliteit waarin proefconcepten vooropstaan naar een technische discipline waarin evaluatie centraal staat. Een jaar geleden bouwden teams vaak snel indrukwekkende proefconcepten door werkstromen met afzonderlijke modellen te verbinden. Maar de factoren die de betrouwbaarheid van AI in productie bepalen — kwaliteit, onderbouwing, toegangscontrole, foutafhandeling, kosten en verantwoordelijkheid van gebruikers — werden vaak te laat aangepakt.

We introduceerden een gedeeld implementatiepatroon waarin elke AI-toepassing begint met een duidelijke definitie van succes, representatieve evaluatiegegevens, een beoordeling van beveiliging en gegevenstoegang, traceerbaarheid en voortdurend toezicht. We bouwden ook de onderliggende architectuur cloud- en modelonafhankelijk. Hierdoor kunnen teams voor elke werkstroom de juiste combinatie van modellen, methoden voor het ophalen van informatie en orkestratiepatronen evalueren, zonder het product vast te leggen aan één provider of modelgeneratie.

In de praktijk leidde dit tot minder herstelwerk en meer vertrouwen in implementaties in productie. Teams kunnen kwaliteits- of kostenverslechteringen identificeren voordat deze gevolgen hebben voor gebruikers, expliciete beslissingen nemen over waar menselijke beoordeling nodig is en systemen verbeteren op basis van bewijs in plaats van anekdotische feedback.

Vooruitkijkend geloof ik dat dit de basis vormt voor verantwoorde agentische AI. Nu systemen verder gaan dan het beantwoorden van vragen en meerstapsacties beginnen uit te voeren binnen werkstromen van ondernemingen, kunnen we evaluatie, observeerbaarheid, machtigingen en bestuur niet achteraf toevoegen. Ze moeten vanaf dag één onderdeel zijn van de technische basis.

Hoe mensen belangrijker worden door agentische technische ontwikkeling

We gebruiken AI gedurende de hele productlevenscyclus. Tijdens de verkenning zet AI input van belanghebbenden, feedback van klanten en bestaande documentatie om in eerste vereisten, gebruikersverhalen, acceptatiecriteria en technische vragen. Binnen de technische ontwikkeling ondersteunt AI het verkennen van codebases, documentatie, implementatie, refactoring, het voorbereiden van pullverzoeken en het genereren van tests. In de operationele fase vat AI logboeken samen, brengt het waarschuwingen in verband met recente releases, haalt het context uit eerdere incidenten op en verkleint het de zoekruimte tijdens triage. Teams besteden minder tijd aan het verzamelen van context uit verschillende tools en meer tijd aan het valideren van beslissingen, het oplossen van complexe problemen en het vooruitbrengen van de implementatie.

We houden het eigenaarschap over de architectuur, de goedkeuring van de beveiliging, beslissingen over gegevenstoegang, goedkeuring van releases en afwegingen rond prioriteiten bij mensen. Voor deze beslissingen zijn bedrijfscontext, verantwoordelijkheid en inzicht in de gevolgen nodig die verder gaan dan wat een ticket, prompt of coderepository bevat. AI kan alternatieven analyseren, afhankelijkheden identificeren, beveiligingsproblemen signaleren en bewijsmateriaal verzamelen, maar een verantwoordelijke engineer of leider neemt de beslissing.

We maken dat onderscheid bewust terwijl we toewerken naar meer agentische engineering. Ik verwacht dat AI meer afgebakende uitvoerende taken op zich neemt, zoals het implementeren van goed omschreven wijzigingen, het genereren en uitvoeren van tests, het valideren van implementatiecriteria of het voorstellen van stappen voor incidentremediatie. Naarmate dit gebeurt, wordt de menselijke rol belangrijker, niet minder. Engineers definiëren de bedoeling, machtigingen, kwaliteitsdrempels en grenzen voor terugdraaien, en valideren vervolgens of het systeem het beoogde resultaat heeft bereikt.

Hoe AI volledige engineeringwerkstromen effectief aanstuurt

Hier is onze volledige werkstroom die een goed gedefinieerd productverzoek door ontwerp, implementatie, validatie en een productierelease leidt. De workflow begint wanneer een productmanager en engineeringverantwoordelijke het klantresultaat, de beperkingen en de acceptatiecriteria definiëren. AI synthetiseert vervolgens relevante bedrijfscontext, bestaande documentatie, architectuurpatronen en afhankelijkheden tot een concept voor een technisch ontwerp, implementatieplan en teststrategie. Een engineer beoordeelt dat plan, neemt de architectuurbeslissingen en verdeelt het werk in kleine, onafhankelijk verifieerbare wijzigingen.

Tijdens de implementatie gebruiken engineers AI binnen de codebasis om relevante services te begrijpen, initiële code- en configuratiewijzigingen te genereren, documentatie bij te werken en unit- en integratietests te maken. Elke wijziging doorloopt nog steeds versiebeheer, geautomatiseerde CI-controles, collegiale beoordeling, beveiligingsscans en het vastgestelde releaseproces. Als een test mislukt, interpreteert AI de fout, identificeert de waarschijnlijke afhankelijkheid of regressie en stelt een correctie voor, maar de engineer verifieert de oplossing voordat deze verdergaat.

Na de implementatie gaat de workflow verder. AI vat applicatielogs samen, brengt afwijkingen in verband met recente releases en presenteert relevante eerdere incidenten of draaiboeken aan de dienstdoende engineer. We meten de volledige cyclus aan de hand van doorlooptijd, testdekking, het percentage mislukte wijzigingen, de frequentie van terugdraaiacties en de tijd tot oplossing.

Dit is geen autonome softwareontwikkeling. Het is een door mensen aangestuurd, door AI uitgebreid leveringssysteem waarin AI het verzamelen van context en de uitvoering versnelt, terwijl engineers verantwoordelijk blijven voor het ontwerp, de kwaliteit, de beveiliging en het resultaat in productie.

Manish vertelt

AI heeft de tijd die engineers besteden aan het verzamelen van context en het produceren van de eerste versie van routinematig werk aanzienlijk verkort. Het helpt teams sneller van een initiële vereiste naar een gestructureerde technische aanpak, implementatie, testdekking en documentatie te gaan.

Hoe AI zorgt voor een betere samenwerking tussen functies

Wat de resultaten betreft: AI heeft de tijd die engineers besteden aan het verzamelen van context en het produceren van de eerste versie van routinematig werk aanzienlijk verkort. Het helpt teams sneller van een initiële vereiste naar een gestructureerde technische aanpak, implementatie, testdekking en documentatie te gaan. Het heeft de ontwikkeling van nieuwe functies en productmogelijkheden versneld, vooral wanneer engineers een onbekende codebasis moeten analyseren, afhankelijkheden moeten traceren of met meerdere services moeten werken.

AI informeert ook architectuurbeslissingen. Het kan bestaande systeemdocumentatie snel synthetiseren, afhankelijkheden identificeren, implementatieopties vergelijken, waarschijnlijke afwegingen zichtbaar maken en teams helpen architectuurbeslissingsdocumenten op te stellen. Mensen nemen de uiteindelijke architectuurbeslissingen, maar teams gaan deze gesprekken aan met betere context. Ze kunnen meer tijd besteden aan het bespreken van de beslissingen die er echt toe doen, zoals schaalbaarheid, veerkracht, beveiliging, kosten en onderhoudbaarheid op lange termijn.

De verbetering bestaat niet alleen uit snellere codegeneratie. We zien een betere samenwerking gedurende de levenscyclus, omdat product, engineering, QA en operations beginnen met completere en consistentere context. Engineers besteden meer tijd aan systeemontwerp, randgevallen, integratiecomplexiteit en de impact op klanten, in plaats van handmatig informatie te verzamelen uit repositories, tickets, dashboards, logs en eerdere incidenten.

Hoe succes met AI moet worden gemeten

We hebben ook belangrijke lessen geleerd over de nadelen. AI kan een vals gevoel van snelheid creëren wanneer teams aannemelijke uitvoer accepteren zonder voldoende validatie. Het kan code genereren die correct lijkt, maar niet past binnen de omliggende architectuur, subtiele bedrijfsregels over het hoofd ziet, onnodige complexiteit introduceert of problemen met beveiliging en onderhoudbaarheid veroorzaakt. Productiviteitswinst is bovendien ongelijk verdeeld. Ingenieurs die het systeem begrijpen, werk precies formuleren en uitvoer grondig valideren, profiteren het meest.

Daarom meten we succes aan de hand van de kwaliteit van de oplevering in plaats van activiteitsstatistieken van AI. De resultaten die voor ons belangrijk zijn, zijn snellere oplevering van functies, een kortere doorlooptijd, stabiele releases, een betere testdekking, minder herstelwerk, een snellere oplossing van incidenten en blijvende betrouwbaarheid. De mogelijkheden op langere termijn zijn aanzienlijk, maar alleen als AI het technisch oordeel en de uitvoering verbetert in plaats van een vervanging voor een van beide te worden.

Hoe nieuwe beperkingen de teamstructuur veranderen

Codegeneratie vormt niet langer de beperking voor de ontwikkelsnelheid. De werkelijke beperkingen zijn vaak onduidelijke vereisten, gefragmenteerde bedrijfscontext, architecturale afhankelijkheden, beveiligingsbeoordelingen, integratie tussen systemen en de tijd die nodig is om te valideren of een wijziging veilig werkt in productie. Gegevens uit de sector wijzen in dezelfde richting: coderen vertegenwoordigt een relatief klein deel van de werkdag van een ingenieur, en AI-adoptie bij het coderen vertaalt zich niet automatisch in evenredige productiviteitswinst.

Dat veranderde mijn kijk op de teamstructuur. In plaats van AI simpelweg te beschouwen als een manier om de inspanning voor oplevering te verminderen, bewegen we naar kleinere, meer multifunctionele teams met een sterker eigenaarschap vanaf ontdekking tot en met leren in productie. Ingenieurs moeten minder tijd besteden aan het maken van eerste versies en meer tijd aan het definiëren van de bedoeling, het vormgeven van de architectuur, het valideren van uitvoer en het verbeteren van het systeem na de release.

Daarnaast is onze focus bij het aannemen van personeel verschoven van pure codeeroutput naar systeemdenken, productinzicht en het valideren van met AI ondersteund werk. We waarderen ingenieurs die met ambiguïteit kunnen omgaan, goede afwegingen kunnen maken op het gebied van architectuur en beveiliging en verantwoordelijkheid nemen voor resultaten in productie.

Manish vertelt ons

De toekomst draait niet alleen om snellere implementatie. Het gaat om snellere afstemming en een kortere cyclus tussen een idee, een productieresultaat en de lessen die de volgende beslissing informeren.

De toekomst draait niet alleen om snellere implementatie. Het gaat om snellere afstemming en een kortere cyclus tussen een idee, een productieresultaat en de lessen die de volgende beslissing informeren.

Waarom testen opnieuw moet worden ontworpen voor een door AI ondersteunde toekomst

Testen moet opnieuw worden ontworpen.

AI maakt het veel sneller om code te creëren, wat betekent dat kwaliteitsborging continu en geautomatiseerd moet worden en in de opleveringsstroom moet zijn ingebouwd, in plaats van als laatste controlepunt te worden behandeld. Teams hebben door AI ondersteunde testgeneratie, realistische evaluatiedatasets, controles op beveiliging en prestaties, productiemonitoring en duidelijk menselijk eigenaarschap voor uitzonderingen nodig.

In een door AI ondersteunde levenscyclus zal het concurrentievoordeel niet liggen bij degene die het snelst code genereert, maar bij degene die wijzigingen het veiligst kan valideren en het snelst van productie kan leren.

Hoe je AI-frictie in een vroeg stadium voorkomt

We hebben de operationele realiteit van AI onderschat. Tokenverbruik en gebruikslimieten kunnen de oplevering aanzienlijk beperken, vooral bij agentgestuurde codeerworkflows die een grote codebasecontext of herhaalde iteraties nodig hebben. We behandelen AI-uitgaven nu als een beslissing over technische capaciteit, met inzicht in gebruik, modelroutering, contextbeheer en de gerealiseerde waarde — niet alleen in licentiekosten. Ook de betrouwbaarheid van diensten is belangrijk. Een extern model of codeerplatform kan te maken krijgen met latentie, snelheidsbeperkingen of beschikbaarheidsproblemen, dus voor kritieke workflows zijn terugvalmodellen, gecontroleerde degradatie en manieren nodig waarop ingenieurs kunnen blijven werken zonder de AI-dienst.

We hadden vroege frictie kunnen voorkomen door vanaf het begin goedgekeurde tools, duidelijke gegevensgrenzen, verwachtingen voor beoordelingen, kostenbeheersing en terugvalpatronen te definiëren.

Ik zou ook niet voortijdig één tool of workflow verplicht stellen. De technologie verandert te snel. Een betere aanpak is om veilige toegang, herbruikbare waarborgen, mogelijkheden voor leren van collega's en duidelijke verantwoordelijkheid te bieden. Een engineer blijft verantwoordelijk voor wat diegene ontwerpt, beoordeelt, samenvoegt en in productie beheert.

Waarom AI moet worden beschouwd als een verandering van het operationele model

Mijn advies aan CTO's is om AI te beschouwen als een verandering van het operationele model, niet als de uitrol van een tool. Begin met een klein aantal workflows met hoge waarde waarin je een nulmeting kunt vaststellen, de impact kunt meten en snel kunt leren. Bouw een gedeeld AI-platform en een gedisciplineerde leveringsaanpak rond goedgekeurde modellen, veilige gegevenstoegang, evaluatie, observeerbaarheid en herbruikbare integratiepatronen, en houd de architectuur cloud- en modelonafhankelijk. Zo voorkom je dat elk team dezelfde beheersmaatregelen opnieuw uitvindt of zich te vroeg aan een leverancier bindt.

Minstens zo belangrijk is investeren in mensen. De organisaties die het meeste zullen winnen, zijn niet de organisaties die simpelweg meer code genereren. Het zijn de organisaties die engineers, productteams, beveiligingspartners en bedrijfsleiders helpen om werk duidelijk te formuleren, AI-uitvoer te valideren en agentische systemen binnen vastgestelde grenzen te beheren. Handel met urgentie, maar maak vertrouwen, kwaliteit, beveiliging en meetbare resultaten niet-onderhandelbaar.

AI wordt een essentiële uitvoeringslaag voor de onderneming, dus de rol van de CTO is om de architectuur, governance en cultuur te creëren die het mogelijk maken om AI op verantwoorde wijze op te schalen.

Volg het vervolg

Je kunt het werk van Manish Jain volgen op zijn Substack en LinkedIn.

Er volgen meer interviews met experts op The CTO Club!