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

Kristin Isaac, VD och medgrundare på Strudel är en veteran inom företagsledning inom teknik som har haft seniora roller på LinkedIn, Udemy, ESPN och Disney innan hon startade Strudel. Hon fokuserar nu på att tackla en av de största friktionspunkterna i mjukvaruorganisationer: 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 att skala team, bygga marknadsstrategier och driva 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, kodarkiv och tidigare supporthistorik för att identifiera rotorsaker och rekommendera lösningar. Målet ä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 förbrukar seniora tekniska resurser. Genom att koppla support direkt till underliggande tekniska problem positionerar sig Strudel som ett verktyg som kan göra företagssupportoperationer snabbare, mer effektiva och mer skalbara.

Du har haft ledande roller på företag som LinkedIn, Udemy och Disney innan du startade Strudel 2025. Vilka erfarenheter från dessa roller övertygade dig om att teknikteam behöver 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 intäktsfö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 göra hjältedåd med begränsad verktygsutrustning.

Det som förenade alla tre och mina medgrundares, Shai Rubins och Brian Kaufmans, erfarenheter av att leda teknikteam var att teknikerna tillbringade mer tid med att återskapa sammanhang än att faktiskt lösa problem. Någon blir väckt klockan 02.00, och innan de ens kan börja diagnostisera, måste de gå 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 oerhört 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 ursprunget till Strudel.

Många driftstopp beror på små buggar eller konfigurationsändringar som smiter förbi testning. Hur kan AI-system identifiera subtila mönster i kod, loggar eller driftssignaler 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 tekniker – 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 har ett mycket längre och bredare minne än någon individ i ditt team.

Det som jag hör från kunder mycket ofta är att förebyggande är bara så bra som de underliggande data. Om dina loggar är ofullständiga, inkonsekventa eller isolerade över ett dussin verktyg som inte pratar med varandra, så 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 presentera en signal som aldrig fångades från början.

Företag investerar ofta kraftigt i upptäcktsverktyg men kämpar fortfarande med medel tid till lösning. Vilka är de största hindren som förhindrar organisationer från att stänga gapet mellan incidentupptäckt och faktisk rotorsakslösning?

Upptäckt är i stort sett ett löst problem vid det här laget. De flesta team har larm. De vet att något är fel. Gapet är allt som händer efteråt.

När en tekniker blir väckt, går de inte in i en tydlig situation med all relevant sammanhang snyggt sammansatt. De går in i en röra. De måste ta reda på vad som förändrades, när det förändrades, vilken system det berörde, om det finns en kundpåverkan, om det är relaterat till något som hände förra veckan. De drar från Slack, från instrumentpaneler, från distributionsloggar, från supportbiljetter – och gör det sammanställningsarbetet manuellt, under tryck, ofta mitt i natten.

Det sammanställningsarbetet är flaskhalsen. Det är inte att tekniker och 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 tittar på. Det är där Strudel bor. Vår helhetsteori är att om man kan ge en tekniker en sammanhängande, bevisbaserad bild av vad som hände och varför – precis när de behöver det – så komprimerar man dramatiskt det gapet. Lösningsarbetet är fortfarande deras. Vi får dem bara till startlinjen mycket snabbare.

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

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

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

Så medan AI skriver mer och mer av den kod som hamnar i produktion, tror jag att vi kommer att se fler av dessa subtila, svåra att upptäcka problem smita igenom – 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 upptäcka under testning.

Ärligt talat? Det är en av anledningarna till att jag tycker att fallet för vad Strudel gör bara blir starkare över tiden. Om fler buggar hamnar i produktion, så 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 dessa är viktiga och team bör vara noggranna med vilken data de ger något AI-system tillgång till. Det handlar också om att hålla människor vid rätt kontrollpunkter, särskilt kring allt som berör produktion.

Om man ser framåt, tror du att framtiden för tillförlitlighetsutveckling kommer att förskjutas mot AI-först infrastruktur, 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ödet ut för tekniker?

Jag tror att vi är på väg dit, men jag är pragmatisk när det gäller 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 det är där vi kommer att vara om några år. Och jag tror att det är okej.

Det jag tror är att loopen blir mycket tätare och mindre smärtsam. Framtiden jag är entusiastisk över ä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å de delar som faktiskt kräver dem. Bedömningar. Nya situationer. En incident du aldrig sett förut. AI hanterar mönsterigenkänning, sammanställning, rutinmässig triage. Tekniska experter hanterar besluten.

För tekniker själva tror jag att det ser ut så här: mindre tid på anrop mitt i natten för saker som inte behövde väcka dem, och mer tid att bygga system som inte går sönder från början. Släckningsarbetet försvinner inte helt. Men det blir undantaget snarare än standardtillståndet för att vara en tekniker på ett företag som kör programvara i stor skala. Det är en framtid som är värd att bygga mot.

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