Kristin Isaac, administrerende direktør og medstifter af Strudel – Interviewserie

Kristin Isaac, administrerende direktør og medstifter af Strudel, er en erfaren leder inden for virksomhedssoftware, der tidligere har haft seniort stillinger hos LinkedIn, Udemy, ESPN og Disney, før hun startede Strudel. Hun fokuserer nu på at løse et af de største friktionspunkter i softwareorganisationer: gapet mellem kundesupport og ingeniørarbejde. Hos Strudel bygger hun en AI-dreven platform, der hjælper tekniske supportteam med at løse komplekse problemer hurtigere ved at tilknytte supportanmodninger direkte til ingeniør-intelligence. Hendes baggrund i at skala teams, opbygge markedsstrategier og drive vækst på tværs af globale organisationer har hjulpet med at forme Strudels tidlige succes og stærke positionering på markedet for virksomheds-AI og udviklerværktøjer.

Strudel er en AI-platform, der er bygget til at automatisere avanceret teknisk support ved at analysere logfiler, produktionsdata, kodebiblioteker og tidligere supporthistorik for at identificere rodårsager og anbefale løsninger. Målet er at reducere den tid og det ingeniørarbejde, der kræves for at løse svære supporttilfælde, især de slags eskaleringer, der normalt forbruger seniorte tekniske ressourcer. Ved at tilknytte support direkte til underliggende tekniske problemer positionerer Strudel sig selv som et værktøj, der kan gøre virksomhedssupportoperationer hurtigere, mere effektive og mere skalerbare.

Du har haft ledelsesstillinger i organisationer som LinkedIn, Udemy og Disney, før du startede Strudel i 2025. Hvordan overtalte erfaringerne fra disse stillinger dig om, at ingeniørteamene havde brug for en ny type AI-dreven “ingeniør-intelligence”-platform, og hvordan formede denne indsigt grundlæggelsen af Strudel?

Hver virksomhed, jeg har arbejdet for, havde en anden version af samme problem. Hos Disney var indsatsen enorm – hvis en streaming-platform gik ned under en stor lancering, var det ikke kun et indtægts-tab, men også et brand-moment. Hos LinkedIn var skalaen uophørlig. Der var tusindvis af tjenester, der alle genererede støj, og selv de bedste teams kæmpede med at følge med.

Hvad forbinder alle tre og min medstifters, Shai Rubins og Brian Kaufmans, erfaring med at lede ingeniørteam, var, at ingeniører tilbragte mere tid med at genskabe kontekst end med at løse problemer. Når nogen blev vækket klokken 2 om natten, og før de overhovedet kunne starte med at diagnosticere, var de nødt til at gennemgå Slack-tråde, dashboards, Jira-billetter, deploymentslogfiler – blot for at forstå, hvad der var sket og hvornår. De spillede i virkeligheden detektiv, før de kunne udføre deres egentlige arbejde. Det er en spild af utroligt talentfulde mennesker.

Jeg tænkte hele tiden: Der må være en smartere måde at fremhæve, hvad der virkelig betyder noget, når det betyder noget. Det er virkelig kimningen til Strudel.

Mange virksomheder måler den finansielle impact af downtime i forhold til tabte indtægter eller SLA-straffe. I din erfaring, hvad er nogle af de mindre synlige omkostninger ved afbrydelser, som organisationer konsekvent undervurderer?

Indtægtsnumre kommer med i bestyrelsesmødet, men den umiddelbare indtægtsimpact er kun en brøkdel af, hvad afbrydelsen faktisk koster. De omkostninger, jeg har set organisationer konsekvent overse, falder i nogle kategorier.

Den første er kundetillid. SLA-straffe er en juridisk konstruktion – de fanger ikke den kunde, der stille og roligt forlader, eller den virksomhedskunde, der så statussiden på det forkerte tidspunkt og valgte en konkurrent. Den skade er langsom, usynlig og permanent på en måde, som en refusionscheck blot ikke er.

Den anden er ingeniørfratræd og udbrændthed. Vagtfatigue er virkelig. Når dine bedste ingeniører gentagne gange trækkes ind i højrisiko-tilfælde – især sådanne, der kunne være blevet forhindret – begynder de at stille spørgsmål om, hvorvidt dette er det rette sted at bygge deres karriere. At erstatte en senior ingeniør koster noget mellem én til to gange deres årlige løn, når man tager med i beregningen rekruttering, oplæring og tabt institutionel viden. Ingen sætter det i post-mortem-rapporten.

Den tredje er mulighedskost. Hvert øjeblik et ingeniørteam bruger på at bekæmpe brand, er et øjeblik, der ikke bliver brugt på at bygge et produkt. Det er svært at sætte på en regnskabsseddel, men akkumuleret over måneder blæser det stille og roligt din roadmap op.

Ingeniører bliver ofte trukket væk fra at bygge nye funktioner for at reagere på produktionshændelser. Hvordan påvirker denne konstante brandbekæmpelse produktinnovation og langsigtede udviklingsplaner?

Det skaber en afgift på ingeniørteamets evne til at bygge. Hvert team har en begrænset mængde kapacitet, og når en betydelig del af den hele tiden bliver omdirigeret til hændelser, er den akkumulerede effekt på produktudvikling alvorlig. Roadmap-forpligtelser bliver overset. Teknisk gæld bliver ikke betalt. Funktioner bliver udgivet med mindre rigor, fordi der er pres for at indhente tabt tid.

Hvad der er særligt skadeligt, er usikkerheden. Et team kan planlægge deres sprint med gode intentioner, og så blæser en større hændelse op på en tirsdag, og alt andet bliver sekundært. Den slags vedvarende usikkerhed gør det næsten umuligt at opbygge en kultur af dybt arbejde – hvilket ultimativt driver de bedste ingeniørresultater.

Det skaber også en selvforstærkende cyklus. Udsat investering betyder flere hændelser, hvilket betyder mere brandbekæmpelse, hvilket betyder endnu mindre tid til at investere i de underliggende problemer. Hos Strudel er en stor del af, hvad vi bygger, specifikt for SRE-teamene, der lever med dette hver dag.

Strudel forbinder kundesupportdata, logfiler, produktionsystemer og kodebiblioteker for at identificere rodårsager hurtigere. Hvordan bringer AI disse forskellige tekniske signaler sammen på en måde, som traditionelle overvågningsværktøjer ikke kan?

Traditionelle overvågningsværktøjer er fundamentalt alertsystemer. De er gode til at fortælle dig, at noget overskred en grænse – en latens-spike, en fejlrate, der stiger, en pod, der crasher. Hvad de ikke kan gøre, er at resonere på tværs af domæner.

De ved ikke, at fejlratens spike i din betalingservice skete fire minutter efter en deployment til en afhængighed, og at en kundesupportbillett, der nævner checkout-fejl, kom ind omkring samme tid, og at sidste gang denne mønster dukkede op i dine logfiler var for seks måneder siden under en database-migration.

Den tværdomæne-korrelation er, hvad AI muliggør. Vi kan behandle en Zendesk-billett, en GitHub-commit, en Datadog-sporing og en CloudWatch-log som en del af en samlet historie snarere end isolerede datapunkter. AI fremhæver ikke kun, hvad der er brudt, men også den sandsynlige årsag og hvor – og det grundfæster i beviser, som en menneskelig ingeniør faktisk kan verificere og handle på. Vi beder ikke teamene om at stole på en sort kasse. Vi giver dem en velbegrundet hypotese og en forhånd.

Du beskriver Strudel som leverandør af “ingeniør-intelligence”. Hvad betyder dette begreb i praksis, og hvordan adskiller det sig fra konventionelle overvågnings- eller AIOps-platforme?

Kristin: Overvågning er fundamentalt om instrumentation og synlighed – sikring af, at telemetrien er der, og at teamene kan forespørge den. AIOps, i de fleste af dets nuværende implementeringer, handler om at reducere alert-støj gennem ML-baseret korrelation og afvigelsesdetektion. Begge er virkelig værdifulde, og vi integrerer med dem.

Men ingeniør-intelligence er et lag ovenover. Vi tager, hvad AIOps gør, og udvider på det. Hvor AIOps fortæller dig, at noget er galt, hjælper ingeniør-intelligence dig med at forstå, hvorfor det er galt, hvor det startede, og hvad du skal gøre ved det – trækker signaler fra på tværs af hele din stack, herunder kilder, som traditionelle AIOps-værktøjer ikke engang kigger på, som kundesupportbilletter eller kodeændringer. Målet er ikke kun at reducere støj. Det er at give dit team en komplet, handlebar billed, så de kan løse problemet hurtigere og vende tilbage til at bygge.

AI-agenter bliver mere og mere anvendt til at automatisere komplekse tekniske arbejdsgange. Hvad rol ser du AI-agenter spille i diagnose og løsning af software-hændelser i de næste fem år?

Jeg tror, det mere interessante spørgsmål ikke er, hvad agenter vil gøre – men hvad ingeniører vil stoppe med at gøre. De bedste ingeniører, jeg har arbejdet med, gik ikke ind i denne branche for at tilbringe deres nætter med at triage-alarm eller lede gennem logfiler efter en konfigurationsændring, som nogen gjorde på en fredag eftermiddag. Det er ikke derfor, de blev gode til deres job. Men det er, hvad en stor del af deres tid bliver spist af.

Over de næste fem år tror jeg, at agenter tager på sig en stor del af det slid – det repetitive, mønster-matching, kontekst-sammenføjningsarbejde, der er vigtigt, men ikke hvor senior ingeniør-talent skal bruge sin tid. Det frigør mennesker til at fokusere på komplekse problemer, arkitektur-beslutninger, ting, der faktisk kræver menneskelig dømmekraft.

Hvad der er spændende for mig, er, at dette ikke kun er en fremtidig tilstand – vi ser det spille ud lige nu, herunder hos Strudel. Hele vores roadmap er orienteret mod at fjerne administrativt og vedligeholdelsesarbejde fra ingeniørernes plader. Og hvad vi finder, ærligt, er, at det ændrer, hvad der er muligt for et team. Du kan bygge mere, flytte hurtigere og gøre det med færre mennesker – fordi de mennesker, du har, er fokuseret på strategi og kompleksitet snarere end på at betale deres dues på det repetitive.

Mange afbrydelser stammer fra små fejl eller konfigurationsændringer, der slipper igennem test. Hvordan kan AI-systemer identificere subtile mønstre i kode, logfiler eller infrastruktursignaler tidligt nok til at forhindre større hændelser?

Velkonstrueret AI har en reel fordel her, og det er ikke, fordi det er smartere end dine ingeniører – men fordi det aldrig glemmer og aldrig sover. Et menneske kan ikke forbinde et subtilt log-mønster i dag med noget, der skete for seks måneder siden i en helt anden del af systemet. AI kan. Det overvåger alt, hele tiden, og det har en langt længere og bredere hukommelse end noget menneske på dit team.

Det sagde, er der også noget andet, jeg hører fra kunder meget: forebyggelse er kun så god som de data, der ligger under. Hvis dine logfiler er inkonsistente, ufuldstændige eller fragmenterede på tværs af en dusin værktøjer, der ikke taler sammen, så arbejder AI med en fragmenteret billed. Skrald ind, skrald ud – det er stadig sandt. Vi bruger meget tid med kunder på at tænke over datakvalitet og instrumentation, fordi den bedste AI i verden ikke kan fremhæve et signal, der aldrig blev fanget fra starten.

Virksomheder investerer ofte kraftigt i detectionsværktøjer, men kæmper stadig med gennemsnitlig tid til løsning. Hvad er de største barrierer for at lukke gapet mellem hændelsesdetektion og faktisk rodårsagsløsning?

Detektion er i store træk et løst problem på dette tidspunkt. De fleste team har alarm. De ved, at noget er galt. Gapet er alt, hvad der sker herefter.

Når en ingeniør bliver vækket, går de ikke ind i en klar situation med alle relevante kontekster samlet. De går ind i en rod. De må selv finde ud af, hvad der ændrede sig, hvornår det ændrede sig, hvilket system det rørte, om der er en kunde-impact, om det er relateret til noget, der skete sidste uge. De trækker fra Slack, dashboards, deploymentslogfiler, supportbilletter – gør det samle-arbejde manuelt, under pres, ofte midt om natten.

Den kontekst-sammenføjning er flaskenhalen. Det er ikke, at ingeniører og tekniske supportteam ikke ved, hvordan de skal løse problemer – men de bruger den første halve time til hver enkelt hændelse på at forstå, hvad de overhovedet kigger på. Det er, hvor Strudel bor. Hele vores teses er, at hvis du kan give en ingeniør et sammenhængende, bevis-baseret billede af, hvad der skete og hvorfor – lige når de har brug for det – så komprimerer du dramatisk det gap. Løsningsarbejdet er stadig deres. Vi får dem bare til startlinjen meget hurtigere.

Når AI-systemer begynder at analysere produktionsdata, kodebiblioteker og operationslogfiler, hvilke regulerings- eller sikkerheds-overvejelser bør ingeniørteamene holde øje med, når de implementerer disse værktøjer?

Det, jeg føler stærkest om her, er dette: mennesker bør stadig gennemgå kode, der kommer i produktion.

Jeg har talt med mange ingeniører om dette, og noget, jeg hører igen og igen, er, at AI skriver fejl effektivt og kløgtigt. Virkelig kløgtigt, faktisk. På en måde, der kan være virkelig svær at fange – selv for seniorte ingeniører, der gennemgår koden omhyggeligt. Fejlene er ikke altid åbenlyse. De kan se perfekt rimelige ud på overfladen.

Så da AI skriver mere og mere af koden, der ender i produktion, tror jeg, vi vil se mere af disse subtile, sværtdetekterbare fejl slippe igennem – ikke fordi nogen var uopmærksom, men fordi naturen af AI-genererede fejl er anderledes. Sværere at spotte under gennemgang. Sværere at fange under test.

Ærligt? Det er en af grundene til, at tilfældet for, hvad Strudel gør, kun bliver stærkere over tid. Hvis flere fejl kommer i produktion, bliver evnen til at finde og løse dem hurtigere mere vigtig, ikke mindre. Spørgsmålet om regulerings- og sikkerhed er ikke kun om dataadgangskontrol og tilladelser – selvom det betyder noget, og teamene bør være omhyggelige med, hvilke data de giver AI-systemer adgang til. Det handler også om at holde mennesker på de rette checkpoints, især omkring noget, der rører produktion.

Settende fremad, tror du, at fremtiden for pålidelighedsingeniørarbejde vil skifte mod AI-først-infrastruktur, hvor autonome systemer overvåger, diagnosticerer og endda løser problemer, før mennesker er klar over dem? Hvis ja, hvordan ser arbejdsprocessen for ingeniører ud i den fremtid?

Jeg tror, vi er på vej i den retning, men jeg er pragmatisk omkring tidsrammen. Fuldt autonome systemer, der løser produktionshændelser uden nogen menneskelig indsigt – det er ikke, hvor vi er, og jeg tror ikke, det er, hvor vi vil være i de næste få år. Og jeg tror, det er okay.

Hvad jeg tror, er, at løkken bliver meget tættere og mindre smertefuld. Fremtiden, jeg er spændt på, er ikke en, hvor mennesker fjernes fra ligningen – men hvor de mennesker, der integreres i processen, bruger deres tid på de dele, der faktisk kræver dem. Dømmekraft. Nye situationer. En hændelse, du aldrig har set før. AI håndterer mønster-matching, kontekst-sammenføjning, rutine-triage. Ingeniører håndterer beslutningerne.

For ingeniørerne selv tror jeg, det ligner: mindre tid på vagt midt om natten for ting, der ikke behøver at vække dem, og mere tid på at bygge systemer, der ikke bryder sammen i første omgang. Brandbekæmpelsen forsvinder ikke helt. Men det bliver undtagelsen snarere end standardtilstanden for at være ingeniør i en virksomhed, der kører software i stor skala. Det er en fremtid, der er værd at bygge mod.

Tak for det gode interview, læsere, der ønsker at lære mere, skal besøge Strudel.