AWS’ globale leder for løsningsarkitektur deler sin modell for AI-ledet modernisering

Saurabh Shrivastava er global leder for løsningsarkitektur og fremoverlent utvikling i Amazon Web Services, der han fokuserer på agentbasert kunstig intelligens og modernisering av virksomheter.

Vi satte oss ned med Saurabh for å lære mer om de nye utviklingsmodellene han bruker i arbeidet sitt hos AWS. Her er det han delte.

Ansvarlig industrialisering av kunstig intelligens

Jeg er leder innen teknologi- og AI-transformasjon, med over 20 års erfaring med å hjelpe virksomheter med å gjøre komplekse teknologiske endringer om til skalerbare forretningsresultater. Karrieren min har ført meg gjennom utvikling, virksomhetsarkitektur, produktorientert feltutvikling, skytjenestetransformasjon og nå agentbasert kunstig intelligens og programvarefabrikkmodeller i AWS.

Tidligere i karrieren bygget og ledet jeg storskalaplattformer for virksomheter innen telekommunikasjon, detaljhandel, forsyningskjeder, fintech og forskning og utvikling. Det ga meg en sterk forståelse for systemtenkning, pålitelighet, integrasjonskompleksitet og realitetene ved å drifte teknologi i virksomheter av stor skala.

I AWS ble rollen min utvidet fra å hjelpe kunder med å modernisere infrastruktur og applikasjoner til å lede globale initiativer innen løsningsarkitektur og fremoverlent utvikling med fokus på kunstig intelligens, modernisering og agentbaserte plattformer. Jeg har samarbeidet med ledere i virksomheter, partnere, produktteam og utviklingsteam for å gå fra strategi og eksperimentering til styrte, produksjonsklare plattformer.

Kunstig intelligens er ikke lenger bare en ny teknologibølge. Den endrer hvordan organisasjoner utvikler programvare, hvordan ansatte arbeider, hvordan kunder samhandler, og hvordan teknologiorganisasjoner må fungere. Den reelle lederutfordringen handler ikke bare om å velge modeller eller verktøy. Det handler om å etablere driftsmodell, arkitektur, styring, kompetanse og produktdisiplin for å industrialisere kunstig intelligens på en ansvarlig måte.

Ledelse av AWS' løsningsarkitektur

Som global leder for løsningsarkitektur og FDE leder jeg AWS' globale organisasjon for løsningsarkitektur og fremoverlent utvikling, med fokus på agentbaserte AI-plattformer, modernisering av virksomheter og skalerbar skytjenestetransformasjon.

Organisasjonen opererer i stor skala og samarbeider med store globale kunder, strategiske partnere, produktteam, spesialiserte utviklingsteam og regionale feltorganisasjoner. Arkitekturomfanget er bredt: AI/ML-plattformer, agentbaserte arbeidsflyter, grunnlag for data og analyse, modernisering av applikasjoner, skybasert infrastruktur, sikkerhet, styring og partnerintegrerte løsninger.

Jeg leder, muliggjør og påvirker mer enn 200 spesialister, partnerutviklere og teknologiledere i felt globalt. Arbeidet er svært komplekst fordi vi ikke bygger isolerte demonstrasjoner. Vi hjelper virksomheter med å gå fra tidlige AI-idéer og forretningssaker for modernisering til repeterbare, sikre og produksjonsklare plattformer som kan skaleres på tvers av forretningsenheter, markeder og kundemiljøer.

Distribusjonsmodellen vår kombinerer fremoverlent utvikling, globale plattformmekanismer, partnerledet levering og tilbakemeldingssløyfer mellom produkt- og feltorganisasjonen. Teamet mitt bygger gjenbrukbare maler, referansearkitekturer, lederdemonstrasjoner, tekniske veiledninger, styringsmønstre og komponerbare løsningsmodeller som fremskynder innføringen, samtidig som kvalitet, sikkerhet og operasjonell disiplin opprettholdes.

Hvorfor en modell for fremoverlent utvikling er avgjørende med kunstig intelligens

Jeg introduserte en modell for fremoverlent utvikling for AI-ledet modernisering i fjor.

I skyæraen hadde vi gjenbrukbare referansearkitekturer, løsningsmaler, distribusjonsmønstre og kontrollpunkter for styring. Disse var nødvendige, men utilstrekkelige med kunstig intelligens. Kundene hadde fortsatt problemer med å gå fra POC til produksjon fordi det vanskeligste arbeidet foregikk i deres faktiske miljø: data, applikasjonsportefølje, kodekompleksitet, sikkerhetsbegrensninger og driftsmodell.

Derfor introduserte jeg en FDE-mekanisme som plasserer utviklere mye nærmere kundens faktiske arbeidsbelastninger. I stedet for å gi råd utenfra arbeider FDE-teamet med kundens data, kode, arkitektur og leveranseteam for å identifisere kandidater for modernisering, bygge nyttige ressurser og flytte den første arbeidsbelastningen til produksjon.

Jeg introduserte også en enkel 3-3-3-modell: 3 dager til kartlegging, 3 uker til vurdering og 3 måneder til å flytte den første arbeidsbelastningen til produksjon. Dette ga ledere en tydelig vei fra AI-ambisjon til målbar verdi.

Effekten var betydelig. Kundene kunne fremskynde moderniseringsreisen med 2x til 4x, redusere kostnadene med opptil halvparten og gå videre fra demonstrasjoner til realisert ROI. Enda viktigere var det at dette endret samtalen på ledernivå. Kunstig intelligens var ikke lenger et sideeksperiment; det ble en praktisk mekanisme for å modernisere faktiske arbeidsbelastninger, forbedre utviklingsproduktiviteten og skape målbar forretningsverdi.

Slik moderniserer du raskere uten å miste tilliten

Jeg bruker AI i stor grad for å fremskynde teknisk forståelse, mønstergjenkjenning og utviklingskapasitet, men jeg delegerer ikke ansvaret til AI.

I komplekse virksomheter bygger forretningen ofte på flere tiår med kode, teknisk gjeld, udokumenterte avhengigheter og innebygde forretningsregler. I dette miljøet trenger vi både deterministiske og probabilistiske tilnærminger. Du kan ikke stole utelukkende på probabilistisk AI-oppdagelse når du prøver å forstå virksomhetskritiske systemer.

For kodeoppdagelse, uttrekking av forretningsregler, avhengighetsanalyse, funksjonskartlegging og vurdering av nåsituasjonen foretrekker jeg en mer deterministisk tilnærming. Vi trenger sporbarhet, repeterbarhet, dokumentasjon og tillit til hva systemet gjør. AI kan bidra ved å oppsummere, gruppere og fremskynde analysen, men grunnlaget må være etterprøvbare fakta fra kode, logger, dataflyter, kjøretidsatferd og arkitekturdokumentasjon.

AI blir kraftigere i arbeid med fremtidige tilstander: generering av alternativer for modernisering, forslag til nye arkitekturer, definering av tjenestegrenser, utvikling av migreringsmønstre, skriving av kode, generering av tester og raskere implementering. Denne delen kan være mer probabilistisk fordi AI kan utforske alternativer og forbedre utviklingshastigheten.

Men selv her forblir den endelige beslutningen menneskelig. Ansvarlige utviklere og ledere må validere arkitekturvalg, sikkerhetsnivå, produksjonsberedskap, etterlevelsesrisiko, kundepåvirkning og avveininger knyttet til investeringer.

Modellen min er derfor: deterministisk oppdagelse, AI-akselerert design og implementering samt menneskestyrt validering. Denne kombinasjonen gjør at vi kan modernisere raskere uten å miste tillit, kontroll eller virksomhetens ansvarlighet.

Ulempene ved AI i utviklingsarbeidsflyter

Saurabh deler

Kostnad er ikke den eneste ulempen (ved AI). AI kan også skape falsk trygghet hvis team bruker det uten styring.

Det viktigste positive resultatet var at AI forkortet veien fra oppdagelse til produksjon betydelig når det ble integrert i en disiplinert utviklingsarbeidsflyt.

AI satte også fart på kodeforståelse, uttrekking av forretningsregler, avhengighetsanalyse, testgenerering, dokumentasjon og planlegging av modernisering. Det reduserte tiden som gikk med til manuell analyse, og hjalp utviklingsteamene med å fokusere mer på arkitekturbeslutninger, validering og produksjonsberedskap.

Men AI kan bli svært kostbart svært raskt hvis team ikke planlegger for økonomien i inferens. I store virksomheter med millioner av brukere kan tokenkostnader for avanserte modeller komme opp i millioner av dollar hvis hver interaksjon avhenger av eksterne tredjeparts grunnmodeller uten optimalisering.

En lærdom er at AI-arkitekturen må inkludere kostnadsarkitektur. For enkelte arbeidsbelastninger bør virksomheter vurdere inferens driftet selv eller i skyen ved hjelp av GPU-er eller akseleratorer, inkludert alternativer som vLLM på skyinfrastruktur. Dette gir større kontroll over kostnad, forsinkelse, datagrenser og strategi for modellkjøring. Teknikker som KV-bufring, kontinuerlig batching, kvantisering og kjerneoptimalisering kan forbedre GPU-utnyttelsen betydelig og redusere inferenskostnaden.

Kostnad er ikke den eneste ulempen. AI kan også skape falsk trygghet hvis team bruker det uten styring. Risikoene omfatter ufullstendig kodeforståelse, hallusinerte avhengigheter, mangelfull testdekning, sikkerhetshull og at team beveger seg for raskt fra prototype til produksjon.

Hvorfor AI sliter med ende-til-ende-modernisering av eldre systemer

AI har hatt størst problemer når team ber det ta tekniske beslutninger uten tilstrekkelig systemkontekst.

Et vanlig eksempel er modernisering av eldre systemer. KI kan oppsummere kode, generere ideer til migrering og til og med produsere ny kode raskt. Men i store virksomheter strekker den reelle kompleksiteten seg utover selve koden. Den omfatter tiår med forretningsregler, udokumenterte integrasjoner, batchjobber, dataavhengigheter, operasjonelle unntak, sikkerhetsbegrensninger og organisatorisk eierskap. Hvis du ber KI modernisere dette miljøet med bare et delvis bilde, kan den produsere selvsikre, men ufullstendige svar.

Produksjonsklarhet er et annet område der den har utfordringer. KI kan lage prototyper svært raskt, men mange prototyper blir ikke automatisk til sikre, observerbare, robuste og kostnadseffektive produksjonssystemer. Team undervurderer noen ganger arbeidet som kreves for testing, styring, håndtering av hendelser, overvåking, modelevaluering, datakvalitet og livssyklusforvaltning.

Hvordan ingeniører kan forbedre produkter samtidig som de har kontroll over inferenskostnader og pålitelighet

Her er et eksempel fra en stor plattform for medie- og markedsføringsinnholdsproduksjon, der KI hjelper brukere med å gå fra hensikt til ferdige digitale ressurser i stor virksomhetsskala.

Arbeidsflyten starter når en bruker beskriver hva de ønsker å lage: en kampanje for en produktlansering, kreativt innhold for sosiale medier, en salgspresentasjon, et videoklipp eller et lokalisert markedsføringsmateriale. KI tolker brukerens hensikt, inkludert målgruppe, format, tone, merkevareretningslinjer, nødvendige ressurser, kanalbegrensninger og krav til etterlevelse.

Derfra bruker plattformen en agentbasert arbeidsflyt. Én agent henter maler, logoer, skrifttyper, farger og kampanjeressurser som er godkjent for merkevaren. En annen genererer tekst og kreative varianter. En tredje foreslår oppsett. En annen kontrollerer merkevareetterlevelse, tilgjengelighet, retningslinjer og innholdssikkerhet. Et siste orkestreringslag setter sammen resultatet til redigerbare ressurser og sender det gjennom arbeidsflyter for godkjenning eller publisering.

I denne skalaen møtte ingeniørteamet utfordringer knyttet ikke bare til modellkvalitet, men også til inferensøkonomi, forsinkelse, pålitelighet og styring. Teamet optimaliserte et inferensmiljø i svært stor skala med støtte for omtrent 10 000 beregningsnoder og rundt 80 000 GPU-er. Arkitekturen kombinerte GPU-kapasitet fra flere nettskyleverandører og godkjente tredjeparter, og koblet disse miljøene sammen gjennom et hybridnettverkslag. Det ga plattformen fleksibilitet til å plassere arbeidsbelastninger basert på kostnad, forsinkelse, tilgjengelighet og datalokasjon.

Teamet innførte også en mer disiplinert strategi for modellbetjening. I stedet for å sende alle forespørsler til den dyreste og mest avanserte modellen, fordelte plattformen forespørslene på modeller som var egnet til formålet, inkludert åpne modeller som Kimi og Qwen, levert gjennom optimaliserte kjøremiljøer som vLLM og Ollama-lignende mønstre. Teamet benyttet også teknikker for optimalisering av inferens, blant annet KV-bufring, kontinuerlig batching, kvantisering, minneoptimalisering og justering på kjernenivå, for å forbedre GPU-utnyttelsen og redusere kostnadene.

Mennesker beholdt kontrollen på de viktigste vurderingspunktene. KI genererte alternativer, anbefalte oppsett, skrev tekst og effektiviserte produksjonen, men brukeren eller merkevareeieren godkjente den endelige ressursen. Ingeniørteamene hadde ansvar for sikkerhetsmekanismene: sikkerhet, datatilgang, modellvalg, observerbarhet, forsinkelse, kostnadskontroller, sikkerhetskontroller og tilbakemeldingssløyfer.

Resultatet var en KI-arbeidsflyt som ble en del av produktopplevelsen, ikke bare et internt produktivitetsverktøy. Den reduserte tiden fra idé til ressurs, forbedret personaliseringen, økte gjenbruken av godkjente merkevarekomponenter og skapte en tilbakemeldingssløyfe der brukerredigeringer og engasjementsdata forbedret fremtidige anbefalinger. Samtidig ga arkitekturen virksomheten langt bedre kontroll over inferenskostnader, pålitelighet og styring.

Hvorfor utrulling av KI krever en produktorientert tankegang

Utrulling av KI-verktøy handler i mindre grad om å ta i bruk verktøy og i større grad om å endre ingeniørenes arbeidsmodell.

I utgangspunktet tror mange organisasjoner at utfordringen er å gi ingeniører tilgang til programmeringsassistenter, kodeassistenter, modell-API-er eller interne KI-plattformer. Det hjelper, men det er ikke nok. Uten tydelige mønstre bruker teamene KI på inkonsekvente måter. Noen bruker det bare til kodegenerering. Noen bruker det til dokumentasjon. Noen stoler for mye på det. Andre unngår det fordi de er usikre på risiko knyttet til sikkerhet, immaterielle rettigheter eller kvalitet.

Hvis jeg skulle begynt på nytt, ville jeg definert KI-arbeidsflyten for ingeniørarbeid enda tidligere: hvor KI bør og ikke bør brukes, hvilken dokumentasjon som kreves, hva mennesker må gjennomgå, og hvordan resultatet testes, sikres og settes i produksjon.

Dette ville ha unngått noen problemer. For det første kunne vi ha redusert inkonsekvent bruk på tvers av team. For det andre kunne vi ha unngått feilplassert tillit til KI-generert kode eller analyse som så riktig ut, men manglet tilstrekkelig kontekst. For det tredje kunne vi ha fått kontroll på kostnadene tidligere ved å implementere modellruting, tokenbudsjettering, hurtigbufring og styring av inferens fra starten av. For det fjerde kunne vi ha opprettet bedre gjenbrukbare mønstre i stedet for å la hvert team finne opp sin egen tilnærming.

Den viktigste lærdommen er at utrulling av KI krever et produkt- og plattformtankesett. Du trenger tilrettelegging, sikkerhetsmekanismer, observerbarhet, kostnadskontroller, sikkerhetsgjennomgang, gjenbrukbare ledetekster og agenter, evalueringsmønstre og tydelig menneskelig ansvar. Ellers øker KI aktiviteten uten alltid å øke ingeniørkvaliteten eller forretningsverdien.

Hvorfor SDLC må bli til AI-DLC

Saurabh deler

CTO-er bør aktivt redesigne selve programvareleveransens livssyklus.

CTO-er bør aktivt redesigne selve programvareleveransens livssyklus. Jeg ser på dette som en overgang fra tradisjonell SDLC til AI-DLC, en KI-forsterket leveranselivssyklus for den agentbaserte KI-æraen.

I tradisjonell SDLC følger vi ofte lineære faser: krav, design, utvikling, utrulling og brukerstøtte. Dette fungerte rimelig godt da hovedmålet var å bygge deterministisk programvare gjennom strukturerte overleveringer. Men med KI, særlig agentbasert KI, blir livssyklusen mer iterativ og komprimert.

Jeg forenkler AI-DLC til tre hovedfaser: oppstart, konstruksjon og drift.

• I oppstartsfasen hjelper KI med kartlegging, kodeforståelse, uttrekking av forretningsregler, avhengighetsanalyse, avklaringer av krav, identifisering av risiko og planlegging av måltilstanden.
• I konstruksjonsfasen bistår KI med arkitekturalternativer, oppdeling av tjenester, generering av kode og tester, dokumentasjon, sikkerhetsgjennomganger, infrastrukturmønstre og gjennomføring av modernisering.
• I driftsfasen støtter KI observerbarhet, hendelsesanalyse, tilbakemeldingssløyfer, modelevaluering, kostnadsoptimalisering, styring og kontinuerlig forbedring.

Det viktige poenget er at AI-DLC ikke bare er SDLC med en kodeassistent lagt til. Det er en redesignet operativ modell for ingeniørarbeid. Den integrerer KI-agenter, deterministisk kartlegging, menneskelig validering, sikkerhetskontroller, produksjonsberedskap og kostnadsstyring i én samlet arbeidsflyt.

Hvordan ingeniørteam endrer seg på grunn av KI

KI har flyttet ingeniørteam fra rollebasert, sekvensiell gjennomføring mot mer integrerte team med fokus på resultater.

Tidligere organiserte vi oss rundt tydelig adskilte roller: arkitekter, applikasjonsingeniører, dataingeniører, DevOps, sikkerhet, kvalitetssikring og drift. Disse rollene er fortsatt viktige, men KI komprimerer livssyklusen og reduserer verdien av lange overleveringer. De best presterende teamene er mer tverrfunksjonelle og nærmere forretningsproblemet.

For KI-ledet modernisering og produktutvikling ser jeg nå etter team som kombinerer flere ferdigheter: et sterkt fundament innen programvareutvikling, sky- og plattformutvikling, KI-kompetanse, sikkerhetsbevissthet, produktforståelse og operasjonelt skjønn. Jeg verdsetter også ingeniører som arbeider i tvetydige miljøer, resonnerer ut fra førsteprinsipper og validerer KI-resultater i stedet for å akseptere dem blindt.

Modellen med fremoverplasserte ingeniører er et godt eksempel. I stedet for å holde arkitektur, KI-utvikling, DevOps og sikkerhet i separate, sekvensielle spor, bringer vi disse ferdighetene nærmere kunden eller forretningsmiljøet. Teamet arbeider med reell kode, reelle data, faktiske begrensninger og konkrete suksessmålinger.

Ansettelser har også endret seg. Jeg legger fortsatt stor vekt på teknisk dybde, men ser også etter systemtenkere: personer som forstår arkitektur, bruker KI på en ansvarlig måte, kommuniserer med interessenter i virksomheten og tar ansvar for resultater i produksjon. I KI-æraen er de beste ingeniørene ikke bare kodeprodusenter. De er problemdefinere, validatorer og utviklere av systemer som kan gjentas.

Slik måler du KI-effektivitet

Ett spørsmål jeg skulle ønske flere stilte, er: Hvordan bør CTO-er måle om AI skaper varig verdi for virksomheten?

CTO-er bør ikke måle AI bare ut fra antallet piloter eller copiloter som er tatt i bruk, eller modellnøyaktighet isolert sett. Dette er nyttige signaler, men de beviser ikke transformasjon.

CTO-er bør måle AI langs fire dimensjoner:

1. Produktivitet i utvikling: Reduserer AI gjennomløpstiden, forbedrer kodekvaliteten, øker testdekningen, fremskynder modernisering og reduserer teknisk gjeld?
2. Forretningspåvirkning: Forbedrer AI kundeopplevelsen, de ansattes produktivitet, inntektskonverteringen, kostnadseffektiviteten eller tiden det tar å komme på markedet?
3. Modenhet i produksjon: Er AI-systemene sikre, observerbare, pålitelige, styrte og kostnadskontrollerte? Har de tydelig menneskelig ansvar og klare krav for produksjonsberedskap?
4. Gjenbrukbarhet og skalerbarhet: Bygger teamene gjenbrukbare AI-tjenester, agenter, ledetekster, mønstre, dataprodukter og plattformfunksjoner, eller lager de isolerte demonstrasjoner?

Dette er viktig fordi AI kan skape mye synlig aktivitet uten å skape varig verdi. CTO-er må omgjøre AI-aktivitet til repeterbar kapasitet. Det innebærer å knytte sammen strategi, arkitektur, driftsmodell, styring og økonomi.

Hvorfor CTO-er må skille eksperimentering fra industrialisering

Her er mine råd.

For det første må du ikke behandle AI som et sideeksperiment. Betrakt det som et nytt driftslag for virksomheten. AI vil påvirke hvordan programvare bygges, hvordan de ansatte arbeider, hvordan kundene samhandler, og hvordan beslutninger tas. CTO-ens oppgave er å flytte organisasjonen fra spredte piloter til en styrt og skalerbar AI-plattformstrategi.

For det andre må du skille eksperimentering fra industrialisering. Det er helt greit å eksperimentere raskt, men AI i produksjon trenger arkitektur, sikkerhet, datastyring, evaluering, observerbarhet, kostnadskontroll og tydelig menneskelig ansvar. Mange selskaper står fast fordi de har mange demonstrasjoner, men ingen repeterbar vei til produksjon. CTO-er må bygge denne veien.

For det tredje bør du fokusere på forretningsverdi, ikke på hvor ny modellen er. De vinnende organisasjonene vil ikke være de som ganske enkelt bruker den nyeste modellen. Det vil være de som integrerer AI i reelle arbeidsflyter, moderniserer teknologigrunnlaget, forbedrer produktiviteten i utviklingen og måler resultater som gjennomløpstid, kostnadseffektivitet, kundeopplevelse, inntektsvirkning og risikoreduksjon.

Og for det fjerde er mitt praktiske råd å etablere en AI-plattform og en modell for fremadrettet utrulling av ingeniørressurser samtidig. Plattformen gir gjenbruk, styring og skala. FDE-modellen bringer AI inn i reelle kunde- og arbeidsbelastninger i virksomheten, ved hjelp av reelle data, reell kode og reelle begrensninger. Slik kan CTO-er gå fra AI-ambisjoner til realisert avkastning på investeringen.

Følg med

Følg arbeidet til Saurabh Shrivastava på LinkedIn og på hans Amazon-forfatterside.

Flere ekspertintervjuer kommer på The CTO Club!