Global chef for AI-arkitektur siger, at AI er en ændring af driftsmodellen, ikke en udrulning af værktøjer

Manish Jain er VP og global chef for AI-arkitektur hos Firstsource, hvor han leder et team på 50 personer. Hans fokus lige nu er at opbygge agentbaserede systemer, der kan håndtere arbejde i flere trin.

Vi satte os ned med Manish for at høre, hvordan AI ændrer hans arbejdsmodel. Her er, hvad han sagde.

Fra potentiale til produktionsklar kapacitet

Jeg hedder Manish Jain og er leder inden for AI og teknologi med fokus på at hjælpe organisationer med at omsætte AI-potentiale til pålidelig, produktionsklar kapacitet. Jeg baserer mit arbejde på transformationens praktiske virkelighed. Jeg har ledet mange AI- og ML-initiativer i løbet af de seneste år, samarbejdet tæt med forretningsteams og arbejdet med udvikling og implementeringer, hvor succes afhænger af langt mere end at vælge den rigtige model. Arkitektur, datakvalitet, sikkerhed, integration, brugeradoption og tydelig forretningsværdi skal gå op i en højere enhed.

Jeg leder i øjeblikket AI-initiativer på tværs af en tværfunktionel organisation med omkring 50 personer, herunder software- og platformingeniører, AI- og dataspecialister, produktledere, sikkerhedspartnere og eksperter inden for forretningsområder. Arbejdet omfatter implementering af AI i virksomheder og fremadrettet leverance. Teams arbejder tæt sammen med kunder og interne interessenter for at føre værdifulde anvendelsesområder fra afdækning gennem sikker og skalerbar implementering i produktion.

Vores tilgang er bevidst uafhængig af både cloud og model. Vi implementerer primært på tværs af Azure og AWS og anvender i udvalgte tilfælde Google Cloud baseret på kundens miljø, dataopbygning og driftsmæssige behov. I stedet for at designe omkring én cloududbyder eller én grundmodel opbygger vi modulære arkitekturer, der gør det muligt at vælge og videreudvikle de underliggende komponenter, efterhånden som kravene ændrer sig. Det omfatter modellaget, tjenester til informationssøgning og data, orkestreringsrammen, værktøjer til evaluering, observerbarhed og sikkerhedskontroller.

Den egentlige kompleksitet ligger ikke blot i at vælge en LLM. Den består i at integrere AI i arbejdsgange på tværs af virksomheden med fragmenterede datakilder, ældre applikationer, varierende brugerrettigheder og strenge krav til sikkerhed, pålidelighed, omkostninger og compliance. Vi begynder typisk med et fokuseret anvendelsesområde og en grundig evaluering og sætter derefter det, der fungerer, i produktion gennem sikkerhedsforanstaltninger, menneskeligt tilsyn, hvor det er relevant, overvågning og løbende iteration. Målet er at skabe AI-kapaciteter, der forbliver tilpasningsdygtige, efterhånden som teknologien ændrer sig, og som er pålidelige nok til, at teams kan stole på dem hver dag.

Jeg er især interesseret i overgangen fra individuelle co-piloter til agentbaserede systemer, der kan håndtere arbejde i flere trin inden for klart definerede rammer. For teknologiledere er potentialet betydeligt, men det kræver disciplineret udvikling, gennemtænkt styring og et stærkt fokus på resultater at realisere det.

Hvorfor AI-leverancer med evaluering først giver bedre resultater

Det seneste år har jeg flyttet AI-leverancer fra en prototype-først-tankegang til en udviklingsdisciplin, hvor evaluering kommer først. For et år siden byggede teams ofte hurtigt imponerende prototyper ved at forbinde arbejdsgange med enkeltstående modeller. Men teams håndterede ofte de faktorer, der afgør, om AI er troværdig i produktion — kvalitet, forankring, adgangskontrol, fejlhåndtering, omkostninger og brugeransvar — for sent.

Vi indførte et fælles leverancemønster, hvor alle AI-anvendelsesområder begynder med en klar definition af succes, repræsentative evalueringsdata, en gennemgang af sikkerhed og dataadgang, sporbarhed og løbende overvågning. Vi opbyggede også den underliggende arkitektur, så den er uafhængig af cloud og model. Det gør det muligt for teams at evaluere den rette kombination af modeller, informationssøgningsmetoder og orkestreringsmønstre for hver arbejdsgang uden at låse produktet fast til én udbyder eller modelgeneration.

I praksis har det resulteret i mindre omarbejde og større tillid til implementeringer i produktion. Teams kan identificere forringelser af kvalitet eller omkostninger, før de påvirker brugerne, træffe eksplicitte beslutninger om, hvor menneskelig gennemgang hører hjemme, og forbedre systemer baseret på evidens frem for anekdotisk feedback.

Fremadrettet mener jeg, at dette danner grundlaget for ansvarlig agentbaseret AI. Når systemer bevæger sig ud over at besvare spørgsmål og begynder at udføre handlinger i flere trin på tværs af virksomhedens arbejdsgange, kan vi ikke tilføje evaluering, observerbarhed, tilladelser og styring bagefter. De skal være en del af udviklingsfundamentet fra dag ét.

Hvordan mennesker bliver vigtigere med agentbaseret udvikling

Vi bruger AI gennem hele produktets livscyklus. I afdækningsfasen omsætter AI input fra interessenter, kundefeedback og eksisterende dokumentation til indledende krav, brugerhistorier, acceptkriterier og tekniske spørgsmål. I udviklingen understøtter AI udforskning af kodebaser, dokumentation, implementering, refaktorering, forberedelse af kodeændringsforslag og generering af tests. I driften opsummerer AI logfiler, sammenholder alarmer med de seneste udgivelser, henter kontekst fra tidligere hændelser og indsnævrer søgeområdet under prioritering og fejlsøgning. Teams bruger mindre tid på at samle kontekst på tværs af værktøjer og mere tid på at validere beslutninger, løse komplekse problemer og føre leverancer fremad.

Vi lader mennesker beholde ejerskabet over arkitekturen, sikkerhedsgodkendelsen, beslutninger om dataadgang, godkendelse af udgivelser og prioriteringsafvejninger. Disse beslutninger kræver forretningskontekst, ansvarlighed og en forståelse af konsekvenser, der rækker ud over det, en opgave, en prompt eller et kodelager indeholder. AI kan analysere alternativer, identificere afhængigheder, gøre opmærksom på sikkerhedsproblemer og samle dokumentation, men en ansvarlig udvikler eller leder træffer beslutningen.

Vi foretager bevidst denne sondring, mens vi bevæger os mod mere agentisk udvikling. Jeg forventer, at AI påtager sig mere afgrænset udførelse, såsom at implementere velafgrænsede ændringer, generere og køre tests, validere kriterier for udrulning eller foreslå trin til afhjælpning af hændelser. Efterhånden som dette sker, bliver menneskets rolle vigtigere, ikke mindre. Udviklere definerer intention, tilladelser, kvalitetstærskler og grænser for tilbagerulning og validerer derefter, om systemet opnåede det tilsigtede resultat.

Sådan driver AI effektivt tekniske arbejdsgange fra ende til ende

Her er vores arbejdsgang fra ende til ende, som fører en veldefineret produktanmodning gennem design, implementering, validering og udgivelse til produktion. Den begynder, når en produktchef og en teknisk leder definerer kundeudbyttet, begrænsningerne og acceptkriterierne. AI sammenfatter derefter relevant forretningskontekst, eksisterende dokumentation, arkitekturmønstre og afhængigheder til et udkast til et teknisk design, en implementeringsplan og en teststrategi. En udvikler gennemgår planen, træffer arkitekturbeslutningerne og opdeler arbejdet i små, uafhængigt verificerbare ændringer.

Under implementeringen bruger udviklerne AI i kodebasen til at forstå relevante tjenester, generere den første kode og konfigurationsændringer, opdatere dokumentationen samt oprette enheds- og integrationstests. Alle ændringer gennemgår stadig versionsstyring, automatiserede CI-kontroller, fagfællebedømmelse, sikkerhedsscanning og den fastlagte udgivelsesproces. Hvis en test mislykkes, fortolker AI fejlen, identificerer den sandsynlige afhængighed eller regression og foreslår en rettelse, men udvikleren verificerer rettelsen, før den går videre.

Efter udrulningen fortsætter arbejdsgangen. AI opsummerer applikationslogfiler, sammenholder anomalier med nylige udgivelser og finder relevante tidligere hændelser eller driftsvejledninger til den vagthavende udvikler. Vi måler hele forløbet gennem gennemløbstid, testdækning, fejlrate for ændringer, hyppighed af tilbagerulninger og tid til løsning.

Dette er ikke autonom softwareudvikling. Det er et menneskestyret, AI-udvidet leveringssystem, hvor AI komprimerer indsamlingen af kontekst og udførelsen, mens udviklerne bevarer ansvaret for design, kvalitet, sikkerhed og resultatet i produktionen.

Manish fortæller

AI har reduceret den tid, udviklerne bruger på at indsamle kontekst og producere den første version af rutinearbejde, betydeligt. Det hjælper teams med hurtigere at bevæge sig fra et indledende krav til en struktureret teknisk tilgang, implementering, testdækning og dokumentation.

Sådan skaber AI et bedre flow på tværs af funktioner

Hvad angår resultaterne, har AI reduceret den tid, udviklerne bruger på at indsamle kontekst og producere den første version af rutinearbejde, betydeligt. Det hjælper teams med hurtigere at bevæge sig fra et indledende krav til en struktureret teknisk tilgang, implementering, testdækning og dokumentation. Det har accelereret udviklingen af nye funktioner og produktegenskaber, især når udviklerne skal analysere en ukendt kodebase, spore afhængigheder eller arbejde på tværs af flere tjenester.

AI bidrager også til arkitekturbeslutninger. Det kan hurtigt sammenfatte eksisterende systemdokumentation, identificere afhængigheder, sammenligne implementeringsmuligheder, synliggøre sandsynlige afvejninger og hjælpe teams med at oprette arkitekturbeslutningsregistre. Mennesker træffer de endelige arkitekturbeslutninger, men teams går ind i disse drøftelser med bedre kontekst. De kan bruge mere tid på at diskutere de beslutninger, der reelt betyder noget, såsom skalerbarhed, robusthed, sikkerhed, omkostninger og langsigtet vedligeholdelse.

Forbedringen handler ikke blot om hurtigere kodegenerering. Vi ser et bedre flow gennem hele livscyklussen, fordi produkt, udvikling, QA og drift starter med en mere komplet og ensartet kontekst. Udviklerne bruger mere tid på systemdesign, kanttilfælde, integrationskompleksitet og kundeindvirkning i stedet for manuelt at samle oplysninger fra kodelagre, opgaver, dashboards, logfiler og tidligere hændelser.

Sådan bør succes måles med AI

Vi har også lært vigtige lektier om ulemperne. AI kan skabe en falsk fornemmelse af hastighed, når teams accepterer sandsynlige resultater uden tilstrækkelig validering. Den kan generere kode, der ser korrekt ud, men ikke passer til den omgivende arkitektur, overser subtile forretningsregler, introducerer unødvendig kompleksitet eller skaber problemer med sikkerhed og vedligeholdelse. Produktivitetsgevinsterne er også ujævnt fordelt. Ingeniører, der forstår systemet, formulerer opgaver præcist og validerer resultater grundigt, får mest ud af det.

Derfor måler vi succes gennem leveringskvalitet i stedet for aktivitetsmålinger for AI. De resultater, vi fokuserer på, er hurtigere levering af funktioner, kortere gennemløbstid, stabile udgivelser, bedre testdækning, mindre omarbejde, hurtigere løsning af hændelser og vedvarende pålidelighed. Muligheden på længere sigt er betydelig, men kun hvis AI forbedrer ingeniørernes dømmekraft og udførelse i stedet for at blive en erstatning for nogen af delene.

Sådan ændrer nye begrænsninger teamstrukturer

Generering af kode er ikke længere begrænsningen for udviklingshastigheden. De reelle begrænsninger er ofte uklare krav, fragmenteret forretningskontekst, arkitektoniske afhængigheder, sikkerhedsgennemgang, integration på tværs af systemer samt den tid, det tager at validere, at en ændring fungerer sikkert i produktion. Data fra branchen peger i samme retning: Kodning udgør en relativt lille del af en ingeniørs arbejdsdag, og AI-anvendelse til kodning omsættes ikke automatisk til tilsvarende produktivitetsgevinster.

Det ændrede min opfattelse af teamstrukturen. I stedet for blot at betragte AI som en måde at reducere leveringsindsatsen på bevæger vi os mod mindre, mere tværfunktionelle teams med et stærkere ejerskab fra afdækning til læring fra produktionen. Ingeniører skal bruge mindre tid på at skabe første udkast og mere tid på at definere hensigten, forme arkitekturen, validere resultater og forbedre systemet efter udgivelsen.

Desuden har vores fokus ved ansættelser flyttet sig fra ren kodeproduktion til systemtænkning, produktmæssig dømmekraft og validering af AI-assisteret arbejde. Vi værdsætter ingeniører, der kan håndtere tvetydighed, træffe velovervejede kompromiser inden for arkitektur og sikkerhed samt tage ansvar for resultater gennem produktionen.

Manish fortæller os

Fremtiden handler ikke kun om hurtigere implementering. Den handler om hurtigere afstemning og en tættere sløjfe mellem en idé, et resultat i produktionen og den læring, der danner grundlag for den næste beslutning.

Fremtiden handler ikke kun om hurtigere implementering. Den handler om hurtigere afstemning og en tættere sløjfe mellem en idé, et resultat i produktionen og den læring, der danner grundlag for den næste beslutning.

Derfor skal testning gentænkes til en AI-understøttet fremtid

Testning skal gentænkes.

AI gør det langt hurtigere at skabe kode, hvilket betyder, at kvalitetssikring skal være kontinuerlig, automatiseret og indbygget i leveringsflowet i stedet for at blive behandlet som en afsluttende kontrol. Teams har brug for AI-assisteret generering af tests, realistiske evalueringsdatasæt, sikkerheds- og ydelseskontroller, overvågning af produktionen samt et klart menneskeligt ansvar for undtagelser.

I en AI-understøttet livscyklus vil konkurrencefordelen ikke ligge hos dem, der genererer kode hurtigst, men hos dem, der hurtigst kan validere ændringer sikkert og lære af produktionen.

Sådan undgår du AI-friktion tidligt

Vi undervurderede de driftsmæssige realiteter ved AI. Forbrug af tokens og brugsgrænser kan i væsentlig grad begrænse leveringen, især for agentbaserede kodningsarbejdsgange, der har brug for kontekst fra store kodebaser eller gentagne iterationer. Vi betragter nu AI-forbrug som en beslutning om ingeniørkapacitet med synlighed i forbrug, modeldirigering, konteksthåndtering og den skabte værdi – ikke kun som en licensomkostning. Tjenestens pålidelighed er også vigtig. En ekstern model eller kodningsplatform kan opleve forsinkelse, hastighedsbegrænsninger eller tilgængelighedsproblemer, så kritiske arbejdsgange har brug for reservemodeller, kontrolleret forringelse og måder, hvorpå ingeniører kan fortsætte arbejdet uden AI-tjenesten.

Vi kunne have undgået den tidlige friktion ved fra starten at definere godkendte værktøjer, klare datagrænser, forventninger til gennemgang, omkostningskontroller og reservemønstre.

Jeg ville heller ikke pålægge alle at bruge ét bestemt værktøj eller én bestemt arbejdsgang for tidligt. Teknologien ændrer sig for hurtigt. Den bedre tilgang er at tilbyde sikker adgang, genanvendelige sikkerhedsrammer, muligheder for læring blandt kolleger og tydeligt ansvar. En ingeniør har stadig ansvaret for det, vedkommende designer, gennemgår, sammenlægger og driver i produktion.

Hvorfor AI bør behandles som en ændring af driftsmodellen

Mit råd til CTO'er er at betragte AI som en ændring af driftsmodellen, ikke som en udrulning af et værktøj. Begynd med et lille antal arbejdsgange med høj værdi, hvor I kan etablere et udgangspunkt, måle effekten og lære hurtigt. Opbyg en fælles AI-platform og en leveringsdisciplin omkring godkendte modeller, sikker dataadgang, evaluering, observerbarhed og genanvendelige integrationsmønstre, og hold arkitekturen uafhængig af både sky og model. Det forhindrer hvert team i at genopfinde de samme kontroller eller blive låst fast til en udbyder for tidligt.

Lige så vigtigt er det at investere i mennesker. De organisationer, der får mest ud af det, er ikke dem, der blot genererer mere kode. Det bliver dem, der hjælper ingeniører, produktteams, sikkerhedspartnere og forretningsledere med at lære at formulere arbejdet klart, validere AI-resultater og drive agentbaserede systemer inden for fastlagte grænser. Bevæg jer hurtigt, men gør tillid, kvalitet, sikkerhed og målbare resultater ufravigelige.

AI er ved at blive et centralt udførelseslag for virksomheden, så CTO'ens rolle er at skabe den arkitektur, styring og kultur, der gør det muligt at skalere ansvarligt.

Følg med

Du kan følge Manish Jains arbejde på hans Substack og LinkedIn.

Der kommer flere ekspertinterviews på The CTO Club!