Natasha Mohanty, SVP for ingeniørarbeid i Doppel – Intervju-serie

Natasha Mohanty, Senior Vice President for ingeniørarbeid i Doppel, er en erfaren teknologileder med dypt erfaring fra AI, betalingsløsninger, medier og forbrukerplattformer. Før hun begynte i Doppel, ledet hun ingeniørarbeidet for Stripe’s Optimized Checkout Suite og Link, og skalerte organisasjonen fra 30 til 200 ingeniører samtidig som hun hjalp til å drive major adopsjon av Stripe’s checkout-produkter og forbrukerlommebok. Tidligere var hun Vice President for ingeniørarbeid i Nielsen etter oppkjøpet av Prizma.ai, det AI-drevne videoengasjement- og medieanalyse-selskapet hun hadde medgrunnlagt og ledet som CTO. Tidligere i sin karriere tilbragte hun over syv år i Google (GOOGL ), hvor hun arbeidet med Søke kvalitet, Google Nyheter og Google+ personliggjøring.

Doppel er et AI-nativt selskap for sosial ingeniørvern som fokuserer på å beskytte organisasjoner, ledere, merkevarer og kunder mot AI-drevet personliggjøring, phishing, svindel og bredere digitale risikoer. Plattformen kombinerer digital risikobeskyttelse, leder- og merkevarebeskyttelse, e-post sikkerhet, menneskelig risikostyring, simuleringer og sikkerhetstreningsprogrammer, som bruker AI og sanntids trusler for å oppdage, korrelere og forstyrre angriper-infrastruktur over kanaler som domener, sosiale medier, meldingsapper, annonser og det mørke nettet. Selskapet har posisjonert seg rundt den økende trusselen fra generativ AI-drevet sosial ingeniørarbeid, og hjelper sikkerhetsteamene med å svare på stadig mer sofistikerte angrep over det moderne digitale trussellandskapet.

Du har ledet ingeniørorganisasjoner i selskaper som Stripe, Google, Nielsen og nå Doppel. Hvordan har din oppfatning av rollen til en programvareingeniør utviklet seg fra å skrive systemer direkte til å koordinere stadig mer autonome AI-drevne arbeidsflyter?

Arbeidsflyten for programvareingeniører har endret seg dramatisk, men ansvarskravene til ingeniører har ikke. Da jeg startet min karriere i Google for to tiår siden, tilbragte ingeniører mesteparten av tiden sin på å skrive og gjennomgå kode selv. I dag kan AI håndtere størsteparten av kodegenerering, men ingeniører er fortsatt ansvarlige for å definere mål, validere utdata, etablere retningslinjer, gjennomgå kode og sikre at systemene forblir pålitelige over tid. På mange måter har AI utvidet omfanget av ingeniøransvar i stedet for å redusere det.

Hva som har endret seg, er hvor ingeniører skaper verdi. Ettersom AI tar på seg stadig mer av kodemekanikken, blir rollen stadig mer sentrert rundt smak og dømmekraft, forståelse av problemet, arkitekturavgjørelser, evaluering av kompromisser og sikring av at resultater stemmer overens med bruker- og bedriftsbehov. De beste ingeniører gjør mer enn bare å skrive programvare. De vil koordinere sammenhengende systemer av mennesker og AI, og anvende kontekst og ansvar som maskiner fortsatt mangler. Dette er lignende med skiftet fra enkeltbidragsyter til leder.

Du har argumentert for at AI ikke reduserer ingeniøransvar, men utvider det. Hva er de største misforståelsene ledere fortsatt har om hva AI-kodeagenter realistisk kan håndtere uten menneskelig tilsyn?

Den største misforståelsen er at AI vil eliminere behovet for sterke ingeniører. Virkeligheten er at AI hever taket for hva en liten, dyktig gruppe kan bygge, noe som gjør ingeniørdømmekraft mer verdifull, ikke mindre.

Hva som endrer seg, er overflaten ingeniører er ansvarlige for. De skriver ikke bare kode lenger. De definerer hva som skal bygges, validerer at agenter gjør hva de var ment til, og eier resultatet når de ikke gjør det.

Hvis noe, har problemrommet blitt mer interessant. Angripere har tilgang til de samme AI-verktøyene vi har, noe som betyr at utfordringen med å holde foran dem er genuint harder og mer interessant enn noen gang tidligere. Det er ingen mangel på harde problemer å løse, og Doppel rekrutterer over ingeniører for mennesker som er begeistret for denne type arbeid.

Ettersom ingeniørteam begynner å koordinere flere AI-agenter over kode, testing, feilsøking og dokumentasjon, hva ser en effektiv “agentstyrings”-arbeidsflyt ut som i praksis?

Ingeniører handler stadig mer som ledere for autonome systemer, ikke bare bidragsytere til dem. De beste ingeniører kan holde betydelig kontekst over flere parallelle arbeidsflyter samtidig som de vet nøyaktig hva kontekst å dele med hver agent. I praksis betyr det å skrive godt definerte akseptkriterier, sette klare retningslinjer for personvern og sikkerhet, og be agenter om å forklare sin begrunnelse og antagelser som en valideringssteg. Hvis en agent ikke kan artikulere hva den gjør og hvorfor, kan du ikke fullt ut stole på utdataene.

I Doppel bygger vi agenter som undersøker trusler, kontinuerlig tilpasser oppdagelsespolitikker og forklarer sine avgjørelser på ren språk. Effektiv agentstyring krever også systemnivå-infrastruktur, inkludert stagingsmiljøer, automatiserte testpipeliner, sikkerhetstverktøy med definerte tillatelser og tilsyn, og evalueringssystemer som kontinuerlig vurderer om agenter og det bredere systemet opererer som forventet.

Hva er de største operasjonelle eller sikkerhetsrisikoene som oppstår når AI-agenter får tilgang til interne verktøy, produksjonssystemer eller sensitive arbeidsflyter uten sterke retningslinjer?

Risikoen er ikke bare at AI-agenter gjør feil. Det er at de kan gjøre dem i en skala som er vanskelig å fange i sanntid. Den mer spesifikke faren er agenter som handler utenfor deres ment å omfatte, enten det betyr å få tilgang til systemer de ikke var designet til å berøre eller håndtere data de ikke bør beholde.

I vår e-post-sikkerhetsprodukt, for eksempel, behandler agenter data som er innebygget sensitiv. Vi har gått til betydelige lengder for å sikre at disse agentene har strengt begrensede tillatelser, ikke kan utilsiktet eksponere sensitive personlige opplysninger nedstrøms og ikke beholder konfidensielle opplysninger, samtidig som de har konteksten nødvendig for å fatte riktige avgjørelser.

På hvilket tidspunkt begynner avhengighet av AI-generert kode å introdusere langsiktige tekniske gjeld, og hvordan bør ingeniørledere tenke om å balansere hastighet mot vedlikehold?

Risikoen er å prioritere korttids-hastighet over grunnleggende fundamentene som tillater systemer å skale og utvikle seg. En av de største lærdommene fra min tid i Stripe var at ikke alle avgjørelser er like. Noen er fellefall: vanskelige å reversere og sannsynlig å ha langsiktige konsekvenser, mens andre kan endres mer lett.

Med AI er disiplinen å vite hvilke avgjørelser fortsatt har langsiktige konsekvenser, å sette sterke retningslinjer rundt disse og å flytte raskt på resten. I Doppel betyr det å bruke evalueringssystemer og nåværende dokumentasjon for å sikre at agenter fortsetter å operere som ment når systemer utvikler seg. Målet er ikke å bremse ned, men å sikre at hastighet ikke stille og quiett undergraver fundamentene du bygger på.

Under din tid med å skale ingeniørorganisasjoner i Stripe, hva lærte du om pålitelighet, tillit og systemdesign som nå føles spesielt relevant i æraen med autonome AI-agenter?

I Stripe var pålitelighet alt, spesielt fordi finansindustrien er så regulert og det kunne være katastrofalt for bedrifter hvis betalingsportaler gikk ned. Hvis et system ikke fungerte som ment, var det en direkte innvirkning på kunder, og det skapte en sterk kultur av eierskap og ansvar i selskapet.

En av tingene som trakk meg til Doppel var et lignende nivå av kundeobsesjon. Teamene her er dypt fokusert på å forstå utfordringene kundene møter og å ta eierskap for å løse dem.

Nå som jeg er i Doppel, føles disse lærdommene spesielt relevante. Vi bygger AI-nativa systemer for å hjelpe organisasjoner med å forsvare seg mot stadig mer sofistikerte sosiale ingeniørangrep. Og lik Stripe, hvor du ikke kan ha betalingsbehandlingssystemer som går ned, er det katastrofalt for bedrifter å ikke ha en sterk cybersikkerhetsposture. De er begge svært høye innsatser, men av forskjellige årsaker.

Hvordan forventer du at ingeniørrekruttering vil endre seg de neste årene, ettersom selskaper stadig mer prioriterer AI-ferdighet, systemtenkning og tilpasning over smalere teknisk spesialisering?

Jeg tror vi vil se en økende fokus på å rekruttere ingeniører som kan operere med autonomi, sterk dømmekraft og evnen til å lære raskt. Disse er egenskaper jeg alltid har rekruttert for, men de betyr mer nå, ikke mindre. Gjennom hele min karriere har ingeniører som har hatt den største innvirkningen ikke nødvendigvis vært de med den smaleste spesialiseringen. De var de som kunne tilpasse seg raskt, navigere usikkerhet og kontinuerlig lære mens teknologien utviklet seg.

Men standarden har skiftet. I Doppel er problemene vi løser ikke nøyaktig definert. Vi arbeider kontinuerlig for å holde foran angripere som også utnytter AI, noe som betyr å bygge systemer som trusselintelligensagenter som proaktivt utforsker nettet for å oppdage trusler. Det finnes ingen etablert spillbok for denne type arbeid, så det krever mot og en villighet til å presse grensene for hva som er mulig.

AI vil bare fortsette å endre hvordan arbeid blir gjort, men selskaper vil fortsatt trenge mennesker som kan arbeide over systemer og ta ansvar for hele livssyklusen av hva de bygger. Ingenicører som trives vil være de som kontinuerlig gjenskaper hva de er i stand til å gjøre mens AI-landskapet utvikler seg rundt dem.

Du har arbeidet omfattende med personliggjøring, anbefalingsystemer og maskinlærings-drevne plattformer gjennom hele din karriere. Hvordan former denne erfaringen måten du tenker om menneske-AI-samarbeid innen ingeniørorganisasjoner i dag?

En ting jeg lærte fra å arbeide med personliggjøring og maskinlærings-systemer er at kvaliteten på utdataene er bare så god som kvaliteten på inndataene, inkludert treningsdata, evalueringssystemer og en klar definisjon av hva “god” faktisk betyr. Modeller er gode til å prosessere informasjon i skala, men mennesker bringer dømmekraft, kontekst og en forståelse av hva som betyr mest.

Jeg tror det samme prinsippet gjelder for ingeniørorganisasjoner som opererer i dag. AI kan hjelpe teamene med å flytte raskere, men de beste teamene vil være bevisste på konteksten og bakgrunnsfakta de gir AI, samt hvordan AI-drevne systemer integreres i det bredere ingeniørikosystemet. Ingenicører må fortsatt fatte avgjørelser, evaluere kompromisser og til slutt eie resultatet.

Mange selskaper kappler for å maksimere utviklerproduktivitet med AI-verktøy. Tror du at den konkurransemessige fordelen ultimate kommer fra raskere kodning, eller fra å bygge organisasjoner som vet hvordan å styre og koordinere AI-systemer effektivt?

Hastighet betyr noe, spesielt i cybersikkerhet, hvor å falle bak angripere ikke er et alternativ. Men hastighet uten retningslinjer er bare en raskere måte å skape utnyttbare hull. Styring av AI-systemer bør være grunnlinjen for hvert selskap som bygger med AI, ikke en ettertanke. Det er essensielt for å sikre kvalitet, pålitelighet og ansvar i programvareingeniørarbeidsflyter. I cybersikkerhetsindustrien spesielt er styring essensiell fordi angripere vil finne og utnytte enhver åpning du lar.

Ser fremover fem år, hva tror du det moderne programvareingeniørteam vil se ut som når AI-agenter blir dypt integrert i hverdagsutviklingsarbeidsflyter?

Fem år er vanskelig å forutsi med sikkerhet fordi verden beveger seg så raskt. Hva jeg kan si med mer sikkerhet er at innen de neste 18 månedene til tre år, vil AI-agenter sannsynligvis håndtere størsteparten av kodegenerering, testing og første feilsøking.

Hva ingeniører kommer til å eie, er produktavgjørelser: spesifikasjonen, smaken, arkitekturen og ansvar når noe feiler. Teamene kan bli mindre, men rollen kommer til å bli harder. Ingenicører som trives, vil ikke nødvendigvis være de som produserer mest kode, men de som kan dirigere, evaluere og korrigere autonome systemer effektivt.

Ettersom jeg har arbeidet gjennom tidligere teknologiske skift, er en ting jeg har lært, at innovasjon sjelden følger en rett linje. Teamene som lykkes, vil være de som forblir nysgjerrige, tilpasser seg raskt og utvikler sine arbeidsflyter ettersom teknologien endrer seg. Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Doppel.