Hvordan ser fremragende ingeniørarbeid ut i AI-alderen?

Les transkripsjonen:

Vi prøver ut å transkribere podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, ettersom boten ikke er korrekt 100 % av tiden.

Hannah Clark: Det har blitt en vits at AI-æraen har ført til at alle jobber innen teknologi har forsvunnet. Faktisk har så mange jobber dødd i år at jeg er overrasket over at jeg ikke har blitt invitert til flere begravelser. Produktledelse er død, brukerundersøkelser er døde, og mest alvorlig av alt: programvareutvikling er død. Jeg forkynner sannsynligvis for koret her, men alle som virkelig tror at programvareutvikling er død fordi den vennlige språkmodellen i nabolaget kan skrive kode, er definitivt ikke utviklere selv.

Dagens gjest, Cortex.io-grunnlegger Anish Dhar, vil til og med hevde at utvikling definitivt ikke er død. Den vokser bare opp. Anish var tidligere utvikler hos Uber og grunnla Cortex for å gjøre det enklere for utviklere å forstå komplekse kodebaser. Som utvikler selv, og som en person hvis brukere er utviklere, ser han faktisk en utvikling innen fremragende ingeniørarbeid og et gap mellom nye og gamle måter å måle dette på. Vi deler neste generasjons tanker om hvordan man måler og evaluerer fremragende ingeniørarbeid, samt en kontroversiell mening om hvordan trenden med «vibe coding» passer inn i samtalen. La oss sette i gang.

Forresten, vi har samtaler som denne hver uke, så hvis dette høres interessant ut, hvorfor ikke abonnere? Greit, la oss begynne.

Velkommen tilbake til The CPO Club-podkasten. I dag har jeg med meg Anish Dhar. Han er grunnleggeren av Cortex.io.

Anish, takk for at du tok deg tid til å snakke med meg i dag.

Anish Dhar: Tusen takk for invitasjonen.

Hannah Clark: Ja, kan du fortelle oss litt om bakgrunnen din og hvordan du kom til rollen du har i dag?

Anish Dhar: Ja, absolutt. Jeg er medgrunnlegger og administrerende direktør i Cortex.io. Vi startet selskapet for omtrent seks år siden, men før det jobbet jeg som utvikler hos Uber. Jeg startet egentlig karrieren min der, og mange av problemene jeg møtte som utvikler hos Uber, inspirerte alle grunnene til at vi startet Cortex.

To av mine aller nærmeste venner og jeg. Uber har en enorm intern tjenestearkitektur. Som utvikler der var det veldig vanskelig for meg å forstå ulike deler av kodebasen, særlig da jeg begynte. Det var så mange forskjellige tjenester som ble bygget. Det skapte en intens kompleksitet, og jeg snakket med en veldig nær venn av meg som var utvikler i en svært liten oppstartsbedrift kalt Lend.

De hadde bare hundre utviklere, mens Uber hadde over tusen. Men vi møtte begge lignende utfordringer med å organisere og forstå tjenestearkitekturen vår. Det fikk alarmklokkene til å ringe: Hvis Uber er i den ene enden av skalaen, og dette andre selskapet, som nettopp har startet reisen sin med mikrotjenester, har de samme problemene, er det tydelig at dette er et stort problem i bransjen.

Dermed endte vi med å starte selskapet. Vi gikk gjennom Winter 20 Y Combinator-kullet. Så, ja, spoler vi frem til i dag, har vi nettopp gjennomført serie C, og jeg jobber med flere hundre ulike virksomheter som bruker Cortex til å håndtere kompleksiteten sin.

Hannah Clark: Kult. Det er en fantastisk reise, og det er alltid flott å høre når et selskap oppstår fra asken av et problem man kjenner inngående.

Når vi først snakker om det, skal vi i denne episoden snakke om fremragende ingeniørarbeid og hvordan det ser ut i dagens teknologilandskap. Dette er selvfølgelig et tema du har vært tett på gjennom hele karrieren. For å starte: Hvordan definerer du fremragende ingeniørarbeid i 2025, og hvorfor blir dette et så viktig fokus for teknologidirektører og utviklingsdirektører akkurat nå?

Anish Dhar: Ja, absolutt. Det er et godt spørsmål. Det vi har funnet hos Cortex, er at samtalen lenge var svært fokusert på utvikleropplevelse. Og utvikleropplevelse er en kritisk del av enhver utviklingsorganisasjon, ikke sant? Det handler om enkle ting, som å sørge for at utviklere enkelt kan sette opp de interne systemene sine når de begynner i et selskap, og at de kobles til GitHub og de ulike verktøyene de har. Eller når de kanskje distribuerer en tjeneste, at infrastrukturen er satt opp på riktig måte, slik at det ikke kreves mye feilsøking eller mange trinn for å komme i mål.

Men det vi særlig har sett de siste par årene, er at samtalen har beveget seg fra bare utvikleropplevelse til det vi kaller fremragende ingeniørarbeid. Jeg vil si at den store forskjellen mellom de to er at fremragende ingeniørarbeid virkelig fokuserer på arbeidet til de ulike teamene i organisasjonen.

Du kan tenke på SRE, sikkerhet, utviklerproduktivitet og til og med utvikleropplevelse, men det handler om å knytte dem til faktiske forretningsresultater. Jeg tror det er den viktigste forskjellen: Fremragende ingeniørarbeid handler om hvordan arbeidet jeg gjør faktisk påvirker virksomheten, og hvordan det driver den fremover.

Målene vi har, helt fra toppledelsen og ned til den spesifikke SRE-en som arbeider med det. Et godt eksempel kan være at organisasjonen som helhet er svært opptatt av å forbedre kundeopplevelsen. Vi ønsker at produktet skal være pålitelig når kundene bruker det, og en bedre kundeopplevelse fører til høyere inntekter fordi folk bruker produktet mer.

Fra et initiativ for fremragende ingeniørarbeid kan SRE-teamet derfor ha en sjekkliste for produksjonsberedskap som de prøver å implementere. Før tjenester distribueres, vil de forsikre seg om at alle tjenestene oppfyller organisasjonens standarder. Man kan se hvordan et initiativ som starter hos SRE-teamet, knyttes tilbake til et konkret forretningsresultat organisasjonen bryr seg om.

Jeg tror det er avgjørende at team tenker på initiativene sine på denne måten, fordi det bekrefter verdien og knytter de tekniske initiativene til noe virksomheten bryr seg om. Det er etter min mening selve kjernen i fremragende ingeniørarbeid.

Hannah Clark: Interessant. Og dette har du sikkert beskrevet mange ganger som en slags endeløs reise, der mange fagområder må arbeide sammen.

Fortell meg om rammeverket dere har utviklet. Hvordan ser de viktigste søylene ut? Hvordan ser dere på dette i deres egen organisasjon?

Anish Dhar: Du har helt rett. Det er virkelig en endeløs reise. Mange av selskapene vi jobber med, særlig store virksomheter, har mye eldre infrastruktur sammenlignet med kanskje et nytt selskap som er bygget på nyere teknologi og kanskje er AI-først.

Det finnes fortsatt ulike initiativer knyttet til fremragende ingeniørarbeid, og det krever etter min mening en gjennomtenkt tilnærming på tvers av alle disse teamene. Hva er arbeidet, og hvordan påvirker det til syvende og sist målene våre for fremragende virksomhetsdrift? Når det gjelder et rammeverk, er noe av det vi virkelig har arbeidet med: Hvordan definerer man fremragende ingeniørarbeid for organisasjonen sin?

Måten vi tenker på det, er at det starter med fremragende virksomhetsdrift. Ledergruppen har ulike mål, og de kan handle om å frigjøre innovasjon og redusere tiden til markedet. Det kan være å redusere kostnader og øke effektiviteten. Det tredje vi vanligvis ser, som jeg nettopp nevnte, er hvordan man forbedrer kvaliteten og kundeopplevelsen.

Under dette finner vi søylene for fremragende ingeniørarbeid. Dette er de ulike teamene og fagpersonene som utformer initiativene som driver disse endelige målene. Det kan være hastighet, effektivitet, sikkerhet og pålitelighet. Selv innenfor disse underkategoriene vil du ha initiativer som en sikkerhetsmigrering eller en sjekkliste for produksjonsberedskap.

Kanskje prøver du å implementere en prosess for hendelseshåndtering. Eller noe så enkelt som at vi ønsker å følge med på DORA-målinger for å forstå hvordan utviklingsteamet faktisk presterer fra et produktivitetsperspektiv. Grunnlaget for ethvert initiativ for fremragende ingeniørarbeid kommer fra det vi liker å kalle de fire C-ene.

Det er i hovedsak fullstendig innsyn, kontinuerlig forbedring, en konsekvent utvikleropplevelse og selvfølgelig tydelig eierskap. Uten eierskap og forståelse av de ulike delene av kodebasen og alle tjenestene er det svært vanskelig å drive disse initiativene fremover. Vi ser derfor vanligvis at det er vanskelig å drive ethvert initiativ uten dette grunnlaget.

Vi ser også vanligvis at interne utviklerplattformer eller interne portaler er en svært god måte å bygge dette grunnlaget på. Det kan også gjøres gjennom interne verktøy, men du trenger en form for system for å forstå hva folk bygger, slik at du kan drive disse utviklingsinitiativene fremover.

Hannah Clark: Greit. Jeg vil gå litt dypere inn i noe du nevnte om måling av prestasjon, fordi jeg vet at det finnes en viss spenning rundt måling av utviklerproduktivitet og målinger som antall kodelinjer.

Det kan være litt kontroversielt blant utviklere. Hvordan bør utviklingsledere tenke på produktivitetsmåling på en mer helhetlig måte som tar hensyn til alle disse C-ene og slikt?

Anish Dhar: Ja, absolutt. Det interessante er at mye av utviklerproduktiviteten de siste årene har handlet om antall kodelinjer eller DORA-målinger. Det finnes mange ulike rammeverk som jeg tror ble laget for å forenkle hvordan man tenker på produktivitet, og det finnes en viss sannhet i hvordan disse målingene beregnes.

Antall kodelinjer er ikke en god indikator på om noen er produktive eller ikke. Men hvis du konsekvent leverer null kodelinjer, kvartal etter kvartal, er det åpenbart noe galt med resultatet. Det kan også være interessant å sammenligne team med hverandre og se på slike datapunkter, men jeg tror samtalen virkelig har gått fra «greit, jeg har disse dataene» til «hvordan får jeg faktisk utviklere til å forholde seg til dataene eller forbedre dem?»

Hvis du bryter det ned, er det et helt annet problem. Et langt vanskeligere problem, fordi hvem som helst kan gå inn, hente GitHub-API-et ditt og få disse målingene, og dermed et øyeblikksbilde av hvordan teamet presterer. Men bare fordi jeg viser en utvikler et sett med målinger og sier «Hei, vi må forbedre denne målingen», betyr ikke det egentlig noe for meg som utvikler.

Jeg fokuserer på å bygge programvare for virksomheten, og jeg fokuserer vanligvis på å gjøre det så effektivt som mulig. Jeg tror derfor samtalen, særlig blant teknologidirektørene vi jobber med, virkelig har gått over til: «Greit, jeg har disse målingene. Hvordan oversetter jeg dem til noe en utvikler bryr seg om?»

Og jeg tror faktisk det er her fremragende ingeniørarbeid spiller en så kritisk rolle. Utviklere, særlig de som jobber i selskaper med høyt tempo, ønsker at virksomheten skal vokse. De bygger produkter fordi de ønsker å se hvilken innvirkning arbeidet deres har på kundene.

Jeg tror utviklerproduktivitet virkelig har gått fra «her er en haug med målinger» til «som virksomhet er dette det vi bryr oss om, og disse målingene forteller en del av historien». Men for en utvikler handler det om hvordan du oversetter det til noe der arbeidet jeg faktisk gjør, betyr noe.

Det er den store endringen vi har sett.

Hannah Clark: Har du lagt merke til at det finnes utdaterte evalueringsmetoder eller KPI-er som folk begynner å bevege seg bort fra? Hva vil du si er den nye skolen innen evaluering, eller har du noen konkrete eksempler du kan dele?

Anish Dhar: Ja, absolutt. Jeg ville tenkt på produktivitet som målinger av innsats og resultat. Resultatmålinger er alle de klassiske rammeverkene du ser i dag for å følge utviklerproduktivitet. Et av de mest kjente og populære er DORA-målinger, som er et sett med ulike målinger som skal gi deg et helhetlig bilde av hvordan utviklingsteamet presterer.

Jeg vil si at de fleste utviklingsorganisasjoner i dag ønsker å se disse resultatmålingene og forsøker å fange dem opp. Men det går tilbake til det jeg sa tidligere: Hvordan påvirker jeg faktisk disse målingene og får dem til å bevege seg? Det vi har sett, særlig blant kundene våre, og jeg tror det er en av grunnene til at Cortex har vokst så interessant de siste årene, er hele konseptet med innsatsmålinger som påvirker resultatmålinger.

Ta for eksempel distribusjonsfrekvens. Det er en flott måling, fordi takten utviklerne distribuerer programvare i, sannsynligvis er en god indikator på hvor raskt du endrer produktet. Det handler til syvende og sist om hvordan du slår konkurrentene i markedet, og hvordan du beveger virksomheten raskere fremover.

Kanskje organisasjonen har bestemt at distribusjonsfrekvens er hovedmålingen dere vil følge. Hvis jeg har et kontrollpanel for distribusjonsfrekvens, og jeg kan hente det opp i OKR-ene mine og vise hele utviklingsteamet: «Hei alle sammen, vi distribuerer to ganger i uken. Vi ønsker å komme opp i fire.»

Som utvikler, hvordan skal jeg egentlig forholde meg til det når det gjelder arbeidet mitt, min del av virksomheten eller tjenestene jeg eier? Å distribuere raskere betyr åpenbart kanskje at du må levere mer, men fører det til flere feil? Vil påliteligheten gå ned fordi jeg leverer mer?

Det er så mange variabler som spiller inn, og det er her innsatsmålinger blir svært viktige, fordi innsatsmålingene til syvende og sist påvirker resultatmålingene. For distribusjonsfrekvens kan det derfor hende at du innfører en prosess for å få den til å øke.

Jeg kan gi deg et eksempel. En av kundene våre, Riley, hadde et svært lignende initiativ. De fulgte distribusjonsfrekvensen ved hjelp av et av våre kontrollpaneler for utviklerinnsikt. De fant ut at de ønsket at utviklerne skulle distribuere raskere, men måten de skulle gjøre det på, var å innføre viktige sikkerhetsbarrierer for hvordan utviklerne distribuerer, og gi dem tydelige retningslinjer for hvordan en god distribusjon ser ut med hensyn til retningslinjene deres for pålitelighet.

Det som skjedde, var at utviklerne forsøkte å distribuere raskere, men det førte til feil eller at ting sluttet å fungere. Derfor nølte de med å bevege seg så raskt som mulig, fordi det oppsto en stor påvirkning på kundene. Når de gikk tilbake til innsatsmålingene, utarbeidet de i praksis en sjekkliste for produksjonsberedskap. Den besto av åtte eller ni ulike innsatsmålinger som samlet ga en svært god forståelse av om distribusjonsprosessen faktisk var sunn eller ikke.

Målingene var for eksempel: Er oppsettet for beredskapsvakt riktig konfigurert? Består byggeprosessen? Har du tester som består for tjenestene dine? Ved å innføre disse innsatsmålingene fikk utviklerne en svært tydelig rettesnor: «Greit, jeg eier disse ti tjenestene. Dette er prosessen, og dette er innsatsmålingene som faktisk betyr noe for meg, fordi de representerer tjenestene og hvordan de fungerer.»

Det de så, var en gradvis økning i distribusjonsfrekvensen fra to ganger i uken til tre og deretter fire, særlig for de kritiske tjenestene. Samtidig gikk antallet hendelser og lignende ned.

Tilbake til det opprinnelige spørsmålet ditt: Mange virksomheter tenker «Ja, vi har disse resultatmålingene, men hvordan oversetter jeg dem til noe utviklerne bryr seg om?» Du må tenke på utviklerproduktivitet og målinger generelt som en helhetlig historie mellom de to.

Hannah Clark: Ja, det gjør det mye mer helhetlig. Når vi skifter tema litt, men fortsatt holder oss til å distribuere mer og raskere, kan vi ikke ha en samtale om utvikling i 2025 uten å snakke om «vibe coding».

La oss snakke om AI-verktøyene som forvandler arbeidsflyten for koding akkurat nå. Jeg har hørt deg si at du ikke kan «vibe code» deg frem til én million brukere per dag. Kanskje en kontroversiell mening, kanskje ikke. Hva vil du si er virkeligheten kontra hypen når det gjelder å bruke AI i produksjonsmiljøer i stor skala?

Anish Dhar: Det er absolutt et svært aktuelt tema, og jeg tror alle utviklingsorganisasjoner tenker på AI eller har tatt i bruk en form for AI-kodeassistent. Det finnes flere svært populære løsninger i markedet, blant annet Cursor. Nesten hele utviklingsteamet i Cortex bruker en eller annen form for AI-kodeassistent i det daglige arbeidet.

Det vi har funnet gjennom samtaler med utviklerne våre og ved å jobbe med de fleste kundene våre, er at AI-kodeassistenter er gode når du har en første idé og ønsker å validere noe raskt. De er også nyttige hvis du er frontendutvikler og raskt vil lage en skisse av hvordan noe kan se ut og føles.

Fra et utviklingsprosessperspektiv er det perfekt til slike ting. Du vil ha noe raskt og enkelt som viser folk hvordan noe kan fungere. Eller hvis du har en idé som gründer og raskt vil validere den, ser du en fantastisk vekst i bruken av slike verktøy.

Men realiteten for kodeassistenter og «vibe coding» i dag er at du aldri kan stole på kode som er levert gjennom «vibe coding» til å drive et produksjonssystem som brukes av millioner av ulike brukere. Det er erfaringen vår basert på det vi har sett.

Til syvende og sist er «vibe coding» på sitt beste som en juniorutvikler som nettopp har lært å kode, sammenlignet med senior- og stabsutviklere som forstår systemdesign og hvordan infrastruktur faktisk distribueres i stor skala. Vi er ikke i nærheten av det ennå, og jeg sier ikke at vi ikke kan komme dit.

Utviklingstakten innen AI er utrolig. Det ville være dumt å si at det ikke finnes en fremtid der AI-systemer kan forstå faktiske produksjonsinstanser. Men realiteten i dag er at ingen virksomhet er avhengig av «vibe coding» for å drive et produksjonssystem som håndterer millioner eller milliarder av brukere. Det tekniske nivået du trenger for å sette opp, diagnostisere og skalere slike systemer, er vi ganske enkelt ikke i nærheten av.

Som helhet vil jeg likevel si at produktiviteten har økt med kodeassistenter. Det skjer bare på andre områder enn det markedet kanskje liker å snakke om, eller enn det som er spennende å snakke om når det gjelder «vibe coding».

Realiteten er at dette ganske enkelt ikke er klart for produksjonssystemer i virksomheter.

Hannah Clark: Jeg tror dette er gjenkjennelig for mange fagfolk som opplever at personer utenfor deres fagområde blir begeistret over hvor tilgjengelig faget deres blir ved hjelp av AI-verktøy. Men det betyr ikke nødvendigvis at AI kommer rett bak deg.

Dette er viktig å snakke om. Vi har ledere som lytter til programmet. For utviklingsledere som prøver å balansere investeringer i AI-verktøy mot bemanning: Hva bør de vurdere? Fra ditt perspektiv, hvordan evaluerer man den faktiske innvirkningen AI har på et teams produktivitet, og hvordan tar man hensyn til dette i budsjettet?

Anish Dhar: Det er et godt spørsmål. Det har mange sider. På et overordnet nivå mener jeg at utviklingsteam eller utviklingsledere som hindrer teamene sine i å se på disse verktøyene eller bruke dem, gjør en stor bjørnetjeneste mot den langsiktige helsen og kvaliteten til utviklingsteamet.

Realiteten er at mange av systemene, eller i det minste den første koden folk skriver, vil være AI-assistert de neste ti årene. Hvis du starter et selskap, begynner på en idé eller ønsker å iterere og teste noe raskt, går det rett og slett ti ganger raskere med noe som Cursor, fordi du kan iterere over ideene dine så raskt uten å måtte tenke på skala eller hvordan alt fungerer.

Selv med et svært langsiktig perspektiv er det derfor viktig at utviklingsteam tar i bruk disse AI-verktøyene og lærer å bruke dem på ulike deler av utviklingsforløpet. Selv i de største virksomhetene, der du trenger produksjonssystemer i stor skala, vil utviklerne samlet sett ha en fordel sammenlignet med dem som sier at dette bare er hype.

Utviklingsledere bør la teamene utforske slike verktøy og til og med gi ikke-tekniske brukere tilgang. Det mest interessante jeg har sett, særlig blant kundene våre, er produktledere, tekniske produktledere og dataforskere som forstår tekniske konsepter, men kanskje ikke har hatt kompetansen til å programmere. De kan ta ideer og dele dem med utviklingsteamet på en langt kraftigere måte fordi de faktisk kan sette opp kode og lignende.

Fra det perspektivet ville det være uklokt å ikke sette av budsjett til å gi utviklerne tilgang til disse verktøyene.

Det store spørsmålet er hvor mye produktivitet vi faktisk får ut av dette. Og jeg tror ærlig talt at alle virksomheter prøver å finne svaret akkurat nå. Kundene kjøper ofte produktet vårt sammen med noe som GitHub Copilot. Det første spørsmålet de stiller, er: «Vi har dette verktøyet som skal øke resultatet til utviklingsteamet vårt tre- eller firedobbelt. Hvordan finner vi ut om det faktisk skjer?»

Det går tilbake til systemet med innsats- og resultatmålinger som jeg snakket om tidligere. Det er ikke nok å bare hente opp distribusjonsfrekvens og si «Greit, har GitHub Copilot hatt en innvirkning på dette?» Kanskje Copilot gjør at du leverer raskere, men koden er svært dårlig. Da fører det til problemer med påliteligheten.

Du må derfor ta et nesten 360-graders perspektiv og se på ulike målinger. Til syvende og sist handler det om fremragende ingeniørarbeid. Som virksomhet må du se bort fra «vibe coding» og alt annet og spørre: Hva fokuserer vi på akkurat nå? Hva hindrer oss i å nå neste vekstnivå, eller det som ellers er viktig for virksomheten?

Du må vurdere om innføringen av kodeassistenten eller AI-verktøyet faktisk utgjør en forskjell eller skaper en innvirkning fra dette perspektivet. I en periode vil du kanskje ikke se noen tydelig effekt, fordi det tar tid å forstå hvor slike verktøy vil påvirke virksomheten.

Feilen jeg ser mange virksomheter gjøre, er å kjøpe seg inn i hypen umiddelbart. De kjøper 5 000 lisenser av et hvilket som helst nytt og spennende verktøy, og seks måneder senere spør de: «Har dette faktisk hatt noen innvirkning?» Du kan få en svært negativ reaksjon hvis du ikke har en gjennomtenkt strategi for hvorfor dere innfører slike verktøy.

Strategien kan være at dere ikke ønsker å bli hengende etter, og at dere vil at utviklerne fortsatt skal oppleve arbeidsplassen som ledende. Dere mener kanskje bare at det er en fordel å ha AI-assisterte verktøy i utviklingsteamet. Selv om det er så enkelt, vet dere i det minste hvorfor dere kjøper det. Feilen er kanskje nettopp å ikke forstå intensjonen, slik at dere kan kontrollere underveis om verktøyet faktisk gjør det dere forventet.

Hannah Clark: Jeg er tilbøyelig til å være enig. Akkurat nå er det et stort press om å mestre disse verktøyene og finne ut hvor de passer inn i arbeidsflyten. Men på tvers av mange avdelinger ser vi stor forskjell mellom mengden som produseres og kvaliteten på resultatene.

Vi må være svært bevisste, ikke bare i utviklingsavdelingene, men også på om vi bruker disse verktøyene i riktig sammenheng for å legge til rette for og styrke det beste i bemanningen vår, i stedet for å prøve å regne med at neste års bemanning blir lavere fordi AI-verktøy vil kunne erstatte folk.

Det er interessant å se at alle prøver å finne ut av dette på ulike måter samtidig. Det er en svært desorienterende tid å være i teknologibransjen. Når vi snakker om AI-verktøy som blir stadig mer utbredt i utviklingsarbeidsflyter, og om kvalitet, hvordan finner vi balansen mellom å opprettholde kodekvalitet, sikkerhetsstandarder og pålitelighet, samtidig som vi ønsker å være ledende arbeidsplasser og utnytte verktøyene best mulig?

Hvordan har dere for eksempel gått frem i deres egen organisasjon?

Anish Dhar: Det er et veldig godt spørsmål. Først vil jeg si at ideen om at AI erstatter utviklere, er så fjern og tåpelig. Det som kanskje er riktig, er at du i starten kan ansette litt færre enn 15 utviklere, fordi du kan gjøre så mye mer med et verktøy som Cursor enn tidligere. Du kan prøve ut ti ulike ideer svært raskt, og hastigheten på iterasjonene er utrolig verdifull.

Men når du faktisk distribuerer produksjonssystemer, prøver virksomheter som sier at de ikke trenger å ansette like mange utviklere på grunn av AI, bare å skape litt medieoppmerksomhet. Det er ganske enkelt ikke riktig. Utviklere vil fortsatt være etterspurt.

Når vi går tilbake til spørsmålet ditt om hvordan AI-verktøy og AI-kodesystemer påvirker sentrale søyler som pålitelighet og sikkerhet, er det ærlig talt det store åpne spørsmålet akkurat nå. Det er sannsynligvis det som skremmer disse teamene mest, særlig SRE-, sikkerhets- og driftsforbedringsteamene.

Innføringen av disse verktøyene skaper til syvende og sist et større angreps- og risikoområde, fordi folk leverer mer kode. Jo større del av systemet som bygges med AI, desto større er sannsynligheten for at du ikke egentlig forstår hvordan alt fungerer internt.

Det betyr at når det uunngåelig oppstår et pålitelighetsproblem, står du i en mye vanskeligere situasjon. Pålitelighetsproblemer er konstante. Uansett hvor godt du forbereder deg, vil det en dag skje noe, enten det er en tilstrømning av brukere du ikke forutså, eller en del av kodebasen du ikke forsto fullt ut, som bryter sammen.

Jo mer AI-assistert systemet ditt er, desto vanskeligere er det for en utvikler å gå gjennom alle delene av kodebasen hvis han eller hun ikke forstår den fullt ut. Det er kanskje den største ulempen jeg ser akkurat nå.

Derfor blir det viktigere enn noen gang å ha det grunnleggende laget av fremragende ingeniørarbeid: fullstendig innsyn og tydelig eierskap. Dette er sentrale søyler i ethvert initiativ for fremragende ingeniørarbeid.

Jo flere av systemene dine som opprettes gjennom AI, desto mindre dekning har du av disse områdene. Hvem eier det egentlig, og hvem forstår det? Dette er de viktigste tingene som skremmer mange sikkerhets- og pålitelighetsteam.

Vi ser dette hos noen av kundene våre, og vi ser det også i vårt eget utviklingsteam. Når vi publiserer kode med AI, eller noe er opprettet med AI, er utviklerne nøye med å si at noe av koden er hundre prosent generert gjennom Cursor eller et annet verktøy, og vi undersøker disse systemene ekstra grundig.

Jeg har sett en enorm trend innen AI-assistert testing. Mange selskaper lager faktisk en AI-utvikler som gjennomgår testene dine og lignende. Noen ganger synes jeg det er litt risikabelt, for AI-systemer er ekstremt kraftige og gjør mer godt enn skade i utviklingsteam i dag.

Men det er skremmende å tenke på en verden der 80 % av systemet mitt er bygget gjennom AI. Det kan føre til pålitelighetsproblemer, og det kan ta lengre tid å løse systemproblemer. Antallet sikkerhetshendelser kan øke fordi du har mindre innsyn. Det er dette du må passe på.

Hannah Clark: Jeg er tilbøyelig til å være enig, og jeg tror dette er det mindre omtalte logistikkproblemet mange team håndterer når det gjelder økt produksjon, som også betyr et økt behov for oppfølging.

I forrige uke snakket vi med seniorvisepresidenten for produktledelse hos Mastercard Gateway. Han fortalte hvordan mange AI-verktøy virkelig akselererer arbeidet med å fullføre ting som skjemaer for å komme inn i nye markeder. Mengden papirarbeid som kreves for å etablere seg i et nytt marked og overholde alle reguleringene, er enorm.

AI gjør det mulig å fullføre mye av dette svært raskt. Men det må også finnes et tilsvarende nivå av oppfølging for å sikre eierskap til innsendingene. Det blir et slags press og motpress: Du kan fullføre det raskere, men du må også kunne stå til ansvar i samme tempo.

Det høres ut som en stor logistisk flaskehals for mange utviklingsteam, i tillegg til andre som bruker disse verktøyene for å akselerere arbeidet. Vi kan altså levere raskt, men kan vi samtidig si at vi er ansvarlige for arbeidet i samme tempo?

Dette er svært interessant å snakke om. Vi har nå snakket med ledere i mange ulike avdelinger og fagområder, og det er fascinerende å se hvor parallelle mange av bekymringene er, selv om fagområdene er svært forskjellige.

Jeg setter stor pris på alle innsiktene du har delt i dag. Det var siste del av episoden vår. Hvor kan folk følge deg på nettet, Anish?

Anish Dhar: Du kan følge meg på LinkedIn eller Twitter. Hvis du søker på navnet mitt, finner du meg. Du kan også finne Cortex på LinkedIn.

Vi publiserer alltid nytt innhold, og vi arrangerer faktisk Android Access-toppmøter over hele verden. Hvis det finnes et i en by nær deg, bør du absolutt komme innom. Vi ønsker å bygge et fellesskap av mennesker som tenker på denne typen spørsmål. Alle selskaper vurderer dem, så det er flott å se et så godt fellesskap vokse frem.

Vi har også begynt å arrangere konferansen vår, IDPCON, som i stor grad handler om fremragende ingeniørarbeid. Der møter vi ledere fra ulike typer virksomheter og utviklere som ønsker å knytte kontakt med andre utviklere rundt dette temaet.

Det blir mange gode foredrag. Konferansen arrangeres i New York i oktober, så forhåpentligvis sees vi der også.

Hannah Clark: Det høres fantastisk ut. Takk for informasjonen. Vi sørger for å legge det inn i beskrivelsen, og tusen takk for at du tok deg tid til å være med oss.

Anish Dhar: Takk for invitasjonen. Det var flott.

Hannah Clark: Takk for at du lyttet. For flere gode innsikter, veiledninger og verktøyanmeldelser kan du abonnere på nyhetsbrevet vårt på theproductmanager.com/subscribe. Du kan høre flere samtaler som denne ved å abonnere på The CPO Club der du får podkastene dine.