Moshe Sambol, VP de Solutions Client chez Lightrun – Série d’entretiens

Moshe Sambol, VP de Solutions Client chez Lightrun – apporte plus de deux décennies d’expérience couvrant l’ingénierie logicielle, l’architecture, l’infrastructure cloud et le leadership technique client. Avant de rejoindre Lightrun en 2022, il a passé près d’une décennie chez Google, où il a occupé plusieurs postes de leadership, notamment celui de responsable de l’ingénierie client Cloud, aidant les organisations à adopter et à mettre à l’échelle les technologies Google Cloud. Plus tôt dans sa carrière, Sambol a occupé des rôles de direction en ingénierie et en développement chez Oracle, Sun Microsystems, BMC Software et JPMorgan Chase. Chez Lightrun, il a initialement dirigé l’ingénierie de solutions mondiales avant de devenir VP de Solutions Client, où il se concentre sur l’aide aux clients pour adopter la technologie d’Insights Runtime de l’entreprise et traduire ses capacités en gains de productivité commerciale et de développement mesurables.

Lightrun est une plateforme d’ingénierie de fiabilité native AI conçue pour donner aux développeurs et aux agents AI une visibilité directe sur la façon dont les logiciels se comportent lors de leur exécution. Sa technologie peut capturer dynamiquement des journaux, des instantanés, des métriques, des traces, des valeurs de variables et des contextes d’exécution à partir d’applications en direct sans nécessiter de modifications de code ou de redéploiements. L’entreprise étend de plus en plus cette intelligence de runtime à l’aide du développement de logiciels assisté par IA via Lightrun MCP, qui utilise le Protocole de Contexte de Modèle pour fournir des assistants de codage et des outils agents avec un contexte d’application en direct plutôt que de s’appuyer uniquement sur le code source statique. Cela permet aux systèmes AI d’enquêter sur les problèmes de production, de valider des hypothèses par rapport au comportement d’exécution réel et de soutenir l’analyse de cause profonde tout en incorporant des contrôles d’entreprise tels que l’accès basé sur les rôles et la rédaction des données sensibles.

Votre carrière a couvert le développement logiciel et l’architecture, l’ingénierie client Cloud chez Google, l’ingénierie de solutions mondiales et maintenant les solutions client chez Lightrun. Comment cette combinaison de construction de logiciels et de travail direct avec des clients d’entreprise a-t-elle façonné votre compréhension de ce qui sépare une démonstration impressionnante d’un agent AI d’un système qui peut être fiable en production ?

Il y a une grande différence entre montrer ce qu’un agent AI peut faire et prouver qu’il peut être fiable dans un environnement d’entreprise. C’est parce que les agents ne sont qu’une partie d’un système prêt pour la production. Le cadre qui l’entoure est tout aussi important. Il doit faire respecter l’accès avec les privilèges minimum, surveiller l’activité, préserver une traçabilité, empêcher des actions à risque inacceptable et faire intervenir un humain lorsque nécessaire.

Les systèmes agents sont fondamentalement différents des logiciels traditionnels, car les développeurs ne prescrivent pas exactement la façon dont le système fonctionnera. Nous fixons un objectif, fournissons des outils et des conseils, et le modèle détermine comment procéder. Cette flexibilité est puissante, mais elle rend également le comportement du système plus difficile à prédire.

Pour les entreprises, en particulier celles des secteurs réglementés, les flux de production qui fonctionnent généralement ou prennent un temps imprévisible pour se terminer sont des non-départs. Les environnements de production contiennent des données sensibles, du code source et des propriétés intellectuelles, les organisations doivent donc être en mesure d’empêcher les agents d’exposer ces informations ou de prendre des routes créatives mais inacceptables pour atteindre leurs objectifs. Cela devient de plus en plus important, car chaque semaine apporte un nouvel exemple d’un système AI qui, dans son effort pour atteindre un objectif, se retrouve vulnérable ou provoque une faille de sécurité.

La plupart des dirigeants avec qui je parle évaluent encore les agents de la même manière qu’un nouvel employé : sur leurs capacités, leur jugement et leur production. La vraie question n’est pas de savoir si l’agent est suffisamment intelligent. C’est de savoir si le système qui l’entoure peut détecter et contenir les moments où il ne l’est pas.

Beaucoup d’entreprises ont initialement cru que construire un agent AI était largement une question d’écriture d’une invite efficace. Qu’est-ce que les organisations ont mal compris des exigences d’ingénierie, d’architecture et d’exploitation derrière les agents prêts pour la production ?

Je pense que la plus grande mécompréhension était une croyance presque naïve dans le pouvoir de l’IA pour résoudre tout défi, une fois donné une invite bien écrite, un contexte pertinent et des outils appropriés. Les équipes ont connecté leur LLM au code, à la documentation, aux tickets et à la télémétrie historique, puis ont attendu qu’il raisonne de manière précise pour arriver à la bonne décision.

Ce qu’ils n’ont pas construit, c’est un modèle de vérification pour chaque étape du raisonnement de l’IA. L’une des grandes forces de l’IA est qu’elle utilise un raisonnement probabiliste, trouvant et prenant l’une des nombreuses routes possibles pour atteindre une destination. Dans des environnements de production complexes et interconnectés, cette force introduit un risque sérieux : une décision unique peut déclencher des régressions en aval, des défaillances silencieuses ou d’autres comportements inattendus qui menacent la résilience opérationnelle d’un système en cours d’exécution.

C’est là que la direction déterministe devient essentielle. Le raisonnement de l’agent peut rester probabiliste, mais les points de contrôle autour de ses actions ne peuvent pas l’être. Pour un agent participant à un flux de travail d’ingénierie, cela nécessite une étape de vérification qui contrôle son hypothèse de prochaine action contre la réalité de production, une porte déterministe plutôt qu’une autre supposition probabiliste. Il doit voir quelle sera la conséquence de cette décision et ne l’approuver qu’une fois qu’il a déterminé que l’action est sûre.

En regardant la première vague d’agents internes développés par les entreprises, quels sont les erreurs architecturales les plus courantes que vous voyez, et quels problèmes peuvent être corrigés de manière incrémentale plutôt que de nécessiter une reconstruction complète ?

La préoccupation principale à laquelle je reviens constamment est la validation. Les agents peuvent devenir une boîte noire : ils collectent des informations à partir de diverses sources et prennent ensuite des décisions qui semblent raisonnables en principe mais peuvent ne pas être appropriées pour les réalités d’un environnement de production complexe.

Cela pointe vers un changement plus fondamental, et c’est quelque chose dont nous discutons constamment chez Lightrun alors que nous aidons les clients à construire des automatisations agences pour leurs organisations d’ingénierie. Les équipes doivent reconstruire le flux agence lui-même et mettre des portes sur les actions de l’agent, pour garantir que son utilisation des outils est soumise à une supervision, à une vérification et à une révision. Fournir à l’agent lui-même une boucle de rétroaction solide – y compris l’observabilité du runtime en direct – concentre son contexte sur ce qui se passe vraiment maintenant. C’est cet accès qui permet à l’agent de valider ses propres décisions de conception, son analyse de cause profonde et ses recommandations d’atténuation des erreurs contre la réalité de production plutôt que contre des hypothèses basées sur une analyse statique du code ou de la télémétrie ancienne.

Une reconstruction dramatique n’est pas la seule option. Ce qui peut être fait de manière incrémentale, et ce n’est pas révolutionnaire mais c’est essentiel, c’est d’investir dans les compétences qui guident le comportement de l’agent. Des compétences soigneusement conçues et évaluées poussent l’agent dans la direction d’un flux de travail déterministe. Les équipes n’ont pas besoin de réarchitecturer tout le système pour obtenir cet avantage. Ils doivent traiter la conception de compétences avec la même rigueur qu’ils donneraient à toute autre logique de production.

Pourquoi certains agents fonctionnent-ils bien lors des tests contrôlés mais commencent-ils à produire des résultats incohérents, incomplets ou trompeurs lorsqu’ils sont exposés à de vrais utilisateurs, à des données changeantes, à des outils externes et à des environnements de production complexes ?

Les tests contrôlés éliminent la plupart de la variabilité qui définira la réalité de production que l’IA doit affronter. Les données sont ciblées, le comportement des outils est prévisible, les autorisations sont connues et nous couvrons un chemin que nous avions anticipé. Lorsque vous libérez un agent pour interagir avec de vrais utilisateurs et leurs effets dans des systèmes en direct, vous n’êtes pas en train de comparer des choses similaires.

Les utilisateurs introduisent des demandes ambiguës et exécutent des actions concurrentes, l’état du système est en constante fluctuation, l’agent doit souvent travailler à partir de données partielles et les outils externes apportent leur propre latence et leurs propres modes de défaillance en plus de cela. Puisque le modèle est probabiliste, chaque nouvelle variable crée un autre endroit où le flux de travail peut diverger ou compounding une erreur antérieure.

La partie dangereuse est que l’agent peut continuer à sembler fonctionner correctement tout en produisant des réponses incorrectes mais plausibles, construites à partir de données partielles ou d’hypothèses enracinées dans des informations obsolètes. C’est pourquoi les agents de production nécessitent une évaluation continue qui continue à s’exécuter après le lancement, une gestion explicite des données manquantes et des défaillances d’outils, ainsi qu’une vérification en direct d’une décision avant de compléter une action à fort impact.

Lightrun met l’accent sur le fait de donner aux systèmes AI un accès au contexte d’exécution. Quelles informations le contexte d’exécution fournit-il qui pourraient être manquantes dans les journaux, les métriques et les traces conventionnels, et pourquoi ces informations sont-elles particulièrement importantes pour diagnostiquer les défaillances des agents ?

L’observabilité conventionnelle montre les symptômes externes du comportement du système, souvent agrégés, échantillonnés ou filtrés à travers des tableaux de bord et des alertes qui déclenchent sur des seuils. Ils dépendent généralement de décisions prises par les développeurs au moment où le code a été écrit : quelles informations seront d’intérêt à l’avenir ? Qu’est-ce qui vaut la peine d’être consigné ou mesuré ? Le contexte d’exécution déconnecte la visibilité de ce besoin de savoir à l’avance ce qui pourrait être d’intérêt, et fournit des données granulaires montrant ce qui se passe sous le capot et comment nous sommes arrivés là.

Le véritable écart est entre les données statiques et dynamiques. Les journaux, les métriques et les traces conventionnels sont statiques et produisent un compte rendu historique de ce qui s’est passé. Le contexte d’exécution de Lightrun est dynamique. Il donne à un agent la capacité de placer de nouveaux instruments dans du code en cours d’exécution, à la demande, et d’observer les valeurs exactes des variables, les arguments de fonction, l’état d’objet, la pile d’appel ou les conditions de branchement au moment où ils se produisent.

Cette distinction est particulièrement importante pour diagnostiquer les défaillances dans le code généré par l’agent, car celles-ci sont fréquemment silencieuses. Un agent peut choisir l’outil incorrect, passer l’argument incorrect ou agir sur une hypothèse obsolète, et toujours terminer sa tâche sans déclencher d’erreur. Une défaillance comme celle-ci ne sera pas visible dans la télémétrie statique, car personne ne savait à l’avance d’instrumenter pour cela. Un comportement inattendu nécessite une enquête dynamique directement sur le système en cours d’exécution, en plaçant de nouveaux instruments exactement à l’endroit où le modèle du monde de l’agent a divergé de la réalité, plutôt que de s’appuyer sur ce qui était déjà enregistré.

C’est ce qui fait du contexte d’exécution dynamique la couche de vérification naturelle pour les décisions générées par l’IA dans l’ingénierie.

Comment le Protocole de Contexte de Modèle (MCP) et des couches d’intégration similaires peuvent-ils permettre aux agents de codage d’apprendre du comportement d’exécution réel sans leur donner un accès excessif ou non sécurisé aux systèmes de production ?

Le MCP et d’autres accès contrôlés aux outils externes (par exemple, des enveloppes CLI) permettent à un agent d’appeler une capacité spécifique et étroite plutôt que de lui accorder un accès large au système et de lui faire confiance pour se comporter. Un agent connecté via un serveur MCP pour le contexte d’exécution peut demander des preuves en lecture seule, une valeur de variable, un chemin d’appel, si un seuil a été dépassé, sans toucher l’accès en écriture, sans la capacité de redéployer quoi que ce soit et sans avoir besoin de droits d’accès sous-jacents à l’environnement.

Lors de la révision d’un agent de première génération, comment les entreprises doivent-elles aborder les autorisations d’outils, la mémoire, la récupération de données, l’évaluation, la surveillance humaine et les procédures de secours comme des parties d’une architecture cohérente plutôt que comme des fonctionnalités distinctes ?

Vous ne pouvez pas ajouter ces pièces de manière indépendante car chacune d’elles modifie les autres. Les meilleurs endroits pour commencer sont le cadre, le harnais qui contrôle la boucle de l’agent et l’orchestration du flux de travail global qui relie plusieurs agents et autres acteurs. Pour un flux de travail d’analyse de cause profonde, par exemple, les équipes devraient décider quels preuves sont nécessaires, quels systèmes l’agent peut inspecter, s’il peut publier une conclusion ou seulement la rédiger, quand un humain doit approuver l’étape suivante et ce qui se passe si les preuves en temps réel sont indisponibles.

Une fois que ce contrat est clair, le harnais et le cadre fournissent les mécanismes pour faire respecter ces lignes directrices. Les passerelles MCP peuvent être utilisées pour limiter l’accès de l’agent à des capacités spécifiques pertinentes à son objectif. Les outils peuvent être accordés avec les privilèges minimum. La mémoire peut être supervisée, avec des données sensibles rédigées de manière déterministe. La récupération peut être conçue autour des preuves dont le flux de travail a besoin.

L’évaluation, la surveillance et les procédures de secours ferment ensuite la boucle. Le système devrait mesurer si les conclusions sont correctes et étayées, faire intervenir un humain lorsque le risque ou l’incertitude dépasse un seuil défini et s’arrêter ou revenir à une recommandation en lecture seule lorsque les preuves suffisantes ne peuvent pas être rassemblées. Un enregistrement d’audit partagé devrait relier le déclencheur, les autorisations, les preuves, les appels d’outils, les approbations, l’action et le résultat. C’est ce qui fait de ces composants une architecture de production plutôt que six fonctionnalités distinctes.

Quelles sont les sauvegardes qui devraient entourer les agents qui peuvent inspecter des applications en direct ou participer aux flux de travail d’ingénierie de fiabilité de site, en particulier dans des environnements réglementés où les contrôles d’accès, la confidentialité, la traçabilité et la stabilité opérationnelle sont critiques ?

C’était l’une des questions de conception centrales lors de la construction de Lightrun AI SRE. Un AI SRE opère à proximité de certains des systèmes les plus sensibles d’une organisation, nous l’avons donc conçu comme un acteur opérationnel privilégié, et non comme un assistant de conversation. Une décision importante a été de séparer le plan d’inspection du plan d’action. L’AI SRE collecte des preuves via des intégrations en lecture seule et l’instrumentation de runtime sandboxée de Lightrun, avec un accès restreint par identité, locataire, service et environnement. Il peut inspecter l’exécution en direct et générer des preuves manquantes, mais la couche d’inspection du runtime ne peut pas modifier l’état de l’application.

Dans un environnement réglementé, cette limite doit être soutenue par le contrôle d’accès basé sur les rôles, l’authentification unique, l’isolement des locataires, la rédaction des informations personnelles, les contrôles de rétention et une traçabilité montrant quels outils et preuves ont soutenu chaque conclusion. Nous avons également besoin de limites opérationnelles autour de la quantité de données qui peuvent être collectées, de la fréquence à laquelle le runtime peut être interrogé et des actions qui nécessitent une approbation. Si les preuves sont manquantes ou qu’une conclusion ne peut pas être vérifiée, l’AI SRE devrait le dire et remettre la décision à un humain plutôt que d’agir comme s’il en savait plus qu’il ne le fait. L’objectif est une autonomie contrôlée : suffisamment utile pour accélérer une enquête, mais suffisamment contrainte pour rester en sécurité pour le système en direct.

À mesure que les entreprises dépassent les agents expérimentaux, quels sont les indicateurs de mesure qui devraient déterminer si un agent est réellement prêt pour la production, et comment prévoyez-vous que la relation entre les agents AI et les ingénieurs humains évoluera au cours des prochaines années ?

Je jugerais la préparation pour la production par la fréquence à laquelle les actions d’un agent AI produisent les résultats souhaités, ses conclusions tiennent face à ce qui était réellement vrai en production, les conclusions non étayées sont détectées avant l’action et si l’agent échoue de manière visible et sûre lorsque les preuves ne sont pas là. Pour les agents d’ingénierie, la précision des résultats vérifiés, la couverture des preuves, le temps pour confirmer la cause profonde, le taux de réussite des procédures de secours et les résultats après l’action sont les métriques clés sur lesquelles nous devrions nous concentrer.

Au cours des prochaines années, je m’attends à ce que les agents prennent en charge davantage la collecte de preuves et les premières investigations, ainsi que la supervision des flux de travail agences et l’apprentissage continu à partir de l’expérience et des commentaires, tandis que les ingénieurs établissent les politiques, résolvent l’ambiguïté, approuvent les actions à haut risque et guident les systèmes agences auto-améliorants. La confiance s’étendra au flux de travail après le flux de travail. Les agents qui peuvent retracer leurs conclusions jusqu’à des preuves en direct et divulguer clairement ce qu’ils n’ont pas pu vérifier gagneront une plus grande autonomie. Ceux qui ne le peuvent pas resteront limités à des tâches étroites et à faible risque, quelle que soit leur fluidité.

Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Lightrun.