Kristin Isaac, CEO og medgrunnlegger i Strudel – Intervju-serie

Kristin Isaac, CEO og medgrunnlegger i Strudel, er en erfaren leder innen bedriftsteknologi som har hatt seniortiller i LinkedIn, Udemy, ESPN og Disney før hun startet Strudel. Hun fokuserer nå på å løse ett av de største friksjonspunktene i programvareorganisasjoner: gapet mellom kundestøtte og ingeniørarbeid. Hos Strudel bygger hun en AI-drevet plattform som hjelper tekniske støtteam å løse komplekse problemer raskere ved å koble støtteforespørsler direkte til ingeniør-intelligens. Hennes bakgrunn i å skalerer team, bygge markedsstrategier og drive vekst over hele verden har hjulpet til å forme Strudels rask tidlige fremgang og sterk posisjonering i bedrifts AI- og utviklerverktøy-markedet.

Strudel er en AI-plattform bygget for å automatisere avansert teknisk støtte ved å analysere logger, produksjonsdata, kodearkiv og tidligere støttehistorikk for å identifisere årsaker og anbefale løsninger. Målet er å redusere tiden og ingeniørinnsatsen som kreves for å løse vanskelige støtte-saker, spesielt de typene eskalasjoner som vanligvis forbruker senior tekniske ressurser. Ved å koble støtte direkte til underliggende tekniske problemer, stiller Strudel seg som et verktøy som kan gjøre bedriftsstøtte-operasjoner raskere, mer effektive og mer skalerbare.

Du har hatt lederstillinger i organisasjoner som LinkedIn, Udemy og Disney før du startet Strudel i 2025. Hva erfaringer fra disse stillingene overbeviste deg om at ingeniørteamene trengte en ny type AI-drevet “ingeniør-intelligens”-plattform, og hvordan har denne innsikten formet grunnleggelsen av Strudel?

Hver bedrift jeg jobbet for hadde en annen versjon av samme problem. Hos Disney var innsatsen enorm – hvis en strømmingtjeneste gikk ned under en stor lansering, var det ikke bare et inntekts-tap, men også et merkevare-øyeblikk. Hos LinkedIn var skalaen relentless. Det var tusenvis av tjenester som alle genererte støy, og selv de beste teamene kjempet for å holde pace. Hos Udemy så jeg et lean-team gjøre heltemodige ting med begrensede verktøy.

Hva knyttet alle tre sammen, og til mine medgrunnleggernes, Shai Rubins og Brian Kaufmans erfaring med å lede ingeniørteam, var at ingeniører tilbrakte mer tid med å rekonstruere kontekst enn å faktisk løse problemer. Når noen blir varslet klokken 02.00, og før de kan begynne å diagnostisere, må de gå gjennom Slack-tråder, dashboards, Jira-billetter, deploylogs – bare for å forstå hva som har endret seg og når. De spiller i realiteten detektiver før de kan gjøre sitt egentlige arbeid. Det er en spille av usede mennesker.

Jeg tenkte hele tiden: det må finnes en smartere måte å fremheve hva som virkelig betyr noe, når det betyr noe. Det er virkelig frøet til Strudel.

Mange nedtider skyldes små feil eller konfigurasjonsendringer som glipper gjennom testing. Hva er noen av de mindre synlige kostnadene ved nedtider som organisasjoner jevnt over undervurderer?

Inntekts-tallet kommer inn i styredekken, men den umiddelbare inntekts-impulsen er bare en brøkdel av hva nedtiden faktisk koster. De jeg har sett organisasjoner jevnt over overse er:

Først er det kundetillit. SLA-straffer er en juridisk konstruksjon – de fanger ikke kunden som stille og rolig forlater, eller bedrifts-prospektet som så status-siden din på feil øyeblikk og valgte en konkurrent. Den skaden er langsom, usynlig og permanent på en måte som en refusjonsjekkel bare ikke er.

Det andre er ingeniør-avhopping og utbrenthet. Varslingstrøtthet er virkelig. Når dine beste ingeniører blir gjentatte ganger trukket inn i høy-stress-episoder – spesielt de som kunne ha blitt forebygget – begynner de å spørre om dette er riktig sted å bygge sin karriere. Å erstatte en senior ingeniør koster hvor som helst fra en til to ganger deres årlige lønn når du faktorer inn rekruttering, onboarding og tap av institusjonell kunnskap. Ingen setter det i post-mortem.

Tredje er mulighet-kostnad. Hver time et ingeniør-team tilbringer med å slåss mot brann er en time ikke brukt på å bygge et produkt. Det er vanskelig å sette på en regneark, men kumulert over måneder, blåser det stille opp din roadmap.

Ingeniører blir ofte trukket bort fra å bygge nye funksjoner for å svare på produksjons-episoder. Hvordan påvirker denne konstante brannslukkingen produkt-innovasjon og langsiktige utviklings-planer?

Det skaper en avgift på ingeniør-teamets evne til å bygge. Hvert team har en begrenset mengde kapasitet, og når en betydelig del av den hele tiden blir omdirigert til episoder, er den kumulative effekten på produktutvikling alvorlig. Veikart-forpliktelsene blir missede. Teknisk gjeld blir ikke betalt ned. Funksjoner blir levert med mindre rigor fordi det er press for å gjøre opp for tapt tid.

Hva som er spesielt skadelig er usikkerheten. Et team kan planlegge sin sprint med gode intensjoner, og så blåser en stor episode opp på en tirsdag og alt annet blir sekundært. Den type vedvarende usikkerhet gjør det nesten umulig å bygge en kultur av dyp arbeid – som ultimate driver de beste ingeniør-resultatene.

Det skaper også en selv-forsterkende syklus. Utsatt investering betyr flere episoder, som betyr mer brannslukking, som betyr enda mindre tid til å investere i de underliggende problemene. Hos Strudel er en stor del av hva vi bygger spesielt for SRE-teamene som lever dette hver dag.

Strudel kobler kundestøtte-data, logger, produksjonssystemer og kodearkiv for å identifisere årsaker raskere. Hvordan bringer AI sammen disse forskjellige tekniske signalene på en måte som tradisjonelle overvåkings-verktøy ikke kan?

Tradisjonelle overvåkings-verktøy er fundamentalt varsel-systemer. De er gode til å fortelle deg noe har krysset en terskel – en latens-spike, en feil-rate som stiger, en pod-crash. Hva de ikke kan gjøre er å resonnere over domener.

De vet ikke at feil-rate-spiken i din betalings-tjeneste skjedde fire minutter etter en deploy til en avhengighet, og at en kundestøtte-billett som nevner kjøps-feil kom inn rundt samme tid, og at siste gang denne mønsteren dukket opp i dine logger var for seks måneder siden under en database-migrering.

Den tverr-domene-korrelasjonen er hva AI muliggjør. Vi kan behandle en Zendesk-billett, en GitHub-kommit, en Datadog (DDOG ) -sporing og en CloudWatch-logg som en del av en samlet historie i stedet for isolerte data-punkter. AI overflater ikke bare hva som er feil, men også den sannsynlige årsaken og hvor – og den grunner det i bevis som en menneskelig ingeniør faktisk kan verifisere og handle på. Vi ber ikke teamene om å stole på en svart boks. Vi gir dem en velfundert hypotese og en forhånds-start.

Du beskriver Strudel som levering “ingeniør-intelligens”. Hva betyr dette konseptet i praksis, og hvordan er det forskjellig fra konvensjonelle overvåkings- eller AIOps-plattformer?

Kristin: Overvåkning er fundamentalt om instrumentering og synlighet – å sikre at telemetri er der og at team kan spørre det. AIOps, i de fleste av sine nåværende implementeringer, er om å redusere varsel-støy gjennom ML-basert korrelasjon og anomali-deteksjon. Begge er virkelig verdifulle, og vi integrerer med dem.

Men ingeniør-intelligens er et lag over. Vi tar hva AIOps gjør og utvider på det. Der AIOps forteller deg noe er feil, hjelper ingeniør-intelligens deg å forstå hvorfor det er feil, hvor det startet og hva du skal gjøre med det – trekker signaler fra hele din stack, inkludert kilder tradisjonelle AIOps-verktøy ikke ser på, som kundestøtte-billetter eller kode-endringer. Målet er ikke bare å redusere støy. Det er å gi ditt team en fullstendig, handlebar bilde så de kan løse problemet raskere og komme tilbake til å bygge.

AI-agenter blir stadig mer deployert for å automatisere komplekse tekniske arbeidsflyter. Hva rolle ser du AI-agenter spille i å diagnostisere og løse programvare-episoder over de neste fem årene?

Jeg tror det mer interessante spørsmålet ikke er hva agenter vil gjøre – det er hva ingeniører vil slutte å gjøre. De beste ingeniører jeg har jobbet med, gikk ikke inn i denne bransjen for å tilbringe nattene med å varsle varsler eller lete gjennom logger for en konfigurasjons-endring noen gjorde på en fredag-ettermiddag. Det er ikke hvorfor de ble gode på jobben sin. Men det er hva en stor del av deres tid blir spist opp av.

Over de neste fem årene tror jeg agenter tar på seg mye av den sliten – det repetitive, mønster-matching, kontekst-sammen- arbeidet som er viktig, men ikke hvor senior ingeniør-talent bør tilbringe sin tid. Det frigjør mennesker til å fokusere på komplekse problemer, arkitektur-beslutninger, ting som faktisk krever menneskelig dømmekraft.

Hva som er spennende for meg er at dette ikke bare er en fremtidig tilstand – vi ser det spille ut nå, inkludert hos Strudel. Vår hele veikart er rettet mot å fjerne administrativt og vedlikeholds-arbeid fra ingeniørers plater. Og hva vi finner, ærlig talt, er at det endrer hva som er mulig for et team. Du kan bygge mer, flytte raskere og gjøre det med færre mennesker – fordi menneskene du har, er fokusert på strategi og kompleksitet i stedet for å betale skatt på det repetitive.

Mange nedtider oppstår fra små feil eller konfigurasjonsendringer som glipper gjennom testing. Hvordan kan AI-systemer identifisere subtile mønster i kode, logger eller infrastruktur-signal tidlig nok til å forhindre større episoder?

Velutformet AI har en virkelig fordel her, og det er ikke at den er smartere enn dine ingeniører – det er at den aldri glemmer og aldri sover. En menneskelig kan ikke koble en subtil log-mønster i dag til noe som skjedde for seks måneder siden i en helt annen del av systemet. AI kan. Den ser på alt, hele tiden, og den har en mye lengre og bredere minne enn noen enkelt person på ditt team.

Det som også er viktig, er at det ikke bare handler om å finne mønster. Det handler om å forstå hva som skjer og hvorfor. AI kan hjelpe med det, men den kan ikke gjøre det alene. Den trenger data av høy kvalitet og en god forståelse av systemet for å kunne identifisere mønster og årsaker.

Bedrifter investerer ofte tungt i detekterings-verktøy, men har likevel problemer med gjennomsnittlig tid til løsning. Hva er de største hindrene for å lukke gapet mellom episode-deteksjon og faktisk årsak-løsning?

Detektering er i stor grad et løst problem på dette punktet. De fleste teamene har varsler. De vet noe er feil. Gapet er alt som skjer etterpå.

Når en ingeniør blir varslet, går de ikke inn i en klar situasjon med all relevant kontekst samlet. De går inn i en rot. De må finne ut hva som har endret seg, når det endret seg, hvilken system det berørte, om det er en kunde-impakt, om det er relatert til noe som skjedde forrige uke. De trekker fra Slack, fra dashboards, fra deploy-logger, fra støtte-billetter – gjør den sammen- arbeidet manuelt, under press, ofte midt på natten.

Den kontekst-sammen-arbeidet er flaskenhalen. Det er ikke at ingeniører og tekniske støtte-team ikke vet hvordan de skal løse problemer – det er at de bruker de første 30 til 60 minuttene av hver episode bare på å forstå hva de ser på. Det er der Strudel bor. Vår hele tese er at hvis du kan gi en ingeniør et sammenhengende, bevis-basert bilde av hva som skjedde og hvorfor – rett når de trenger det – kan du dramatisk komprimere det gapet. Løsnings-arbeidet er fortsatt deres. Vi får dem bare til start-linjen mye raskere.

Når AI-systemer begynner å analysere produksjons-data, kodebasen og operasjonelle logger, hva slags styring eller sikkerhets-overveielser bør ingeniør-teamene ha i mente når de deployer disse verktøyene?

Det ene jeg føler sterkest om her, er dette: mennesker bør fortsatt gjennomgå kode som går i produksjon.

Jeg har talt med mange ingeniører om dette, og en ting jeg hører igjen og igjen, er at AI skriver feil effektivt og smart. Veldig smart, faktisk. På en måte som kan være virkelig vanskelig å fange – selv for senior ingeniører som gjennomgår koden nøye. Feilene er ikke alltid åpenbare. De kan se perfekt ut på overflaten.

Så når AI skriver mer og mer av koden som havner i produksjon, tror jeg vi kommer til å se flere av disse subtile, vanskelige å oppdage feil slippe gjennom – ikke fordi noen var uaktsom, men fordi naturen til AI-genererte feil er annerledes. Hardere å se i gjennomgang. Hardere å fange i testing.

Ærlig talt? Det er en av grunnene til at jeg tror tilfellet for hva Strudel gjør bare blir sterkere over tid. Hvis flere feil havner i produksjon, blir evnen til å finne og løse dem raskere mer viktig, ikke mindre. Styrings-spørsmålet er ikke bare om data-tilgangskontroller og tillatelser – selv om det betyr og teamene bør være nøye med hva slags data de gir noen AI-system tilgang til. Det handler også om å holde mennesker på riktige sjekkpunkter, spesielt rundt alt som berører produksjon.

Ser du frem til at fremtiden for pålitelighets-ingeniør-arbeid vil skifte mot AI-først-infrastruktur, hvor autonome systemer overvåker, diagnostiserer og til og med fikser problemer før mennesker er klar over dem? Hvis ja, hva ser den fremtidige arbeidsflyten ut for ingeniører?

Jeg tror vi er på vei dit, men jeg er pragmatisk om tidsrammen. Fullt autonome systemer som løser produksjons-episoder uten noen menneskelig varsel – det er ikke der vi er, og jeg tror ikke det er der vi kommer til å være de neste årene. Og jeg tror det er greit.

Hva jeg tror, er at løkken blir mye tettere og mindre smertefull. Fremtiden jeg er spennende om, er ikke en hvor mennesker fjernes fra ligningen – det er en hvor menneskene som er integrert i prosessen, tilbringer sin tid på delene som faktisk krever dem. Dømmekraft. Nyttige situasjoner. En episode du aldri har sett før. AI håndterer mønster-matching, kontekst-sammen-arbeid, rutine-triage. Ingeniører håndterer beslutningene.

For ingeniører selv, tror jeg det ser ut som: mindre tid på vakt midt på natten for ting som ikke trengte å våkne dem, og mer tid på å bygge systemer som ikke bryter sammen fra første sted. Brannslukkingen forsvinner ikke helt. Men den blir unntaket i stedet for standard-tilstanden for å være en ingeniør i en bedrift som kjører programvare i skala. Det er en fremtid verdt å bygge mot.

Takk for det flotte intervjuet, lesere som ønsker å lære mer, bør besøke Strudel.