Kristin Isaac, CEO en mede-oprichter van Strudel – Interviewreeks

Kristin Isaac, CEO en mede-oprichter van Strudel is een ervaren leider in enterprise-technologie die senior rollen heeft gehad bij LinkedIn, Udemy, ESPN en Disney voordat ze Strudel oprichtte. Ze richt zich nu op het aanpakken van een van de grootste frictiepunten in software-organisaties: de kloof tussen klantenservice en engineering. Bij Strudel bouwt ze een AI-gedreven platform dat technische ondersteuningsteams helpt om complexe problemen sneller op te lossen door ondersteuningsaanvragen rechtstreeks te koppelen aan engineeringsinformatie. Haar achtergrond in het schalen van teams, het opbouwen van go-to-marktstrategieën en het stimuleren van groei in globale organisaties heeft geholpen om Strudels snelle start en sterke positie in de enterprise AI- en developer tools-markt vorm te geven.

Strudel is een AI-platform dat is gebouwd om geavanceerde technische ondersteuning te automatiseren door logs, productiegegevens, coderepositories en eerdere ondersteuningsgeschiedenis te analyseren om oorzaken te identificeren en oplossingen aan te bevelen. Het doel is om de tijd en engineeringsinspanning te verminderen die nodig is om moeilijke ondersteuningsgevallen op te lossen, vooral de soorten escalaties die gewoonlijk senior technische middelen consumeren. Door ondersteuning rechtstreeks te koppelen aan onderliggende technische problemen, positioneert Strudel zich als een instrument dat enterprise-ondersteuningsoperaties sneller, efficiënter en schaalbaarder kan maken.

U hebt leiderschapsrollen gehad bij organisaties als LinkedIn, Udemy en Disney voordat u Strudel in 2025 oprichtte. Welke ervaringen uit die rollen hebben u uiteindelijk overtuigd dat engineeringsteams een nieuw soort AI-gebaseerd “engineeringsinformatie”-platform nodig hadden, en hoe heeft die inzicht de oprichting van Strudel gevormd?

Elk bedrijf waar ik voor werkte, had een andere versie van hetzelfde probleem. Bij Disney waren de inzetten enorm – als een streamingplatform uitviel tijdens een grote lancering, was het niet alleen een omzetreductie, maar ook een merk-moment. Bij LinkedIn was de schaal meedogenloos. Er waren duizenden diensten die allemaal lawaai produceerden, en zelfs de beste teams worstelden om bij te blijven. Bij Udemy zag ik een mager team heroïsche dingen doen met beperkte tooling.

Wat alle drie en mijn mede-oprichters, Shai Rubin en Brian Kaufman, die ervaring hadden met het leiden van engineeringsteams, verbindt, was dat engineers meer tijd besteedden aan het reconstrueren van context dan aan het daadwerkelijk oplossen van problemen. Iemand wordt om 2 uur ‘s nachts gewekt, en voordat ze zelfs maar kunnen beginnen met diagnosticeren, moeten ze door Slack-threads, dashboards, Jira-tickets, implementatielogs – alleen maar proberen te begrijpen wat veranderde en wanneer. Ze spelen eigenlijk detective voordat ze hun eigenlijke werk kunnen doen. Dat is een verspilling van ongelooflijk getalenteerde mensen.

Ik dacht steeds: er moet een slimmere manier zijn om te laten zien wat er echt toe doet, wanneer het toe doet. Dat is eigenlijk de kiem van Strudel.

Veel bedrijven meten de financiële impact van uitval in termen van verloren omzet of SLA-boetes. Uit uw ervaring, welke minder zichtbare kosten van uitval schatten organisaties consistent onderschatten?

Het omzetcijfer komt in het bestuursdebat terecht, maar de directe omzetreductie is slechts een fractie van wat de uitval eigenlijk kost. Degenen die ik heb gezien die organisaties consistent missen, vallen in een paar categorieën.

De eerste is klantvertrouwen. SLA-boetes zijn een juridische constructie – ze vangen de klant niet die stilzwijgend afhaakt, of het enterprise-voorbeeld dat uw statuspagina op het verkeerde moment zag en een concurrent koos. Die schade is langzaam, onzichtbaar en permanent op een manier die een terugbetaalcheque eenvoudig niet is.

De tweede is engineer-vertrek en burn-out. On-call-moeheid is echt. Wanneer uw beste engineers herhaaldelijk in hoge-stress-incidenten worden getrokken – vooral die welke voorkomen hadden kunnen worden – beginnen ze te twijfelen of dit de juiste plek is om hun carrière op te bouwen. Het vervangen van een senior engineer kost ergens tussen de een en twee keer hun jaarlijkse salaris wanneer u rekening houdt met werving, inwerken en verloren institutionele kennis. Niemand zet dat in de post-mortem.

De derde is kansenkost. Elk uur dat een engineerings-team besteedt aan brandweer, is een uur dat niet wordt besteed aan het bouwen van een product. Dat is moeilijk om op een spreadsheet te zetten, maar gecumuleerd over maanden, blaast het stil uw roadmap op.

Engineers worden vaak weggehaald van het bouwen van nieuwe functies om te reageren op productie-incidenten. Hoe beïnvloedt deze constante brandweer de productinnovatie en de langetermijnontwikkelingsroadmap?

Het creëert een belasting op de capaciteit van uw engineerings-team om te bouwen. Elk team heeft een eindige hoeveelheid bandbreedte, en wanneer een aanzienlijk deel daarvan constant wordt omgeleid naar incidenten, is het cumulatieve effect op productontwikkeling ernstig. Roadmap-verplichtingen worden gemist. Technische schuld wordt niet afgelost. Functies worden uitgevoerd met minder rigor omdat er druk is om verloren tijd in te halen.

Wat bijzonder schadelijk is, is de onvoorspelbaarheid ervan. Een team kan hun sprint plannen met goede bedoelingen, en dan blaast een groot incident op een dinsdag op en alles anders wordt secundair. Die duurzame onvoorspelbaarheid maakt het bijna onmogelijk om een cultuur van diepe werk te bouwen – wat uiteindelijk de beste engineeringsresultaten drijft.

Het creëert ook een zelfversterkende cyclus. Uitgestelde investering betekent meer incidenten, wat meer brandweer betekent, wat nog minder tijd betekent om te investeren in de onderliggende problemen. Bij Strudel is een groot deel van wat we bouwen specifiek voor de SRE-teams die dit elke dag meemaken.

Strudel verbindt klantenservicegegevens, logs, productiesystemen en coderepositories om oorzaken sneller te identificeren. Hoe brengt AI deze verschillende technische signalen samen op een manier die traditionele bewakingsinstrumenten niet kunnen?

Traditionele bewakingsinstrumenten zijn fundamenteel waarschuwingssystemen. Ze zijn geweldig in het vertellen dat iets een drempel is overschreden – een latentie-spike, een foutpercentage dat klimt, een pod dat crasht. Wat ze niet kunnen doen, is redeneren over domeinen.

Ze weten niet dat de foutpercentage-spike in uw betalingsdienst vier minuten na een implementatie van een afhankelijkheid gebeurde, en dat een klantenserviceticket met betrekking tot checkout-falen rond dezelfde tijd binnenkwam, en dat het laatste keer dat dit patroon in uw logs verscheen, zes maanden geleden was tijdens een database-migratie.

Die cross-domein-correlatie is wat AI mogelijk maakt. We kunnen een Zendesk-ticket, een GitHub-commit, een Datadog (DDOG ) -trace en een CloudWatch-log behandelen als onderdeel van een verenigd verhaal in plaats van geïsoleerde datapunten. De AI brengt niet alleen naar voren wat kapot is, maar ook het waarschijnlijke waarom en waar – en het baseert dat op bewijs dat een menselijke engineer daadwerkelijk kan verifiëren en actie op ondernemen. We vragen teams niet om een zwarte doos te vertrouwen. We geven ze een goed doordachte hypothese en een voorsprong.

U beschrijft Strudel als het leveren van “engineeringsinformatie”. Wat betekent dat concept in de praktijk, en hoe verschilt het van conventionele observabiliteit- of AIOps-platforms?

Kristin: Observabiliteit is fundamenteel over instrumentatie en zichtbaarheid – ervoor zorgen dat de telemetrie er is en dat teams het kunnen opvragen. AIOps, in de meeste van zijn huidige implementaties, is over het reduceren van alarmruis via ML-gebaseerde correlatie en anomaliedetectie. Beiden zijn waardevol, en we integreren ermee.

Maar engineeringsinformatie is een laag erboven. We nemen wat AIOps doet en breiden het uit. Waar AIOps vertelt dat er iets mis is, helpt engineeringsinformatie u begrijpen waarom het mis is, waar het begon en wat u eraan kunt doen – signalen trekken vanuit uw hele stack, inclusief bronnen die traditionele AIOps-instrumenten niet eens bekijken, zoals klantenservicetickets of code-wijzigingen. Het doel is niet alleen om ruis te reduceren. Het is om uw team een complete, actiegerichte afbeelding te geven zodat ze het probleem sneller kunnen oplossen en terugkeren naar het bouwen.

Denk aan het als het verschil tussen een rookdetector en een brandonderzoeker. Observabiliteit en AIOps zijn de rookdetector – essentieel, maar ze stoppen bij de alarm. Engineeringsinformatie is wat daarna komt: hier is wat er gebeurde, hier is waarom, hier is waar het begon.

AI-agents worden steeds vaker ingezet om complexe technische workflows te automatiseren. Wat is de rol die u AI-agents ziet spelen bij het diagnosticeren en oplossen van software-incidenten in de komende vijf jaar?

Ik denk dat de meer interessante vraag niet is wat agents zullen doen – het is wat engineers zullen stoppen met doen. De beste engineers met wie ik heb gewerkt, zijn niet in dit veld gestapt om hun nachten door te brengen met het trieren van alarmen of het doorzoeken van logs naar een configuratieverandering die iemand op een vrijdagmiddag heeft gemaakt. Dat is niet waarom ze goed zijn in hun baan. Maar dat is waar een groot deel van hun tijd doorheen wordt opgeslokt.

In de komende vijf jaar denk ik dat agents een groot deel van die grind overnemen – het repetitieve, patroon-matching, context-assemblage-werk dat belangrijk is, maar niet waar senior engineerings-talent zou moeten worden besteed. Dat bevrijdt mensen om te focussen op complexe problemen, architectonische beslissingen, dingen die daadwerkelijk menselijke oordeel vereisen.

Wat spannend is, is dat dit niet alleen een toekomstige staat is – we zien het nu al gebeuren, inclusief bij Strudel. Ons hele roadmap is gericht op het verwijderen van administratieve en onderhoudswerk van engineerings-platen. En wat we vinden, eerlijk gezegd, is dat het verandert wat mogelijk is voor een team. U kunt meer bouwen, sneller verplaatsen en het doen met minder mensen – omdat de mensen die u heeft, gefocust zijn op strategie en complexiteit in plaats van het betalen van hun rekeningen op het repetitieve spul. Dat voelt als een significante verschuiving in hoe teams worden opgebouwd en gestructureerd in de toekomst.

Veel uitval ontstaat uit kleine bugs of configuratieveranderingen die door tests heen glipt. Hoe kunnen AI-systemen subtiele patronen in code, logs of infrastructuursignalen identificeren voordat grote incidenten optreden?

Goed ontworpen AI heeft hier een echt voordeel, en het is niet dat het slimmer is dan uw engineers – het is dat het nooit vergeet en nooit slaapt. Een mens zou mogelijk geen verbinding maken tussen een subtiele log-patroon vandaag en iets dat zes maanden geleden in een compleet andere onderdeel van het systeem gebeurde. AI kan. Het kijkt naar alles, altijd, en het heeft een veel langere en bredere geheugen dan enig individu op uw team.

Maar er is ook iets anders dat we veel van klanten horen: preventie is alleen zo goed als de data eronder. Als uw logs inconsistent, onvolledig of verspreid zijn over een dozijn tools die niet met elkaar praten, werkt de AI met een gefragmenteerde afbeelding. Garbage in, garbage out – dat is nog steeds waar. We besteden veel tijd met klanten aan het denken over datakwaliteit en instrumentatie, omdat de beste AI in de wereld geen signaal kan oppikken dat nooit is vastgelegd.

De antwoord is dus beiden: ja, AI kan dingen eerder oppikken en verbindingen leggen die mensen zouden missen. Maar de teams die de meeste waarde uit het halen, zijn degenen die ook het werk hebben gedaan om ervoor te zorgen dat hun data daadwerkelijk de moeite waard is om over na te denken.

Bedrijven investeren vaak zwaar in detectie-instrumenten, maar worstelen nog steeds met de gemiddelde tijd tot resolutie. Wat zijn de grootste barrières die organisaties ervan weerhouden om de kloof tussen incidentdetectie en daadwerkelijke oorzakelijke resolutie te dichten?

Detectie is grotendeels een opgelost probleem op dit punt. De meeste teams hebben alarmen. Ze weten dat er iets mis is. De kloof is alles wat daarna gebeurt.

Wanneer een engineer wordt gewekt, loopt hij niet in een duidelijke situatie met alle relevante context netjes geassembleerd. Hij loopt in een rommeltje. Hij moet uitvinden wat veranderde, wanneer het veranderde, welk systeem het aanging, of er een klantimpact is, of het gerelateerd is aan iets dat de vorige week gebeurde. Hij trekt uit Slack, uit dashboards, uit implementatielogs, uit ondersteuningsaanvragen – doet dat assemblage-werk handmatig, onder druk, vaak midden in de nacht.

Die context-assemblage is de bottleneck. Het is niet dat engineers en technische ondersteuningsteams niet weten hoe ze problemen moeten oplossen – het is dat ze de eerste 30 tot 60 minuten van elk incident besteden aan het proberen te begrijpen wat ze eigenlijk zien. Dat is waar Strudel leeft. Onze hele these is dat als u een engineer een coherent, bewijs-gebaseerd beeld kunt geven van wat er gebeurde en waarom – recht op het moment dat ze het nodig hebben – u die kloof dramatisch samenperst. Het resolutiewerk is nog steeds van hen. We krijgen ze alleen sneller naar de startlijn.

Terwijl AI-systemen productiegegevens, codebases en operationele logs beginnen te analyseren, welke overwegingen op het gebied van governance of beveiliging moeten engineerings-teams in gedachten houden bij het implementeren van deze instrumenten?

Het ding waar ik me het sterkst over bekommer, is dit: mensen moeten nog steeds code die in productie gaat, controleren.

Ik heb met veel engineers over dit onderwerp gesproken, en één ding dat ik steeds hoor, is dat AI bugs efficiënt en slim schrijft. Echt slim, eigenlijk. Op een manier die echt moeilijk te vangen is – zelfs voor senior engineers die de code zorgvuldig controleren. De bugs zijn niet altijd voor de hand liggend. Ze kunnen er op het eerste gezicht perfect redelijk uitzien.

Dus terwijl AI meer en meer van de code schrijft die in productie terechtkomt, denk ik dat we meer van deze subtiele, moeilijk te detecteren problemen zullen zien glipen – niet omdat iemand onzorgvuldig was, maar omdat de aard van AI-gegenereerde bugs anders is. Moeilijker om te detecteren in een review. Moeilijker om te vangen in tests.

Eerlijk gezegd? Dat is een van de redenen waarom ik denk dat het geval voor wat Strudel doet alleen maar sterker wordt in de loop van de tijd. Als meer bugs in productie terechtkomen, wordt de mogelijkheid om ze sneller te vinden en op te lossen belangrijker, niet minder. De governance-vraag is niet alleen over data-toegangscontroles en machtigingen – hoewel die ertoe doen en teams moeten zorgvuldig zijn over welke data ze elke AI-systeem toegang geven. Het gaat ook over het houden van mensen op de juiste checkpoints, vooral rond alles wat productie raakt.

Kijkt u naar de toekomst, denkt u dat de toekomst van betrouwbaarheidsengineering zal verschuiven naar AI-geleide infrastructuur, waar autonome systemen monitoren, diagnosticeren en zelfs problemen oplossen voordat mensen zich ervan bewust zijn? Zo ja, hoe ziet de toekomstige workflow voor engineers eruit?

Ik denk dat we in die richting gaan, maar ik ben pragmatisch over de tijdlijn. Volledig autonome systemen die productie-incidenten oplossen zonder enige menselijke bewustzijn – dat is niet waar we zijn, en ik denk niet dat we daar de komende jaren zullen zijn. En ik denk dat dat oké is.

Wat ik wel geloof, is dat de lus veel strakker en minder pijnlijk wordt. De toekomst waar ik naar uitkijk, is niet een waarin mensen uit het verhaal worden verwijderd – het is een waarin de mensen die in het proces zijn geïntegreerd, hun tijd besteden aan de delen die echt van hen vereisen. Oordeelsvellingen. Nieuwe situaties. Een incident dat u nog nooit eerder hebt gezien. AI behandelt het patroon-matching, de context-assemblage, de routine-triage. Engineers behandelen de beslissingen.

Voor de engineers zelf denk ik dat het er zo uitziet: minder tijd op call in het midden van de nacht voor dingen die ze niet wakker hoefden te maken, en meer tijd om systemen te bouwen die niet kapot gaan in de eerste plaats. Het brandweerwerk verdwijnt niet helemaal. Maar het wordt de uitzondering in plaats van de standaardtoestand van een engineer in een bedrijf dat software op grote schaal uitvoert. Dat is een toekomst die het waard is om naar toe te werken.

Bedankt voor het geweldige interview, lezers die meer willen leren, kunnen Strudel bezoeken.