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

Kristin Isaac, CEO en mede-oprichter van Strudel is een ervaren leider in enterprise technology 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 wrijvingspunten in softwareorganisaties: 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 opschalen van teams, het opbouwen van go-to-market-strategieën en het stimuleren van groei in mondiale organisaties heeft geholpen om Strudels snelle vroege tractie en sterke positionering 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 voor te stellen. 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 leidinggevende rollen 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 een merkmoment. 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 heldhaftige 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 oplossen van problemen. Iemand wordt om 2 uur ‘s nachts gewekt, en voordat ze zelfs maar kunnen beginnen met diagnosticeren, zijn ze bezig met het doorzoeken van Slack-threads, dashboards, Jira-tickets, implementatielogs – alleen maar om te proberen te begrijpen wat veranderde en wanneer. Ze spelen eigenlijk detective voordat ze hun eigenlijke werk kunnen doen. Dat is een verspilling van uitzonderlijk getalenteerde mensen.

Ik dacht steeds: er moet een slimmere manier zijn om te laten zien wat er echt toe doet, wanneer het ertoe doet. Dat is echt 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 onderschat?

Het omzetcijfer komt in het bestuursrapport terecht, maar de directe omzetimpact is slechts een fractie van wat de uitval eigenlijk kost. Degenen die ik heb gezien die organisaties consistent onderschatten, 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 de enterprise-kandidaat die uw statuspagina op het verkeerde moment zag en een concurrent koos. Die schade is langzaam, onzichtbaar en permanent op een manier die een terugbetaalcheque gewoon niet is.

De tweede is engineer-vertrek en burn-out. On-call-moeheid is echt. Wanneer uw beste engineers herhaaldelijk worden getrokken in high-stress-incidenten – 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 opportuniteitskost. Elk uur dat een engineeringsTeam 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 wanneer het over maanden wordt opgeteld, 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 langetermijnontwikkelingsroadmaps?

Het creëert een belasting op de capaciteit van uw engineeringsTeam om te bouwen. Elk team heeft een eindige hoeveelheid bandbreedte, en wanneer een aanzienlijk deel daarvan constant wordt omgeleid naar incidenten, is het 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 zijn sprint plannen met goede bedoelingen, en dan blaast een groot incident op een dinsdag op en alles wordt secundair. Die voortdurende onvoorspelbaarheid maakt het bijna onmogelijk om een cultuur van diep werk te bouwen – wat uiteindelijk de beste engineeringsresultaten drijft.

Het creëert ook een zelfversterkende cyclus. Uitgestelde investeringen betekenen meer incidenten, die meer brandweer betekenen, die op hun beurt nog minder tijd betekenen om de onderliggende problemen aan te pakken. Bij Strudel is een groot deel van wat we bouwen specifiek voor de SRE-teams die dit elke dag meemaken.

Strudel koppelt 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 om u te vertellen dat iets een drempel is overgestoken – een latentiepiek, een foutpercentage dat stijgt, een pod die crasht. Wat ze niet kunnen doen, is redeneren over domeinen.

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

Die domein-correlatie is wat AI mogelijk maakt. We kunnen een Zendesk-ticket, een GitHub-commit, een Datadog-trace en een CloudWatch-log behandelen als onderdeel van één verenigd verhaal in plaats van geïsoleerde gegevenspunten. De AI brengt niet alleen naar voren wat kapot is, maar ook de waarschijnlijke reden en waar – en het baseert dat op bewijs dat een menselijke engineer daadwerkelijk kan verifiëren en actie op kan ondernemen. We vragen teams niet om een zwarte doos te vertrouwen. We geven ze een goed onderbouwd 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 aanwezig is en dat teams deze kunnen opvragen. AIOps, in de meeste van zijn huidige implementaties, is over het reduceren van waarschuwingslawaai via ML-gebaseerde correlatie en anomaliedetectie. Beide zijn echt waardevol, en we integreren ermee.

Maar engineeringsinformatie is een laag erboven. We nemen wat AIOps doet en breiden dat uit. Waar AIOps u 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 uit uw hele stack, inclusief bronnen die traditionele AIOps-instrumenten niet eens bekijken, zoals klantenservice-tickets of code-wijzigingen. Het doel is niet alleen om lawaai 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 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 interessantere 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 ‘s nachts wakker te worden voor dingen die ze niet hoefden wakker te maken. Dat is niet waarom ze goed werden in hun baan. Maar dat is waar een groot deel van hun tijd doorheen wordt opgesoupeerd.

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 vrijwaart mensen om zich te concentreren op complexe problemen, architectonische beslissingen, dingen die echt 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 administratief en onderhoudswerk van engineerings-teams. 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 hun tijd te besteden aan het afbetalen van repetitief werk. Dat voelt als een betekenisvolle verschuiving in hoe teams worden opgebouwd en gestructureerd in de toekomst.

Veel uitval ontstaat uit kleine bugs of configuratie-wijzigingen die door testen heen glippen. Hoe kunnen AI-systemen subtiele patronen in code, logs of infrastructuursignalen identificeren voordat grote incidenten kunnen worden voorkomen?

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 kan een subtiele log-patroon van vandaag niet in verband brengen met iets dat zes maanden geleden in een heel ander deel van het systeem gebeurde. AI kan. Het kijkt naar alles, altijd, en het heeft een veel langere en bredere geheugen dan enig individu in uw team.

Dat gezegd hebbende, is er ook iets anders dat ik veel van klanten hoor: preventie is alleen zo goed als de data eronder. Als uw logs onvolledig, inconsistent of gesiloëerd zijn over een dozijn tools die niet met elkaar praten, werkt de AI met een gefragmenteerd beeld. Garbage in, garbage out – dat is nog steeds waar. We besteden veel tijd met klanten aan het denken over gegevenskwaliteit en instrumentatie, omdat de beste AI ter wereld geen signaal kan oppikken dat nooit is vastgelegd.

Dus het antwoord is beide: 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 echt 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 oorzaak-resolutie te dichten?

Detectie is grotendeels een opgelost probleem op dit punt. De meeste teams hebben waarschuwingen. 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 uitzoeken wat veranderde, wanneer het veranderde, welk systeem het aanging, of er een klantimpact is, of het gerelateerd is aan iets dat vorige week gebeurde. Hij trekt uit Slack, dashboards, Jira-tickets, implementatielogs – alleen maar om te proberen te begrijpen waar hij naar kijkt. Dat context-assemblage-werk 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 waar ze naar kijken. 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 de kloof dramatisch samenperst. Het resolutiewerk is nog steeds van hen. We krijgen ze alleen sneller naar de startlijn.

Als AI-systemen productiegegevens, codebases en operationele logs beginnen te analyseren, welke overwegingen met betrekking tot 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 code die in productie gaat nog steeds controleren.

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

Dus als AI meer en meer 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 vinden tijdens 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 gegevens-toegangscontrole en -machtigingen – hoewel die ertoe doen en teams daar zorgvuldig over moeten nadenken. Het gaat er ook om mensen op de juiste checkpoints te houden, 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 bewaken, diagnosticeren en zelfs problemen oplossen voordat mensen zich ervan bewust zijn?

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 binnen de komende paar jaar zullen zijn. En ik denk dat dat oké is.

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

Voor de engineers zelf denk ik dat het eruitziet als: minder tijd in de nacht voor dingen die ze niet wakker hoefden te maken, en meer tijd om systemen te bouwen die niet kapot gaan. Het brandweerwerk verdwijnt niet helemaal. Maar het wordt de uitzondering in plaats van de standaardtoestand van een engineer in een bedrijf dat software op schaal uitvoert. Dat is een toekomst waarnaar het de moeite waard is om te bouwen.

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