Global chef för AI-arkitektur säger att AI innebär en förändring av verksamhetsmodellen, inte utrullning av ett verktyg

Manish Jain är vice vd och global chef för AI-arkitektur på Firstsource, där han leder ett team på 50 personer. Just nu fokuserar han på att bygga agentbaserade system som kan hantera arbete i flera steg.

Vi satte oss ner med Manish för att ta reda på hur AI förändrar hans operativa modell. Här är vad han sa.

Från potential till produktionsklar kapacitet

Jag heter Manish Jain och är AI- och teknikledare med fokus på att hjälpa organisationer att omvandla AI-potential till tillförlitlig, produktionsklar kapacitet. Jag grundar mitt arbete i transformationens praktiska verklighet. Under de senaste åren har jag lett många AI- och ML-initiativ, samarbetat nära med verksamhetsteam och arbetat med utveckling och driftsättning där framgången beror på mycket mer än att välja rätt modell. Arkitektur, datakvalitet, säkerhet, integration, användarinförande och tydligt affärsvärde måste samverka.

Jag leder för närvarande AI-initiativ i en tvärfunktionell organisation med omkring 50 personer, däribland programvaru- och plattformsingenjörer, AI- och dataspecialister, produktledare, säkerhetspartner och experter inom olika verksamhetsområden. Arbetet omfattar implementering av AI i företag samt leverans nära verksamheten. Teamen arbetar nära kunder och interna intressenter för att ta värdefulla användningsfall från upptäckt till säker och skalbar produktionsdriftsättning.

Vår strategi är medvetet moln- och modelloberoende. Vi driftsätter främst lösningar i Azure och AWS och använder Google Cloud selektivt utifrån kundens miljö, datalandskap och operativa behov. I stället för att utforma lösningar kring en enda molnleverantör eller grundmodell bygger vi modulära arkitekturer som gör det möjligt för oss att välja och utveckla de underliggande komponenterna när kraven förändras. Detta omfattar modellagret, tjänster för hämtning och data, orkestreringsramverk, verktyg för utvärdering, observerbarhet och säkerhetskontroller.

Den verkliga komplexiteten ligger inte bara i att välja en LLM. Det handlar om att integrera AI i verksamhetens arbetsflöden över fragmenterade datakällor, äldre applikationer, varierande användarbehörigheter och strikta krav på säkerhet, tillförlitlighet, kostnader och efterlevnad. Vi börjar vanligtvis med ett avgränsat användningsfall och en noggrann utvärdering och sätter sedan det som fungerar i produktion genom skyddsräcken, mänsklig översyn där det är lämpligt, övervakning och kontinuerlig vidareutveckling. Målet är att skapa AI-kapacitet som förblir anpassningsbar när tekniken förändras och tillräckligt tillförlitlig för att team ska kunna förlita sig på den varje dag.

Jag är särskilt intresserad av övergången från individuella AI-assistenter till agentbaserade system som kan hantera arbete i flera steg inom tydligt definierade gränser. För teknikledare är möjligheten betydande, men för att förverkliga den krävs disciplinerad utveckling, genomtänkt styrning och ett starkt fokus på resultat.

Varför AI-leverans med utvärdering först ger bättre resultat

Under det senaste året har jag gått från ett prototypförst-perspektiv på AI-leverans till en utvecklingsdisciplin där utvärdering kommer först. För ett år sedan byggde team ofta snabbt imponerande konceptdemonstrationer genom att koppla arbetsflöden till enskilda modeller. Men de faktorer som avgör AI:s tillförlitlighet i produktion – kvalitet, förankring, åtkomstkontroll, felhantering, kostnader och användaransvar – hanterades ofta för sent.

Vi införde ett gemensamt leveransmönster där varje AI-användningsfall börjar med en tydlig definition av framgång, representativa utvärderingsdata, en granskning av säkerhet och dataåtkomst, spårbarhet samt löpande övervakning. Vi byggde också den underliggande arkitekturen så att den är moln- och modelloberoende. Det gör det möjligt för teamen att utvärdera rätt kombination av modeller, metoder för datahämtning och orkestreringsmönster för varje arbetsflöde utan att låsa produkten till en leverantör eller modellgeneration.

I praktiken ledde detta till mindre omarbete och större förtroende för produktionsdriftsättningar. Teamen kan identifiera försämringar i kvalitet eller kostnader innan de påverkar användarna, fatta tydliga beslut om var mänsklig granskning behövs och förbättra systemen utifrån fakta i stället för anekdotisk återkoppling.

Framöver tror jag att detta utgör grunden för ansvarsfull agentbaserad AI. När systemen går från att besvara frågor till att börja utföra handlingar i flera steg över verksamhetens arbetsflöden kan vi inte lägga till utvärdering, observerbarhet, behörigheter och styrning i efterhand. De måste vara en del av utvecklingsstrukturen från dag ett.

Hur människor blir viktigare med agentbaserad utveckling

Vi använder AI under hela produktlivscykeln. I upptäcktsfasen omvandlar den synpunkter från intressenter, kundfeedback och befintlig dokumentation till inledande krav, användarberättelser, acceptanskriterier och tekniska frågor. Inom utveckling stöder den kartläggning av kodbaser, dokumentation, implementering, omstrukturering, förberedelse av pull requests och generering av tester. Inom drift sammanfattar den loggar, kopplar samman aviseringar med nyligen genomförda lanseringar, hämtar kontext från tidigare incidenter och begränsar sökområdet under felsökning. Teamen ägnar mindre tid åt att sammanställa kontext från olika verktyg och mer tid åt att validera beslut, lösa komplexa problem och driva leveransen framåt.

Vi behåller ägarskapet för arkitekturen, säkerhetsgodkännandet, besluten om dataåtkomst, godkännandet av releaser och prioriteringsavvägningarna hos människor. Dessa beslut kräver affärskontext, ansvarstagande och en förståelse för konsekvenser som sträcker sig längre än vad ett ärende, en prompt eller ett kodförråd innehåller. AI kan analysera alternativ, identifiera beroenden, uppmärksamma säkerhetsproblem och sammanställa underlag, men det är en ansvarig ingenjör eller ledare som fattar beslutet.

Vi gör medvetet denna åtskillnad när vi rör oss mot ett mer agentbaserat ingenjörsarbete. Jag förväntar mig att AI tar på sig mer avgränsat utförande, till exempel att implementera välavgränsade ändringar, generera och köra tester, validera driftsättningskriterier eller föreslå åtgärder för incidenthantering. När detta sker blir människans roll viktigare, inte mindre. Ingenjörer definierar avsikt, behörigheter, kvalitetsnivåer och gränser för återställning och validerar sedan om systemet uppnådde det avsedda resultatet.

Så effektiviserar AI tekniska arbetsflöden från början till slut

Här är vårt arbetsflöde från början till slut, som tar en väldefinierad produktförfrågan genom design, implementering, validering och produktionssättning. Det börjar när en produktchef och en teknisk ledare definierar kundresultatet, begränsningarna och acceptanskriterierna. AI sammanställer sedan relevant affärskontext, befintlig dokumentation, arkitekturmönster och beroenden till ett utkast till teknisk design, implementeringsplan och teststrategi. En ingenjör granskar planen, fattar arkitekturbesluten och delar upp arbetet i små, oberoende verifierbara ändringar.

Under implementeringen använder ingenjörerna AI i kodbasen för att förstå relevanta tjänster, generera inledande kod- och konfigurationsändringar, uppdatera dokumentationen och skapa enhets- och integrationstester. Varje ändring genomgår fortfarande versionshantering, automatiska CI-kontroller, kollegial granskning, säkerhetsskanning och den etablerade releaseprocessen. Om ett test misslyckas tolkar AI felet, identifierar det sannolika beroendet eller regressionen och föreslår en korrigering, men ingenjören verifierar lösningen innan den går vidare.

Efter driftsättningen fortsätter arbetsflödet. AI sammanfattar applikationsloggar, kopplar avvikelser till de senaste releaserna och lyfter fram relevanta tidigare incidenter eller körböcker för den ingenjör som har jour. Vi mäter hela återkopplingsloopen genom ledtid, testtäckning, andel ändringar som leder till fel, frekvensen av återställningar och tid till lösning.

Det här är inte autonom mjukvaruutveckling. Det är ett människolett, AI-förstärkt leveranssystem där AI komprimerar insamlingen av kontext och utförandet, medan ingenjörerna behåller ansvaret för design, kvalitet, säkerhet och resultatet i produktion.

Manish berättar för oss

AI har avsevärt minskat den tid ingenjörer lägger på att samla in kontext och ta fram den första versionen av rutinartat arbete. Det hjälper team att snabbare gå från ett inledande krav till ett strukturerat tekniskt angreppssätt, implementering, testtäckning och dokumentation.

Så skapar AI ett bättre flöde mellan funktioner

Vad gäller resultaten har AI avsevärt minskat den tid ingenjörer lägger på att samla in kontext och ta fram den första versionen av rutinartat arbete. Det hjälper team att snabbare gå från ett inledande krav till ett strukturerat tekniskt angreppssätt, implementering, testtäckning och dokumentation. Det har påskyndat utvecklingen av nya funktioner och produktegenskaper, särskilt när ingenjörer behöver analysera en obekant kodbas, spåra beroenden eller arbeta över flera tjänster.

AI bidrar också till arkitekturbeslut. Det kan snabbt sammanställa befintlig systemdokumentation, identifiera beroenden, jämföra implementeringsalternativ, synliggöra sannolika avvägningar och hjälpa team att skapa beslutsunderlag för arkitekturen. Människor fattar de slutliga arkitekturbesluten, men teamen går in i dessa diskussioner med bättre kontext. De kan ägna mer tid åt att diskutera de beslut som verkligen spelar roll, till exempel skalbarhet, motståndskraft, säkerhet, kostnad och långsiktig underhållbarhet.

Förbättringen handlar inte bara om snabbare kodgenerering. Vi ser ett bättre flöde genom hela livscykeln eftersom produkt, teknik, kvalitetssäkring och drift börjar med mer fullständig och konsekvent kontext. Ingenjörer ägnar mer tid åt systemdesign, kantfall, integrationskomplexitet och kundpåverkan i stället för att manuellt sammanställa information från kodförråd, ärenden, instrumentpaneler, loggar och tidigare incidenter.

Så bör framgång mätas med AI

Vi har också lärt oss viktiga lärdomar om nackdelarna. AI kan skapa en falsk känsla av snabbhet när team accepterar sannolika resultat utan tillräcklig validering. Den kan generera kod som verkar korrekt men inte passar in i den omgivande arkitekturen, missar subtila affärsregler, introducerar onödig komplexitet eller skapar säkerhets- och underhållsproblem. Produktivitetsvinsterna är också ojämna. Ingenjörer som förstår systemet, formulerar arbetet exakt och validerar resultaten noggrant drar störst nytta.

Därför mäter vi framgång genom leveranskvalitet snarare än aktivitetsmått för AI. De resultat vi bryr oss om är snabbare leverans av funktioner, kortare cykeltid, stabila releaser, bättre testtäckning, mindre omarbete, snabbare incidentlösning och varaktig tillförlitlighet. Den långsiktiga möjligheten är betydande, men bara om AI förbättrar ingenjörernas omdöme och genomförande i stället för att bli en ersättning för något av dem.

Hur nya begränsningar förändrar teamstrukturer

Kodgenerering är inte längre begränsningen för ingenjörernas leveranshastighet. De verkliga begränsningarna är ofta otydliga krav, fragmenterad affärskontext, arkitektoniska beroenden, säkerhetsgranskning, integration mellan system och tiden det tar att validera att en förändring fungerar säkert i produktion. Branschdata pekar i samma riktning: kodning utgör en relativt liten del av en ingenjörs arbetsdag, och AI-användning vid kodning leder inte automatiskt till proportionella produktivitetsökningar.

Det förändrade hur jag ser på teamstrukturen. I stället för att helt enkelt se AI som ett sätt att minska leveransinsatsen går vi mot mindre, mer tvärfunktionella team med starkare ägarskap från upptäckt till lärande i produktion. Ingenjörer behöver lägga mindre tid på att skapa första utkast och mer tid på att definiera avsikten, utforma arkitekturen, validera resultaten och förbättra systemet efter lansering.

Dessutom har vårt rekryteringsfokus skiftat från ren kodningsproduktion till systemtänkande, produktomdöme och validering av AI-assisterat arbete. Vi värdesätter ingenjörer som kan hantera tvetydighet, göra välgrundade avvägningar kring arkitektur och säkerhet samt ta ansvar för resultaten i produktion.

Manish berättar

Framtiden handlar inte bara om snabbare implementation. Den handlar om snabbare samsyn och en tätare återkopplingsloop mellan en idé, ett produktionsresultat och den lärdom som ligger till grund för nästa beslut.

Framtiden handlar inte bara om snabbare implementation. Den handlar om snabbare samsyn och en tätare återkopplingsloop mellan en idé, ett produktionsresultat och den lärdom som ligger till grund för nästa beslut.

Varför testningen måste göras om för en AI-förstärkt framtid

Testningen måste göras om.

AI gör det mycket snabbare att skapa kod, vilket innebär att kvalitetssäkringen måste bli kontinuerlig, automatiserad och inbyggd i leveransflödet i stället för att behandlas som en sista kontrollpunkt. Team behöver AI-assisterad testgenerering, realistiska utvärderingsdatauppsättningar, säkerhets- och prestandakontroller, produktionsövervakning samt ett tydligt mänskligt ansvar för undantag.

I en AI-förstärkt livscykel kommer konkurrensfördelen inte att ligga hos den som genererar kod snabbast, utan hos den som kan validera förändringar säkert och lära sig av produktionen snabbast.

Så undviker du AI-friktion i ett tidigt skede

Vi underskattade de operativa realiteterna med AI. Tokenförbrukning och användningsgränser kan begränsa leveransen avsevärt, särskilt för agentbaserade kodningsarbetsflöden som behöver en stor kodbas som kontext eller upprepade iterationer. Nu betraktar vi AI-kostnader som ett beslut om ingenjörskapacitet, med insyn i användning, modellstyrning, kontexthantering och det värde som skapas – inte bara som en licenskostnad. Tjänsternas tillförlitlighet är också viktig. En extern modell eller kodningsplattform kan drabbas av fördröjningar, hastighetsbegränsningar eller tillgänglighetsproblem, så kritiska arbetsflöden behöver reservmodeller, kontrollerad degradering och sätt för ingenjörer att fortsätta arbeta utan AI-tjänsten.

Vi hade kunnat undvika tidig friktion genom att från början definiera godkända verktyg, tydliga datagränser, förväntningar på granskning, kostnadskontroller och reservmönster.

Jag skulle inte heller föreskriva ett enda verktyg eller arbetsflöde för tidigt. Tekniken förändras alldeles för snabbt. Ett bättre tillvägagångssätt är att tillhandahålla säker åtkomst, återanvändbara skyddsräcken, möjligheter till kollegialt lärande och tydligt ansvar. En ingenjör ansvarar fortfarande för det de utformar, granskar, slår samman och driver i produktion.

Varför AI bör behandlas som en förändring av verksamhetsmodellen

Mitt råd till CTO:er är att behandla AI som en förändring av verksamhetsmodellen, inte som en utrullning av ett verktyg. Börja med ett litet antal arbetsflöden med högt värde där ni kan fastställa ett utgångsläge, mäta effekten och lära er snabbt. Bygg en gemensam AI-plattform och leveransdisciplin kring godkända modeller, säker dataåtkomst, utvärdering, observerbarhet och återanvändbara integrationsmönster, och håll arkitekturen oberoende av moln och modell. Det hindrar varje team från att uppfinna samma kontroller på nytt eller bli bundet till en leverantör för tidigt.

Minst lika viktigt är att investera i människor. De organisationer som kommer att vinna mest är inte de som helt enkelt genererar mer kod. Det är de som hjälper ingenjörer, produktteam, säkerhetspartner och företagsledare att lära sig formulera arbetet tydligt, validera AI-resultat och driva agentbaserade system inom definierade gränser. Agera skyndsamt, men gör förtroende, kvalitet, säkerhet och mätbara resultat icke-förhandlingsbara.

AI håller på att bli ett centralt genomförandelager för företaget, så CTO:ns roll är att skapa den arkitektur, styrning och kultur som gör att det kan skalas ansvarsfullt.

Följ med

Du kan följa Manish Jains arbete på hans Substack och LinkedIn.

Fler expertintervjuer kommer snart på The CTO Club!