Kristin Isaac, VD och medgrundare på Strudel – Intervju-serie

Kristin Isaac, VD och medgrundare på Strudel är en veteran inom företags-teknologi som har haft seniora roller på LinkedIn, Udemy, ESPN och Disney innan hon lanserade Strudel. Hon fokuserar nu på att tackla en av de största friktionspunkterna i programvaruorganisationer: gapet mellan kundsupport och teknik. På Strudel bygger hon en AI-driven plattform som hjälper tekniska supportteam att lösa komplexa problem snabbare genom att koppla supportförfrågningar direkt till teknisk intelligens. Hennes bakgrund inom skalning av team, byggnad av marknadsstrategier och drivande tillväxt över hela världen har hjälpt till att forma Strudels snabba tidiga framgångar och starka positionering på marknaden för företags-AI och utvecklarverktyg.

Strudel är en AI-plattform byggd för att automatisera avancerad teknisk support genom att analysera loggar, produktionsdata, kodrepositoryer och tidigare support-historik för att identifiera rotorsaker och rekommendera lösningar. Dess mål är att minska den tid och tekniska ansträngning som krävs för att lösa svåra supportärenden, särskilt de typer av eskaleringar som vanligtvis konsumerar seniora tekniska resurser. Genom att koppla support direkt till underliggande tekniska problem positionerar Strudel sig som ett verktyg som kan göra företags supportoperationer snabbare, mer effektiva och mer skalbara.

Du har haft ledande roller på företag som LinkedIn, Udemy och Disney innan du grundade Strudel 2025. Vilka erfarenheter från dessa roller övertygade dig om att teknikteam behövde en ny typ av AI-driven “teknisk intelligens”-plattform, och hur formade den insikten grundandet av Strudel?

Varje företag jag arbetade på hade en annan version av samma problem. På Disney var insatserna enorma – om en strömningplattform gick ner under en stor lansering, var det inte bara en inkomstförlust, det var ett varumärkesögonblick. På LinkedIn var skalan obeveklig. Det fanns tusentals tjänster som alla genererade brus, och även de bästa teamen kämpade för att hålla jämna steg. På Udemy såg jag ett smalt team som gjorde hjältedåd med begränsad verktygsutrustning.

Vad som förenade alla tre och mina medgrundare, Shai Rubins och Brian Kaufmans erfarenheter av att leda teknikteam, var att ingenjörerna tillbringade mer tid med att rekonstruera sammanhang än att faktiskt lösa problem. Någon blir väckt klockan 02.00, och innan de ens kan börja diagnostisera, letar de igenom Slack-trådar, instrumentpaneler, Jira-biljetter, distributionsloggar – bara för att förstå vad som förändrades och när. De spelar i princip detektiver innan de kan göra sitt riktiga jobb. Det är en slöseri med otroligt begåvade människor.

Jag tänkte hela tiden: det måste finnas ett smartare sätt att presentera vad som faktiskt är viktigt, när det är viktigt. Det är verkligen utsädet till Strudel.

Många företag mäter den finansiella påverkan av driftstopp i termer av förlorad inkomst eller SLA-straff. I din erfarenhet, vad är några av de mindre synliga kostnaderna för driftstopp som organisationer konsekvent underskattar?

Inkomstsiffran hamnar i styrelserummet, men den omedelbara inkomstpåverkan är bara en bråkdel av vad driftstoppet faktiskt kostar. De jag har sett organisationer konsekvent missa faller inom några kategorier.

Den första är kundförtroende. SLA-straff är ett juridiskt koncept – de fångar inte den kund som tystnar eller det företag som såg din statussida vid fel ögonblick och valde en konkurrent. Den skadan är långsam, osynlig och permanent på ett sätt som en återbetalningscheck inte är.

Den andra är ingenjörsavgång och utbrändhet. On-call-utmattning är verklig. När dina bästa ingenjörer upprepat dras in i högriskincidenter – särskilt de som kunde ha förhindrats – börjar de ifrågasätta om detta är rätt plats att bygga sin karriär. Att ersätta en senioringenjör kostar var som helst mellan en till två gånger deras årliga lön när man räknar in rekrytering, ombordstigning och förlorad institutionell kunskap. Ingen lägger det i post-mortem.

Den tredje är möjlighetskostnad. Varje timme ett teknikteam tillbringar med att släcka bränder är en timme som inte tillbringas med att bygga produkter. Det är svårt att sätta på en kalkylblad, men ackumulerat över månader, blåser det tyst upp din vägkarta.

Ingenjörer dras ofta bort från att bygga nya funktioner för att svara på produktionsincidenter. Hur påverkar denna konstanta släckning av bränder produktinnovation och långsiktiga utvecklingsvägar?

Det skapar en skatt på ditt teknikteams förmåga att bygga. Varje team har en ändlig mängd bandbredd, och när en betydande del av den ständigt omdirigeras till incidenter, är den ackumulerade effekten på produktutveckling allvarlig. Vägkartsåtaganden missas. Teknisk skuld betalas inte av. Funktioner skickas med mindre rigor eftersom det finns tryck på att ta igen förlorad tid.

Vad som är särskilt skadligt är oförutsägbarheten. Ett team kan planera sin sprint med goda avsikter, och sedan sprängs en stor incident på en tisdag och allt annat blir sekundärt. Den här typen av ihållande oförutsägbarhet gör det nästan omöjligt att bygga en kultur av djup arbete – vilket är vad som driver de bästa teknikresultaten.

Det skapar också en självförstärkande cykel. Uppskjuten investering innebär fler incidenter, som innebär mer släckning av bränder, som innebär ännu mindre tid att investera i de underliggande problemen. På Strudel är en stor del av vad vi bygger specifikt för SRE-teamen som lever det här varje dag.

Strudel kopplar kundsupportdata, loggar, produktionsystem och kodrepositoryer för att identifiera rotorsaker snabbare. Hur kombinerar AI dessa olika tekniska signaler på ett sätt som traditionella övervakningsverktyg inte kan?

Traditionella övervakningsverktyg är i grunden larmsystem. De är bra på att berätta att något har överskridit en tröskel – en latensspik, en felhastighet som stiger, en podd som kraschar. Vad de inte kan göra är att resonera över domäner.

De vet inte att felhastighetspiken i din betalningstjänst inträffade fyra minuter efter en distribution till en beroende, och att en kundsupportbiljett som nämner köpproblem kom in ungefär samtidigt, och att samma mönster visades i dina loggar för sex månader sedan under en databasmigration.

Den här korrelationen över domäner är vad AI möjliggör. Vi kan behandla en Zendesk-biljett, en GitHub-kommit, en Datadog-spårning och en CloudWatch-logg som en del av en enda berättelse snarare än isolerade datapunkter. AI: n ytor inte bara vad som är trasigt, utan den troliga orsaken och var – och den grundar det i bevis som en mänsklig ingenjör faktiskt kan verifiera och agera på. Vi ber inte teamen att lita på en svart låda. Vi ger dem en väl underbyggd hypotes och en försprång.

Du beskriver Strudel som levererande “teknisk intelligens”. Vad betyder det begreppet i praktiken, och hur skiljer det sig från konventionell observabilitet eller AIOps-plattformar?

Kristin: Observabilitet handlar i grunden om instrumentering och synlighet – att se till att telemetrin finns där och att teamen kan fråga den. AIOps, i de flesta av dess nuvarande implementationer, handlar om att minska larmbrus genom ML-baserad korrelation och avvikelseupptäckt. Båda är genuint värdefulla, och vi integrerar med dem.

Men teknisk intelligens är ett lager ovanpå. Vi tar vad AIOps gör och utvidgar det. Där AIOps berättar att något är fel, hjälper teknisk intelligens dig att förstå varför det är fel, var det började och vad du ska göra åt det – genom att dra signaler från hela din stack, inklusive källor som traditionella AIOps-verktyg inte ens tittar på, som kundsupportbiljetter eller kodändringar. Målet är inte bara att minska bruset. Det är att ge ditt team en komplett, agerbar bild så att de kan lösa problemet snabbare och återgå till att bygga.

Tänk på det som skillnaden mellan en rökdetektor och en brandutredare. Observabilitet och AIOps är rökdetektorn – väsentlig, men de slutar vid larmet. Teknisk intelligens är vad som kommer efter: här är vad som hände, här är varför, här är var det började.

AI-agenter deployeras alltmer för att automatisera komplexa tekniska arbetsflöden. Vilken roll ser du att AI-agenter kommer att spela för att diagnostisera och lösa programvaruincidenter under de kommande fem åren?

Jag tycker att den mer intressanta frågan inte är vad agenter kommer att göra – det är vad ingenjörer kommer att sluta göra. De bästa ingenjörerna jag har arbetat med gick inte in i det här fältet för att tillbringa sina nätter med att triage-larm eller leta igenom loggar efter en konfigurationsändring som någon gjorde på en fredagseftermiddag. Det är inte varför de blev bra på sina jobb. Men det är vad en stor del av deras tid blir uppäten av.

Under de kommande fem åren tror jag att agenter tar på sig en stor del av den mödan – det repetitiva, mönstermatchande, sammanhangsmonteringsarbetet som är viktigt men inte där seniora ingenjörstalen borde spendera sin tid. Det frigör människor att fokusera på de komplexa problemen, de arkitekturbesluten, de saker som faktiskt kräver mänskligt omdöme.

Vad som är spännande för mig är att det inte bara är en framtida tillstånd – vi ser det spela ut just nu, inklusive på Strudel. Vår hela vägkarta är inriktad på att ta bort administrativt och underhållsarbete från ingenjörernas tallrik. Och vad vi hittar, ärligt, är att det förändrar vad som är möjligt för ett team. Du kan bygga mer, flytta snabbare och göra det med färre människor – eftersom de människor du har är fokuserade på strategi och komplexitet snarare än att betala sin skuld till det repetitiva. Det känns som en meningsfull förändring i hur team byggs och struktureras framöver.

Många driftstopp har sitt ursprung i små buggar eller konfigurationsändringar som glider igenom testning. Hur kan AI-system identifiera subtila mönster i kod, loggar eller infrastruktursignaler tidigt nog för att förhindra stora incidenter?

Välkonstruerad AI har en verklig fördel här, och det är inte att den är smartare än dina ingenjörer – det är att den aldrig glömmer och aldrig sover. En människa kanske inte kopplar ett subtilt loggmönster idag till något som hände för sex månader sedan i en helt annan del av systemet. AI kan. Den tittar på allt, hela tiden, och den har ett mycket längre och bredare minne än någon individ i ditt team.

Det sagt finns det också något annat vi hör från kunder mycket: förebyggande är bara så bra som de underliggande data. Om dina loggar är ofullständiga, inkonsekventa eller silade över ett dussin verktyg som inte pratar med varandra, arbetar AI med en fragmenterad bild. Skräp in, skräp ut – det är fortfarande sant. Vi tillbringar mycket tid med kunder med att tänka på datakvalitet och instrumentering eftersom den bästa AI i världen inte kan yta en signal som aldrig fångades från början.

Så svaret är båda: ja, AI kan fånga saker tidigare och koppla ihop punkter som människor missar. Men teamen som får mest värde från det är de som också har gjort jobbet för att se till att deras data faktiskt är värd att resonera över.

Företag investerar ofta tungt i upptäcktsverktyg men kämpar fortfarande med medel tid till lösning. Vilka är de största hindren för att förhindra att organisationer stänger gapet mellan incidentupptäckt och faktisk rotorsakslösning?

Upptäckt är i stor utsträckning ett löst problem vid det här laget. De flesta teamen har larm. De vet att något är fel. Gapet är allt som händer efter.

När en ingenjör blir väckt, går de inte in i en tydlig situation med all relevant sammanhang snyggt monterat. De går in i en röra. De måste lista ut vad som förändrades, när det förändrades, vilken system det rörde, om det finns en kundpåverkan, om det är relaterat till något som hände förra veckan. De letar i Slack, instrumentpaneler, distributionsloggar, supportbiljetter – bara för att förstå vad de faktiskt tittar på. Det är det som är flaskhalsen.

Det är inte så att ingenjörer och tekniska supportteam inte vet hur man löser problem – det är att de tillbringar de första 30 till 60 minuterna av varje incident med att försöka förstå vad de faktiskt ser. Det är där Strudel lever. Vår hela tes är att om du kan ge en ingenjör en sammanhängande, bevisbaserad bild av vad som hände och varför – precis när de behöver det – komprimerar du dramatiskt gapet. Lösningsarbetet är fortfarande deras. Vi ger dem bara en försprång.

När AI-system börjar analysera produktionsdata, kodbas och operativa loggar, vilka styrnings- eller säkerhetsaspekter bör teknikteam ha i åtanke när de distribuerar dessa verktyg?

Det jag känner starkast för här är att människor fortfarande bör granska kod som går till produktion.

Jag har pratat med många ingenjörer om det, och en sak jag hör om och om igen är att AI skriver buggar effektivt och smart. Riktigt smart, faktiskt. På ett sätt som kan vara genuint svårt att upptäcka – även för seniora ingenjörer som granskar koden noggrant. Buggarna är inte alltid uppenbara. De kan se perfekt rationella ut vid en första anblick.

Så när AI skriver alltmer av koden som hamnar i produktion, tror jag att vi kommer att se fler av dessa subtila, svåra att upptäcka problem smyga sig förbi – inte för att någon var vårdslös, utan för att naturen hos AI-genererade buggar är annorlunda. Svårare att upptäcka under granskning. Svårare att fånga under testning.

Ärligt? Det är en av anledningarna till att fallet för vad Strudel gör bara blir starkare över tid. Om fler buggar hamnar i produktion, blir förmågan att hitta och lösa dem snabbare viktigare, inte mindre. Styrningsfrågan är inte bara om dataåtkomstkontroller och behörigheter – även om de är viktiga och team bör vara tänksamma på vilken data de ger något AI-system tillgång till. Det handlar också om att hålla människor på rätt kontrollstationer, särskilt runt allt som rör produktion.

Om man ser framåt, tror du att framtiden för tillförlitlighetsingenjörskap kommer att förskjutas mot AI-förstainfrastruktur, där autonoma system övervakar, diagnostiserar och till och med åtgärdar problem innan människor är medvetna om dem? Om så, vad ser den framtida arbetsflödesprocessen ut för ingenjörer?

Jag tror att vi är på väg dit, men jag är pragmatisk om tidsramen. Fullt autonoma system som löser produktionsincidenter utan någon mänsklig medvetenhet – det är inte där vi är, och jag tror inte att vi kommer att vara där de kommande åren. Och jag tycker att det är okej.

Vad jag tror är att slingan blir mycket tätare och mindre smärtsam. Framtiden jag är spänd på är inte en där människor tas bort från ekvationen – det är en där de människor som integreras i processen tillbringar sin tid på delarna som faktiskt kräver dem. Bedömningar. Nya situationer. En incident du aldrig har sett förut. AI hanterar mönstermatchning, sammanhangsmontering, rutintriage. Ingenjörer hanterar besluten.

För ingenjörerna själva tror jag att det ser ut så här: mindre tid på väg i mitten av natten för saker som inte behövde väcka dem, och mer tid att bygga system som inte bryts i första hand. Släckandet av bränder försvinner inte helt. Men det blir undantaget snarare än standardtillståndet för att vara en ingenjör på ett företag som kör programvara i skala. Det är en framtid värd att bygga mot.

Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka Strudel.