Styring av KI kan ikke være en ettertanke

Abhishek Ranjan er CTO i Apna og Blue Machines, der han er dypt involvert i å transformere både den menneskelige arbeidsstyrken og AI-arbeidsstyrken.

Vi satte oss ned med ham for å diskutere styring i AI-arbeidsflyter. Her er det han sa.

Teknologi side om side med mennesker

Jeg heter Abhishek Ranjan. Jeg er CTO i Apna og Blue Machines. To svært sammenkoblede, men likevel forskjellige verdener har formet reisen min frem til dette øyeblikket med AI-transformasjon.

I Apna utvikler vi løsninger for den menneskelige arbeidsstyrken. Apna er en av Indias raskest voksende enhjørningsbedrifter, med over 60 millioner brukere på plattformen. I denne skalaen får vi et svært nært innblikk i Indias arbeidsstyrke. Vi ser millioner av mennesker som leter etter bedre muligheter, arbeidsgivere som prøver å ansette raskere, ulike språk, ulike ferdighetsnivåer og varierende grad av digital tilgang og trygghet.

I Blue Machines utvikler vi løsninger for AI-arbeidsstyrken. Vi fokuserer på tale-AI for virksomheter og håndterer millioner av minutter hver dag. Vi utvikler mer enn bare boter som svarer på spørsmål. Vi utvikler AI-arbeidere som kan snakke med kunder, forstå kontekst, ta imot tilbakemeldinger, bli bedre over tid og utføre reelle arbeidsflyter for virksomheten.

Jeg har sett teknologi hjelpe mennesker med å finne arbeid, utvikle seg og delta i økonomien. Og nå ser jeg at AI selv blir en ny type arbeidsstyrke som kan arbeide side om side med mennesker.

For meg handler dette øyeblikket derfor ikke bare om å bruke AI for å øke produktiviteten eller skrive kode raskere. Det handler om å tenke nytt om hvordan virksomheter drives, og hvordan selve arbeidet blir utført.

Arkitekturen til to svært forskjellige virksomheter

Arkitekturen i Apna er bygget som en stor markedsplassplattform. Vi har forbrukersystemer, arbeidsgiversystemer, dataplattformer, AI- og matchingssystemer, søk, kommunikasjon, lag for svindelbeskyttelse og tillit, samt nå også funksjoner for AI-rekrutterere og AI-støttet intervjuforberedelse på toppen. Distribusjonsmodellen er skybasert fra grunnen av, svært skalerbar og bygget for høy tilgjengelighet, fordi millioner av brukere og tusenvis av virksomheter bruker plattformen.

Ingeniørorganisasjonen har over 100 personer som arbeider på tvers av produktutvikling, backend, frontend, mobil, data, AI, infrastruktur, sikkerhet og plattformteam. Vi fokuserer ikke bare på å utvikle funksjoner, men også på å bygge pålitelige systemer som kan fungere i massiv skala.

Blue Machines er en annen type teknologiorganisasjon. Den fokuserer på tale-AI for virksomheter og agentbaserte arbeidsflyter. Vi utvikler AI-arbeidere som kan snakke, resonnere, utføre handlinger, integreres med forretningssystemer og bli bedre gjennom tilbakemeldinger. I dag opererer vi allerede i betydelig skala, med millioner av tale-AI-minutter hver dag.

Arkitekturen i Blue Machines er mer sanntidsbasert og AI-basert fra grunnen av. Den omfatter taleinfrastruktur, telefoni, tale-til-tekst, resonnering med store språkmodeller, tekst-til-tale, orkestrering av arbeidsflyter, integrasjoner, analyse, overvåking og evalueringssystemer. Produktkompleksiteten er høy fordi tale-AI for virksomheter må fungere i produksjon, i reelle samtaler, med lav forsinkelse, høy nøyaktighet, etterlevelsesmekanismer og tydelige forretningsresultater.

I Blue Machines bygget et kjerneteam på fire ingeniører en distribuert plattform for taleorkestrering i løpet av noen få uker. Vi har også et svært merittert forskningsteam som arbeider i dybden med tale-AI, agentevaluering, resonnering, forsinkelse, flerspråklige systemer og forbedring av agenter over tid. Denne forskningsdybden er viktig fordi tale-AI for virksomheter ikke kan løses bare ved å sette sammen modeller. Det krever sterk produktutvikling, sterk systemutvikling og sterk anvendt AI-forskning.

Samlet sett befinner teknologiorganisasjonen jeg leder seg i skjæringspunktet mellom plattformer i stor skala og AI-baserte systemer.

Hvordan godt styrt AI forbedrer programvarelivssyklusen

Det siste året har AI endret hvordan vi utvikler, tester og lanserer teknologi.

Tidligere var utgivelsesprosessen vår mer tradisjonell. Utviklerne bygde funksjoner, opprettet PR-er, gjennomgikk fagfellevurderinger, kjørte testtilfeller og sendte dem deretter gjennom den vanlige distribusjonspipelinen. Det fungerte, men leveringshastigheten var avhengig av menneskelige gjennomgangssykluser, manuell kvalitetssikring og teamets tillit til utgivelsen.

Etter hvert som AI-assistert koding ble en større del av utviklingsarbeidet, tok vi det i bruk – og innså snart at bedre hastighet alene ikke var nok. AI kan hjelpe utviklere med å skrive kode raskere, men uten bedre styring kan det også føre til flere skjulte feil, oversette spesialtilfeller eller dårlige abstraksjoner.

Derfor endret vi arbeidsmodellen.

1. Vi la til et AI-assistert lag for PR-gjennomgang. Alle PR-er ble kontrollert for risikofylt logikk, manglende spesialtilfeller, brudd på API-kontrakter, sikkerhetsproblemer, migreringsrisiko og svak testdekning før menneskelig gjennomgang. Dette reduserte de mest åpenbare forglemmelsene før gjennomgangen.
2. Vi styrket CI-sperrene. En endring kunne ikke gå videre bare fordi koden så riktig ut. Den måtte bestå enhetstester, integrasjonstester, linting, sikkerhetskontroller, tester av API-kontrakter og regresjonstester for det berørte produktområdet.
3. Vi bygde sterkere regresjonstestpakker for kritiske arbeidsflyter. Det innebar for eksempel å legge til testtilfeller for reelle brukerscenarioer, spesialtilfeller, flerspråklig atferd, feilhåndtering og forretningsresultater.
4. Vi endret styringen av instruksjoner. Mer om det om litt.
5. Vi gjorde kanariutgivelser obligatoriske for områder med høy risiko. I stedet for å lansere til alle, lanserer vi til en liten andel av trafikken, overvåker feil, svartid, konvertering, frafall, agentkvalitet og kundepåvirkning, og ruller deretter ut videre eller tilbake.
6. Vi la til bedre observerbarhet. Når noe gikk galt, ville vi vite nøyaktig hvilken kodeversjon, instruksjonsversjon, modell, arbeidsflyt eller avhengighet som forårsaket det.

Effekten har vært svært tydelig. Leveringshastigheten vår økte betydelig. Team som tidligere leverte større, samlede utgivelser, går nå over til mindre og hyppigere utgivelser. På enkelte områder økte utgivelsesfrekvensen med nesten 2x til 3x fordi kontrollene er mer automatiserte og tilliten er høyere. Og det er slik et team på fire bygde en kompleks, distribuert plattform på bare noen uker.

Antallet problemer i produksjon gikk også ned fordi hver utgivelse er mindre, bedre testet og enklere å rulle tilbake. Vi ser en betydelig nedgang i produksjonsfeil, særlig der automatisert regresjonstesting og kanariutgivelser nå er obligatorisk. I dag ligger antallet feil nesten 40 % under det opprinnelige utgangspunktet.

AI alene gir hastighet. AI med styring gir hastighet og kvalitet.

Hvorfor instruksjoner må behandles som kode

Abhishek deler

For AI-systemer begynte vi også å behandle instruksjoner som kode … Dette har vært en viktig forbedring. Vi vet hvilken instruksjon som var aktiv, hva som ble endret, hva som ble forbedret, og om kunderesultatene ble bedre.

For AI-systemer begynte vi også å behandle instruksjoner som kode.

Vi versjonsbehandler, gjennomgår, tester og fremmer nå instruksjoner på tvers av miljøer, og ruller dem ut trinnvis. Instruksjoner behandles ikke lenger som små konfigurasjonsoppdateringer. De gjennomgår testsamtaler, spesialtilfeller, flerspråklige kontroller, kontroller av svartid, samsvarskontroller og kontroller av forretningsresultater.

Vi kan først lansere en ny instruksjon eller agentarbeidsflyt til en liten andel av trafikken, observere resultatene og deretter rulle den videre ut dersom måltallene ser bedre ut.

Dette har vært en viktig forbedring. Tidligere var det vanskelig å vite om en endring i instruksjonen forbedret agenten eller bare endret atferden dens. Nå kan vi sammenligne versjoner mer objektivt. Vi vet hvilken instruksjon som var aktiv, hva som ble endret, hva som ble forbedret, og om kunderesultatene ble bedre.

Den største endringen er at hele teknologisystemet ble mer automatisert, mer målbart og bedre styrt.

En agentdrevet arbeidsflyt for utviklingsutgivelser

Vi bruker en agentdrevet arbeidsflyt for utviklingsutgivelser, med mennesker involvert på viktige tidspunkter.

Denne arbeidsflyten fungerer ikke for alle utgivelser. For svært komplekse plattformendringer, omfattende arkitekturendringer eller sensitive systemer bruker vi fortsatt en mer tradisjonell, menneskestyrt prosess. Men for enkelte produktområder, særlig arbeidsflyter som utvikler seg raskere, har den blitt standardmåten å bygge på.

Slik ser arbeidsflyten ut:

1. Prosessen starter når et produktkrav eller et teknisk problem kommer inn. En AI-planleggingsagent leser kravet, bryter det ned i oppgaver, identifiserer avhengigheter, markerer risikoområder og foreslår en implementeringsplan. Ingeniøren gjennomgår planen, korrigerer antakelser og bestemmer den endelige fremgangsmåten.
2. Deretter genererer en kodeagent kode, refaktorerer moduler, skriver standardkode og oppretter enhetstester og integrasjonstester. En gjennomgangsagent kontrollerer pull request-en for risikofylt logikk, manglende randtilfeller, sikkerhetsproblemer, brudd på API-kontrakter og mangler i testene.
3. Deretter oppretter en testagent regresjonsscenarier og validerer randtilfeller. For AI-arbeidsflyter kjører den også promptevalueringer, samtaletester, flerspråklige kontroller, latenstester og kontroller av forretningsresultater.
4. Utgivelsesagenten anbefaler deretter om endringen er trygg for canary-distribusjon, basert på testresultater, påvirket område, tidligere feil og hvor klare systemene for observerbarhet er. Mennesker godkjenner likevel fortsatt kritiske utrullinger, særlig hvis endringen påvirker inntekter, kundeopplevelse, sikkerhet eller kjerneinfrastruktur.
5. Når endringen er lansert, overvåker overvåkingsagenten feil, latenstid, konvertering, frafall, agentkvalitet og kundepåvirkning. Hvis noe ser galt ut, anbefaler den tilbakerulling, oppretter en hendelse, oppsummerer logger og lager et første utkast til RCA.

Denne arbeidsflyten er agentbasert, men ikke blindt autonom. AI-agenter planlegger, koder, gjennomgår, tester, lanserer, overvåker og oppsummerer. Mennesker godkjenner, utfordrer, prioriterer og tar det endelige ansvaret for beslutningen.

Der Claude Code og Cursor utmerker seg

Favorittverktøyene mine er Claude Code og Cursor, avhengig av arbeidsflyten.

Cursor utmerker seg når ingeniører ønsker AI dypt integrert i IDE-en til daglig koding, refaktorering, forståelse av kodebasen og raskere implementering.

Claude Code viser seg å være svært nyttig for mer agentbaserte oppgaver: forståelse av større kodebaser, endringer på tvers av flere filer, generering av tester, feilretting og iterasjon som en teknisk samarbeidspartner.

Hvorfor AI gir større gjennomslagskraft, mens mennesker utøver dømmekraft

Vi er nå svært avhengige av AI for alt som forbedrer hastighet, dekning eller konsistens, men ikke for oppgaver som krever dømmekraft, ansvarlighet eller langsiktige avveininger.

AI hjelper oss for eksempel nå med kodegjennomgang, generering av testtilfeller, regresjonsdekning, dokumentasjon, feilsøking, logganalyse og til og med hendelseshåndtering. Den kan raskt identifisere risikofylte kodebaner, manglende randtilfeller, mulige sikkerhetsproblemer eller mønstre i produksjonsfeil. I AI-systemer hjelper den oss også med å sammenligne promptversjoner, evaluere samtaler og forstå hvor en agent feiler.

Men de endelige beslutningene tas av mennesker. Her er noen eksempler:

• Arkitekturvalg må fortsatt tas av mennesker, fordi de innebærer avveininger knyttet til skala, kostnader, pålitelighet, teamets kompetanse og produktets langsiktige retning.
• En helhetlig RCA kan støttes av AI, men mennesker må fortsatt se sammenhengene, validere hypotesen og bestemme løsningen.
• Prioritering av oppgaver i backloggen forblir menneskestyrt, fordi det krever kundekontekst, forretningsstrategi og dømmekraft om hva som virkelig betyr noe.
• Sikkerhetsgjennomganger bruker AI, men ekspertvurderinger er nødvendige. AI kan flagge problemer, men den kan også skape falske positiver eller overse risikoer knyttet til forretningskonteksten. Mennesker beholder ansvaret fordi risikoen og ansvarsforpliktelsen er for store.

Eksempler fra virkeligheten på AI-feil i tekniske vurderinger

Her er et par eksempler på betydningen av menneskelig dømmekraft.

Det første gjaldt latenstopper på millisekundnivå i tale-pipelinen vår. AI kommenterte riktig på problemet og identifiserte at latens i én bane kunne bli et problem. Men koden den foreslo, var feil. Den så ryddig ut, men ville ha skapt en annen flaskehals under belastning. En menneskelig utvikler grep inn, forsto kjøretidsatferden og løste det på riktig måte.

Et annet eksempel oppsto under feilsøking i produksjon. Flere nedstrømssystemer sviktet, og AI fortsatte å analysere disse systemene uavhengig av hverandre og foreslo optimaliseringer. Men vi visste allerede at det egentlige problemet var en oppstrømsavhengighet som hadde sviktet først. AI forvekslet synlige feil med rotårsaken.

Det er her AI fortsatt har utfordringer. Den kan lese logger, oppsummere spor, foreslå løsninger og gjøre feilsøking raskere. Men i komplekse distribuerte systemer kan den overse årsakssammenhenger, tidsforløp og kontekst på systemnivå.

Hvorfor team blir slankere og får større bredde

AI har endret profilen vi ansetter etter, mer enn organisasjonskartet.

Tidligere ansatte vi for smalere funksjonell dybde: backend, frontend, QA, DevOps, data og så videre. Disse ferdighetene er fortsatt viktige, men nå setter jeg større pris på utviklere som kan arbeide på tvers av hele stakken, bruke AI inngående og gå fra problem til produksjon med langt mindre oppfølging.

De beste utviklerne skriver ikke bare kode lenger. De utformer arbeidsflyter, bruker AI til implementering, genererer tester, gjennomgår resultater, feilsøker raskere og tenker på kvaliteten ved utrulling.

Dermed har listen for ansettelser beveget seg mot utviklere med stort eierskap og god dømmekraft. Personer som kan stille de riktige spørsmålene, verifisere AI-resultater, forstå systemer i dybden og levere selvstendig.

Det har også redusert behovet for store team på enkelte områder. Et mindre team med god utnyttelse av AI kan nå utføre arbeid som tidligere krevde langt flere personer.

Hvorfor AI gjør det vanskeligere å lære opp nye utviklere

Abhishek Shares

Jeg mener ikke at det riktige svaret er å forby AI eller tvinge folk til å kode som om det var 2010. Det ville vært feil. Men jeg mener heller ikke at vi fullt ut har løst hvordan vi bygger opp dyp teknisk dømmekraft når AI gjør så mye av forarbeidet. Foreløpig er mitt beste svar å gjøre forståelsen synlig.

Hvordan lærer vi opp nye utviklere i AI-tiden? Jeg har ikke et perfekt svar ennå.

Da vi startet, hjalp IDE-er oss. Deretter hjalp Google oss. Så hjalp Stack Overflow oss. Men i alle disse fasene måtte du fortsatt arbeide deg gjennom problemet. Du måtte forstå svaret, tilpasse det, feilsøke det og lære hvorfor det fungerte.

Med AI og stemmekoding kan vi hoppe over denne anstrengelsen. En ny utvikler kan generere fungerende kode uten egentlig å forstå systemet, avveiningene eller feilmodusene. Det bekymrer meg.

Jeg mener ikke at det riktige svaret er å forby AI eller tvinge folk til å kode som om det var 2010. Det ville vært feil. Men jeg mener heller ikke at vi fullt ut har løst hvordan vi bygger opp dyp teknisk dømmekraft når AI gjør så mye av forarbeidet.

Foreløpig er mitt beste svar å gjøre forståelsen synlig. Utviklere bør kunne forklare hvorfor koden fungerer, hvor den kan feile, hvilke tester som er viktige, hva som skjer i stor skala, og hvordan de ville ha feilsøkt den i produksjon.

Slik håndterer du tokenbruk

Kostnader har også vært en utfordring med AI.

Tokenbruk virker ufarlig i begynnelsen, men når AI tas i bruk til koding, gjennomganger, testing, feilsøking og agentbaserte arbeidsflyter, kan kostnadene vokse svært raskt.

Derfor må vi nå måle avkastningen på investeringen per arbeidsflyt og bruke smartere orkestrering. Ikke alle oppgaver trenger den dyreste modellen.

Fremtiden innebærer å bruke riktig modell til riktig oppgave.

Hvorfor teknologidirektører må handle raskt – med kontrollmekanismer

Her er mitt råd: Bygg raskt. Eksperimenter raskt. Ta AI i bruk i reelle arbeidsflyter innen utvikling, produkt, brukerstøtte, salg, drift og interne prosesser. Ikke lat som om det ikke fungerer. Det gjør det, noen ganger overraskende godt.

Men ikke bli ukritiske tilhengere. AI er kraftig, men det er ikke magi. Du trenger kontroll, styring, testing, observerbarhet og tydelig eierskap. Ellers skaper du bare kaos raskere.

Den riktige innstillingen er verken «AI vil erstatte alt» eller «AI er hauset opp». Den riktige innstillingen er «hvordan kan jeg bruke dette til å gjøre organisasjonen min ti ganger mer kapabel?»

Følg med videre

Følg med på Abhishek Ranjan på LinkedIn. Og sjekk ut nyhetsbrevet hans, Hacktivate.

Det kommer flere ekspertintervjuer i CTO-klubben!