Hvordan ser teknisk ekspertise ud i AI’s tidsalder?

Læs transskriptionen:

Vi afprøver at transskribere vores podcasts ved hjælp af et softwareprogram. Tilgiv venligst eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Hannah Clark: Det er blevet en joke, hvordan AI-æraen har ført til alle teknologijobbenes undergang. Faktisk er så mange job døde i år, at jeg er overrasket over, at jeg ikke er blevet inviteret til flere begravelser. Produktledelse er død, brugerresearch er død, og mest alvorligt af alt er softwareudvikling død. Jeg prædiker sikkert for koret her, men enhver, der virkelig tror, at softwareudvikling er død, fordi den venlige sprogmodel i nabolaget kan skrive kode, er bestemt ikke selv udvikler.

Min gæst i dag, Cortex.io-grundlæggeren Anish Dhar, vil endda argumentere for, at udvikling bestemt ikke er død. Den er bare ved at blive voksen. Anish var tidligere udvikler hos Uber og grundlagde Cortex for at gøre det lettere for udviklere at forstå komplekse kodebaser. Som udvikler selv og som en person, hvis brugere er udviklere, ser han faktisk en udvikling inden for teknisk ekspertise og en afkobling mellem nye og gamle måder at måle den på. Vi deler næste generations tanker om måling og evaluering af teknisk ekspertise samt en kontroversiel holdning til, hvordan dillen med stemningsbaseret kodning passer ind i samtalen. Lad os komme i gang.

Nå ja, vi har samtaler som denne hver uge, så hvis det lyder interessant, hvorfor så ikke abonnere? Okay, lad os komme i gang.

Velkommen tilbage til The CPO Club-podcasten. Jeg er her i dag sammen med Anish Dhar. Han er grundlæggeren af Cortex.io.

Anish, tak fordi du tog dig tid til at tale med mig i dag.

Anish Dhar: Tusind tak, fordi du inviterede mig.

Hannah Clark: Kan du fortælle os lidt om din baggrund, og hvordan du nåede frem til din nuværende rolle?

Anish Dhar: Ja, helt sikkert. Jeg er medstifter og administrerende direktør for Cortex.io. Vi startede virksomheden for omkring seks år siden, men før det arbejdede jeg som udvikler hos Uber. Jeg begyndte faktisk min karriere der, og mange af de problemer, jeg mødte som udvikler hos Uber, inspirerede alle grundene til, at vi startede Cortex.

Jeg havde to meget nære venner. Uber har en enorm intern tjenestearkitektur. Som udvikler dér var det virkelig svært for mig at forstå forskellige dele af kodebasen, især da jeg begyndte. Der blev bygget så mange forskellige tjenester. Det tilføjede en intens kompleksitet, og jeg talte med en nær ven, som var udvikler i en meget lille startup ved navn Lend.

De havde kun hundrede udviklere, mens Uber havde over tusind. Men vi stod begge over for lignende udfordringer med at organisere og forstå vores tjenestearkitektur. Det fik alarmklokkerne til at ringe: Hvis Uber befinder sig i den ene ende af skalaen, og denne anden virksomhed, der netop er begyndt på sin rejse med mikrotjenester, har de samme problemer, er det tydeligt, at dette er et stort problem i branchen.

Så vi endte med at starte virksomheden. Vi gennemførte Winter 20 Y Combinator-holdet. Og ja, spoler vi frem til i dag, har vi netop gennemført vores serie C, og jeg arbejder med nogle få hundrede forskellige virksomheder, der bruger Cortex til at administrere deres kompleksitet.

Hannah Clark: Cool. Det er en fantastisk rejse, og det er altid skønt at høre, når en virksomhed vokser ud af asken fra et problem, man kender indgående.

Når vi taler om det, skal vi i denne episode tale om teknisk ekspertise, og hvordan den ser ud i nutidens teknologiske landskab. Det er naturligvis et problem, du har været tæt på gennem hele din karriere. For at lægge ud: Hvordan definerer du teknisk ekspertise i 2025, og hvorfor er det blevet et så afgørende fokus for teknologidirektører og tekniske chefer lige nu?

Anish Dhar: Det er et godt spørgsmål. Det, vi har fundet hos Cortex, er, at samtalen i lang tid primært handlede om udvikleroplevelsen. Og udvikleroplevelsen er en virkelig vigtig del af enhver udviklingsorganisation, ikke? Det er simple ting som at sikre, at udviklere, når de starter i en virksomhed, nemt kan få sat deres interne system op og koblet det til GitHub og de forskellige værktøjer, de har, eller at infrastrukturen er sat korrekt op, når de implementerer en tjeneste, så der ikke er en masse fejlfinding eller trin for at komme i mål.

Men det, vi især har set i løbet af de seneste par år, er, at samtalen har flyttet sig fra kun at handle om udvikleroplevelsen til det, vi kalder teknisk ekspertise. Den store forskel er efter min mening, at teknisk ekspertise virkelig fokuserer på forskellige teams i organisationen.

Man kan tænke på SRE, sikkerhed, udviklerproduktivitet og endda udvikleroplevelse, men det handler om at knytte dem til faktiske forretningsresultater. Og det er den vigtigste forskel: Teknisk ekspertise handler om, hvordan det arbejde, jeg udfører, faktisk påvirker virksomheden, og hvordan det bringer den fremad.

Målene går hele vejen fra den administrerende direktørs organisation ned til den specifikke SRE, der for eksempel arbejder med det. Et godt eksempel kunne være, at vi som organisation fokuserer på at forbedre kundeoplevelsen, og at vi ønsker, at vores produkt skal være pålideligt, når kunderne bruger det, fordi en bedre kundeoplevelse fører til større omsætning, når folk bruger vores produkt mere.

Fra et initiativ om teknisk ekspertise kan SRE-teamet derfor måske have en tjekliste for produktionsparathed, som de forsøger at implementere. Før tjenester implementeres, vil de sikre sig, at alle tjenester lever op til organisationens standarder. Så man kan se, hvordan et initiativ, der starter hos SRE-teamet, fører tilbage til et reelt forretningsresultat, som organisationen går op i.

Jeg mener, det er afgørende, at teams tænker på deres initiativer på denne måde, fordi det bekræfter værdien og knytter de tekniske initiativer til noget, virksomheden går op i. Det er efter min mening hele pointen med teknisk ekspertise.

Hannah Clark: Interessant. Og det har du sikkert beskrevet mange gange som en slags uendelig rejse, der involverer mange discipliner, som arbejder sammen.

Fortæl mig om den ramme, du har udviklet. Hvordan ser de vigtigste søjler ud? Hvordan ser du på det fra din egen organisations perspektiv?

Anish Dhar: Du har helt ret. Det er virkelig en uendelig rejse. Mange af de virksomheder, vi arbejder med, især store virksomheder, har en masse ældre infrastruktur sammenlignet med en ny virksomhed, der er bygget på nyere teknologier og måske endda er AI-først.

Der er stadig forskellige initiativer omkring teknisk ekspertise, og de kræver efter min mening en meget gennemtænkt tilgang på tværs af alle disse teams: Hvad er arbejdet, og hvordan påvirker det i sidste ende de mål for forretningsmæssig ekspertise, vi har? Set fra et rammeperspektiv er noget af det, vi virkelig har arbejdet med, derfor, hvordan man definerer teknisk ekspertise for sin organisation.

Vi tænker på det sådan, at det begynder med forretningsmæssig ekspertise. Ledelsen har forskellige mål, som kan handle om at frigøre innovation og reducere tiden til markedet. Det kan også handle om at sænke omkostningerne og øge effektiviteten. Og som nævnt ser vi ofte et tredje mål: Hvordan forbedrer man kvaliteten og kundeoplevelsen?

Under det ligger søjlerne for teknisk ekspertise. Det er de forskellige teams og fagfolk, der udgør de initiativer, som driver disse endelige mål. Det kan være hastighed, effektivitet, sikkerhed og pålidelighed. Selv inden for disse underkategorier har man initiativer som en sikkerhedsmigrering eller en tjekliste for produktionsparathed.

Måske er der en proces for hændelseshåndtering, som man forsøger at implementere. Eller noget så enkelt som, at vi vil følge DORA-målinger for at forstå, hvordan vores udviklingsteam faktisk klarer sig produktivitetsmæssigt. Fundamentet for ethvert initiativ om teknisk ekspertise kommer fra det, vi kalder de fire C’er.

Det er grundlæggende fuld synlighed, løbende forbedring, en ensartet udvikleroplevelse og naturligvis tydeligt ejerskab. Uden ejerskab og forståelse af de forskellige dele af kodebasen og alle tjenesterne er det meget svært faktisk at drive disse initiativer fremad. Vi oplever derfor typisk, at det er svært at drive initiativer uden dette fundament.

Vi ser også typisk, at interne udviklerportaler er en meget stærk måde at opbygge dette fundament på. Det kan også gøres gennem interne værktøjer, men man har brug for en form for system til at forstå, hvad folk bygger, så man kan drive disse tekniske initiativer fremad.

Hannah Clark: Jeg vil gerne dykke ned i noget, du nævnte om måling af resultater, for jeg ved, at der er en vis spænding omkring måling af udviklerproduktivitet og målinger som antal kodelinjer.

Det kan være lidt kontroversielt blandt udviklere. Hvordan bør tekniske ledere tænke på måling af produktivitet på en mere holistisk måde, der tager højde for alle disse C’er og den slags?

Anish Dhar: Det interessante er, at meget af udviklerproduktiviteten i de seneste år har handlet om antal kodelinjer eller DORA-målinger. Der findes mange forskellige rammer, som er blevet skabt for at forenkle måden, man tænker på produktivitet på, og der er en vis sandhed i, hvordan disse målinger beregnes.

Antallet af kodelinjer er ikke en god indikator for, om nogen er produktive eller ej. Men hvis man konsekvent leverer nul kodelinjer fra kvartal til kvartal, er der tydeligvis noget galt med resultatet. Det kan også være interessant at sammenligne teams og se disse datapunkter, men samtalen har flyttet sig fra: “Jeg har disse data” til: “Hvordan får jeg faktisk udviklere til at forholde sig til dataene eller forbedre dem?”

Hvis man bryder det ned, er det et helt andet problem. Et langt vanskeligere problem, fordi alle kan gå ind, ramme sin GitHub-API og få disse målinger og et øjebliksbillede af, hvordan teamet klarer sig. Men bare fordi jeg viser et sæt målinger til en udvikler og siger: “Hey, vi skal forbedre denne måling”, betyder det ikke rigtig noget for mig som udvikler.

Jeg fokuserer på at bygge software til virksomheden og på at gøre det så effektivt som muligt. Samtalen har især med de teknologidirektører, vi arbejder med, flyttet sig til: “Okay, jeg har disse målinger. Hvordan omsætter jeg dem til noget, en udvikler går op i?”

Det er her, teknisk ekspertise spiller en så vigtig rolle. Udviklere, især dem der arbejder i hurtigt voksende virksomheder, ønsker, at virksomheden skal vokse. De bygger produkter, fordi de vil se virkningen af deres arbejde hos kunderne.

Udviklerproduktivitet har flyttet sig fra blot at være en bunke målinger til: “Som virksomhed er dette de ting, vi går op i, og disse målinger fortæller en del af historien.” For en udvikler handler det om at omsætte det til noget, hvor det arbejde, jeg udfører, faktisk betyder noget.

Det er den store ændring, vi har set.

Hannah Clark: Har du bemærket, at der er nogle forældede evalueringsmetoder eller KPI’er, som folk er begyndt at bevæge sig væk fra? Hvad vil du sige er den nye skole inden for evaluering, og har du nogle konkrete eksempler?

Anish Dhar: Jeg ville tænke på produktivitet som input- og outputmålinger. Outputmålinger er alle de klassiske rammer, man ser i dag til at følge udviklerproduktivitet. En af de mest berømte og populære er DORA-målingerne, som er et sæt forskellige målinger, der skal give et holistisk billede af, hvordan udviklingsteamet klarer sig.

De fleste udviklingsorganisationer vil gerne se disse outputmålinger og følge dem. Det vender tilbage til det, jeg sagde tidligere: Hvordan påvirker jeg faktisk disse målinger og får dem til at flytte sig? Hos vores kunder har vi set et interessant fokus på inputmålinger, som påvirker outputmålingerne.

Lad os for eksempel tage implementeringsfrekvens. Det er en god måling, fordi den hastighed, hvormed udviklerne implementerer software, sandsynligvis er en god indikator for, hvor hurtigt man flytter produktet fremad. Det handler i sidste ende om at komme hurtigere på markedet end konkurrenterne og bevæge sig hurtigere som virksomhed.

Måske har man som organisation besluttet, at implementeringsfrekvens er den vigtigste måling. Man kan have et kontrolpanel med implementeringsfrekvens og vise hele udviklingsteamet: “Hej alle, vi implementerer to gange om ugen. Vi vil gerne op på fire.”

Men hvordan skal jeg som udvikler forholde mig til det i relation til mit arbejde, min del af virksomheden eller de tjenester, jeg ejer? Hurtigere implementering betyder måske, at man skal levere mere, men fører det til flere fejl? Falder pålideligheden, fordi jeg leverer mere?

Der er så mange forskellige variabler, og det er her, inputmålinger bliver afgørende, fordi de i sidste ende påvirker outputmålingerne. For implementeringsfrekvens kan man måske indføre en proces, der faktisk får den til at stige.

Et eksempel er en af vores kunder, Riley. De havde et lignende initiativ og fulgte implementeringsfrekvensen ved hjælp af et af vores kontrolpaneler til udviklerindsigt. De ville have udviklerne til at implementere hurtigere, men gjorde det ved at indføre vigtige sikkerhedsforanstaltninger for implementering og give meget klare retningslinjer for, hvordan en god implementering ser ud i forhold til deres retningslinjer for pålidelighed.

Problemet var, at udviklerne forsøgte at implementere hurtigere, men det førte til fejl eller nedbrud. Derfor tøvede de med at bevæge sig så hurtigt som muligt på grund af den kundeindvirkning, der opstod. De udarbejdede en tjekliste for produktionsparathed med otte eller ni forskellige inputmålinger, som samlet gav en god forståelse af, om implementeringsprocessen faktisk var sund.

Det var målinger som: Er vores vagtordning sat korrekt op? Består vores byggeproces? Har vi beståede tests på vores tjenester? Ved at indføre disse inputmålinger fik udviklerne en klar rettesnor: “Jeg ejer disse ti tjenester. Dette er processen, og det er inputmålinger, der betyder noget for mig, fordi de repræsenterer tjenesterne og deres funktion.”

De så en gradvis stigning i implementeringsfrekvensen fra to gange om ugen til tre og fire, især for de kritiske tjenester, samtidig med en reduktion i hændelser og lignende problemer.

Mange virksomheder tænker derfor: “Vi har outputmålingerne, men hvordan omsætter vi dem til noget, udviklerne går op i?” Man skal tænke på udviklerproduktivitet og målinger generelt som en samlet historie mellem de to.

Hannah Clark: Det gør det meget mere holistisk. Lad os skifte lidt gear, men blive ved samme emne om at implementere mere og hurtigere. Vi kan ikke tale om udvikling i 2025 uden at tale om stemningsbaseret kodning.

Lad os tale om de AI-værktøjer, der lige nu forandrer arbejdsgangene omkring kodning. Jeg har hørt dig sige, at man ikke kan stemningskode sig til en million brugere om dagen. Måske er det kontroversielt, måske ikke. Hvad er virkeligheden sammenlignet med hypen, når det handler om at bruge AI til produktionsmiljøer i stor skala?

Anish Dhar: Det er bestemt et meget aktuelt emne, og alle udviklingsorganisationer tænker over AI eller har taget en form for AI-kodeassistent i brug. Der findes flere populære løsninger på markedet, blandt andet Cursor. Næsten hele udviklingsteamet hos Cortex bruger en form for AI-kodeassistent i hverdagen.

AI-kodeassistenter er fantastiske, når man har en indledende idé og hurtigt vil validere noget. Hvis man er frontendudvikler og hurtigt vil lave en prototype ud fra en idé for at se, hvordan noget kan se ud og føles, er de også meget nyttige.

I udviklingsprocessen er det perfekt til den slags. Man vil have noget hurtigt og simpelt, som man kan vise andre for at demonstrere, hvordan noget kan fungere. Eller hvis man som iværksætter har en idé, som man hurtigt vil validere. Det er derfor, man ser så stor vækst på området.

Virkeligheden er dog, at man ikke kan stole på kode, der er leveret gennem stemningsbaseret kodning, til at drive et produktionssystem, som bruges af millioner af brugere. Det er i hvert fald vores erfaring.

Stemningsbaseret kodning svarer i bedste fald til en juniorudvikler, der netop har lært at kode. Det er ikke det samme som senior- og stabsudviklere, der forstår systemdesign og ved, hvordan infrastruktur implementeres i stor skala. Vi er langt fra det niveau, og jeg siger ikke, at vi ikke kan nå dertil.

AI udvikler sig utroligt hurtigt. Det ville være dumt at sige, at der aldrig kommer en verden, hvor AI-systemer kan forstå reelle produktionsmiljøer. Men i dag er der ingen større virksomhed, der er afhængig af stemningsbaseret kodning til at drive et produktionssystem med millioner eller milliarder af brugere.

Den tekniske ekspertise, der kræves for at opsætte disse systemer, diagnosticere dem og sikre, at de skalerer, er simpelthen ikke til stede endnu. Produktiviteten er dog blevet forbedret med kodeassistenter, bare på andre områder end dem, markedet måske helst taler om. Virkeligheden er, at det endnu ikke er klar til produktionssystemer i større virksomheder.

Hannah Clark: Det kan mange fagfolk sikkert genkende. Folk uden for ens fagområde bliver begejstrede over, hvor tilgængeligt ens fagområde bliver med AI-værktøjer, men det betyder ikke nødvendigvis, at AI er lige i hælene på dig.

Vi har ledere, der lytter med, så for tekniske ledere, der forsøger at balancere investeringer i AI-værktøjer med medarbejderantallet: Hvad bør de overveje? Hvordan vurderer man den faktiske indvirkning, AI har på et teams produktivitet, og hvordan tager man det med i budgettet?

Anish Dhar: Det er et godt spørgsmål med mange forskellige aspekter. Udviklingsledere, der forhindrer deres teams i at se på disse værktøjer eller få adgang til eksempelvis Cursor eller GitHub Copilot, gør efter min mening deres teams en bjørnetjeneste på lang sigt.

Om ti år vil mange af de systemer, eller i det mindste den indledende kode, som folk skriver, være AI-assisteret. Hvis man starter en virksomhed eller en idé og hurtigt vil afprøve noget, er det ti gange hurtigere at bruge noget som Cursor, fordi man kan iterere så hurtigt uden nødvendigvis at skulle tænke på skala eller systemets indre funktion.

Selv på lang sigt vil udviklingsteams, der tager disse AI-værktøjer til sig og lærer at bruge dem i forskellige dele af deres kodeforløb, have en fordel. Det gælder også de største virksomheder, hvor man har brug for systemer, der fungerer i produktion.

Det er meget vigtigt, at tekniske ledere lader deres teams udforske denne type værktøjer og endda giver ikke-tekniske brugere adgang. Den mest interessante innovation, jeg har set hos vores kunder, kommer måske fra produktchefer, tekniske produktchefer og dataforskere, der forstår tekniske begreber, men ikke nødvendigvis har haft ekspertisen til at kode.

De kan tage idéer og dele dem med udviklingsteamet på en langt mere effektiv måde, fordi de faktisk kan starte kode og lignende. Det ville være meget ufornuftigt ikke at afsætte et budget til at give udviklerne adgang til disse værktøjer.

Det store spørgsmål er selvfølgelig, hvor meget produktivitet vi faktisk får ud af det. Alle større virksomheder forsøger at besvare det lige nu. Kunder køber ofte vores produkt sammen med noget som GitHub Copilot. Det første spørgsmål, de stiller, er: “Vi har dette værktøj, der angiveligt skal tredoble eller firedoble vores udviklingsteams output. Hvordan finder vi ud af, om det faktisk sker?”

Det vender tilbage til systemet med input- og outputmålinger. Det er ikke nok bare at vise implementeringsfrekvensen og sige: “Har GitHub Copilot påvirket den?” Måske gør Copilot, at man leverer hurtigere, men koden er dårlig, og det fører til problemer med pålideligheden. Man er nødt til at tage et næsten 360-graders syn på det og se på forskellige målinger.

Det handler i sidste ende om teknisk ekspertise. Glem stemningsbaseret kodning og alt andet et øjeblik. Hvad fokuserer vi på som virksomhed? Hvad forhindrer os i at nå vores næste vækstniveau? Man skal overveje, om introduktionen af en kodeassistent eller et AI-værktøj faktisk gør en forskel set fra det perspektiv.

Man ser måske ikke en effekt med det samme. Det tager tid at forstå, hvor disse værktøjer påvirker virksomheden. En fejl, jeg ser mange virksomheder begå, er at købe ind på hypen med det samme: købe 5.000 licenser til et smart værktøj og efter seks måneder spørge, om det faktisk har haft en effekt.

Uden en gennemtænkt strategi kan reaktionen blive meget negativ. Strategien kan for eksempel være, at vi ikke vil sakke bagud, at vi vil have udviklere til fortsat at opleve arbejdspladsen som førende, og at vi mener, det er en fordel at have AI-assisterede værktøjer i udviklingsteamet.

Selv hvis det er så enkelt, ved man i det mindste, hvorfor man køber værktøjerne. Man skal forstå sine intentioner og derefter løbende kontrollere, om værktøjerne faktisk gør det, man forventede.

Hannah Clark: Det er jeg tilbøjelig til at være enig i. Der er lige nu et stort pres for at mestre disse værktøjer og finde ud af, hvor de passer ind i arbejdsgangen. På tværs af mange afdelinger støder vi på en stor forskel mellem mængden af output og kvaliteten af resultaterne.

Vi skal være meget bevidste, ikke kun i udviklingsafdelingerne, men også om hvorvidt vi bruger værktøjerne i den rigtige sammenhæng for at understøtte og styrke vores medarbejdere i stedet for blindt at regne med, at næste års medarbejderantal bliver lavere, fordi AI-værktøjer kan erstatte folk.

Det er interessant at se alle forsøge at finde ud af dette på forskellige måder samtidig. Det er en meget desorienterende tid at være i teknologibranchen. Når vi taler om AI-værktøjer, der bliver mere udbredte i udviklingsarbejdsgange, og om kvalitet: Hvordan finder vi balancen mellem at opretholde kodekvalitet, sikkerhedsstandarder og pålidelighed, samtidig med at vi vil være førende arbejdspladser og udnytte værktøjerne bedst muligt?

Hvordan har I for eksempel grebet det an i jeres organisation?

Anish Dhar: Det er et virkelig godt spørgsmål. Jeg vil først sige, at idéen om, at AI erstatter udviklere, er så fjern fra virkeligheden og så fjollet. Når man lige er begyndt, kan man måske nøjes med at ansætte færre udviklere, fordi man i de tidlige dage med iteration og søgen efter produkt-markedstilpasning kan gøre langt mere med et værktøj som Cursor.

Man kan afprøve ti forskellige idéer meget hurtigt, og den høje iterationshastighed er utrolig stærk. Men når man faktisk implementerer produktionssystemer, forsøger virksomheder, der siger, at de ikke behøver at ansætte lige så mange udviklere på grund af AI, bare at skabe lidt medieopmærksomhed. Det er ikke realistisk.

Hannah Clark: Uden at nævne navne.

Anish Dhar: Ja. Alle disse virksomheder vil fortsat ansætte udviklere. Efterspørgslen efter udviklere forsvinder ikke. Men for at vende tilbage til dit spørgsmål om, hvordan AI-værktøjer og AI-kodesystemer påvirker de centrale søjler som pålidelighed og sikkerhed: Det er ærligt talt det store åbne spørgsmål lige nu.

Det er formentlig det, der skræmmer disse teams mest, især SRE-, sikkerheds- og driftsorganisationer. Introduktionen af værktøjerne skaber i sidste ende et større angrebsområde, fordi folk leverer mere kode.

Jo større en del af systemet der er bygget med AI, desto større er sandsynligheden for, at man ikke fuldt ud forstår, hvordan alt fungerer internt. Det betyder, at man står i en vanskeligere situation, når der uundgåeligt opstår et problem med pålideligheden.

Det kan være en uventet tilstrømning af brugere eller en del af kodebasen, man ikke har forstået fuldt ud, som bryder sammen. Jo mere AI-assisteret systemet er, desto sværere er det som udvikler at gennemgå alle dele af kodebasen, hvis man ikke forstår den fuldt ud.

Det er måske den største ulempe, jeg ser lige nu. Derfor bliver det fundamentale lag af teknisk ekspertise vigtigere end nogensinde: fuld synlighed og tydeligt ejerskab er centrale søjler i ethvert initiativ om teknisk ekspertise.

Jo flere systemer der skabes gennem AI, desto mindre dækning har man reelt på disse områder. Hvem ejer det faktisk, og hvem forstår det? Det er de ting, der skræmmer mange sikkerheds- og pålidelighedsteams. Hos nogle af vores kunder og i vores eget udviklingsteam ser vi, at udviklere er meget omhyggelige med at fortælle, når noget er genereret gennem Cursor eller et andet værktøj, og vi undersøger disse systemer ekstra grundigt.

Jeg har set en stor tendens til AI-assisteret testning. Nogle virksomheder skaber ligefrem en AI-udvikler, der gennemgår deres tests. Det kan være lidt usikkert, fordi AI-systemer i dag gør mere gavn end skade i udviklingsteams, men det er skræmmende at tænke på en verden, hvor 80 % af mit system er bygget gennem AI.

Det kan føre til, at problemer med pålidelighed og systemer tager længere tid at løse. Antallet af sikkerhedshændelser kan stige, fordi man har mindre synlighed. Det er det, man skal holde øje med.

Hannah Clark: Det er jeg enig i. Det er et mindre omtalt logistisk problem, som mange teams håndterer, når større output også betyder et øget behov for kontrol.

Vi talte i sidste uge med SVP’en for produktledelse hos Mastercard Gateway, og han fortalte, hvordan mange AI-værktøjer accelererer opgaver som formularudfyldelse i forbindelse med indtræden på nye markeder. Der er enorme mængder papirarbejde, når man skal ind på et nyt marked og overholde alle reglerne.

AI gør det muligt at færdiggøre meget af dette langt hurtigere. Men der skal også være en tilstrækkelig grad af kontrol for at sikre ejerskab over indsendelserne. Man kan altså færdiggøre arbejdet hurtigere, men man skal også kunne stå til ansvar i samme tempo.

Det lyder som en stor logistisk flaskehals for mange udviklingsteams og andre, der bruger disse værktøjer til at accelerere arbejdet. Det er værd at understrege: Ja, vi kan levere hurtigt, men kan vi samtidig sige, at vi er ansvarlige for arbejdet i samme tempo?

Det er meget interessant at tale om. Vi har talt med ledere i alle mulige afdelinger og discipliner, og det er fascinerende at se, hvordan mange af disse bekymringer ligner hinanden, selvom disciplinerne er meget forskellige.

Jeg sætter virkelig pris på alle de indsigter, du har delt i dag. Det afslutter vores episode. Hvor kan folk følge dig online, Anish?

Anish Dhar: Man kan følge mig på LinkedIn eller Twitter. Hvis man søger på mit navn, finder man mig. Man kan også finde Cortex på LinkedIn.

Vi lægger altid opslag op, og vi afholder faktisk Cortex-sammenkomster over hele verden. Hvis der er en i en by nær dig, bør du helt sikkert komme forbi. Vi vil gerne skabe et fællesskab af mennesker, der tænker over denne type ting. Alle virksomheder tænker over dem, så det er fantastisk at se et så stærkt fællesskab vokse frem.

Vi er også begyndt at afholde vores konference, som hedder IDPCON, og den handler grundlæggende om teknisk ekspertise. Vi har ledere fra forskellige typer virksomheder, som kommer, samt udviklere, der er interesserede i at møde andre udviklere og tale om teknisk ekspertise.

Der vil være masser af gode oplæg. Den afholdes i New York i oktober, så forhåbentlig ses vi også der.

Hannah Clark: Det lyder fantastisk. Tak, fordi du fortalte os om det. Vi sørger for at nævne det i beskrivelsen, og tusind tak, fordi du tog dig tid til at være med.

Anish Dhar: Tak, fordi jeg måtte være med. Det var fantastisk.

Hannah Clark: Tak, fordi du lyttede med. Du kan få flere gode indsigter, vejledninger og anmeldelser af værktøjer ved at abonnere på vores nyhedsbrev på theproductmanager.com/subscribe. Du kan høre flere samtaler som denne ved at abonnere på The CPO Club, uanset hvor du får dine podcasts.