Moshe Sambol, VP for Customer Solutions hos Lightrun – Interviewserie

Moshe Sambol, VP for Customer Solutions hos Lightrun – har mere end to årtiers erfaring inden for softwareudvikling, arkitektur, cloud-infrastruktur og kundeorienteret teknisk ledelse. Før han kom til Lightrun i 2022, tilbragte han næsten et årti hos Google, hvor han havde flere ledende stillinger, herunder Cloud Customer Engineering Manager, hvor han hjalp organisationer med at adoptere og skala Google Cloud-teknologier. Tidligere i sin karriere havde Sambol ingeniør- og udviklingslederroller hos Oracle, Sun Microsystems, BMC Software og JPMorgan Chase. Hos Lightrun startede han med at lede global Solution Engineering, før han blev VP for Customer Solutions, hvor han fokuserer på at hjælpe kunder med at adoptere virksomhedens Runtime Insights-teknologi og omsætte dens kapaciteter til målbare forretnings- og udviklerproduktivitetsgevinster.

Lightrun er en AI-nativ platform for teknisk pålidelighed, designet til at give udviklere og AI-agenter direkte indsigt i, hvordan software opfører sig, mens den køres. Dens teknologi kan dynamisk fange logs, snapshots, metrikker, spor, variabelværdier og kørselskontekst fra live-applikationer uden at kræve kodeændringer eller genudleveringer. Virksomheden udvider stadig denne runtime-intelligens til AI-understøttet softwareudvikling gennem Lightrun MCP, som anvender Model Context Protocol til at give kodestøtter og agenter live-applikationskontekst i stedet for kun at afhænge af statisk kildekode. Dette ermögiller AI-systemer at undersøge produktionsproblemer, validere hypoteser mod virkelig kørselsadfærd og støtte rodårsagsanalyse, mens de inkorporerer virksomhedskontroller som rollebaseret adgang og følsomme data-redigering.

Dit karriere har spændt over hånd-til-hånd softwareudvikling og arkitektur, cloud-kunde-teknisk ledelse hos Google, global solution engineering og nu kunde-løsninger hos Lightrun. Hvordan har denne kombination af bygning af software og arbejde direkte med enterprise-kunder formet din forståelse af, hvad der adskiller en imponerende AI-agent-demonstration fra et system, der kan tillides i produktion?

Der er en stor forskel på at vise, hvad en AI-agent kan gøre, og at bevise, at den kan tillides i en enterprise-miljø. Dette skyldes, at agenter kun er en del af et produktionsklart system. Rammen omkring det er lige så vigtig. Den skal påtvinge mindst-privilegeret adgang, overvåge aktivitet, bevare en revisionshistorik, forhindre uacceptabelt risikable handlinger og bringe en menneske ind, når det er nødvendigt.

Agenter er i sig selv forskellige fra traditionel software, fordi udviklere ikke foreskriver nøjagtigt, hvordan systemet vil fungere. Vi sætter et mål, giver værktøjer og vejledning, og modellen bestemmer, hvordan den skal fortsætte. Denne fleksibilitet er kraftfuld, men den gør også systemets adfærd sværere at forudsige.

For virksomheder, især de i regulerede brancher, er produktionsworkflows, der normalt fungerer eller tager en urealistisk lang tid at fuldføre, ikke-startere. Produktionsmiljøer indeholder følsomme data, kildekode og immaterielle aktiver, så organisationer skal kunne forhindre, at agenterne afslører denne information eller tager kreative, men uacceptable, veje til at opnå deres mål. Dette bliver stadig mere vigtigt, da hver uge bringer et nyt eksempel på et AI-system, der, i sin stræben efter at nå et mål, ender med at være sårbart over for eller forårsager en sikkerhedsudnyttelse.

De fleste ledere, jeg taler med, vurderer stadig agenter på samme måde, som de ville en ny medarbejder: på evner, dømmekraft og output. Det virkelige spørgsmål er ikke, om agenten er intelligent nok. Det er, om systemet omkring det kan fange og indeholde øjeblikke, hvor det ikke er.

Mange virksomheder troede oprindeligt, at opbygning af en AI-agent primært var et spørgsmål om at skrive en effektiv prompt. Hvad forstod organisationerne ikke omkring den tekniske, arkitektoniske og operationelle krav bag produktionsklare agenter?

Jeg tror, den største misforståelse var en næsten naiv tro på AI’s evne til at løse enhver udfordring, når blot givet en vel skrevet prompt, relevant kontekst og passende værktøjer. Teams forbinder deres LLM med kode, dokumentation, billetter og historisk telemetri og forventer derefter, at det kan forstå vej til den rigtige beslutning.

Hvad de ikke byggede var en verifikationsmodel for hvert trin i AI’s resonnering. En af AI’s store styrker er, at den bruger sandsynlighedsbaseret resonnering, finder og tager en af mange mulige ruter til at nå et mål. I komplekse, sammenhængende produktionsmiljøer introducerer denne styrke dog alvorlige risici: en enkelt beslutning kan udløse downstream-regressioner, stille fejl eller anden uventet adfærd, der truer den operationelle robusthed af et kørende system.

Dette er, hvor deterministisk styring bliver essentiel. Agentens resonnering kan forblive sandsynlighedsbaseret, men checkpoints omkring dens handlinger kan ikke. For en agent, der deltar i en teknisk workflow, kræver dette en verifikationsstep, der checker dens hypotetiske næste handling mod produktionsrealiteten, en deterministisk port og ikke endnu en sandsynlighedsbaseret gæt. Den skal se, hvad konsekvensen af den beslutning vil være, og kun godkende den, når den har fastslået, at handlingen er sikker.

Når du ser på den første bølge af internt udviklede enterprise-agenter, hvad er de mest almindelige arkitektoniske fejl, du ser, og hvilke problemer kan korrigeres inkrementelt i stedet for at kræve en komplet genopbygning?

Det centrale bekymring, jeg hele tiden vender tilbage til, er validering. Agenter kan blive en sort kasse: de indsamler information fra en række kilder og tager derefter beslutninger, der ser rimelige ud i princippet, men som måske ikke er passende for realiteterne i et komplekst produktionsmiljø.

Det peger på en mere grundlæggende ændring, og det er noget, vi taler om konstant hos Lightrun, mens vi hjælper kunder med at bygge agenter til automatisering af deres tekniske organisationer. Teams skal genopbygge den agente flux selv og sætte porte på agentens handlinger for at sikre, at dets brug af værktøjer er underlagt tilsyn, revision og gennemgang. At give agenten selv en stærk feedback-løkke – herunder live runtime-observabilitet – fokuserer dets kontekst på, hvad der sker lige nu. Den adgang er, hvad der låser agenten til at validere sine egne designbeslutninger, rodårsagsanalyse og fejlreduceringsforslag mod produktionsrealiteten i stedet for mod antagelser baseret på statisk analyse af kode eller gammel telemetri.

En dramatisk genopbygning er ikke den eneste mulighed. Hvad der kan gøres inkrementelt, og det er ikke revolutionerende, men det er essentiel, er at investere i de færdigheder, der styrer agentens adfærd. Omhyggeligt udformede og vurderede færdigheder skubber agenten i retning af en deterministisk workflow. Teams behøver ikke at genopbygge hele systemet for at få den fordel. De skal behandle færdighedsdesign med samme rigor, de ville give enhver anden del af produktionslogik.

Hvorfor fungerer nogle agenter godt under kontrollerede tests, men begynder at producere inkonsistente, ufuldstændige eller misvisende resultater, når de udsættes for rigtige brugere, ændrende data, eksterne værktøjer og komplekse produktionsmiljøer?

Kontrollerede tests fjerner det meste af variationen, der vil definere produktionsrealiteten, som AI skal håndtere. Data er kurateret, værktøjsadfærd er forudsigelig, tilladelser er kendt, og vi dækker en vej, vi havde forventet. Når du frigør en agent til at interagere med rigtige brugere og deres effekter i live-systemer, er du ikke sammenlignelig med lignende.

Brugere introducerer tvetydige anmodninger og kører samtidige handlinger, systemtilstanden er i konstant flux, agenten skal ofte arbejde fra delvis data, og eksterne værktøjer bringer deres egen latency og fejlmodus oven i det. Fordi modellen er sandsynlighedsbaseret, skaber hver ny variabel en ny mulighed for, at workflow kan afvige eller forstærke en tidligere fejl.

Det farlige er, at agenten kan fortsætte med at se ud til at fungere korrekt, mens den producerer forkerte, men plausibleresultater, bygget på delvis data eller antagelser rod i forældet information. Det er derfor, produktionsagenter behøver kontinuerlig evaluering, der fortsætter efter lanceringen, eksplicit håndtering af manglende data og værktøjsfejl samt live-verifikation af en beslutning, før den fuldfører en høj-impact-handling.

Lightrun lægger stor vægt på at give AI-systemer adgang til runtime-kontekst. Hvad information giver runtime-kontekst, som konventionelle logs, metrikker og spor måske ikke når, og hvorfor er denne information særligt vigtig for at diagnosticere agentfejl?

Konventionel overvågning viser de ydre symptomer på systemadfærd, ofte aggregat, samplet eller filteret gennem dashboards og alerts, der udløser på grænseværdier. De er ofte afhængige af beslutninger, udviklere tog, da koden blev skrevet: hvilken information vil være af interesse i fremtiden? Hvad er værd at logge eller måle? Runtime-kontekst frakobler synlighed fra dette behov for at vide på forhånd, hvad der måske er af interesse, og giver en granuleret data, der viser, hvad der sker under køretiden, og hvordan vi kom dertil.

Det virkelige gap er statisk versus dynamisk data. Konventionelle logs, metrikker og spor er statiske og producerer en historisk beretning om, hvad der skete. Lightruns runtime-kontekst er dynamisk. Den giver en agent mulighed for at indsætte ny instrumentation i kørende kode på krav og observere de præcise variabelværdier, funktionsargumenter, objekttilstand, call-stack eller branch-betingelser, som de opstår.

Denne forskel er særligt vigtig for at diagnosticere fejl i agent-genereret kode, fordi disse ofte er stille. En agent kan vælge det forkerte værktøj, give det forkerte argument eller handle på en forældet antagelse og stadig fuldføre sin opgave uden at udløse nogen fejl. En fejl som den vil ikke vise sig i statisk telemetri, fordi ingen vidste på forhånd at instrumentere for det. Uventet adfærd kræver en dynamisk undersøgelse direkte på det kørende system, indsættelse af ny instrumentation præcis, hvor agentens model af verden afveg fra realiteten, i stedet for at afhænge af, hvad der allerede blev optaget.

Det er, hvad der gør dynamisk runtime-kontekst den naturlige verifikationslag for AI-genererede beslutninger i teknisk udvikling.

Hvordan kan Model Context Protocol (MCP) og lignende integrationslag tillade kodestøtter at lære af rigtig kørselsadfærd uden at give dem for megen eller usikker adgang til produktionsystemer?

MCP og andre kontrollerede adgange til eksterne værktøjer (f.eks. CLI-vrappers) lader en agent kalde en specifik, omfattet kapacitet i stedet for at få bred adgang til et system og tillides til at opføre sig. En agent forbundet gennem en MCP-server til runtime-kontekst kan anmode om læse-adgang, en variabels værdi, en call-sti, om en grænseværdi blev overskredet, uden at røre skriveadgang, uden mulighed for at genudleverer noget og uden at kræve stående legitimationsoplysninger til den underliggende miljø.

Når du genopbygger en første-generations-agent, hvordan skal virksomheder tilgå værktøjsadgang, hukommelse, datahentning, evaluering, menneskelig tilsyn og reserveprocedurer som dele af én samlet arkitektur i stedet for separate funktioner?

Du kan ikke montere disse dele uafhængigt, fordi hver enkelt ændrer de andre. De bedste steder at starte er rammen, harness, der kontrollerer agent-løkken, og den samlede workflow-koordinering, der binder sammen flere agenter og andre aktører. For en rodårsagsanalyse-workflow, for eksempel, skal teams beslutte, hvilken bevis der kræves, hvilke systemer agenten må inspicere, om den kan offentliggøre en konklusion eller kun udkaste en, hvornår en menneske skal godkende næste skridt, og hvad der sker, hvis runtime-bevis ikke er tilgængeligt.

Når denne kontrakt er klar, giver harness og ramme mekanismerne til at påtvinge disse retningslinjer. MCP-gateways kan udnyttes til at begrænse agentens adgang til bestemte kapaciteter, der er relevante for dets formål. Værktøjer kan tildeles med mindst-privilegie. Hukommelse kan overvåges med følsomme data-redigering, der reduceres deterministisk. Hentning kan designes omkring beviset, workflow behøver.

Evaluering, tilsyn og reserve lukker derefter cirklen. Systemet skal måle, om konklusioner er korrekte og understøttet, bringe en menneske ind, når risiko eller usikkerhed krydser en defineret grænseværdi, og stoppe eller falde tilbage til en læse-anbefaling, når det ikke kan samle nok bevis. En fælles revisionspost skal forbinde udløser, tilladelser, bevis, værktøjskald, godkendelser, handling og resultat. Det er, hvad der gør disse komponenter én produktionsarkitektur i stedet for seks separate funktioner.

Hvad med sikkerhedsforanstaltninger skal omgive agenter, der kan inspicere live-applikationer eller deltage i site-reliability-engineering-workflows, især i regulerede miljøer, hvor adgangskontrol, privatliv, revision og operationel stabilitet er kritiske?

Dette var et af de centrale designspørgsmål, da vi byggede Lightrun AI SRE. En AI SRE opererer tæt på nogle af de mest følsomme systemer i en organisation, så vi designede den som en privilegeret operationel aktør, ikke en chat-assistent. En vigtig beslutning var at adskille inspektionssplanet fra handlingssplanet. AI SRE indsamler bevis gennem læse-adgangsintegrationer og Lightruns sandboxede runtime-instrumentering, med adgang begrænset af identitet, lejer, service og miljø. Den kan inspicere live-kørsel og generere manglende bevis, men runtime-inspektionsslaget kan ikke ændre applikationsstatus.

I et reguleringssystem skal denne grænse understøttes af RBAC, SSO, lejertil isolation, PII-redigering, retentionskontrol og en revisionshistorik, der viser, hvilke værktøjer og bevis understøttede hver konklusion. Vi har også behov for operationelle begrænsninger omkring, hvor meget data der kan indsamles, hvor ofte runtime kan spørges, og hvilke handlinger kræver godkendelse. Hvis bevis mangler eller en konklusion ikke kan verificeres, skal AI SRE sige det og overdrage beslutningen til en menneske i stedet for at handle, som om det ved mere, end det gør. Målet er kontrolleret autonomi: nyttig nok til at accelerere en undersøgelse, men begrænset nok til at forblive sikker for det live-system.

Når virksomheder går ud over eksperimentelle agenter, hvad skal målinger bestemme, om en agent er ægte produktionsklar, og hvordan forventer du, at forholdet mellem AI-agenter og menneskelige ingeniører vil udvikle sig over de næste flere år?

Jeg ville bedømme produktionsklarhed efter, hvor ofte en AI-agents handlinger producerer de ønskede resultater, dens konklusioner holder stand mod, hvad der faktisk var sandt i produktionen, uhæmmet konklusioner fanges, før handling, og om den fejler synligt og sikkert, når beviset ikke er til stede. For ingeniør-agenter er verificeret resultatnøjagtighed, bevisdækning, tid til at bekræfte rodårsag, succesfuld reserve-procent og post-handlingsresultater de kerne-målinger, vi skal fokusere på.

Over de næste flere år forventer jeg, at agenter vil overtage mere af bevisindsamlingen og den første undersøgelse samt overvågning af agenter-workflows og læring fra erfaring og feedback, mens ingeniører fastsætter politik, løser tvivl, godkender høj-risiko-handlinger og styrer selvforbedrende agenter-systemer. Tillid vil udvide workflow efter workflow. Agenter, der kan spore deres konklusioner tilbage til live-bevis og klart afsløre, hvad de ikke kunne verificere, vil tjene større autonomi. De, der ikke kan, vil forblive begrænset til smalle, lav-risiko-opgaver, uanset hvor flydende de lyder.

Tak for det store interview, læsere, der ønsker at lære mere, skal besøge Lightrun.