Moshe Sambol, VP of Customer Solutions at Lightrun – Rozhovorová série

Moshe Sambol, VP of Customer Solutions at Lightrun – přináší více než dvě desetiletí zkušeností z oblasti softwarového inženýrství, architektury, cloudové infrastruktury a technického vedení zákazníků. Předtím, než se v roce 2022 připojil k Lightrun, strávil téměř deset let v Google, kde zastával několik vedoucích pozic, včetně Cloud Customer Engineering Manager, který pomáhá organizacím přijmout a škálovat technologie Google Cloud. V počátcích své kariéry zastával Sambol inženýrské a vývojové vedoucí role v Oracle, Sun Microsystems, BMC Software a JPMorgan Chase. V Lightrun původně vedl globální Solution Engineering, než se stal VP of Customer Solutions, kde se zaměřuje na pomoc zákazníkům při přijetí technologie Runtime Insights a přeložení jejích schopností do měřitelných obchodních a vývojářských produktivních zisků.

Lightrun je platforma pro inženýrskou spolehlivost založenou na umělé inteligenci, která je navržena tak, aby poskytla vývojářům a agentům umělé inteligence přímou viditelnost do toho, jak se software chová během provozu. Jeho technologie může dynamicky zachytit protokoly, snímky, metriky, stopy, hodnoty proměnných a kontext provádění z živých aplikací bez nutnosti změn kódu nebo opětovného nasazení. Společnost stále více rozšiřuje tuto runtime inteligenci o AI-pomocný vývoj softwaru prostřednictvím Lightrun MCP, který využívá Model Context Protocol k poskytnutí kódovacím asistentům a agentic nástrojům živého kontextu aplikace místo spoléhání se pouze na statický zdrojový kód. To umožňuje AI systémům vyšetřovat produkční problémy, ověřovat hypotézy proti skutečnému chování při provádění a podporovat analýzu kořenové příčiny, zatímco začleňují podnikové kontroly, jako je role-based přístup a redakce citlivých dat.

Vaše kariéra zahrnuje ruční vývoj softwaru a architekturu, cloudové zákaznické inženýrství v Google, globální řešení inženýrství a nyní zákaznické řešení v Lightrun. Jak tato kombinace budování softwaru a přímé práce se zákazníky ovlivnila vaše pochopení toho, co odlišuje působivou demonstraci agenta umělé inteligence od systému, který lze důvěřovat v produkci?

Existuje velký rozdíl mezi tím, co ukáže agent umělé inteligence, a tím, co prokáže, že lze důvěřovat v podnikovém prostředí. To je proto, že agenti jsou pouze jednou částí systému připraveného pro produkci. Rámec kolem něj je stejně důležitý. Musí vynucovat přístup s nejmenším možným oprávněním, monitorovat aktivitu, uchovávat záznam auditu, zabránit nepřijatelně rizikovým akcím a zavolat člověka, když je to nutné.

Agentic systémy jsou inherentně odlišné od tradičního softwaru, protože vývojáři přesně nespecifikují, jak systém bude fungovat. Nastavíme cíl, poskytujeme nástroje a vedení, a model určuje, jak postupovat. Tato flexibilita je mocná, ale také činí chování systému obtížněji předpověditelným.

Pro podniky, zejména ty v regulovaných odvětvích, produkční pracovní postupy, které obvykle fungují nebo vyžadují nepředvídatelnou dobu dokončení, jsou nevhodné. Produkční prostředí obsahuje citlivá data, zdrojový kód a duševní vlastnictví, takže organizace potřebují zabránit tomu, aby agenti tyto informace odhalili, nebo se uchýlili k tvořivým, ale nepřijatelným cestám k dosažení svých cílů. To se stává stále důležitějším, protože každý týden přináší nový příklad systému umělé inteligence, který, ve svém úsilí dosáhnout cíle, skončí zranitelný nebo způsobí bezpečnostní zranitelnost.

Většina lídrů, se kterými mluvím, stále vyhodnocuje agenty způsobem, jakým by vyhodnotili nového zaměstnance: na základě schopností, úsudku a výstupu. Skutečná otázka není, zda je agent dostatečně chytrý. Je to, zda systém kolem něj může chytit a obsáhnout okamžiky, kdy tomu tak není.

Mnohé podniky původně věřily, že budování agenta umělé inteligence bylo z velké části otázkou napsání účinného podnětu. Co organizace nepochopily o inženýrských, architektonických a provozních požadavcích za produkčními agenty?

Domnívám se, že největší nedorozumění spočívalo v téměř naivní víře v moc umělé inteligence, aby řešila jakoukoli výzvu, pokud byla dána dobře napsaná otázka, relevantní kontext a vhodné nástroje. Týmy propojily svůj LLM s kódem, dokumentací, lístky a historickými telemetrickými údaji a poté očekávaly, že dojde k přesnému rozhodnutí.

Co však nevytvořili, byla verifikační model pro každý krok rozumu umělé inteligence. Jednou z velkých sil umělé inteligence je, že používá probabilistický rozum, najde a vezme jednu z mnoha možných cest k dosažení cíle. V komplexních, propojených produkčních prostředích tato síla představuje vážné riziko: jediné rozhodnutí může spustit následné regrese, tiché selhání nebo jiné neočekávané chování, které ohrožuje provozní odolnost běžícího systému.

To je místo, kde se stává deterministické řízení nezbytným. Rozum umělé inteligence může zůstat probabilistický, ale kontrolní body kolem jejích akcí nemohou. Pro agenta, který se účastní inženýrského pracovního postupu, je vyžadován verifikační krok, který ověřuje jeho hypotetickou další akci proti produkční realitě, deterministická brána místo další probabilistické domněnky. Musí vidět, jakou bude mít tato rozhodnutí důsledky, a schválit je pouze tehdy, pokud určí, že akce je bezpečná.

Při pohledu na první vlnu interně vyvinutých podnikových agentů, jaké jsou nejčastější architektonické chyby, které vidíte, a které problémy lze opravit postupně, spíše než vyžadovat kompletní přestavbu?

Hlavní obava, ke které se neustále vracím, je ověření. Agenti se mohou stát černou skříňkou: shromažďují informace z různých zdrojů a poté činí rozhodnutí, která vypadají rozumně z principu, ale nemusí být vhodná pro realitu složitých produkčních prostředí.

To naznačuje hlubší posun, a je to něco, o čem neustále mluvíme v Lightrun, zatímco pomáháme zákazníkům budovat agentic automatizace pro jejich inženýrské organizace. Týmy potřebují přestavět agentic tok sám a umístit brány na akcím agenta, aby zajistily, že jeho použití nástrojů je pod dohledem, audit a kontrola. Poskytnutí agentovi silné zpětné vazby – včetně živé runtime pozorovatelnosti – zaměřuje jeho kontext na to, co se skutečně děje právě teď. To je to, co umožňuje agentovi ověřit svá vlastní rozhodnutí o návrhu, analýzu kořenové příčiny a doporučení pro zmírnění chyb proti produkční realitě místo proti předpokladům založeným na statické analýze kódu nebo staré telemetrické údaje.

Dramatická přestavba není jedinou možností. Co lze udělat postupně, a to je nezbytné, je investovat do dovedností, které řídí chování agenta. Péčlivě vytvořené a vyhodnocené dovednosti tlačí agenta směrem k deterministickému pracovnímu postupu. Týmy nemusí přestavět celý systém, aby získaly tuto výhodu. Musí zacházet s návrhem dovedností se stejnou přísností, jakou by poskytli jakékoli jiné kusy produkční logiky.

Proč někteří agenti fungují dobře během kontrolovaných testů, ale začínají produkovat nekonzistentní, neúplné nebo zavádějící výsledky, když jsou vystaveni skutečným uživatelům, měnícím se datům, externím nástrojům a komplexním produkčním prostředím?

Kontrolované testy odstraňují většinu variability, která bude definovat produkční realitu, se kterou se umělé inteligence musí vypořádat. Data jsou kurátorská, chování nástrojů je předvídatelné, oprávnění jsou známa a pokrývají cestu, kterou jsme očekávali. Když uvolníte agenta, aby interagoval se skutečnými uživateli a jejich účinky v živých systémech, nemáte srovnatelné srovnání.

Uživatelé zavádějí nejasné požadavky a běží současně akcí, systémový stav je v neustálém toku, agent často musí pracovat s částečnými daty a externí nástroje přinášejí svou vlastní latenci a režimy selhání. Protože model je probabilistický, kažná nová proměnná vytváří další místo, kde může pracovní postup divergovat nebo zesílit předchozí chybu.

Nebezpečná část spočívá v tom, že agent může pokračovat v tom, aby se zdál fungovat správně, zatímco produkuje nesprávné, ale věrohodné odpovědi, postavené na částečných datech nebo na předpokladech zakořeněných ve starých informacích. To je důvod, proč produkční agenti potřebují nepřetržitou evaluaci, která pokračuje po spuštění, explicitní zpracování chybějících dat a nástrojových selhání a živou verifikaci rozhodnutí před dokončením vysoce dopadající akce.

Lightrun klade velký důraz na poskytování AI systémům přístupu k runtime kontextu. Jaké informace poskytuje runtime kontext, které mohou být chybějící v konvenčních logech, metrikách a stopách, a proč jsou tyto informace zvláště důležité pro diagnostiku selhání agentů?

Konvenční pozorovatelnost ukazuje vnější symptomy chování systému, často agregované, vzorkované nebo filtrované prostřednictvím řídicích panelů a upozornění, které se spustí na prahových hodnotách. Tyto jsou obvykle závislé na rozhodnutích, která vývojáři učinili v době, kdy byl kód napsán: co bude zajímavé v budoucnu? Co stojí za protokolování nebo měření? Runtime kontext odpojuje viditelnost od této potřeby vědět předem, co by mohlo být zajímavé, a poskytuje jemná data, která ukazují, co se děje pod kapotou, a jak jsme se tam dostali.

Skutečná mezera spočívá ve statických versus dynamických datech. Konvenční logy, metriky a stopy jsou statické a produkují historický účet toho, co se stalo. Runtime kontext Lightrun je dynamický. Poskytuje agentovi schopnost umístit novou instrumentaci do běžícího kódu, na vyžádání, a pozorovat přesně hodnoty proměnných, argumenty funkcí, stav objektu, zásobník volání nebo podmínky větvení, jak se vyskytují.

Tento rozdíl je zvláště důležitý pro diagnostiku selhání v kódu generovaném agentem, protože tato selhání jsou často tichá. Agent může zvolit špatný nástroj, předat špatný argument nebo jednat na základě zastaralého předpokladu a stále dokončit svou úlohu bez spuštění chyby. Selhání, jako je toto, se neobjeví ve statické telemetrické údaje, protože nikdo nevěděl předem, zda je třeba instrumentovat pro ně. Neočekávané chování vyžaduje dynamické vyšetřování přímo na běžícím systému, umístění nové instrumentace přesně tam, kde se model agenta odchýlil od reality, místo spoléhání se na to, co bylo již zaznamenáno.

To je to, co činí dynamický runtime kontext přirozenou verifikační vrstvou pro rozhodnutí umělé inteligence v inženýrství.

Jak může Model Context Protocol (MCP) a podobné integrační vrstvy umožnit kódovacím agentům učit se z reálného chování při provádění, aniž by jim poskytly nadměrný nebo nebezpečný přístup k produkčním systémům?

MCP a další řízený přístup k externím nástrojům (například CLI obálky) umožňují agentovi volat konkrétní, rozsahově omezenou schopnost místo toho, aby mu byl dán široký přístup k systému a důvěřoval, že se bude chovat. Agent připojený prostřednictvím MCP serveru pro runtime kontext může požadovat pouze čtení důkazů, hodnotu proměnné, cestu volání, zda byla překročena prahová hodnota, bez dotyku přístupu pro zápis, bez možnosti opětovného nasazení a bez potřeby stálých přihlašovacích údajů k základnímu prostředí.

Když přestavujete první generaci agenta, jak by měly podniky přistupovat k oprávněním nástrojů, paměti, načítání dat, hodnocení, lidskému dohledu a postupům pro návrat jako součásti jedné ucelené architektury, spíše než samostatných funkcí?

Nemůžete tyto kusy nezávisle připevnit, protože každý z nich mění ostatní. Nejlepší místa, kde začít, jsou rámec, který ovládá agentic smyčku, a celková orchestrace pracovního postupu, která spojuje více agentů a dalších aktérů. Pro pracovní postup analýzy kořenové příčiny, například, by týmy měly rozhodnout, jaké důkazy jsou vyžadovány, které systémy může agent prohlédnout, zda může zveřejnit závěr nebo pouze jej vypracovat, kdy musí člověk schválit další krok a co se stane, pokud důkazy z runtime nejsou k dispozici.

Jakmile je tato smlouva jasná, rámec a ovládací prvky poskytují mechanismy pro vynucení těchto pokynů. MCP brány lze využít k omezení přístupu agenta ke konkrétním schopnostem relevantním pro jeho účel. Nástroje mohou být uděleny s nejmenším možným oprávněním. Paměť může být dohlížena, s citlivými daty deterministicky vymazána. Načítání lze navrhnout kolem důkazů, které pracovní postup potřebuje.

Hodnocení, dohled a návrat pak uzavírají smyčku. Systém by měl měřit, zda jsou závěry správné a podporované, zavolat člověka, když riziko nebo nejistota překročí stanovenou prahovou hodnotu, a zastavit nebo vrátit se k pouze čtení doporučení, když nemůže shromáždit dostatečné důkazy. Společný záznam auditu by měl propojit spouštěcí mechanismus, oprávnění, důkazy, volání nástrojů, schválení, akci a výsledek. To je to, co dělá tyto komponenty jednu produkční architekturu, spíše než šest samostatných funkcí.

Jaké bezpečnostní opatření by měly obklopovat agenty, kteří mohou prohlížet živé aplikace nebo se účastnit pracovních postupů pro zajištění spolehlivosti webu, zejména v regulovaných prostředích, kde jsou kritické kontroly přístupu, ochrana soukromí, auditovatelnost a provozní stabilita?

To byla jedna z ústředních designových otázek, když jsme postavili Lightrun AI SRE. AI SRE funguje v blízkosti některých z nejcitlivějších systémů v organizaci, takže jsme ho navrhli jako privilegovaného provozního aktéra, ne jako chatovacího asistenta. Jedním z důležitých rozhodnutí bylo oddělit inspekční rovinu od akční roviny. AI SRE shromažďuje důkazy prostřednictvím pouze čtení integrací a sandboxované runtime instrumentace Lightrun, s přístupem omezeným identitou, nájemcem, službou a prostředím. Může prohlížet živou realizaci a generovat chybějící důkazy, ale runtime-inspekční vrstva nemůže měnit stav aplikace.

V regulovaném prostředí musí být tato hranice podporována RBAC, SSO, izolací nájemců, redakcí PII, kontrolami uchovávání a záznamem auditu, který ukazuje, které nástroje a důkazy podporovaly každý závěr. Potřebujeme také provozní limity kolem toho, kolik dat lze shromáždit, jak často lze runtime dotazovat a které akce vyžadují schválení. Pokud chybí důkazy nebo nelze závěr ověřit, AI SRE by měl říci to a předat rozhodnutí člověku, spíše než jednat, jako by věděl více, než ve skutečnosti ví. Cílem je řízená autonomie: dostatečně užitečná pro urychlení vyšetřování, ale dostatečně omezená, aby zůstala bezpečná pro živý systém.

Jak podniky postupují za experimentálními agenty, jaká měření by měla určit, zda je agent skutečně připraven pro produkci, a jak očekáváte, že se vztah mezi agenty umělé inteligence a lidskými inženýry bude vyvíjet v průběhu následujících několika let?

Soudil bych připravenost pro produkci podle toho, jak často akce agenta umělé inteligence produkují požadované výsledky, jeho závěry se drží proti tomu, co bylo skutečně pravdivé v produkci, nepodporované závěry jsou chyceny před akcí a zda selže viditelně a bezpečně, když důkazy nejsou k dispozici. Pro inženýrské agenty by se měly zaměřit na ověřenou přesnost výsledků, pokrytí důkazů, dobu potvrzení kořenové příčiny, úspěšnou míru návratu a výsledky po akci.

V průběhu následujících několika let očekávám, že agenti převezmou více sběru důkazů a prvního kola vyšetřování, jakož i dohledu nad agentic pracovními postupy a pokračujícího učení z经验 a zpětné vazby, zatímco inženýři nastaví politiku, vyřeší nejasnosti, schválí vysoce rizikové akce a povedou sebehodnotící agentic systémy. Důvěra se bude rozšiřovat pracovní postup po pracovním postupu. Agenti, kteří mohou vysledovat své závěry zpět k živým důkazům a jasně prokázat, co nemohli ověřit, získá větší autonomii. Ti, kteří nemohou, zůstanou omezeni na úzké, nízkonákladové úkoly, bez ohledu na to, jak plynulé zvuky.

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit Lightrun.