Moshe Sambol, Lightrunin asiakasratkaisujen varapuheenjohtaja – Haastattelusarja

Moshe Sambol, Lightrunin asiakasratkaisujen varapuheenjohtaja, tuo yli kaksi vuosikymmentä kokemusta ohjelmistokehityksestä, arkkitehtuurista, pilvi-infrastruktuurista ja asiakaslähtöisestä teknisestä johtajuudesta. Ennen liittymistään Lightruniin vuonna 2022 hän työskenteli lähes kymmenen vuotta Googlella, jossa hänellä oli useita johtotehtäviä, mukaan lukien Cloud Customer Engineering Manager, jossa hän auttoi organisaatioita omaksumaan ja skaalaamaan Google Cloud -teknologioita. Uran alkuvaiheessa Sambolilla oli tekninen johtajuusrooleja Oraclella, Sun Microsystemsilla, BMC Softwarella ja JPMorgan Chasella. Lightrunilla hän johti aluksi globaaleja ratkaisujen suunnittelua, kunnes siirtyi asiakasratkaisujen varapuheenjohtajaksi, jossa hän keskittyy auttamaan asiakkaita omaksumaan yhtiön Runtime Insights -teknologian ja kääntämään sen ominaisuuksia mitattaviin liiketoimintatuottoihin ja kehittäjien tuottavuuden parantamiseen.

Lightrun on AI-käyttöön tarkoitettu ohjelmistokehityksen luotettavuuspalvelu, joka antaa kehittäjille ja AI-järjestelmille suoran näkyvyyden siihen, miten ohjelmisto käyttäytyy suoritettaessa. Sen teknologia voi dynaamisesti tallentaa lokit, otokset, mittaukset, jäljitykset, muuttujien arvot ja suorituskontekstin suoritettavista sovelluksista ilman koodin muutoksia tai uudelleenasennuksia. Yritys laajentaa jatkuvasti tätä suoritusaikaisen älykkyyden teknologiaa AI-tukeen ohjelmistokehityksessä Lightrun MCP:n kautta, joka käyttää mallikontekstin protokollaa tarjoamaan koodin apuvälineille ja agenteille suoritettavan sovelluksen kontekstin sijaan, joka perustuu ainoastaan staattiseen lähdekoodiin. Tämä mahdollistaa AI-järjestelmien tutkimisen tuotantovirheitä, vahvistaa hypoteeseja todellisen suorituskäyttäytymisen vastaisuutta ja tukee juurisyyanalyysiä sisällyttäen yrityksen valvontaa, kuten roolipohjaisen pääsyluvan ja arkaluontoisen tietojen poistamisen.

Uranne on kattanut käsillään ohjelmistokehityksen ja arkkitehtuurin, pilvi-asiakasinsinööritöitä Googlessa, globaaleja ratkaisujen suunnittelua ja nyt asiakasratkaisuja Lightrunilla. Miten tämä yhdistelmä ohjelmistojen rakentamisesta ja suoraan yritysasiakkaiden kanssa työskentelystä on muovannut ymmärrystäsi siitä, mitä erottaa vaikuttavan AI-välikappaleen esityksen järjestelmästä, johon voidaan luottaa tuotannossa?

On suuri ero näyttää, mitä AI-välikappale voi tehdä, ja osoittaa, että se voidaan luottaa yritysympäristössä. Tämä johtuu siitä, että agentit ovat vain yksi osa tuotantovalmiista järjestelmästä. Ympäröivä kehys on yhtä tärkeä. Se on oltava sellainen, joka toteuttaa vähimmäispääsyoikeudet, valvoo toimintaa, säilyttää audit-reitin, estää hyväksymättömän riskialttiit toimet ja tuo ihmisen mukaan, kun tarve vaatii.

Agenteille on luonteenomaista, että ne eroavat perinteisestä ohjelmistosta, koska kehittäjät eivät määrittele tarkasti, miten järjestelmä toimii. Asetamme tavoitteen, tarjoamme työkaluja ja ohjeita, ja malli päättää, miten edetä. Tämä joustavuus on voimakasta, mutta se tekee myös järjestelmän käyttäytymisen ennakoida vaikeammaksi.

Yrityksille, erityisesti sääntelykohteisia aloja, tuotantoprosessit, jotka yleensä toimivat tai vaativat epätarkasti määritellyn ajan valmistumiseen, eivät ole aloitettavissa. Tuotantoympäristössä on arkaluontoista tietoa, lähdekoodia ja immateriaalioikeuksia, joten organisaatioiden on oltava kykeneviä estämään agenteja paljastamasta tietoa tai ottamasta luovia, hyväksymättömiä reittejä tavoitteidensa saavuttamiseksi. Tämä on tulevaisuudessa yhä tärkeämpää, koska jokainen viikko tuo uuden esimerkin AI-järjestelmästä, joka pyrkii tavoitteeseensa ja joutuu haavoittuvaksi tai aiheuttaa turvallisuusongelman.

Useimmat johtajat, joille puhun, arvioivat edelleen agenteja samalla tavalla kuin uuden työntekijän: kyvykkyyden, harkinnan ja tuotannon perusteella. Todellinen kysymys ei ole, onko agentti tarpeeksi älykäs. Se on, voivatko järjestelmät ympärillä pyydystää ja rajoittaa ne hetket, jolloin se ei ole.

Monet yritykset uskoivat aluksi, että AI-agentin rakentaminen oli pääasiassa tehokkaan ohjelmointivinkin kirjoittamista. Mitä yritykset ymmärtivät väärin ohjelmistosuunnittelun, arkkitehtuuriin ja toiminnallisiin vaatimuksiin liittyen tuotantovalmiiden agenttien osalta?

Luulen, että suurin väärinkäsitys oli lähes viattoman usko AI:n voimaan ratkaista haasteita, kun sille annettiin tehokas ohjelmointivinkki, asiaankuuluva konteksti ja sopivat työkalut. Tiimit yhdistivät LLM:nsä koodiin, asiakirjoihin, lippuihin ja historialliseen telemetriatietoon ja odottivat, että se päättelisi oikein oikeaan päätökseen.

Mitä he eivät rakentaneet, oli vahvistusmalli kunkin AI:n päättelyvaiheen jokaiselle osalle. Yksi AI:n suurista vahvuuksista on, että se käyttää todennäköisyyssääntöjä, löytää ja ottaa yhden useista mahdollisista reiteistä, jotta se saavuttaa kohteen. Monimutkaisissa, toisiinsa liittyvissä tuotantoympäristöissä tämä vahvuus tuo mukanaan vakavan riskin: yksittäinen päätös voi laukaista aliraportteja, hiljaisia virheitä tai muita odottamattomia käyttäytymisiä, jotka uhkaavat suoritettavan järjestelmän toiminnallista luotettavuutta.

Tässä määrin deterministinen ohjaus on olennainen. Agentin päättely voi pysyä todennäköisyyssäännöissä, mutta toimien ympärillä olevat portaat eivät voi. Tuotantoprosessin osallistuvalle agentille tämä edellyttää vahvistusaskelta, joka tarkistaa hypoteettisen seuraavan toiminnan tuotannon todellisuutta vastaan, determinististä portasta, ei toista todennäköisyyssääntöä. Se tarvitsee nähdä, mikä on päätöksen seuraus, ja hyväksyä sen vain, kun on määritellyt, että toimi on turvallinen.

Katsellessasi ensimmäistä aaltoa sisäisesti kehitettyjä yritysagenteja, mitkä ovat yleisimmät arkkitehtuurivirheet, joita näet, ja mitkä ongelmat voidaan korjata asteittain ilman täydellistä uudelleenrakentamista?

Pääasiallinen huolenaihe, johon jatkuvasti palaa, on vahvistus. Agentit voivat muuttua mustaksi laatikoksi: ne keräävät tietoa useista lähteistä ja tekevät päätöksiä, jotka vaikuttavat järkeviltä periaatteessa, mutta eivät välttämättä ole sovellettavissa monimutkaisen tuotantoympäristön todellisuuksiin.

Tämä osoittaa perustavanlaatuista muutosta, ja se on jotain, mistä puhumme jatkuvasti Lightrunilla, kun autamme asiakkaitamme rakentamaan agenteille automaatioita heidän insinöörijärjestelmiinsä. Tiimien on rakennettava itse agenteille virtaus ja asetettava portaat agentin toimille, jotta varmistetaan, että sen työkalujen käyttö on alainen valvontaa, tarkastelua ja katselua. Agentin itsensä vahvistus silmukkaan sisällyttäminen – mukaan lukien suoritettavissa oleva havainnollistus – kohdistaa sen kontekstin siihen, mitä tapahtuu juuri nyt. Tämä pääsy mahdollistaa agentin vahvistaa itse oman suunnittelupäätöksiensä, juurisyyanalyysin ja virheenkorjausmenetelmien suositukset tuotannon todellisuutta vastaan eikä vain oletuksia, jotka perustuvat staattiseen koodin analyysiin tai vanhaan telemetriatietoon.

Dramaattinen uudelleenrakentaminen ei ole ainoa vaihtoehto. Mitä voidaan tehdä asteittain, ja se ei ole mullistava, mutta se on olennainen, on panostaa taitoihin, jotka ohjaavat agentin käyttäytymistä. Huolellisesti suunnitellut ja arvioidut taidot työntävät agenttia deterministisen työnkulun suuntaan. Tiimien ei tarvitse uudelleenrakentaa koko järjestelmää, jotta he saavat tämän hyödyn. Heidän on kohdeltava taitojen suunnittelua samalla tarkkuudella kuin mitä he antaisivat mille tahansa muulle tuotantologiikalle.

Miksi jotkut agentit suorittavat hyvin hallitussa testauksessa, mutta alkavat tuottaa epäjohdonmukaisia, epätäydellisiä tai harhaanjohtavia tuloksia, kun ne altistetaan todellisille käyttäjille, muuttuville tietoihin, ulkoisiin työkaluihin ja monimutkaisiin tuotantoympäristöihin?

Hallitut testit poistavat useimmat muuttujat, jotka määrittävät tuotannon todellisuuden, jonka AI on selviytymään. Data on kuratoitu, työkalujen käyttäytyminen on ennalta arvioitavissa, käyttöoikeudet ovat tiedossa, ja me peitämme polun, jonka olemme ennustaneet. Kun julkaiset agentin vuorovaikuttaakseen todellisten käyttäjien ja heidän vaikutustensa kanssa suoritettavissa järjestelmissä, et vertaa samanlaista asiaa.

Käyttäjät esittävät epäselviä pyynnöitä ja suorittavat rinnakkaisia toimia, järjestelmän tila on jatkuvasti muuttumassa, agentin on usein toimittava osittaisilla tiedoilla, ja ulkoiset työkalut tuovat omat viiveensä ja virhetilansa sen lisäksi. Koska malli on todennäköisyyssääntöinen, jokainen uusi muuttuja luo uuden paikan, jossa työnkulu voi poiketa tai yhdistää aiemman virheen.

Vaarallinen osa on, että agentti voi jatkaa näyttämistä siltä, että se toimii oikein, tuottaen virheellisiä, mutta uskottavia vastauksia, jotka perustuvat osittaiseen tietoon tai oletuksiin, jotka perustuvat vanhentuneeseen tietoon. Siksi tuotantoagenteja tarvitaan jatkuva arviointi, joka jatkuu julkaisun jälkeen, selkeä käsittely puuttuvasta tiedosta ja työkaluvirheistä sekä suoritettavien päätösten ennakkoarviointi.

Lightrun korostaa merkittävästi AI-järjestelmien pääsyä suoritusaikaiseen kontekstiin. Mitä tietoa suoritusaikainen konteksti tarjoaa, mitä perinteiset lokit, mittaukset ja jäljitykset saattavat puuttua, ja miksi tämä tieto on erityisen tärkeää agenttien virheiden diagnosoinnissa?

Perinteinen havainnollistus näyttää järjestelmän käyttäytymisen ulkoiset oireet, usein aggregoitu, näytteitä tai suodatettu dashboardeissa ja hälytyksissä, jotka laukaistaan kynnyksillä. Ne riippuvat usein kehittäjien tekemistä päätöksistä koodin kirjoittamisen aikana: mitä tietoa on tulevaisuuden kannalta kiinnostavaa? Mitä on arvoa lokittaa tai mitata? Suoritusaikainen konteksti irrottaa näkyvyyden tästä tarpeesta etukäteen tietää, mitä saattaa olla kiinnostavaa, ja tarjoaa hienojakoinen tieto siitä, mitä tapahtuu moottorin alla, ja miten sinne päädytään.

Todellinen aukko on staattinen vs. dynaaminen tieto. Perinteiset lokit, mittaukset ja jäljitykset ovat staattisia ja tuottavat historiallisen selonteon siitä, mitä tapahtui. Lightrunin suoritusaikainen konteksti on dynaaminen. Se antaa agentille kyvyn asettaa uuden instrumentaation suoritettavaan koodiin tarpeen mukaan ja havainnollistaa tarkat muuttujien arvot, funktioargumentit, olion tila, puhelupino tai haara-ehtoja, kun ne tapahtuvat.

Tämä ero on erityisen tärkeä agenttien virheiden diagnosoinnissa, koska ne usein ovat hiljaisia. Agentti voi valita väärän työkalun, antaa väärän argumentin tai toimia vanhentuneen oletuksen perusteella ja silti suorittaa tehtävän ilman virheen laukaisemista. Tällainen virhe ei näy staattisessa telemetriassa, koska kukaan ei tiennyt etukäteen instrumentoida sitä. Odottamaton käyttäytyminen vaatii dynaamisen tutkimuksen suoritettavassa järjestelmässä, asettamalla uuden instrumentaation tarkalleen sinne, missä agentin malli maailmasta poikkesi todellisuudesta, sen sijaan, että olisi riippuvainen siitä, mitä oli jo tallennettu.

Tämä on se, mikä tekee dynaamisen suoritusaikaisen kontekstin luonnolliseksi vahvistuskerroksiksi AI-tuottamien päätösten osalta insinöörintiissä.

Miten mallikontekstin protokolla (MCP) ja muut integraatiokerrokset voivat sallia koodin apuvälineiden oppimisen todellisen suorituskäyttäytymisen perusteella antamatta niille liiallista tai vaarallista pääsyä tuotantojärjestelmiin?

MCP ja muut valvottu pääsy ulkoisiin työkaluihin (esim. CLI-kääreet) antavat agentille mahdollisuuden kutsua tiettyä, laajennettua kykyä sen sijaan, että sille annettaisiin laaja pääsy järjestelmään ja luotettaisiin siihen, että se käyttäytyy hyvin. Agentti, joka on yhdistetty MCP-palvelimeen suoritusaikaisen kontekstin vuoksi, voi pyytää vain luku-oikeuksia, muuttujan arvoa, kutsupolku, onko kynnysehto ylittynyt, ilman kirjoitusoikeuksia, ilman uudelleenasennustarpeita ja ilman pysyviä tunnistetietoja perustana.

Kun uudelleenmuotoilet ensimmäisen sukupolven agenttia, miten yritysten on lähestyttävä työkalupääsyä, muistia, tietojen hakua, arviointia, ihmisen valvontaa ja takaisinkutsuprosesseja yhtenäisen arkkitehtuurin osana sen sijaan, että ne olisivat erillisiä ominaisuuksia?

Et voi kiinnittää näitä osia itsenäisesti, koska kunkin osan muuttaminen vaikuttaa muihin. Parhaat paikat aloittaa ovat kehys, joka ohjaa agenttisilmukkaa, ja työnkulun ohjaus, joka yhdistää useita agenteja ja muita toimijoita. Esimerkiksi juurisyyanalyysityönkulussa tiimien on päättävä, mitä todisteita vaaditaan, mitkä järjestelmät agentti saa tarkastella, voiko se julkaista johtopäätöksen vai ainoastaan luonnostella sitä, milloin ihminen on hyväksyttävä seuraava askel ja mitä tapahtuu, jos suoritusaikaiset todisteet eivät ole saatavilla.

Kun tämä sopimus on selvä, kehys ja ohjaus tarjoavat mekanismit, joilla nämä ohjeet voidaan toteuttaa. MCP-portit voidaan hyödyntää rajoittamaan agentin pääsyä tiettyihin kykyihin, jotka ovat relevantteja sen tarkoitukselle. Työkalut voidaan myöntää vähimmäispääsyoikeuksilla. Muisti voidaan valvoa, ja arkaluontoiset tiedot voidaan poistaa deterministisesti. Haun suunnittelu voidaan suunnitella työnkulun tarvitseman todistusaineiston ympärille.

Arviointi, valvonta ja takaisinkutsu sitten sulkevat silmukan. Järjestelmän on mitattava, ovatko johtopäätökset oikein ja tuettu, tuoda ihminen mukaan, kun riski tai epävarmuus ylittää määritetyn kynnyksen, ja pysäyttää tai palata lukuunni luvattuun suositukseen, jos riittävästi todisteita ei ole saatavilla. Jaettu audit-tallenne tulisi yhdistää laukaiseva, käyttöoikeudet, todisteet, työkalukutsut, hyväksynnät, toimenpiteet ja tulokset. Se on se, mikä tekee näistä osista yhden tuotantoprosessin arkkitehtuurin eikä kuusi erillistä ominaisuutta.

Mitkä turvallisuusvarmistukset tulisi ympäröidä agenteilla, jotka voivat tarkastella suoritettavia sovelluksia tai osallistua sivuston luotettavuuden insinöörintiin, erityisesti sääntelykohteisissa ympäristöissä, joissa pääsyvalvonta, yksityisyys, auditointi ja toiminnallinen vakaus ovat kriittisiä?

Tämä oli yksi keskeisimmistä suunnittelukysymyksistä, kun rakensimme Lightrun AI SRE:n. AI SRE toimii lähellä useita organisaation herkillisiä järjestelmiä, joten suunnittelimmekin sen etuoikeutetuksi toiminnalliseksi toimijaksi, ei vain chat-avustajaksi. Yksi tärkeä päätös oli erottaa tarkasteluplane tarkasteluplaneesta. AI SRE kerää todisteita lukuoikeuksilla Lightrunin hiekkalaatikkoinstrumentaation kautta, pääsy rajoitettu identiteetin, vuokraajan, palvelun ja ympäristön mukaan. Se voi tarkastella suoritettavaa sovellusta ja luoda puuttuvia todisteita, mutta suoritusaikaisen tarkastelun kerros ei voi muuttaa sovelluksen tilaa.

Sääntelyympäristössä tämä raja on oltava tuettu roolipohjaisella pääsyoikeudella, SSO:lla, vuokraajan eristämisellä, henkilökohtaisten tietojen poistamisella, säilytysrajoituksilla ja audit-reitillä, joka osoittaa, mitkä työkalut ja todisteet tukivat kunkin johtopäätöksen. Meidän on myös oltava toiminnalliset rajoitukset siitä, kuinka paljon dataa voidaan kerätä, kuinka usein suoritusaika voidaan kysyä ja mitkä toimenpiteet vaativat hyväksyntää. Jos todisteita puuttuu tai johtopäätös ei voida vahvistaa, AI SRE tulisi sanoa niin ja antaa päätös ihmiselle sen sijaan, että se toimisi niin, kuin se tietäisi enemmän kuin se todella tietää. Tavoitteena on ohjattu autonomia: riittävän hyvä kiihdyttämään tutkimusta, mutta riittävän rajoitettu, jotta se säilyy turvalliseksi suoritettavalle järjestelmälle.

Kun yritykset siirtyvät kokeellisista agenteista, mitkä mittaukset tulisi määrittää, onko agentti todella tuotantovalmis, ja miten odotat AI-agenttien ja ihmisten insinöörien välisen suhteen kehittyvän seuraavien vuosien aikana?

Arvioisin tuotantovalmiuden sen mukaan, kuinka usein AI-agentin toimet tuottavat toivottuja tuloksia, sen johtopäätökset kestävät verrattuna siihen, mitä tuotannossa todella tapahtui, miten usein sen johtopäätökset kiinni otetaan ennen toimintaa, ja miten usein se epäonnistuu näkyvästi ja turvallisesti, kun todisteita ei ole. Insinööriagenteille vahvistettu lopputulos, todisteen kattavuus, juurisyyanalyysin vahvistusaika, onnistuneen takaisinkutsun osuus ja toimenpiteen jälkeen tulokset ovat keskeisiä mittareita, joihin meidän tulisi keskittyä.

Seuraavien vuosien aikana odotan, että agentit ottavat haltuunsa enemmän todisteenkeruuta ja ensimmäisen tutkimuksen, sekä valvontaa agenteille ja jatkuvaa oppimista kokemuksesta ja palautteesta, kun taas insinöörit määrittävät politiikkaa, ratkaisevat epäselvyyksiä, hyväksyvät korkean riskin toimia ja ohjaavat itseparantavia agenteja. Luottamus laajenee työnkulku työnkulkuun. Agentit, jotka voivat jäljittää johtopäätöksensä takaisin suoritettavaan todisteeseen ja selvästi ilmoittaa, mitä ne eivät voineet vahvistaa, ansaitsevat suuremman autonomian. Ne, jotka eivät voi, pysyvät rajoitettuina kapeisiin, matalan riskin tehtäviin, riippumatta siitä, kuinka sulavasti ne kuulostavat.

Kiitos hienosta haastattelusta, lukijat, jotka haluavat oppia lisää, kannattaa vierailla Lightrun:ssa.