Moshe Sambol, VP for kundeløsninger i Lightrun – Intervju-serie

Moshe Sambol, VP for kundeløsninger i Lightrun – bringer mer enn to tiår med erfaring fra programvareutvikling, arkitektur, skyinfrastruktur og kundeorientert teknisk ledelse. Før han ble med i Lightrun i 2022, tilbragte han nesten et tiår i Google, der han hadde flere lederstillinger, inkludert Cloud Customer Engineering Manager, og hjalp organisasjoner med å ta i bruk og skalerer Google Cloud-teknologier. Tidligere i sin karriere hadde Sambol ingeniør- og utviklingslederroller i Oracle, Sun Microsystems, BMC Software og JPMorgan Chase. I Lightrun ledet han først global løsningsteknikk før han ble VP for kundeløsninger, der han fokuserer på å hjelpe kunder med å ta i bruk selskapets Runtime Insights-teknologi og omgjøre dens muligheter til målbare forretnings- og utviklerproduktivitetsgevinster.

Lightrun er en AI-nativ plattform for programvaretilgjengelighet designet for å gi utviklere og AI-agenter direkte synlighet på hvordan programvaren oppfører seg mens den kjører. Plattformens teknologi kan dynamisk fange logger, øyeblikksbilder, målinger, spor, variabelverdier og kjørehistorikk fra live-applikasjoner uten å kreve kodeendringer eller gjenutleveringer. Selskapet utvider stadig denne kjørehistorikken til AI-assistert programvareutvikling gjennom Lightrun MCP, som bruker Model Context Protocol for å gi kodehjelpere og agenter live-applikasjonskontekst i stedet for å bare stole på statisk kildekode. Dette muliggjør at AI-systemer kan undersøke produksjonsproblemer, verifisere hypoteser mot faktisk kjørehistorikk og støtte rotårsaksanalyse samtidig som de inkorporerer bedriftskontroller som rollebasert tilgang og sensitivdata-redigering.

Din karriere har spenning fra hånd-til-hånd programvareutvikling og arkitektur, sky-kundeingeniørarbeid i Google, global løsningsteknikk og nå kundeløsninger i Lightrun. Hvordan har denne kombinasjonen av å bygge programvare og arbeide direkte med bedriftskunder formet din forståelse av hva som skiller en imponerende AI-agentdemonstrasjon fra et system som kan stoles på i produksjon?

Det er en stor forskjell på å vise hva en AI-agent kan gjøre og å bevise at den kan stoles på i en bedriftsmiljø. Dette skyldes at agenter bare er en del av et produksjonsklart system. Rammen rundt det er like viktig. Den må påtvinge minst mulig tilgang, overvåke aktivitet, bevare en audit-sporing, forhindre uakseptable risikofylte handlinger og inkorporere en menneskelig faktor når det er nødvendig.

Agenter er i seg selv forskjellige fra tradisjonell programvare, fordi utviklere ikke bestemmer nøyaktig hvordan systemet skal fungere. Vi setter et mål, gir verktøy og veiledning, og modellen bestemmer hvordan den skal fortsette. Den fleksibiliteten er kraftfull, men den gjør også systemets atferd vanskeligere å forutsi.

For bedrifter, spesielt de i regulerte bransjer, er produksjonsarbeidsflyter som vanligvis fungerer eller tar en uforutsigbar mengde tid å fullføre, ikke startbare. Produksjonsmiljøer inneholder sensitiv data, kildekode og immaterielle rettigheter, så organisasjoner må kunne forhindre at agenter eksponerer denne informasjonen eller tar kreative, men uakseptable, veier for å nå målene sine. Dette blir stadig viktigere, ettersom hver uke bringer et nytt eksempel på et AI-system som, i sin iver etter å nå et mål, ender opp sårbart for eller forårsaker en sikkerhetsutnyttelse.

De fleste ledere jeg snakker med, vurderer agenter på samme måte som de ville en ny ansatt: på evner, dømmekraft og utdata. Det virkelige spørsmålet er ikke om agenten er smart nok. Det er om systemet rundt det kan fange og begrense øyeblikkene det ikke er.

Mange bedrifter trodde opprinnelig at å bygge en AI-agent i hovedsak var et spørsmål om å skrive en effektiv prompt. Hva misforsto organisasjonene om ingeniør-, arkitektur- og driftskravene bak produksjonsklare agenter?

Jeg tror den største misforståelsen var en nesten naiv tro på AIens kraft til å løse enhver utfordring, så lenge den fikk en vel skrevet prompt, relevant kontekst og passende verktøy. Teamene koblet sine LLM til kode, dokumentasjon, billetter og historisk telemetri, og så forventet de at den skulle finne veien til riktig avgjørelse.

Hva de ikke bygde, var en verifiseringsmodell for hvert trinn i AIens resonnering. En av AIens store styrker er at den bruker sannsynlighetsbasert resonnering, finner og tar en av mange mulige veier til målet. I komplekse, sammenkoblede produksjonsmiljøer, introduserer denne styrken en alvorlig risiko: en enkelt avgjørelse kan utløse nedstrømsregresjoner, stille feil eller andre uventede atferd som truer den operative motstanden i et kjørende system.

Dette er der deterministisk styring blir essensiell. Agentens resonnering kan forbli sannsynlighetsbasert, men kontrollpunktene rundt dens handlinger kan ikke. For en agent som deltar i en ingeniørarbeidsflyt, krever dette en verifiseringssteg som sjekker dens hypotetiske neste handling mot produksjonsrealiteten, en deterministisk port i stedet for en annen sannsynlighetsbasert gjetning. Den må se hva konsekvensen av den avgjørelsen vil være, og godkjenne den bare når den har bestemt at handlingen er trygg.

Ser du over den første bølgen av internutviklede bedriftsagenter, hva er de vanligste arkitektoniske feilene du ser, og hvilke problemer kan korrigeres inkrementelt i stedet for å kreve en fullstendig ombygging?

Det sentrale problemet jeg kommer tilbake til, er validering. Agenter kan bli en svart boks: de samler informasjon fra en rekke kilder og tar avgjørelser som ser rimelige ut i prinsippet, men som kanskje ikke er passende for realitetene i et komplekst produksjonsmiljø.

Dette peker mot en mer grunnleggende endring, og det er noe vi diskuterer stadig i Lightrun når vi hjelper kunder med å bygge agenter for automatisering av ingeniørorganisasjoner. Teamene må bygge om agenterfløten selv og sette porter på agentens handlinger for å sikre at dens bruk av verktøy er underlagt tilsyn, audit og gjennomgang. Å gi agenten selv en sterk tilbakekoblingsloop – inkludert live kjørehistorikk – fokuserer dens kontekst på hva som skjer nå. Den tilgangen er det som lar agenten verifisere sine egne designavgjørelser, rotårsaksanalyse og feilreduksjonsforslag mot produksjonsrealiteten i stedet for mot antagelser basert på statisk analyse av kode eller gammel telemetri.

En dramatisk ombygging er ikke den eneste valgmuligheten. Hva som kan gjøres inkrementelt, og det er ikke banebrytende, men det er essensielt, er å investere i ferdighetene som styrer agentens atferd. Omhyggelig utformede og evaluerte ferdigheter skyver agenten i retning av en deterministisk arbeidsflyt. Teamene trenger ikke å ombygge hele systemet for å få den fordelen. De må behandle ferdighetsdesign med samme rigor som de ville gi noen annen produksjonslogikk.

Hvorfor fungerer noen agenter godt under kontrollerte tester, men begynner å produsere inkonsistente, ufullstendige eller misvisende resultater når de utsettes for virkelige brukere, endrende data, eksterne verktøy og komplekse produksjonsmiljøer?

Kontrollerte tester fjerner mesteparten av variasjonen som vil definere produksjonsrealiteten som AI-en må håndtere. Dataene er kurerte, verktøyatferd er forutsigbar, tillatelser er kjente, og vi dekker en vei vi hadde forutsett. Når du slipper en agent løs for å samhandle med virkelige brukere og deres effekter i live-systemer, er du ikke sammenlignende like med like.

Brukere introduserer tvetydige forespørsler og kjører samtidige handlinger, systemtilstanden er i konstant flukt, og agenten må ofte arbeide fra delvis data, og eksterne verktøy bringer med seg egen latens og feilmodus i tillegg til det. Fordi modellen er sannsynlighetsbasert, skaper hver ny variabel en ny plass hvor arbeidsflyten kan avvike eller forsterke en tidligere feil.

Det farlige er at agenten kan fortsette å se ut til å fungere korrekt mens den produserer feilaktige, men plausiblene, svar bygget på delvis data eller antagelser basert på gammel informasjon. Derfor trenger produksjonsagenter kontinuerlig evaluering som fortsetter å kjøre etter lansering, eksplisitt håndtering av manglende data og verktøyfeil, og live-verifisering av en avgjørelse før den fullfører en høy-impakt handling.

Lightrun legger stor vekt på å gi AI-systemer tilgang til kjørehistorikk. Hva informasjon gir kjørehistorikk som konvensjonelle logger, målinger og spor kan gå glipp av, og hvorfor er denne informasjonen spesielt viktig for å diagnostisere agentfeil?

Konvensjonell overvåkning viser de ytre symptomene på systematferd, ofte aggregert, samplet eller filtrert gjennom dashboards og varsler som utløses på terskler. De er vanligvis avhengige av avgjørelser tatt av utviklere på tidspunktet da koden ble skrevet: hva vil være av interesse i fremtiden? Hva er verdig å logge eller måle? Kjørehistorikk kobler synlighet fra dette behovet for å vite på forhånd hva som kan være av interesse, og gir granulert data som viser hva som skjer under panseret, og hvordan vi kom dit.

Det virkelige gapet er statisk versus dynamisk data. Konvensjonelle logger, målinger og spor er statiske og produserer en historisk beretning om hva som skjedde. Lightruns kjørehistorikk er dynamisk. Den gir en agent muligheten til å plassere ny instrumentering i kjørende kode, på forespørsel, og observere de eksakte variabelverdiene, funksjonsargumenter, objekttilstand, kallstakk eller grensebetingelser som de skjer.

Denne forskjellen er spesielt viktig for å diagnostisere feil i agentgenerert kode, fordi disse ofte er stille. En agent kan velge feil verktøy, overføre feil argument eller handle på en utdatert antagelse, og likevel fullføre oppgaven uten å utløse noen feil. En feil som den vil ikke vise seg i statisk telemetri, fordi ingen visste på forhånd å instrumentere for det. Uventet atferd krever en dynamisk undersøkelse direkte på det kjørende systemet, plassering av ny instrumentering nøyaktig der agentens modell av verden avvikte fra realiteten, i stedet for å stole på hva som allerede ble registrert.

Det er det som gjør dynamisk kjørehistorikk den naturlige verifiseringslaget for AI-genererte avgjørelser i ingeniørarbeid.

Hvordan kan Model Context Protocol (MCP) og lignende integreringslag tillate kodeagenter å lære fra virkelig kjørehistorikk uten å gi dem eksessiv eller usikker tilgang til produksjonssystemer?

MCP og andre kontrollerte tilganger til eksterne verktøy (f.eks. CLI-omhylninger) lar en agent kalle en bestemt, avgrenset kapasitet i stedet for å få bred tilgang til et system og bli betrodd til å oppføre seg. En agent koblet til en MCP-tjener for kjørehistorikk kan be om skrivebeskyttet bevis, en variabels verdi, en kallstrekning, om en terskel ble overskredet, uten å berøre skriveadgang, uten å ha behov for stående legitimasjon til den underliggende miljøet.

Når du redesigner en første-generasjonsagent, hvordan bør bedrifter nærme seg verktøytilganger, minne, datahenting, evaluering, menneskelig tilsyn og fallback-prosedyrer som deler av en samlet arkitektur i stedet for separate funksjoner?

Du kan ikke bolt disse delene på uavhengig, fordi hver enkelt endrer de andre. De beste stedene å starte er rammen, harnesset som kontrollerer agentløkken, og den overordnede arbeidsflyt-koordineringen som binder sammen flere agenter og andre aktører. For en rotårsaksanalyse-arbeidsflyt, for eksempel, bør teamene bestemme hva slags bevis som er nødvendig, hvilke systemer agenten kan inspisere, om den kan publisere en konklusjon eller bare utkast en, når en menneskelig må godkjenne neste trinn, og hva som skjer hvis kjørehistorikk-bevis er utilgjengelig.

Når den kontrakten er klar, gir harnesset og rammen mekanismene for å påtvinge disse retningslinjene. MCP-gater kan utnyttes for å begrense agentens tilgang til bestemte kapasiteter relevante for dens formål. Verktøy kan tildeles med minst mulig tilgang. Minne kan overvåkes, med sensitiv data redigert deterministisk. Henting kan designes rundt beviset arbeidsflyten trenger.

Evaluering, tilsyn og fallback lukker så løkken. Systemet må måle om konklusjoner er korrekte og støttet, bringe inn en menneskelig faktor når risiko eller usikkerhet krysser en definert terskel, og stoppe eller falle tilbake til en skrivebeskyttet anbefaling når det ikke kan samle nok bevis. En felles audit-oppføring må knytte sammen utløseren, tillatelser, bevis, verktøykall, godkjenninger, handling og utfall. Det er det som gjør disse komponentene en produksjonsarkitektur i stedet for seks separate funksjoner.

Hva slags sikkerhetstiltak bør omringe agenter som kan inspisere live-applikasjoner eller delta i nettverksdrifts-arbeidsflyter, spesielt i regulerte miljøer hvor tilgangskontroller, personvern, overvåkbarhet og operasjonell stabilitet er kritiske?

Dette var ett av de sentrale designspørsmålene når vi bygde Lightrun AI SRE. En AI SRE opererer nær noen av de mest sensitive systemene i en organisasjon, så vi designet det som en privileert operasjonell aktør, ikke en chat-assistent. En viktig avgjørelse var å skille inspeksjonsplanet fra handlingplanet. AI SRE samler bevis gjennom skrivebeskyttede integrasjoner og Lightruns sandboxede kjørehistorikk-instrumentering, med tilgang begrenset av identitet, leier, tjeneste og miljø. Den kan inspisere live-kjøring og generere manglende bevis, men kjørehistorikk-laget kan ikke endre applikasjonsstaten.

I et regulert miljø, må denne grensen støttes av RBAC, SSO, leierisolering, PII-redigering, oppbevaringskontroller og en audit-sporing som viser hvilke verktøy og bevis støttet hver konklusjon. Vi trenger også operasjonelle begrensninger rundt hvor mye data som kan samles inn, hvor ofte kjørehistorikken kan spørres, og hvilke handlinger som krever godkjenning. Hvis bevis er manglende eller en konklusjon ikke kan verifiseres, bør AI SRE si det og overføre avgjørelsen til en menneskelig faktor i stedet for å handle som om den vet mer enn den gjør. Målet er kontrollert autonomi: nyttig nok til å akselerere en undersøkelse, men begrenset nok til å forbli trygg for det live-systemet.

Når bedrifter går utenfor eksperimentelle agenter, hva slags målinger bør bestemme om en agent er virkelig produksjonsklar, og hvordan forventer du at forholdet mellom AI-agenter og menneskelige ingeniører vil utvikle seg over de neste flere årene?

Jeg ville dømme produksjonsklarhet ut fra hvor ofte en AI-agents handlinger produserer ønskede resultater, dens konklusjoner holder seg mot hva som faktisk var sant i produksjon, ubakket konklusjoner fanges før handling, og om den feiler synlig og trygt når beviset ikke er til stede. For ingeniør-agenter er verifisert resultatnøyaktighet, bevisdekning, tid til å bekrefte rotårsak, vellykket fallback-rate og post-handling-resultater de kjernemålene vi bør fokusere på.

Over de neste flere årene, forventer jeg at agenter tar på seg mer av bevisinnsamlingen og første-passe-undersøkelsen, samt overvåking av agenter-arbeidsflyter og kontinuerlig læring fra erfaring og tilbakemelding, mens ingeniører setter politikk, løser tvetydighet, godkjenner høyrisikohandlinger og styrer selvforbedrende agenter. Tillit vil utvide arbeidsflyt for arbeidsflyt. Agenter som kan spore sine konklusjoner tilbake til live-bevis og tydelig avsløre hva de ikke kunne verifisere, vil tjene større autonomi. De som ikke kan, vil forbli begrenset til smale, lav-utsatt-oppdrag, uavhengig av hvor flytende de hører ut.

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