Hur ser teknisk excellens ut i AI-eran?

Läs transkriberingen:

Vi testar att transkribera våra poddar med hjälp av ett datorprogram. Ha överseende med eventuella stavfel eftersom boten inte är korrekt till 100 procent hela tiden.

Hannah Clark: Det har blivit ett skämt hur AI-eran har lett till att alla jobb inom teknik försvinner. Faktum är att så många jobb har dött i år. Jag är förvånad över att jag inte har blivit bjuden till fler begravningar. Produktledning är död, användarforskning är död och mest upprörande av allt: programvaruutveckling är död. Jag predikar förmodligen för kören här, men den som verkligen tror att programvaruutveckling är död eftersom din vänliga lokala stora språkmodell kan skriva kod är definitivt inte själv utvecklare.

Min gäst idag, Cortex.io-grundaren Anish Dhar, skulle till och med hävda att tekniskt utvecklingsarbete definitivt inte är dött. Det håller bara på att växa upp. Anish var tidigare utvecklare på Uber och grundade Cortex för att göra det enklare för utvecklare att förstå komplexa kodbaser. Som utvecklare själv och som någon vars användare är utvecklare ser han faktiskt en utveckling inom detta område, där den tekniska excellensen förändras och där det finns en koppling mellan nya och gamla sätt att mäta den. Vi delar nästa generations tankar om hur man mäter och utvärderar teknisk excellens, samt en kontroversiell syn på hur trenden med så kallad stämningskodning passar in i samtalet. Nu kör vi.

Förresten håller vi sådana här samtal varje vecka, så om det här låter intressant för dig, varför inte prenumerera? Okej, nu kör vi.

Välkommen tillbaka till The CPO Club-podden. Jag har idag sällskap av Anish Dhar. Han är grundare av Cortex.io.

Anish, tack för att du tog dig tid att prata med mig idag.

Anish Dhar: Tack så mycket för att jag fick vara med.

Hannah Clark: Kan du berätta lite om din bakgrund och hur du hamnade i din nuvarande roll?

Anish Dhar: Absolut. Jag är medgrundare och vd för Cortex.io. Vi startade företaget för ungefär sex år sedan, men innan dess arbetade jag som utvecklare på Uber. Jag började egentligen min karriär där, och många av problemen jag mötte som utvecklare på Uber inspirerade faktiskt alla anledningar till att vi startade Cortex.

Jag hade två mycket nära vänner. Uber har en enorm intern tjänstearkitektur. Som utvecklare där var det verkligen svårt för mig att förstå olika delar av kodbasen, särskilt när jag började. Det fanns så många olika tjänster som byggdes. Det skapade en intensiv komplexitet, och jag pratade med en mycket nära vän till mig som var utvecklare på ett mycket litet nystartat företag som hette Lend.

De hade bara hundra utvecklare medan Uber hade över tusen. Men vi mötte båda liknande utmaningar när det gällde att organisera och förstå våra tjänstearkitekturer. Det ringde varningsklockor: om Uber befinner sig i ena änden av skalan och ett annat företag, som precis har börjat sin resa med mikrotjänster, har samma problem, är det uppenbart att detta är ett stort problem i branschen.

Därför startade vi till slut företaget. Vi gick igenom Winter 20 Y Combinator-programmet. Sedan, ja, spola fram till idag. Vi har precis genomfört vår serie C och arbetar med några hundra olika företag som använder Cortex för att hantera sin komplexitet.

Hannah Clark: Häftigt. Det är en fantastisk resa, och det är alltid underbart att höra när ett företag uppstår ur ett problem som man själv känner väl till.

På tal om det ska vi prata om teknisk excellens och hur det ser ut inom dagens tekniklandskap i det här avsnittet. Det här är förstås en fråga som har varit nära dig under hela din karriär. För att börja: hur definierar du teknisk excellens år 2025, och varför blir det ett så viktigt fokus för CTO:er och teknikchefer just nu?

Anish Dhar: Det är en bra fråga. Det vi har upptäckt på Cortex är att samtalet under lång tid främst har handlat om utvecklarupplevelsen. Utvecklarupplevelsen är en mycket viktig del av varje utvecklingsorganisation, eller hur? Det handlar om enkla saker som att se till att utvecklare, när de börjar på ett företag, enkelt kan konfigurera sina interna system och ansluta till GitHub och de olika verktyg de använder. Eller när de kanske distribuerar en tjänst ska infrastrukturen vara korrekt konfigurerad, så att det inte krävs mycket felsökning eller många steg för att komma i mål.

Men vad vi har sett under de senaste åren, särskilt, är att samtalet har skiftat från enbart utvecklarupplevelse till det vi kallar teknisk excellens. Den stora skillnaden mellan de två är enligt min mening att teknisk excellens verkligen fokuserar på olika team inom organisationen.

Det kan handla om SRE, säkerhet, utvecklarproduktivitet och även utvecklarupplevelse, men det kopplar verkligen samman dem med konkreta affärsresultat. Det är den viktigaste skillnaden: teknisk excellens handlar om hur det arbete jag utför faktiskt påverkar verksamheten och hur det för den framåt.

Målen sträcker sig hela vägen från vd:ns organisation ner till den specifika SRE som arbetar med frågan. Ett bra exempel är att organisationen kanske fokuserar på att förbättra kundupplevelsen och vill att produkten ska vara tillförlitlig när kunderna använder den. En bättre kundupplevelse leder till ökade intäkter eftersom människor använder produkten mer.

Ur perspektivet teknisk excellens kan SRE-teamet då ha en checklista för produktionsberedskap som de försöker införa. Innan tjänster distribueras vill de säkerställa att alla tjänster uppfyller organisationens standarder. Man kan alltså se hur ett initiativ som börjar hos SRE-teamet leder tillbaka till ett verkligt affärsresultat som organisationen bryr sig om.

Det är mycket viktigt att team tänker på sina initiativ på det här sättet, eftersom det bekräftar värdet och kopplar de tekniska initiativen till något som verksamheten bryr sig om. Det är, enligt min mening, vad teknisk excellens handlar om.

Hannah Clark: Intressant. Det här är, som du säkert har beskrivit många gånger, en resa utan slut, som kräver att många discipliner arbetar tillsammans.

Berätta om det ramverk ni har utvecklat. Vilka är de viktigaste pelarna? Hur ser ni på detta i den egna organisationen?

Anish Dhar: Du har helt rätt. Det är verkligen en resa utan slut. Många av de företag vi arbetar med, särskilt stora företag, har mycket äldre infrastruktur jämfört med ett nytt företag som bygger på nyare teknik och kanske är AI-baserat från början.

Det finns fortfarande olika initiativ kring teknisk excellens, och de kräver ett genomtänkt angreppssätt från alla dessa team. Man måste fråga sig vilket arbete som behöver utföras och hur det i slutändan påverkar verksamhetens mål för excellens. Ur ett ramverksperspektiv har vi därför arbetat mycket med frågan: hur definierar man teknisk excellens för sin organisation?

Vi ser det som att det börjar med affärsmässig excellens. Ledningsgruppen har olika mål, till exempel att frigöra innovation och minska tiden till marknaden. Det kan också handla om att sänka kostnader och öka effektiviteten. Det tredje målet vi vanligtvis ser, och som jag nämnde tidigare, är att förbättra kvaliteten och kundupplevelsen.

Under detta finns pelarna för teknisk excellens. Det är de olika teamen och yrkesrollerna som tillsammans utgör de initiativ som driver de slutliga målen. Det kan handla om leveranshastighet, effektivitet, säkerhet och tillförlitlighet. Även inom dessa underkategorier finns initiativ, till exempel en säkerhetsmigrering eller en checklista för produktionsberedskap.

Kanske finns det en process för incidenthantering som man försöker införa. Eller så enkelt som att man vill följa DORA-mått för att förstå hur utvecklingsteamet faktiskt presterar ur ett produktivitetsperspektiv. Grunden för alla initiativ kring teknisk excellens består av det vi kallar de fyra C:na.

Det handlar i huvudsak om fullständig insyn, kontinuerlig förbättring, en konsekvent utvecklarupplevelse och naturligtvis tydligt ägarskap. Utan ägarskap och förståelse för de olika delarna av kodbasen och alla tjänster är det mycket svårt att driva dessa initiativ framåt. Vi ser därför vanligtvis att det är mycket svårt att driva initiativ utan denna grund.

Vi ser också ofta att interna utvecklarplattformar eller interna portaler är ett mycket bra sätt att bygga denna grund. Det kan även göras med interna verktyg, men man behöver någon form av system för att förstå vad människor bygger så att man kan driva dessa tekniska initiativ framåt.

Hannah Clark: Jag vill gå djupare in på något du nämnde om att mäta prestation, eftersom jag vet att det finns en viss spänning kring att mäta utvecklarproduktivitet och mått som antal kodrader.

Det kan vara kontroversiellt bland utvecklare. Hur bör tekniska ledare tänka kring att mäta produktivitet på ett mer holistiskt sätt som tar hänsyn till alla dessa C:n och liknande?

Anish Dhar: Det intressanta är att mycket av utvecklarproduktiviteten under de senaste åren har handlat om antal kodrader eller DORA-mått. Det finns många olika ramverk som försöker förenkla hur man tänker kring produktivitet, och det finns en viss sanning i hur dessa mått beräknas.

Antalet kodrader är inte en bra indikation på om någon är produktiv eller inte. Men om du konsekvent levererar noll kodrader, kvartal efter kvartal, är det uppenbart att något är fel med resultatet. Även när man jämför team kan det ibland vara intressant att se dessa datapunkter. Men samtalet har verkligen skiftat från att säga ”jag har den här datan” till ”hur får jag faktiskt utvecklare att tänka på datan eller förbättra den?”

Om man bryter ner det är det ett helt annat problem, och ett mycket svårare sådant. Vem som helst kan anropa GitHubs API och få dessa mått, vilket ger en ögonblicksbild av hur teamet presterar. Men bara för att jag visar en uppsättning mått för en utvecklare och säger att vi måste förbättra det här måttet, betyder det inte särskilt mycket för utvecklaren.

Utvecklaren fokuserar på att bygga programvara för verksamheten och försöker vanligtvis göra det så effektivt som möjligt. Samtalet har därför, särskilt med de CTO:er vi arbetar med, skiftat till frågan: jag har dessa mått, men hur översätter jag dem till något som utvecklaren bryr sig om?

Det är där teknisk excellens spelar en så viktig roll. Utvecklare, särskilt de som arbetar på snabbväxande företag, vill att verksamheten ska växa. De bygger produkter eftersom de vill se vilken effekt deras arbete har på kunderna.

Utvecklingsproduktivitet har verkligen skiftat från ”här är en massa mått” till ”som företag är det här sakerna vi bryr oss om, och dessa mått berättar en del av den historien”. För en utvecklare handlar det om att översätta detta till något där det arbete jag faktiskt utför betyder något.

Det är den stora förändring vi har sett.

Hannah Clark: Har du märkt att det finns föråldrade utvärderingsmetoder eller KPI:er som människor börjar överge? Vad skulle du säga är den nya skolan inom utvärdering? Har du några konkreta exempel?

Anish Dhar: Jag skulle tänka på produktivitet som mått på insats och resultat. Resultatmått är alla de klassiska ramverk som används idag för att följa utvecklarproduktivitet. Ett av de mest kända och populära är DORA-måtten, som består av flera olika mått som tillsammans ska ge en holistisk bild av hur utvecklingsteamet presterar.

De flesta utvecklingsorganisationer vill se dessa resultatmått och försöker fånga dem. Men det återgår till det jag sade tidigare: hur påverkar jag faktiskt dessa mått och får dem att förändras? Det vi har sett, särskilt bland våra kunder, och en anledning till att Cortex har vuxit på det sätt det har gjort, är konceptet med insatsmått som påverkar resultatmått.

Ta till exempel distributionsfrekvens. Det är ett bra mått eftersom den takt i vilken utvecklare distribuerar programvara förmodligen är en bra indikator på hur snabbt man levererar produkten. I slutändan handlar det om hur man slår konkurrenterna på marknaden och hur man rör sig snabbare som företag.

Organisationen kanske har bestämt att distributionsfrekvens är det viktigaste måttet. Man kan ha en instrumentpanel som visar distributionsfrekvensen och ta upp den på ett målstyrningsmöte inför hela utvecklingsteamet: ”Vi distribuerar två gånger i veckan och vill komma upp till fyra.”

Men som utvecklare, hur ska jag koppla det till mitt arbete, min del av verksamheten eller de tjänster jag äger? Att distribuera snabbare innebär kanske att man måste leverera mer, men leder det till fler fel? Kommer tillförlitligheten att minska eftersom jag levererar mer?

Det finns så många variabler i detta, och därför blir insatsmåtten så viktiga. Insatsmåtten påverkar i slutändan resultatmåtten. När det gäller distributionsfrekvens kanske man inför en process för att faktiskt få den att öka.

Jag kan ge ett exempel. En av våra kunder hade ett mycket liknande initiativ och följde distributionsfrekvensen med hjälp av en av våra instrumentpaneler för utvecklarintelligens. De upptäckte att de ville att utvecklarna skulle distribuera snabbare, men sättet att göra det var att införa viktiga skyddsräcken för hur utvecklare distribuerar och ge tydliga riktlinjer för hur en bra distribution ser ut i relation till organisationens tillförlitlighetsriktlinjer.

Det som hände var att utvecklarna försökte distribuera snabbare, men det ledde till fel eller att saker gick sönder. Därför fanns det en tvekan inför att röra sig så snabbt som möjligt, eftersom det påverkade kunderna. När de återgick till insatsmåtten tog de fram en checklista för produktionsberedskap med åtta eller nio olika insatsmått. Tillsammans gav de en god bild av om distributionsprocessen faktiskt var sund eller inte.

Måtten handlade om huruvida beredskapen för jourarbete var korrekt konfigurerad, om byggprocessen klarade sig och om testerna för tjänsterna passerade. Genom att införa dessa insatsmått fick utvecklarna tydliga riktlinjer: ”Jag äger de här tio tjänsterna. Det här är processen, och det här är insatsmått som betyder något för mig eftersom de representerar tjänsterna och hur de fungerar.”

De såg en gradvis ökning av distributionsfrekvensen från två gånger i veckan till tre och sedan fyra, särskilt för kritiska tjänster. Samtidigt minskade antalet incidenter.

Om vi återgår till din ursprungliga fråga tror jag att många företag tänker: ”Vi har dessa resultatmått, men hur översätter vi dem till något som utvecklarna bryr sig om?” Man måste tänka på utvecklarproduktivitet och mått i allmänhet som en komplett berättelse där insats och resultat hänger samman.

Hannah Clark: Det gör det mycket mer, ja. Jag tycker att holistiskt är ett bra sätt att se på det. Om vi byter ämne lite, men fortfarande håller oss till att distribuera mer och snabbare, kan vi inte prata om utveckling år 2025 utan att prata om stämningskodning.

Låt oss prata om AI-verktygen som förändrar arbetsflödena för kodning just nu. Jag har hört dig säga att man inte kan stämningskoda sig fram till en miljon användare per dag. Kanske är det en kontroversiell åsikt, kanske inte. Vad är verkligheten jämfört med hypen när det gäller att använda AI i produktionsmiljöer i stor skala?

Anish Dhar: Det är definitivt ett mycket aktuellt ämne, och jag tror att alla utvecklingsorganisationer funderar på AI eller har infört någon form av AI-assistent för kodning. Det finns flera mycket populära alternativ på marknaden, bland annat Cursor. Nästan hela utvecklingsteamet på Cortex använder någon form av AI-assistent för att hjälpa dem i vardagen.

Det vi har upptäckt när vi pratat med utvecklare i vårt team och arbetat med våra kunder, som har funderat på liknande initiativ, är att AI-stöd för kodning är fantastiskt när man har en första idé och snabbt vill validera något. Det är också bra om man är frontendutvecklare och snabbt vill skapa en prototyp för att se hur något kan se ut och kännas.

Ur ett utvecklingsprocessperspektiv är det perfekt för sådant. Man vill ha något snabbt och enkelt som man kan visa andra, eller så har man en idé som entreprenör och vill validera den snabbt. Där ser man en otrolig utveckling.

Men verkligheten för kodassistenter och stämningskodning idag är att man inte kan lita på kod från stämningskodning för att driva ett produktionssystem som används av miljontals användare. Det är helt enkelt den erfarenhet vi har gjort.

I bästa fall är stämningskodning som en junior utvecklare som precis har lärt sig koda. Där är vi inte i närheten av den nivå som seniora utvecklare och huvudingengörer har, med förståelse för systemdesign och hur infrastruktur faktiskt distribueras i stor skala. Jag säger inte att vi aldrig kan nå dit. AI utvecklas i en otrolig takt, och det vore dumt att säga att AI-system aldrig kan förstå verkliga produktionsinstanser.

Men verkligheten idag är att inget företag förlitar sig på stämningskodning för att driva ett produktionssystem som hanterar miljontals eller miljarder användare. Den tekniska expertis som krävs för att konfigurera, diagnostisera och skala sådana system är helt enkelt långt mer omfattande.

Samtidigt skulle jag säga att produktiviteten har förbättrats med kodassistenter. Det sker bara inom andra områden än de som marknaden kanske gärna talar om, eftersom det låter mer spännande att prata om stämningskodning.

Men verkligheten är att tekniken ännu inte är redo för produktionssystem i företagsskala.

Hannah Clark: Jag tror att många yrkesverksamma känner igen det. Personer utanför ens yrke blir entusiastiska över hur lättillgängligt yrket blir med AI-verktyg, men det betyder inte nödvändigtvis att AI kommer direkt efter dig.

Det här är viktigt att prata om. Vi har ledare som lyssnar på programmet. För tekniska ledare som försöker balansera investeringar i AI-verktyg mot personalstyrkan: vad bör de tänka på? Hur utvärderar man den faktiska påverkan AI har på ett teams produktivitet, och hur tar man hänsyn till den i budgeten?

Anish Dhar: Det är en bra fråga. Det finns många olika aspekter. På en övergripande nivå tycker jag att tekniska team eller ledare som hindrar sina team från att använda dessa verktyg, eller hindrar dem från att få tillgång till till exempel Cursor eller GitHub Copilot, gör en stor otjänst mot teamets långsiktiga hälsa och kvalitet.

Om tio år kommer mycket av de system, eller åtminstone den första kod, som människor skriver att vara AI-stödd. Om man startar ett företag, börjar på en idé eller vill iterera och testa något snabbt går det tio gånger snabbare med verktyg som Cursor. Man kan snabbt iterera på idéer utan att behöva tänka särskilt mycket på skala eller hur saker fungerar.

Även ur ett långsiktigt perspektiv kommer utvecklingsteam som använder dessa AI-verktyg och lär sig hur de fungerar i olika delar av kodlivscykeln att ha en fördel. Det gäller även de största företagen, där man behöver produktionssystem i stor skala. Därför är det viktigt att tekniska ledare låter sina team utforska dessa verktyg och även ger icke-tekniska användare tillgång till dem.

Det mest intressanta jag har sett, särskilt bland våra kunder, är produktchefer, tekniska produktchefer och datavetare som förstår tekniska koncept men kanske inte har haft kompetensen att koda. De kan ta idéer och dela dem med utvecklingsteamet på ett mycket kraftfullare sätt eftersom de faktiskt kan skapa kod och liknande.

Ur det perspektivet vore det mycket oklokt att inte budgetera för att ge utvecklarna tillgång till dessa verktyg.

Den stora frågan är hur mycket produktivitet vi faktiskt vinner. Varje företag försöker besvara den frågan just nu. Kunder köper ofta vår produkt tillsammans med något som GitHub Copilot. Den första frågan de ställer är: ”Vi har det här verktyget som ska tredubbla eller fyrdubbla utvecklingsteamets resultat. Vill vi ta reda på om det faktiskt händer.”

Det återgår till systemet med insats- och resultatmått som jag pratade om tidigare. Det räcker inte att bara ta fram distributionsfrekvensen och säga: ”Har GitHub Copilot påverkat den?” Copilot kanske gör att man levererar snabbare, men koden kan vara dålig och leda till problem med tillförlitligheten. Man måste därför ha ett nästan 360-gradersperspektiv och titta på olika mått.

Det återgår i slutändan till teknisk excellens. Som företag, bortsett från stämningskodning och allt annat: vad fokuserar vi på just nu? Vad hindrar oss från att nå nästa tillväxtnivå? Man måste fråga sig om införandet av kodassistenten eller AI-verktyget faktiskt gör skillnad eller skapar påverkan ur det perspektivet.

Det kan ta lite tid innan man ser effekten. Man behöver förstå var den här typen av verktyg påverkar verksamheten. Ett misstag jag ser många företag göra är att omedelbart köpa in sig i hypen, till exempel köpa 5 000 licenser av något nytt verktyg och sedan, sex månader senare, fråga om det faktiskt har haft någon effekt.

Utan en genomtänkt strategi för varför man inför verktygen kan reaktionen bli mycket negativ. Strategin kan vara att man inte vill hamna efter, att man vill att utvecklarna ska känna att detta är en arbetsplats i teknisk framkant eller att man helt enkelt bedömer att AI-stödda verktyg är en fördel för utvecklingsteamet.

Även om det är så enkelt vet man åtminstone varför man köper verktyget. Det är kanske det viktigaste: förstå avsikten och kontrollera sedan längs vägen om verktyget faktiskt gör det man förväntade sig.

Hannah Clark: Jag håller med. Just nu finns det ett så stort tryck att behärska dessa verktyg och förstå var de passar in i arbetsflödet. Men inom många avdelningar ser vi en enorm skillnad mellan mängden producerat material och kvaliteten på resultaten.

Vi måste vara mycket mer avsiktliga, inte bara på utvecklingsavdelningen utan också när det gäller om vi använder verktygen i rätt sammanhang för att stärka och få ut det bästa av vår personal, i stället för att blint räkna med att nästa års personalstyrka blir mindre eftersom AI-verktyg kommer att kunna ersätta människor.

Det är intressant att se hur alla försöker förstå detta på olika sätt samtidigt. Det är en mycket förvirrande tid att arbeta inom teknik. När vi talar om AI-verktyg som blir allt vanligare i utvecklingsarbetsflöden och samtidigt om kvalitet: hur hittar vi balansen mellan att upprätthålla kodkvalitet, säkerhetsstandarder och tillförlitlighet, samtidigt som vi vill vara moderna arbetsplatser och dra nytta av verktygen på bästa sätt?

Hur har ni hanterat det i er organisation?

Anish Dhar: Det är en mycket bra fråga. Jag vill först säga att idén att AI ersätter utvecklare är så långsökt och dum. Det som däremot stämmer är att man i början kanske kan anställa några färre utvecklare än tidigare. Under de tidiga dagarna, när man itererar och försöker hitta produkt–marknad-passning, kan man göra mycket mer med ett verktyg som Cursor än någonsin tidigare.

Man kan prova tio olika idéer väldigt snabbt. Iterationshastigheten är mycket kraftfull. Men när man faktiskt distribuerar produktionssystem är företag som säger att de inte behöver anställa lika många utvecklare på grund av AI bara ute efter uppmärksamhet eller provokativa rubriker. Det stämmer helt enkelt inte.

Hannah Clark: Utan att nämna några namn.

Anish Dhar: Ja. Alla dessa företag kommer att fortsätta behöva anställa utvecklare. Efterfrågan på utvecklare kommer aldrig att försvinna.

När det gäller din fråga om hur AI-verktyg och AI-baserade kodsystem påverkar pelare som tillförlitlighet och säkerhet är det ärligt talat den stora öppna frågan just nu. Det är förmodligen det som skrämmer team som SRE, säkerhet och operativ excellens mest.

Införandet av dessa verktyg skapar i slutändan en större angreppsyta eftersom människor levererar mer kod. Ju större del av systemet som byggs med AI, desto större är risken att man inte riktigt förstår hur allt fungerar internt.

Det innebär att man hamnar i ett mycket svårare läge när det oundvikligen uppstår ett problem med tillförlitligheten. Oavsett hur mycket man förbereder sig kommer något att hända en dag. Det kan vara ett inflöde av användare som man inte förutsett eller en del av kodbasen som man inte helt förstår och som går sönder.

Ju mer AI-stött systemet är, desto svårare blir det för utvecklaren att gå igenom alla olika delar av kodbasen om man inte helt förstår den.

Det är kanske den största nackdelen jag ser just nu. Därför blir det viktigare än någonsin att ha det grundläggande lagret av teknisk excellens: fullständig insyn och tydligt ägarskap är centrala pelare i alla initiativ kring teknisk excellens.

Ju fler system som skapas med AI, desto mindre täckning får man ärligt talat inom dessa områden. Vem äger egentligen systemet? Vem förstår det? Vem har insyn? Det är de saker som skrämmer många säkerhets- och tillförlitlighetsteam.

Vi ser det hos vissa av våra kunder och även i vårt eget utvecklingsteam. När vi publicerar kod som har skapats med AI är utvecklarna mycket noga med att ange att en del av koden genererats helt med Cursor eller något liknande, och vi granskar dessa system extra noggrant.

Jag har sett en enorm trend kring AI-stödd testning. Många företag skapar nu en AI-utvecklare som granskar tester och liknande. Ibland känns det lite osäkert, eftersom AI-system i slutändan är extremt kraftfulla och idag gör mer nytta än skada för utvecklingsteam.

Men det är skrämmande att tänka på en värld där 80 procent av systemet har skapats genom AI. Det kan leda till att tillförlitlighets- och systemproblem tar längre tid att lösa. Säkerhetsincidenter kan öka eftersom man har mindre insyn. Det är det man måste vara uppmärksam på.

Hannah Clark: Jag håller med, och jag tror att det är det mindre omtalade logistiska problemet som många team hanterar när det gäller ökad produktion, vilket också innebär ett ökat behov av tillsyn.

Förra veckan pratade vi med produktledningschefen på Mastercard Gateway. Han berättade hur många AI-verktyg verkligen påskyndar möjligheten att fylla i formulär för att gå in på nya marknader. Det är en enorm mängd pappersarbete som måste göras för att komma in på en ny marknad och följa alla regler.

AI gör att mycket av detta kan slutföras mycket snabbt. Men det måste också finnas en tillsynsnivå som säkerställer att någon äger dessa inlämningar. Det finns alltså en dragkamp: man kan slutföra arbetet snabbare, men man måste också kunna ta ansvar i samma takt.

Det är en stor logistisk flaskhals för många utvecklingsteam och andra som använder dessa verktyg för att öka hastigheten. Det är en aspekt som förtjänar att betonas: visst kan vi leverera snabbt, men kan vi också säga att vi är ansvariga för arbetet i samma takt?

Det här är mycket intressant att prata om. Vi har nu pratat med ledare inom alla möjliga avdelningar och discipliner, och det är fascinerande att se hur många av dessa problem är parallella trots att disciplinerna själva är så olika.

Jag uppskattar verkligen alla insikter du har delat med dig av idag. Det avslutar vårt avsnitt. Var kan lyssnarna följa dig på nätet, Anish?

Anish Dhar: Jag skulle säga att man kan följa mig på LinkedIn eller Twitter. Om man söker på mitt namn hittar man mig. Man kan också hitta Cortex på LinkedIn.

Vi publicerar alltid innehåll och arrangerar faktiskt toppmöten om utvecklarupplevelse i städer över hela världen. Om det finns ett i en stad nära dig bör du absolut komma förbi. Vi vill skapa en gemenskap av människor som funderar på den här typen av frågor. Alla företag tänker på dem, så det är fantastiskt att se en så bra gemenskap växa fram.

Vi har också börjat arrangera vår konferens IDPCON, som verkligen kretsar kring teknisk excellens. Där deltar ledare från olika typer av företag och utvecklare som vill knyta kontakt med andra utvecklare kring teknisk excellens.

Det blir många bra föredrag. Konferensen hålls i New York i oktober, så förhoppningsvis ses vi där också.

Hannah Clark: Det låter fantastiskt. Tack för informationen. Vi ser till att lägga in det i beskrivningen. Och tack så mycket för att du tog dig tid att vara med.

Anish Dhar: Tack för att jag fick vara med. Det var trevligt.

Hannah Clark: Tack för att ni lyssnade. För fler bra insikter, guider och verktygsrecensioner kan ni prenumerera på vårt nyhetsbrev på theproductmanager.com/subscribe. Ni kan höra fler samtal som detta genom att prenumerera på The CPO Club där ni brukar lyssna på poddar.