AWS globala chef för lösningsarkitektur delar sin modell för AI-ledd modernisering

Saurabh Shrivastava är global chef för lösningsarkitektur och kundnära ingenjörsutveckling på Amazon Web Services, där han fokuserar på agentisk AI och modernisering av företag.

Vi satte oss ner med Saurabh för att lära oss mer om de nya ingenjörsmodeller som han använder i sitt arbete på AWS. Här är vad han berättade.

Att industrialisera AI på ett ansvarsfullt sätt

Jag är ledare inom teknik och AI-transformation med över 20 års erfarenhet av att hjälpa företag omvandla komplexa teknikskiften till skalbara affärsresultat. Min resa har tagit mig genom ingenjörsarbete, företagsarkitektur, produktinriktad fältteknik, molntransformation och nu agentisk AI samt modeller för programvarufabriker på AWS.

Tidigare i min karriär byggde och ledde jag storskaliga företagsplattformar inom telekom, detaljhandel, leveranskedjor, fintech och forsknings- och utvecklingsmiljöer. Det gav mig en stark förståelse för systemtänkande, tillförlitlighet, integrationskomplexitet och verkligheten i att driva teknik i företagsskala.

På AWS utökades min roll från att hjälpa kunder att modernisera infrastruktur och applikationer till att leda globala lösningsarkitektur- och kundnära ingenjörsinitiativ med fokus på AI, modernisering och agentiska plattformar. Jag har arbetat med företagsledare, partner, produktteam och ingenjörsteam för att gå från strategi och experimenterande till styrda, produktionsklara plattformar.

AI är inte längre bara ännu en teknisk våg. Den förändrar hur organisationer utvecklar programvara, hur medarbetare arbetar, hur kunder interagerar och hur teknikorganisationer måste fungera. Den verkliga ledarskapsutmaningen handlar inte bara om att välja modeller eller verktyg. Det handlar om att skapa den verksamhetsmodell, arkitektur, styrning, kompetens och produktdisciplin som krävs för att industrialisera AI på ett ansvarsfullt sätt.

Att leda AWS:s lösningsarkitektur

Som global chef för lösningsarkitektur och FDE leder jag AWS:s globala organisation för lösningsarkitektur och kundnära ingenjörsutveckling med fokus på agentiska AI-plattformar, modernisering av företag och molntransformation i produktionsskala.

Organisationen arbetar i företagsskala med stora globala kunder, strategiska partner, produktteam, specialiserade ingenjörsteam och regionala fältorganisationer. Arkitekturområdet är omfattande: AI/ML-plattformar, agentiska arbetsflöden, grunder för data och analys, modernisering av applikationer, molnbaserad infrastruktur, säkerhet, styrning och partnerintegrerade lösningar.

Jag leder, möjliggör och påverkar arbetet för fler än 200 specialister, partneringenjörer och tekniska fältledare globalt. Arbetet är mycket komplext eftersom vi inte bygger isolerade demonstrationer. Vi hjälper företag att gå från tidiga AI-idéer och affärsfall för modernisering till repeterbara, säkra och produktionsklara plattformar som kan skalas över affärsenheter, marknader och kundmiljöer.

Vår implementeringsmodell kombinerar kundnära ingenjörsutveckling, globala plattformsmekanismer, partnerledd leverans och återkopplingsloopar mellan produkt- och fältorganisationer. Mitt team bygger återanvändbara ritningar, referensarkitekturer, presentationer för ledningsgrupper, tekniska handböcker, styrningsmönster och komponerbara lösningsmodeller som påskyndar införandet samtidigt som kvalitet, säkerhet och operativ disciplin upprätthålls.

Varför en modell för kundnära ingenjörsutveckling är avgörande med AI

Jag införde en modell för kundnära ingenjörsutveckling för AI-driven modernisering förra året.

Under molneran hade vi återanvändbara referensarkitekturer, lösningsritningar, implementeringsmönster och kontrollpunkter för styrning. Dessa var nödvändiga, men otillräckliga med AI. Kunder hade fortfarande svårt att gå från POC till produktion eftersom det svåraste arbetet ägde rum i deras faktiska miljö: data, applikationslandskap, kodkomplexitet, säkerhetsbegränsningar och verksamhetsmodell.

Därför införde jag en FDE-mekanism som placerar ingenjörer mycket närmare kundens verkliga arbetsbelastningar. I stället för att ge råd utifrån arbetar FDE-teamet med kundens data, kod, arkitektur och leveransteam för att identifiera kandidater för modernisering, bygga användbara tillgångar och flytta den första arbetsbelastningen till produktion.

Jag införde också en enkel 3-3-3-modell: 3 dagar för upptäckt, 3 veckor för bedömning och 3 månader för att flytta den första arbetsbelastningen till produktion. Det gav ledningsgrupperna en tydlig väg från AI-ambition till mätbart värde.

Effekten var betydande. Kunderna kunde påskynda sin moderniseringsresa 2 till 4 gånger, minska kostnaderna med upp till hälften och gå bortom demonstrationer till realiserad avkastning på investeringen. Ännu viktigare var att det förändrade samtalet på ledningsnivå. AI var inte längre ett sidoexperiment; det blev en praktisk mekanism för att modernisera verkliga arbetsbelastningar, förbättra ingenjörernas produktivitet och skapa mätbart affärsvärde.

Så moderniserar du snabbare utan att förlora förtroendet

Jag använder AI i stor utsträckning för att påskynda teknisk förståelse, mönsterigenkänning och utvecklingskapacitet, men jag delegerar inte ansvaret till AI.

I komplexa företag bygger verksamheten ofta på årtionden av kod, teknisk skuld, odokumenterade beroenden och inbäddade affärsregler. I den miljön behöver vi både deterministiska och probabilistiska metoder. Man kan inte enbart förlita sig på probabilistisk AI-identifiering när man försöker förstå verksamhetskritiska system.

För kodidentifiering, extrahering av affärsregler, beroendeanalys, funktionskartläggning och bedömning av nuläget föredrar jag en mer deterministisk metod. Vi behöver spårbarhet, repeterbarhet, bevis och förtroende för vad systemet gör. AI kan hjälpa till genom att sammanfatta, gruppera och påskynda analysen, men grunden måste bestå av verifierbara fakta från kod, loggar, dataflöden, körningsbeteende och arkitektoniska bevis.

AI blir kraftfullare i arbetet med framtida lägen: genom att generera alternativ för modernisering, föreslå nya arkitekturer, definiera tjänstegränser, utveckla migreringsmönster, skriva kod, generera tester och påskynda implementeringen. Den delen kan vara mer probabilistisk eftersom AI kan utforska alternativ och förbättra utvecklingstakten.

Men även där förblir det slutliga beslutet mänskligt. Ansvariga ingenjörer och ledare måste validera arkitekturval, säkerhetsnivå, produktionsberedskap, efterlevnadsrisk, kundpåverkan och avvägningar kring investeringar.

Min modell är alltså: deterministisk identifiering, AI-accelererad design och implementering samt mänskligt styrd validering. Den kombinationen gör att vi kan modernisera snabbare utan att förlora förtroende, kontroll eller företagsansvar.

Nackdelarna med AI i tekniska arbetsflöden

Saurabh delar med sig

Kostnaden är inte den enda nackdelen med AI. AI kan också skapa falsk trygghet om team använder det utan styrning.

Det största positiva resultatet var att AI avsevärt förkortade vägen från identifiering till produktion när det integrerades i ett disciplinerat tekniskt arbetsflöde.

AI påskyndade också kodförståelse, extrahering av affärsregler, beroendeanalys, testgenerering, dokumentation och planering av modernisering. Det minskade tiden för manuellt analysarbete och hjälpte tekniska team att fokusera mer på arkitekturbeslut, validering och produktionsberedskap.

Men AI kan bli mycket dyrt mycket snabbt om team inte planerar för inferensekonomi. I stora företag med miljontals användare kan kostnaderna för token i avancerade modeller uppgå till miljoner dollar om varje interaktion är beroende av externa tredjepartsmodeller utan optimering.

En lärdom är att AI-arkitekturen måste omfatta en kostnadsarkitektur. För vissa arbetsbelastningar bör företag utvärdera egen drift eller molnbaserad inferens med hjälp av GPU:er eller acceleratorer, inklusive alternativ som vLLM på molninfrastruktur. Det ger större kontroll över kostnad, fördröjning, datagränser och strategi för modelldrift. Tekniker som KV-cachning, kontinuerlig batchbearbetning, kvantisering och kärnoptimering kan förbättra GPU-utnyttjandet avsevärt och minska inferenskostnaden.

Kostnaden är inte den enda nackdelen. AI kan också skapa falsk trygghet om team använder det utan styrning. Riskerna omfattar bristande kodförståelse, påhittade beroenden, otillräcklig testtäckning, säkerhetsluckor och att team går för snabbt från prototyp till produktion.

Varför AI har svårt med heltäckande modernisering av äldre system

AI har haft störst svårigheter när team ber det fatta tekniska beslut utan tillräckligt med systemkontext.

Ett vanligt exempel är modernisering av äldre system. AI kan sammanfatta kod, ta fram migreringsidéer och till och med snabbt producera ny kod. Men i stora företag sträcker sig den verkliga komplexiteten bortom koden. Den omfattar årtionden av affärsregler, odokumenterade integrationer, batchjobb, databeroenden, operativa undantag, säkerhetsbegränsningar och organisatoriskt ägarskap. Om du ber AI att modernisera den miljön med endast en begränsad överblick kan den ge självsäkra men ofullständiga svar.

Produktionsberedskap är ett annat område där den har svårt att räcka till. AI kan skapa prototyper mycket snabbt, men många prototyper blir inte automatiskt säkra, observerbara, motståndskraftiga och kostnadseffektiva produktionssystem. Team underskattar ibland det arbete som krävs för testning, styrning, incidenthantering, övervakning, modellevaluering, datakvalitet och livscykelhantering.

Hur ingenjörer kan förbättra produkter samtidigt som inferenskostnader och tillförlitlighet hanteras

Här är ett exempel från en stor plattform för medie- och marknadsföringsinnehåll, där AI hjälper användare att gå från avsikt till färdiga digitala tillgångar i företagsskala.

Arbetsflödet börjar när en användare beskriver vad de vill skapa: en kampanj för en produktlansering, kreativt innehåll för sociala medier, en sälj­presentation, ett videoklipp eller ett lokaliserat marknadsföringsmaterial. AI tolkar användarens avsikt, inklusive målgrupp, format, ton, varumärkesriktlinjer, nödvändiga tillgångar, kanalbegränsningar och efterlevnadskrav.

Därefter använder plattformen ett agentbaserat arbetsflöde. En agent hämtar varumärkesgodkända mallar, logotyper, teckensnitt, färger och kampanjtillgångar. En annan genererar texter och kreativa variationer. En tredje föreslår layouter. En annan kontrollerar efterlevnad av varumärket, tillgänglighet, policyer och innehållssäkerhet. Ett slutligt orkestreringslager sammanställer resultatet till redigerbara tillgångar och skickar det vidare genom arbetsflöden för godkännande eller publicering.

I den här skalan mötte ingenjörerna utmaningar som inte bara handlade om modellkvalitet utan även om inferensekonomi, svarstid, tillförlitlighet och styrning. Teamet optimerade en inferensmiljö i mycket stor skala som stödde ungefär 10 000 beräkningsnoder och omkring 80 000 GPU:er. Arkitekturen kombinerade GPU-kapacitet från flera molnleverantörer och godkända tredjartsleverantörer och kopplade samman dessa miljöer genom ett hybridnätverkslager. Det gav plattformen flexibilitet att placera arbetsbelastningar utifrån kostnad, svarstid, tillgänglighet och datalokalisering.

Teamet införde också en mer disciplinerad strategi för modellservering. I stället för att skicka varje begäran till den dyraste frontmodellen dirigerade plattformen förfrågningar till modeller som var lämpliga för ändamålet, inklusive öppna modeller som Kimi och Qwen, som kördes genom optimerade körmiljöer som vLLM och mönster av Ollama-typ. Teamet tillämpade även inferensoptimeringstekniker, inklusive KV-cachelagring, kontinuerlig batchbearbetning, kvantisering, minnesoptimering och finjustering på kärnnivå, för att förbättra GPU-utnyttjandet och minska kostnaderna.

Människor behöll kontrollen vid de avgörande bedömningspunkterna. AI genererade alternativ, rekommenderade layouter, skrev texter och effektiviserade produktionen, men användaren eller varumärkesägaren godkände den slutliga tillgången. Ingenjörsteamen ansvarade för skyddsräckena: säkerhet, dataåtkomst, modellval, observerbarhet, svarstid, kostnadskontroller, säkerhetskontroller och återkopplingsloopar.

Resultatet blev ett AI-arbetsflöde som blev en del av produktopplevelsen, inte bara ett internt produktivitetsverktyg. Det minskade tiden från idé till tillgång, förbättrade personaliseringen, ökade återanvändningen av godkända varumärkeskomponenter och skapade en återkopplingsloop där användarredigeringar och engagemangsdata förbättrade framtida rekommendationer. Samtidigt gav arkitekturen verksamheten betydligt bättre kontroll över inferenskostnad, tillförlitlighet och styrning.

Varför utrullningar av AI kräver ett produktorienterat tänkesätt

Att rulla ut AI-verktyg handlar mindre om att införa verktyg och mer om att förändra ingenjörernas operativa modell.

Inledningsvis tror många organisationer att utmaningen består i att ge ingenjörer tillgång till copiloter, kodningsassistenter, modell-API:er eller interna AI-plattformar. Det hjälper, men det räcker inte. Utan tydliga arbetssätt använder team AI på ett inkonsekvent sätt. Vissa använder det bara för kodgenerering. Andra använder det för dokumentation. Vissa litar för mycket på det. Andra undviker det eftersom de är osäkra på riskerna kring säkerhet, immateriella rättigheter eller kvalitet.

Om jag skulle börja om skulle jag definiera AI-arbetsflödet för ingenjörsarbetet ännu tidigare: var AI bör och inte bör användas, vilka bevis som krävs, vad människor måste granska och hur resultat testas, säkras och befordras till produktion.

Det här skulle ha undvikit några problem. För det första kunde vi ha minskat den inkonsekventa användningen mellan teamen. För det andra kunde vi ha undvikit en felplacerad tilltro till AI-genererad kod eller analys som såg korrekt ut men saknade tillräcklig kontext. För det tredje kunde vi ha hållit kostnaderna under kontroll tidigare genom att införa modellrouting, tokenbudgetering, cachning och styrning av inferens från början. För det fjärde kunde vi ha skapat bättre återanvändbara mönster i stället för att låta varje team uppfinna sitt eget tillvägagångssätt.

Den viktigaste lärdomen är att utrullning av AI kräver ett produkt- och plattformsperspektiv. Man behöver aktivering, skyddsräcken, observerbarhet, kostnadskontroller, säkerhetsgranskning, återanvändbara prompter och agenter, utvärderingsmönster samt tydligt mänskligt ansvar. Annars ökar AI aktiviteten utan att alltid öka ingenjörskvaliteten eller affärsvärdet.

Varför SDLC måste bli AI-DLC

Saurabh delar med sig

CTO:er bör aktivt omforma själva livscykeln för programvaruleverans.

CTO:er bör aktivt omforma själva livscykeln för programvaruleverans. Jag ser detta som en övergång från traditionell SDLC till AI-DLC, en AI-förstärkt leveranslivscykel för den agentiska AI-eran.

I traditionell SDLC följer vi ofta linjära faser: krav, design, utveckling, driftsättning och support. Det fungerade förhållandevis bra när huvudmålet var att bygga deterministisk programvara genom strukturerade överlämningar. Men med AI, särskilt agentisk AI, blir livscykeln mer iterativ och komprimerad.

Jag förenklar AI-DLC till tre huvudfaser: initiering, konstruktion och drift.

• Under initieringen hjälper AI till med upptäckt, kodförståelse, extrahering av affärsregler, beroendeanalys, förtydligande av krav, identifiering av risker och planering av målbilden.
• Under konstruktionen hjälper AI till med arkitekturalternativ, uppdelning av tjänster, generering av kod och tester, dokumentation, säkerhetsgranskningar, infrastrukturmönster och genomförande av modernisering.
• Under drift stöder AI observerbarhet, incidenttriage, återkopplingsloopar, modellutvärdering, kostnadsoptimering, styrning och kontinuerlig förbättring.

Det viktiga är att AI-DLC inte bara är SDLC med en kodningsassistent tillagd. Det är en omdesignad operativ modell för ingenjörsarbete. Den integrerar AI-agenter, deterministisk upptäckt, mänsklig validering, säkerhetsgrindar, produktionsberedskap och kostnadsstyrning i ett enda arbetsflöde.

Hur ingenjörsteam förändras på grund av AI

AI har förflyttat ingenjörsteam från rollbaserat, sekventiellt genomförande till mer integrerade, resultatorienterade grupper.

Tidigare organiserade vi oss kring tydligt avgränsade roller: arkitekter, applikationsingenjörer, dataingenjörer, DevOps, säkerhet, QA och drift. Dessa roller är fortfarande viktiga, men AI komprimerar livscykeln och minskar värdet av långa överlämningar. De bäst presterande teamen är mer tvärfunktionella och närmare affärsproblemet.

För AI-ledd modernisering och produktutveckling söker jag nu team som kombinerar flera förmågor: starka grunder inom programvaruutveckling, moln- och plattformsutveckling, data- och AI-kompetens, säkerhetsmedvetenhet, produkttänkande och operativt omdöme. Jag värdesätter också ingenjörer som arbetar i tvetydiga miljöer, resonerar utifrån grundprinciper och validerar AI-resultat i stället för att blint acceptera dem.

Modellen med framåtriktade ingenjörsteam är ett bra exempel. I stället för att hålla arkitektur, AI-utveckling, DevOps och säkerhet i separata sekventiella spår för vi dessa kompetenser närmare kunden eller affärsmiljön. Teamet arbetar med verklig kod, verkliga data, faktiska begränsningar och tydliga framgångsmått.

Även rekryteringen har förändrats. Jag bryr mig fortfarande mycket om tekniskt djup, men jag söker också systemtänkare: personer som förstår arkitektur, använder AI ansvarsfullt, kommunicerar med affärsintressenter och tar ansvar för resultat i produktion. I AI-eran är de bästa ingenjörerna inte bara kodproducenter. De formulerar problem, validerar och bygger system som kan upprepas.

Så mäter du AI-effektivitet

En fråga jag önskar att fler ställde är: Hur bör CTO:er mäta om AI skapar varaktigt affärsvärde?

CTO:er bör inte mäta AI enbart utifrån antalet implementerade piloter eller copiloter, eller modellens träffsäkerhet isolerat. Detta är användbara signaler, men de bevisar inte transformation.

CTO:er bör mäta AI utifrån fyra dimensioner:

1. Produktivitet inom utveckling: Minskar AI ledtiden, förbättrar kodkvaliteten, ökar testtäckningen, påskyndar moderniseringen och minskar teknisk skuld?
2. Affärspåverkan: Förbättrar AI kundupplevelsen och de anställdas produktivitet samt ökar konverteringen, kostnadseffektiviteten eller snabbheten till marknaden?
3. Produktionsmognad: Är AI-systemen säkra, observerbara, tillförlitliga, styrda och kostnadskontrollerade? Har de tydligt mänskligt ansvar och tydliga grindar för produktionsberedskap?
4. Återanvändbarhet och skalbarhet: Bygger teamen återanvändbara AI-tjänster, agenter, instruktioner, mönster, dataprodukter och plattformsfunktioner, eller skapar de isolerade demonstrationer?

Detta är viktigt eftersom AI kan skapa en stor mängd synlig aktivitet utan att skapa varaktigt värde. CTO:er måste omvandla AI-aktivitet till en återanvändbar förmåga. Det innebär att koppla samman strategi, arkitektur, verksamhetsmodell, styrning och ekonomi.

Varför CTO:er måste skilja experimentering från industrialisering

Här är mina råd.

För det första bör AI inte behandlas som ett sidoexperiment. Behandla det som ett nytt verksamhetslager för företaget. AI kommer att påverka hur programvara utvecklas, hur medarbetarna arbetar, hur kunder interagerar och hur beslut fattas. CTO:ns uppgift är att hjälpa organisationen att gå från utspridda piloter till en styrd och skalbar strategi för en AI-plattform.

För det andra bör experimentering skiljas från industrialisering. Det är bra att experimentera snabbt, men AI i produktion behöver arkitektur, säkerhet, datastyrning, utvärdering, observerbarhet, kostnadskontroller och tydligt mänskligt ansvar. Många företag har fastnat eftersom de har många demonstrationer men ingen återanvändbar väg till produktion. CTO:er måste bygga den vägen.

För det tredje bör fokus ligga på affärsvärde, inte på modellnyhet. De vinnande organisationerna kommer inte att vara de som helt enkelt använder den senaste modellen. Det kommer att vara de som integrerar AI i verkliga arbetsflöden, moderniserar sin tekniska grund, förbättrar utvecklingsproduktiviteten och mäter resultat som ledtid, kostnadseffektivitet, kundupplevelse, intäktspåverkan och riskminskning.

Och för det fjärde är mitt praktiska råd att skapa en AI-plattform och en modell för framåtriktad ingenjörsutveckling tillsammans. Plattformen möjliggör återanvändning, styrning och skalning. FDE-modellen för AI till verkliga kund- och företagsarbetsbelastningar med hjälp av verkliga data, verklig kod och verkliga begränsningar. Det är så CTO:er kan gå från AI-ambition till realiserad avkastning på investeringen.

Följ med

Följ Saurabh Shrivastavas arbete på LinkedIn och hans författarsida på Amazon.

Fler expertintervjuer kommer snart på The CTO Club!