Global leder for AI-arkitektur sier at AI er en endring av driftsmodellen, ikke en utrulling av verktøy

Manish Jain er VP og global leder for AI-arkitektur hos Firstsource, der han leder et team på 50 personer. Fokuset hans nå er å bygge agentbaserte systemer som kan håndtere arbeid i flere trinn.

Vi satte oss ned med Manish for å finne ut hvordan AI endrer driftsmodellen hans. Her er det han sa.

Fra potensial til produksjonsklar kapasitet

Jeg heter Manish Jain og er en AI- og teknologileder med fokus på å hjelpe organisasjoner med å omsette AI-potensial til pålitelig, produksjonsklar kapasitet. Jeg forankrer arbeidet mitt i transformasjonens praktiske virkelighet. Jeg har ledet mange AI- og ML-initiativer de siste årene, samarbeidet tett med forretningsteam og jobbet med utvikling og utrulling, der suksess avhenger av langt mer enn å velge riktig modell. Arkitektur, datakvalitet, sikkerhet, integrasjon, brukeradopsjon og tydelig forretningsverdi må ses i sammenheng.

For tiden leder jeg AI-initiativer på tvers av en tverrfunksjonell organisasjon på rundt 50 personer, inkludert programvare- og plattformingeniører, AI- og dataeksperter, produktledere, sikkerhetspartnere og fageksperter. Arbeidet omfatter implementering av AI i virksomheter og fremoverlent leveranse. Teamene samarbeider tett med kunder og interne interessenter for å ta verdifulle bruksområder fra kartlegging til sikker og skalerbar produksjonssetting.

Tilnærmingen vår er bevisst sky- og modellagnostisk. Vi distribuerer hovedsakelig på tvers av Azure og AWS, og bruker Google Cloud selektivt basert på kundens miljø, dataforvaltning og driftsbehov. I stedet for å utforme løsninger rundt én enkelt skyleverandør eller grunnmodell, bygger vi modulære arkitekturer som gjør det mulig å velge og videreutvikle de underliggende komponentene etter hvert som kravene endres. Dette omfatter modellaget, tjenester for datainnhenting og data, orkestreringsrammeverk, verktøy for evaluering, observerbarhet og sikkerhetskontroller.

Den virkelige kompleksiteten handler ikke bare om å velge en LLM. Det handler om å integrere AI i arbeidsflyter på tvers av fragmenterte datakilder, eldre applikasjoner, varierende brukertillatelser og strenge krav til sikkerhet, pålitelighet, kostnader og etterlevelse. Vi begynner vanligvis med et avgrenset bruksområde og en grundig evaluering, og setter deretter det som fungerer, i produksjon gjennom sikkerhetsmekanismer, menneskelig tilsyn der det er hensiktsmessig, overvåking og kontinuerlig iterasjon. Målet er å skape AI-kapasitet som forblir tilpasningsdyktig etter hvert som teknologien endres, og som er pålitelig nok til at team kan stole på den hver dag.

Jeg er spesielt interessert i overgangen fra individuelle assistenter til agentbaserte systemer som kan håndtere arbeid i flere trinn innenfor definerte grenser. For teknologiledere er muligheten betydelig, men realiseringen krever disiplinert utvikling, gjennomtenkt styring og et sterkt fokus på resultater.

Hvorfor AI-leveranser med evaluering først gir bedre resultater

Det siste året har jeg flyttet AI-leveranser fra en prototypeorientert tankegang til en evalueringsorientert utviklingsdisiplin. For et år siden bygget teamene ofte raskt imponerende konseptbevis ved å koble arbeidsflyter til enkeltmodeller. Men teamene tok ofte for sent tak i faktorene som avgjør hvor pålitelig AI er i produksjon – kvalitet, forankring, tilgangskontroll, feilhåndtering, kostnader og brukeransvar.

Vi innførte et felles leveransemønster der hvert AI-bruksområde starter med en tydelig definisjon av suksess, representative evalueringsdata, en gjennomgang av sikkerhet og datatilgang, sporbarhet og løpende overvåking. Vi bygget også den underliggende arkitekturen slik at den er sky- og modellagnostisk. Dette gjør det mulig for teamene å evaluere riktig kombinasjon av modeller, tilnærminger til datainnhenting og orkestreringsmønstre for hver arbeidsflyt, uten å låse produktet til én leverandør eller modellgenerasjon.

I praksis førte dette til mindre omarbeiding og større trygghet ved produksjonssettinger. Teamene kan identifisere forringelse av kvalitet eller kostnadsøkninger før de påvirker brukerne, ta tydelige beslutninger om hvor menneskelig gjennomgang hører hjemme, og forbedre systemene basert på dokumentasjon i stedet for anekdotiske tilbakemeldinger.

Fremover mener jeg at dette danner grunnlaget for ansvarlig agentbasert AI. Når systemene går videre fra å besvare spørsmål til å begynne å utføre handlinger i flere trinn på tvers av arbeidsflyter i virksomheten, kan vi ikke legge til evaluering, observerbarhet, tillatelser og styring i etterkant. Dette må være en del av utviklingsgrunnlaget fra dag én.

Hvordan mennesker blir viktigere med agentbasert utvikling

Vi bruker AI gjennom hele produktlivssyklusen. I kartleggingsfasen omgjør den innspill fra interessenter, tilbakemeldinger fra kunder og eksisterende dokumentasjon til innledende krav, brukerhistorier, akseptansekriterier og tekniske spørsmål. I utviklingen støtter den kartlegging av kodebasen, dokumentasjon, implementering, refaktorering, klargjøring av forespørsler om kodeendringer og generering av tester. I driften oppsummerer den logger, sammenstiller varsler med nylige lanseringer, henter frem kontekst fra tidligere hendelser og begrenser søkeområdet under feilsortering. Teamene bruker mindre tid på å samle kontekst på tvers av verktøy og mer tid på å validere beslutninger, løse komplekse problemer og drive leveransen fremover.

Vi lar mennesker beholde ansvaret for arkitekturen, sikkerhetsgodkjenning, beslutninger om datatilgang, godkjenning av utrullinger og prioriteringsavveininger. Disse beslutningene krever forretningskontekst, ansvarlighet og en forståelse av konsekvenser som går utover det et oppgavekort, en ledetekst eller et kodelager inneholder. KI kan analysere alternativer, identifisere avhengigheter, varsle om sikkerhetsbekymringer og samle dokumentasjon, men en ansvarlig utvikler eller leder tar beslutningen.

Vi skiller bevisst mellom dette når vi beveger oss mot mer agentbasert utvikling. Jeg forventer at KI tar på seg mer avgrenset utførelse, for eksempel å implementere velavgrensede endringer, generere og kjøre tester, validere kriterier for utrulling eller foreslå trinn for utbedring av hendelser. Når dette skjer, blir menneskets rolle viktigere, ikke mindre. Utviklere definerer intensjon, tillatelser, kvalitetsgrenser og rammer for tilbakeføring, og validerer deretter om systemet oppnådde det ønskede resultatet.

Slik driver KI effektive ende-til-ende-arbeidsflyter for utvikling

Her er vår ende-til-ende-arbeidsflyt, som tar en veldefinert produktforespørsel gjennom design, implementering, validering og produksjonsutrulling. Den begynner når en produktsjef og en utviklingsleder definerer kundeutfallet, begrensningene og akseptansekriteriene. KI sammenstiller deretter relevant forretningskontekst, eksisterende dokumentasjon, arkitekturmønstre og avhengigheter til et utkast til teknisk design, en implementeringsplan og en teststrategi. En utvikler gjennomgår planen, tar arkitekturbeslutningene og deler arbeidet opp i små, uavhengig verifiserbare endringer.

Under implementeringen bruker utviklerne KI i kodebasen til å forstå relevante tjenester, generere innledende kode- og konfigurasjonsendringer, oppdatere dokumentasjon og opprette enhets- og integrasjonstester. Alle endringer gjennomgår fortsatt kildekontroll, automatiserte CI-kontroller, fagfellevurdering, sikkerhetsskanning og den etablerte utgivelsesprosessen. Hvis en test mislykkes, tolker KI feilen, identifiserer den sannsynlige avhengigheten eller regresjonen og foreslår en korrigering, men utvikleren verifiserer løsningen før den går videre.

Etter utrullingen fortsetter arbeidsflyten. KI oppsummerer applikasjonslogger, sammenstiller avvik med nylige utgivelser og finner frem relevante tidligere hendelser eller driftsprosedyrer for utvikleren som har vakt. Vi måler hele sløyfen gjennom ledetid, testdekning, feilrate for endringer, hyppighet av tilbakeføringer og tid til løsning.

Dette er ikke autonom programvareutvikling. Det er et menneskeledet, KI-forsterket leveransesystem der KI komprimerer innhenting av kontekst og utførelse, mens utviklerne beholder ansvaret for design, kvalitet, sikkerhet og resultatet i produksjon.

Manish forteller oss

KI har redusert tiden utviklerne bruker på å innhente kontekst og produsere den første versjonen av rutinearbeid, betydelig. Det hjelper team med å bevege seg raskere fra et innledende krav til en strukturert teknisk tilnærming, implementering, testdekning og dokumentasjon.

Slik skaper KI bedre flyt på tvers av funksjoner

Når det gjelder resultatene, har KI redusert tiden utviklerne bruker på å innhente kontekst og produsere den første versjonen av rutinearbeid, betydelig. Det hjelper team med å bevege seg raskere fra et innledende krav til en strukturert teknisk tilnærming, implementering, testdekning og dokumentasjon. Det har satt fart på utviklingen av nye funksjoner og produktegenskaper, særlig når utviklerne må analysere en ukjent kodebase, spore avhengigheter eller arbeide på tvers av flere tjenester.

KI gir også innspill til arkitekturbeslutninger. Den kan raskt sammenstille eksisterende systemdokumentasjon, identifisere avhengigheter, sammenligne implementeringsalternativer, synliggjøre sannsynlige avveininger og hjelpe team med å opprette arkitekturbeslutningsregistre. Mennesker tar de endelige arkitekturbeslutningene, men teamene går inn i disse diskusjonene med bedre kontekst. De kan bruke mer tid på å diskutere beslutningene som faktisk betyr noe, for eksempel skalerbarhet, robusthet, sikkerhet, kostnader og langsiktig vedlikeholdbarhet.

Forbedringen handler ikke bare om raskere kodegenerering. Vi ser bedre flyt gjennom hele livssyklusen fordi produkt, utvikling, kvalitetssikring og drift starter med mer fullstendig og konsistent kontekst. Utviklerne bruker mer tid på systemdesign, kanttilfeller, integrasjonskompleksitet og kundepåvirkning, i stedet for å sette sammen informasjon manuelt fra kodelagre, oppgavekort, kontrollpaneler, logger og tidligere hendelser.

Hvordan suksess bør måles med AI

Vi har også lært viktige ting om ulempene. AI kan skape en falsk følelse av hastighet når team aksepterer plausible resultater uten tilstrekkelig validering. Den kan generere kode som ser riktig ut, men som ikke passer inn i den omkringliggende arkitekturen, overser subtile forretningsregler, introduserer unødvendig kompleksitet eller skaper sikkerhets- og vedlikeholdsproblemer. Produktivitetsgevinstene er også ujevnt fordelt. Ingeniører som forstår systemet, formulerer arbeidet presist og validerer resultatene grundig, får størst utbytte.

Derfor måler vi suksess gjennom leveringskvalitet i stedet for aktivitetsmålinger for AI. Resultatene vi bryr oss om, er raskere funksjonsleveranser, kortere syklustid, stabile utrullinger, bedre testdekning, mindre omarbeid, raskere løsning av hendelser og vedvarende pålitelighet. Mulighetene på lengre sikt er betydelige, men bare hvis AI forbedrer ingeniørmessig dømmekraft og gjennomføring i stedet for å bli en erstatning for noen av delene.

Hvordan nye begrensninger endrer teamstrukturer

Kodegenerering er ikke lenger begrensningen for utviklingshastigheten. De reelle begrensningene er ofte uklare krav, fragmentert forretningskontekst, arkitektoniske avhengigheter, sikkerhetsgjennomgang, integrasjon på tvers av systemer og tiden det tar å validere at en endring fungerer trygt i produksjon. Bransjedata peker i samme retning: Koding utgjør en relativt liten del av en ingeniørs arbeidsdag, og bruk av AI i koding fører ikke automatisk til tilsvarende økning i gjennomstrømningen.

Det endret måten jeg tenker på teamstruktur på. I stedet for å bare se på AI som en måte å redusere leveringsarbeidet på, beveger vi oss mot mindre, mer tverrfunksjonelle team med sterkere eierskap fra utforskning til læring i produksjon. Ingeniører må bruke mindre tid på å lage førsteutkast og mer tid på å definere intensjon, forme arkitekturen, validere resultater og forbedre systemet etter lansering.

Videre har fokuset vårt i ansettelser flyttet seg fra ren kodeproduksjon til systemtenkning, produktmessig dømmekraft og validering av AI-assistert arbeid. Vi verdsetter ingeniører som kan håndtere tvetydighet, gjøre gode avveininger mellom arkitektur og sikkerhet og ta ansvar for resultater i produksjon.

Manish forteller oss

Fremtiden handler ikke bare om raskere implementering. Den handler om raskere samordning og en tettere sløyfe mellom en idé, et resultat i produksjon og læringen som legger grunnlaget for den neste beslutningen.

Fremtiden handler ikke bare om raskere implementering. Den handler om raskere samordning og en tettere sløyfe mellom en idé, et resultat i produksjon og læringen som legger grunnlaget for den neste beslutningen.

Hvorfor testingen må utformes på nytt for en AI-forsterket fremtid

Testingen må utformes på nytt.

AI gjør det mye raskere å lage kode, noe som betyr at kvalitetssikring må bli kontinuerlig, automatisert og innebygd i leveranseflyten i stedet for å bli behandlet som en avsluttende kontroll. Team trenger AI-assistert generering av tester, realistiske evalueringsdatasett, sikkerhets- og ytelseskontroller, produksjonsovervåking og tydelig menneskelig ansvar for unntak.

I en AI-forsterket livssyklus vil konkurransefortrinnet ikke ligge hos den som genererer kode raskest, men hos den som kan validere endringer på en trygg måte og lære raskest av produksjonen.

Slik unngår du AI-friksjon tidlig

Vi undervurderte de operative realitetene ved AI. Tokenforbruk og bruksgrenser kan begrense leveransen betydelig, særlig for agentiske kodearbeidsflyter som trenger kontekst fra store kodebaser eller gjentatte iterasjoner. Nå behandler vi AI-utgifter som en beslutning om ingeniørkapasitet, med oversikt over bruk, modellruting, konteksthåndtering og verdien som skapes — ikke bare lisenskostnaden. Tjenestepålitelighet er også viktig. En ekstern modell eller kodeplattform kan oppleve forsinkelser, hastighetsbegrensninger eller tilgjengelighetsproblemer, så kritiske arbeidsflyter trenger reservemodeller, kontrollert funksjonsreduksjon og måter for ingeniører å fortsette arbeidet på uten AI-tjenesten.

Vi kunne ha unngått tidlig friksjon ved å definere godkjente verktøy, tydelige datagrenser, forventninger til gjennomgang, kostnadskontroller og reservemønstre fra starten av.

Jeg ville heller ikke på et tidlig tidspunkt pålegge alle å bruke ett bestemt verktøy eller én bestemt arbeidsflyt. Teknologien endrer seg for raskt. En bedre tilnærming er å tilby sikker tilgang, gjenbrukbare sikkerhetsrammer, muligheter for læring mellom kolleger og tydelig ansvar. En utvikler har fortsatt ansvaret for det de utformer, gjennomgår, slår sammen og drifter i produksjon.

Hvorfor AI bør behandles som en endring av driftsmodellen

Mitt råd til CTO-er er å behandle AI som en endring av driftsmodellen, ikke som en utrulling av et verktøy. Start med et lite antall arbeidsflyter med høy verdi, der dere kan etablere et utgangspunkt, måle effekten og lære raskt. Bygg en felles AI-plattform og en leveransedisiplin rundt godkjente modeller, sikker datatilgang, evaluering, observerbarhet og gjenbrukbare integrasjonsmønstre, og hold arkitekturen skyuavhengig og modellagnostisk. Det hindrer hvert team i å finne opp de samme kontrollene på nytt eller bli bundet til en leverandør for tidlig.

Like viktig er det å investere i mennesker. Organisasjonene som vil få størst utbytte, er ikke nødvendigvis de som ganske enkelt genererer mer kode. Det vil være de som hjelper utviklere, produktteam, sikkerhetspartnere og virksomhetsledere med å lære å formulere arbeidet tydelig, validere resultater fra AI og drifte agentbaserte systemer innenfor definerte grenser. Beveg dere raskt, men gjør tillit, kvalitet, sikkerhet og målbare resultater ufravikelige.

AI er i ferd med å bli et sentralt gjennomføringslag for virksomheten, så CTO-ens rolle er å skape arkitekturen, styringen og kulturen som gjør det mulig å skalere på en ansvarlig måte.

Følg med

Du kan følge arbeidet til Manish Jain på hans Substack og LinkedIn.

Flere ekspertintervjuer kommer på The CTO Club!